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.
[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:
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:
This aligns with publicly known credential lists that attackers use for large scale reconnaissance.
Successful Connections
During the analysis window, I observed:
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:
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:
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:
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:
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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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.
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.
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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
It’s Friday, let’s have a look at another simple piece of malware to close a busy week! I received a Fedex notification about a delivery. Usually, such emails are simple phishing attacks that redirect you to a fake login page to collect your credentials. Here, it was a bit different:
Nothing really fancy but it is effective and uses interesting techniques. The attached archive called "fedex_shipping_document.7z" (SHA256: a02d54db4ecd6a02f886b522ee78221406aa9a50b92d30b06efb86b9a15781f5 ) contains a Windows script (.bat file) with the same filename. This script, not really obfuscated and easy to understand, receiveds a low VT score, only 12/61!
First, il will generate some environment variables and implement persistence through a Run key:
The variable name "!contract" contains the path of a script copy in %APPDATA%RailEXPRESSIO.cmd. The threat actor does not use the classic environment variable format “%VAR%” but “!var!”. This is expanded at execution time, meaning it reflects the current value inside loops and blocks[1]. It’s enabled via this command
setlocal enableDelayedExpansion
Simple but nice trick to defeat simple search of "%..%"!
Then a PowerShell one-liner is invoked. The Powershell payload is located in the script (at the end) and Bas64-encoded. A nice trick is that the very first characters of the Base64 payload makes it undetectable by tools like base64dump! PowerShell extracts it through a regular expression:
Once the payload decoded, it is piped to another PowerShell:
The PowerShell implements different behaviors. First, it will create a Mutex on the victim’s computer:
Strange, it seems that some anti-debugging and anti-sandoxing are not completely implemented. By example, the scripts gets the number of CPU cores (a classic) but it’s never tested!
The script waits for the presence of an « explorer » process (which means that a user is logged in) otherwise it exists:
There is a long Base64-encoded variable that contains a payload that has been AES encrypted. The IV and salt are extracted and the payload decrypted. No time to loose, run the script into the Powershell debugger and dump the decrypted data in a file:
The decrypted data is the next stage: a shellcode. This one will be injected into the explorer process and a new thread started:
This behavior is typical to DonutLoader[2].
The shell code connects to the C2 server: 204[.]10[.]160[.]190:7003. It's a good old XWorm!
[1] https://ss64.com/nt/delayedexpansion.html
[2] https://medium.com/@anyrun/donutloader-malware-overview-00d9e3d79a48
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.
![Differentiating Between a Targeted Intrusion and an Automated Opportunistic Scanning [Guest Diary], (Wed, Mar 4th)](https://www.ironcastle.net/wp-content/uploads/2026/03/status-2.gif)
