How Filigran built the Salt Typhoon scenario in OpenAEV

Salt Typhoon, also reported as Earth Estries or Ghost Emperor, is an APT known for sustained espionage campaigns and extensive use of living-off-the-land binaries (LOLBins).
At Filigran, we reproduced their TTPs as a controlled scenario in our simulation platform, OpenAEV to evaluate detection and enhance, prevention and XDR resilience against stealthy behaviors.
In this blog, we explain how we researched, designed, sanitized, and validated this specific scenario, now available as pre-built content on the XTM Hub for all Filigran users.

---

TL;DR

• Salt Typhoon relies on LOLBins, persistence and discreet exfiltration techniques.
• Filigran translated public TTPs into a safe, non-destructive OpenAEV scenario.
• Payloads are customizable and mapped to MITRE ATT&CK for traceability.
• Tests were run in an isolated lab with assertions to validate XDR , SIEM on prevention and detection.

---

Understanding Salt Typhoon

Threat context

Salt Typhoon (a.k.a. Earth Estries / Ghost Emperor / UNC2286) is an APT observed conducting long-running intrusions against government and telecommunications targets.

Their campaigns show extended reconnaissance, reliance on living-off-the-land tools, and carefully staged persistence and data collection phases.

Sources and intelligence collection

Our scenario design started with open reports such as Trend Micro’s technical analysis and Varonis’ threat summary.

From these reports we extracted recurring behaviors: remote execution via wmic, use of archive utilities for packaging, scripts dropped under C:\\ProgramData, and targeted access to internal logs.

We treated these behaviors as the signal to emulate, not the malware artifacts themselves.

(See: Trend Micro, Varonis.)

Translating TTPs into OpenAEV payloads

Emulation objective

We aimed to reproduce adversary behavior patterns: lateral execution via legitimate system tooling, artifact placement in common writable locations, and staged collection, while avoiding any destructive actions.

Example 1: WMIC-based execution chain

Reports show Salt Typhoon using wmic process call create "cmd.exe /c <script>" to run scripts on a host.

We recreated the behavior but replaced harmful actions with observable, benign markers:

This template writes marker files and logs instead of executing unknown payloads. It triggers the same telemetry footprints (process spawn via cmd, access to ProgramData, file reads) that XDRs should surface.

Design principles for payloads

• Non-destructive: never perform real exfiltration or destructive changes.
• Parametric: use variables (#{file}, #{artifact_dir}) to adapt payloads to different target images.
• Benign: payloads should be safe to re-run without side effects.
• Prerequisites: you can have check and get prerequisites to facilitate the setup and automations on payloads.
• Cleanup: Each payload can be cleaned up after is execution to avoid let artifacts on endpoints.
• Noise control: simulate realistic timings and spread steps across time windows.
• Sanitization: replace IPs, domains, and keys with placeholders for public artifacts.

MITRE ATT&CK mapping

We mapped every payload to MITRE ATT&CK for traceability:

• T1059.001 — Command and Scripting Interpreter (cmd.exe, wmic)
• T1105 — Ingress Tool Transfer (archive and transfer behaviors, simulated)
• T1078 — Valid Accounts (mimicked via authorized tool use and persistence patterns)

Example 2: Mimic the beacon masquerading & execution

On the Trend Micro report, we saw some paths and the use of cab files to hide Cobalt Strike Beacon inside:

The following schema illsutrates Salt Typhoon’s first attack chainbased on Trend Micro’s research:

WIth this information, we reproduced the same logic but instead of hiding a Cobalt Strike beacon we hid our OpenAEV agent and used the same path:

Other Examples

We developed others payloads into OpenAEV with the same logical sequence:

Here,the HOSTNAME is a variable which can be set to the one we want. By default it’s going on the loopback (127.0.0.1) which should be detected by EDR & SIEM.

Chaining all payloads together

We crafted all the payloads step by step, then chained them together.

Following the Salt Typhoon methodology, we created the following diagram to clearly illustrate our approach, outlining the scenario we are currently implementing in OpenAEV.

What about CVE ?

Salt Typhoon, similar to many other threat actors, uses vulnerabilities to gain initial access to victims before moving to others steps in itsattack path. The threat actor is well-known for usingspecific Cisco vulnerabilities combined to mount a GRE tunnel (like a IPSEC VPN) and then access internal resources. Others known vulnerabilities used include Proxy Shell targeting Microsoft Exchange servers.

Based on this research, we added CVE checks on OpenAEV based on Nuclei templates supporting them:

These templates can be used to check vulnerabilities on remote endpoints – whether they are internal or external through our agentless Nuclei Injector. In the event of vulnerabilities, here’s what we saw:

We could see which assets are vulnerable, view the execution details, and access more information about the CVE and its remediation.

Testing, validation and lessons learned

Safety check

All scenarios were executed inside an isolated lab with snapshots and VLAN segmentation.

Each test run used clean VM states and was instrumented for forensic collection.

Assertions and telemetry verification

OpenAEV scenarios include assertions that verify expected artifacts: assets with vulnerabilities (CVE), presence of marker files, generated logs, and EDR telemetry events.

We validated EDR signals (process creation, command-line arguments, file I/O, archive operations) and confirmed mapping to detection rules.

Iteration and tuning

If your EDR doesn’t detect it, it may be misconfigured or not up to date with these new attack techniques.

OpenAEV’s latest AI features can improve your posture by providing you with detection rules tailored to your specific EDR.

To do so, just select which security platform the rule is for then click on “Use Ariane”:

Security and compliance

We sanitized all public examples. Real report artifacts (sensitive IPs, exact malware samples) were not included in public templates.

Conclusion

Recreating Salt Typhoon’s behaviors in OpenAEV allowed Filigran to test detection coverage for living-off-the-land execution, persistence placements and staged data collection.
Key takeaways: emulate behaviors not malware, keep payloads safe and parametric, map steps to MITRE ATT&CK, and validate in an isolated lab with clear assertions.
These practices yield reproducible scenarios that improve EDR detection and analyst readiness.

Pre-configured scenarios on the XTM Hub

If you are interested in simulating this ATP for internal testing, you can download a free, pre-configured, and sanitized scenario package from the XTM Hub.
https://hub.filigran.io/app.
Enjoy and feel free to ask any questions about it on our Slack community channel !