Detecting account compromise with UEBA detection packages

The Elastic InfoSec Threat Detection team is responsible for building, tuning, and maintaining the security detections used to protect all Elastic® systems. Internally, we call ourselves Customer Zero and we strive to always use the newest versions of our products. This blog details how we are building packages of detection rules that work together to create a high fidelity alert for strange user behavior.

From within the Create new rule interface, select the type of rule type you want to create for your building block rule. We use new terms rules for a lot of our building block rules, but any type of rule could be used.

After defining the rule type and query, the next step is to complete the About rule section. Within this section, you can add the tag you defined for the package in the Tags block.

If you don’t want these building block alerts visible in your SIEM by default, you will want to go to the Advanced settings and check the box to turn this into a building block alert.

After creating your collection of building block alerts that all contain the tag, you can then create a new Threshold alert that will create a new alert when multiple different building block alerts are seen with the same username. To do this, we build a threshold alert that queries the signals index pattern to search the open building block alerts.

When first creating a new UEBA detection package, I recommend that you have an observation period where you do not send the alerts to your production workflows. During this period, you can observe any alerts created and add any exceptions to the building block rules that may be needed to tune the alerts to your environment.

• New user agent for a user: This alert will trigger when there is a change to the user agent by a user for the first time in 30 days.

• New event.action for a PAT: This alert will trigger when a new action is seen for a PAT that hasn’t been seen in the last 7 days. An example of this is when an automation account does something brand new, like a git.clone.

• New PAT created for an account: This alert will trigger for a new PAT being used by an account that hasn’t used the PAT within the last 30 days. We use a new terms rule because PATs are controlled by the users and not the organization, so there are no events created in the organization’s GitHub audit logs when a user creates a new PAT. If an attacker has compromised a GitHub account, they may create a new highly privileged PAT to maintain access.

• New source IP for a service account: This alert will trigger when a service account is seen from a new source IP that hasn’t been identified in at least 30 days. Depending on your automation and network infrastructure, this rule could require tuning to filter out network blocks — for example, those used by GitHub for automations. For some environments, this detection rule may be impossible to filter to a reasonable level and may not work.
• Large number of private repos cloned by a user: This is a threshold alert looking for an account cloning more than 10 different private repos in an hour. This may be a common action for some automation accounts or user workflows and may require filtering.

For our GitHub UEBA package, we have two different UEBA alerts that are sent to the security analysts. The alerts have almost identical logic, but one alerts to activity only from the list of service accounts used by our DevOps and CI/CD systems. This rule has a lower threshold of building block alerts required to create it and a higher severity rating. 

The threshold rule that sends an alert to the Security team is triggered when we have more than one alert in an hour from the same user.name and source.ip. To do this, we build a threshold alert that queries the signals index pattern to search the open building block alerts. We filter the threshold alert to only the recent alerts that contain the Github UEBA tag that have not been closed by one of our workflows or analysts. The threshold rule will group the alerts by the user.name and source.ip and then create a high severity alert if three or more distinct signals were seen for the same user and source IP. Our service account detection rule contains additional filtering with a list of service account names to create a high severity alert when two or more signals are triggered for a user.name and source.ip.

Another example of the UEBA packages that our team has created for internal use at Elastic is a detection package for Slack focused on alerting the team to a compromised Slack account. Attackers can compromise a Slack account by stealing the session token through a social engineering attack, such as using a reverse proxy server like Evilnginx to steal the login information and bypass some MFA protections. Once they have compromised a Slack account, they will usually use that account to look for sensitive information being shared among employees, such as scripts or log files containing API keys or personal access tokens.

Building these detections requires that you configure the Elastic Slack integration to ingest the audit logs into your Elastic Stack. You can then use the logs-slack.audit* index pattern to build these alerts.

• New user agent for a Slack login session: This alerts to a change in user agent based on the login session ID. Each login session has a unique ID for the duration of that session. It is uncommon for the user agent value to change during a session and could be an indication that the session has been hijacked

• New country for a Slack user: Sometimes users travel between countries, but it could also be an indication that the account was compromised. This alert helps provide context when elevating other alerts. If your users are normally in offices and not traveling, you could use the source.geo.region_name or source.geo.city_name instead.

• High number of file downloads for a Slack user: This is a threshold rule that alerts when a user downloads 10 different files from Slack within a specific timeframe. This could be an indication of someone downloading files to look for sensitive information.

• High number of channel previews for a Slack user: This is a threshold rule that alerts when a user previews five or more different Slack channels. This could be an indication of a compromised account being used for reconnaissance.

After creating the behavior-based portion of the UEBA alerts, we can create a threshold rule that sends an alert to the Security team when more than three different alerts are seen for a user and source IP. To do this, we build a threshold alert that uses the signals index pattern to view existing alerts, and then we filter by open alerts that contain the ‘Slack UEBA’ tag. The threshold rule will then group the alerts by the user.email and source.ip and create a new alert when three or more different alerts names were seen.

A common false positive we see with this Slack UEBA package is from new employees that log in to Slack for the first time — this triggers the new login, new location, and new user agent alerts. To remove these false positives, we use SOAR automations to query our Okta event logs for the creation of the user account within the last 48 hours. To do this, use Action within the detection rule to send the full contents of the alert to our Tines SOAR as a .json. From Tines, we query Elasticsearch® via the API to search the Slack audit logs for any results for event.action:"user_created" AND slack.audit.entity.email : {{user.mail}}. If the results indicate that this is a new user, our SOAR system will use the signals API to automatically close the alerts in our SIEM. If there are no results, a notification is sent to the security analysts.