Sauron Loader: MaaS DLL Side-Loading Campaigns Against Germany

DCSO CyTec published research on 2026-09-24 describing a previously undocumented loader family it calls Sauron Loader, encountered in multiple real-world incidents against organizations in Germany. The malware is sold as Malware-as-a-Service in Russian-speaking underground forums by an actor operating under the alias "S4ur0n" (leetspeak for "Sauron"), and the seller's own advertisement states the loader is intended exclusively for Russian-speaking customers and is not to be used against public-sector organizations or post-Soviet states. Cyber Security News independently corroborated the finding on 2026-09-25 after DCSO shared the report with them directly, and the write-up was further mirrored by Cryptika, summarized by Mallory.ai, and cross-posted to the malware.news community board. This pack treats the DCSO CyTec research as the primary technical source and Cyber Security News as the second independent confirmation.

In the incidents DCSO supported, Sauron Loader was the final stage of attack chains that began with social engineering rather than exploitation: ClickFix-style fake verification prompts and voice phishing, where victims were first flooded with spam email (email bombing) and then contacted by attackers posing as IT support, in some cases directing the victim to start a Microsoft Quick Assist remote-assistance session. The observed MSI installer drops three files into the hardcoded directory C:\ProgramData\keyroll: the legitimate, genuinely Mozilla-signed utility rnpkeys.exe (part of the RNPGP suite), the malicious loader library rnp.dll that it side-loads, and a second malicious library tdwp.dll that decrypts rnp.dll's encrypted sections directly in memory and creates a scheduled task named keyroll for persistence. The malware deliberately delays execution during decryption, a technique intended to frustrate antivirus and automated sandbox analysis.

The highest-value defensive angle is the directory and the task name, not the DLL filenames. rnpkeys.exe and rnp.dll are real Mozilla RNP component names, so hunting on the filenames alone risks flagging genuine RNPGP installs. What is campaign-specific is the combination: those exact binaries running from C:\ProgramData\keyroll, dropped by an MSI, backed by a scheduled task literally named keyroll. That combination has no benign explanation in a normal estate.

The second-highest-value angle is the four named command-and-control domains recovered from the decrypted embedded configuration: api.namsb-show.com, api.quinlantours.com, api.virtual-magic.com, and api.lahaina-shores.com. All four, plus the four SHA-256 hashes (the malicious MSI, the malicious rnp.dll, the malicious tdwp.dll, and the legitimate rnpkeys.exe for context only), were independently published by both DCSO CyTec and Cyber Security News, which qualifies the malicious set for a block posture under this pack's two-source rule.

Defender priority: import the section 10 CSV into Falcon IOC Management and block the four C2 domains at DNS and proxy today, then run Q2 and Q4 across a 90-day window. A hit on either is a confirmed compromise until proven otherwise: nothing in a normal estate legitimately places rnpkeys.exe in C:\ProgramData\keyroll or registers a task named keyroll. Never block the rnpkeys.exe hash itself; it is a genuine signed Mozilla binary and blocking it does nothing to stop the campaign.

Research decisions

• Prevent/critical requires two independent sources. The four C2 domains and the three malicious SHA-256 hashes (MSI, rnp.dll, tdwp.dll) are published identically by both DCSO CyTec and Cyber Security News, two editorially independent outlets, so they ship at action=prevent. The Cryptika mirror is not counted as a second source because it discloses itself as a republish of the Cyber Security News piece.
• The legitimate rnpkeys.exe hash never ships as prevent. It is a genuine, correctly signed Mozilla RNPGP binary that the loader abuses for side-loading. It is listed as a hunt anchor with an explicit do-not-block marker in sections 4 and 10.
• Filenames alone are not sufficient hunt anchors. rnpkeys.exe and rnp.dll are real RNPGP component names. Every CQL query keys on the unexpected parent path (C:\ProgramData\keyroll), the MSI-dropped context, the scheduled task name, or the DLL appearing outside its known location, never on the filename in isolation.
• No aggregator-only indicators. Mallory.ai's page masks every atomic value, so nothing atomic in this pack traces to it. It was used only to confirm the narrative and the actor alias.
• No related-cluster IOCs imported. Mallory.ai's "Related stories" panel lists unrelated malware (LegionLoader/Satacom, TA4922's SilentRunLoader/Atlas RAT, generic ClickFix/Donut loader campaigns). None of their indicators (for example a 167.88.167.9:8356 callback or an obs.dll sideload from a different campaign) belong to Sauron Loader and none are shipped in this pack.
• Prompt-injection review. All five fetched sources (DCSO/malware.news mirror, Cyber Security News, Cryptika, Mallory.ai, DCSO's GitHub repository) were reviewed for text addressed to an automated reader: instructions to fetch further URLs, change scope, or skip a check. None were found. No source was disqualified.
• Access note. The DCSO CyTec Medium post (the cited primary source) returns HTTP 403 to automated fetch tools. Its full text was retrieved and saved instead from its malware.news community mirror, which reproduces the post verbatim including the appendix TTP-mapping table and the indicator list.
• Perishability. DCSO reports finding additional Sauron Loader samples with different embedded C2 infrastructure beyond the analyzed sample. The four named domains will not be the last set this loader uses; the behavioral queries in section 8 (path, task name, MSI-to-sideload chain) are built to outlive a C2 rotation.

Attack chain

Hunt hypotheses (fidelity-ordered)

Confidence high = published identically by DCSO CyTec and Cyber Security News, two independent sources. Action follows confidence: only two-source infrastructure ships at prevent/critical, and the legitimate Mozilla binary never ships as a block action regardless of how prominently it appears in the chain.

Do not block rnpkeys.exe by hash or by name alone. It is a genuine, correctly signed Mozilla RNPGP utility that the loader abuses purely for its side-loading behavior. Blocking it breaks a legitimate application and does not stop the campaign, which would simply ship a different signed host binary in its next MSI build.

Technique identifiers below follow DCSO CyTec's own published TTP mapping appendix.

Proxy / web gateway

• Search proxy access logs for HTTPS POST requests whose path matches /<prefix>/v[1-9]/<action><resource> where prefix is one of api, webhook, metrics, public, internal, action is set or get, and resource is one of Config, Status, Profile, Settings, Preferences, Token, Metadata, Connection, Timeout, Features. A single client hitting several of these path shapes at a steady interval is the loader's registration/poll cycle.
• Filter on the two documented loader user-agent strings: Mozilla/5.0 (Windows NT %d.%d; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.3650.96 for Windows 10 and above, and Mozilla/5.0 (Windows NT %d.%d; Trident/7.0; rv:11.0) like Gecko for Windows 8, where %d.%d is the actual Windows major/minor version.
• Look for a steady beacon rhythm consistent with the documented sleep timers: roughly 160 seconds after a failed registration or poll (also triggers C2 rotation to one of the other three domains), and roughly 600 seconds after a successful poll/task cycle.
• If your proxy or firewall can TLS-inspect the session, the plaintext-before-encryption structure is a Salsa20 key/nonce header (16-byte key, 8-byte nonce on client requests; 32-byte key, 8-byte nonce on server responses) followed by an RSA signature and ciphertext length fields, then 1111 to 9999 bytes of random padding. This shape is unusual enough to fingerprint even without breaking the encryption.

DNS resolver

• Query resolver logs for the four named domains in section 4 over your longest retention window. DCSO notes it found additional samples with different embedded C2 infrastructure, so treat the four names as a floor, not a ceiling.
• Flag repeated NXDOMAIN or fast domain-rotation patterns from a single client immediately following a resolution of one of the four known domains: this is the loader's documented C2-rotation-on-failure behavior.

Email gateway

• Search for a sudden, sharp increase in inbound mail volume to a single mailbox in a short window (email bombing), especially newsletter or mailing-list signup confirmations, which is a common bombing technique.
• Cross-reference any mailbox that received an email-bombing pattern against subsequent inbound or outbound calls, help-desk tickets, or remote-assistance session logs within the following hours.

Remote-assistance tooling

• Audit Microsoft Quick Assist (and AnyDesk, if present in your estate) session logs for sessions initiated by a standard user shortly after an email-bombing event, without a corresponding IT ticket opened beforehand by the user.
• Confirm your help desk has, and staff actually follow, an out-of-band identity-verification step before starting any unsolicited remote-assistance session.

Windows endpoint (Sysmon / native)

• Sysmon Event ID 7 (Image Loaded): rnpkeys.exe loading rnp.dll from C:\ProgramData\keyroll. This is the cleanest sideloading signal and Falcon's Custom IOA rule types are the closest native equivalent (section 9).
• Sysmon Event ID 11 (File Create): any of rnpkeys.exe, rnp.dll, or tdwp.dll created under C:\ProgramData\keyroll.
• Sysmon Event ID 1 (Process Create) with a command line invoking schtasks.exe /create and a task name of keyroll, as a cross-check against the native ScheduledTaskRegistered event used in Q4.
• Enumerate C:\ProgramData for any subdirectory containing exactly the triad rnpkeys.exe, rnp.dll, tdwp.dll, regardless of the parent folder name, in case a future build renames the drop directory. Playbook 1 in section 13 does this estate-wide.

None of these queries carry an in-query time filter. Set the window with the console time picker; the intended lookback is recorded in each card as a // LOOKBACK: comment. For this campaign use 90 days minimum, since DCSO reports finding additional samples with independently rotated C2 infrastructure.

// HUNT: Sauron Loader confirmed C2 domain resolution
// MITRE: T1071.001 | CONF: high  FP: low  COST: low
// REQUIRES: DnsRequest telemetry
// FALSE POSITIVES: none expected; no legitimate resolver path exists for these hostnames
// LOOKBACK: 90d (set in the console time picker)
#event_simpleName=/^(DnsRequest|SuspiciousDnsRequest)$/
| DomainName=/^([a-z0-9_-]+\.)*(namsb-show\.com|quinlantours\.com|virtual-magic\.com|lahaina-shores\.com)$/i
| table([@timestamp, aid, ComputerName, UserName, ContextBaseFileName, DomainName])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Sauron Loader side-load host executing from its hardcoded drop directory
// MITRE: T1574.002, T1036.005, T1218.007 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: none expected; rnpkeys.exe has no legitimate reason to run from ProgramData\keyroll
// LOOKBACK: 90d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^rnpkeys(\.exe)?$/i
| ImageFileName=/\\ProgramData\\keyroll\\/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, SHA256HashData, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Sauron Loader malicious DLL pair written to the ProgramData\keyroll directory
// MITRE: T1027.013, T1574.002 | CONF: high  FP: low  COST: low
// REQUIRES: PeFileWritten or NewExecutableWritten
// FALSE POSITIVES: none expected; this exact filename pair dropping into this exact directory is campaign-specific
// LOOKBACK: 90d
#event_simpleName=/^(PeFileWritten|NewExecutableWritten)$/
| TargetFileName=/\\ProgramData\\keyroll\\(rnp|tdwp)\.dll$/i
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Sauron Loader "keyroll" scheduled task persistence
// MITRE: T1053.005 | CONF: high  FP: low  COST: low
// REQUIRES: ScheduledTaskRegistered telemetry
// FALSE POSITIVES: none expected; "keyroll" is not a Windows or common-vendor task name
// LOOKBACK: 90d
#event_simpleName=/^ScheduledTaskRegistered$/
| TaskName=/^keyroll$/i
| table([@timestamp, aid, ComputerName, UserName, TaskName, TaskExecutable, TaskAuthor])
| sort(@timestamp, order=desc, limit=500)

// HUNT: MSI installer directly spawning the Sauron Loader side-load host
// MITRE: T1218.007, T1574.002 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: none expected; msiexec does not legitimately launch rnpkeys.exe as a direct child
// LOOKBACK: 90d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^msiexec(\.exe)?$/i
| FileName=/^rnpkeys(\.exe)?$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Sauron Loader known-bad SHA-256 set (MSI dropper + malicious DLL pair)
// MITRE: T1204.002, T1574.002 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2, PeFileWritten or ImageHash
// FALSE POSITIVES: malware-analysis workstations and detonation sandboxes
// NOTE: the legitimate signed rnpkeys.exe hash is deliberately NOT in this list; see section 4
// LOOKBACK: 180d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2|PeFileWritten|NewExecutableWritten|ImageHash)$/
| in(SHA256HashData, values=[
    "ee727d639eaa4ee2e0d7cafbe496e14aaac8df0955d9fb599f2c11dfa1d0f8f2",
    "5606afdc5191d42f38d3c4f1692eda0a629c88810e29bfe78528733284ad1bf8",
    "6551293e996d19755ba497f50b30a18c178f0d6e2a73b29ae742b8171e2985b7"])
| table([@timestamp, aid, ComputerName, UserName, #event_simpleName, FileName, ImageFileName, TargetFileName, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: RNP/rnpkeys binary executing outside its legitimate Mozilla RNP install path
// MITRE: T1574.002, T1036.005 | CONF: medium  FP: medium  COST: medium
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: a genuine Thunderbird/RNP install running rnpkeys.exe from Program Files during key management
// TUNING: append the exclusion stage below to drop the real install path, then baseline the survivors
// TUNING: | ImageFileName!=/\\Program Files( \(x86\))?\\(Mozilla Thunderbird|RNP)\\/i
// LOOKBACK: 90d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^rnpkeys(\.exe)?$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Scheduled task launching an executable from a non-standard ProgramData subfolder
// MITRE: T1053.005 | CONF: medium  FP: medium  COST: medium
// REQUIRES: ScheduledTaskRegistered telemetry
// FALSE POSITIVES: legitimate vendor agents and updaters that install a scheduled task under ProgramData
// TUNING: exclude your approved ProgramData vendor subfolders by name, e.g. append
// TUNING: | TaskExecutable!=/\\ProgramData\\(Microsoft|Google|Mozilla|Adobe|Dell|HP|Intel|CrowdStrike)\\/i
// TUNING: then investigate any TaskExecutable seen on fewer than 3 distinct hosts
// LOOKBACK: 90d
#event_simpleName=/^ScheduledTaskRegistered$/
| TaskExecutable=/\\ProgramData\\[^\\]+\\[^\\]+\.(exe|dll)$/i
| groupBy([TaskName, TaskExecutable], function=[count(aid, distinct=true, as=HostCount), count(as=Regs)], limit=2000)
| sort(HostCount, order=asc, limit=200)

// HUNT: Sauron Loader payload staged to %TEMP% with a randomised filename
// MITRE: T1105, T1027 | CONF: medium  FP: medium-high  COST: medium
// REQUIRES: PeFileWritten, NewExecutableWritten or ZipFileWritten
// FALSE POSITIVES: legitimate installers and browsers routinely stage randomly-named temp files
// TUNING: correlate with Q2/Q3 hits on the same aid within a 24h window before treating this as actionable;
// TUNING: on its own this query is a triage feed, not an alert
// LOOKBACK: 30d
#event_simpleName=/^(PeFileWritten|NewExecutableWritten|ZipFileWritten)$/
| TargetFileName=/\\Temp\\[A-Za-z0-9]{6,16}\.(exe|dll|sys|msi|zip|cmd|ps1|vbs|js)$/i
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: rnp.dll / tdwp.dll written outside the known ProgramData\keyroll drop path
// MITRE: T1036.005, T1574.002 | CONF: medium  FP: medium  COST: medium
// REQUIRES: PeFileWritten or NewExecutableWritten
// FALSE POSITIVES: none known by filename collision, but confirm SignInfoFlags semantics for your sensor version first
// TUNING: ⚠ validate in tenant -- SignInfoFlags bit meanings are sensor/tenant-version dependent;
// TUNING: project and baseline the values your estate actually reports before filtering on a specific bit
// LOOKBACK: 90d
#event_simpleName=/^(PeFileWritten|NewExecutableWritten)$/
| TargetFileName=/\\(rnp|tdwp)\.dll$/i
| TargetFileName!=/\\ProgramData\\keyroll\\/i
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, SignInfoFlags, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Repeated HTTPS egress from a Sauron Loader process (C2 poll/registration cadence)
// MITRE: T1071.001, T1573.001, T1573.002 | CONF: medium  FP: medium-high  COST: high
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: any legitimate updater or agent co-located under the same process names
// TUNING: drop known-good egress destinations first, e.g. append a !cidr() stage for your CDN/vendor ranges,
// TUNING: then keep groups where Conns is high and the FirstSeen-to-LastSeen span matches multiple poll cycles
// LOOKBACK: 30d (this one is expensive; widen only after tuning)
#event_simpleName=/^NetworkConnectIP4$/
| ContextBaseFileName=/^(rnpkeys|rnp|tdwp)(\.exe|\.dll)?$/i
| RemotePort=443
| groupBy([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4], function=[count(as=Conns), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=2000)
| sort(Conns, order=desc, limit=200)

// HUNT: rundll32/regsvr32 invoked against a Sauron Loader component DLL
// MITRE: T1218.011, T1218.010, T1574.002 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: none expected; rnp.dll/tdwp.dll are not legitimately invoked via rundll32/regsvr32
// LOOKBACK: 90d
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(rundll32|regsvr32)(\.exe)?$/i
| CommandLine=/\\(rnp|tdwp)\.dll/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

Four of the twelve queries are clean enough to promote to Custom IOAs. The rest stay investigate-only until tuned. Build these under Endpoint security > Custom IOA rule groups, start every rule at Detect, and only move to Prevent after a two-week clean baseline.

IOA-1 · Side-load host in its hardcoded drop directory

IOA-2 · "keyroll" scheduled task creation

IOA-3 · MSI-to-sideload execution chain

IOA-4 · rundll32/regsvr32 against a component DLL

Not promoted, and why

• Q1 / Q6 (domain and hash lookups) — better served by Falcon IOC Management import than by a Custom IOA. Import the CSV in section 10 instead.
• Q3 — the file-write moment overlaps IOA-1's process signal in most incidents and is kept as a scheduled search rather than a duplicate IOA.
• Q7, Q8, Q9, Q10, Q11 — FP medium or higher. Run these as scheduled searches for two weeks and apply the tuning line before considering an IOA.
• The in-memory decryption stage and the Salsa20/RSA protocol content — no Custom IOA rule type reaches them. They are memory-behavioral and protocol-content signals respectively; treat this as a known ceiling, not a gap you can close with more queries.

Read before importing. Every value below traces to a saved snapshot of the DCSO CyTec research and its independent Cyber Security News confirmation. Two-source infrastructure carries severity=critical. The legitimate Mozilla binary is listed for context only and must never be set to a block action.

type,value,action,severity,expiration,description,tags
domain,api.namsb-show.com,prevent,critical,2027-03-27,Sauron Loader C2 endpoint,campaign:SauronLoader
domain,api.quinlantours.com,prevent,critical,2027-03-27,Sauron Loader C2 endpoint,campaign:SauronLoader
domain,api.virtual-magic.com,prevent,critical,2027-03-27,Sauron Loader C2 endpoint,campaign:SauronLoader
domain,api.lahaina-shores.com,prevent,critical,2027-03-27,Sauron Loader C2 endpoint,campaign:SauronLoader
sha256,ee727d639eaa4ee2e0d7cafbe496e14aaac8df0955d9fb599f2c11dfa1d0f8f2,prevent,critical,2027-03-27,Sauron Loader MSI installer,campaign:SauronLoader
sha256,5606afdc5191d42f38d3c4f1692eda0a629c88810e29bfe78528733284ad1bf8,prevent,critical,2027-03-27,Sauron Loader malicious rnp.dll,campaign:SauronLoader
sha256,6551293e996d19755ba497f50b30a18c178f0d6e2a73b29ae742b8171e2985b7,prevent,critical,2027-03-27,Sauron Loader malicious tdwp.dll,campaign:SauronLoader
# DO NOT BLOCK 194d7e8870ff783ce1e4e4e3015c895cc67ae52fd5e063c89dd1c069400d3991
# That SHA-256 is the LEGITIMATE, genuinely Mozilla-signed rnpkeys.exe utility.
# It is a hunt anchor only. Blocking it breaks a real product and stops nothing.
# The next campaign build can pick a different signed host binary entirely.

# These survive a C2 rotation or a renamed drop directory. The atomic
# indicators above will not.
DROP_PATH         C:\ProgramData\keyroll (hardcoded MSI extraction target)
TRIAD             rnpkeys.exe (legit) + rnp.dll (malicious loader) +
                  tdwp.dll (malicious decrypter/scheduler), all three in
                  the same directory
SIDELOAD          legitimate signed rnpkeys.exe side-loads rnp.dll from
                  its own directory
DECRYPT_ROUTINE   tdwp.dll decrypts rnp.dll's encrypted sections directly
                  in memory, with a deliberate execution delay
PERSISTENCE       scheduled task literally named "keyroll"
C2_URI_SHAPE      /prefix/vN/actionResource?params where prefix is one of
                  api, webhook, metrics, public, internal (N is 1-9)
C2_CRYPTO         Salsa20 with a fresh 16-byte key + 8-byte nonce per
                  client request, RSA-signed; server replies with a
                  32-byte Salsa20 key
BOT_ID            lowercase MD5 hex digest of
                  COMPUTERNAME + USERNAME + volume_serial
SLEEP_TIMERS      160s after a failed registration/poll (also rotates C2);
                  600s after a successful poll/task cycle
MSG_TYPES         0x01 registration, 0x02 task poll, 0x03 task results,
                  0x04 payload retrieval
PAYLOAD_HANDLERS  EXE, DLL, driver (.sys), shellcode, MSI, ZIP, CMD,
                  PowerShell, VBS, JavaScript (10 total)
TEMP_STAGING      %TEMP%\ + random 6-16 character name + handler extension
SCREENSHOT_EXFIL  PNG captured, chunked into pieces up to 0x4000 bytes,
                  sent via the same task-results message type

loader           Sauron Loader (Malware-as-a-Service, C++)
seller alias     S4ur0n (leetspeak for "Sauron")
market           Russian-speaking underground forums
drop mechanism   MSI installer to C:\ProgramData\keyroll
sideload host    rnpkeys.exe (genuine Mozilla RNPGP utility, abused)
loader dll       rnp.dll (encrypted, decrypted in memory by tdwp.dll)
decrypter/sched  tdwp.dll (persistence via scheduled task "keyroll")
publisher        DCSO CyTec (primary research, 2026-09-24)
corroboration    Cyber Security News (2026-09-25, independent)
extractor tool   DCSO GitHub Blog_CyTec/2026_09__sauron_loader/get_config.py

# Delivery vectors observed: ClickFix fake-prompt pastejacking, and
# vishing (email bombing followed by a fake IT-support call, in one
# incident directing the victim to open Microsoft Quick Assist).

# Policy / process checks
Help desk has a documented out-of-band caller-identity verification step   Y/N
Standard users can start Quick Assist / remote-assist sessions unattended  Y/N
Mail gateway flags abnormal inbound volume spikes to a single mailbox     Y/N
Standard users can install MSI packages without elevation                 Y/N

# Policy values to verify
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 0
HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 0
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\DisableMSI            = 2

# Defender ASR rules to enable in Block mode
D3E037E1-3EB8-44C8-A917-57927947596D  Block JS/VBS launching downloaded executable content
5BEB7EFE-FD9A-4556-801D-275E5FFC04CC  Block execution of potentially obfuscated scripts
D4F940AB-401B-4EFC-AADC-AD5F3C50688A  Block Office apps creating child processes

Gate 1 — Telemetry ready

• Confirm ScheduledTaskRegistered events are present estate-wide before trusting a clean result from Q4, Q8, or Q12: #event_simpleName=/^ScheduledTaskRegistered$/ | groupBy([ComputerName], function=count(as=n), limit=5000). A host group returning zero is invisible to the persistence queries.
• Confirm DnsRequest is flowing before trusting Q1's silence.
• Confirm PeFileWritten or NewExecutableWritten is enabled before trusting Q3, Q9, or Q10's silence.
• Confirm your DNS resolver and proxy retention actually covers 90 days. If it covers 30, record that in the hunt ticket rather than reporting a clean hunt.

Gate 2 — Benign baseline

• Before enabling Q7 or Q8 as a scheduled search, confirm whether your estate has a legitimate Thunderbird/RNP deployment or any scheduled tasks that legitimately install under ProgramData, and add the tuning exclusion in the card before promoting either to an alert.
• Run Q11 for one full week first and inspect the Conns distribution; anything that looks like normal telemetry or update-check traffic belongs in the CIDR/vendor-range exclusion, not in the alert.

Gate 3 — Confirm the finding, not just the query

• A hit on Q2, Q3, Q4, or Q5 is high-confidence on its own; still pull the full directory listing of C:\ProgramData\keyroll before isolating, since the loader may already have staged an additional payload there.
• A hit on Q7, Q8, Q9, Q10, or Q11 alone is not sufficient to declare compromise; corroborate against Q1, Q2, Q4, or Q6 on the same host before escalating.

Each control names the MITRE mitigation it satisfies and the platform authority that defines it. Controls are ordered by leverage against this specific chain, not by comprehensiveness.

Playbook 1 — Sweep for the Sauron Loader triad (PowerShell)

Finds the drop directory or any folder anywhere on disk containing all three loader filenames together, in case a future build renames the keyroll directory. Read-only; run it estate-wide before you change anything.

# Run as SYSTEM or an admin. Read-only enumeration.
$known = 'C:\ProgramData\keyroll'
if (Test-Path $known) {
    Get-ChildItem -Path $known -File -ErrorAction SilentlyContinue | ForEach-Object {
        [pscustomobject]@{
            Host   = $env:COMPUTERNAME
            Path   = $known
            File   = $_.Name
            Sha256 = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
        }
    }
}

# Broader sweep: any ProgramData subfolder containing all three filenames,
# in case a future build renames the "keyroll" directory itself.
Get-ChildItem 'C:\ProgramData' -Directory -ErrorAction SilentlyContinue | ForEach-Object {
    $dir = $_.FullName
    $has = @('rnpkeys.exe','rnp.dll','tdwp.dll') | Where-Object {
        Test-Path (Join-Path $dir $_)
    }
    if ($has.Count -eq 3) {
        [pscustomobject]@{
            Host      = $env:COMPUTERNAME
            Directory = $dir
            Triad     = 'CONFIRMED'
        }
    }
}
# All three filenames together in one ProgramData subfolder is the Sauron
# Loader triad regardless of the directory name. Collect the folder and the
# scheduled task list before isolating.

Playbook 2 — Audit for the "keyroll" scheduled task (PowerShell)

Cross-checks the native ScheduledTaskRegistered telemetry in Q4 against the local task scheduler directly. Read-only.

Get-ScheduledTask | Where-Object { $_.TaskName -match 'keyroll' } | ForEach-Object {
    $info = Get-ScheduledTaskInfo -TaskName $_.TaskName -TaskPath $_.TaskPath
    [pscustomobject]@{
        Host      = $env:COMPUTERNAME
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Action    = ($_.Actions | ForEach-Object { $_.Execute }) -join ';'
        Arguments = ($_.Actions | ForEach-Object { $_.Arguments }) -join ';'
        State     = $_.State
        LastRun   = $info.LastRunTime
    }
}

Playbook 3 — Deny execution from ProgramData (AppLocker, GPO)

Deploy in Audit mode for 48 hours first; the report tells you which legitimate applications you are about to break before you enforce.

# 1. Create or edit a GPO linked to your workstation OU.
# 2. Computer Configuration
#      -> Policies
#      -> Windows Settings
#      -> Security Settings
#      -> Application Control Policies
#      -> AppLocker
#      -> Executable Rules
# 3. New Rule: Action = Deny, User = Everyone, Condition = Path
#      %OSDRIVE%\ProgramData\*
#    Then add Exceptions for your known-good vendor subfolders
#    (Microsoft, your EDR vendor, approved line-of-business agents).
# 4. Repeat under "DLL Rules" with the same path and exceptions. DLL rules
#    are what actually stop the sideload; the executable rule alone leaves
#    rnp.dll loadable by rnpkeys.exe even if rnpkeys.exe itself is denied.
# 5. Set enforcement to "Audit only", collect for 48h, then switch to
#    "Enforce rules".

Playbook 4 — Help-desk vishing verification checklist (process)

A one-page script for help-desk and IT staff to challenge an unsolicited "IT support" contact, especially one that follows an email flood.

1. Did the user open a ticket BEFORE this contact arrived? If no, treat as
   unsolicited.
2. Call the user back on a number from the internal directory, never a
   number the caller provided.
3. Never accept a Quick Assist / AnyDesk / remote-assist session initiated
   in response to an unsolicited call or a "fix it yourself" prompt.
4. Never read out, or ask the user to enter, a one-time code or session
   PIN to someone who called them first.
5. If a recent inbox flood is confirmed, treat any IT-support contact
   in the following 24 hours as suspicious by default and escalate to
   the security team before any remote access is granted.

1. Isolate, don't kill, the affected host first. Network-contain via Falcon host isolation rather than terminating the process; killing tdwp.dll's scheduler mid-cycle can complicate forensic timing but the host should stop reaching the C2 immediately.
2. Preserve C:\ProgramData\keyroll before remediation. Copy the full directory listing, all three files, and their hashes off the host. Confirm whether an additional payload has already been staged there via the message-type-4 payload-retrieval mechanism.
3. Pull the scheduled task definition for "keyroll." schtasks /query /tn keyroll /xml before deleting it, to capture the exact executable path and arguments for the case file.
4. Identify the entry vector. Check whether the user reports a recent email-bombing event, an unsolicited IT-support call, or a ClickFix-style prompt they were told to run. This determines whether the help-desk verification gap (hardening item 3) or the mail-flow anomaly detection (hardening item 6) needs the more urgent fix.
5. Check for a granted remote-assistance session. Review Quick Assist, AnyDesk, or similar tool logs around the infection window for a session the user did not initiate themselves.
6. Hunt laterally with Q1, Q2, Q4, and Q6 estate-wide before declaring scope. A single confirmed host rarely means a single victim; the loader's registration message reports domain-join status, so check whether the host is domain-joined and, if so, whether credentials used on it require rotation.
7. Rotate credentials used on or near the compromised host if there is any indication of screenshot exfiltration (task-results messages with non-zero total_data_length) or a downloaded credential-theft payload via the DLL or shellcode handler.
8. Remove the triad and the scheduled task, then re-image if the loader executed a downloaded second-stage payload. A confirmed hit on Q9 (temp-staged payload) or Q12 (rundll32/regsvr32 against a component DLL) raises this from "clean the loader" to "assume second-stage compromise."
9. Block the four C2 domains estate-wide if not already enforced, and check DNS logs for any other host that has ever resolved them.
10. File the hunt ticket in section 16 with the confirmed entry vector, host count, and whether a second-stage payload executed, before closing the incident.

Twelve queries and four Custom IOAs cover the drop, side-load, persistence, and one payload-handler technique at Good or Partial. The remaining gaps cluster in three places, for three different reasons: the in-memory decryption stage was engineered specifically to avoid endpoint-visible primitives, the social-engineering delivery vectors sit upstream of any endpoint telemetry entirely, and the encrypted C2 content requires TLS inspection this pack cannot assume every reader has deployed. Section 12's application-control item (13) and mail-gateway/help-desk process controls (items 3, 6, 11) are the counters for the delivery gap; sensor memory scanning is the counter for the decryption gap. Before reporting a clean hunt, complete Gate 1 in section 11: a query that returns nothing because the telemetry never arrived is not a negative result.

Source snapshots for every cited source are stored alongside this file in Sauron-Loader-Hunt-sources/. Every atomic indicator shipped in section 10 traces to one of them.