James Spiteri - Elastic Security Labs

Speeding APT Attack Confirmation with Attack Discovery, Workflows, and Agent Builder

James Spiteri,Dhrumil Patel — Wed, 18 Feb 2026 00:00:00 GMT

9:15 AM: The Non-Event - A headline breaks: "Chrysalis Backdoor: A Deep Dive into Lotus Blossom." Your CISO sends a Slack message: "Are we affected?"

In a traditional SOC, you’re about to lose your entire morning to a manual scramble - sifting through dozens of alerts, writing queries, manually checking VirusTotal, and pivoting across index patterns to build a timeline hoping you don’t miss something.

But in an Agentic SOC, the work is already done. Attack Discovery, running on its hourly schedule, had already correlated 5 critical alerts out of 30+ into a single attack narrative: "Malware with DLL Side-Loading Persistence." That discovery automatically triggered a workflow, which handed the findings to an agent. The agent used its tools and verified the malware hash on VirusTotal, searched your logs with ES|QL, checked the on-call schedule, created a case, and spun up a Slack incident channel with the on-call analyst already added, and also generated a CISO-ready summary — all before you sat down for coffee.

You reply to your CISO: "Already confirmed and triaged. The case is open. Here's the link."

This post explains how we built that pipeline: the integration of Attack Discovery, Workflows, and Agent Builder.

The threat: Chrysalis backdoor by Lotus Blossom

Threat actor profile

Campaign overview

Lotus Blossom executed a supply chain compromise of Notepad++ update infrastructure:

Attack Window: June 2025 – December 2025 (~6 months)
Vector: Hijacked Notepad++ update mechanism (WinGUp)
Method: Selective redirection of targeted users to malicious update servers
Payload: Previously undocumented "Chrysalis" backdoor
Discovery: Rapid7 MDR team, published 2026-02-02

Chrysalis backdoor capabilities

The Chrysalis backdoor is a sophisticated, feature-rich implant:

Custom encryption (LCG, FNV-1a hashing, MurmurHash)
Reflective DLL loading
API hashing for evasion
DLL sideloading via legitimate Bitdefender binary (BluetoothService.exe)
Full remote access capabilities
Persistent Windows service installation

Attack chain

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

MITRE ATT&CK mapping

| Tactic | Technique | ID | | :---- | :---- | :---- | | Initial Access | Supply Chain Compromise | T1195.002 | | Execution | User Execution | T1204.002 | | Persistence | Windows Service | T1543.003 | | Defense Evasion | DLL Side-Loading | T1574.002 | | Command & Control | DNS | T1071.004 |

The Challenge: Speed vs. Accuracy

When threat intelligence drops on a nation-state APT campaign, SOC teams face a brutal trade-off:

Speed: Executives want answers now. "Are we compromised?"

Accuracy: Analysts need time to hunt, correlate, and confirm before making the call.

Traditional workflows require analysts to:

Determine the scope of analysis and relevant search criteria
Manually search for IOCs across multiple data sources
Correlate alerts that may span days or weeks
Validate findings against threat intelligence
Build the attack timeline
Escalate with confidence

This process takes hours to days, during which an active attacker may exfiltrate data or move laterally.

The Solution: Attack Discovery + Workflows + Agent Builder

Elastic Security's AI-powered automation stack transforms this workflow from manual hunting to automated confirmation. But before we dive into the specific setup, it's worth understanding how the building blocks fit together.

Agents & Workflows: Two entry points, one composable architecture

Agent Builder gives you two primitives that work together:

Agents are the intelligence layer. They reason about a task, decide which tools to call, and adapt based on what they find. An agent can call search tools, MCP tools, and critically - workflows as tools.
Workflows are the structure layer. They're deterministic pipelines: steps run in order, reliably and repeatably. Any step in a workflow can optionally be an agent step, giving it the ability to reason mid-pipeline.

The two are fully composable. A workflow can invoke an agent. An agent can call a workflow. An agent step inside a workflow can call another workflow. Every connection is optional allowing you to mix and match based on what the problem demands.

This is what makes the architecture powerful: agents reason and decide; workflows execute and coordinate. For our Chrysalis attack scenario, we used both.

Our Flow

The Flow:

Many Alerts → Attack Discovery correlates disparate alerts into a single attack narrative
Attack Discovery → Generates an alert that triggers the workflow
Workflow → Invokes Agent Builder to analyze the attack discovery findings
Agent Builder → Calls enrichment workflows (VirusTotal, Threat Intel, ES|QL queries)
Agent Builder Calls a Workflow → Agent builder continues with incident response actions calling on workflow as a tool (case actions, isolate host, notify team)

Step 1: Attack Discovery surfaces the threat

Attack Discovery uses LLMs to analyze security alerts and identify attack patterns. Unlike traditional alert grouping, it understands the semantic relationships between alerts.

The alert queue: Needle in a haystack

Here's reality for a SOC analyst. You open the alerts page and see dozens of alerts across multiple hosts, users, and rules, combination of, mixed severities, mixed types, many of them noise.

Dozens of alerts. Multiple rules firing. Severity levels ranging from low to critical. Some are the Chrysalis attack. Some are unrelated Windows Defender events. Some are SIEM change detections from a completely different workflow. It’s difficult to find the coordinated attack in this wall of noise.

What Attack Discovery found

Attack Discovery analyzed all of these alerts and identified 5 alerts that belonged to a single coordinated attack - pulling them out of the noise and correlating them into one narrative:

Instead of presenting 5 individual alerts, Attack Discovery correlated them into a single discovery:

Malware with DLL Side-Loading Persistence

Malicious executable on srv-win-defend-01 escalated to persistence via BluetoothService.exe with DLL side-loading

Host: srv-win-defend-01
User: james_spiteri
Severity: Critical
Attack Chain: Initial Access → Execution → Persistence → Defense Evasion → C2

Attack Discovery also:

Mapped alerts to MITRE ATT&CK tactics
Identified the DLL sideloading technique
Flagged the suspicious persistence mechanism
Highlighted the C2 network indicator

Step 2: Scheduled discovery triggers the workflow

Attack Discovery doesn't require an analyst to click a button. We configured it to run on an hourly schedule, continuously analyzing the latest alerts for coordinated attacks.

When our hourly run kicked off, it ingested all alerts from the last hour including the Chrysalis-related alerts buried among routine detections and surfaced the DLL side-loading attack as a discovery.

Linking a workflow as an action step from attack discovery means every time Attack Discovery finds a coordinated attack, it automatically fires the workflow..

But here's what makes this approach different from traditional SOAR playbooks: the workflow doesn't script out every step. It hands the entire attack discovery to Agent Builder and says "figure it out."

Workflow definition

This is the real workflow we used consisting of two steps, that's it:

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id:         # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https:///app/agent_builder/conversations/)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: 
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

Why this workflow is so short

The entire automation is two steps:

initial_analysis: Send the attack discovery to Agent Builder with natural language instructions describing what you want done
followup_analysis: A failsafe that resumes the same conversation and asks the agent to verify all tasks were completed. Because agents call multiple tools in sequence and any individual tool call could time out or hit a transient error, this step ensures nothing falls through the cracks.

This is the fundamental shift: the workflow is the trigger and the safety net; the agent is the brain.

Under the hood: How we extended the Threat Hunting Agent

Before we continue with the results, it's worth pausing on what made this possible. One of Agent Builder's most powerful capabilities is that you can extend existing agents with additional tools. Rather than building from scratch, we took the default Threat Hunting Agent and added custom workflow-backed tools to give it the specific capabilities this scenario required.

What we added

Agent Builder ships with built-in platform tools like platform.core.generate_esql and platform.core.product_documentation. But the real power comes from adding your own. We extended the Threat Hunting Agent with tools across several categories:

Five custom tools. That's all it took to turn the default Hunting Agent into automatically verifying malware, searching logs, finding the on-call responder, creating a case, and spinning up an incident channel - all expediting the time to detect a potential threat.

The Agent's reasoning chain

Here's what's remarkable: given the Attack Discovery context, the agent automatically decided which tools to call and in what order. No human scripted these steps.

Step 1: VirusTotal Lookup: vt.hash.lookup

The agent's first move: verify the malware hash.

Step 2: Generate ES|QL Query: platform.core.generate_esql

With malware confirmed, the agent searched for all related activity.

Step 3: Product Documentation: platform.core.product_documentation

The agent referenced Elastic Security docs to generate remediation commands for the Response Console.!

Reasoning steps showing which tools were called in sequence for transparency

Shows the additional reasoning chain: referencing product documentation, then checking the on-call schedule information before creating a case with all relevant information and notifying the analyst on call over Slack.

Step 4: Check current time: get.time

Step 5: Check On-Call Schedule: check.on.call.schedule

The agent ran an ES|QL query against the on-call-schedule index to find the current responder:

Step 6: Create Case: create.case

Step 7: Create Slack Channel: create.channel

Why this matters

The agent wasn't following a script. It reasoned about the situation and decided:

First, verify the malware is real (VirusTotal)
Then, understand the impact (ES|QL log search)
Then, figure out how to remediate (product documentation)
Then, find the right person to respond (on-call schedule)
Then, create tracking artifacts (case)
Finally, coordinate the team (Slack channel)

This is the difference between a workflow (which follows a fixed sequence) and an agent (which reasons about what to do next). The workflow triggered the agent; the agent figured out the rest.

Step 3: Automated incident response

With high-confidence confirmation, the workflow automatically:

1. Creates an incident Case

A structured case is created with all relevant evidence attached:

Attack Discovery findings
VirusTotal analysis results
Threat intelligence matches
Agent Builder analysis
Recommended response actions

2. Notifies the SOC

A Slack message is sent to the right channel informing analysts of the critical incident.

3. Enables Response Actions

The workflow can optionally trigger automated response actions:

Host Isolation: Isolate srv-win-defend-01 via Elastic Defend
User Suspension: Disable james_spiteri in Active Directory
Network Block: Push C2 domain to firewall blocklist
IOC Sweep: Launch fleet-wide scan for Chrysalis indicators

Time-to-confirmation: Before and after

The other path: Just ask the Agent

Everything above describes the automated pipeline - Attack Discovery finds the threat, the workflow fires, the agent triages it, and the right analyst(s) gets notified.

But there's another equally powerful way to use this: go directly to Agent Builder and ask it in plain English.

Scenario: You read about the threat first

Imagine you're scrolling through your threat intel feeds and see Rapid7's blog post about the Chrysalis backdoor. You just want to know: are we compromised?

That's it. The same agent with the same tools does the rest:

Reads the threat report using the web.search tool to pull IOCs and TTPs from the Rapid7 blog
Generates ES|QL queries to hunt for Chrysalis indicators across your file, network, and process event logs
Checks VirusTotal for any matching file hashes found in your environment
Produces a CISO-ready summary with findings, confidence level, and recommended actions

The agent calls the same tools it would in the automated pipeline. The difference is the entry point: instead of a scheduled Attack Discovery triggering a workflow, you triggered the agent with a question.

Why this changes the game for analysts

This is the part that's easy to overlook but profoundly important: the analyst didn't need to know a single query language, index pattern, or tool name.

They didn't write ES|QL. They didn’t need to remember where their different data lives. They didn't need to remember the VirusTotal API syntax or figure out which threat intel index to query.

They asked a question in natural language. The agent figured out the rest including which indices to search, which queries to write, which tools to call, and how to synthesize the results.

For a junior analyst who joined the team last month, this is transformative. For a senior analyst who's been doing this for a decade, it's hours of their life back. For a CISO who wants a status update, it's a question away.

The barrier to effective threat hunting just dropped from "knows ES|QL and 47 index patterns" to "can describe what they're looking for."

Key takeaways

Attack Discovery on a schedule means you don't miss attacks - it continuously analyzes your alerts, so coordinated threats get surfaced even when no one is watching the queue.
Workflows orchestrate the response, triggering on discoveries, invoking agents, executing actions.
Agent Builder lets you build or extend agents for your needs - whether you start from scratch or add custom tools to an existing agent, you shape the capabilities to match your environment.
Agents reason, workflows execute - the agent autonomously decided to call VirusTotal, search logs, check the on-call schedule, and create a Slack channel. No human scripted that sequence.
Two entry points, same power - the automated pipeline and the chat interface use the same agent and the same tools. Whether a scheduled discovery triggers it or an analyst asks a question, the outcome is the same.
Natural language is the new query language - analysts don't need to know ES|QL, index patterns, or API syntax. They describe what they're looking for, and the agent handles the rest.

The Chrysalis backdoor campaign demonstrates why this matters. When nation-state actors can compromise your supply chain and establish persistence in 4 seconds, you need defenses that can match that speed - whether that's an automated pipeline running while you sleep, or a direct conversation with an agent when you're the first to spot the threat.

Operation Bleeding Bear

Daniel Stepanic,James Spiteri,Joe Desimone,Mark Mager,Andrew Pease — Tue, 06 Dec 2022 00:00:00 GMT

Key Takeaways

Elastic Security provides new analysis and insights into targeted campaign against Ukraine organizations with destructive malware reported over the weekend of Jan 15, 2022
Techniques observed include process hollowing, tampering with Windows Defender, using a Master Boot Record (MBR) wiper, and file corruptor component
Elastic Security prevents each stage of the described campaign using prebuilt endpoint protection features

Overview

Over this past weekend (1/15/2022), Microsoft released details of a new campaign targeting Ukrainian government entities and organizations with destructive malware. In a multi-staged attack, one malware component known as WhisperGate utilizes a wiping capability on the Master Boot Record (MBR), making any machine impacted inoperable after boot-up.

Within another stage, a file infector component is used to corrupt files in specific directories with specific file extensions. The elements used in this campaign lack the common characteristics of a ransomware compromise – in this case the adversary uses the same Bitcoin address for each victim and offers no sign of intent to decrypt the victim’s machine.

The Ukrainian National Cyber Security Coordination Center has been referring to this threat activity on its official Twitter and Facebook accounts as Operation Bleeding Bear.

Elastic users are fully protected from attacks like these through our advanced malware detection and Ransomware Protection capabilities in the platform. The Elastic Security team continues to monitor these events. This case highlights the importance of prevention when it’s up against ransomware and malware with destructive capabilities.

Stage 1: WhisperGate MBR payload

The Master Boot Record (MBR) is software that executes stored start-up information and, most importantly, informs the system of the location of the bootable partition on disk that contains the user’s operating system. If tampered with, this can result in the system being inoperable – a common tactic for malware and ransomware campaigns over the years to interrupt operation of the infected system.

The stage 1 binary is named stage1.exe and has low complexity. A 8192 byte buffer containing the new MBR data that includes the ransom note is allocated on the stack. A file handle is retrieved from CreateFileW pointing to the first physical drive which represents the MBR. That file handle is then called by WriteFile which takes only 512 bytes from the buffer writing over the Master Boot Record.

Malware analysis breakdown (Stages 1-4)

The host is subsequently rendered inoperable during the next boot-up sequence. Below is a screenshot showing the ransom note from an affected virtual machine.

Contained within the ransom note are instructions soliciting payment to a bitcoin wallet address of 1AVNM68gj6PGPFcJuftKATa4WLnzg8fpfv. The wallet does not appear to have received funds from victims as of the publication of this post.

Stage 2/3: Discord downloader and injector

Once the payload has gained a foothold, further destructive capabilities are facilitated by the stage 2 binary, called stage2.exe. This binary pulls down and launches a payload hosted via the Discord content delivery network, a recently reported approach which is increasingly being used by malicious actors.

The obfuscated .NET payload (described as Stage 3 below) is then executed in memory, setting off a number of events including:

Writing and executing a VBS script that uses PowerShell to add a Windows Defender exclusion on the root directory (C:)

Writing and executing a VBS script

"C:\Windows\System32\WScript.exe""C:\Users\jim\AppData\Local\Temp\Nmddfrqqrbyjeygggda.vbs"

Uses PowerShell to add a Windows Defender exclusion

powershell.exe Set-MpPreference -ExclusionPath 'C:\'

AdvancedRun, a program used to run Windows applications with different settings, is then dropped to disk and executed in order to launch the Service Control Manager and stop the Windows Defender service (WinDefend).

AdvancedRun is used to stop Windows Defender

"C:\Users\jim\AppData\Local\Temp\AdvancedRun.exe" /EXEFilename "C:\Windows\System32\sc.exe" `
  /WindowState 0 /CommandLine "stop WinDefend"  /StartDirectory "" /RunAs 8 /Run

AdvancedRun is used again when launching PowerShell to recursively delete the Windows Defender directory and its files.

AdvancedRun deleting the Windows Defender directory

"C:\Users\jim\AppData\Local\Temp\AdvancedRun.exe" `
  /EXEFilename "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" /WindowState 0 `
  /CommandLine "rmdir 'C:\ProgramData\Microsoft\Windows Defender' -Recurse" `
  /StartDirectory "" /RunAs 8 /Run

Copies InstallUtil.exe is a command-line utility that allows users to install and uninstall server resources from the local machine into the user’s %TEMP% directory. This action leverages the file for process hollowing by launching it in a suspended state.

It then proceeds to allocate memory (VirtualAllocEx , write the file corruptor payload (described as the Final Stage below) into memory (WriteProcessMemory), modify the thread entry point (SetThreadContext) to point to the file corruptor entry point, and start execution of the file corruptor (ResumeThread).

Final stage: File corruptor

The final file corruptor payload is loaded in memory via process hollowing to the InstallUtil process. The file corruptor:

Targets any local hard drives, attached USB drives, or mounted network shares
Scans directories for files matching internal hard-coded extension list (excluding the Windows folder)

.3DM .3DS .602 .7Z .ACCDB .AI .ARC .ASC .ASM .ASP .ASPX .BACKUP .BAK .BAT .BMP .BRD
.BZ .BZ2 .C .CGM .CLASS .CMD .CONFIG .CPP .CRT .CS .CSR .CSV .DB .DBF .DCH .DER .DIF
.DIP .DJVU.SH .DOC .DOCB .DOCM .DOCX .DOT .DOTM .DOTX .DWG .EDB .EML .FRM .GIF .GO
.GZ .H .HDD .HTM .HTML .HWP .IBD .INC .INI .ISO .JAR .JAVA .JPEG .JPG .JS .JSP .KDBX
.KEY .LAY .LAY6 .LDF .LOG .MAX .MDB .MDF .MML .MSG .MYD .MYI .NEF .NVRAM .ODB .ODG .ODP
.ODS .ODT .OGG .ONETOC2 .OST .OTG .OTP .OTS .OTT .P12 .PAQ .PAS .PDF .PEM .PFX .PHP .PHP3
.PHP4 .PHP5 .PHP6 .PHP7 .PHPS .PHTML .PL .PNG .POT .POTM .POTX .PPAM .PPK .PPS .PPSM .PPSX
.PPT .PPTM .PPTX .PS1 .PSD .PST .PY .RAR .RAW .RB .RTF .SAV .SCH .SHTML .SLDM .SLDX .SLK
.SLN .SNT .SQ3 .SQL .SQLITE3 .SQLITEDB .STC .STD .STI .STW .SUO .SVG .SXC .SXD .SXI .SXM
.SXW .TAR .TBK .TGZ .TIF .TIFF .TXT .UOP .UOT .VB .VBS .VCD .VDI .VHD .VMDK .VMEM .VMSD
.VMSN .VMSS .VMTM .VMTX .VMX .VMXF .VSD .VSDX .VSWP .WAR .WB2 .WK1 .WKS .XHTML .XLC .XLM
.XLS .XLSB .XLSM .XLSX .XLT .XLTM .XLTX .XLW .YML .ZIP

Overwrites the start of each targeted file with 1MB of static data (byte 0xCC), regardless of file size
Renames each targeted file to a randomized extension
Deletes self with the command:

Overwriting, renaming, and deleting files

cmd.exe /min /C ping 111.111.111.111 -n 5 -w 10 > Nul & Del /f /q

MBR protection with Elastic Security

Changes to the MBR are particularly strong signals of anomalous and destructive activity typically associated with ransomware. To counteract this, Elastic security researchers built an MBR protection component based around these signals into our multi-layered ransomware protection feature.

When a process attempts to overwrite the contents of the MBR, the prewrite buffer and other associated process metadata will be analyzed inline before any changes are written to disk. If the activity is deemed malicious in nature, the process will either be terminated immediately (prevention mode) and / or an appropriate ransomware alert will be generated (prevention and detection modes) to allow security operators time to respond.

When configured in prevention mode, Elastic Security’s ransomware protection ensures that the integrity of the MBR is fully preserved, with no changes ever reaching disk thanks to the synchronous framework leveraged by the feature — effectively preventing the ransomware attack in their tracks as the offending process is terminated.

When WriteFile is invoked on PhysicalDrive0 on a host running Elastic Security with ransomware protection enabled, the pending change will immediately be analyzed and deemed malicious. Afterwards, the process will be terminated, the endpoint user will be alerted via a popup notification, and a ransomware prevention alert will be sent to and stored in Elasticsearch. The intended ransom note can be easily deciphered after Base64 decoding the contents of the prewrite buffer found in the alert within Kibana.

It is important to note that while this behaviour is detected by Elastic, it is not specific to this payload and rather the behaviour the payload is exhibiting. This increases our chance of being able to detect and prevent malicious behaviors, even when a static signature of the malware is not known. Threat actors find this kind of control more difficult to evade than traditional, signature-based detection and prevention approaches.

Observing WhisperGate in Elastic Security

By observing the process hash of the stage 1 dropper above (a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92) via the process.hash function within Elastic Security, we can isolate the ransomware alert and analyze the blocked attempt at overwriting the MBR.

As we can see, the data is stored as a Base64 encoded string in Elasticsearch. Decoded, we can see the contents of the ransom note that would be displayed to the end user of an affected system.

Alert breakdown and defensive recommendations

The following alerts were triggered in Elastic Security during our investigations:

Endpoint Security Integration Alerts

Stage 1 - MBR Wiper

(a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92)

Malware Prevention Alert
Ransomware Prevention Alert (MBR overwrite)

Stage 2 - Downloader

(dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78)

Malware Prevention Alert

Stage 3 + Stage 4 - Injector/File Corruptor

(34CA75A8C190F20B8A7596AFEB255F2228CB2467BD210B2637965B61AC7EA907)

Ransomware Prevention Alert (canary files)
Malicious Behaviour Prevention Alert - Binary Masquerading via Untrusted Path
Memory Threat Prevention Alert

Prebuilt Detection Engine Alerts

The following existing public detection rules can also be used to detect some of the employed techniques:

Hunting queries

Detect attempt to tamper with Windows defender settings via NirSoft AdvancedRun executed by the Stage 3 injector:

Detect attempts to tamper with Windows Defender

process where event.type == "start" and
process.pe.original_file_name == "AdvancedRun.exe" and
process.command_line :
   ("*rmdir*Windows Defender*Recurse*",
    "*stop WinDefend*")

Masquerade as InstallUtil via code injection:

Identifies code injection with InstallUtil

process where event.type == "start" and
process.pe.original_file_name == "InstallUtil.exe" and
not process.executable : "?:\\Windows\\Microsoft.NET\\*"

MITRE ATT&CK

Summary

These targeted attacks on Ukraine using destructive malware match a similar pattern observed in the past such as NotPetya. By leveraging different malware components to wipe machines and corrupt files, it’s apparent there was no intent to recover any funds, but likely a technique used to sow chaos and doubt into Ukraine’s stability.

As these events are still ongoing, we wanted to release some initial analysis and observations from our perspective. We also wanted to highlight the prevention capabilities of Elastic Security across each stage of this attack, available to everyone today.

Existing Elastic Security users can access these capabilities within the product. If you’re new to Elastic Security, take a look at our Quick Start guides (bite-sized training videos to get you started quickly) or our free fundamentals training courses. You can always get started with a free 14-day trial of Elastic Cloud.

Indicators

| Indicator | Type | Note | | ---------------------------------------------------------------- | ------ | ---------------------------- | | a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92 | SHA256 | Stage1.exe (MBR wiper) | | dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78 | SHA256 | Stage2.exe (Downloader) | | 923eb77b3c9e11d6c56052318c119c1a22d11ab71675e6b95d05eeb73d1accd6 | SHA256 | Stage3 (Injector - original) | | 9ef7dbd3da51332a78eff19146d21c82957821e464e8133e9594a07d716d892d | SHA256 | Stage3 (Injector - fixed) | | 34CA75A8C190F20B8A7596AFEB255F2228CB2467BD210B2637965B61AC7EA907 | SHA256 | Stage4 (File Corruptor) |

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.