DEV Community: Anoymask

PAN-OS CVE-2026-0322: Authenticated Code Injection in Management Interface Leads to Root Privileges

Anoymask — Fri, 16 Oct 2026 10:05:39 +0000

1. Basic Information

Report Title: CVE-2026-0322 PAN-OS: Authenticated Remote Code Execution (RCE) in the Management Interface
Publisher: Palo Alto Networks
Publication Date: 2026-10-14
Update Date: 2026-10-15
Original Source: Palo Alto Networks
Related Source: SecurityWeek: Palo Alto Networks Patches Exploited Firewall Vulnerability
Related Malware: None
Related Threat Actor: None
Related CVE: CVE-2026-0322
Related Products: PAN-OS on PA-Series, PAN-OS on VM-Series, Panorama virtual / M-Series
Severity: Critical

The official CVSS score is 8.6 HIGH. However, exploitation leads to root privileges on the firewall or Panorama management interface, and active exploitation has been confirmed. Public-facing management interfaces must be restricted immediately, and branch-specific fixed versions must be applied.

2. Executive Summary

A code injection vulnerability in the PAN-OS management interface allows remote code execution with root privileges, requiring network reachability and authentication with high privileges (PR:H) based on the official CVSS. Palo Alto Networks has disclosed very limited active exploitation and three related IPs.

3. Attack Flow

Path 1: Exploitation Conditions from Public Information

An attacker reaches the PAN-OS management interface over the network.
The attacker exploits vulnerable input processing in the management interface while authenticated with high privileges. The official CVSS specifies PR:H, but details regarding how authentication is obtained and individual roles remain unpublished.
Successful exploitation allows the execution of arbitrary code with root privileges on the firewall.
Subsequent actions in individual attacks have not been disclosed; therefore, the impact on configurations, credentials, and traffic must be determined via internal telemetry.

4. Attacker Positioning and Execution Location

An attacker who reaches the management interface over the network and possesses the high-privilege authentication required for exploitation. The required privilege level is PR:H per the official CVSS.

5. Visibility for Victims and Administrators

Victims and Users: Ordinary users may not observe any noticeable changes.
Administrators: May observe management logins from unknown sources, abnormal requests, unusual processes, configuration changes, or outbound traffic originating from the firewall itself.

6. Success and Failure Conditions

Success Conditions

Running a vulnerable PAN-OS version.
Network reachability to the management interface and possession of authentication classified as high privileges (PR:H) in the official CVSS.

Failure Conditions and Mitigations

Update to the official fixed version. There are no known workarounds.
Restrict access to the management interface to trusted internal IP addresses or a jump box.

7. Impact of Successful Exploitation

Arbitrary code is executed with root privileges on the firewall or Panorama.
Inference: Root privileges could severely impact security policies, configurations, credentials, and traffic visibility. Subsequent operations for individual incidents have not been publicly disclosed.

8. Observable Logs

The following are candidates for investigation within your organization. Availability depends on products, permissions, log settings, and retention periods. The absence of records does not prove an environment is uncompromised.

Email: No email vectors specific to this issue have been identified.
Proxy / SWG / DNS: Inference: Check for requests originating from published IPs or unknown sources targeting the management interface.
Endpoint / EDR: Inference: Check PAN-OS system logs, process and crash information, unknown files, and traces of root execution.
Identity / IdP: Inference: Check management logins, MFA, jump servers, VPNs, and service account usage.
SaaS / Cloud: Inference: Check operation history for Panorama, the support portal, and configuration backups.
Network: Inference: Check for communication with 66.42.72.14, 208.83.239.114, and 149.248.47.234, as well as abnormal outbound traffic originating from the firewall.

9. Determining Attack Success

Confirmed in Public Information

Palo Alto Networks has reported very limited active exploitation. Root commands and subsequent actions for individual incidents have not been publicly disclosed.

Internal Assessment Criteria

Initial Execution Confirmed: Assessment criterion: This stage is determined if evidence supports code execution following the exploitation of the management interface within your organization. While public information indicates vendor reports of very limited exploitation, evidence of root commands or subsequent operations in individual incidents has not been disclosed. Scope: Internal assessment criteria, distinct from the exploitation scope published by the vendor.

Separate contact, execution, persistence, data collection, and exfiltration; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Focus on vulnerable versions, publicly exposed management interfaces, published IPs, and unknown management logins.
Initial Verification: Check the model, PAN-OS branch, hotfixes, management interface exposure scope, and authenticated users.
Endpoint / Server Investigation: Preserve system logs, configuration diffs, process and crash data, and unknown files.
Identity / Cloud Investigation: Review usage history for management accounts, MFA, VPNs, jump servers, and API keys.
Subsequent Operations: Track policy changes, credential access, internal reconnaissance, and outbound traffic.
Containment: Restrict the management interface, update to a fixed version after preserving evidence, and rotate management credentials and keys.
Categorization: Separate reachability, authentication, exploit attempts, root execution, configuration changes, and subsequent communication.

11. Defense and Detection Ideas

Single Event: Prioritize management access and abnormal management requests originating from published IPs.
Timeline Correlation: Correlate management logins -> abnormal requests -> root processes -> configuration changes or outbound traffic.
Threat Hunting: Inventory the versions and management interface exposure status for all PA-Series, VM-Series, and Panorama instances.
Log Limitations: Logs within the appliance may become untrustworthy after root compromise; external syslog and network records are required.
Priority Mitigations: Apply fixed versions, restrict management interfaces to trusted networks, enforce MFA, and configure external log forwarding.

12. Facts, Inference, and Hypothesis

Facts

CVE-2026-0322 is a code injection vulnerability in the PAN-OS management interface with a CVSS score of 8.6 and CWE-94.
Exploitation requires network reachability to the management interface and high-privilege authentication (official CVSS PR:H), allowing arbitrary code execution with root privileges upon exploitation.
PA-Series, VM-Series, and Panorama virtual / M-Series are affected; Cloud NGFW and Prisma Access are not affected.
Palo Alto Networks confirmed very limited active exploitation.
Related IPs published are 66.42.72.14, 208.83.239.114, and 149.248.47.234.
Fixed versions include 12.2.4, 12.1.4-h12 / 12.1.7-h8 / 12.1.10-h2, 11.2.4-h22 / 11.2.7-h21 / 11.2.10-h15 / 11.2.13-h3 / 11.2.16, and designated hotfixes for the 11.1 and 10.2 branches.
There are no known workarounds. Threat IDs 510046 and 510047 provide limited protection under specific decryption and routing conditions, but do not replace updates.

Inference

Because high-privilege authentication is required, management credentials and access paths must be verified. Public information does not disclose how credentials were obtained or the individual intrusion vectors used.

Hypothesis

No additional hypotheses. Unconfirmed items are noted in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1078	Valid Accounts	medium	Exploitation requires authentication, but it remains unpublished whether legitimate credentials were used in actual attacks. Source
T1190	Exploit Public-Facing Application	high	Exploits a vulnerability in a network-reachable management interface. Source

14. Unknowns and Additional Investigation

The threat actor, number of victims, method of obtaining credentials, executed commands, and the presence of persistence or data access have not been publicly disclosed.

15. Impact on SOCs and Organizations

Even if authentication is required, an attacker with high-privilege authentication in the management plane can exploit this vulnerability to execute code as root. Therefore, both authentication and access restrictions must be maintained. Organizations exposing management interfaces should prioritize updates, correlate authentication, configuration changes, and execution artifacts in external logs, and judge update completion separately from compromise investigations.

16. Summary by Role

For SOCs: Check for published IPs, management logins, code execution, configuration changes, and outbound traffic originating from the firewall.
For Administrators: Restrict management interfaces to trusted IPs or jump boxes, and immediately update the running branch to the official fixed version.
For Users: No user action is required. Follow any instructions regarding VPNs or credential changes provided by administrators.

skynox7: D-Link, Ubiquiti, and SAP Devices Repurposed into Pawns.app Residential Proxies

Anoymask — Fri, 16 Oct 2026 10:05:31 +0000

1. Basic Information

Article Name: skynox7: Proxyjacking Edge Devices Into Residential Proxies
Source: GreyNoise
Published Date: 2026-10-15
Updated Date: None
Original: GreyNoise
Related Sources: BleepingComputer: Hackers hijack D-Link, Ubiquiti devices to resell stolen bandwidth, Ubiquiti: Security Advisory Bulletin 023
Related Malware: None
Related Threat Actor: skynox7
Related CVEs: CVE-2024-3272, CVE-2024-3273, CVE-2021-44228, CVE-2025-31324
Related Products: D-Link ShareCenter NAS, Ubiquiti UniFi Video NVR, SAP NetWeaver Visual Composer, Hikvision and Dahua DVR/NVR, Pawns.app
Severity: Critical

Compromises installing Pawns.app without the owners' consent have been confirmed in 34 countries. In addition to unauthorized bandwidth usage, some devices were left with SSH keys for re-access. The mere attribute of a residential proxy does not distinguish between legitimate and unauthorized traffic.

2. In Brief

Threat actor skynox7 invaded edge devices using known vulnerabilities, installed the Pawns.app client, and resold the victims' network connections as paid residential proxies. GreyNoise identified at least 143 devices across 34 countries, with SSH public keys added to some of them.

3. Attack Flow

Path 1: Confirmed Proxyjacking Path

The attacker scans for public edge devices and exploits product-specific known CVEs.
The Pawns.app client is downloaded and executed on the device.
The client is linked to skynox7's payout account, providing the victim's network connection as a residential proxy.
SSH public keys are added to some devices to leave a re-access path even after Pawns.app is stopped.

4. Attacker Position and Execution Location

A remote attacker reaching public interfaces such as NAS, NVR, and SAP NetWeaver from the internet.

5. Victim and Administrator Perspective

Victims and Users: May experience reduced internet speed or IP blocks from external services.
Administrators: May observe unknown processes, added SSH keys, long-term outbound TLS connections, abuse notifications, and suspicious authentication from the same IP.

6. Success and Failure Conditions

Success Conditions

Vulnerable or end-of-life (EOL) edge devices are exposed to the internet.
Outbound communication and execution of Pawns.app are permitted.

Failure Conditions and Countermeasures

Patch the target CVEs, replace EOL devices, and restrict management interfaces to VPNs or trusted networks.
For the UniFi Network application, Bulletin 023 confirms that the issue was fixed in version 6.5.54 and later. Do not apply this fix level to UniFi Video NVRs; compare the actually running application with the corresponding fixed version.
Use application allowlists and outbound traffic controls to block unauthorized proxy clients.

7. What Happens Upon Success

Victim IPs and bandwidth are used to relay third-party traffic.
This leads to a degraded corporate IP reputation, handling abuse notifications, and re-compromise through additional SSH persistence.

8. Observable Logs

The following are candidates for investigation within your organization. Availability depends on products, permissions, log settings, and retention periods, and the absence of records does not prove a lack of compromise.

Email: No email vectors specific to this incident have been confirmed.
Proxy / SWG / DNS: Inference: Identify Pawns.app-related domains, unknown proxy services, and continuous outbound connections.
Endpoint / EDR: Inference: Identify unknown binaries on edge devices, autostart configurations, and changes to SSH authorized_keys.
Identity / IdP: Inference: Detect authentications to multiple accounts from the same residential proxy IP combined with device mismatches.
SaaS / Cloud: Inference: Review SAP NetWeaver management, upload logs, and change history.
Network: Inference: Observe exploit requests from 209.99.190.80, unusual bulk relay traffic, and long-duration sessions to multiple destinations.

9. Assessing Attack Success

Confirmed in Public Information

Subsequent Compromise Confirmed: Public information: GreyNoise confirmed the installation of Pawns.app, proxy operation, and the addition of some SSH keys on real devices. Scope: Activity confirmed by GreyNoise

Separate contact, execution, persistence, information acquisition, and external transmission; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Target CVEs, Pawns.app, 209.99.190.80, and unknown SSH keys.
Initial Verification: Check device models, firmware, exposure scope, outbound traffic, and management access.
Endpoint / Server Investigation: Preserve the file system, processes, autostart settings, authorized_keys, and firmware images.
Authentication / Cloud Investigation: Compare device management accounts with internal SaaS authentications originating from the proxy IP.
Subsequent Operations: Track Pawns.app traffic, SSH re-access, internal reconnaissance, and deployment to other devices.
Containment: Stop public exposure, isolate the network, reinstall firmware or replace devices, and rotate credentials and SSH keys.
Decision Categories: Separate scanning, exploitation, client installation, proxy operation, and SSH persistence.

11. Defense and Detection Ideas

Single Event: Inference: Treat unauthorized Pawns.app execution or authorized_keys modifications as investigation candidates. Do not infer compromise solely from legitimate consensual Pawns.app installations or residential proxy IPs.
Timeline Correlation: Correlate exploit requests -> binary download -> long-duration outbound traffic -> SSH key addition.
Threat Hunting: Search for all edge devices possessing target CVEs and traffic destined for residential proxies.
Log Limitations: Because many edge devices lack process and file auditing, network telemetry and configuration diffs are critical.
Priority Countermeasures: Prioritize patching, replacing EOL devices, making management interfaces private, operating outbound traffic allowlists, and managing SSH keys.

12. Facts / Inference / Hypothesis

Facts

GreyNoise confirmed activity where at least 143 edge devices in 34 countries were converted into Pawns.app residential proxies.
GreyNoise reported the exploitation of CVE-2024-3272/3273 in D-Link ShareCenter, CVE-2021-44228 on devices designated as Ubiquiti UniFi Video NVRs, and CVE-2025-31324 in SAP NetWeaver Visual Composer as attack paths. Product names and version matches must be verified against physical devices and vendor information.
Ubiquiti Security Advisory Bulletin 023 states for Log4j CVE-2021-44228 that the affected product is the UniFi Network application, affected versions are 6.5.53 and earlier, and the fix is version 6.5.54 and later.
Hikvision and Dahua DVRs/NVRs were also targeted, but specific intrusion vulnerabilities have not been identified.
Following compromise, the Pawns.app client is launched under the attacker's monetization account to sell the victim's bandwidth and IP reputation.
SSH public keys for re-access were added to some devices.
GreyNoise disclosed the attacking IP 209.99.190.80 and the payout account skynox7@proton.me.
GreyNoise does not classify the Pawns.app binary itself as malicious, distinguishing whether it is installed without the owner's consent.

Inference

When authentications to multiple corporate accounts originate from the same residential proxy IP, it may indicate proxy usage rather than user travel.

Hypothesis

No additional hypotheses. Unconfirmed items are documented in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Invades public edge devices using multiple known CVEs. Source
T1090	Proxy	high	Deploys Pawns.app and operates as a residential proxy node. Source
T1098.004	Account Manipulation: SSH Authorized Keys	high	SSH public keys were added to some devices. Source

14. Unknowns and Additional Investigation

The total number of compromised devices, initial intrusion methods for Hikvision/Dahua, contents of relayed third-party traffic, and additional lateral movement from compromised devices remain unknown.
The correspondence between GreyNoise's "UniFi Video NVR" designation and Ubiquiti's official target, the UniFi Network application, is unconfirmed. The application name and version actually running on the observed devices, as well as the basis for identifying the exploited target, are required.

15. Impact on SOCs and Organizations

Residential IPs and normal location information do not guarantee that a communication entity is trustworthy. On the other hand, merely detecting Pawns.app or residential proxy IP addresses does not confirm a compromise; assessments must combine vulnerabilities in public devices, authorization of installations, changes to SSH keys and processes, and discrepancies in authentication devices.

16. Summary by Role

For SOCs: Correlate requests for known CVEs, Pawns.app processes, SSH authorized_keys modifications, and unusually long outbound communications.
For Administrators: Isolate and update EOL devices, close public management interfaces, and remove Pawns.app along with unknown SSH keys.
For Users: This is a device-side compromise requiring no user interaction. Pay attention to communication delays or connection change notices from administrators.

CikaBika: Rust RAT Uses Discord C2; UAC Bypass and Edge DLL Placement Are Attempted

Anoymask — Fri, 16 Oct 2026 10:05:26 +0000

1. Basic Information

Article Title: CikaBika Bot: Inside a Discord RAT
Source: Darktrace
Publication Date: 2026-10-14
Updated: None
Original: Darktrace
Related Source: SecurityWeek: CikaBika RAT Uses Discord for Command and Control
Related Malware: CikaBika
Related Threat Group: None
Related CVE: None
Related Products: Windows, Microsoft Edge, Discord, ngrok
Severity: High

In addition to a path where an LNK file disguised as a document uses a Nim loader to load a Rust-based RAT, it attempts UAC bypass and DLL dropping into Edge. While successful loading by Edge remains unconfirmed, Discord C2 and data exfiltration via ngrok have been observed.

2. Executive Summary

CikaBika launches PowerShell and a Nim loader from an LNK file inside an IMG, featuring routines to directly load a Rust DLL as well as attempts at UAC bypass and DLL dropping into Edge. Darktrace observed operations via Discord and ZIP file transmission using ngrok. DLL loading by Edge is unconfirmed.

3. Attack Flow

Common loader processing, parallel Edge dropping attempts, and post-RAT-launch behavior are separated below.

Step / Path	Actor / Technique	Prerequisites	Confirmation Scope in Public Information
Common processing and direct Nim loading	LNK -> PowerShell -> Nim loader launches Rust DLL via `loadLib` (or `regsvr32.exe` on failure)	User opens the LNK inside the IMG	Implementation confirmed via sample analysis
Parallel UAC bypass and Edge dropping attempt	Deployment PowerShell attempts to drop `dbghelp.dll` into the Edge directory using `ms-settings` and `computerdefaults.exe`	Windows configuration enabling UAC bypass and write access to protected directories	Dropping logic implemented; actual DLL load by Edge unconfirmed
Post-RAT launch C2 and exfiltration	Command reception and file retrieval via Discord channels, directory archiving to ZIP, and transmission via ngrok	Outbound network access to the Discord API and ngrok	Darktrace observed attacker operations, ZIP exfiltration, and file retrieval

Common Processing and Direct Nim Loading

When a user opens an LNK disguised as a DOCX inside an IMG file, a hidden PowerShell script starts and displays a decoy PDF.
PowerShell decrypts an embedded executable using the value 0x20 at offset 239 of the PDF as the XOR key, writes it to %TEMP%\IfyuUapz.txt, and executes it.
The Nim loader decrypts the Rust DLL and the deployment PowerShell script. It loads the DLL via loadLib, falling back to regsvr32.exe if that fails.

Parallel UAC Bypass and Edge Dropping Attempt

The deployment PowerShell script places the DLL at C:\Windows\Temp\dbghelp.tmp and attempts to move it into the protected Edge directory using ms-settings registry keys and computerdefaults.exe.
UAC bypass depends on the target Windows configuration. The target destination is C:\Program Files (x86)\Microsoft\Edge\Application\dbghelp.dll, but no evidence shows Edge actually loaded it.

Post-RAT Launch C2 and Observed Exfiltration

The RAT registers the endpoint with Discord and accepts commands from a dedicated channel.
Darktrace observed the attacker compressing a directory into a ZIP file and exfiltrating it via ngrok, alongside retrieving specific files via Discord. This is not treated as evidence of successful loading via Edge.

4. Attacker Positioning and Execution Location

The attacker delivers the disk image and operates the Discord C2. The initial distribution vector is unconfirmed, and it is not proven to be email or messaging.

5. Victim and Administrator Perspective

Victims and Users

A French-language PDF explaining how to summarize a text opens, making it difficult to notice the background loader process.

Administrators

Appears as LNK/hidden PowerShell execution, UAC bypass registry modifications, computerdefaults.exe activity, suspicious DLLs under the Edge directory, and Discord traffic originating from non-browser processes.

6. Success and Failure Conditions

Success Conditions

The user executes the LNK inside the IMG, successfully running PowerShell, the Nim loader, and the Rust DLL.
Communication from the RAT to Discord must succeed. ngrok exfiltration also requires outbound connectivity.
The Edge deployment path additionally requires a Windows configuration permitting UAC bypass and write access to protected directories. Successful Edge loading is not a prerequisite for general RAT execution.

Failure Conditions and Countermeasures

Restrict IMG/LNK execution and enforce archive/disk image policies that preserve Mark-of-the-Web.
Inference: Restrict UAC bypass registry entries and write access to the Edge directory, and monitor/control direct DLL loading from Nim. Do not assume blocking the Edge drop entirely cuts off all paths; unauthorized Discord/ngrok traffic must also be controlled.

7. Impact Upon Success

Remote commands, screenshots, and file operations are possible under the privileges used to run the RAT. Privilege escalation via UAC bypass depends on the Windows configuration.
Public observations include Discord operations and ngrok ZIP exfiltration. The privileges obtained on all victim endpoints and the scope of exfiltrated data remain unpublished.

8. Observable Logs

Below are candidate investigation sources within your organization. Availability depends on products, privileges, log settings, and retention periods; the absence of records does not prove an uncompromised state.

Email: Inference: The email delivery vector is unconfirmed. Email and messaging records are candidates when investigating distribution sources.
Proxy / SWG / DNS: Inference: Verify non-browser process communication to the Discord API/CDN and ngrok.
Endpoint / EDR: Inference: Check for LNK -> PowerShell, %TEMP%\IfyuUapz.txt, computerdefaults.exe, ms-settings registry keys, and Edge\Application\dbghelp.dll.
Identity / IdP: Inference: Check for account logins from new locations or devices originating from compromised hosts.
SaaS / Cloud: Inference: Verify connections to Discord bots/channels and token usage.
Network: Inference: Monitor periodic beaconing to Discord, ngrok tunnels, and external connections following remote commands.

9. Attack Success Determination

Confirmed in Public Information

Information Theft or Session Compromise Confirmed: Public Information: Darktrace observed operations via Discord, directory compression to ZIP with ngrok exfiltration, and retrieval of specific files via Discord. Successful DLL loading by Edge and administrator privilege escalation on all endpoints remain unconfirmed. Scope: Attacker actions identified by Darktrace. Total victim scale and ZIP contents are unpublished.

Separate contact, execution, persistence, data access, and exfiltration; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Start from the IMG/LNK, IfyuUapz.txt, ms-settings registry entries, and Discord API traffic.
Initial Verification: Check the delivery source, file hashes, executing user, process tree, and destinations.
Endpoint / Server Investigation: Preserve the IMG, PDF, LNK, Nim loader, DLL, registry, and Edge directory.
Authentication / Cloud Investigation: Check Discord tokens, Windows accounts, browser sessions, and SaaS logins from compromised hosts.
Subsequent Activity: Track remote commands, screenshots, file transfers, ngrok exfiltration, and credential access.
Containment: Isolate hosts, block C2, remove malicious files/registry keys, and rotate credentials.
Categorization: Separate decoy opening, PowerShell execution, UAC bypass, DLL loading, C2, and data exfiltration.

11. Defense and Detection Ideas

Single Event: Detect modifications to ms-settings\shell\open\command immediately prior to computerdefaults.exe execution.
Timeline Correlation: Inference: Correlate LNK -> PowerShell -> Nim DLL loading with Discord traffic, and track UAC bypass registry changes -> Edge DLL dropping attempts as a separate path.
Threat Hunting: Search for non-Microsoft dbghelp.dll files in the Edge application directory and non-browser Discord API clients.
Log Limitations: Because Discord traffic is TLS encrypted, correlating host processes with communication destination metadata is necessary.
Priority Countermeasures: Prioritize IMG/LNK restrictions, PowerShell logging, program directory protection, and outbound traffic management for Discord and ngrok.

12. Facts / Inference / Hypothesis

Facts

The initial lure files consist of a DOCX-style LNK and a PDF contained within Proposition_Projet.img.
The LNK launches a hidden PowerShell script, which decrypts an embedded executable using the value 0x20 at offset 239 of the PDF as the XOR key, writes it to %TEMP%\IfyuUapz.txt, and executes it.
The Nim loader contains a Rust DLL and deployment PowerShell, implementing DLL loading via loadLib and a retry fallback calling regsvr32.exe on failure.
The deployment PowerShell attempts UAC bypass using HKCU\Software\Classes\ms-settings\shell\open\command and computerdefaults.exe. Success depends on the Windows configuration.
The Rust DLL is dropped into C:\Program Files (x86)\Microsoft\Edge\Application\dbghelp.dll, targeting an Edge DLL search-order hijacking condition. Analysis confirmed this path, but evidence of Edge actually loading the DLL in the observation environment was not presented.
The RAT uses Discord channels for C2, accepting reconnaissance, command execution, screenshots, and file operations, with functionality to exfiltrate data via ngrok.
Darktrace observed directory compression to ZIP sent via ngrok, and retrieving specific files via Discord using !download.

Inference

In environments with legitimate Discord usage, it is effective to correlate non-browser process usage of the Discord API with host-level changes rather than relying solely on domain-based controls.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Open Questions and Further Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1204.002	User Execution: Malicious File	high	Relies on the user opening a DOCX-style LNK inside an IMG. Source
T1548.002	Abuse Elevation Control Mechanism: Bypass User Account Control	high	Uses the `ms-settings` handler and `computerdefaults.exe`. Source
T1574.001	Hijack Execution Flow: DLL	medium	A path dropping `dbghelp.dll` into the Edge directory was confirmed; actual loading is unconfirmed. Source
T1102	Web Service	high	Uses Discord channels for C2. Source

14. Open Questions and Further Investigation

The distribution vector, campaign scale, threat actor, victim organizations, successful DLL loading by Edge, specific contents of exfiltrated ZIP files, and total impact volume remain unknown.

15. Impact on SOCs and Organizations

Even if writes to the protected Edge directory are blocked, the direct DLL loading path from Nim remains. Organizations utilizing Discord for business must not permit traffic simply because it targets a common cloud destination; they need to correlate evidence of loaders, DLL loading, registry modifications, and data exfiltration.

16. Summary by Target Audience

For SOCs: Correlate LNK -> PowerShell -> computerdefaults.exe, the ms-settings registry key, dbghelp.dll under Edge, and Discord C2.
For Administrators: Restrict IMG/LNK execution, and prevent standard users from writing to the Edge program directory and making unauthorized Discord connections.
For Users: Do not open unexpected proposal IMG or DOCX-style shortcuts; verify with the legitimate sender via alternative channels.

Collabora Online CVE-2026-110447: Pre-Authentication OS Command Injection in Nextcloud Built-in CODE Server

Anoymask — Fri, 16 Oct 2026 10:05:18 +0000

1. Basic Information

Advisory: Unauthenticated OS command injection in the richdocumentscode proxy
Vendor: Collabora Online
Published: 2026-10-14
Updated: None
Source: Collabora Online
Related Source: Administrator Report and Developer Guidance: richdocumentscode #354
Associated Malware: None
Associated Threat Group: None
Associated CVE: CVE-2026-110447
Related Products: Nextcloud Built-in CODE Server (richdocumentscode) prior to 26.4.303, Nextcloud Server
Severity: Critical

This vulnerability allows unauthenticated remote attackers to execute OS commands on internet-facing Nextcloud instances, and active exploitation has been confirmed. Disabling the application is insufficient; updating to version 26.4.303 or later or removing the application is required.

2. Executive Summary

An unauthenticated OS command injection vulnerability exists in proxy.php within the optional Nextcloud application "Built-in CODE Server," allowing arbitrary command execution when connecting to a stopped CODE server. Active exploitation and the deployment of PHP web shells have been reported starting September 10, 2026.

3. Attack Flow

Path 1: Confirmed Pre-Authentication Exploitation Vector

An attacker sends a crafted request to proxy.php in richdocumentscode on Nextcloud.
The input reaches shell commands when the CODE server is stopped, executing OS commands without authentication.
A PHP web shell is deployed to maintain the ability to execute additional commands continuously.
Files related to password databases, password managers, and cryptocurrency wallets are searched.

4. Attacker Position and Execution Location

An unauthenticated remote attacker with network access to Nextcloud over the internet.

5. Victim and Administrator Perspective

Victims and Users: No explicit warnings may appear during normal Nextcloud usage.
Administrators: Appears as anomalous requests to proxy.php, unknown PHP files under the Nextcloud directory, shell execution spawned by the web server child process, and credential reconnaissance activity.

6. Success and Failure Conditions

Success Conditions

The richdocumentscode application version is prior to 26.4.303.
The CODE server is stopped, and the vulnerable proxy path is reachable.

Failure Conditions and Countermeasures

Update to version 26.4.303 or later, or remove the application from the file system.
Inference: If applying temporary access restrictions, target the vulnerable application paths including proxy.php rather than just the administrative interface. Web server privileges and the placement of sensitive information serve as mitigation measures and do not replace updates or removal.

7. Impact of Successful Exploitation

Arbitrary OS commands executed with web server privileges.
Persistent remote access via PHP web shells and reconnaissance for credentials and wallet information.

8. Observable Logs

Email: No email vectors specific to this issue have been identified.
Proxy / SWG / DNS: Inference: Unusual parameters or rapid repeated requests directed at proxy.php.
Endpoint / EDR: Inference: Records of shells or utilities spawned from web server processes, and unknown PHP files created under the Nextcloud directory.
Identity / IdP: Inference: Nextcloud sessions following the compromise timestamp, administrator logins, and the use of stored credentials.
SaaS / Cloud: Inference: Nextcloud audit logs, application update history, and file access history.
Network: Inference: Outbound connections or downloads from the Nextcloud host to unknown destinations.

9. Determining Attack Success

Confirmed in Public Information

Subsequent Compromise Confirmed: Public Information: The affected administrator in issue #354 reported the creation of a PHP web shell and subsequent reconnaissance of credentials and wallets from it. This does not substantiate successful data exfiltration or root privilege acquisition. Scope: Multiple Nextcloud environments reported by the affected administrator. Subsequent actions under web server privileges.

Separate contact, execution, persistence, data collection, and exfiltration; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Versions prior to 26.4.303, anomalous requests to proxy.php, and unknown PHP files.
Initial Verification: Determine whether the instance uses the Built-in CODE Server app or an external CODE server, then check the version, stop/restart timestamps, and exposure scope.
Endpoint / Server Investigation: Preserve web roots, process trees, shell history, temporary directories, and web shell IOCs.
Authentication / Cloud Investigation: Review usage history for Nextcloud administrators, databases, password managers, and service credentials.
Subsequent Actions: Track web shell commands, secret access, outbound communications, and lateral movement.
Containment: Isolate the host, preserve evidence, update or remove the application, remove web shells, and rotate credentials.
Judgment Classification: Evaluate scanning, command execution, web shell deployment, secret access, and outbound transmission separately.

11. Defense and Detection Ideas

Single Event: Prioritize events where shells are spawned from web server processes.
Time-Series Correlation: Correlate proxy.php requests -> shell execution -> PHP file creation -> outbound communications.
Threat Hunting: Search all Nextcloud instances for richdocumentscode versions and unknown PHP files.
Log Limitations: Web access logs alone cannot verify command results or file access; host-side telemetry is required.
Priority Action: Prioritize updating to 26.4.303 or later, or removing the application.

Inference: Apply access restrictions leading up to the update to paths including proxy.php, and combine this with the segregation of sensitive information.

12. Facts / Inference / Hypothesis

Facts

CVE-2026-110447 is an OS command injection vulnerability in proxy.php of richdocumentscode, with a CVSS score of 9.2 and CWE-78.
It affects the optional Built-in CODE Server application used in Nextcloud. Standalone, Docker, RPM/DEB versions of Collabora Online and Nextcloud AIO CODE servers are not affected.
The attack succeeds when proxy-mediated connections occur while the CODE server is stopped.
An affected administrator reported logs from September 10-11, 2026, the creation of a PHP web shell, and the exploration of credential and wallet files. Public requests do not show commands indicating file archiving, uploading, or exfiltration.
It was patched in version 26.4.303. Because Nextcloud 29 and earlier have reached End of Life (EOL), application removal or migration to a supported version is required.
Simply disabling the application leaves files behind, so official guidance requires updating or removal.

Inference

Following web shell deployment, attackers may proceed to subsequent reconnaissance using Nextcloud privileges, settings, and external connection details. The scope of individual damage has not been publicly disclosed.

Hypothesis

No additional hypotheses. Unverified items are listed in "Open Questions and Additional Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Exploits the `richdocumentscode` proxy on internet-facing Nextcloud instances prior to authentication. Source
T1505.003	Server Software Component: Web Shell	high	Deployment of PHP web shells was reported in active exploitation. Source

14. Open Questions and Additional Investigation

Verification of threat actors, total number of affected organizations, actually exfiltrated information, and additional reports concerning ransomware remains incomplete.

15. Impact on SOCs and Organizations

Stopping or disabling an application is not equivalent to rendering vulnerable files unreachable. Organizations that have deployed the Built-in CODE Server should also evaluate periods of stoppage, restarts, and outages, verify application updates or removal, and assess the impact of residual web shells and secrets readable by the web server.

16. Summary by Role

For SOCs: Review Nextcloud web access, proxy.php, PHP file creation, web shell execution, and credential reconnaissance in chronological order.
For Administrators: Update richdocumentscode to 26.4.303 or later, or remove it. Do not rely solely on disabling the app.
For Users: No user action is required. Follow any password change or session re-authentication instructions from administrators.

AdFection: Zero-Click Chain Delivering Candiru Spyware via Targeted Ads Without User Interaction

Anoymask — Fri, 16 Oct 2026 10:05:12 +0000

1. Basic Information

Article: Exposing AdFection: How Discover-Tech Turned Targeted Ads Into a Pipeline for Zero-Click Mercenary Spyware
Source: The Citizen Lab
Published: 2026-10-15
Updated: None
Original: The Citizen Lab
Related Sources: Confiant: ADINT—Weaponized Ad Tech for Zero-Click Spyware, The Record: Israeli advertising company used to deliver spyware
Related Malware: Candiru Windows spyware
Related Threat Actors: Discover-Tech, Candiru / Integrity Labs
Related CVEs: None
Related Products: Controlium, real-time bidding advertising ecosystem, Windows
Severity: Critical

Because users can enter a zero-click spyware chain simply by displaying ads on normal websites or applications, user training alone is not enough to prevent it. Organizations must cross-reference advertising, browser, and endpoint telemetry to detect the targeted behavior of mercenary spyware.

2. Executive Summary

Discover-Tech's Controlium advertising infrastructure used real-time bidding (RTB) data to select specific individuals and redirected them to a validator and Candiru infrastructure simply by displaying ads. Citizen Lab confirmed a chain targeting at least 45 devices within Al Jazeera, along with Windows spyware samples.

3. Attack Flow

Path 1: Targeted Selection and Zero-Click Delivery via AdFection

Controlium uses real-time bidding data to select targets based on ad placements, devices, and location data.
When a target views a normal website or app, ad JavaScript runs and collects identification data.
A validator re-confirms the target criteria and redirects only matching browsers to infrastructure managed by Candiru.
Network records and recovered Windows samples support that target devices were compromised and connected to the Candiru spyware C2. Confiant stated that they did not recover the complete exploit chain. It has not been confirmed that infection can occur on all operating systems where ads were displayed.
The spyware establishes persistence through COM hijacking, leading to monitoring and data collection by operators.

4. Attacker Position and Execution Location

Operators link the ad tech infrastructure with the commercial spyware infrastructure. Direct interaction with the victim is not required.

5. Visibility for Victims and Administrators

Victims and Users: Ads simply display on regular websites or apps, and there may be no clear warning screens or confirmation prompts.
Administrators: Appears as ad script or validator traffic from a small number of devices, browser anomalies, unknown binaries, and modified COM registrations.

6. Success and Failure Conditions

Success Conditions

The advertising ecosystem delivers Controlium ad creatives to the target device.
The validator determines the device is a target, and an unpatched exploit succeeds.

Failure Conditions and Countermeasures

Promptly update browsers and operating systems, and isolate ads and scripts on high-risk devices.
Block IOCs for advertising vendors, validators, and Candiru infrastructure at the DNS, proxy, and endpoint levels.

7. What Happens Upon Success

Leads to zero-click spyware infection, continuous monitoring, and theft of data and communication contents.
Real-time bidding data is abused for mass identification and precise targeting.

8. Observable Logs

These are investigation candidates for your organization. Availability depends on products, permissions, log settings, and retention periods, and a lack of records does not prove an absence of compromise.

Email: No email vectors specific to this case have been confirmed.
Proxy / SWG / DNS: Inference: Confirm chains from ad domains to validators, unknown redirects, and Candiru-related infrastructure.
Endpoint / EDR: Inference: Confirm browser child processes, crashes associated with exploits, unknown binaries, and COM registrations or hijacking.
Identity / IdP: Inference: Confirm email and cloud sessions and token usage after the spyware infection timestamp.
SaaS / Cloud: Inference: Confirm access to ad campaigns and vendors, browser syncing, and access to cloud data.
Network: Inference: Confirm validators and C2s connected by only a small number of devices, and redirect chains distinct from normal ad traffic.

9. Attack Success Assessment

Confirmed in Public Information

Subsequent Compromise Confirmed: Public Information: Citizen Lab confirmed infections based on Al Jazeera network records and Windows DLLs recovered from infected devices, where samples showed persistence via COM hijacking. At least 45 units refers to the number of targeted devices, not a confirmed count of all 45 units infected. Scope: 2024–2025 Al Jazeera cases and recovered Windows samples. Do not generalize to total ad impressions or all operating systems.

Separate contact, execution, persistence, data collection, and exfiltration, and do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Start from related ad domains, validators, Candiru IOCs, browser anomalies, and COM modifications.
Initial Verification: Check high-risk users, viewed URLs, ad request chains, browser and OS versions, and endpoint alerts.
Device and Server Investigation: Preserve memory, browser artifacts, downloads, unknown binaries, COM registry entries, and network caches.
Authentication and Cloud Investigation: Check email, messaging, cloud, and SSO token usage from the infection timestamp onward.
Subsequent Actions: Track C2, access to documents and messages, camera and microphone use, and data exfiltration.
Containment: Isolate devices from the network, perform professional forensics, rotate credentials, and rebuild from trusted images.
Judgment Categories: Separate ad contact, validator selection, exploitation, spyware execution, persistence, and data access.

11. Defense and Detection Ideas

Single Event: Detect rare redirects from browsers to validator domains and modified COM registrations.
Time-Series Correlation: Correlate ad requests -> validator -> browser anomalies -> unknown binaries -> C2.
Threat Hunting: Search for related domains, sample hashes, COM hijacking, and rare communication destinations on high-risk user devices.
Log Limitations: Inference: Ad views alone cannot confirm individual targeting or infection. Cross-reference validators, C2s, and device evidence. Because targeted delivery has low reproducibility, preserve accessible URL, DNS, and browser records.
Priority Countermeasures: Prioritize rapid patching, browser isolation, ad script control, isolation of high-risk users, and network logging.

12. Facts / Inference / Hypothesis

Facts

Citizen Lab and Confiant analyzed Discover-Tech's Controlium as the AdFection chain directing targeted ads into zero-click spyware.
Citizen Lab analyzed approximately 4 billion bid records over four months, showing ad impressions across roughly 200,000 websites and apps and dozens of countries. This is not an infection count.
When ads render in a target browser, JavaScript collects identification data and guides the user through a validator to Candiru infrastructure.
At least 45 devices within Al Jazeera were targeted, and Citizen Lab confirmed infection chains and Windows spyware samples.
The SHA-256 hash of the Windows DLL recovered from an infected device is 255869de85e2a171993fc5eb8a556d873a1b8966e040f6f55926f2fa2d595cc8, and persistence via COM hijacking was confirmed.
Citizen Lab assessed the partnership between Discover-Tech and Candiru with high confidence.
Following advance notice of the findings, Google and industry partners moved to block and restrict access to Discover-Tech. Removal by Google and IAB Europe occurred in early October 2026.
The Al Jazeera attacks are 2024–2025 cases. Infections are supported by network records and recovered samples, but Confiant noted they did not recover the complete exploit chain.

Inference

Because ad bidding data is used for target selection, ad tech vendor risks must be evaluated not only for privacy but also as an exploit delivery vector.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1189	Drive-by Compromise	high	Renders targeted ads to guide users into the exploit chain without user interaction. Source
T1546.015	Event Triggered Execution: Component Object Model Hijacking	high	Persistence via COM hijacking was confirmed in recovered Windows spyware. Source

14. Unknowns and Additional Investigation

The complete chain of browser and OS exploits used, total victim counts, all customers, Candiru operator command structures, and ongoing activity after removal from advertising networks remain unknown.

15. Impact on SOCs and Organizations

Because advertising infrastructure is used for both information gathering and exploit delivery, user training to avoid clicks cannot address this vector alone. Organizations protecting high-risk users should combine browser and OS updates, ad script controls, isolated environments, and log preservation while evaluating ad contact and infection as separate stages.

16. Summary by Role

SOC: Correlate ad scripts -> validator -> rare redirects or downloads, browser child processes, and COM hijacking.
Administrators: Modernize browsers and operating systems, and strengthen ad script controls, isolated environments, and external DNS and proxy log recording for high-risk devices.
Users: Because compromises can occur simply by viewing content, close and report abnormal browser behavior and do not delay updates.

UAT-6275 and TAG-193: Four Phishing Chains and Custom Reverse Shells Targeting Government Organizations

Anoymask — Fri, 16 Oct 2026 10:05:07 +0000

1. Basic Information

Article Title: Break the silence: Kazakhstan-nexus UAT-6275 targets CIS government organizations
Publisher: Cisco Talos
Publication Date: 2026-10-14
Updated Date: None
Source: Cisco Talos
Related Sources: Recorded Future: TAG-193 regional espionage operations, The Record: Suspected Kazakhstan-linked hackers target governments across Central Asia, Cisco Talos / Recorded Future: Break the silence (VB2026 Joint Paper)
Related Malware: Chvost, Laplas, PickleShell
Related Threat Groups: UAT-6275, TAG-193, Silent Lynx
Related CVE: CVE-2025-8088
Related Products: Microsoft Office, PowerShell, WinRAR, GitHub
Severity: High

This is an ongoing espionage campaign targeting government, diplomatic, water, and energy organizations across nine countries. Because GitHub is used for payload distribution, monitoring is required not only for email attachments but also for external PowerShell retrieval and startup persistence following archive extraction.

2. Executive Summary

UAT-6275 (TAG-193) targets government agencies in CIS countries, gaining initial access through four distinct chains: macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and WinRAR archives exploiting CVE-2025-8088. The group deploys reverse shells such as Chvost, Laplas, and PickleShell.

3. Attack Flow

The following four alternative paths involve different conditions and do not necessarily execute in a continuous sequence.

Path	Initial Vector & User Interaction	Retrieved or Placed Artifacts	Subsequent Payload & Confirmation Scope
Attack Path A	Open a macro-enabled Word document and enable macros	Retrieve an executable from the delivery server	Subsequent binary for the representative sample was not recovered; reverse shell deployment is researcher inference
Attack Path B	Run a PS2EXE-generated executable contained within a RAR archive	Retrieve a VBScript/script or ZIP, and create a scheduled task	Deploy a PowerShell reverse shell or Chvost (depending on the sample)
Attack Path C	Open an LNK file inside a RAR archive	PowerShell retrieves and executes a script from GitHub	Operates directly as a TCP reverse shell or places PickleShell in the Startup folder
Attack Path D	Extract a crafted RAR archive using a vulnerable Windows version of WinRAR	Write directly to the user's Startup folder via CVE-2025-8088	Place PickleShell (placement and subsequent execution at logon or similar events are separate stages)

Attack Path A: Macro-Enabled Word Document

The user opens the document and enables macros, triggering AutoOpen.
The macro retrieves an executable from the delivery server and launches it in a hidden window. The subsequent binary for the representative sample was not recovered, and the deployment of a reverse shell remains researcher inference.

Attack Path B: PS2EXE Downloader

The user executes a PS2EXE-generated executable included in the phishing RAR archive.
Depending on the sample, it retrieves a VBScript and PowerShell reverse shell, or a ZIP containing Chvost, and maintains execution via a scheduled task.

Attack Path C: PowerShell Hosted on GitHub

Opening the LNK file inside the RAR archive launches PowerShell, which retrieves and executes a script from GitHub.
Depending on the sample, it acts directly as a TCP reverse shell or as a launcher that places PickleShell into the Startup folder. In this context, GitHub serves as the script and payload distribution source.

Attack Path D: WinRAR Archive Exploiting CVE-2025-8088

The user extracts a crafted RAR archive using a vulnerable Windows version of WinRAR.
Path traversal via NTFS alternate data streams writes PickleShell directly into the user's Startup folder. Verify placement and subsequent execution at user sign-in as separate stages. Administrative privileges are not a prerequisite for this placement.

4. Attacker Location and Execution Context

A regional espionage actor operating phishing infrastructure, GitHub repositories, staging directories, and C2 servers.

5. Victim and Administrator Perspective

Victims and Users

Received as email attachments disguised as legitimate documents related to government, diplomacy, trade, and energy.

Administrators

Inference: Depending on the specific path, indicators of compromise may include executable retrieval from Office, PS2EXE execution with scheduled tasks, LNK leading to PowerShell and GitHub, or WinRAR writing to the Startup folder. Not all paths involve PowerShell launching directly from Office or WinRAR.

6. Success and Failure Conditions

Success Conditions

For Path A, opening the document and enabling macros; for Paths B and C, executing the executable or LNK file.
For Path D, extracting the archive using a Windows version of WinRAR vulnerable to CVE-2025-8088, followed by successful payload execution after placement in the Startup folder.
Successful network reachability to the path-specific delivery source and C2. PowerShell, GitHub, and macros are not prerequisites common to all paths.

Failure Conditions and Mitigations

Restrict Office macros and archives originating from the internet, and update WinRAR to a patched version.
Monitor GitHub raw downloads within the context of executing processes and block outbound egress traffic for reverse shells.

7. What Happens Upon Success

Exfiltration of government, diplomatic, water, and energy data (espionage), remote command execution, and deployment of additional tools.
Indications of preparation for expansion to Linux hosts or public appliances, though actual compromise remains unconfirmed.

8. Observable Logs

The following items are candidates for internal investigation. Feasibility depends on products, permissions, log settings, and retention periods; the absence of records does not prove an absence of compromise.

Email: Inference: Delivery from legitimate accounts of compromised government organizations has been reported. Do not rely solely on sender display names or domains to determine legitimacy; cross-reference attachments and authentication records.
Proxy / SWG / DNS: Inference: Identify PowerShell communications to GitHub raw or staging directories, as well as C2 destinations.
Endpoint / EDR: Inference: Separately verify indicators such as document-based retrieval and execution for Path A, PS2EXE and scheduled tasks for Path B, LNK-to-PowerShell for Path C, and WinRAR writes outside the selected extraction directory (into the Startup folder) as well as subsequent execution as distinct stages for Path D.
Identity / IdP: Inference: Check for new VPN, mailbox, or cloud account sessions originating from the compromised host.
SaaS / Cloud: Inference: Review downloads from GitHub, cloud storage access, and access to government portals.
Network: Inference: Identify periodic or interactive communication associated with Chvost, Laplas, or PickleShell, along with new C2 connections.

9. Determining Attack Success

Confirmed in Public Information

Information Theft or Session Compromise Confirmed: Public Information: The joint paper reports the compromise of two Armenian government entities and the transmission of information to attack infrastructure. However, it does not link specific lure documents or the use of CVE-2025-8088 directly to the establishment of those compromises. Scope: Cases involving Armenian government entities reported in the joint paper. This does not imply success across all nine countries or all attack paths.

Separate contact, execution, persistence, data acquisition, and external transmission; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Initiate investigation using IOCs related to lure documents, CVE-2025-8088, GitHub PowerShell, and reverse shells.
Initial Verification: Check emails, attachment hashes, executing user accounts, WinRAR versions, GitHub URLs, and process trees.
Endpoint / Server Investigation: Preserve documents, archives, PowerShell scripts, Startup folders, and reverse shell binaries.
Authentication / Cloud Investigation: Review email, VPN, cloud, and government portal sessions starting from the estimated time of compromise.
Subsequent Actions: Trace credential access, document collection, deployment of additional tools, and access to Linux or appliance systems.
Containment: Isolate hosts, block C2 communication, rotate credentials, and block macro and archive vectors.
Judgment Categories: Separate delivery, user execution, vulnerability exploitation, payload retrieval, reverse shells, and data access.

11. Defense and Detection Ideas

Single Events: Inference: Detect suspicious Office-based retrieval and execution, PS2EXE with new tasks, PowerShell launched from LNK files, and WinRAR writes outside the selected extraction directory across the respective paths.
Temporal Correlation: Inference: For Path C, correlate LNK execution, PowerShell launch, GitHub retrieval, and reverse shell deployment; for Path D, correlate archive extraction, Startup placement, and subsequent execution at logon.
Threat Hunting: Search for PowerShell processes downloading from GitHub raw, PS2EXE artifacts, and IOCs associated with Chvost, Laplas, or PickleShell.
Log Limitations: Because cloud communications to GitHub blend with legitimate traffic, cross-referencing URLs, processes, and file hashes is necessary.
Priority Mitigations: Prioritize WinRAR patches, macro controls, monitoring of outbound communications to GitHub, and PowerShell logging.

12. Facts, Inference, and Hypothesis

Facts

Talos identified four infection chains active from June 2025 to August 2026.
The chains utilize macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and crafted WinRAR archives exploiting CVE-2025-8088.
Payloads include custom reverse shells such as Chvost, Laplas, and PickleShell, providing interactive remote access.
Targets and lure documents span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.
Targeted entities include government organizations related to diplomacy, economics, agriculture, environment, water resources, and energy.
Three publicly exposed staging directories and GitHub repository histories exposed payload builds, tools, and C2 modifications.
Talos assesses the activity as having a Kazakhstan nexus with medium confidence, based on infrastructure access, language, sample submissions, operating hours, and targeted regions.
The joint paper notes that the subsequent binary for the representative sample in Path A could not be recovered, classifying its reverse shell deployment as an inference.

Inference

The report does not indicate direct targeting of Japanese organizations, although organizations or business partners with operations related to Central Asian government, energy, and water sectors may intersect with the context of the lure documents.

Hypothesis

No additional hypotheses. Unconfirmed items are documented under Open Questions and Further Investigation.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1566.001	Phishing: Spearphishing Attachment	high	Sends macro-enabled documents and crafted archives to government organizations. Source
T1203	Exploitation for Client Execution	high	Utilizes WinRAR archives exploiting CVE-2025-8088. Source
T1059.001	Command and Scripting Interpreter: PowerShell	high	Utilizes PowerShell hosted on GitHub and PS2EXE chains. Source
T1105	Ingress Tool Transfer	high	Retrieves scripts and payloads from GitHub or delivery servers. Serving as a distribution source alone is not considered sufficient basis for attributing unidirectional C2. Source

Script and payload retrieval from GitHub is mapped to T1105. The reviewed sources establish script and payload delivery from GitHub, but do not establish its use for one-way C2 instructions. Therefore, T1102.003 is not assigned.

14. Open Questions and Further Investigation

Connections to the Kazakh government, specific numbers of victim organizations, total successful compromise counts, and the operational deployment of Linux or FortiWeb tools remain unconfirmed.
The subsequent binary retrieved by the representative sample in Path A and the specific initial access vectors used in individual compromise incidents remain unverified.

15. Impact on SOCs and Organizations

Communications to trusted platforms such as GitHub and the extraction of legitimate archives do not guarantee the safety of subsequent code. Organizations involved in Central Asian government and resource-related operations should evaluate macros, executables/LNK files, and WinRAR exploitation as distinct vectors, correlating retrieval sources, executing processes, and persistence mechanisms. Attribution is assessed at medium confidence, and definitive conclusions regarding state sponsorship are avoided.

16. Audience-Specific Summary

For SOCs: Separate the four paths and verify macro execution, PS2EXE activity, LNK-to-PowerShell execution, and WinRAR writes outside the selected extraction directory, tying each to execution and C2 evidence.
For Administrators: Restrict Office macros, WinRAR usage, PowerShell, and GitHub raw access to the minimum necessary, and apply patches for CVE-2025-8088.
For Users: Verify documents disguised as diplomatic, energy, or water communications through alternative channels, and avoid opening unverified macros or archives.

Arch Linux AUR: Typosquatted yay and paru Packages Execute Remote Scripts with Root Privileges

Anoymask — Fri, 16 Oct 2026 10:05:02 +0000

1. Basic Information

Report Title: Re: hundreds of aur packages were mass uploaded with malware
Source: Arch Linux aur-general
Published Date: 2026-10-13
Updated Date: None
Original Source: Arch Linux aur-general
Related Information Sources: Fake Arch Linux packages push malware with root privileges, Arch Linux: PKGBUILD(5)
Related Malware: None
Related Threat Groups: None
Related CVEs: None
Related Products: Arch User Repository (AUR), yay, paru, yyay
Severity: Critical

Malicious install scriptlets execute with root privileges during package installation or updates via pacman. Low-privilege builds using makepkg must be evaluated separately from root-privileged host installations, and administrators must verify execution artifacts and credentials on affected hosts.

2. Executive Summary

Public analysis of AUR packages mimicking yay and paru revealed a path where install scriptlets added to legitimate upstream code execute remote scripts as root without validation during installation or updates. Although package removal and account suspensions have been reported, execution on individual hosts requires separate verification.

3. Attack Flow

Installation and Update Path Shown by Public Static Analysis

A user acquires an AUR package resembling yay or paru and builds it using makepkg.
During package installation or updates via pacman, the top-level logic of the added install scriptlet executes with root privileges.
The scriptlet retrieves a script from GitFlic via a Wayback Machine URL. The retrieved item is not included in the source array and lacks a checksum.
The retrieved script is passed to a shell for execution. Static analysis indicates this execution path, which must be distinguished from actual execution and compromise confirmation on individual user hosts.

4. Attacker Position and Execution Location

A software supply chain attacker who publishes packages to the AUR and manages external repositories.

5. Victim and Administrator Perspective

Victims and Users: Appears as a standard AUR helper installation and build process, potentially overlooking subtle differences in package names.
Administrators: Manifests as external downloads via makepkg or package managers, root shell activity, and unknown services or persistence configurations.

6. Success and Failure Conditions

Success Conditions

The user installs or updates the target package and executes the install scriptlet as root.
The external script retrieval destination is reachable, and the returned code is passed to the shell.

Failure Conditions and Mitigations

Restrict installations to official repositories or verified AUR packages, and verify PKGBUILD, install scripts, and source checksums.
Inference: In addition to building in low-privilege and isolated environments, inspect install scriptlets before installing them on the host, and block unverified remote script retrieval and execution. Build isolation alone does not protect against subsequent root installation steps.

7. Impact of Successful Exploitation

Arbitrary script execution with root privileges can lead to a full host compromise.
Access to source code, SSH keys, tokens, build secrets, and secondary impacts on the software supply chain are possible.

8. Observable Logs

The following items are candidates for investigation within your organization. Availability depends on products, permissions, log settings, and retention periods, and the absence of records does not prove the absence of compromise.

Email: No email vectors specific to this incident have been confirmed.
Proxy / SWG / DNS: Inference: If connections from installation or update processes to the Wayback Machine or GitFlic are recorded, correlate their timestamps with the retrieval destinations.
Endpoint / EDR: Inference: Verify retrieval tools, shell execution, and the executing user spawned by pacman install scriptlets. Distinguish between makepkg builds and root installations.
Identity / IdP: Inference: Check for the use of SSH keys, Git tokens, and cloud credentials stored on compromised hosts.
SaaS / Cloud: Inference: Review access from compromised hosts to Git hosting, CI/CD, and package registries.
Network: Inference: Confirm external script retrieval around the time of installation or updates. Subsequent C2 activity remains an unconfirmed investigation candidate.

9. Determining Attack Success

Confirmed in Public Information

The aur-general post outlines the static execution path of the install scriptlet. This must be distinguished from records observing root execution on individual user endpoints or validation environments.

Internal Evaluation Criteria

Initial Execution Confirmed: Criteria: This stage is reached when evidence confirms root script execution from an install scriptlet on organizational endpoints. Public analysis shows static execution paths and does not indicate observed execution success on individual hosts. Scope: Internal evaluation criteria. Distinguish public static analysis from actual execution evidence.

Separate contact, execution, persistence, data collection, and exfiltration, and do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Initiate investigation from similarity-named packages such as yyay, author marchos1as, and retrievals from GitFlic.
Initial Verification: Check pacman and AUR helper history, package caches, PKGBUILD, and installation timestamps.
Endpoint and Server Investigation: Preserve processes, shell history, systemd, cron, authorized_keys, and added binaries.
Authentication and Cloud Investigation: Verify usage of SSH, Git, registries, and cloud tokens after the suspected compromise time.
Subsequent Actions: Trace unauthorized access to developer repositories, CI/CD pipelines, and package publication workflows.
Containment: Isolate hosts, rotate credentials, rebuild from trusted images, and remove malicious packages.
Categorization: Separate package acquisition, builds, root script execution, credential usage, and secondary supply chain impacts.

11. Defense and Detection Ideas

Single Events: Inference: Detect undeclared downloads and root shell execution originating from package installation or update processes.
Timeline Correlation: Correlate AUR acquisition, installation hooks, external scripts, root processes, and credential access.
Threat Hunting: Search all Arch Linux hosts for package names resembling yay or paru alongside external script retrieval activity.
Log Limitations: Package manager logs alone do not reveal commands executed inside scripts; process and network telemetry are required.
Priority Mitigations: Prioritize AUR allowlist operations, PKGBUILD reviews, isolated builds, and build environments devoid of secrets.

12. Facts, Inference, and Hypothesis

Facts

The aur-general post dated October 13, 2026, reports packages mimicking yay and paru and the contributor marchos1as.
At least yyay used a legitimate upstream tarball while adding a top-level malicious install scriptlet.
Published static analysis indicates that the install scriptlet executes remote scripts as root without checksum validation during installation or updates.
BleepingComputer reported the removal of related packages and the suspension of the contributing account marchos1as.
The malicious scriptlet uses a Wayback Machine URL as a retrieval vector to connect to hellscripter/install-scripts on GitFlic.
Links to DirtyBlanket or CHAOS are based on similarities, and attribution remains unconfirmed.

Inference

Adding or replacing a single character in AUR helper names targets search and typo errors, necessitating diff verification of PKGBUILD and install scripts alongside package names.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1195.002	Supply Chain Compromise: Compromise Software Supply Chain	high	Distributed malicious install scripts embedded in AUR packages. Source
T1059.004	Command and Scripting Interpreter: Unix Shell	high	Executes remote shell scripts with root privileges. Source

14. Open Questions and Further Investigation

Download and installation counts, executed final payloads, number of compromised hosts, the true identity of the contributor, and connections to DirtyBlanket or CHAOS remain undetermined.

15. Impact on SOCs and Organizations

Even if legitimate upstream checksums match, the safety of added install scriptlets is not guaranteed. Organizations using Arch Linux for development terminals or build environments should manage low-privilege builds and root installations as separate trust boundaries, and review both PKGBUILD and scriptlets.

16. Summary by Role

For SOCs: Verify AUR helper installations, pipe execution from curl or wget to shells, root processes, and GitFlic communications.
For Administrators: Audit environments for the presence of similarity-named packages like yyay, and isolate and rebuild hosts on which the malicious script ran assuming compromise.
For Users: Review AUR package names and PKGBUILD files, and avoid building or installing software from unofficial or untrusted sources.

PEERSTITCH: Theft of 500+ Firewall Configurations and Payload Injection into FortiGate Daemons

Anoymask — Thu, 15 Oct 2026 15:24:21 +0000

1. Overview

Article Title: Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant
Publisher: Unit 42
Publication Date: 2026-10-14
Original Source: Unit 42
Related Information Sources: Fortinet CNA: CVE-2024-47575, Fortinet CNA: CVE-2025-61624, MITRE ATT&CK: T1602.002
Related Malware and Threat Groups: PEERSTITCH, CL-STA-0954, UNC5820
Related CVEs: CVE-2024-47575, CVE-2025-61624
Related Products: FortiManager, FortiGate / FortiOS
Importance: Critical

2. Quick Summary

CL-STA-0954 exploited FortiManager CVE-2024-47575 to steal configuration files, keys, and credentials for over 500 FortiGate devices, escalated to root via CVE-2025-61624, and injected the memory-resident ARM64 implant PEERSTITCH into miglogd and iked.

3. Attack Flow

Attack and Exploitation Vector

The attackers sent a crafted request to FortiManager TCP/541 to register a rogue appliance.
They generated and exfiltrated a configuration archive, obtaining information and credentials for over 500 firewalls.
The attackers established unauthorized FortiGate VPN sessions using valid credentials. Separately, Unit 42 verified that passwords could be recovered from the stolen configurations.
The attackers exploited the auto-script path traversal vulnerability CVE-2025-61624 to deploy the PEERSTITCH loader.
The injector patched the memory of miglogd and iked, activating backdoor behavior through markers in legitimate traffic.

Separate C2 Channel Used Alongside PEERSTITCH

Unit 42 also observed an outbound reverse shell abusing Apache mod_md alongside PEERSTITCH. The implant itself creates no outbound connections; this does not mean the overall intrusion generated no outbound traffic.

4. Attacker Position and Prerequisites

The intrusion begins with an unauthenticated attacker able to reach FortiManager TCP/541 from the internet, transitioning to an authenticated attacker with stolen administrator credentials.

5. Visible Indicators for Victims and Administrators

Victim Side

There may be no obvious change on users' screens; the effects involve unauthorized VPN sessions and traffic interception.

Administrator Side

Indicators include rogue FortiGate registrations, .tm archives, sniffer policies, auto-script path traversal, ptrace use, and read-write-execute (RWX) memory regions.

6. Success and Failure Conditions

Success Conditions

External reachability to a vulnerable FortiManager.
VPN re-entry requires valid credentials. Unit 42 verified that passwords could be recovered from the stolen configurations, but the attackers' own recovery steps require separate evidence.
CVE-2025-61624 requires vulnerable FortiOS and authentication with an administrator profile that has at least read/write privileges. VPN access alone does not necessarily provide these management privileges.

Affected Versions

CVE-2024-47575 affects FortiManager 6.2.0–6.2.12, 6.4.0–6.4.14, 7.0.0–7.0.12, 7.2.0–7.2.7, 7.4.0–7.4.4, and 7.6.0. Fortinet's CNA description identifies FortiOS 7.4.0–7.4.9, 7.6.0–7.6.4, and the 6.4, 7.0, and 7.2 branches as affected by CVE-2025-61624. The systems observed in this report were FortiManager and FortiGate.

Failure Conditions and Defensive Limits

Check the fixed releases for each CVE in Fortinet's CNA records, apply the updates, and restrict the sources allowed to reach TCP/541. Updating alone does not resolve the misuse of credentials and keys that have already been stolen.
Memory acquisition and process-integrity monitoring are post-compromise detection measures. If anomalies are found, proceed to isolation and recovery; monitoring alone is not evidence that intrusion was prevented.

Fixed Releases

For CVE-2024-47575, the fixed FortiManager releases are 6.2.13, 6.4.15, 7.0.13, 7.2.8, 7.4.5, and 7.6.1 or later in their respective branches. For CVE-2025-61624, Fortinet recommends FortiOS 7.4.10 or 7.6.5 and later. Because the 7.2, 7.0, and 6.4 branches are affected, verify an appropriate migration path to a fixed branch.

7. What Happens If the Attack Succeeds

Theft of firewall configurations, keys, and credentials for over 500 devices.
Establishment of VPN sessions and traffic interception.
Bypassing authentication validation and maintaining long-term access through a memory-only implant.

8. Observable Logs

The following are investigation candidates. Availability depends on the product, permissions, logging configuration, and retention period. Missing records do not prove that a system was not compromised.

Email: Inference: Email-based initial access has not been confirmed.
Proxy/SWG/DNS: Inference: Check communications from FortiManager/FortiGate to destinations such as 23.240.77[.]233.
Endpoint/EDR: Inference: Check for lldprx, index.wasm, ipssem.js, ptrace, and writes to /proc/*/mem.
Identity/IdP: Inference: Check sessions from 23.240.77[.]233 and 47.18.167[.]159 involving stolen VPN credentials.
SaaS/Cloud: Inference: Check FortiManager device-registration, revision, and policy-push audit records.
Network: Inference: Investigate TCP/541 and known external delivery and ACME destinations. The strings 8550 and 169.254.0.1 are markers inside traffic data; destination ports and IP addresses in flow logs alone cannot match this behavior.

9. Scope of Confirmed Success

Information Theft or Session Compromise Confirmed

Scope: Scope confirmed by public information
Basis: Public information: Exfiltration of an archive containing configurations, keys, and credentials for over 500 devices has been confirmed.

Subsequent Compromise Confirmed

Scope: The investigated MSP's environment. Intrusion into its customers' internal networks has not been confirmed.
Basis: Public information: The attackers re-entered through VPN sessions using stolen credentials and proceeded to deploy PEERSTITCH and intercept traffic.

Criteria for Internal Assessment

Separate contact, execution, information acquisition, and subsequent compromise; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Start from rogue device registrations, configuration archives, unknown VPN sessions, and auto-script traversal.
Initial Verification: Check FortiManager and FortiOS versions, TCP/541 exposure, device inventory, and credential rotation status.
Device and Server Investigation: Preserve appliance memory, miglogd and iked memory maps, evidence of /proc writes, and staging files.
Authentication and Cloud Investigation: Verify the use of all administrator and SSL-VPN credentials, certificates, and private keys.
Subsequent Operations: Expand the investigation to customer firewalls, packet captures, VPN sessions, and internal scans.
Containment: Isolate the management plane, preserve evidence, and update to fixed releases. Rotate credentials, keys, and certificates within the compromise scope after assessing dependencies and the risk of connectivity disruption. Rebuild from trusted images where necessary.
Judgment Categories: Distinguish configuration theft, credential use, root escalation, implant injection, and customer compromise.

11. Defense and Detection Ideas

Single Events: Detect rogue FortiGate registrations from external IPs and ../ in auto-script names.
Time-Series Correlation: Correlate TCP/541 registration -> .tm generation -> exfiltration -> VPN login -> loader download -> ptrace.
Threat Hunting: Check RWX regions in miglogd and iked and memory writes through /proc.
Log Limitations: PEERSTITCH itself creates no listening ports or outbound connections, so disk and flow logs alone are insufficient. An outbound reverse shell abusing Apache mod_md was also observed in the same intrusion; investigate its communications as well.
Priority Countermeasures: Prioritize patching, management-plane restrictions, memory forensics, and credential/key rotation.

12. Facts, Inference, and Hypothesis

Facts

The intrusion began with the compromise of a telecommunications MSP in September 2024, using FortiManager CVE-2024-47575 for initial access.
The attackers registered a rogue Virtual FortiGate named localhost and exfiltrated an archive containing running configurations, databases, public IP addresses, credentials, and private keys associated with over 500 devices.
Unit 42 verified that administrator and SSL-VPN passwords could be recovered from the stolen configurations. Separately, it observed the attackers using valid credentials to connect through VPN sessions; the attackers' own password-recovery procedure has not been disclosed.
The attackers exploited CVE-2025-61624 auto-script path traversal for file writes and execution as root to deploy PEERSTITCH.
PEERSTITCH uses an ARM64 injector to attach to miglogd and iked through ptrace and write a 1,344-byte payload into RWX memory.
PEERSTITCH leaves no persistent binary on disk, creates no listeners or outbound connections, and monitors traffic markers processed by legitimate processes.
It extracts tags using 8550 and 169.254.0.1 as markers inside traffic data, then shares them between daemons through /proc/<pid>/mem to bypass VPN validation. The 8550 marker does not designate a listening port.

Inference

Public facts must be mapped to internal assets and logs for validation.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in section 14, Unresolved Questions and Further Investigation.

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1190	Exploit Public-Facing Application	high	Exploited FortiManager CVE-2024-47575.
T1602.002	Data from Configuration Repository: Network Device Configuration Dump	high	Unit 42 confirmed the exfiltration from FortiManager of an archive containing running configurations for managed FortiGate devices. This is distinct from dumping an operating-system credential store.
T1055	Process Injection	high	Injected a payload into the memory of miglogd and iked.
T1040	Network Sniffing	high	Pushed sniffer configurations to managed firewalls.

14. Unresolved Questions and Further Investigation

Whether the attackers entered the individual customer networks associated with the 500+ devices, their ultimate objective, and formal threat-actor attribution remain unconfirmed.

15. Impact on SOCs and Organizations

A compromise of centralized management can expose configurations and keys for firewalls protecting numerous customers. Memory investigation is important because PEERSTITCH operates inside legitimate daemons. Investigators should also account for network traces from the outbound reverse shell used alongside it.

16. Summary by Target Audience

For SOCs: Review FortiManager registrations, archives, VPNs, auto-scripts, and daemon memory as a continuous chain.
For Administrators: Restrict TCP/541, update to fixed releases, and comprehensively rotate administrative credentials and cryptographic material.
For Users: Promptly follow administrators' instructions regarding re-authentication or credential changes when using VPNs.

Package Manager Integrity Study: Only 2 of 25 Verified All Downloads by Default in Tests

Anoymask — Thu, 15 Oct 2026 15:24:10 +0000

1. Basic Information

Article Title: Package managers have an integrity problem
Publisher: Trail of Bits
Original: Trail of Bits
Publication Date: 2026-10-14
Related Sources: Go Modules Reference: Authenticating modules, Gradle: Verifying Dependencies
Importance: High

2. Summary

Among the 25 package managers Trail of Bits evaluated using public packages, fewer than half used lockfiles for tamper checks by default. Under the study's test conditions, only Go and vcpkg verified the integrity of every package downloaded by default.

3. Security Issue

Measuring the issue where package managers fail to detect malicious code injected into legitimate packages by a compromised package repository.

4. Proposal and Evaluation Method

Containerizing 25 package managers and using mitmproxy to simulate a malicious repository, evaluating the actual behavior of hash and signature verification.

5. Inputs

For each package manager, one version and one package from a public repository, evaluated on Ubuntu using primarily quickstart configurations and default command flags.
Lockfiles, repository signatures, developer signatures, and transparency logs.
A mitmproxy harness to inject malicious code.

6. Outputs

Four categories of lockfile-based integrity.
Four categories of signature verification.
Default defense states of each tool against repository compromise.

7. Evaluation Workflow

Fetch dependencies both with and without a lockfile.
Insert malicious modifications into the repository response.
Check whether fetching or installing the modified package is stopped or requires additional configuration. Count the attack as successful if the sample code executes the injected code.
Compare the design, distribution, and verification paths of hashes and signatures.

8. Evaluation Design

Target: 25 package managers
Threat Model: Simulated compromise of public-facing distribution servers, while assuming backend resources such as private signing keys remain secure.
Harness: Docker container and mitmproxy
Verified every package downloaded by default under these test conditions: Go, vcpkg

9. Key Results

Under these test conditions, Go and vcpkg were the only tools that verified the integrity of every package downloaded by default.
Fewer than half used lockfiles for default tamper checks.
In the study, only Go verified signatures by default.
Many tools required additional configuration, had partial implementations, or lacked verification even when lockfiles or signatures were present.

10. Practical Implications

Do not assume the presence of SBOMs or lockfiles guarantees control; verify CI failure behavior as well.
Design defenses by separating developer account compromise mitigations from repository compromise mitigations.

11. Success Criteria

For hash-based verification, immutable lockfiles or trusted metadata must store package content hashes obtained through a trusted channel.
Compare downloads against trusted hashes for hash-based verification, or verify authenticity using trusted signers and public keys for signature-based verification. Enforce the applicable verification on every download, and stop installation on mismatch.

12. Constraints and Limitations

The study tested one version of each package manager and one package on Ubuntu. These conditions may not represent common usage, particularly for tools such as PowerShell and CocoaPods.
The research simulated repository compromise and did not measure real-world breach counts or malware distribution rates.
Some ecosystems can achieve stronger verification through additional configuration.
For Go, a module can be accepted without checksum-database verification when go.sum has no known hash and either the module is excluded through GOPRIVATE / GONOSUMDB or GOSUMDB=off is set.
The vcpkg evaluation assumes that the package manager and its bundled hashes are trustworthy; the security of their update path was outside the evaluation scope.

Unknowns and Additional Investigation

Differences in tool versions and configurations, and future updates, may change the results.
The study did not measure actual repository-compromise rates or the probability of victimization.

13. Deployment Guidance

Inference: Identify the verification features implemented by the product and version in use, and enforce them in CI using hashes or signing keys obtained through a trusted path. A uniform configuration procedure cannot be applied to products without lockfiles or without implemented signature verification.
Maintain upstream metadata even in internal mirrors and alert on verification failures.
Re-run tamper regression tests when updating package managers.

Evidence Needed for Verification

Inference: Preserve CI logs, lockfile diffs, hash-mismatch and signature-verification results, download URLs, and cache provenance. Use them to confirm that verification ran and that a mismatch stopped processing.

14. Facts, Inference, and Hypothesis

Facts

Evaluated 25 popular package managers using a malicious repository simulation.
Inserted malicious code into repository responses using a Docker and mitmproxy harness to check for detection.
Under these test conditions, Go and vcpkg verified the integrity of every package downloaded by default.
Bun, Bundler, Cargo, npm, pnpm, Poetry, SwiftPM, uv, and Yarn verified integrity when lockfiles were present.
Conda, Gradle, Pip, NuGet, and Pub required additional steps beyond lockfiles.
CocoaPods, Composer, Conan, cpanminus, Gem, Maven, PowerShellGet, PSResourceGet, and R either did not verify via lockfile or were out of scope.
In the study, only Go verified signatures by default; most required configuration, had incomplete implementations, or provided no signatures.

Inference

Organizations should empirically test whether hash and signature verification fail-closed in CI, rather than relying on the presence of lockfiles.
Repository compromise must be added to threat models, requiring a review of trust boundaries for mirrors, proxies, and caches.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Unknowns and Additional Investigation."

15. Implications for Defenders

Assuming repository compromise in addition to developer account protection means that the mere presence of HTTPS, lockfiles, hashes, and signatures is insufficient. Each ecosystem must be tested to ensure verification is actually enforced in CI.

16. Summary by Target Audience

For SOCs: Monitor for hash mismatches, signature failures, and repository endpoint changes during dependency retrieval.
For Administrators: Enforce the hash and signature verification supported by the products in use in CI, and confirm that mismatches stop processing.
For Users: Developers should review lockfile management policies and verification settings for the package manager in use, taking account of whether they are developing an application or a library.

Hirudo: Replaces Banking Apps to Tamper with Local Signature, Accessibility, and Play Integrity Checks

Anoymask — Thu, 15 Oct 2026 15:23:59 +0000

1. Basic Information

Article Name: Hirudo: From Fake Updates to Patched Banking Apps
Publisher: ThreatFabric
Publication Date: 2026-10-14
Original Source: ThreatFabric
Related Sources: BleepingComputer: Hirudo Android malware replaces banking apps, Android Developers: Play Integrity standard requests, MITRE ATT&CK: T1476, MITRE ATT&CK: T1417.002
Related Malware & Threat Actors: Hirudo
Related CVE: None
Related Products: Android, eight Indonesian banking apps, Shopora, 1V1 X, ZoyaTV, KoiShort
Importance: High

2. Executive Summary

A dropper disguised as shopping and video apps uses a fake update to deploy the Hirudo RAT, which attempts to remove legitimate banking apps and replace them with patched copies. YAHFA and Dobby hooks tamper with the app's local checks for signatures, accessibility, screen capture, and Play Integrity results.

3. Attack Flow

After RAT installation, banking-app replacement and credential theft through fake screens or remote-control features are separate capabilities. Interrupting replacement alone does not establish that the other capabilities have also been stopped.

Common Installation Path

Users install lure APKs after being directed to them through advertisements or similar channels.
A fake in-app update prompts installation of Hirudo as a separate APK, which requests accessibility and notification access.

Banking-App Replacement Path (Seven Banks, Eight Apps)

Hirudo detects a targeted banking app, opens its uninstallation screen, and downloads the patched copy in parallel. Uninstallation and installer authorization are required.
When the patched app starts and the shared trigger file created by the RAT is present, the analyzed hooks interfere with security decisions inside the app.

Related Capabilities (Not Mandatory Steps After Replacement)

The RAT collects PINs and passwords through fake payment and authentication screens and sends them to the backend.
It also supports screen sharing, camera access, SMS collection, and remote control. These capabilities do not establish that every feature ran on every device.

4. Attacker Positioning and Prerequisites

Attackers capable of distributing unofficial APKs, and malware granted accessibility permissions on the device.

5. Observable Indicators for Victims and Administrators

Victim-Side

Fake updates, banking-app reinstallations, and fake checkout success screens are displayed.

Administrator-Side

Inference: Depending on the management setup and collection capabilities, app inventories may show unknown APKs or replaced banking apps, alongside changes to signatures and accessibility settings. Where network records are collected, traffic to CloudFront or integrity-relay destinations may be available as artifacts.

6. Success and Failure Conditions

Success Conditions

Sideloading the lure APK and granting permissions to Hirudo.
The banking-app replacement path requires removal of the legitimate app and authorization to install the patched APK. Users can interrupt either step.

Failure Conditions and Defensive Limits

Restrict installation of unofficial APKs. Verify Play Integrity server-side, binding the check to the session and protected action, and combine it with attestation-key revocation checks and transaction-risk controls.
Inference: Where supported by management or protection products, restrict suspicious APKs, unauthorized accessibility services, and communications with known relay destinations. Do not rely solely on decisions made inside the app.

7. What Happens If the Attack Succeeds

Theft of banking credentials, PINs, device-unlock secrets, and SMS messages.
Unauthorized transactions enabled by live screen viewing, camera access, and remote control.
Bypassing local security controls in banking apps.

8. Observable Logs

Email: Inference: Advertising and web downloads are the principal reported delivery routes; email delivery has not been confirmed.
Proxy/SWG/DNS: Inference: Check communications involving CloudFront downloads, helloharmonyos, baojingtextile, and the Play Integrity relay.
Endpoint/EDR: Inference: Check for unknown APKs, test-key signatures, accessibility services, and uninstallation of legitimate banking apps.
Identity/IdP: Inference: Check banking logins and abrupt changes in device fingerprints.
SaaS/Cloud: Inference: Use MDM to compare app inventories and installation sources within its managed scope. Review Play Protect verdict history where the product makes it available.
Network: Inference: Check MQTT traffic on ports 1883/1884, HTTP traffic on ports 8085/18085, and WebRTC communications.

9. Verification Scope

Information Theft or Session Compromise Confirmed

Scope: Within the scope confirmed by public information
Basis: Public information: Backend records obtained by ThreatFabric in August 2026 included thousands of application-credential entries and device records. They did not establish the number of unique victims or successful banking-app replacements.

Internal Assessment Criteria

Differentiate contact, execution, data access, and subsequent compromise; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Start from unknown APKs, accessibility permissions, banking-app reinstallations, and IOC communications.
Initial Verification: Check app inventories, installation sources, signing certificates, accessibility settings, and targeted banking apps.
Device and Server Investigation: Isolate the device from the network and collect APK hashes, accessibility data, SMS messages, camera artifacts, and WebRTC artifacts.
Authentication and Cloud Investigation: Check banking sessions, beneficiaries, payments, and password resets.
Subsequent Operations: Track credential reuse, SIM/SMS abuse, and expansion to other financial apps. Also correlate available communications records for CloudFront and integrity-relay destinations.
Containment: Inference: Isolate the device and preserve evidence, then contact the bank through its official channels to check transactions and accounts. Follow the recovery plan and consider a factory reset after assessing the impact of data erasure. Change banking and device credentials from a separate, clean device.
Classification: Differentiate lure installation, RAT permissions, banking-app replacement, credential transmission, and unauthorized transactions.

11. Defense and Detection Ideas

Single Event: Detect events where a banking app's signature changes to a public test key.
Timeline Correlation: Correlate lure installation, fake updates, accessibility use, banking-app uninstall/install events, and external communications.
Threat Hunting: Search for IOC hashes, package names, CloudFront routes, and MQTT endpoints.
Log Limitations: Prioritize server-side decisions because local device signals can be spoofed by hooks.
Prioritized Countermeasures: Prioritize restricting APK sideloading, using MDM, checking attestation revocation, and controlling transaction risks.

12. Facts / Inference / Hypothesis

Facts

Hirudo is delivered as a fake update from functional lure apps for shopping, adult video, and short dramas.
The RAT includes 42 financial apps in its registry and has dedicated patched APKs for seven banks and eight apps in Indonesia.
Its replacement mechanism removes the legitimate app and installs a patched copy with the same package name and version, signed with a public test key.
The analyzed patched build uses YAHFA and Dobby to interfere with signing-certificate checks, accessibility-service lists, screen-capture restrictions, key attestation, and Play Integrity decisions. Hook activation requires a shared trigger file created by the RAT.
Play Integrity requests are relayed in plain HTTP to the attacker's server. ThreatFabric confirmed that at least two certificates in the bundled, publicly leaked keybox were on Google's attestation revocation list.
The RAT supports collection of credentials, payment PINs, device-unlock secrets, SMS messages, screen content, and camera feeds. Thousands of credential entries and device records were exposed on the backend.
Lures use CloudFront, OpenInstall, and Meta Pixel, and some routes remained active as of October 2026.

Inference

Public facts must be mapped to and verified against internal assets and logs.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "14. Open Questions and Additional Research".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1476	Deliver Malicious Application via Other Means	high	ThreatFabric reports delivery of lure APKs from sources outside authorized app stores. This is a Mobile delivery technique; the mapping does not establish successful installation on an individual device.
T1417.002	Input Capture: GUI Input Capture	high	ThreatFabric reports credential-capture capabilities using fake checkout screens and bank-specific input prompts. This maps to the Mobile technique for Android.

14. Open Questions and Additional Research

The exact number of victims, fraudulent transfer amounts, and operators have not been disclosed.

15. Impact on SOCs and Organizations

Hirudo can disable defenses inside a banking app's own process and has credential-theft and remote-control capabilities. Relying only on in-app checks to determine whether a device or app is trustworthy can therefore miss compromise. Combine the bank's server-side verification and transaction-risk assessment with monitoring of app signatures and accessibility settings on managed devices. The infrastructure identified by ThreatFabric is centered on Indonesia and can expand to multiple countries. However, numerous backend records should not be equated with victim counts or successful banking-app replacements; assess impact using evidence from your organization's devices and transactions.

16. Summary by Target Audience

For SOCs: Trace app replacements, test-key signatures, accessibility use, and integrity relays chronologically.
For Administrators: Restrict unofficial APKs. Combine server-side integrity verification bound to the session and protected action with attestation-key revocation checks and transaction-risk controls.
For Users: Do not install APKs or in-app updates from unofficial stores, and stop the process if a banking app is being uninstalled and reinstalled.

SneakPeek: Claude Code Desktop Preview Can Exfiltrate Local Secrets After Repository Cloning and a File Review Request

Anoymask — Thu, 15 Oct 2026 15:23:49 +0000

1. Basic Information

Article Name: SneakPeek: How the Preview Pane in Claude Code Desktop Can Exfiltrate Your Data
Publisher: Noma Labs
Publication Date: 2026-10-14
Source: Noma Labs
Related Sources: Dark Reading: Anthropic SneakPeek Flaw Is a Silent Zero-Click Threat, MITRE ATT&CK: T1041 Exfiltration Over C2 Channel, MITRE ATT&CK: T1195.001 Compromise Software Dependencies and Development Tools
Related Malware / Threat Groups: None
Related CVEs: Not yet published; Noma stated that publication of a CVE and GitHub Advisory was pending.
Related Products: Unpatched versions of Claude Code Desktop (the earliest affected version is unknown; Noma reports a fix in version 1.30096.1 and later), Electron (the rendering framework)
Importance: High

2. One-Sentence Summary

In Noma's test environment, when Claude Code Desktop previewed poisoned HTML files larger than 256KB from a repository, a chain of issues involving a file:// origin, missing CSP, and an inactive request filter allowed SSH keys, AWS/GitHub/npm tokens, and Kubernetes credentials to be exfiltrated using sendBeacon.

3. Attack Flow

Attack and Exploitation Vectors

An attacker places a poisoned coverage HTML file larger than 256KB in a repository that appears to be a normal project.
A developer clones the repository and asks Claude to review the files.
The preview pane automatically renders the file using a file:// URL and executes embedded JavaScript without a Content Security Policy (CSP).
A script or Web Worker reads local credential files and exfiltrates them externally using sendBeacon.

4. Attacker Position and Prerequisites

A supply-chain attacker capable of placing malicious HTML into a public repository.

5. What Victims and Administrators See

Victim Side

It appears as a normal coverage report review with no additional prompts or permission requests displayed.

Administrator Side

Inference: Temporary HTML files, credential-file access, and traffic to external destinations are potential investigation leads. The traces available depend on the monitoring products and their configuration.

6. Success and Failure Conditions

Success Conditions

An unpatched version of Claude Code Desktop (the earliest affected version is unknown; Noma reports a fix in version 1.30096.1 and later).
Triggering the preview by having Claude read an HTML file larger than 256KB.
Egress traffic permitted to the attacker's endpoint.

Failure Conditions and Defensive Limits

Verify that Claude Desktop version 1.30096.1 or later, which Noma identifies as fixed, is installed. Until the fix is applied, avoid previewing untrusted HTML.
Inference: Reducing long-lived secrets on endpoints limits potential impact; monitoring egress traffic and credential access supports detection. Neither measure guarantees prevention of arbitrary file reads.

7. What Happens If the Attack Succeeds

Exfiltration of SSH keys, cloud credentials, source-control tokens, and cluster credentials.
Inference: Stolen credentials could enable subsequent compromise of repositories, cloud environments, or Kubernetes clusters if they remain valid and have the necessary permissions.

8. Observable Logs

Email: Inference: If the developer was directed to the repository by email, retained messages may identify the sender and repository link.
Proxy / SWG / DNS: Inference: If HTTP logging is enabled on a proxy or secure web gateway, logs may show the destination and timing of an external POST; DNS logs may show name resolution. These records alone do not identify a sendBeacon call.
Endpoint / EDR: Inference: Where file-access telemetry is collected, Claude Desktop processes can be correlated with access to credential files. Whether file:// URLs or preview activity are recorded depends on the product and configuration.
Identity / IdP: Inference: Authentication audit logs can help investigate suspicious authentication associated with the targeted credentials. Not all API token usage appears in IdP logs.
SaaS / Cloud: Inference: If GitHub or cloud audit logging is enabled, logs may show operations performed using a token. Whether exfiltration succeeded must be established separately.
Network: Inference: Telemetry that links processes to network connections may help correlate Electron processes with traffic to external destinations.

9. Scope of Success Confirmation

Information Exfiltration or Session Compromise Confirmed

Scope: A proof of concept (PoC) in Noma's test environment.
Basis: Public disclosure: Noma reported arbitrary file reads and credential exfiltration in its laboratory PoC. This is distinct from confirmation of in-the-wild exploitation or subsequent compromise.

Internal Evaluation Criteria

Distinguish between contact, execution, information access, and subsequent compromise; do not infer unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Origin: Start from reviews of untrusted repositories, HTML previews exceeding 256KB, and Claude Desktop egress traffic.
Initial Checks: Verify app versions, repository origins, previewed files, and egress destinations.
Endpoint / Server Investigation: Preserve temporary HTML files, Electron caches, process file access, and credential file timestamps.
Authentication / Cloud Investigation: Investigate the usage of SSH, GitHub, npm, AWS, Kubernetes, and Claude tokens.
Subsequent Actions: Track repository modifications, cloud resource creations, and cluster access.
Containment: Update software, revoke or rotate tokens, isolate endpoints, and block malicious repositories.
Classification: Distinguish between previews, file reads, exfiltration, and token usage.

11. Defense and Detection Ideas

Single Events: Inference: Where network activity can be linked to processes, traffic from Claude Desktop to unapproved external destinations is a candidate for detection.
Temporal Correlation: Correlate repository clones, HTML previews, secret reads, sendBeacon requests, and cloud logins.
Threat Hunting: Search for coverage HTML files exceeding 256KB containing embedded scripts and blob workers.
Log Limitations: Inference: Ordinary network logs may not identify the sendBeacon API, and visibility into file reads depends on collection settings. Missing logs do not prove that execution did not occur.
Priority Actions: Prioritize upgrading to version 1.30096.1 or later, deploying secret managers, using short-lived tokens, and monitoring developer egress traffic.

12. Facts / Inference / Hypothesis

Facts

HTML files under 256KB were previewed using data URLs, while those over 256KB used temporary file URLs (file://).
The file:// paths lacked a script-src 'none' Content Security Policy (CSP), allowing local files to be fetched from the same origin.
Request filters failed to operate during static HTML previews, allowing JavaScript to read arbitrary local paths.
The proof of concept (PoC) successfully accessed SSH private keys, AWS keys, npm and GitHub tokens, as well as Kubernetes, Docker, Git, and Claude OAuth tokens.
navigator.sendBeacon allowed silent POST requests to the attacker's server without requiring additional approval.
An initial fix blocking fetch and XHR requests was bypassed using blob URL Web Workers.
According to Noma, the final fix was distributed in Claude Desktop 1.30096.1 and later on August 17, 2026, and Anthropic assessed the vulnerability as 8.7 under CVSS v4.0.

Inference

Public facts must be mapped to internal assets and logs for verification.
Reducing long-lived secrets on endpoints limits potential impact; monitoring egress traffic and credential access supports detection. Neither measure guarantees prevention of arbitrary file reads.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Uncertainties and Additional Investigation."

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1552.001	Unsecured Credentials: Credentials In Files	high	Noma reported reading local credential files in its test environment.

T1195.001 and T1041 are not assigned. Delivery through a public repository alone does not establish manipulation of software dependencies or development tools, and a one-way POST using sendBeacon alone does not establish an existing C2 channel.

14. Uncertainties and Additional Investigation

The presence of in-the-wild exploitation and the number of endpoints not running automatic updates remain unknown.
The earliest affected version, OS-specific scope, and details of the final fix cannot be established from the Noma article reviewed.
At the time of Noma's publication, a CVE and GitHub Advisory were pending publication.

15. Impact on SOCs and Organizations

In Noma's testing, cloning a repository containing crafted HTML and asking Claude to review that file led to credential exfiltration without additional approval. Automatic preview rendering also needs to be treated as a trust boundary. The initial fix was bypassed via Web Workers, and Noma reports that the final fix was delivered in version 1.30096.1 and later.

16. Target-Specific Summary

For SOC Teams: Review file access, egress traffic, and subsequent token usage related to Claude Desktop in a unified manner.
For Administrators: Update to version 1.30096.1 or later and remove long-lived secrets from developer endpoints.
For Users: Inspect HTML files and coverage reports from unknown repositories before letting Claude read them, and keep applications updated.

Storm-3119/Storm-2990: YAM Store and CoGUI Infrastructure Behind Over One Billion Phishing Emails and SMS Messages

Anoymask — Thu, 15 Oct 2026 15:23:38 +0000

1. Overview

Article Title: The hidden network: Inside the phishing infrastructure ecosystem powering global cybercrime
Publisher: Microsoft
Publication Date: 2026-10-14
Source: Microsoft
Related Sources: Proofpoint: Disruption Targets Major Chinese-Language Phishing Kits with Japanese Focus, Microsoft Learn: Compromised and malicious applications investigation, Microsoft Learn: Block authentication flows with Conditional Access, Microsoft Learn: How Conditional Access authentication strengths work
Related Malware and Threat Groups: Storm-3119, Storm-2990, CoGUI, CoAceV, CoFish_Ws
Related CVEs: None
Related Products: Microsoft 365, Google Workspace, CoGUI, Haozi, Iron Man System, YAM Store
Importance: High

2. Summary

YAM Store sold illicitly acquired Microsoft and Google environments to support phishing kits such as CoGUI, Haozi, and Iron Man. According to Microsoft, since January 2026, the related kits have supported the sending of over one billion phishing emails and SMS messages to more than 75,000 organizations. Japan and the United States were among the most heavily affected countries.

3. Attack Flow

Distinguish the compromise of infrastructure-supplier tenants from downstream phishing by customers who purchase that infrastructure. The following describes the relationship between supply and abuse, not a continuous intrusion sequence within a single victim organization.

Infrastructure Supply and Downstream Phishing: Different Actors and Environments

Storm-3119 uses application credentials from compromised tenants to retain administrative access and sells accounts, licenses, and storage. Separately, it also creates fraudulent organizations to obtain tenants.
Storm-2990 family kit operators purchase tenants, domains, storage, and licenses.
Affiliates send large volumes of emails and SMS messages mimicking Japanese consumer and finance brands.
Credential-stealing campaigns capture information entered on fake pages. In a separate path, attackers abuse device code authentication to induce users to authenticate to legitimate applications, allowing the attacker-controlled client to obtain tokens.
Stolen credentials are used for account takeover and fraud.

4. Attacker Position and Prerequisites

On the supply side, Storm-3119 abuses application credentials or administrator privileges in compromised tenants. Downstream attackers purchase cloud infrastructure or phishing kits and target users.

5. Visible Indicators for Victims and Administrators

Victim Side

Users view notifications or login pages resembling legitimate brands and enter credentials and payment data.

Administrator Side

Manifests as new tenants, expired domains, high-volume mail traffic, suspicious redirects, and brand impersonation.

6. Success and Failure Conditions

Success Conditions

The reputation of a spoofed tenant or domain may help evade reputation-based detection, but does not guarantee passage through delivery controls.
Credential-stealing campaigns require users to enter information on fake pages. Device code phishing requires the flow to be allowed and the user to complete the authentication prompted by the attacker.

Failure Conditions and Defensive Limits

Detect using a combination of domain age, tenant provenance, URL chains, and login context.
Require phishing-resistant MFA, such as FIDO2, through Conditional Access authentication strengths, and apply session protection where supported.
Following Microsoft's guidance, audit device code flow usage and block unnecessary use with Conditional Access. Make exceptions only for necessary business uses, assess operational impact in report-only mode, and then enable enforcement.

Inference: Deploying FIDO2 alone does not establish that the device code phishing path is blocked. Check the required authentication strength, the users and resources covered by Conditional Access, policy exclusions, and the authentication flows that remain allowed.

7. What Happens If the Attack Succeeds

Credential and payment data theft leading to account takeover.
Large-scale email and SMS fraud targeting Japanese organizations.
Abuse of cloud infrastructure reputation.

8. Observable Logs

The following are investigation candidates. Availability depends on products, permissions, logging configuration, and retention. Missing records do not prove the absence of compromise.

Email: Inference: Examine templates associated with CoGUI and related kits, sender tenants, Reply-To values, and redirect chains.
Proxy/SWG/DNS: Inference: Examine access to domains associated with YAM Store or the kits, newly registered domains, and expired domains that have been reused.
Endpoint/EDR: Inference: Examine browser history, downloads, and credential prompts.
Identity/IdP: Inference: After phishing, look for new devices, impossible travel, added MFA methods, and mail rule changes. Also check device code flow usage and Conditional Access decisions.
SaaS/Cloud: Inference: In a supplier tenant, correlate available audit logs for application registrations, credential changes, permission grants, and license or storage operations. A downstream victim organization may not have direct access to the supplier tenant's internal logs.
Network: Inference: Examine relationships between high-volume email sources and landing-page infrastructure.

9. Scope of Verified Success

Attack Attempt Observed (Success Unconfirmed)

Scope: Scope confirmed by public information
Basis: Although the transmission of over one billion messages has been confirmed, this does not imply successful credential theft for all messages.

Information Theft or Session Compromise Confirmed

Scope: Scope confirmed by public information
Basis: The kits acquire credentials and payment data, and related account takeovers have been observed.

Determination Criteria for Your Organization

Separate contact, execution, data access, and subsequent compromise; do not assume unconfirmed success from a single alert.

10. Investigation Playbook

Investigation Starting Point: Start with brand impersonation, related domains, and post-phishing identity alerts.
Initial Verification: Check message headers, URL chains, domain history, sender tenants, and user clicks.
Endpoint and Server Investigation: Check browser artifacts, downloads, tokens, and saved credentials.
Authentication and Cloud Investigation: Investigate logins, MFA changes, OAuth grants, mail rules, and session tokens. If compromise of a supplier tenant is suspected, also examine service principal sign-ins, credential changes, and application permissions.
Subsequent Actions: Track payment fraud, BEC, internal phishing, and credential reuse.
Containment: Revoke sessions, reset credentials, enforce phishing-resistant MFA, and block domains and tenants. For a compromised application, identify its owner and assess operational impact, then disable sign-in, rotate credentials and remove old ones, and correct excessive or unauthorized permissions.
Classification Categories: Separate delivery, clicks, credential submissions, authentication, and fraud.

11. Defense and Detection Ideas

Single Events: Detect brand login URLs originating from new or recycled domains.
Timeline Correlation: Correlate messages, clicks, credential submissions, new logins, and mail rule modifications.
Threat Hunting: Retroactively search for infrastructure related to CoGUI, CoAceV, CoFish_Ws, Haozi, and Iron Man.
Log Limitations: A downstream victim organization may not have direct access to a supplier tenant's internal logs. Availability depends on permissions, configuration, and retention.
Priority Countermeasures: Alongside email and URL defenses, verify the scope of policies requiring phishing-resistant MFA and block unnecessary device code flow usage with Conditional Access. Also establish session revocation procedures and brand monitoring. Domain seizures do not imply the shutdown of the entire affiliate infrastructure, so continue monitoring related domains and tenants.

12. Facts, Inference, and Hypothesis

Facts

Microsoft tracks YAM Store as Storm-3119 and three major phishing kit operations as Storm-2990.
Microsoft reports that, since January 2026, the related kits have supported the sending of over one billion emails and SMS messages to more than 75,000 organizations.
Japan and the United States were the most heavily affected countries; targeted sectors included finance, healthcare, distribution, and IT.
YAM Store sold compromised or fraudulent Microsoft and Google tenants, domains, credentials, storage, and licenses.
Automated processes reused expired organization names and real customer details to fabricate educational and nonprofit appearances.
CoGUI, Haozi, and Iron Man provided brand impersonation templates and credential capture, while Proofpoint assessed a high-confidence common root for CoGUI, CoAceV, and CoFish_Ws.
Microsoft and Health-ISAC pursued litigation and domain seizure or redirection; Proofpoint, JC3, and other partners supported the investigation and disruption.
Storm-3119 retained administrative access to tenants through app-only authentication using stolen application client secrets. This access does not depend on an individual user session.

Inference

Public facts must be mapped and verified against your organization's assets and logs.
Deploying FIDO2 alone does not establish that the device code phishing path is blocked. Check the required authentication strength, the users and resources covered by Conditional Access, policy exclusions, and the authentication flows that remain allowed.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unresolved Points and Additional Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1566.002	Phishing: Spearphishing Link	high	Maps to Microsoft's observation of phishing emails containing malicious links.
T1583.001	Acquire Infrastructure: Domains	high	Downstream attackers acquire illicitly obtained domains from YAM Store.
T1078	Valid Accounts	high	Reuses stolen credentials for subsequent access.

14. Unresolved Points and Additional Investigation

The extent of remaining affiliate infrastructure, reconstruction speed, and total financial loss after the seizures remain undetermined.

15. Impact on SOCs and Organizations

Cloud environments reusing legitimate or expired organization data combined with high-volume transmission kits delivered large-scale credential phishing to Japanese organizations that was difficult to detect using standard tenant reputation alone. App-only access in a supplier tenant does not depend on individual user sessions. If a similar application compromise is suspected in your organization, investigate application credentials and permissions in addition to revoking sessions. Downstream victim organizations cannot rely on access to the supplier's internal logs, so use received emails, URLs, and authentication logs to determine the stage of compromise.

16. Summary by Target Audience

For SOCs: Do not confuse delivery volume with actual compromise; verify up to post-click identity events.
For Administrators: Require phishing-resistant MFA, such as FIDO2, through authentication strengths, and review Conditional Access coverage, exclusions, and allowed flows. Block unnecessary device code flow usage, make exceptions only for necessary business uses, and assess operational impact before enforcement. Also establish monitoring for new tenants and domains and session revocation procedures.
For Users: Do not log in via links in emails or SMS; use official apps and bookmarks instead.