On 05/08/2018 03:47 PM, David Jones wrote:
On 05/08/2018 03:02 PM, Alex wrote:
Hi,
Does anyone have any special techniques for catching these invoice
phish emails?
https://pastebin.com/raw/TfvhUu0X
I've added a few body rules, and even despite training previous
similar messages as spam, they continue. These emails very closely
resemble legitimate email regarding invoices that purchasing people
fall for them all the time.
Senderscore greater than 90, and routed through O365.
The domain is no longer defined in DNS, but even the x-originating-ip
is not currently listed on any RBL.
I ran it through my SA platform manually:
Content analysis details: (5.9 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
1.2 ENA_SUBJ_INVOICE Subject contains suspicious invoice wording
2.2 MISSING_HEADERS Missing To: header
-3.2 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature
from author's
domain
3.2 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net)
-0.1 DKIM_VALID Message has at least one valid DKIM or DK
signature
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not
necessarily valid
0.2 ENA_NO_TO_CC No To: or Cc: so it must have been
completely Bcc'd
0.2 ENA_FREEMAIL No description available.
2.2 ENA_DIGEST_FREEMAIL Freemail account hitting message digest
spam seen
by the Internet (DCC, Pyzor, or Razor).
What I have had to do is basically increase the score on all invoice
emails to try to block the bad ones and then whitelist the good ones.
That email was BCC'd which is another suspicious trait which is why I
bump up the score for MISSING HEADERS. I have other ways to penalize
these emails at SMTP time based on the number of BCC'd recipients if
this were received by my servers but I can't tell after the fact like this.
There is so much junk coming out of Office 365 right now from
compromised accounts and otherwise that it's really hard to accurately
filtering O365 email. I have created a rule based on the
X-OriginatorOrg: header to start subtracting points for known OK senders
and then bumping up other rule hits like invoice-related ones that come
from O365. I know this doesn't help with compromised accounts in known
OK Orgs but it definitely cuts down the majority of the fake invoice
emails.
header __RCVD_OFFICE365 Received =~
/\.outbound\.protection\.outlook\.com \[/
header __RCVD_OFFICE365_PROXY X-ClientProxiedBy =~
/\.outlook\.com \(/
header __OFFICE365_TRUST_ORG X-OriginatorOrg =~
/^(ena\.com|example\.com)/
meta TRUSTED_O365_ORG __RCVD_OFFICE365 && __OFFICE365_TRUST_ORG &&
(SFP_PASS || DKIM_VALID_AU)
score TRUSTED_O365_ORG -1.2
meta TRUSTED_O365_ORG_INVOICE TRUSTED_O365_ORG && SUBJ_INVOICE
score TRUSTED_O365_ORG_INVOICE -1.2
header SUBJ_INVOICE Subject =~
/([Ii]nvoice|ACH|Payment.Advice)/
describe SUBJ_INVOICE Subject contains suspicious invoice
wording
score SUBJ_INVOICE 1.2
I am sure that now I have posted my SUBJ_INVOICE rule on this list that
the spammers will deviate slightly and I will have to add more regex to
my rule. I know they want to mimic other commercial invoices so they
will not change it too much.
One more thing. I have expanded my definition of FREEMAIL to any Google
and Office 365 senders like this:
header __RCVD_YAHOO Received =~ /\.yahoo\.com \[/
header __RCVD_HOTMAIL Received =~ /\.hotmail\.com \[/
header __RCVD_GOOGLE Received =~ /\.google\.com \[/
header __RCVD_OFFICE365 Received =~
/\.outbound\.protection\.outlook\.com \[/
header __RCVD_COX_NET Received =~ /\.cox\.net \[/
header __RCVD_RR_COM Received =~ /\.rr\.com \[/
header __RCVD_CHARTER_NET Received =~ /\.charter\.net \[/
header __RCVD_COMCAST_NET Received =~ /\.comcast\.net \[/
header __RCVD_CENTURYLINK_NET Received =~
/\.onyx\.syn-alias\.com \[/
header __RCVD_HUGHES_NET Received =~ /\(mx\.hughes\.net \[/
meta __RCVD_FREEMAIL (__RCVD_YAHOO || __RCVD_HOTMAIL
|| __RCVD_GOOGLE || __RCVD_OFFICE365 || __RCVD_COX_NET ||
__RCVD_CHARTER_NET || __RCVD_COMCAST_NET || __RCVD_RR_COM ||
__RCVD_CENTURYLINK_NET || __RCVD_HUGHES_NET)
meta ENA_FREEMAIL (FREEMAIL_FROM ||
FREEMAIL_REPLYTO || FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL)
score ENA_FREEMAIL 0.2
Then I use the ENA_FREEMAIL rule in meta rules to bump up the
sensitivity of mail passing through these sources just like other
non-trusted FREEMAIL.
NOTE: The Received headers above are Postfix-style so you may have to
adjust the rule to fit your MTA's style or what you are trying to target.
--
David Jones
