Flight Risk Emailing

Description

This search implements several heuristics to look for indications that a user is a flight risk. While most savvy employees will use a personal email address when emailing competitors, everyone in Security has some story of employees who don't, as it will happen. Detect when it does.


Use Case

Insider Threat

Category

Insider Threat

Security Impact

Detecting users who are about to leave, before they actually give notice, can provide you the opportunity to potentially fix the situation for an unhappy employee, but also can help you prevent the exfiltration of sensitive data (which usually happens before an employee actually gives notice). Look for the indications that an employee may be leaving, by checking email logs.

Alert Volume

Medium (?)

SPL Difficulty

Medium

Journey

Stage 4

Data Sources

Email

   How to Implement

This search leverages email logs, with attachment data. You can pull this data in from your email system, or from Splunk Stream. See How to Respond for more details.

   Known False Positives

There is a variety of different rules being implemented here with varying levels of confidence. See How to Respond for more details.

   How To Respond

There are several checks being run in this search. Most of these will require some tuning, and are often best to combine with another correlation searches that look for anomalous activities (e.g., data exfiltration).

  • Emailing Competitors: while there can be legitimate reasons to email competitors, there are several concerns as well. We don't have concrete guidelines for tuning this search, and consider it beta and high false positive.
  • Email to careers@ / jobs@ / recruiting@: There are a few common email aliases used for job sites. If a user is emailing multiple recruiting aliases, alert on that. Low false positives.
  • Outbound Attachments Mentioning Resume: Look for someone emailing out a resume. Medium false positives.
  • Outbound Attachments Mentioning Resume and Name: Look for someone emailing out a resume that has their name in it. Low false positives.

You should likely not look at the results of this search directly, but correlate it with other risky events via the Risk Framework in ES or the Threat Models in UBA.

   Help

Flight Risk Emailing Help

This example leverages the simple search assistant. Our dataset is an anonymized collection of email logs.

SPL for Flight Risk Emailing

Demo Data

First we start by pulling our demo email logs, and filter for outbound emails.
In order to understand if a user's name is in the filename, we need to know what a user's name is. Lets look up this data in LDAP output from the ldapsearch app, detailed in the "Pull List of Privileged Users" example.
Now we use the first name and last name to look up different incarnations in the attachment, storing the result (1 or 0) in a field called hasNameInAttachment. (Why not filter directly? We want to be able to make a big search in the next line, and while you could do that with | where all in one.. most people would prefer not to.) We're looking for first name, or last name, or first initial + last name, so we would get resume_jane.pdf and smith_resume.pdf and jsmith.docx.
Now we actually do the search. We look to see if the filename is in the attachment, we look to see if the recipient looks like a third party careers address, and we look to see if there is a resume attached.
The bucket command flattens the timestamps so we can easily see how many days we saw this behavior on.
Almost done. Now we do some stats to see if it's a one-off, or if this is happening over the course of multiple days. We also list the recipient addresses and emails, for convenience.
Finally, we filter for where the activity occurs over multiple days, or there are many destinations or instances of the attachment.

Live Data

First we start by pulling our email logs, and filter for outbound emails.
In order to understand if a user's name is in the filename, we need to know what a user's name is. Lets look up this data in LDAP output from the ldapsearch app, detailed in the "Pull List of Privileged Users" example.
Now we use the first name and last name to look up different incarnations in the attachment, storing the result (1 or 0) in a field called hasNameInAttachment. (Why not filter directly? We want to be able to make a big search in the next line, and while you could do that with | where all in one.. most people would prefer not to.) We're looking for first name, or last name, or first initial + last name, so we would get resume_jane.pdf and smith_resume.pdf and jsmith.docx.
Now we actually do the search. We look to see if the filename is in the attachment, we look to see if the recipient looks like a third party careers address, and we look to see if there is a resume attached.
The bucket command flattens the timestamps so we can easily see how many days we saw this behavior on.
Almost done. Now we do some stats to see if it's a one-off, or if this is happening over the course of multiple days. We also list the recipient addresses and emails, for convenience.
Finally, we filter for where the activity occurs over multiple days, or there are many destinations or instances of the attachment.

Screenshot of Demo Data