In Part 2 “Envelope Sender” field was used to match trusted 3rd party domains, but what if that field was also spoofed or did not have sender domain information needed to allow these messages.
Below we see an email that came in from the domain “rrd.com” with spoofed “from” and “Envelope Sender” fields.
Without another filter condition, we can not identify who the sender is. In addition, this field needs to work with “contain” logic and be capable of querying terms from the dictionary. After reviewing message details I found one field that will work – “message-id“. Let’s add it to logging and verify the information it records.
(Cluster ESA)> logconfig
Choose the operation you want to perform:
– NEW – Create a new log.
– EDIT – Modify a log subscription.
– DELETE – Remove a log subscription.
– SETUP – General settings.
– LOGHEADERS – Configure headers to log.
– HOSTKEYCONFIG – Configure SSH host keys.
– CLUSTERSET – Set how logs are configured in a cluster.
– CLUSTERSHOW – Display how logs are configured in a cluster.
[]> logheaders
[from]> message-id
[from, message-id]>
(Cluster ESA)> commit
Now messages are logged with “message-id” header information which contains domain information needed to build filter logic for trusted domains. Ironport groups this data at the end of message details and makes it easier to track.
(DCID 6314485) Delivery details: Message 18615547 sent to somone@company.com [(\’message-id\’, \'<OF8B34AB1B.95138EB2-ON86257F78.0071CB1C@rrd.com>\’), (\’from\’, \'”John Smith” <cfo@company.com>\’)]
After we’ve identified new field to match we need to change our filter to do logical OR on all trusted emails based on “Envelop Sender” or “message-id” field, then logical OR on “from” field for all execs and combine both results with logical AND.
This task is done with another Content Filter and new Message Header. First, create new Content Filter and add condition to evaluate “Envelop Sender” field against TrustedDomains content dictionary.
Next, add the second condition called “Other Header” and for header name enter “message-id“. This header will also reference TrustedDomains dictionary for match condition.
Combined conditions will look as following: if we do not find trusted domain in “Envelop Sender” field, we’ll also check custom header. Since this is logical OR more conditions can be added later without complicating the design.
The result of the above logic needs to be a single action. The way to accomplish it is by inserting a new header with the specific value. This is done under Add/Edit Header action by entering new header name (Ex. X-TrustedDomains) and value (Ex. true). Header Value is optional.
The end result filter will look as following: If “Envelop Sender” OR “message-id” fields contain trusted domain then the custom header will be added with value “true“.
Next, modify the original filter to reflect new header. Change “Envelop Sender” condition to “Other Header” with Header Name “X-TrustedDomains” and header value Does Not Equal “true“.
Under Actions add a new action to strip custom header if desired.
Final Content Filter will look as following: if “from” header matches one of the exec’s email address AND it is NOT coming from trusted domain THEN quarantine and alert.
Note the order of Content Filters is important once attached to Incoming Mail Policy.
Hopefully, this short tutorial will help you battle email scams as they are getting more evasive and sophisticated.