A recovered Windows post-exploitation kit shows an operator preparing to turn one US organization’s Active Directory domain into a durable launchpad.
The scripts created Domain Admin access, disabled eight endpoint-security services, collected credentials three ways, weakened Remote Desktop protections, and prepared the same backdoor account for deployment across 18 internal hosts.
The Hunter’s Ledger published the analysis on September 7 after examining 81 captured files. Its most surprising finding is where the operator invested effort: public tools handled exploitation and elevation, while custom code encoded the victim’s own DNS filter, internal names, administrative paths, and host list. As researcher Joseph put it, “They did not build a better exploit, they built better knowledge of one estate.”
The scripts show the operator’s prepared capabilities and detailed access. Execution records would be needed to determine which commands ran or succeeded. The beacon’s network behavior and the Ethereum contract’s write history were directly observed, but the corpus contained no encryptor, wiper, or recovery-inhibition artifact. The report connects the infrastructure to a confirmed ransomware incident through Huntress telemetry without establishing whether this operator deployed the encryptor or handed access to someone else.
Victim knowledge drives the kit
The operation began from a privileged position inside a real Windows domain. One script created an Active Directory account with a non-expiring password and added it directly to Domain Admins. Another created a local administrator, added it to Remote Desktop Users, enabled RDP, and set UserAuthentication to 0, disabling Network Level Authentication.
Credential collection ran along three parallel routes. The scripts wrote an LSASS minidump to C:\Windows\Temp\ls.dmp, carried Mimikatz, and saved the SAM, SYSTEM, and SECURITY registry hives under C:\ProgramData for HTTP upload and offline cracking. The kit also set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0 and changed HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy to weaken remote local-account restrictions.
The most victim-specific mechanism targeted a commercial DNS content filter. The operator logged into its administrative interface, downloaded the product’s client-side JavaScript, extracted API action names from that code, and added an attacker domain to the whitelist. Four more scripts planted a matching A record in Active Directory-integrated DNS, pointing the name inward at the filtering appliance. The DNS record made the name resolve inside the estate; the whitelist let the traffic pass.
Figure details
The figure places victim-specific knowledge in a context strip: DNS filter administration, internal names, and the prepared host list. A staged-capability lane groups a new Domain Admin account, eight stopped and disabled security services, a paired internal DNS record and filter whitelist, a prepared eighteen-host deployment list, an LSASS dump at C:\Windows\Temp\ls.dmp, Mimikatz, and SAM, SYSTEM, and SECURITY registry hives. These staged families have no connectors because the recovered scripts do not establish an execution order. A separate direct-observation lane shows Sliver network traffic leading to the measured sixty-second beacon with no observed jitter; Ethereum resolver history appears as another directly observed item with five C2 values over five months.
Two command paths share one name
Sliver formed one command-and-control strand. A weekly SYSTEM scheduled task used a hidden PowerShell DownloadString one-liner to retrieve task_39.ps1 from 193[.]233[.]202[.]17 on port 42718. Re-fetching the chain on every run meant removing a downloaded payload would leave the persistence mechanism ready to pull its replacement.
A separate MSI-delivered Node.js implant formed the second strand. It downloaded the legitimate signed Node.js runtime, ran attacker JavaScript inside node.exe, and read its command server from Ethereum contract 0xb3f2897f2bc797e5b9033faef8c81e92b01cb831. The contract recorded five C2 domains over five months: publisherresolution[.]com, resumeacceptable[.]com, simultaneouslypower[.]com, wiselystarting[.]com, and itemrange[.]com.
The first contract value, publisherresolution[.]com, was also the domain inserted into the victim’s DNS and filter whitelist. That shared name directly links the Sliver and blockchain-resolved strands. The contract gave the operator takedown resistance, while its permanent history gave defenders a stable pivot that domain rotation could not erase.
Behavior survives rotating infrastructure
The report published 321 indicators and 18 behavior-led rules: four YARA, 12 Sigma, and two Suricata. The strongest signal has no per-event signature. The Sliver beacon called home every 60 seconds with no measured jitter, so defenders need flow-timing or beacon-scoring analytics to recognize the cadence.
Two other network traits survive a domain change. The Node.js implant sent HTTP POST requests to freshly generated paths shaped like minified static assets, with a single-letter query parameter. It also used the impossible browser string Chrome/108.0.6602.492; genuine Chrome 108 stable builds used 108.0.5359.x.
Host telemetry can anchor the intrusion more specifically than generic Sliver or Mimikatz detections. Look for an account created outside normal provisioning and added directly to Domain Admins, and for a hidden SYSTEM task with a forged author or backdated registration time whose action contains iex((New-Object Net.WebClient).DownloadString(...)). The report’s primary Sliver sample is bd61c2880920bbfb86c12df439dd1ca0258a10e532433698fd029aef2a5b33f2, and the staged shellcode filename is slv_beacon_sc.bin.
Treat 77[.]110[.]126[.]46 as hunt-only because the source could not establish current ownership. Treat 146[.]103[.]127[.]44 as historical and monitor-only because it has been reassigned. A flat blocklist would risk disrupting an unrelated current occupant.
Contain the domain-level changes
Reset credentials across the affected domain because the three collection routes include offline-crackable material whose later use leaves no collection-time trace. Compare privileged-group membership with approved change records, then inspect scheduled tasks for forged authors, backdated registration times, SYSTEM execution, and fileless re-fetch actions.
Restore the DNS filter’s intended whitelist and rotate its administrative credential. Remove operator-planted records from the Active Directory DNS zone as part of the same repair; changing only one side leaves the bypass partially intact. Check every affected host for RDP enabled while Network Level Authentication is disabled, then restore the approved setting.
Endpoint-service state is another recovery target. The public report withholds the vendor and service names to protect the victim, so teams outside that organization cannot hunt a universal eight-service list. They can still correlate unexplained service stops with the account, scheduled-task, registry, DNS, and network markers above.
Check for remaining attacker access
Run a verification pass from domain, endpoint, DNS, and network telemetry after containment. The expected result is no unauthorized privileged account, no weekly SYSTEM re-pull task, no planted attacker-domain record or whitelist entry, Network Level Authentication enabled on the affected hosts, and no continuing 60-second zero-jitter beacon or malformed Chrome/108.0.6602.492 traffic.
Then query the Ethereum resolver separately. The expected campaign-level result is that any newly recorded domain enters monitoring before an endpoint contacts it. Infrastructure blocks age quickly in this operation; the contract and the victim-specific control changes carry the durable evidence.