On Tue, 15 May 2018, Alex wrote:
Hi,
We received another of those phishes as a result of a compromised O365 account.
https://pastebin.com/raw/Fv5NKRAP
Anyone able to take a look and provide ideas on how to block them? It
passes with DKIM_VALID_AU, RCVD_IN_SENDERSCORE_90_100 and SPF_PASS.
It's missing headers, and I've written a rule to account for that, but
it would be great to have some other input.
Interestingly, it was passed through a mimecast system first.
The amount of Outlook/O365/Exchange headers in this email is enormous!
Thanks,
Alex
For openers either totally lose "RCVD_IN_HOSTKARMA_W" & "RCVD_IN_DNSWL_LOW"
rules, or set their score to something minimal (EG -0.1 instead of that honking
-2.5) or create a rule that detects the message being from O365 and meta it with
RCVD_IN_HOSTKARMA_W to then add an offsetting score to nullify the damage from
RCVD_IN_HOSTKARMA_W WRT O365.
(Can we get the maintainers of RCVD_IN_HOSTKARMA_W to remove that contagion pit
called O365 from their list of "good guy" sites?).
I've done a bit of all of the above so an incoming O365 message ends up with no
"brownie points" at all, so it's only scored on the merits of its contents.
Then look for custom anti-phish rulesets. Your example hit a rule
"RULEGEN_PHISH2" which was in a file 90_rulegen_phish.cf on my server.
(I'm sorry I don't remember where I got that from).
Train bayes, look for custom URIBL lists that might hit that powned website.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
