Emails from Outside the Organization with Company Domains

Description

Phishers will often try to send emails where the from address uses your organization's domain name, e.g., emailing finance from yourceo@yourcompany.com. Detect that now!


Use Case

Advanced Threat Detection

Category

Endpoint Compromise, SaaS

Alert Volume

Very Low (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Initial Access

MITRE ATT&CK Techniques

Spearphishing Link

MITRE Threat Groups

APT28
APT29
APT32
APT33
APT39
Cobalt Group
Dragonfly 2.0
Elderwood
FIN4
FIN8
Kimsuky
Leviathan
Machete
Magic Hound
Night Dragon
OilRig
Patchwork
Stolen Pencil
TA505
Turla

Kill Chain Phases

Delivery

Data Sources

Email

   How to Implement

Implementation of this example (or any of the First Time Seen examples) is generally very simple.

  • Validate that you have the right data onboarded, and that the fields you want to monitor are properly extracted.
  • Make sure that you specify the correct domain name (or domain names) that belong to your company.
  • Save the search.

For most environments, these searches can be run once a day, often overnight, without worrying too much about a slow search. If you wish to run this search more frequently, or if this search is too slow for your environment, we recommend leveraging a lookup cache. For more on this, see the lookup cache dropdown below and select the sample item. A window will pop up telling you more about this feature.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

Sending emails from your organization's domain from outside the organization is not uncommon, but new sources should be rare and investigated. Because this search has a behavioral component, only new sources (or very rare sources you haven't seen before, such as maybe quarter-end notifications) should show up and be investigated. Those can be filtered out, or you can use the lookup cache to build a long baseline that allows for it.

The only other source of false positives here will be more IP addresses from known and trusted vendors -- you can filter out entire cidr ranges, or just quickly dismiss the alerts based on forward and reverse DNS matching both matching an allowed source.

   How To Respond

When this search returns values, initiate your incident response process and capture the time of the event, the system that originated the incoming mail and if possible identify the sender, recipient, subject of the mail and attachments, if any. Contact the recipient and mail administrator. If it is authorized behavior, document that this is authorized and by whom. If not, the user credentials may have been used by another party and additional investigation is warranted.

   Help

Emails from Outside the Organization with Company Domains Help

This example leverages the Simple Search assistant. Our dataset is an anonymized collection of email logs centered around a particular user for a month.

SPL for Emails from Outside the Organization with Company Domains

Demo Data

First we pull in our demo dataset.
Then we filter for where the sender is *@mycompany.com, but the incoming_address is not in our internal environment (update this with your environment's details).
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
Next we calculate the most recent value in our demo dataset
We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset.

Live Data

Here we start with our basic dataset of email logs, where we have a sender address who uses our company's email addresses, but where the IP address isn't a part of our environment.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Cisco ESA Live Data

Here we start with our basic dataset of Cisco ESA (aka Ironport) logs, where we have either an MID (Message ID) or ICID (Incoming Connection ID).
Ironport logs will have several messages with just ICID, and many with just MID. We want to ultimately analyze MIDs, but we need to tag those ICID fields that don't have any MID with the MIDs that came on that connection. Eventstats will let us do that, without otherwise changing the dataset. If two messages (MIDs 159950 and 159951) came across one incoming connect (ICID 102501), after this the events would look the same except all logs with ICID 102501 would now have a multi-value field called MID with the values 159950 and 159951.
Now we can aggregate the source IPs and sender addresses of every incoming message.
Finally we can filter in on those that have a sender domain that belongs to our company, but didn't originate from our environment.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Accelerated Data

Here, tstats is pulling in one command a super-fast count per sender, per day of emails where the sender domain is our organization, but the email did not originate from our organization
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.