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].
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:
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.
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|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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.
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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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.
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|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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.
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 "HKCUSoftwareMicrosoftWindowsCurrentVersionRun" /v csgh4Pbzclmp /t REG_SZ /d ""%APPDATA%MicrosoftWindowsTemplatesdwm.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%MicrosoftWindowsTemplatesdwm.cmd" >nul 2>&1
Just after the copy operation, a PowerShell one-liner is executed:
powershell -w h -c "try{Remove-Item -Path '%APPDATA%MicrosoftWindowsTemplatesdwm.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 (1 = My Computer, 2 = Local intranet, 3 = Trusted sites, 4 = Internet, 5 = 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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.