Original posting as chasemullins.com
Log Sources: Log all the things!! However, for the purpose of this post you only need your Exchange logs and those from your spam gateway (Cisco IronPort in this example).
Scenario: Phishing has evolved far beyond Nigerian scams to the point that it will catch even the tech savvy from time to time. Spam gateways go a long way in prevention but they still lack the intelligence to catch decent phishing.
Purpose: Provide early detection of phishing email.
Exchange will often lie as to the SMTP sender. IronPort however, does not. i.e. firstname.lastname@example.org will masquerade as email@example.com, Exchange will display it as such, the recipient will trust the email and the hyperlink that leads to the malicious payload. Compromise complete….sit back and profit.
As you can see, this is a true correlation rule that compares Exchange and IronPort logs for the following:
- Is the recipient the same?
- Is the sender different? (detects the masquerading mentioned)
- Did IronPort see the event first?
- Lastly, are the Subject lines the same? In Exchange, the Subject comes in as message. IronPort however, logs it as Device Custom String 6. A contains operator is used only because the subject has a space before it in Exchange events, at least as of connector version 126.96.36.19982.0.
Get your aggregation correct:
Above everything, this proved to be the most crucial part of this rule. Variations of # of matches within a longer timeframe caused the rule to deactivate due to excessive partial matches.
Play with your own phishing rules and let me know if you get something better with the same logs. Prost!