Monday, 21 September 2026

AFPA (France's national adult vocational-training agency) confirms a data extraction potentially affecting up to 1.7 million people, linked to a flaw in a third-party-hosted accommodation-management tool

AFPA, France's national public adult vocational-training agency, confirmed a potential extraction of identity, address and possibly phone-number data on up to 1.7 million people after the handles xMetah and Cybernox claimed 971,420 and 1,732,811 records a day apart in mid-September 2026, figures FrenchBreaches warns must not simply be summed (Cyberattaque.org, 2026-09-19 · Clubic, 2026-09-20 · FrenchBreaches, 2026-09-19). AFPA says its first investigations found the potential extraction linked to a flaw in a third-party-hosted accommodation-management tool outside its own information system, a link it words cautiously, and it has neither confirmed the insecure direct object reference Cybernox describes nor established whether both datasets come from one environment (Clubic, 2026-09-20 · Cyberattaque.org, 2026-09-19). It is relevant as a European public agency exposed through a vendor-hosted administrative tool.

REF9334/KREMLIN forges Chromium's own Secure Preferences integrity hashes to silently install a banking-fraud browser extension outside the Web Store, resolving C2 through an Ethereum smart contract

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.

A conference-targeted phishing chain installs a rogue root CA generated fresh on every host, plus a hosts-file/firewall local proxy able to fake clean VirusTotal results and to mint trusted certificates for any domain, surviving reboot

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 · Huntress Labs, 2026-09-15). The sidebar runs client-side with no OAuth consent prompt, and merely opening the document while signed in, with no click or download, was enough for it to 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 API (Huntress Labs, 2026-09-15). A fake "decryption failure" overlay then delivered OS-specific ClickFix instructions, each offering a choice between pasting a command or downloading a file manually (Huntress Labs, 2026-09-15). On macOS, the pasted command launched a piped zsh chain that never delivered a payload in Huntress's testing, because the fetched URL looped through redirects. The manual download led to a disk image bundling its own Gatekeeper-bypass instructions and password prompt, which 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 (Huntress Labs, 2026-08-19 · Huntress Labs, 2026-09-15). On Windows, one path launched an encoded PowerShell command that fetched a loader, which pulled down three further payloads that were offline by the time Huntress looked but already on VirusTotal (Huntress Labs, 2026-09-15). The other told the victim to update a "Google API Connector", an application signed with a certificate belonging to a small Norwegian company (stolen or fraudulently issued) and deployed through Microsoft's ClickOnce feature, the first of three abused code-signing certificates in the campaign (Huntress Labs, 2026-08-19 · Huntress Labs, 2026-09-15).

Contradiction: Huntress's two pieces assign the Windows paths differently. The 2026-08-19 write-up says the update button launches the ClickOnce installer and the manual path shows ClickFix-style instructions with an encrypted PowerShell script (Huntress Labs, 2026-08-19). The 2026-09-15 recap assigns ClickOnce to the manual download and the encoded PowerShell command to the ClickFix lure (Huntress Labs, 2026-09-15).

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). The installer's DocSend flow was a non-functional distraction: a five-screen fake onboarding carousel using genuine Dropbox marketing pages that installed nothing. Huntress reconstructed the sample's command-and-control registration protocol from its bundled @sentry/electron module and queried the live infrastructure of a sibling campaign directly (Huntress Labs, 2026-09-15), recovering three payload archives this way: NetSupport Manager, a TLS-intercepting local proxy and a Ledger-wallet implant. Each was downloaded encrypted, launched detached and hidden, then relaunched twenty seconds later with an elevation request. The first, NetSupport Manager, is a legitimate remote-monitoring tool reconfigured to redirect data to attacker infrastructure and disable its own chat, connect and disconnect alerts, and it 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. Disguised as a Lenovo driver package and signed with a genuine stolen Lenovo certificate, the third abused code-signing certificate, it hollows MsBuild.exe, generates its own self-signed certificate authority presenting itself as "Google Trust Services CN=WR3", issues a www.virustotal.com leaf certificate from it, installs the CA into the system root store, adds a hosts-file entry pointing www.virustotal.com at the local machine and creates a local-proxy firewall rule (Huntress Labs, 2026-08-19). VirusTotal lookups from the host then reach a local proxy that answers over fully validating HTTPS and can block them or return fabricated results. VirusTotal was the only target Huntress observed, but the CA's private key is written to disk, so a trusted certificate can be minted for any domain at will (Huntress Labs, 2026-08-19). A Huntress researcher named crypto-wallet domains and antivirus update signals as targets the operator could intercept the same way (Huntress Labs, 2026-09-15). Because the certificate authority is regenerated per infected host, blocking a specific certificate thumbprint achieves nothing. The interception process dies at reboot, but the installed root CA, the hosts-file entry and the firewall rule persist (Huntress Labs, 2026-09-15).

Triage: a locally-installed root CA is not automatically malicious, since some legitimate enterprise MDM and TLS-inspection proxies do this deliberately. The discriminator is provenance: a root CA your own PKI or 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.

TraderTraitor (Jade Sleet) backdoors resurface on a non-cryptocurrency IT-services firm in a campaign that delivers malware through weaponized Terraform provider lockfiles, resolving C2 through a Nostr-relay dead drop

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 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. SentinelLabs cannot prove how this victim's backdoors were delivered: both were on disk by March 18, and the victim cloned a lure repository only on April 13 (SentinelOne SentinelLabs, 2026-09-18).

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 moments later, a Gatekeeper bypass. 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 a public Nostr relay-status API 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 beaconed intermittently to a separate C2 until 2026-06-01, the last beacon in SentinelLabs' collected telemetry (SentinelOne SentinelLabs, 2026-09-18).

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.

Builds on: A Swiss research lab co-publishes the DPRK actor-tracking update: two nominally-espionage…

NightEagle (APT-Q-95) pivots to Russian targets, tunnels RDP through Microsoft's own legitimate dev-tunnels service, and attempts DCSync against Active Directory

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). In most incidents, 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 could not determine how the backdoor reached the servers but 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. Payload archives staged on GitHub contain files named to mimic legitimate Adobe, 1C and TrueConf software, unrelated to the archive names (Kaspersky Securelist, 2026-09-16). 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. After obtaining an account with sufficient privileges, the group attempted DCSync, replicating the Domain-Password object from Active Directory by impersonating the domain controller (Kaspersky Securelist, 2026-09-16).

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.

Talos finds AI-generated Python wiper and mass-deployment scripts in a Qilin-affected environment, identified by step-numbered comments and consistent per-step logging

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.

Builds on: A Swiss research lab co-publishes the DPRK actor-tracking update: two nominally-espionage…

The Gentlemen's open-directory attack toolchain: mounting a victim's own VHDX backup files to pull ntds.dit and SAM offline, then chunked-rclone exfil to Wasabi

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 tried to exploit CVE-2025-24799 with a PoC and sqlmap to pull user information from the database, an unauthenticated SQL injection in GLPI's inventory endpoint fixed in GLPI 10.0.18 (GLPI, 2025-03-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) indicate to Talos the possibility that a Russian-speaking individual was involved. Talos notes that The Gentlemen is suspected to be led by individuals based in Russia, which it says further supports the connection to the group (Cisco Talos, 2026-09-17).

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.

Huntress: distinguishing malicious Volume Shadow Copy abuse (NTDS.dit theft via shadow copy, anti-recovery deletion) from routine RMM/backup housekeeping requires event correlation, not single-event alerting

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.

An independent researcher's lab test finds SAP's Security Audit Log carries no event for OS command execution via SM49/SM69 or RFC, only OS-level auditd sees the command on every path

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 auditd execve 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.