In November 2015, we released our first in-house macOS sandbox, Box of Apples, followed by an update in March 2018 that introduced HTML behavior reports, desktop screenshots, and process trees. Over the past decade, the macOS ecosystem and the threat landscape targeting it have changed dramatically. Apple transitioned its hardware architecture from Intel (x86_64) to Apple Silicon (ARM64), hardened its operating system security model, and deprecated legacy dynamic tracing mechanisms. At the same time, macOS threat actors have shifted toward native ARM64 binaries, multi-stage social engineering installers, credential-harvesting AppleScripts, and evasive infostealers.

Today, we are excited to introduce macOS Mirage, our brand-new, ground-up dynamic analysis sandbox built natively for Apple Silicon and macOS 26. macOS Mirage replaces Box of Apples as part of the VirusTotal Multi-Sandbox project, delivering high-fidelity behavioral telemetry, automated Sigma behavioral detections mapped to MITRE ATT&CK, and—exclusively within our Private Scanning product offering—full Interactive Live Analysis.

Why We Built macOS Mirage: Beyond Box of Apples

Box of Apples was designed for an era of Intel-based Macs and relied on dtrace scripts to monitor system calls. As macOS evolved, two structural shifts required a completely new approach:

1. Native Apple Silicon (ARM64) Execution: Modern macOS applications and malware families are compiled natively for Apple Silicon or distributed as Universal Mach-O binaries. Running modern samples on legacy Intel hardware either fails outright or misses architecture-specific execution paths. macOS Mirage runs natively on bare-metal Apple Silicon hardware with Apple's native virtualization stack and macOS 26, ensuring authentic execution fidelity.
2. Modern Kernel-Backed Behavioral Telemetry: In modern macOS releases, System Integrity Protection (SIP) restricts legacy dtrace hooks, and high syscall volumes could cause event drops. macOS Mirage uses modern, kernel-supported macOS security instrumentation to capture process creation, command-line arguments, file system modifications, persistence installation, and access to sensitive credential stores without losing events.

Rich GUI Execution and Persistence Tracking

Many macOS samples package their payloads inside disk images (.dmg) or application bundles (.app) that initialize graphical windows, register background services, or trigger system notifications during execution. macOS Mirage provides full graphics acceleration and desktop monitoring, capturing both visual screenshots and underlying system modifications in real time.

Figure 1: Dynamic detonation of a macOS application in macOS Mirage, capturing both the application GUI and a macOS system notification alerting to a newly registered persistent background Login Item.

Figure 2: Full window management, 3D rendering, and Dock process tracking inside macOS Mirage.

In addition to capturing screenshots to show what a user would see on screen, macOS Mirage automatically monitors security-sensitive locations across the operating system, including:

• Persistence Mechanisms: LaunchAgents, LaunchDaemons, Login Items, and cron jobs.
• Shell & Environment Profiles: Modifications to .zshrc, .bashrc, .zshenv, and /etc/profile.
• Credential & Privacy Stores: Unauthorized access to Keychain databases (login.keychain-db), browser cookie and credential stores, SSH keys, and the Transparency, Consent, and Control (TCC.db) database.
• System & Network Configuration: Changes to /etc/hosts, /etc/resolv.conf, and /private/etc/sudoers.

New Behavioral Detections with Sigma Rules: Catching a macOS Info-Stealer in Action

To help analysts quickly identify malicious behavior without sifting through thousands of raw file and process events, macOS Mirage evaluates runtime telemetry against a curated library of macOS Sigma rules and maps every detection directly to MITRE ATT&CK techniques.

Let's look at a real-world example of a macOS info-stealer and credential-phishing sample analyzed by macOS Mirage on VirusTotal: be77bca22f078d57058535ddcf26a39a752a8df030392cb45ba6a60e06651878

When executed inside macOS Mirage, the binary (unix51436504) performs a multi-stage credential theft and persistence chain:

1. AppleScript Password Phishing: The malware invokes /usr/bin/osascript to display a deceptive system prompt titled "Password Request" asking the user: "Please enter device password to continue."
2. Local Credential Validation & LaunchDaemon Persistence: It validates the harvested password against local Directory Services (dscl . authonly) and invokes sudo -S to copy /tmp/daemonplist to /Library/LaunchDaemons/com.somedaemon.plist.
3. Keychain, Browser & Notes Harvesting: The sample opens the user's Keychain (/Users/admin/Library/Keychains/login.keychain-db), Safari cookies (Cookies.binarycookies), Apple Notes database (NoteStore.sqlite), SSH keys (authorized_keys, known_hosts), and .zsh_history, staging the stolen files under /tmp/lksopo while continuously polling the clipboard via pbpaste.
4. Secondary Payload Download, Exfiltration & Cleanup: Using ditto, the malware compresses the staging directory into /tmp/lksopo.zip, exfiltrates the archive via an HTTP POST request (curl -X POST), downloads a secondary bot payload (curl -o /tmp/binaryexe), and deletes the staging directory (rm -rf /tmp/lksopo) to cover its tracks.

Figure 3: macOS Mirage screenshot capturing the deceptive AppleScript "Password Request" phishing dialog displayed by sample be77bca22f078d57058535ddcf26a39a752a8df030392cb45ba6a60e06651878.

From this single detonation, macOS Mirage automatically generates a high-confidence malicious verdict (macos_osascript_credential_phishing) and triggers 7 distinct Sigma rules spanning the entire attack lifecycle:

Hunting Related Threats with VirusTotal Intelligence Pivots

At the time of analysis, sample be77bca22f078d57058535ddcf26a39a752a8df030392cb45ba6a60e06651878 was detected by only 6 out of 76 static antivirus engines. Moreover, during execution inside macOS Mirage, the first-stage dropper downloaded and executed a 12.9 MB universal Mach-O second-stage bot (f7dcdc4167ec267aef007f9d5f98e9e0314185e5355effd3e304b6fa686ea84c) alongside a LaunchDaemon persistence property list (d7dd630f67e03d2945185838dca887211ea3693c91fc0bd0d2e257948bb3b678, 0/75 AV detections). When that second-stage binary is detonated in isolation, it exits in under a second because it depends on hidden state files (~/.bhost, ~/.phost, ~/.username, ~/.pwd) written to disk by the first-stage dropper. Because macOS Mirage tracks the full multi-stage process tree on macOS 26, analysts can pivot directly on runtime command lines, dropped artifacts, network URI patterns, and Sigma detections across VirusTotal Intelligence to uncover entire clusters of active macOS campaigns. For a complete reference of supported file and behavior query syntax, see the VirusTotal Search Modifiers Full List.

1. Process & Command-Line Pivots (behaviour_processes)

• Custom Exfiltration curl Headers: Hunts samples exfiltrating staged archives with custom buildid: and username: HTTP headers across rotating C2 servers: behaviour_processes:"curl -X POST -H buildid:"
• AppleScript Phishing Dialog Variable: Pinpoints samples spawning osascript with the passwen password dialog variable: behaviour_processes:"set passwen to display dialog"
• Second-Stage Bot Payload Delivery: Matches command lines downloading the persistent implant from /web/bot: behaviour_processes:"/web/bot"
• Staging Archive Compression via ditto: Identifies Mach-O stealers compressing harvested credentials in /tmp/ using Apple's ditto utility: behaviour_processes:"ditto -c -k --sequesterRsrc /tmp/" type:macho

2. Dropped File & Hidden State File Pivots (behaviour_files)

• Hidden Bot C2 Configuration in $HOME: Finds samples writing hidden bot configuration files (~/.bhost, ~/.phost, ~/.botid) into the user's home directory: behaviour_files:".bhost"
• Hidden Second-Stage Bot Executable: Matches samples dropping the persistent second-stage payload to $HOME/.binaryexe: behaviour_files:".binaryexe"
• LaunchDaemon Persistence Plist: Uncovers samples installing system-wide persistence at /Library/LaunchDaemons/com.somedaemon.plist: behaviour_files:"/Library/LaunchDaemons/com.somedaemon.plist"

3. C2 & Network Pivots (behaviour_network)

• Infrastructure-Agnostic Bot Check-In URI: Matches the /api/v1/bot/joinsystem// check-in endpoint across all C2 IP addresses: behaviour_network:"/api/v1/bot/joinsystem"
• Exfiltration Collector Server: Pivots on samples posting stolen Keychain, Safari cookie, and Notes archives to 109.238.87.111: behaviour_network:109.238.87.111
• Second-Stage Bot C2 Server: Pivots on samples retrieving /web/bot and polling /api/v1/bot/actions/ on 193.178.159.129: behaviour_network:193.178.159.129

4. macOS Mirage Verdict, Sigma & MITRE ATT&CK Pivots

• macOS Mirage Credential Phishing Verdict: Surfaces Mach-O stealers convicted by macOS Mirage's macos_osascript_credential_phishing detection across distinct malware builders (commandbuild-* and macos-stealer-v2-*): sandbox_name:"VirusTotal MacOS Mirage" behaviour:"macos_osascript_credential_phishing"
• macOS Mirage PASSWORD_DIALOG Behavioral Tag: Finds Mach-O binaries displaying deceptive credential prompts during macOS Mirage execution: sandbox_name:"VirusTotal MacOS Mirage" behaviour_tags:PASSWORD_DIALOG type:macho p:5+
• Sigma Suspicious /tmp/ Execution in macOS Mirage: Hunts samples matching Sigma rule b8017658b8eef8b1293176d76212e600b660d0a36a4f5dc80141324fae360bbf (Potentially Suspicious Execution From Tmp Folder): sandbox_name:"VirusTotal MacOS Mirage" sigma_rule:b8017658b8eef8b1293176d76212e600b660d0a36a4f5dc80141324fae360bbf p:5+
• MITRE ATT&CK Keychain Credential Access (T1555.001): Identifies Mach-O samples flagged by macOS Mirage for targeting macOS Keychain credentials: sandbox_name:"VirusTotal MacOS Mirage" attack_technique:T1555.001 type:macho p:5+

Interactive Live Analysis (Exclusive to Private Scanning)

While automated dynamic analysis and Sigma behavioral detections are available on VirusTotal reports, sophisticated macOS threats often require human interaction to detonate completely. Malware may hide behind multi-step custom installer wizards, require a password to unlock a disk image, or pause execution until realistic user input is provided—just like the "Password Request" dialog shown above.

To empower incident responders and malware analysts, Interactive Live Analysis with macOS Mirage is available exclusively as part of our Private Scanning product offering in Google Threat Intelligence and VirusTotal Enterprise:

• Real-Time Mouse & Keyboard Control: Analysts can step directly into the running macOS 26 desktop inside their web browser to click buttons, navigate prompts, open Terminal, or manually interact with suspicious applications.
• Host-to-Guest Clipboard ("Send as Keystrokes"): Analysts can paste passwords, decryption keys, URLs, or terminal commands from their local workstation directly into the sandbox VM as simulated keystrokes.
• Extended Session Timeouts & Network Control: Interactive sessions can run for extended durations (up to 30 minutes) and can be configured with custom network routing modes—including full isolation, simulated internet services, HTTPS MITM inspection, or Tor routing.
• Complete Tenant Privacy: All files, interactive sessions, screenshots, and behavioral reports generated in Private Scanning remain strictly isolated within your organization's private environment and are never shared publicly.

Figure 4: Selecting macOS Mirage and enabling Live Interaction inside the Private Scanning configuration modal.

Figure 5: Using the "Send as keystrokes" clipboard bridge during a live interactive macOS Mirage session in Private Scanning.

Try It Out and Share Your Feedback

macOS Mirage is part of our ongoing commitment to expanding multi-platform dynamic analysis across VirusTotal and Google Threat Intelligence. To view the new behavioral reports on public samples, navigate to the Behavior tab on any macOS file report in VirusTotal to inspect process trees, file system changes, network activity, screenshots, and Sigma rule matches. Enterprise customers using Private Scanning can select MacOS Mirage directly from the scan configuration dialog to launch automated or live interactive sessions.

If you find any issues or have feature requests, please don't hesitate to contact us.

Happy hunting!

Every detection team knows this moment. A rule is written or downloaded, reviewed, translated into the query language of the SIEM, and deployed. The status says enabled, the rule count goes up, and the coverage report gets a little greener.

None of that tells you whether the rule will detect the attack it was written for. A rule can be well written and still find nothing, because its logic, its data, or its translation quietly disagrees with reality. And since a rule that never fires looks the same as a rule with nothing to catch, the problem can stay hidden for a long time.

This article explains what separates a working rule from a broken one, where rules usually go wrong, and what you can do with SOC Prime to prove that a rule works before it ships and keep it working afterward.

Contact Sales

What “working” actually means

A working detection rule does three things. It expresses the right logic for the behavior it targets. It runs on data that actually contains that behavior. And it is written correctly for the platform it runs on. If any one of these fails, the rule is broken, even though it is enabled and throws no errors.

This framing helps because each failure has a different cause and a different fix:

• Logic problems live in the rule itself. It is too narrow to catch variations of the behavior, or so broad that it matches normal activity.
• Data problems live in the environment. The events the rule needs are not logged, not collected, or missing the fields the rule relies on.
• Translation problems live in the move between languages. The meaning of the rule changes when it is converted into a platform’s query syntax.

Most teams check the first one carefully when they write a rule. The second and third are where rules tend to break without anyone noticing.

Where working rules go wrong

Logic that doesn’t match the behavior. A rule keyed only on a tool’s file name is easy to evade by renaming the file. A rule keyed on a common command-line pattern, with no filtering, can match administrators all day. Neither mistake is visible at deployment. The first shows up when an attacker walks past it, the second as alert noise.

Data that isn’t there. A process creation rule that depends on command-line arguments is useless if command-line logging isn’t enabled, because the event arrives without the field. The same goes for a log source that was never onboarded, or an agent that stopped sending. The rule runs on schedule, finds nothing, and looks healthy.

Fields that mean different things in different places. The same concept can have different names across products, and even data models from different vendors are separate contracts. Splunk CIM and Microsoft Sentinel ASIM are a good example: a field that exists in one may not exist in the other. A character-by-character port produces a rule that references fields the destination never populates.

Translation that changes meaning. Automated translators handle straightforward selection logic well, but correlation rules and proprietary functions usually need human review. Platforms also differ in how they treat details like case sensitivity, wildcards, and regular expressions. A rule can be translated “successfully” and still behave differently from the original.

Platform limits that retire good rules. SIEMs cap how many rules can run. Teams routinely disable working rules to make room for new ones, so coverage shrinks without anyone deciding it should.

Why it matters

Every one of these problems leaves the rule count and the dashboard unchanged. Coverage figures that count deployed rules therefore overstate protection, and the gap usually surfaces during an incident, when someone discovers that the rule that should have fired never could.

There is a second cost: a quiet rule is ambiguous. If nothing fires, is the environment clean, is the telemetry missing, or is the logic wrong? Working that out after the fact means checking logic, data, and translation one after another. It is far cheaper to gather evidence early and keep it current.

How SOC Prime helps you prove a rule works

Detection validation is really a chain of questions: what does this rule need, does my environment provide it, does the rule behave as expected on my data, and if not, what should change? SOC Prime supports each step.

Understand detection requirements

Validation starts before any testing. SOC Prime provides contextual information around detection content, including its intended behavior, telemetry requirements, MITRE ATT&CK mapping, potential false positives, and other metadata. This gives detection engineers a starting point for deciding whether a detection is applicable to their environment and what prerequisites need to be in place before it is tested. A rule that needs command-line logging, for example, tells you so up front, instead of leaving you to find out later.

Assess available telemetry

Once you know what a rule needs, the next question is whether you have it. Prime Hunt can help teams assess the relationship between their available data and potential detection coverage. Data Audit analyzes available log data and maps it to MITRE ATT&CK to identify potential visibility gaps. This helps you determine whether a lack of detection coverage comes from missing telemetry rather than missing detection content, which are two very different problems with two very different fixes.

Test detections against organizational data

Prime Hunt can also run detection scans against data from connected environments. Testing detections against actual data gives you evidence of how the content behaves in your environment, rather than relying only on theoretical validation. Scan results help identify detections that produce relevant matches, and highlight those that need further investigation or tuning.

Investigate and improve detection logic

When a detection needs modification, SOC Prime provides detection engineering capabilities through Prime Core and Prime Architect. Detection content can be reviewed, customized, translated, and optimized for the target environment. This addresses differences in schemas, field mappings, query languages, and environment-specific requirements without treating every problematic detection as a brand-new development task.

In practice, that means:

• Translate for the platform you run. All Sigma rules on the platform are already translated into all supported SIEM languages and formats, so you can pick up the query for your stack and deploy it right away. For anything custom, or for your own Sigma rules, use the Translation workspace in Prime Architect to convert them into the native query language of your SIEM, EDR, XDR, or data lake. Sigma stays the source, so a change made once can be translated again instead of edited by hand in each platform.
• Map tables, fields, and values to your schema. Custom Field Mapping lets you define profiles that map your non-standard tables, fields, and values to the defaults. Create a profile once, then apply it each time you deploy a rule or send a query.
• Add filters that fit your environment. Filters add conditions to the detection logic before deployment to include or exclude specific users, hosts, or other sets of items. They keep known-benign activity from turning a good rule into a noisy one, without rewriting the rule itself.
• Save deployment settings as presets. Presets store parameters such as query period, severity, and rule status, so deployments stay consistent.
• Validate, optimize, and fine-tune. The Translation workspace also validates and optimizes detection content. It doesn’t replace review: check every field against the destination schema, and look closely at anything flagged, especially correlation logic and platform-specific functions. When a change goes beyond mapping and filters, edit the code directly, translate it again, and save it to your custom repository as an update or a new rule.
• Research and adjust with the AI-assisted workspace. Use it to research the behavior a rule targets and work through changes to its logic. Engineers stay in control and review every change before it ships.

Identify coverage gaps

Detection validation should also answer what is not being detected. Data Audit in Prime Hunt provides coverage analysis based on both available telemetry and detection content. This helps teams distinguish between gaps caused by insufficient visibility and gaps caused by missing or unsuitable detection rules. That distinction informs the next engineering action: collect more data, tune an existing detection, or identify and develop additional detection content.

Continue validating over time

Detection effectiveness changes as environments and detection content evolve. Recurring validation with Prime Hunt lets teams reassess detections against current data rather than relying on an initial validation result indefinitely. This matters most in environments where logging configurations, data schemas, infrastructure, or detection content change frequently.

Evidence over assumption

A deployed rule is a claim. A rule that has been tested against real data is evidence. The difference is easy to overlook, because both look the same in a rule list and both stay quiet until an attack arrives.

SOC Prime helps teams close that gap. It starts with clear detection requirements and an honest look at available telemetry, tests detections against your own data, and gives you the tools to fix what doesn’t fit. Coverage analysis then shows whether the remaining gaps call for more data, better tuning, or new content, and recurring validation keeps the answer current as your environment changes. Start with the rules that matter most, and find out which ones would really fire.

The post A Deployed Rule Is Not a Working Rule: How to Tell the Difference appeared first on SOC Prime.

MITRE ATT&CK detection coverage is the ratio of adversary techniques your SOC can detect, validated against the technique set your threat model prioritizes, on the current framework version.

A coverage percentage means nothing without its denominator and proof method. Validated coverage counts techniques where a deployed detection rule fires against its required data source, divided by the techniques your SOC has prioritized, on ATT&CK v19 (released 2026-04-28). Every gap between that definition and the number on your slide is where the measurement breaks down. This page gives the method, the failure modes, and the questions that separate a vendor’s library figure from the coverage you actually run.

How do I measure my organization’s MITRE ATT&CK detection coverage?

Five steps, each measured per tactic, on ATT&CK v19:

1. Inventory your deployed detection rules.

2. Map each rule to ATT&CK technique IDs it covers.

3. Confirm the required log source for each mapped technique is collected and passing its contract gates: freshness, null-rate, and field-semantics. A source that flows but fails its contract does not count.

4. Prove each rule fires against a real or simulated test event. Tools: Atomic Red Team, MITRE Caldera, AttackIQ.

5. Compute the ratio per tactic.

Step 3 is where most programs quietly lose ground: a log source can be technically ingested while its null-rate or schema drift makes the detections above it unreliable.

Step 4 matters because a rule that has never fired might never fire, whether from a logic error, a parser change, or a renamed field. Tools like ATT&CK Navigator, or a coverage-audit product like Prime Hunt, support the mapping and validation.

Count a technique that spans two tactics once per tactic, which is ATT&CK Navigator‘s default. This keeps percentages comparable across sources.

What does an ATT&CK coverage percentage actually count?

It counts techniques, not sub-techniques or procedures, and each carries different data dependencies.

T1078 (Valid Accounts) needs identity and authentication telemetry. Its cloud sub-technique T1078.004 (Cloud Accounts) adds cloud control-plane logs joined to the identity provider. A rule written against generic authentication logs alone leaves T1078.004 uncovered, so it covers only part of Valid Accounts.

A defensible program measures against its prioritized technique set, states the denominator, and calls the difference.

What’s the difference between a detection content vendor’s claimed ATT&CK coverage and the coverage actually deployed and validated in my environment?

Four independent measurements exist. They are not interchangeable, and only the last one describes what your SOC detects.

Coverage-analytics tools like CardinalOps and Prime Hunt reconcile claimed mappings against your live Splunk, Elastic, or Microsoft Sentinel environment, where the library-to-validated gap becomes visible.

Which ATT&CK techniques can I not detect because of the logs I am not collecting?

Detection depends on data. Without the required data source collected, no detection fires, regardless of how many rules you own.

Map each prioritized technique to the data components its ATT&CK detection strategy uses (ATT&CK v19.2; version 18 replaced per-technique data sources with detection strategies, analytics, and data components), then reconcile against what your environment actually collects. A technique with no collected source scores zero.

Rank missing sources by the coverage each adds, weighed against ingest volume, licensing, parser effort, retention cost, and SLO reliability.

Prime Hunt runs a data audit that maps the log sources you actually collect to ATT&CK and lists the techniques with no telemetry behind them.

Contact Sales

How do I find and close gaps in my MITRE ATT&CK detection coverage?

Close a gap by deploying a rule and proving it fires against a collected source. Adding a rule to a catalog does not close a gap.

1. Build a heatmap on ATT&CK v19 using ATT&CK Navigator.

2. Prioritize by threat model and which data sources already pass their gates.

3. Source or author the rule.

4. Validate it fires end to end using Atomic Red Team, MITRE Caldera, or AttackIQ.

5. Re-measure.

What changes when ATT&CK releases a new version?

The denominator changes. Recompute.

ATT&CK v19 (initially released April 28, 2026) split the former Defense Evasion tactic into two new tactics, Stealth and Defense Impairment. A percentage computed before that split cannot compare to one after, because the taxonomy changed, not only technique counts.

Re-map to the new structure, recompute per tactic, and publish the delta. Do not relabel the old number.

How should I report ATT&CK detection coverage to our board?

Report validated coverage, not library size. Three metrics belong in the board package:

Give the board three questions for any vendor: what is the coverage denominator, which log sources does it assume are collected, and which ATT&CK version is it computed on.

How long should it take my SOC to have a detection in production after a new attack technique goes public?

Measure time-to-coverage: from technique or procedure publication (t0) to a detection deployed and proven to fire in production (t1).

Track median and P90 by technique class, since a commodity technique and a novel procedure carry different windows. Set the target based on your own program maturity. A published vendor turnaround time describes that vendor’s pipeline, not yours; SOC Prime’s published figure is a 24-hour SLA for detection content against emerging threats.

Where this does not hold

A coverage percentage cannot demonstrate detection effectiveness when any of its inputs are unknown: whether each source passes its gates, whether each rule has fired, whether the denominator is a real threat-model set. A number that cannot confirm all three describes a catalog, not a defended environment.

Coverage measurement checklist

• Rules inventoried and mapped to ATT&CK technique IDs (v19).

• Required data source for each mapped technique collected and passing freshness, null-rate, and field-semantics gates.

• Each rule proven to fire against a real or simulated execution.

• Denominator: techniques prioritized for your threat model.

• Coverage computed per tactic, each cross-tactic technique counted once per tactic.

• Missing sources ranked by coverage added against ingest volume, licensing tier, parser effort, retention cost, and SLO reliability.

• Board report shows validated coverage per source, gaps with owners, and time-to-coverage.

• Coverage recomputed and the delta published on every ATT&CK version change.

Related reading

• Attack Chains: See the Full Story Behind Every Threat (August 2026)
• MITRE Attack Flow v3.0.0 (October 2025)
• Uncoder AI Automates MITRE ATT&CK Tagging in Sigma Rules (April 2025)

The post Measuring MITRE ATT&CK detection coverage: what the percentage counts and what it hides appeared first on SOC Prime.

Introduction

Tell me what role you have and I'll tell you how you use VirusTotal

Our approach

p:5+ have:behavior fs:30d+ not have:sigma

p:5+ (sandbox_name:"CAPE Sandbox" or sandbox_name:"Zenbox") fs:30d+ not have:sigma

p:5+ have:behavior fs:30d+ sigma_critical:0 sigma_high:0 sigma_medium:0 sigma_low:2-

Our detections for the community

Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer

title: Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer
  id: 19b3806e-46f2-4b4c-9337-e3d8653245ea
  status: experimental
  description: Detects the execution of more.com and vbc.exe in the process tree. This behaviors was observed by a set of samples related to Lummac Stealer. The Lummac payload is injected into the vbc.exe process.
  references:
      - https://www.virustotal.com/gui/file/14d886517fff2cc8955844b252c985ab59f2f95b2849002778f03a8f07eb8aef
      - https://strontic.github.io/xcyclopedia/library/more.com-EDB3046610020EE614B5B81B0439895E.html
      - https://strontic.github.io/xcyclopedia/library/vbc.exe-A731372E6F6978CE25617AE01B143351.html
  author: Joseliyo Sanchez, @Joseliyo_Jstnk
  date: 2024-11-14
  tags:
      - attack.defense-evasion
      - attack.t1055
  logsource:
      category: process_creation
      product: windows
  detection:
      # VT Query: behaviour_processes:"C:\\Windows\\SysWOW64\\more.com" behaviour_processes:"C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe"
      selection_parent:
          ParentImage|endswith: '\more.com'
      selection_child:
          - Image|endswith: '\vbc.exe'
          - OriginalFileName: 'vbc.exe'
      condition: all of selection_*
  falsepositives:
      - Unknown
  level: high

Sysmon event for: Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer

{
  "System": {
    "Provider": {
      "Guid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}",
      "Name": "Microsoft-Windows-Sysmon"
    },
    "EventID": 1,
    "Version": 5,
    "Level": 4,
    "Task": 1,
    "Opcode": 0,
    "Keywords": "0x8000000000000000",
    "TimeCreated": {
      "SystemTime": "2024-11-26T16:23:05.132539500Z"
    },
    "EventRecordID": 692861,
    "Correlation": {},
    "Execution": {
      "ProcessID": 2396,
      "ThreadID": 3116
    },
    "Channel": "Microsoft-Windows-Sysmon/Operational",
    "Computer": "DESKTOP-B0T93D6",
    "Security": {
      "UserID": "S-1-5-18"
    }
  },
  "EventData": {
    "RuleName": "-",
    "UtcTime": "2024-11-26 16:23:05.064",
    "ProcessGuid": "{C784477D-F5E9-6745-6006-000000003F00}",
    "ProcessId": 4184,
    "Image": "C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe",
    "FileVersion": "14.8.3761.0",
    "Description": "Visual Basic Command Line Compiler",
    "Product": "Microsoft® .NET Framework",
    "Company": "Microsoft Corporation",
    "OriginalFileName": "vbc.exe",
    "CommandLine": "C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe",
    "CurrentDirectory": "C:\\Users\\george\\AppData\\Roaming\\comlocal\\RUYCLAXYVMFJ\\",
    "User": "DESKTOP-B0T93D6\\george",
    "LogonGuid": "{C784477D-9D9B-66FF-6E87-050000000000}",
    "LogonId": "0x5876e",
    "TerminalSessionId": 1,
    "IntegrityLevel": "High",
    "Hashes": {
      "SHA1": "61F4D9A9EE38DBC72E840B3624520CF31A3A8653",
      "MD5": "FCCB961AE76D9E600A558D2D0225ED43",
      "SHA256": "466876F453563A272ADB5D568670ECA98D805E7ECAA5A2E18C92B6D3C947DF93",
      "IMPHASH": "1460E2E6D7F8ECA4240B7C78FA619D15"
    },
    "ParentProcessGuid": "{C784477D-F5D4-6745-5E06-000000003F00}",
    "ParentProcessId": 6572,
    "ParentImage": "C:\\Windows\\SysWOW64\\more.com",
    "ParentCommandLine": "C:\\Windows\\SysWOW64\\more.com",
    "ParentUser": "DESKTOP-B0T93D6\\george"
  }
} 

File Creation Related To RAT Clients

title: File Creation Related To RAT Clients
  id: 2f3039c8-e8fe-43a9-b5cf-dcd424a2522d
  status: experimental
  description: File .conf created related to VenomRAT, AsyncRAT and Lummac samples observed in the wild.
  references:
      - https://www.virustotal.com/gui/file/c9f9f193409217f73cc976ad078c6f8bf65d3aabcf5fad3e5a47536d47aa6761
      - https://www.virustotal.com/gui/file/e96a0c1bc5f720d7f0a53f72e5bb424163c943c24a437b1065957a79f5872675
  author: Joseliyo Sanchez, @Joseliyo_Jstnk
  date: 2024-11-15
  tags:
      - attack.execution
  logsource:
      category: file_event
      product: windows
  detection:
      # VT Query: behaviour_files:"\\AppData\\Roaming\\DataLogs\\DataLogs.conf"
      # VT Query: behaviour_files:"DataLogs.conf" or behaviour_files:"hvnc.conf" or behaviour_files:"dcrat.conf"
      selection_required:
          TargetFilename|contains: '\AppData\Roaming\'
      selection_variants:
          TargetFilename|endswith:
              - '\datalogs.conf'
              - '\hvnc.conf'
              - '\dcrat.conf'
          TargetFilename|contains:
              - '\mydata\'
              - '\datalogs\'
              - '\hvnc\'
              - '\dcrat\'
      condition: all of selection_*
  falsepositives:
      - Legitimate software creating a file with the same name
  level: high

Sysmon event for: File Creation Related To RAT Clients

{
  "System": {
    "Provider": {
      "Guid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}",
      "Name": "Microsoft-Windows-Sysmon"
    },
    "EventID": 11,
    "Version": 2,
    "Level": 4,
    "Task": 11,
    "Opcode": 0,
    "Keywords": "0x8000000000000000",
    "TimeCreated": {
      "SystemTime": "2024-12-02T00:52:23.072811600Z"
    },
    "EventRecordID": 1555690,
    "Correlation": {},
    "Execution": {
      "ProcessID": 2624,
      "ThreadID": 3112
    },
    "Channel": "Microsoft-Windows-Sysmon/Operational",
    "Computer": "DESKTOP-B0T93D6",
    "Security": {
      "UserID": "S-1-5-18"
    }
  },
  "EventData": {
    "RuleName": "-",
    "UtcTime": "2024-12-02 00:52:23.059",
    "ProcessGuid": "{C784477D-04C6-674D-5C06-000000004B00}",
    "ProcessId": 7592,
    "Image": "C:\\Users\\george\\Desktop\\ezzz.exe",
    "TargetFilename": "C:\\Users\\george\\AppData\\Roaming\\MyData\\DataLogs.conf",
    "CreationUtcTime": "2024-12-02 00:52:23.059",
    "User": "DESKTOP-B0T93D6\\george"
  }

Wrapping up

sigma_rule:a1021d4086a92fd3782417a54fa5c5141d1e75c8afc9e73dc6e71ef9e1ae2e9c

sigma_rule:8f179585d5c1249ab1ef8cec45a16d112a53f91d143aa2b0b6713602b1d19252