HollowFrame & Matryoshka — Layered Loader and Nested Backdoors

The attacker's objective was durable, deniable remote command execution inside a professional-services network, reached by walking malicious code through a chain of increasingly trusted components until the final implant ran inside a signed Microsoft process. Blackpoint Cyber's Adversary Pursuit Group documented the chain across two endpoints: a spear-phishing link, an attacker-controlled redirector, a Mega-hosted encrypted archive, a shortcut named to look like case documents, an XOR-obfuscated PowerShell downloader, a staged Python package, a fake python311.dll, the HollowFrame Go loader framework, and finally the Matryoshka Rust backdoor family in two variants.

Two properties make this pack worth running even if these exact indicators never appear in your environment. First, the actor prepared the ground before the payload arrived: PowerShell requested elevation, created %LOCALAPPDATA%\Programs\Python\Python311-Brief, then added Microsoft Defender exclusions for both that directory and the process name python.exe — all before a single executable was downloaded. Second, every executable stage ran under a name Windows expects: python.exe loading an adjacent rogue python311.dll, then a OneDrive updater.exe loading an adjacent rogue version.dll, then a Rust wtsapi32.dll proxying 41 genuine Terminal Services exports.

The highest-value defensive angle is therefore not the hashes. It is the ordering: a Defender exclusion for a user-writable directory, followed minutes later by a signed binary executing from that same directory and loading a same-directory dependency. Either event alone is common. The pair, in that order, on that path, is the intrusion. Queries Q3, Q4, Q6 and Q7 in this pack are built to be joined on host and time for exactly that reason.

The GitHub variant deserves separate attention. Matryoshka GitHub uses the GitHub Contents API against a private repository as a dead drop, with one directory per victim host holding beacon.json, cmd.json and result.json. Blocking api.github[.]com outright is not a viable control on most estates. Constraining which processes and which hosts may reach it is, and that is what the hardening section recommends.

Defender priority: hunt Defender exclusion changes first (Q3, Q4). The exclusions were added before the payloads landed, they persist after the malware is removed, and they are the one stage in this chain that leaves an obvious, durable, high-signal artifact on disk and in the registry.

Two sources were fetched and saved verbatim as snapshots alongside this pack. Every atomic indicator shipped below traces to one of them. A third intended source could not be retrieved and is recorded here rather than silently dropped.

Research notes and judgement calls

• No actor attribution exists. The primary report states it is not known who is behind the activity. The Go build path Project220Rebr is explicitly assessed by the researchers as an internal build-directory name, not a malware family or an actor handle. Do not treat it as attribution.
• Three of the eleven published hashes are legitimate host binaries — the bundled python.exe, vcruntime140.dll and the OneDrive updater.exe. They are the trusted halves of the side-load pairs, not malware. They are kept out of the block list and routed to a separate context-only block in section 10. Blocking them would break Python and OneDrive on clean hosts.
• One published hash is missing: the report records "hash not recovered" for Case Documents.lnk. That row is shipped as a labelled placeholder, never as an invented value.
• Only one search hit added anything. Every other result for this campaign was a syndicated republication of the trade-press article. Nothing independent of Blackpoint's telemetry has been published, so overall confidence rests on a single primary reporter — high on internal consistency, unconfirmed by a second sensor network.
• Infrastructure perishability. Both IP addresses and the phishing redirector are single-campaign infrastructure with a short useful life. They are shipped with a three-month expiry; the hashes and the behavioural content are the durable half of this pack.

Attack chain

Hunt hypotheses (ordered by fidelity)

1. H1 — Pre-staged Defender exclusion. A non-management process added a Defender path or process exclusion covering a user-writable directory, and executable content appeared under that path afterwards. Confidence: high. FP: medium (IT and line-of-business installers do this legitimately). Requires: ProcessRollup2, RegGenericValueUpdate.
2. H2 — Python host with nothing to interpret. python.exe executed from a user-writable path with no script path, no -m module and no interactive flag. Confidence: high. FP: low. Requires: ProcessRollup2.
3. H3 — Side-load DLL name in the wrong place. A file named python311.dll, version.dll or wtsapi32.dll was written outside a system or vendor-install directory. Confidence: high. FP: medium (genuine Python installs and application installers write these names). Requires: PeFileWritten.
4. H4 — Shortcut-driven decode chain. certutil.exe -decode ran against content in a user temp path with a script interpreter or shell in the ancestry. Confidence: high. FP: medium. Requires: ProcessRollup2.
5. H5 — Self-elevating hidden PowerShell. PowerShell relaunched itself with an elevation verb, a hidden window and an execution-policy bypass. Confidence: high. FP: low. Requires: ProcessRollup2.
6. H6 — Trusted host talking to the internet. A Python host or an application updater opened outbound connections to endpoints outside its vendor's own infrastructure. Confidence: medium. FP: high on developer and engineering estates. Requires: NetworkConnectIP4.
7. H7 — GitHub as a dead drop. The GitHub API was resolved and contacted by a process that has no development role, at a beacon-like cadence, with an application user agent that does not match the process. Confidence: medium. FP: high without a process allowlist. Requires: DnsRequest plus proxy logs.
8. H8 — Logon-triggered persistence into a user path. A scheduled task or WMI subscription was registered to run a payload stored under a user profile or temp directory at logon. Confidence: high. FP: medium. Requires: ScheduledTaskRegistered, WMI-Activity operational log.

Read the Action column before importing anything. Three of the published file hashes belong to legitimate signed binaries that the actor abused as side-load hosts. They are listed for context and retrospective search only. Setting them to prevent will break Python and OneDrive on clean endpoints.

Run these where Falcon is absent, where the sensor was installed after the intrusion window, or to recover the stages that produce no sensor event. Each stands alone and needs no CQL.

Microsoft Defender operational log

• Event ID 5007 — configuration change. Filter for values under the exclusions key. This is the single most durable artifact in the chain: the exclusions were added before the payloads landed and survive removal of the malware.
• Event ID 5001 / 5010 / 5012 — real-time, antispyware or antivirus scanning disabled.
• Enumerate current exclusions across the fleet and compare against an approved baseline. Any path under a user profile, and any process-name exclusion for an interpreter, is a finding regardless of this campaign.

PowerShell logging

• 4104 (Script Block Logging) — search for blocks containing a long unbroken hexadecimal literal together with Invoke-Expression, or containing -Verb RunAs together with -WindowStyle Hidden.
• 4104 — search for Add-MpPreference or Set-MpPreference with any exclusion parameter.
• 4103 (module logging) and transcription — recover the decoded stage body where script block logging was truncated.

Task Scheduler operational log

• 106 (task registered), 140 (task updated), 141 (task deleted). Export every logon-triggered task and review those whose action points into a user profile, temp or programdata path, or that run with highest privileges under a standard user account.
• Compare C:\Windows\System32\Tasks against a known-good baseline. Pay attention to update-themed task names, which is the naming style the reporting calls out.

WMI-Activity operational log

• 5857 (provider started), 5860 and 5861 (permanent event consumer registration). A subscription created through the WMI API produces no process-execution telemetry, so 5861 is the only reliable source.
• Enumerate __EventFilter, CommandLineEventConsumer, ActiveScriptEventConsumer and __FilterToConsumerBinding instances under the subscription namespace on every host, not just suspected ones. Look for filters keyed on logon-session object creation.

Sysmon (where deployed)

• Event 7 (Image Loaded) — the cleanest possible detection for this chain: a signed executable loading an unsigned or mismatched DLL from its own directory outside Program Files. Filter on the three side-load DLL names.
• Event 11 (File Create) — archives and PE files written into download and temp paths.
• Events 19, 20, 21 — WMI filter, consumer and binding activity.
• Event 1 — carries Signature and SignatureStatus, which the Falcon event stream does not expose as a queryable signer field.

Web proxy / secure web gateway

• Search full request URIs for the per-victim mailbox path on the dead-drop repository, and for requests to the code-hosting contents API whose response bodies are JSON task objects.
• Search for the spoofed OneDrive user agent paired with a code-hosting destination. The genuine OneDrive client never contacts the code-hosting API, so that pairing alone is a finding.
• Search for plaintext HTTP requests to bare IPv4 literals originating from endpoints — the delivery stage used no hostname at all.
• Search for downloads of password-protected archives from consumer file-sharing services, then correlate against mail-gateway click telemetry for the same user in the same minute.

Mail gateway

• Retro-hunt for the redirector host across all recipients, not just the ones who clicked, and for any message delivering a link to a consumer file-sharing service with an archive password in the message body.
• Review policy: encrypted and password-protected archives that bypass content inspection should be quarantined or detonated, not delivered.

No query below carries an in-query time filter. Set the window with the console time picker. Each query records its intended lookback as a // LOOKBACK: comment. Start at 30 days for the persistence and Defender queries, 7 days for the network ones.

// HUNT: certutil decoding a staged blob inside a user-writable path
// MITRE: T1140, T1204.002, T1059.003
// CONF: high | FP: medium | COST: low
// REQUIRES: ProcessRollup2 with command lines (Falcon Insight)
// FALSE POSITIVES: certificate tooling, log-packing scripts, some vendor installers
// TUNING: exclude ParentBaseFileName values belonging to your patch and software-deployment agents, and exclude decodes whose target sits under a managed application directory
// LOOKBACK: 30d - set the window with the console time picker
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^certutil\.exe$/i
| CommandLine=/-decode/i
| CommandLine=/\\(Temp|AppData|Downloads|Users\\Public)\\/i
| table([@timestamp, ComputerName, UserName, GrandparentBaseFileName, ParentBaseFileName, FileName, CommandLine, SHA256HashData])

// HUNT: PowerShell relaunching itself elevated, hidden and policy-bypassed
// MITRE: T1059.001, T1548
// CONF: high | FP: low | COST: low
// REQUIRES: ProcessRollup2 with command lines
// FALSE POSITIVES: a small number of self-elevating vendor install wrappers
// TUNING: if a packaging tool trips this, exclude on the parent binary rather than on the flag combination - the flags are the signal
// LOOKBACK: 30d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(powershell|powershell_ise|pwsh)\.exe$/i
| CommandLine=/-Verb\s+RunAs/i
| CommandLine=/-w(indowstyle)?\s+hidden/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, SHA256HashData])

// HUNT: Defender exclusion added for a path or a process name
// MITRE: T1562.001
// CONF: high | FP: medium | COST: low
// REQUIRES: ProcessRollup2 with command lines
// FALSE POSITIVES: IT-run exclusion scripts, endpoint-management tooling, some application installers
// TUNING: exclude your management agent as ParentBaseFileName and your build or imaging service account as UserName; never exclude on the exclusion value itself, and always triage any exclusion naming an interpreter or a user-profile path
// LOOKBACK: 30d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/(Add|Set)\-MpPreference/i
| CommandLine=/Exclusion(Path|Process|Extension|IpAddress)/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])

// HUNT: Defender exclusion key written in the registry
// MITRE: T1562.001, T1112
// CONF: high | FP: medium | COST: low
// REQUIRES: RegGenericValueUpdate / RegSystemConfigValueUpdate
// FALSE POSITIVES: endpoint-management and antivirus-migration tooling writing approved exclusions
// TUNING: exclude writes whose RegStringValue resolves under Program Files or your managed application root, then review everything that remains by hand - the population should be small enough to read
// LOOKBACK: 30d
#event_simpleName=/^(RegGenericValueUpdate|RegSystemConfigValueUpdate)$/
| RegObjectName=/\\Windows Defender\\Exclusions\\/i
| table([@timestamp, ComputerName, UserName, RegObjectName, RegValueName, RegStringValue])

// HUNT: archive imitating a Python embeddable distribution written to a user path
// MITRE: T1105, T1036.005
// CONF: medium | FP: low | COST: low
// REQUIRES: ZipFileWritten
// FALSE POSITIVES: a developer legitimately downloading an embeddable Python package
// TUNING: real Python embeddable archives end in -embed-amd64, -embed-win32 or -embed-arm64; anything else is worth reading, and any of them landing on a non-developer endpoint is worth reading too
// LOOKBACK: 30d
#event_simpleName=/^ZipFileWritten$/
| TargetFileName=/python\-3[\d.]*\-embed/i
| table([@timestamp, ComputerName, UserName, ContextBaseFileName, TargetFileName, SHA256HashData])

// HUNT: Python host executed with nothing to interpret (side-load tell)
// MITRE: T1574.002, T1036.005
// CONF: high | FP: low | COST: low
// REQUIRES: ProcessRollup2 with command lines
// FALSE POSITIVES: a user opening a bare Python REPL from a portable install under their profile
// TUNING: on developer estates, exclude ImageFileName paths under your sanctioned toolchain roots rather than dropping the path filter; keep the no-argument condition, which is what separates a side-load from a REPL that was actually typed into
// LOOKBACK: 30d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^pythonw?3?\d*\.exe$/i
| ImageFileName=/\\(AppData|Temp|ProgramData|Downloads|Users\\Public)\\/i
| CommandLine!=/\.(py|pyw|pyz)\b/i
| CommandLine!=/\s\-(m|c|i|E|X)\b/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, ImageFileName, CommandLine, SHA256HashData])

// HUNT: side-load DLL names written outside the system directories
// MITRE: T1574.002, T1036.005
// CONF: high | FP: medium | COST: medium
// REQUIRES: PeFileWritten / NewExecutableWritten
// FALSE POSITIVES: Python installers, application setup routines that bundle their own version library
// TUNING: exclude ContextBaseFileName values of msiexec.exe, TrustedInstaller.exe and your software-deployment agent, and exclude writes landing under Program Files; what should remain is DLLs written into user-writable paths by something that is not an installer
// LOOKBACK: 30d
#event_simpleName=/^(PeFileWritten|NewExecutableWritten)$/
| TargetFileName=/\\(python3\d\d|version|wtsapi32|vcruntime\d+)\.dll$/i
| TargetFileName!=/^[A-Za-z]:\\Windows\\/i
| table([@timestamp, ComputerName, UserName, ContextBaseFileName, TargetFileName, SHA256HashData])

// HUNT: known HollowFrame and Matryoshka network infrastructure
// MITRE: T1071.001, T1105
// CONF: high | FP: low | COST: low
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: none expected - these are single-campaign endpoints
// TUNING: none needed; a hit here is an incident, not a tuning exercise
// LOOKBACK: 90d - go as far back as retention allows, the report window opens well before disclosure
#event_simpleName=/^NetworkConnectIP4$/
| in(RemoteAddressIP4, values=["2.26.252.84", "45.158.196.184"])
| table([@timestamp, ComputerName, UserName, ContextBaseFileName, RemoteAddressIP4, RemotePort_decimal, Protocol_decimal])

// HUNT: trusted side-load hosts opening outbound connections
// MITRE: T1071.001, T1574.002
// CONF: medium | FP: high | COST: medium
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: package installs and API calls from developer Python, and genuine updater traffic to vendor infrastructure
// TUNING: run this scoped to non-developer host groups first; then exclude vendor destination ranges for the updater and your internal package mirror for Python, and read what is left - a single stable destination on a non-standard port from an updater process is the shape you want
// LOOKBACK: 7d
#event_simpleName=/^NetworkConnectIP4$/
| ContextBaseFileName=/^(python|pythonw|updater|loader_panda)\.exe$/i
| groupBy([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4, RemotePort_decimal], function=count(as=Connections))
| sort(Connections, order=desc, limit=200)

// HUNT: code-hosting API resolved by non-browser, non-developer processes
// MITRE: T1102.002, T1567
// CONF: medium | FP: high | COST: medium
// REQUIRES: DnsRequest
// FALSE POSITIVES: every developer tool, package manager, CI agent and IDE extension host on the estate
// TUNING: this query is unusable estate-wide - scope it to host groups with no development role first, then build the ContextBaseFileName exclusion list from what your own baseline shows, and finally pivot every survivor to proxy logs for the request URI, because the repository path and the user agent are what actually confirm it
// LOOKBACK: 7d
#event_simpleName=/^DnsRequest$/
| DomainName=/^api\.github\.com$/i
| ContextBaseFileName!=/^(chrome|msedge|firefox|brave|iexplore|code|devenv|git|git-remote-https|gh|node|npm|yarn|dotnet|java|curl|wget|OneDrive)\.exe$/i
| groupBy([aid, ComputerName, ContextBaseFileName], function=count(as=Lookups))
| sort(Lookups, order=desc, limit=200)

// HUNT: logon-triggered scheduled task pointing at a user-profile payload
// MITRE: T1053.005
// CONF: high | FP: medium | COST: low
// REQUIRES: ScheduledTaskRegistered / ScheduledTaskModified
// FALSE POSITIVES: user-scoped auto-update helpers and sync clients that install under a profile
// TUNING: exclude the specific TaskName values your known user-scoped applications register, one by one, and keep a standing review of anything new; do not exclude the whole user-profile path, which is the entire point of the query
// LOOKBACK: 30d
#event_simpleName=/^(ScheduledTaskRegistered|ScheduledTaskModified)$/
| TaskExecutable=/\\(Users|AppData|ProgramData|Temp|Downloads)\\/i
| table([@timestamp, ComputerName, UserName, TaskName, TaskAuthor, TaskExecutable])

// HUNT: command shell spawned by a side-load host with merged-output capture
// MITRE: T1059.003, T1071.001
// CONF: high | FP: low | COST: low
// REQUIRES: ProcessRollup2 with command lines
// FALSE POSITIVES: build scripts that shell out from a Python parent on developer endpoints
// TUNING: on developer estates exclude Python parents whose ImageFileName sits under a sanctioned toolchain root, and keep updater parents unexcluded - an application updater spawning a shell has no benign explanation
// LOOKBACK: 30d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(cmd|powershell|pwsh)\.exe$/i
| ParentBaseFileName=/^(python|pythonw|updater|loader_panda)\.exe$/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, SHA256HashData])

Correlation beats any single card. Run Q3 or Q4 first, take the host and the timestamp, then re-run Q5, Q6, Q7 and Q11 scoped to that host across the following two hours. The chain compresses into minutes on a live intrusion, so an exclusion followed inside the same hour by a PE write into the excluded path and a no-argument interpreter launch is a confirmed sequence, not a coincidence.

Four of the twelve queries are strong enough to promote to Custom IOAs. The rest stay as scheduled hunts because their false-positive profile depends on estate composition and cannot be tuned generically.

Stay as scheduled hunts

• Q9 and Q10 — false-positive rate is a function of how many developers you have. Promoting either to an IOA before scoping produces an unusable alert stream and trains analysts to close the whole rule.
• Q7 — legitimate installers write these DLL names often enough that a prevent action risks blocking a Python or application install. Run weekly, review by hand.
• Q8 — atomic infrastructure belongs in Falcon IOC Management, not in an IOA. Import the CSV in section 10 instead.
• Q11 — task persistence is better served by a scheduled search with a review queue, because the finding is usually "which task is this" rather than "block it now".

Deployment path

1. Create a Custom IOA Rule Group scoped to a pilot host group of 20 to 50 endpoints spanning your real mix of roles.
2. Add each rule in Detect mode with the exclusions above. Leave it for a full business cycle, including a patch window and a month-end.
3. Review every detection. Convert anything benign into a named exclusion; do not broaden the pattern.
4. Promote to Prevent only for the rules whose benign population reached zero, and only on the host groups where that was true.
5. Record the pilot outcome in the changelog and bump this pack to v1.0.

The import block below contains malicious artifacts only. The three legitimate host binaries the actor abused are in a separate context-only block and are deliberately not importable. Importing them as blocks would break Python and the OneDrive updater across the estate.

type,value,action,severity,expiration,description,tags
sha256,55ed788ca7130089c4262cda8f0cb936eab9244bea68eeebe863842ba368e270,prevent,critical,2027-02-01,HollowFrame initial phishing archive,campaign:HollowFrame
sha256,cb6b6289698f53111bb026ad5e95f841a03cf690bda670bb551e416e8cda77d3,prevent,critical,2027-02-01,HollowFrame staged payload archive,campaign:HollowFrame
sha256,b2123d476646459234ab3083b79d13690d3864f9f5a9aa2b1272dfd502d0d3e2,prevent,critical,2027-02-01,HollowFrame Go side-load DLL,campaign:HollowFrame
sha256,d3bf01fce1f97f86aa58e9220e6dc1dae90005e5d7552f06192393d370355ed9,prevent,critical,2027-02-01,HollowFrame Go loader payload,campaign:HollowFrame
sha256,f882d0a0bf6f7fc687b9be6c7991d0bce4b60e81b742f5919933d07de37d625c,prevent,critical,2027-02-01,HollowFrame native dropper,campaign:HollowFrame
sha256,f59f32c9af4fa8a5dbd4668df8893593bc0c4324816cbf9b956acedcbfb8cdb6,prevent,critical,2027-02-01,Matryoshka HTTP backdoor DLL,campaign:Matryoshka
sha256,f96ff2f3abbff7f382ace509b90e54853b4b61c402ecde27d82f1c17b414867b,prevent,critical,2027-02-01,Matryoshka GitHub backdoor DLL,campaign:Matryoshka
sha256,REPLACE_WITH_LNK_SHA256,detect,high,2027-02-01,Malicious shortcut - hash not recovered by the reporting vendor,campaign:HollowFrame
ipv4,2.26.252.84,detect,high,2026-11-01,HollowFrame PowerShell payload delivery server,campaign:HollowFrame
ipv4,45.158.196.184,detect,high,2026-11-01,Matryoshka HTTP C2 on port 8888,campaign:Matryoshka
domain,avvoalert.info,detect,high,2026-11-01,Attacker-controlled phishing redirector,campaign:HollowFrame

# These three hashes are LEGITIMATE SIGNED BINARIES abused as side-load hosts.
# Use them for retrospective search and for scoping. Never set them to prevent.
# python.exe        14a89eda72e385f76bf15a7c4fd539c48837cf5df444a16f28c5b94f29799550
# vcruntime140.dll  d66c3b47091ceb3f8d3cc165a43d285ae919211a0c0fcb74491ee574d8d464f8
# updater.exe       015d7b212d20681d346e690159e7f4cd9e88b51de27e84b514fce865deef3a5c
#
# Pivot instead on WHERE they ran from and WHAT loaded beside them:
#   - any of these executing from a user-writable path
#   - a same-directory DLL whose name matches a system or runtime library
#   - the interpreter running with no script, module or interactive argument

B1  Defender exclusion added for a user-writable DIRECTORY and for a PROCESS NAME,
    minutes apart, by the same process, before any executable is written there.
B2  Interpreter host executed with no script path, no module switch and no
    interactive flag, from a user-writable directory.
B3  A DLL bearing the name of a system or runtime library written into the same
    directory as a signed executable, outside Program Files and outside Windows.
B4  Signed utility used to decode content in a user temp path, with an interactive
    shell or the desktop shell in the ancestry.
B5  PowerShell relaunching itself with an elevation verb plus a hidden window plus
    an execution-policy bypass.
B6  Archive named to imitate an official runtime distribution but carrying an
    architecture suffix that no real release uses.
B7  On-logon scheduled task, highest privileges, short start delay, action path
    inside a user profile or temp directory.
B8  Permanent WMI event subscription whose filter keys on logon-session object
    creation, where prior same-named filters and consumers were deleted first.
B9  Application updater or interpreter process opening a command shell.
B10 Beacon-cadence requests to a code-hosting contents API from a process with no
    development role, with an application user agent that does not match the
    process making the request.
B11 Plaintext HTTP to a bare IPv4 literal with no hostname, from an endpoint,
    fetching an archive.
B12 Repeated GET-then-PUT pairs against the same small set of JSON objects under
    one repository path, one path per host.

HollowFrame        Go modular loader and persistence framework
Matryoshka HTTP    Rust backdoor, plaintext HTTP JSON tasking
Matryoshka GitHub  Rust backdoor, private repository dead drop
loader_panda.exe   native dropper staging the second side-load
Project220Rebr     Go build directory name - NOT a family or actor name
looks like a sandbox, exiting     anti-analysis failure message
pongv2                            health-check response value
/repos/adioziaete/memio/contents/ per-victim mailbox path
OneDrive/24.170.0825.0001         spoofed user agent
beacon.json / cmd.json / result.json   per-host tasking objects
<computer>_<username>             per-victim directory naming scheme
%LOCALAPPDATA%\Programs\Python\Python311-Brief   staging directory

# Dump every current Defender exclusion and the tamper-protection state.
# Anything under a user profile, or any process-name exclusion for an
# interpreter, is a finding regardless of this campaign.
$p = Get-MpPreference
[PSCustomObject]@{
  Host            = $env:COMPUTERNAME
  ExclusionPath   = ($p.ExclusionPath   -join '; ')
  ExclusionProcess= ($p.ExclusionProcess-join '; ')
  ExclusionExt    = ($p.ExclusionExtension -join '; ')
  TamperProtection= (Get-MpComputerStatus).IsTamperProtected
  RealTimeDisabled= $p.DisableRealtimeMonitoring
  ASRRules        = ($p.AttackSurfaceReductionRules_Ids -join '; ')
  ASRActions      = ($p.AttackSurfaceReductionRules_Actions -join '; ')
}

# Logon-triggered tasks whose action points into a user-writable path.
Get-ScheduledTask | Where-Object {
  $_.Triggers.CimClass.CimClassName -contains 'MSFT_TaskLogonTrigger'
} | ForEach-Object {
  [PSCustomObject]@{
    TaskName = $_.TaskName
    RunLevel = $_.Principal.RunLevel
    Action   = ($_.Actions.Execute -join '; ')
  }
} | Where-Object { $_.Action -match 'AppData|\\Temp\\|ProgramData|\\Users\\' }

# Permanent WMI event subscriptions - the mechanism that leaves no process trace.
Get-WmiObject -Namespace root\subscription -Class __EventFilter
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

Do not treat a query as deployed until it has cleared all four gates. A query that returns nothing because the telemetry is absent looks identical to a query that returns nothing because the estate is clean.

Order matters for the reproduction test. Run the Q3 exclusion test and the Q7 DLL-drop test on the same lab host within the same hour, then confirm your correlation logic surfaces the pair. That pairing — not either event alone — is what this pack is really detecting.

Every control below is anchored to a MITRE mitigation (the why) and to a platform benchmark or vendor guidance (the what). The chain has ten links; you do not need to break all of them. Breaking the execution link (user-writable execution) or the tamper link (Defender exclusions) ends the intrusion on its own.

Playbook 1 — Enforce Tamper Protection and audit Defender exclusions (H2)

Prerequisites: Microsoft Defender Antivirus in active mode; Intune or Configuration Manager for the Tamper Protection setting (it cannot be enabled by local registry edit on a managed device); local administrator for the audit step. Reboot required: no. Rollback: set the Tamper Protection policy back to Not Configured in the management console; the exclusion audit is read-only and needs no rollback. Note that rolling back Tamper Protection re-exposes exactly the tamper path this campaign used, so record a reason if you do it.

1. In Intune: Endpoint security > Antivirus > create a Windows Security Experience
   profile, set "TamperProtection (Device)" to "On", assign to all devices.
   (Tamper Protection is enforced by the cloud-managed policy; a local registry
   write is not a supported enablement path and will be reverted.)

2. Confirm enforcement on a sample of hosts:
   (Get-MpComputerStatus).IsTamperProtected     # expect: True

3. Inventory every existing exclusion across the fleet:
   $p = Get-MpPreference
   $p.ExclusionPath
   $p.ExclusionProcess
   $p.ExclusionExtension

4. Flag for removal any exclusion that:
   - resolves under a user profile, %TEMP%, %APPDATA% or %LOCALAPPDATA%
   - names an interpreter process (python.exe, powershell.exe, wscript.exe, ...)
   - has no owner, ticket or documented business justification

5. Remove a flagged exclusion through your management channel, not locally:
   Remove-MpPreference -ExclusionPath 'C:\Path\To\Remove'
   Remove-MpPreference -ExclusionProcess 'python.exe'

6. Forward Defender operational event 5007 to the SIEM and alert on every
   occurrence whose new value falls under the exclusions key.

Playbook 2 — Attack Surface Reduction rules in Block mode (H4)

Prerequisites: Defender Antivirus active with real-time protection on; Windows 10 1709 or later; a pilot ring of 20 to 50 mixed-role endpoints. Reboot required: no. Rollback: re-run the same commands with -AttackSurfaceReductionRules_Actions Disabled for the specific rule ID, or set the rule to AuditMode to keep visibility while removing enforcement. Roll back per rule, never all four at once, so you keep the coverage you have already proven.

1. Put the four rules in AUDIT first and leave them for one business cycle:
   Add-MpPreference -AttackSurfaceReductionRules_Ids `
     BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550, `   # exec content from mail/webmail
     5BEB7EFE-FD9A-4556-801D-275E5FFC04CC, `   # potentially obfuscated scripts
     D1E49AAC-8F56-4280-B9BA-993A6D77406C, `   # process creation from PSExec/WMI
     9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 `    # credential theft from LSASS
     -AttackSurfaceReductionRules_Actions AuditMode, AuditMode, AuditMode, AuditMode

2. Review Defender event 1122 (audit) for each rule. Build the exclusion list from
   what you actually see, not from what you expect to see.

3. Add only the exclusions the audit justified:
   Add-MpPreference -AttackSurfaceReductionOnlyExclusions 'C:\Approved\Path'

4. Promote to BLOCK, one rule at a time, a week apart:
   Set-MpPreference -AttackSurfaceReductionRules_Ids BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 `
     -AttackSurfaceReductionRules_Actions Enabled

5. Verify the enforced state:
   $p = Get-MpPreference
   $p.AttackSurfaceReductionRules_Ids
   $p.AttackSurfaceReductionRules_Actions       # expect: 1 = Block, 2 = Audit

Playbook 3 — PowerShell Script Block Logging and transcription (H6)

Prerequisites: Group Policy or Intune for the policy path; a log destination sized for the volume — script block logging is verbose; a write-protected file share for transcripts. Reboot required: no; new PowerShell sessions pick the policy up immediately. Rollback: set both policies back to Not Configured in the GPO, or delete the two registry keys below and run gpupdate /force. Transcripts already written are not removed by rollback — retire them under your normal evidence-retention policy.

1. GPO path:
   Computer Configuration > Administrative Templates > Windows Components >
   Windows PowerShell
     - "Turn on PowerShell Script Block Logging"  = Enabled
     - "Turn on PowerShell Transcription"         = Enabled
       Output directory = \\logserver\ps-transcripts$   (append-only to clients)
     - "Turn on Module Logging"                   = Enabled, module names = *

2. Equivalent registry values if you are deploying outside GPO:
   HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
     EnableScriptBlockLogging (DWORD) = 1
   HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription
     EnableTranscripting (DWORD) = 1
     OutputDirectory (SZ)        = \\logserver\ps-transcripts$

3. Remove the legacy engine, which ignores these policies entirely:
   Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root

4. Verify: run a benign script and confirm event 4104 appears in
   Microsoft-Windows-PowerShell/Operational and reaches the SIEM.

5. Standing hunts to build on top of it:
   - 4104 containing a long unbroken hex literal together with Invoke-Expression
   - 4104 containing -Verb RunAs together with -WindowStyle Hidden
   - 4104 containing Add-MpPreference or Set-MpPreference with any Exclusion parameter

Playbook 4 — AppLocker audit-then-block for user-writable paths (H5)

Prerequisites: Application Identity service set to Automatic and running on targets; a GPO scoped to a pilot ring; an inventory owner who can adjudicate the audit results. Use WDAC instead of AppLocker if you already run it — the intent is identical. Reboot required: no, but the Application Identity service must be restarted or the host recycled for a first-time enablement. Rollback: unlink the GPO and run gpupdate /force; rules stop being enforced immediately. Keep the audit-mode GPO linked after rolling back enforcement so you do not lose visibility while you re-scope.

1. Ensure the enforcement service will run:
   Set-Service -Name AppIDSvc -StartupType Automatic
   Start-Service -Name AppIDSvc

2. Create the GPO at:
   Computer Configuration > Windows Settings > Security Settings >
   Application Control Policies > AppLocker
   Create default rules for Executable and DLL collections, then set BOTH
   collections to "Audit only".

3. Add a deny rule for user-writable execution (Executable + DLL collections):
   Path condition:  %OSDRIVE%\Users\*\AppData\*
   Path condition:  %OSDRIVE%\Users\*\Downloads\*
   Path condition:  %OSDRIVE%\ProgramData\*
   Path condition:  %OSDRIVE%\Windows\Temp\*
   (The DLL collection is the one that matters here - the side-loaded payloads
   are DLLs, and an executable-only policy would have allowed all three.)

4. Leave in audit for one full business cycle. Harvest results:
   Get-AppLockerFileInformation -EventLog -EventType Audited -Statistics

5. Convert every legitimate hit into a publisher rule - signed by vendor - rather
   than a path exception. Path exceptions are what the actor was exploiting.

6. Flip the collections to "Enforce rules", one collection at a time, a week apart.

7. Verify: copy a benign signed executable to %LOCALAPPDATA% and run it. Expect a
   block, and expect event 8004 (exe) or 8007 (dll) in
   Microsoft-Windows-AppLocker/EXE and DLL.

Playbook 5 — Mark-of-the-Web propagation and shortcut handling (H3, H9)

Prerequisites: control of the standard archive tool deployed to endpoints; mail-gateway policy edit rights. Reboot required: no. Rollback: set the archive tool's zone-propagation value back to its prior setting and re-run the deployment; revert the gateway rule to its previous action. Both are single-value changes with no dependent state.

1. Standard archive tool - propagate the zone identifier to extracted files.
   For 7-Zip, deploy the "Propagate Zone.Id stream" option set to "All files"
   (HKCU\Software\7-Zip\Options : WriteZoneIdExtract (DWORD) = 1) via GPP or Intune.

2. Block or restrict archive tools that cannot propagate the zone identifier,
   using the same AppLocker or WDAC policy built in Playbook 4.

3. Mail gateway - hold, do not deliver, any message whose attachment is a
   password-protected archive that content inspection could not open. Route to
   detonation if your platform supports it, otherwise to a review queue.

4. Mail gateway - strip or quarantine .lnk files found inside delivered archives.
   Confirm with the business first; the legitimate rate is close to zero in most
   estates but is not always exactly zero.

5. Verify: send yourself a password-protected archive containing a harmless
   shortcut, confirm it is held, then extract a file from an ordinary downloaded
   archive and confirm the zone identifier stream is present:
   Get-Item .\extracted-file.txt -Stream Zone.Identifier

The most commonly missed eradication step is the Defender exclusion. It was created before the payload and it survives every payload removal. A host that is cleaned but keeps a path and process-name exclusion is a host that is pre-prepared for the next attempt.

Known gaps, stated plainly

• The anti-analysis gates and the in-memory execution modes cannot be hunted from telemetry. They happen inside one process with no observable side effect. This pack does not pretend otherwise, and no query below claims to cover them.
• WMI subscription persistence has no CQL angle here because the loader creates it through the WMI API rather than through wmic.exe or a cmdlet. The WMI-Activity operational log is the only source, so if you are not collecting it you have no coverage of one of the three persistence mechanisms.
• The dead-drop channel is only half-visible on the endpoint. Without full-URI proxy logging you can see that a process resolved a code-hosting API and nothing more, which is not enough to call it.
• Single-source intelligence. Every atomic indicator here comes from one vendor's telemetry on one intrusion at two endpoints. Treat absence of hits as uninformative rather than reassuring, and lean on the behavioural half of the pack.

All four validation gates in section 11 must pass before any of this coverage is real. In particular, gate 1 — telemetry ready — is what separates a genuine "no hits" from a silently broken query, and gate 2 must be completed for Q9 and Q10 before either is handed to an analyst.

Source snapshots for both cited sources are saved verbatim alongside this file in HollowFrame-Matryoshka-Hunt-sources/. Every atomic indicator shipped in section 10 traces to one of them.