Can't get enough of those EvilNumbers...
Turns out I ordered Norton for like a gazillion machines. Add this number, +1(867)768-0009, to the list thusly: Services Activated Successfully. Order Details:- 0rder Date: July 12, 2021 Product : Norton Amount : USD 311.06 Order ID : AKSF-624F Payment Mode :Auto-Debit If you have any issues regarding this order, Connect with us: +1(867)768-0009. Thanks and Regards, +1(867)768-0009. FWIW, -- Jared Hall
Re: Email Phishing and Zloader: Redux
1) Kenneth: Uncomment the line in v343. Rules in the present KAM.cf are thusly: ifplugin Mail::SpamAssassin::Plugin::OLEVBMacro # increase number of mime parts checked olemacro_num_mime 10 if (version >= 3.0040005) body KAM_OLEMACRO eval:check_olemacro() describe KAM_OLEMACRO Attachment has an Office Macro score KAM_OLEMACRO 7.5 body KAM_OLEMACRO_MALICE eval:check_olemacro_malice() describe KAM_OLEMACRO_MALICE Potentially malicious Office Macro score KAM_OLEMACRO_MALICE 10.0 body KAM_OLEMACRO_ENCRYPTED eval:check_olemacro_encrypted() describe KAM_OLEMACRO_ENCRYPTED Has an Office doc that is encrypted score KAM_OLEMACRO_ENCRYPTED 3.0 #This may cause more CPU usage olemacro_extended_scan 1 body KAM_OLEMACRO_RENAME eval:check_olemacro_renamed() describe KAM_OLEMACRO_RENAME Has an Office doc that has been renamed score KAM_OLEMACRO_RENAME 0.5 meta GB_OLEMACRO_REN_VIR ( KAM_OLEMACRO_RENAME && FORGED_OUTLOOK_HTML ) describe GB_OLEMACRO_REN_VIR Olemacro and fake Outlook score GB_OLEMACRO_REN_VIR 10 endif body KAM_OLEMACRO_ZIP_PW eval:check_olemacro_zip_password() describe KAM_OLEMACRO_ZIP_PW Has an Office doc that is password protected in a zip score KAM_OLEMACRO_ZIP_PW 1.0 body KAM_OLEMACRO_CSV eval:check_olemacro_csv() describe KAM_OLEMACRO_CSV Macro in csv file score KAM_OLEMACRO_CSV 5.0 #meta KAM_OLEMACRO_ZIP_PW_NOMID ( KAM_OLEMACRO_ZIP_PW && MISSING_MID ) #describe KAM_OLEMACRO_ZIP_PW_NOMID OLE macro sent by a bot / ratware #score KAM_OLEMACRO_ZIP_PW_NOMID 5.0 meta KAM_OLEMACRO_ZIP_BOT ( KAM_OLEMACRO_ZIP_PW && ( MISSING_MID || PDS_FROMNAME_SPOOFED_EMAIL ) ) describe KAM_OLEMACRO_ZIP_BOT OLE macro sent by a bot / ratware score KAM_OLEMACRO_ZIP_BOT 5.0 endif Yes, there does seems to be one "endif" too many but I don't think it matters much with this type of a plugin. Thanks for the information from hornetsecurity. It's the most comprehensive write-up on Zloader that I've seen. I did do some testing with Word and MHTML. A Word document when sent out is assigned Content-Type: application/msword and Content-Transfer-Encoding: base64. A MHTML file is sent out with Content-Type: text/html and Content-Transfer-Encoding: quoted-printable (w/ my document anyway). I'm curious as to what HornetSecurity saw in their E-mail MIME header. It DOES make a difference, at least regarding plugin scanning. But a .doc file is a .doc file as far as Word is concerned. I put forth a query to them. I'll let you know if they respond. -- Jared Hall I simpy uncommented it in /etc/spamassassin/v343.pre: # OLEVBMacro - Detects both OLE macros and VB code inside Office documents loadplugin Mail::SpamAssassin::Plugin::OLEVBMacro the KAM.cf takes care of the rest.
Re: SPAM scanned twice
I just forgot how email works, it seems. It just now struck me it is not be rescanned at all, but merely has the information posted again, so it appears as part of the "new message"? I thought it odd the SPAM scores were identical. That should have been the first clue x four. But, no . . . In the words of Lt. Commander Data, I was "chasing an untamed ornithoid without cause". Perhaps sheepishly yours . . . . joe a. > On Monday 12 July 2021 at 20:07:16, Joe Acquisto-j4 wrote: > >> SpamAssassin 3.4.5 (2021-03-20) on Suse Leap 15.2 (their distro IIRC) >> >> Noticed that mail marked as SPAM was scanned again by SA after it had been >> "disposed" as an attachment. >> >> I uncommented "report_safe 0" and did a restart of SA. Next SPAM came >> through as a normal email, still marked as SPAM and only scanned once. > > I think we'd need to know a bit more about how you have SpamAssassin > connected > in with your MTA, and what your delivery paths are, to be able to comment > usefully. > > > Antony > > -- > GIT/E d- s+:--(-) a+ C$(---) UL$ P+(---)>++ L+++()$ !E W(-) N(-) > o? w--(---) O !M V+++(--) !PS !PE Y+ PGP+> t- !tv@ b+++ DI++ D--- e+++(*) h++ > 5? !X- !R K--? G- > >Please reply to the list; > please *don't* CC > me.
Re: Process of domain submission for inclusion in 60_whitelist_auth.cf
On 2021-07-12 at 14:38:43 UTC-0400 (Mon, 12 Jul 2021 20:38:43 +0200) Robert Harnischmacher is rumored to have said: > Hi Bill, > > thanks for the detailed explanations. I understand the purpose of the > def_whitelist_auth list better now, but wonder if its benefit is not > overcompensated by significant negative effects, certainly not desired by the > community. > > First of all, I would like to contribute some statistical findings: > > A look at the exemplary group of the largest 1,000 U.S. online stores > according to Alexa Rank shows that about 15 percent of the domains are > whitelisted in 60_whitelist_auth.cf. There are no significant and especially > no consistent differences in the email reputation of these 15 percent > compared to the rest of the top 1,000. Sure there is: they have a default WL entry in SpamAssasin. That's a reputation metric in itself, albeit a very noisy and incomplete metric. I feel like I need to point out that SpamAssassin is designed on the premise that there is no such thing as a perfect rule for discriminating between spam and ham. Imperfection in a SA rule or feature is not enough of a reason for it to be removed altogether. > This would not be a problem if the Spamassassin whitelist did not > unintentionally give the 15 percent a competitive advantage. Based on the > high spam score bonus of 7.5 points, which USER_IN_DEF_DKIM_WL and > USER_IN_DEF_SPF_WL bring, one can for example risk a higher frequency of mass > mailings, run riskier reactivation campaigns or write to "broader" > distribution lists: Possible spam scores, for example due to blacklisting, > would be ironed out by the above-mentioned "bonus". And indeed: With some > stores from the 15 percent group I see again and again - partly even > consistently - serious blacklistings. If you (or anyone) has definitive evidence of a sender with a default WL entry sending spam which is classified by SA as ham incorrectly, you can submit it in a bug report and there's a very strong chance that the WL entry will be removed. Hand-waving about what the general feature of a default WL might enable for hypothetically listed senders is not an actionable bug report. If we removed every feature in SA that had hypothetical negative effects, it would be a useless and tiny bit of software. > There are about 16 DKIM rules and 12 SPF rules in Spamassassin that are meant > to evaluate in a technically automated way whether and how good the SPF and > DKIM implementation of a sender is. Interestingly, the comment in > 60_whitelist_auth.cf. says: "These listings are intended to (...) reward > senders that send with good SPF, DKIM, and DMARC." With this in mind, it > seems like a logical overlap to me that USER_IN_DEF_DKIM_WL and > USER_IN_DEF_SPF_WL introduce additional high "bonus" scores based solely on > human judgment at the one-time point of a check. Almost all of the senders > listed in 60_whitelist_auth.cf have changed their email service providers one > or more times over the years, with sometimes significant changes in the > quality of their deliverability settings and with significant differences in > list hygiene, sending frequency, etc. But the spam score bonus of 7.5 remains > nailed down all the time! Anyone using SA can set that value to anything they like, including zero, or knock out individual senders from the list as they like. For example, I knock the bonus for those rules down to 2 points on systems where I control scoring. Anyone running SA can do the same. > In short, I would recommend considering removing the DKIM and SPF whitelists > in Spamassassin altogether. It would make the spam-fighting world a better > and fairer place! I am unconvinced that "better" is true and I am quite sure that "fairer" doesn't have a useful definition in this context. Nothing in SA is designed to provide "fairness" between different senders or between senders and recipients. We are heavily biased towards our users, who are the recipients and their immediate service providers. If a feature benefits THEM uniformly while unevenly punishing/benefitting various senders, that's just fine. The purpose of the default WL is to eliminate "false positive" spam identification for mail whose senders have had such problems for affirmatively wanted mail (as noticed by SA users) while NOT sending any discernible spam. As far as I can tell, there's never been a case of a sender successfully advocating for inclusion or even being consulted about inclusion or removal. We've not had any cases of a listing being a matter of meaningful controversy. I have no idea how we'd handle anything resembling an edge case. >> Am 29.06.2021 um 06:52 schrieb Bill Cole >> : >> >> On 2021-06-28 at 17:04:05 UTC-0400 (Mon, 28 Jun 2021 23:04:05 +0200) >> Robert Harnischmacher >> is rumored to have said: >> >>> In which form can one submit the subdomain of a mail sender for the >>> integration in
Re: Process of domain submission for inclusion in 60_whitelist_auth.cf
Hi Bill, thanks for the detailed explanations. I understand the purpose of the def_whitelist_auth list better now, but wonder if its benefit is not overcompensated by significant negative effects, certainly not desired by the community. First of all, I would like to contribute some statistical findings: A look at the exemplary group of the largest 1,000 U.S. online stores according to Alexa Rank shows that about 15 percent of the domains are whitelisted in 60_whitelist_auth.cf. There are no significant and especially no consistent differences in the email reputation of these 15 percent compared to the rest of the top 1,000. This would not be a problem if the Spamassassin whitelist did not unintentionally give the 15 percent a competitive advantage. Based on the high spam score bonus of 7.5 points, which USER_IN_DEF_DKIM_WL and USER_IN_DEF_SPF_WL bring, one can for example risk a higher frequency of mass mailings, run riskier reactivation campaigns or write to "broader" distribution lists: Possible spam scores, for example due to blacklisting, would be ironed out by the above-mentioned "bonus". And indeed: With some stores from the 15 percent group I see again and again - partly even consistently - serious blacklistings. There are about 16 DKIM rules and 12 SPF rules in Spamassassin that are meant to evaluate in a technically automated way whether and how good the SPF and DKIM implementation of a sender is. Interestingly, the comment in 60_whitelist_auth.cf. says: "These listings are intended to (...) reward senders that send with good SPF, DKIM, and DMARC." With this in mind, it seems like a logical overlap to me that USER_IN_DEF_DKIM_WL and USER_IN_DEF_SPF_WL introduce additional high "bonus" scores based solely on human judgment at the one-time point of a check. Almost all of the senders listed in 60_whitelist_auth.cf have changed their email service providers one or more times over the years, with sometimes significant changes in the quality of their deliverability settings and with significant differences in list hygiene, sending frequency, etc. But the spam score bonus of 7.5 remains nailed down all the time! In short, I would recommend considering removing the DKIM and SPF whitelists in Spamassassin altogether. It would make the spam-fighting world a better and fairer place! Best, Robert > Am 29.06.2021 um 06:52 schrieb Bill Cole > : > > On 2021-06-28 at 17:04:05 UTC-0400 (Mon, 28 Jun 2021 23:04:05 +0200) > Robert Harnischmacher > is rumored to have said: > >> In which form can one submit the subdomain of a mail sender for the >> integration in 60_whitelist_auth.cf. Which information is required for >> consideration? > > There is no process by which a sender can pro-actively apply for the addition > of a def_whitelist_auth entry in that file. Entries are added rarely, when a > committer to the project sees a need for an entry due to false positives or > borderline scoring of messages from a sender who is not known to send ANY > spam and is known to send "ham" that users value highly. Removal of entries > is equally ad hoc and unilateral, and more rare. If a committer is convinced > that an entry is causing spam to be misclassified as ham, they can remove > that entry. > > Note that the above describes concrete process and vague criteria, not any > sort of objective formal policy. There is no objective official policy. The > normal state for any sender is to not have an entry. I believe that most > committers to the project would agree with me that ideally there would be no > such list because high-value ham would be more readily distinguishable from > spam. Additions and removals happen when they are believed to address a > concrete problem being experienced by actual SpamAssassin users. I don't > recall any significant disagreements about entries in that list, but if there > were any they could be discussed here or on the 'dev' list. Ultimately, the > PMC would be the final authority on including an entry or not, however our > processes for deciding anything that becomes an issue for the PMC is biased > towards stability, not agility. > > > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire smime.p7s Description: S/MIME cryptographic signature
Re: SPAM scanned twice
On Monday 12 July 2021 at 20:07:16, Joe Acquisto-j4 wrote: > SpamAssassin 3.4.5 (2021-03-20) on Suse Leap 15.2 (their distro IIRC) > > Noticed that mail marked as SPAM was scanned again by SA after it had been > "disposed" as an attachment. > > I uncommented "report_safe 0" and did a restart of SA. Next SPAM came > through as a normal email, still marked as SPAM and only scanned once. I think we'd need to know a bit more about how you have SpamAssassin connected in with your MTA, and what your delivery paths are, to be able to comment usefully. Antony -- GIT/E d- s+:--(-) a+ C$(---) UL$ P+(---)>++ L+++()$ !E W(-) N(-) o? w--(---) O !M V+++(--) !PS !PE Y+ PGP+> t- !tv@ b+++ DI++ D--- e+++(*) h++ 5? !X- !R K--? G- Please reply to the list; please *don't* CC me.
SPAM scanned twice
SpamAssassin 3.4.5 (2021-03-20) on Suse Leap 15.2 (their distro IIRC) Noticed that mail marked as SPAM was scanned again by SA after it had been "disposed" as an attachment. I uncommented "report_safe 0" and did a restart of SA. Next SPAM came through as a normal email, still marked as SPAM and only scanned once. Don't recall seeing that behavior mentioned anywhere and wondering if it is "working as designed"?
Re: Email Phishing and Zloader: Such a Disappointment
--On Sunday, July 11, 2021 4:55 PM -0400 "Kevin A. McGrail" wrote: We use the olevbmacro detection added to SA. I would guess that's blocking the payload.I would guess that's blocking the payload. On 11.07.21 13:35, Kenneth Porter wrote: I see the plugin in the distribution but it doesn't appear to be loaded by default and the rules in the plugin's man page don't appear in the downloaded rules. So I guess I need to create a custom cf file. I simpy uncommented it in /etc/spamassassin/v343.pre: # OLEVBMacro - Detects both OLE macros and VB code inside Office documents loadplugin Mail::SpamAssassin::Plugin::OLEVBMacro the KAM.cf takes care of the rest. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Save the whales. Collect the whole set.
Re: Email Phishing and Zloader: Such a Disappointment
On 7/11/2021 5:11 PM, John Hardin wrote: "The other parts contain an application/vnd.ms-officetheme and an application/x-mso file. Which (in addition to the text/xml files) are used by Microsoft Word to load the embedded Word document." Would the presence of all three of those MIME types be a scorable indicator? On Sun, 11 Jul 2021, Kevin A. McGrail wrote: If you can get me a spample, I'm sure I can tell you but in general we block macros so that's all that's needed. Likely the OLEVBMacro plugin and KAM ruleset is blocking all of these already if you have the plugin enabled. On 12/07/2021 07:40, Dave Funk wrote: Aren't there already rules and heuristics in ClamAV for detecting VBmacros in office docs? I've got two copies of ClamAV running, one used as a blocking direct milter with default rules and another one feeding into the SA "clamav.pm" plugin with extra rules and heuristics/algorithms enabled. On 12.07.21 08:51, Dominic Raferd wrote: I quarantine emails that are caught by ClamAV with 'ScanOLE2 true' and 'AlertOLE2Macros true'; these are then checked by command-line tool mraptor (part of olevba) to see if the macros are truly malicious. I will try the OLEVBMacro plugin alongside, thanks for the heads up. note that standard SA rules don't contain any rule using the OLEVBMacro functions, but the KAM.cf do. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe.
Re: Email Phishing and Zloader: Such a Disappointment
>On Monday, July 12, 2021, 04:01:03 AM GMT+2, Kevin A. McGrail wrote: >If you can get me a spample, I'm sure I can tell you but in general we >block macros so that's all that's needed. Likely the OLEVBMacro plugin >and KAM ruleset is blocking all of these already if you have the plugin >enabled. The inital email has not a macro... they use an old MS feature where a document marks itself as "incomplete" andtells MS Office App where to download the missing part, that contains the payload. To my knowledge (very limited) only zipped versions of MS files can use that feature. Within them, there are 2 data structures to checkif you want to find prizes... -Pedro.
Re: Email Phishing and Zloader: Such a Disappointment
On 12/07/2021 07:40, Dave Funk wrote: On Sun, 11 Jul 2021, Kevin A. McGrail wrote: On 7/11/2021 5:11 PM, John Hardin wrote: "The other parts contain an application/vnd.ms-officetheme and an application/x-mso file. Which (in addition to the text/xml files) are used by Microsoft Word to load the embedded Word document." Would the presence of all three of those MIME types be a scorable indicator? If you can get me a spample, I'm sure I can tell you but in general we block macros so that's all that's needed. Likely the OLEVBMacro plugin and KAM ruleset is blocking all of these already if you have the plugin enabled. Aren't there already rules and heuristics in ClamAV for detecting VBmacros in office docs? I've got two copies of ClamAV running, one used as a blocking direct milter with default rules and another one feeding into the SA "clamav.pm" plugin with extra rules and heuristics/algorithms enabled. I quarantine emails that are caught by ClamAV with 'ScanOLE2 true' and 'AlertOLE2Macros true'; these are then checked by command-line tool mraptor (part of olevba) to see if the macros are truly malicious. I will try the OLEVBMacro plugin alongside, thanks for the heads up.
Re: Email Phishing and Zloader: Such a Disappointment
On Sun, 11 Jul 2021, Kevin A. McGrail wrote:
On 7/11/2021 5:11 PM, John Hardin wrote:
"The other parts contain an application/vnd.ms-officetheme and an
application/x-mso file. Which (in addition to the text/xml files) are used
by Microsoft Word to load the embedded Word document."
Would the presence of all three of those MIME types be a scorable
indicator?
If you can get me a spample, I'm sure I can tell you but in general we block
macros so that's all that's needed. Likely the OLEVBMacro plugin and KAM
ruleset is blocking all of these already if you have the plugin enabled.
Regards,
KAM
Aren't there already rules and heuristics in ClamAV for detecting VBmacros in
office docs?
I've got two copies of ClamAV running, one used as a blocking direct milter with
default rules and another one feeding into the SA "clamav.pm" plugin with extra
rules and heuristics/algorithms enabled.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-05491256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
