Observations from running Open Windows Shares on the Internet
When the OpenCanary honeypots were initially configured with open SMB (Windows) shares, the assumption was that attackers would occasionally discover them and exfiltrate data. To lure them in, we seeded the shares with enticing filenames like “passwords.xls“, generated using Canary Tokens.
Additionally, the shared folders were set up to mimic an antivirus product—allowing files to be written but then instantly moving them (making it appear as if the antivirus had deleted them). Remarkably, no matter what username and password the attacker uses will succeed (and of course be logged).
However, it quickly became apparent that attackers weren’t interested in stealing data from these shares, as the Canary Tokens were rarely triggered. Instead, those scanning the internet for misconfigured machines began using the shares as a drop point for malware.
Throughout 2024, the three honeypots collected over 24,000 dropped files—most of them malware.
The standout was the Sentinel honeypot, hosted on Google Cloud in California. It attracted thousands of malware samples per month, far surpassing the combined total of the other two honeypots.


The Digger honeypot, hosted on a residential ISP network in Switzerland, might have seemed like the most attractive target. Attackers could have assumed that home networks—often used by less security-savvy individuals—would yield more victims.
Yet, Google Cloud proved far more appealing, likely because attackers believed datacenters offered richer rewards in data or resources. However, this doesn’t fully explain why the Sentinel honeypot (California) was hit significantly harder than the Armada honeypot (also in Google Cloud, but on the US East Coast). Perhaps attackers simply found it first.
Monthly trends remained consistent, with 2,000–3,000 malware samples typically dropped onto the shares each month for most of the year.
Only four distinct files were dropped onto the shares. The most prevalent was a 55kb executable file – always with a different filename – that would give attackers full control if executed. More interestingly is that this malware has been known and detected by antivirus products since 2016.
This single file variant accounted for 24,159 of 24,467 samples (98.7%) in 2024, with all other malware types making up just the remaining 308 cases.

With over 98% of samples being the same remote access tool, the attacker’s intent was clear: they wanted the file executed on the host system. Their strategy relied on victims accidentally running the file, which would grant the attacker persistent control of the machine.
Once inside, the attacker could:
- Move laterally through the network
- Steal sensitive data
- Use the compromised host as a foothold for further attacks
This approach exploits three critical weaknesses:
- Human error (accidental execution)
- System misconfigurations (unsecured shares)
- Inherent trust in files within shared network environments
This is not new and the approach was seen many years ago with the MSBlaster worm (also known as Blaster or Lovsan) which was one of the most disruptive cyberattacks of the early 2000s. It spread aggressively by exploiting Windows RPC vulnerabilities (CVE-2003-0352) and leveraged open administrative shares (ADMIN,C,C) to propagate across networks. This worm demonstrated how poorly secured file shares, weak passwords, and delayed patching could lead to catastrophic breaches.
The lessons to learn today as this similar cycle repeats and mutates are:
1. Patch Immediately—Zero-Day Exploits Won’t Wait For You
- It’s often the case that a service such as a file share may be exposed due to a software flaw.
- Enable automatic updates for critical systems (including antivirus).
- Prioritize patch management—especially for internet-facing services.
2. Lock Down File Shares—They’re a Major Attack Surface
- Remember default open shares create an attack surface. Configuration is important, you need to configure services on and off (some are enabled by default).
- Disable unnecessary shares (or restrict them with firewall rules).
- Require strong authentication (multi-factor where possible).
- Monitor SMB traffic for unusual file transfers.
3. Assume Lateral Movement—Segment Networks
- Once inside, an attacker will try to jump from machine to machine.
- Implement Zero Trust policies (least-privilege access).
- Segment critical networks to limit worm spread.
4. Educate Users—Human Error Fuels Attacks
- Many infections happened because users execute malicious files on shares.
- Train employees on spotting suspicious files.
- Block executable files from being run in shared folders.