9 verified findings from 1 run · the settled record for this UTC day, in the classic brief order.
Criticality
Kind
Topic
Region
TL;DR · the day in one read
01Huntress: a fake Lenovo driver installs a working, private certificate authority into a victim's own trust store to fake 'clean' HTTPS results at will. A Huntress researcher was targeted post-conference by a fake CoinDesk executive persona over a compromised Google Doc carrying a zero-click reconnaissance sidebar, three abused stolen code-signing certificates, and (the most novel component) a payload that hollows MsBuild.exe, generates its own self-signed certificate authority impersonating Google Trust Services, installs it into the system root store, and adds a hosts-file entry plus a firewall rule so a local proxy answers HTTPS connections to any chosen domain with fabricated "clean" results and no certificate warning. →
02SentinelLabs: the same DPRK backdoors from a $292M crypto theft resurface on a victim with no crypto ties, delivered through a poisoned Terraform lockfile. SentinelLabs found the FLATROOF and ROOFDECK macOS backdoors (first documented in April 2026's USD 292 million LayerZero/KelpDAO cryptocurrency theft) on an unrelated victim: a small India-based IT-services provider with no cryptocurrency ties, compromised through a fake job-interview GitHub repository whose weaponized Terraform provider lockfile redirected terraform init to an attacker-controlled provider registry. The second-stage backdoor resolves its command-and-control address by reading an operator profile's public "website" field from the Nostr decentralized relay network. →
03Kaspersky: an APT group that abused Microsoft's own developer-tunnel feature to expose RDP outward, then chained BlueKeep into a full DCSync credential dump. Kaspersky's Global Emergency Response Team documents NightEagle (also tracked as APT-Q-95), active since at least 2023 and previously focused on Asia, now confirmed against Russian organizations. The group deploys a VIEWSTATE-injected Exchange backdoor (GhostContainer), abuses Microsoft's legitimate dev-tunnels service plus the rdp2tcp tool to expose RDP outward without opening new firewall ports, and exploits CVE-2019-0708 (BlueKeep) and CVE-2020-0688 en route to a DCSync domain-credential dump. →
04Cisco Talos maps The Gentlemen's AD attack chain, including credential theft from a mounted backup image rather than the live domain controller. Cisco Talos reconstructed a six-phase Active Directory attack chain used by an operator associated with the ransomware-as-a-service brand The Gentlemen, recovered from an exposed open directory's own command history. The chain tunnels through Chisel/Ligolo-ng, enumerates AD via RustHound/BloodHound and NetExec, exploits a public-facing GLPI SQL injection and attempts Zerologon/MS17-010 for lateral movement, then extracts ntds.dit and SAM not from the live domain controller but from a CIFS-mounted VHDX backup image, exfiltrating the results in 256MiB chunks to Wasabi cloud storage via rclone. →
AFPA (Agence nationale pour la formation des adultes), France's national public adult vocational-training agency, has confirmed a "potential data extraction" after two criminal-forum claims surfaced within 24 hours of each other in mid-September 2026 (Clubic, 2026-09-20). The handle xMetah first offered 971,420 records for sale on 2026-09-15; the following day, Cybernox (separately tracked for exposing 101 AFPA accounts a month earlier, with no established link between that exposure and this extraction) claimed 1,732,811 records via an alleged insecure direct object reference (IDOR) flaw (Cyberattaque.org, 2026-09-19). AFPA's own investigation traced the "potential extraction" to a flaw in a third-party-hosted tool it uses to manage worker accommodation, which AFPA's deputy director Pierre Prady told AFP is external to the agency's own information system, so there was "a priori" no impact on AFPA's own services. AFPA has not confirmed the IDOR mechanism Cybernox claims, and has not stated whether the two claimed datasets overlap or were extracted from the same source; FrenchBreaches states the two figures must not simply be summed to declare a combined victim count (FrenchBreaches, 2026-09-19). AFPA states the affected application held identity, address and possibly phone-number data, with no banking data or French national ID (Sécurité sociale) numbers identified so far; Cyberattaque.org's own sample review additionally found full dates of birth, internal identifiers and a "partner" field (one observed value, "LHEA," suggesting a partner-feed origin), while noting that several fields provisioned for email addresses, a second phone number or other contact details were observed empty in its samples (Cyberattaque.org, 2026-09-19); FrenchBreaches' separate, independent sample review instead found populated email addresses and nationality fields, in records spanning creation or modification dates from 2006 through 2026 (FrenchBreaches, 2026-09-19). Clubic's reporting notes AFPA has not stated whether it has notified the CNIL, despite GDPR's 72-hour breach-notification requirement.
According to AFPA, the hacked application contained people's identity and address, and possibly their phone number, but "a priori" no banking data or Social Security number. (translated from French)
This tool 'is hosted by a third-party vendor and is external to our information system, so there was, a priori, no impact on AFPA's own services and information systems.' (translated from French)
Clubic
AFPA now confirms that a data extraction potentially took place and states that the incident could affect up to 1.7 million people. (translated from French)
A Huntress researcher was targeted after DEFCON by an X account impersonating a CoinDesk marketing executive, who sent a legitimate Google Doc carrying a custom Google Apps Script sidebar (Huntress Labs, 2026-08-19). The sidebar runs client-side with no OAuth consent prompt; per Huntress's own recap of the incident, merely opening the document while signed in, no click, no download; was enough for it to silently report the viewer's public IP address, geolocation, browser, and whether a MetaMask, Phantom, Tron or Solana wallet extension was installed, beaconing every action through the Telegram Bot API (Huntress Labs, 2026-09-15), a reconnaissance and victim-qualification step requiring no interaction at all. A fake "decryption failure" overlay then delivered OS-specific ClickFix remediation instructions, each offering a choice between pasting a clipboard command or downloading a file manually. On macOS, the pasted command launched a piped zsh chain that never actually delivered a payload in Huntress's own testing, the fetched URL looped through repeated redirects until the browser gave up, so the actor's evident intent for that path went unconfirmed; the manual-download option instead led to a disk image bundling its own Gatekeeper-bypass instructions and password prompt, and running it delivered a confirmed AMOS-family stealer harvesting browser, crypto-wallet, Telegram, Apple Notes, cookie and login-keychain data, plus a LaunchDaemon-installed backdoor capable of arbitrary remote commands and of turning the host into a SOCKS5 proxy. On Windows, pasting the ClickFix command launched an encoded PowerShell command that fetched a loader which pulled down three further payloads; by the time Huntress analyzed the kit all three had already gone offline, and their existence is known only because copies had reached VirusTotal; no certificate or further technical detail on this particular set was recoverable. Windows victims who instead chose the manual download were led down an entirely separate route: the same fake decryption-failure message told them to update a "Google API Connector," an application signed with a certificate belonging to a small Norwegian company (either stolen or fraudulently issued) that deployed via abuse of Microsoft's ClickOnce feature, the first of the three stolen code-signing certificates Huntress recovered across the whole campaign.
In a later message, the same actor sent a second document link, this time via DropBox DocSend, that routed macOS victims to another host serving the same AMOS payload and told Windows victims to install a DocSend-branded desktop installer signed with a second stolen certificate, from Discord Inc., whose signature did not validate (Huntress Labs, 2026-08-19). That installer's own DocSend flow was itself a non-functional distraction, a five-screen fake onboarding carousel using genuine Dropbox marketing pages that installed nothing. Per Huntress's own recap, the firm reconstructed the sample's own command-and-control registration protocol from its bundled @sentry/electron module and queried the live infrastructure directly (Huntress Labs, 2026-09-15), recovering three payload archives this way: Manager.zip (NetSupport Manager), Localcertificate.zip (a TLS-intercepting local proxy) and asusdriverld.zip (a Ledger-wallet implant), each downloaded encrypted, launched detached and hidden, then relaunched twenty seconds later with an elevation request. The first, NetSupport Manager (a legitimate remote-monitoring tool reconfigured to redirect data to attacker infrastructure and disable its own chat/connect/disconnect alerts) carries persistence for all three payloads: a kernel-mode keyboard-filter driver, a Windows service, a Winlogon modification and its own registered COM object (Huntress Labs, 2026-08-19). The third, the Ledger-wallet implant, reuses the second payload's disguise and technique.
The most novel component is that second payload, the TLS-intercepting local proxy itself: disguised as a Lenovo driver package and signed with a genuine stolen Lenovo certificate, the third of the three abused code-signing certificates, after the Norwegian and Discord ones, it hollows MsBuild.exe and generates its own self-signed certificate authority presenting itself as "Google Trust Services CN=WR3" plus a fabricated www.virustotal.com leaf certificate, installs that CA into the system root store, adds a hosts-file entry and a local-proxy firewall rule, and thereby locally answers HTTPS connections with fabricated "clean" results and no certificate warning for any domain the operator chooses, crypto-wallet sites, antivirus update checks, or anything else (Huntress Labs, 2026-08-19). Because the certificate authority is regenerated per infected host, blocking a specific certificate thumbprint achieves nothing. The interception process itself dies at reboot, but the installed root CA, the hosts-file entry and the firewall rule all persist across reboots untouched.
Triage: a locally-installed root CA is not automatically malicious; some legitimate enterprise MDM and TLS-inspection proxies do this deliberately. The discriminator is provenance: a root CA your own PKI/MDM inventory does not recognize as provisioned by it, especially one impersonating a well-known public CA's name, is the signal; one your MDM issued is not.
VIEW is the one worth sitting with. Opening the document while signed in, clicking nothing, and downloading nothing, was enough to report the viewer's IP address, location, browser, and whether they were running a crypto wallet extension.
It hollowed MsBuild.exe and imported only kernel32, ultimately establishing what Jon called "purpose-built and working public key infrastructure on your machine."
Because the CA was regenerated per host, blocking a single certificate thumbprint does nothing.
SentinelLabs hunted its telemetry for the FLATROOF (also known as macOS.Gaslight) and ROOFDECK macOS backdoors first disclosed in April 2026's USD 292 million LayerZero/KelpDAO cryptocurrency theft, and found an unrelated victim carrying the same implants: a small India-based IT-services provider with no cryptocurrency exposure, compromised through a single Apple Silicon MacBook belonging to a DevOps engineer (SentinelOne SentinelLabs, 2026-09-18). The lure follows DPRK's established "Contagious Interview" pattern: fake job-interview GitHub repositories themed as infrastructure-engineering coding challenges (named Northwind-IAC, novacart-interview, terraform-candidate-repo) each carry a weaponized .terraform.lock.hcl pointing to a typosquatted, attacker-controlled Terraform provider registry impersonating HashiCorp's own naming. Because Terraform treats the lockfile's declared provider source as authoritative, running terraform init against the poisoned lockfile causes Terraform itself to download and execute the attacker's provider module in place of the genuine HashiCorp one.
On the victim host, both backdoors sat dormant on disk from March 18 to March 29, 2026, then launched the moment the developer opened a specific Cursor IDE workspace: the Cursor process itself spawned both implants directly, which began beaconing to their command-and-control servers within two seconds, before FLATROOF stripped the macOS quarantine attribute from ROOFDECK and set its executable bit (a Gatekeeper bypass) moments later. FLATROOF is a Rust ARM64 backdoor supporting shell, kill, upload and stop commands, paired with a Python data-harvesting module that pulls Chrome/Brave/Firefox/Safari data, Terminal history, installed-application lists, ps aux output, system_profiler output and a raw copy of login.keychain-db, exfiltrated via a hardcoded Telegram bot. ROOFDECK is the more capable second-stage implant: on first run it queries the public api.nostr[.]watch/v1/online endpoint plus a hardcoded relay list, searches Nostr relays for an operator profile matching a configured public key, and reads that profile's "website" field as its live command-and-control URL, a decentralized dead-drop resolver that survives takedown of any single C2 domain. A third stage later replaced both original implants and kept beaconing to a separate C2 for over a month before going silent.
Triage: developers legitimately run terraform init against new or unfamiliar repositories constantly, so the command itself is not the signal; the discriminator is the lockfile's declared provider source pointing to a domain that is not registry.terraform.io or a known private registry the organization operates.
Unlike the previous high-profile victim, this target was a much smaller organization in the IT services industry.
When the victim runs terraform init with the weaponized lockfile in place, Terraform treats the custom provider as the source of truth, resulting in Terraform downloading and executing the malicious provider modules.
Upon first execution, it pulls live Nostr relays from api.nostr[.]watch/v1/online and combines them with a hardcoded relay list belonging to legitimate Nostr services, then searches the relays for an operator's profile on the Nostr network based on a public profile key given in the configuration file nostr_public_keys. When found, it reads the website field of the profile and uses that as its C2 URL.
Kaspersky's Global Emergency Response Team documents a NightEagle (also tracked as APT-Q-95) campaign, active since at least 2023 and previously focused on Asian targets, now confirmed against organizations in Russia (Kaspersky Securelist, 2026-09-16). Initial access used compromised VPN credentials, with connections originating from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from European VPS ranges. On Microsoft Exchange servers the group deploys the GhostContainer backdoor, a .NET assembly that incorporates the Neo-reGeorg tunnel, an exploit component for CVE-2020-0688, and the GhostWebShell class from the ysoserial utility; Kaspersky assesses with high confidence that delivery reused a technique it had already documented, extracting Exchange's own ASP.NET machine keys, then overwriting the VIEWSTATE framework parameter and injecting a payload into it to launch the backdoor in memory. Once running, the backdoor evades detection by patching addresses in amsi.dll and ntdll.dll, blinding both the Antimalware Scan Interface and Windows Event Logging.
For network access, NightEagle abuses Microsoft's own legitimate dev-tunnels feature (*.devtunnels.ms), a service meant to publish local developer web services to the internet, to expose port 3389 (RDP) outward on the compromised host, then layers rdp2tcp, a public RDP-virtual-channel TCP tunneling tool, inside that RDP session; a combination Kaspersky states lets the group maintain network access using legitimate services, without opening any additional suspicious port. Staged payloads on GitHub carry mismatched legitimate-sounding filenames (adobe_32.exe, 1c-office-plugin.exe, trueconf-broker.exe) to blend in with normal software update or business-communication traffic. For lateral movement and privilege escalation, NightEagle exploited CVE-2019-0708 (BlueKeep) in one incident to create and elevate a local account into the Administrators and Remote Desktop Users groups, used Impacket's atexec to set scheduled netsh portproxy rules for internal port forwarding, and requested Kerberos tickets carrying a non-standard Forwardable/Proxiable/Renewable flag combination before executing DCSync against the Domain-Password object to dump domain credentials by impersonating the domain controller.
Triage: Microsoft dev-tunnels traffic to *.devtunnels.ms is legitimate on developer workstations running Visual Studio or the Dev Tunnels CLI; the discriminator is the host class: a production server, domain controller, or non-developer endpoint establishing an outbound dev-tunnels connection has no legitimate reason to do so.
We have now identified attacks by the group targeting businesses in Russia.
This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on ..devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.
The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.
Cisco Talos recovered an exposed open directory believed to belong to an operator associated with the ransomware-as-a-service brand The Gentlemen, and reconstructed a six-phase attack chain from the directory's own shell command history (Cisco Talos, 2026-09-17). The operator first built a pivot platform using Chisel, Ligolo-ng and SSH tunnels, then ran nmap and masscan against externally exposed hosts and internal services once inside, then used NetExec to enumerate SMB shares, host information, LDAP and computer information in Active Directory; Talos assesses the operator may also have used RustHound/BloodHound-related tools (a Rust BloodHound collector) to collect domain users, groups, computers, administrative privileges and trust relationships for attack-path analysis. For initial footholds against public-facing applications, the actor ran a PoC and sqlmap against CVE-2025-24799, an unauthenticated SQL injection in GLPI's inventory endpoint (fixed in GLPI 10.0.18), and separately downloaded and ran a cPanel/WHM authentication-bypass PoC. Toward the domain controller, the command history shows attempted exploitation of CVE-2020-1472 (Zerologon) and the MS17-010 vulnerabilities alongside NTLM-relay tooling via Responder. Separately, for lateral movement once inside the network, the operator used NetExec and Impacket to attempt authentication against SMB, LDAP, RDP and WinRM across multiple hosts.
The credential-theft step is the chain's most distinctive detail: rather than dumping credentials from a live, monitored domain controller, the operator mounted a backup share over CIFS, installed libguestfs-tools, qemu-utils and nbd-client to inspect the Windows filesystem inside VHDX backup images, copied out ntds.dit, SAM and SYSTEM, and ran Impacket's secretsdump.py offline against the extracted files (Cisco Talos, 2026-09-17). The VHDX backup files themselves (not just the small credential-dump output) were compressed with zstd, split into 256MiB chunks and uploaded concurrently (up to 16 files at a time) to Wasabi cloud storage via rclone, with the operator visibly reconfiguring transfer settings mid-exfiltration to improve speed and reliability. Command and control ran on the open-source AdaptixC2 post-exploitation framework, and Russian-language script comments plus Cyrillic-keymap mistyping in the operator's own bash history (whoami, ls, ip a, clear, exit typed on a Russian keyboard layout) support Talos's existing assessment that The Gentlemen is Russian-speaking-operator-led.
Triage: legitimate backup-verification and disaster-recovery testing also mount VHDX images and inspect their contents, so the mount event alone is not the signal; the discriminator is the immediate follow-on: secretsdump.py or an equivalent credential-extraction tool run against files copied from that mount, on a host or account that has no operational reason to be doing backup verification.
Talos identified open directory infrastructure believed to have been used by a threat actor associated with The Gentlemen. During our investigation, we observed numerous tools used to support ransomware operations.
In Phase 6, involving information collection and exfiltration, the threat actor mounted a backup share via CIFS at /mnt/Backup and inspected the Windows file system within VHDX backups. The command history records the installation of libguestfs-tools, qemu-utils, and nbd-client, the creation of directories such as /mnt/vhdx, and the copying of ntds.dit, SAM, and SYSTEM. The actor then used Impacket's secretsdump.py to extract credentials and password hashes from the collected ntds.dit and SAM files, saving the results as "ntds.txt" and "SAM.txt".
Elastic Security Labs has tracked REF9334, a Brazilian-banking-focused operation, across seven campaigns since May 2025 (Elastic Security Labs, 2026-09-14). Its toolkit, KREMLIN, a name the malware's own author chose; Elastic states nothing about the operation is actually Russian: Portuguese-language lures and code comments, and Ethereum transaction timestamps its executive summary describes as clustering during São Paulo working hours, its technical analysis separately finds only a small minority of transactions falling in late-night hours, none extending into early morning, and reasons this is more consistent with operators working late than waking before dawn, corroborating rather than contradicting the same São Paulo conclusion, instead point to Brazil. KREMLIN's infection chain begins with an obfuscated, multi-stage JavaScript loader (trivially de-obfuscated by an LLM, per Elastic) that checks sandbox indicators such as desktop file count and WMI process count before decoding a second stage via certutil and downloading Node.js to run it. That second stage installs persistence disguised as a scheduled task named "MicrosoftNodeRuntimeUpdater," then queries an Ethereum smart contract for three configuration parameters: a main module URL, a .NET RunPE injector hidden as Base64-encoded JPEG data, and a legitimate SentinelOne SentinelMemoryScanner.exe binary abused for DLL sideloading, a technique Symantec first documented in a separate Seedworm intrusion. The main C++ installer resolves NTDLL syscall numbers indirectly, by correlating export names against the .pdata exception-directory RUNTIME_FUNCTION table rather than parsing Nt*/Zw* stubs directly, and runs extensive sandbox and analysis-tool checks (process-name blacklists, a hardcoded username blacklist, CPU/RAM thresholds, a deliberately-unregistered-domain network canary, and VMware/VirtualBox artifact checks) before proceeding.
The extension-installation step is the toolkit's most technically striking element, documented in detail by Synacktiv's "Phantom Extension" research and rarely seen deployed in the wild: KREMLIN waits for the browser to close, or for the user to idle for two minutes and then force-terminates it if still open, then relaunches the browser under a debugger specifically to catch the LOAD_DLL_DEBUG_EVENT for chrome.dll or msedge.dll, scans that module's memory for a string cross-reference to OSCrypt.AppBoundProvider.Decrypt.ResultCode to locate and read the in-memory App-Bound encryption key via ReadProcessMemory, and separately recovers the legacy DPAPI-protected OSCrypt key from Local State. Using the recovered keys plus a seed extracted from resources.pak, a sibling file in the Chrome installation directory, KREMLIN regenerates the legacy HMAC and the newer OSCrypt-encrypted SHA-256 hash that Chromium's Secure Preferences integrity mechanism requires, then manually copies the extension's files into the browser profile and edits Secure Preferences directly (enabling developer mode, registering the extension under extensions.settings.<id>, and writing the forged protection.macs values) installing the extension exactly as if a user had approved it through the Web Store, with no user interaction and no visible warning. Elastic disrupted over 1,500 infections by registering the operation's network-canary kill-switch domain.
Triage: extensions are routinely installed and removed through the Web Store's own mechanism, so an extension's mere presence is not the signal; the discriminator is provenance: an extension entry in Secure Preferences with no matching Web Store installation event, or extensions.settings entries whose protection.macs values were written outside a normal browser-update or user-installation flow.
Malicious browser extensions bypass Chromium integrity mechanisms by manipulating Secure Preferences and regenerating required HMACs and App-Bound encrypted hashes.
KREMLIN uses a documented technique rarely observed in malware: it manually copies the extension into the browser's profile directories and registers it in the Secure Preferences file.
Threat Command temporarily disrupted over 1,500 (and counting) infections in this reported campaign by registering the network canary (kill switch) domain
Investigating a separate, Qilin-affected environment, Cisco Talos found three Python post-exploitation scripts in the operator's own staging directory that it assesses with medium-to-high confidence were generated with AI assistance rather than hand-written: deadman.py, a time-triggered wiper deployed via Group Policy Object; veeam_kill.py, which stops, disables and destroys Veeam backup infrastructure; and deploy_locker.py, a mass-deployment launcher for the ransomware payload itself (Cisco Talos, 2026-09-17). Talos's basis for the AI-generation call is stylistic rather than a direct admission or watermark: veeam_kill.py's main() function divides execution into four numbered stages, each carrying a comment and a progress-log line held to a uniform level of detail, and deadman.py's do_gpo function shows the same evenly-commented, staged structure, a pattern Talos found consistent across the scripts and consistent with specification-style docstrings rather than typical hand-written incident-response or red-team tooling. The operator's own bash history additionally references a local tool named llm_chatbot, which Talos cites as corroborating evidence for AI involvement in the scripting workflow.
Talos identified several characteristics in Python scripts found in an open directory used by Qilin that suggest, with medium-to-high confidence, that scripts may have been generated using AI
Figure 17 shows an excerpt from "veeam_kill.py", a Python script designed to stop, disable, and destroy Veeam backups. As shown in Figures 17 and 18, the main() function clearly divides the overall process into four stages, labeled "Step 1" through "Step 4," with comments and progress logs provided at a consistent level of detail for each step.
Huntress lays out three distinct classes of Volume Shadow Copy Service (VSS) abuse it detects, and the correlation logic each requires to separate it from benign RMM- and backup-agent housekeeping that performs the identical raw create/delete API calls constantly (Huntress Labs, 2026-09-14). The first and most familiar class, MITRE ATT&CK's Inhibit System Recovery, is pre-ransomware shadow-copy deletion, most commonly via vssadmin.exe but achievable through several other services and binaries, so a detection that anchors only on the vssadmin.exe process image misses variants. The second, less commonly discussed class is credential access by proxy: rather than running credential-dumping tools live against a monitored host, an attacker creates a shadow copy specifically in order to pull the NTDS.dit Active Directory database out of the static snapshot, a materially quieter path than direct extraction. The third class is shadow-copy size or configuration manipulation as ancillary tradecraft.
Huntress's own detection logic fires on the raw VSS event plus its surrounding context rather than the event in isolation: for deletions, it inspects how the deletion occurred, accounting for the non-vssadmin paths; for creations, it looks for pairing with lateral-movement indicators and credential-harvesting commands appearing before or after the VSS event within a correlation window, rather than judging the creation alone. A worked incident illustrates the method: PsExec spawned a SYSTEM-level shell on a domain controller, the operator enumerated active RDP sessions, ran vssadmin create shadow (the NTDS.dit-theft pattern) then, a few minutes later, attempted to delete the shadow copies to cover their tracks, an attempt endpoint antivirus blocked and flagged, while DNS enumeration against at least one additional host appeared in the same window. Huntress states no single step in that sequence would have justified escalating alone; the lateral-movement-then-VSS-creation-then-credential-harvesting-attempt correlation is what does.
Triage: a shadow copy being created or deleted is one of the most common legitimate Windows operations (routine RMM tooling and backup agents do it constantly) so the raw event carries almost no signal by itself. The discriminator is context: lateral-movement activity and credential-harvesting-adjacent commands appearing in the same time window as the VSS event is what separates an attacker's shadow-copy abuse from a backup agent's routine housekeeping.
Rather than running credential-dumping tools directly against a live, monitored system, an attacker can spin up a shadow copy and quietly pull the NTDS.dit file (the Active Directory database) out of it.
PsExec was used to spawn SYSTEM-level command shell processes on a domain controller. From there, the attacker enumerated active Remote Desktop sessions, then ran vssadmin create shadow, a technique commonly used to pull credentials out of the NTDS.dit database without touching it directly. A few minutes later, the attacker tried to cover their tracks by deleting the shadow copies they'd just created; that attempt was blocked and flagged by endpoint antivirus.
An independent researcher, publishing on Detect FYI / Medium and syndicated in full via malware.news, demonstrates on a self-owned SAP NetWeaver AS ABAP 7.52 lab that SAP's Security Audit Log (SAL) carries no event type or field for OS-level "external command" execution launched via transactions SM49/SM69 or over RFC, a structural gap in the log's schema, not a misconfiguration that can be turned on (Detect FYI, 2026-09-20). External commands run through the sapxpg helper process as the <sid>adm OS-owner account, and the researcher found that most Linux-applicable SAP-delivered command definitions accept additional runtime parameters, so the binary actually executed at runtime can differ entirely from the one an administrator defined; demonstrated by using a find-with--exec command definition to run /usr/bin/id instead of its intended target. On the interactive SM49 path, the SAL records only a generic "Transaction SM49 started" event, with no command, binary or parameter data, even with every audit class enabled. On the RFC path, the SAL at best records an "RFC call" event naming only the invoked function module (SXPG_COMMAND_EXECUTE), never the command or its arguments. Only the background-job path (SM36) records the full command and its output, and it does so in the job log rather than the Security Audit Log.
OS-level auditd is the only source that sees the full argument vector on every path, via the sapxpg parent-process chain (SAP work process → sapxpg → target binary), but the researcher flags three practical failure modes: the -a task,never audit rule, which some SUSE/SLES builds ship active and others omit entirely, silently suppresses execve auditing for new tasks; runtime auditctl changes do not survive reboot unless persisted under /etc/audit/rules.d/; and a bare execve rule is noisy unless filtered on a ParentImage ending in sapxpg, since that name matches both the SAP work-process binary and the SAP Host Agent's own sapxpg (the latter running as root). Because the SAL always knows the SAP user but never the command, and auditd always knows the command but only the OS account, the researcher recommends bridging the two by time-correlating the SAL's SAP-user timestamp (or, on the background path, simply reading the self-sufficient job log) against the auditdexecve record within a tight window to reconstruct the full "this SAP user ran this OS command as <sid>adm" statement.
Triage: a sapxpg child process running a benign, expected command is routine SAP operation and not itself a signal. The researcher's recommended discriminator is content-based: a high-severity alert on any sapxpg-child command line carrying injection gadgets (-exec, an interpreter invocation, shell metacharacters) versus a lower-severity baseline rule matching any sapxpg child regardless of content, to establish what normal looks like in a given environment before tuning the higher-severity rule.
The only trace is a generic “Transaction SM49 started.” There is no event for the command, the binary, the parameters, the -exec payload, or the npladm context. A SIEM ingesting this log sees "a user opened SM49" and nothing more.
auditd tells you what ran but not which SAP user triggered it (every SAP-spawned command is uid=<sid>adm), while the SAL knows the SAP user but not the command.
2026-09-21T0410Z-intel· Sonnet 5 · window 24 h · 9 entries published
Verification loop closed at the 8-iteration cap (fail-open). Iteration 8 returned NEEDS_FIXES
(truth: 2, editorial: 1, advisory: 0); all three findings were remediated as recorded above and
tools/check_run.py reconfirmed 49 pass · 1 warn (the run's own runaway-duration telemetry fact,
non-fixable, disclosed above) · 0 fail immediately afterward. Per the loop's cap-with-fail-open rule,
no iteration 9 was spawned; this run publishes on the cap rather than on a confirmed double-CLEAN.
verification_residual_count (3) reflects iteration 8's own truth+editorial sum, not zero, the fixes
above are believed correct but were not re-verified by a fresh cold pass before publish, which is what
publishing on fail-open rather than double-CLEAN means in practice.
Verification & coverage notes
Runaway threshold exceeded (duration_seconds=12313, ~3.4h; check_run.py WARN). Cause: the verification loop ran the full 8-iteration cap, each iteration catching genuine, previously-unnoticed defects, several introduced by the prior iteration's own remediation (the conference-phishing entry's macOS payload-attribution swap, caught in iteration 5 after the document/certificate/payload structure was fixed across iterations 1-3; the Gentlemen entry's NetExec/RustHound scope error, introduced by iteration 6's own hedge-restoration fix and caught by iteration 7). No single iteration stalled past its 30-minute per-role cap; the cumulative wall-clock cost is the number of genuine correction rounds this run's initial composition needed, not a stalled sub-agent. The loop closed on the cap (fail-open) rather than a confirmed double-CLEAN; see the note at the end of the verification.iterations block. This is a run-caused, non-fixable-by-editing telemetry fact (elapsed time already happened) rather than a defect in any published entry; left for the quality audit to acknowledge per the zero-warning-discipline carve-out for a run's own telemetry facts.
Window: Standard class, gap_hours ≈ 15.0 (previous run 2026-09-20T1308Z-audit, started 2026-09-20T13:08:12Z), no catch-up/major-gap disclosure needed. Mechanical KEV sweep (tools/kev_window_diff.py) found zero CISA KEV additions in the window, independently corroborated by S1's own exhaustive sweep.
Coverage-backlog work (Phase 0 step 5b), six research items and one incident resolved. Yesterday's audit (2026-09-20T1308Z-audit) fully researched six PD-11(d) tradecraft items and one confirmed AFPA incident but hit its wall-clock cut before composing them. This run re-verified all seven live (fresh WebFetch of every primary, evidence quotes re-confirmed verbatim) and published them:
2026-09-21/the-gentlemen-open-directory-vhdx-backup-ntds-theft and 2026-09-21/qilin-ai-generated-wiper-locker-scripts-forensic-markers, split from the single Talos backlog row per the item-granularity rule (distinct actor, distinct victim environment within one primary source).
2026-09-21/afpa-third-party-accommodation-tool-data-extraction, this resolved TWO open backlog rows at once: the 2026-09-20-surfaced "AFPA confirmed" row and the 2026-09-16-surfaced row on the two competing xMetah/Cybernox criminal claims were treated as the same underlying event. AFPA's own AFP-quoted statement names "two hackers" claiming data "mercredi et jeudi" (Wednesday/Thursday); the verifier's iteration-1 pass flagged that Wednesday/Thursday falls on 2026-09-16/17, one day later than xMetah's own 2026-09-15 claim date (Cybernox's 2026-09-16 claim does land on the Wednesday). The published entry itself does not assert an exact day-of-week match (it says only that the two claims surfaced "within 24 hours of each other") so this is a same-incident judgment resting on the shared third-party tool, the 24-hour claim spacing and AFPA's own two-hackers framing, not on an exact calendar match; noted here rather than corrected as a published-entry defect, since the entry's own wording already avoids the overclaim.
One further backlog item, an independent researcher's SAP SM49/SM69 Security Audit Log blind-spot write-up surfaced fresh by this run's own S3 sweep (not a carried-forward row), published as 2026-09-21/sap-sm49-sm69-external-command-execution-blind-spot at reduced reliability (Admiralty F, no track record) given its single-blogger provenance, reached only via a syndication mirror after the true primary (detect.fyi) 403'd on every transport.
Verification catches during Phase 4 composition (main-agent deep-read, all fixed before publish):
CVE mislabeling in the Talos primary itself. Talos's tool-inventory paragraph names "exploit code targeting CVE-2025-2479, a SQL injection vulnerability", that CVE resolves on MITRE's CVE API to an unrelated WordPress plugin reflected-XSS flaw. The article's own Phase 3 narrative separately and correctly describes exploiting CVE-2025-24799 (GLPI unauthenticated SQLi, confirmed via the CNA record). Per PD-12 (the per-CVE authority wins over blog prose), the Gentlemen entry cites CVE-2025-24799 only and omits the mislabeled id entirely.
Two revoked ATT&CK ids in sub-agent-proposed mappings, caught against the pinned attack/enterprise-attack.json (v19.2) before publish: T1562.006 (NightEagle's AMSI/Event-Log tampering) → replaced with its survivor T1685; T1574.002 (REF9334/KREMLIN's DLL sideload) → replaced with its survivor T1574.001.
An ellipsis-spliced quote in the VSS-abuse findings (two sentences joined across an omitted middle clause) was caught by literal grep -F verification against the saved primary and replaced with the full, unspliced contiguous quote.
A DCSync id (T1003.006) misapplied to the Gentlemen entry: the Gentlemen chain extracts ntds.dit/SAM offline from a mounted VHDX backup, not via live DCSync (that is NightEagle's technique, correctly mapped there); corrected to T1003.002/T1003.003.
Registry hygiene: actor:jade-sleet's aliases (TraderTraitor, UNC4899, PUKCHONG) added per the SentinelLabs source's own alias statement; actor:cybernox's summary extended to note the AFPA financially-motivated episode alongside its earlier hacktivist framing.
Borderline drops:
borderline-drop: LMU Munich student enrollment-data breach — German state university, no Swiss home-region or primary-sector nexus, no global significance, no named TTP or actor plausibly targeting the profiled constituency; the breach-notification-timeliness angle is a general lesson, not a PD-11 breach-gate (a)-(d) clearance. (S2's finding; genuinely well-sourced but out of scope for this constituency.)
borderline-drop: Swiss Federal Council "Verordnung über die militärische Cyberabwehr" (MCAV) lead — S2 investigated a kleinreport.ch story with a genuinely in-window timestamp, but the linked admin.ch press release 404s and the linked PDF is the original 2019 explanatory report; single Admiralty-C source with unresolved novelty ambiguity, dropped per PD-1/PD-6 rather than risk a fabricated-novelty claim.
borderline-drop: Qilin leak-site claim against Touring Club Suisse (TCS) — bare leak-site listing only, no victim statement, no Admiralty A/B journalism despite a targeted multilingual search; fails PD-6 as it stands. Added as a new Open row on state/coverage_backlog.md (strong, fresh Swiss home-region nexus if corroborated) rather than dropped outright.
Single-source items (all verification: single-source, no national-CERT/victim carve-out applicable; each entry's own sourcing_note carries the detail): 2026-09-21/the-gentlemen-open-directory-vhdx-backup-ntds-theft, 2026-09-21/qilin-ai-generated-wiper-locker-scripts-forensic-markers, 2026-09-21/nighteagle-apt-q-95-ghostcontainer-devtunnels-rdp2tcp-dcsync, 2026-09-21/tradertraitor-terraform-lockfile-nostr-dead-drop, 2026-09-21/huntress-vss-abuse-detection-correlation-ntds-shadow-copy, 2026-09-21/conference-phishing-rogue-root-ca-mitm-persistence, 2026-09-21/ref9334-kremlin-chromium-secure-preferences-hmac-forge, 2026-09-21/sap-sm49-sm69-external-command-execution-blind-spot. 2026-09-21/afpa-third-party-accommodation-tool-data-extraction is multi-source, Clubic's AFP-quoted victim statement plus Cyberattaque.org/FrenchBreaches independently paraphrasing AFPA's own confirmation (not merely relaying the criminals' figures).
Deep-dive: none selected this run. No candidate met deep-dive selection criterion 1 (active in-the-wild exploitation with non-trivial exposure) or 2; several research pieces (Gentlemen, TraderTraitor, the rogue-CA phishing chain, REF9334/KREMLIN) would satisfy criterion 3 on technical depth alone, but none is clearly the single strongest pick over the others, and the closest category fits (supply-chain, apt-campaign) were both used within the prior 7 days per the rotation check, demoted rather than manufactured.
Correction to this run's own iteration-1 note: the notes previously flagged actor:gentlemen-raas-gentlekiller as an apparent unmerged duplicate of actor:thegentlemen. The verifier's iteration-2 pass caught this as wrong: the record already carries merged_into: "actor:thegentlemen", added three weeks earlier (2026-08-31T0411Z-intel); it was correctly tombstoned all along, and the main agent's own registry read simply stopped one line short of that field. No registry action needed; retracting the flag.
Coverage gaps: keycloak (dead RSS path); trustwave-spiderlabs/LevelBlue (dead feed path post-rebrand); flatt-security, mozilla-mfsa, edpb, netcraft (JS-rendered listings the current recipe can't see); ncc-research (redirects to a generic page); ic3.gov/fbi-cyber-alerts (/PSA resolves to a complaint-filing T&C page, not a PSA index; this has now recurred across multiple runs and may warrant a dedicated recipe review); cisa-advisories/cisa-directives listing pages (render as filter-form/nav shells with no visible per-item dates; cross-checked via the CISA KEV catalog instead, which stayed current); socradar (the plain bridge url subcommand returns a JS-empty shell; the jina reader recovered the real dated listing this run; recommend the source record require jina rather than plain url); franceinfo.fr and afpa.fr (403 / no dedicated press notice, AFPA's confirmation composed from Clubic's direct AFP quotation instead).
Essential-coverage: all essential-tier sources in S1's and S2's domains were attempted this run; no miss to disclose.