Detecting account compromise with UEBA detection packages
Share on Twitter
Share on LinkedIn
Share on Facebook
Share by email
Print
Threat detection at Elastic
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.
The problem: Detecting a compromised account
Creating detections for compromised accounts can be one of the most challenging alerts for a security engineer to build. Every network is unique and has different definitions of what is “normal” activity.
A method of detection that has been growing in popularity recently involves building models called user entity behavior analytics (UEBA). These model the normal behavior of an account or system and work with machine learning to teach your environment how to detect when something strange happens. Traditionally, building these models can be complex, expensive, and prone to false positives. Model accuracy can be reduced if the models are trained on events that typically cause false positives, like transferring users to a new team, adding new accounts or systems, or users logging in while on a business trip.
The challenge is to detect activity when an account has been compromised without the alerts getting lost in the noise of false positives. In a modern network, there are a large number of different accounts that need to be tracked per user, such as their account activity in Slack, Okta, GitHub, O365, Active Directory, Salesforce, ServiceNow, and any other business system you use.
In this blog post, I will show you one of the approaches we are using internally at Elastic to create UEBA detection packages within our SIEM that are easier to build and maintain and also less prone to false positives. These UEBA packages can also be built entirely within the Elastic Security detection engine without the need for any additional transforms or external systems.
>> Elastic Global Threat Report: Top cybersecurity forecasts and recommendations
The solution: UEBA detection packages
A UEBA detection package is what we call a group of detection rules that work together to create alerts on truly anomalous behavior by an account or an entity. To do this, we create a collection of building block rules that individually alert on new activity even though that by itself may not be a high confidence indication that something is malicious. Each of these rules has a tag that marks it as part of the UEBA detection package. These building block alerts are not visible by default in the SIEM alert view, and we do not use the alert actions to send these alerts out of the SIEM.
After the UEBA detection package building block rules are applied, we implement threshold rules for each one that use the alerts index to identify elements of the UEBA package within different alerts. This can include tags for a user, machine, or source IP address and creates an alert based on all of the information available. For example, a UEBA alert would be created when a Slack login session is seen from a new device in a new location and it is conducting irregular activity. If the login is from a new location but there was no change in device or regular behavior, it doesn’t create an alert. This UEBA alert has a low false positive rate and is set at a higher severity level than any individual alert.
Many of our UEBA building block alerts are new terms alerts because they will create a signal when something new happens with an account. A new terms rule generates an alert for each new term detected in source documents within a specified time range. You can also detect a combination of up to three new terms (for example, a host.ip and host.id that have never been observed together before). An example of a UEBA new terms building block rule would be to alert on a new source.ip or geographic region for a service account, or a new user agent for a login session.
How to create a UEBA detection package in Elastic Security
The first step to building a UEBA detection package is to identify the data source you will be building for and create a plan for the type of activity that you want to detect. Spend some time exploring your data to learn what normal user activity looks like. Once you know what normal looks like for an account, you can then plan your building block detections for the abnormal behaviors. You will also need to decide on a tag name for your building block rules. The tag field is case sensitive, so you will have to have the same case for each tag.
From within the Security application, navigate to the Rules page and select Create new rule.
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.
Example UEBA package for GitHub
A lot of companies like Elastic use an “Infrastructure as code” technology to automate the management of their cloud infrastructure. Infrastructure as code means that making a change to the code within a repository will cause the systems to make changes to your infrastructure. This means that the repositories and the user accounts that can update the repos should be considered critical assets.
Building these detections requires that you configure the Elastic GitHub Audit logs integration and collect these for your SIEM. In addition to collecting the standard logs from GitHub, we also enrich them to add the user’s email address to the events so we don’t have to manually look up the owner of the associated account.
We pay special attention to the GitHub personal access tokens (PAT) in our GitHub detections with some new term detections specifically for PATs rather than the user account. One of the common ways an adversary will compromise a GitHub account is by finding a PAT and then using that access token from their own infrastructure. These tokens are created by the users with very little oversight and control from administrators, and they are often used in automation so they can regularly be found on systems in scripts, shell history, environment variables, or saved into a crash file. Each PAT has a unique ID, which is in the field json.token_id. A json.token_id value of 0 means that a token is not being used and that the user has authenticated to GitHub in a different way, for example via Secure Shell.
GitHub UEBA building block rules
We start by creating several building block alerts that all have the tag GitHub UEBA.
We use a lot of new terms rules to create signals when new behaviors are seen on an account or a PAT. We have a list of our approved service accounts that are used for automation tools, and we have created additional detection rules specifically for any new activity on those accounts.
Below is a list of the building block rules that we deployed for our GitHub UEBA. These six alerts are not visible in the SIEM by default.
- New private repo activity for a user: This alert will trigger when a user clones, fetches, or pushes to a private repo that they haven’t used in the past 30 days.
- 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.
GitHub UEBA threshold alerts
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.
Example: UEBA package for Slack
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.
Slack UEBA building block rules
To start out, we created three new terms rules to detect new behavior for an account within the last 30 days. Each of these alerts has the custom Slack UEBA tag, so they can be used as part of the package.
Slack UEBA building block rules
- New login for a Slack user: This alerts on any new Slack login for a user that doesn’t often log in. Most organizations set the Slack sessions to last for a long time so users don’t have to log in regularly. We use the alert suppression feature in the Elastic SIEM to deduplicate the alerts by the user and source IP, so we don’t see multiple alerts when a new user is setting up multiple devices
- 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.
Keep critical assets safe with faster detection and response
Detecting a compromised account is one of the most challenging things to do in security. By creating UEBA detection packages for each of our critical business systems, we have dramatically improved our ability to detect strange activity from an account without overwhelming our security analysts with a flood of false positives. Building these UEBA packages in your own environment can help you protect your most critical assets by identifying and responding faster to a compromised user account.
Learn more about threat hunting with Elastic Security.
The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.
Share
Share on Twitter
Share on LinkedIn
Share on Facebook
Share by email
Print
