Honeynet Field Notes, Day 2: WannaCry Is Still Working Port 445

The Day 1 post covered a Mirai loader and a Perl IRC DDoS bot that came in over SSH and Telnet. The second pull from the sensors added something older and, honestly, more surprising: a WannaCry launcher delivered over SMB through DoublePulsar, nine years after the original outbreak.

The Mirai loader and the Perl bot from Day 1 also appear in this pull with identical hashes, so I won’t repeat that analysis here. Everything below is new material.

As before, every sample was analyzed statically. Nothing was executed, and no attacker host, distribution server, or C2 was contacted.

WannaCry, Delivered Through DoublePulsar

#

The delivery session

#

During the first collection window, a single source connected to the sensor’s SMB service on 445 and walked through the full MS17-010 sequence:

• SMB1 negotiate
• Session setup, with the client identifying itself as Windows 2000 (build 2195)
• Tree connect
• 1,289 Trans2 SESSION_SETUP packets, carrying about 5.38 MB from the attacker to the sensor None of those packets contained a cleartext MZ header. That’s consistent with DoublePulsar, which pushes its payload in XOR-encoded chunks through the Trans2 SESSION_SETUP channel after EternalBlue installs the backdoor. The honeypot’s DoublePulsar emulation reassembled and decoded the chunks into a complete DLL.

The source made three sessions in total. Three other SMB talkers in the same window ran between 23 and 44 sessions each, but their traffic topped out around 81 KB. That’s the profile of MS17-010 scanners that never delivered a payload.

The launcher DLL

#

The delivered file is a 5.27 MB 32-bit DLL with a very small footprint of actual code:

• Export name launcher.dll, with a single export: PlayGame
• Imports limited to resource handling, file writing, and CreateProcessA
• Strings C:\%s\%s, WINDOWS, and mssecsvc.exe
• One 5 MB resource of type W, ID 101
• Compile timestamp of May 11, 2017, one day before the global WannaCry outbreak The logic is simple. PlayGame pulls the embedded resource, writes it to C:\WINDOWS\mssecsvc.exe, and launches it. This is the well-documented x86 DoublePulsar stage of WannaCry, and every structural detail lines up with the May 2017 strain.

The embedded worm

#

Carving the resource produced a 32-bit executable with the same size as the canonical WannaCry mssecsvc.exe, 3,723,264 bytes. The family indicators inside it are unambiguous:

• The original kill-switch domain
• Service name mssecsvc2.0 and dropper tasksche.exe
• The WANACRY! marker, the WNcry@2ol7 archive password, and the t.wnry and r.wnry components
• The icacls . /grant Everyone:F /T /C /Q and attrib +h . commands
• Two Bitcoin wallets that match publicly known WannaCry ransom addresses
• Imports from WININET, WS2_32, and IPHLPAPI for the kill-switch check and SMB propagation
  The kill switch is still doing its job. This build checks the original kill-switch domain before detonating. That domain has been sinkholed since May 2017, so on a host with normal DNS and internet access the worm exits without encrypting anything. Hosts on isolated networks, or networks that block or fail to resolve that domain, don’t get that protection. If your DNS filtering policy sinkholes or blocks newly seen or “random-looking” domains, it’s worth confirming that this one still resolves.

This is significant because it’s almost certainly not an operator choosing to deploy WannaCry in 2026. The worm is self-propagating, and the most likely source is a Windows host that’s been infected for years, still running, and still scanning the internet for SMB. The kill switch prevents the ransomware from firing in most environments, but it doesn’t stop the propagation component that brought it to my sensor.

The carved payload’s hash didn’t turn up in the public write-ups I checked. The size, strings, wallets, and kill-switch domain all match the 2017 strain, so I’m treating it as WannaCry and pending a reputation lookup to confirm whether this exact byte image is already catalogued.

EternalBlue at Volume

#

The second sensor didn’t receive a payload, but its SMB service had a busy day. In a single day it logged 14,165 SMB sessions, nearly all from two hosts:

The 80 KB sessions have the same shape as the scanners on the first sensor: EternalBlue exploit attempts that never moved on to a DoublePulsar upload. Two hosts running the same exploit attempt thousands of times in a loop looks much more like infected machines on autopilot than an operator working a target.

Between the two sensors, the SMB picture is consistent. MS17-010 traffic is still a background constant on the internet, and at least some of it is coming from hosts that are themselves compromised.

An Attacker Staged an Outbound SSH Identity

#

On the SSH side, one attacker left behind two small files that read more like tradecraft than malware.

The first was an unencrypted OpenSSH ed25519 private key with the comment dlr@sftp. The second was a 55-byte SSH client config that sets StrictHostKeyChecking no and UserKnownHostsFile /dev/null.

Both were written with the same one-line echo technique, with line breaks replaced by ; , which points to the same actor or the same tooling.

Put together, the most likely reading is that the attacker was preparing the “compromised” host to connect outbound to their own infrastructure. A pre-staged key lets the box SFTP or SSH out without a password, and the config ensures it never stops at a host-key prompt. That would support uploading collected data or pulling a later stage without any interactive step.

I haven’t correlated these files to a specific session’s source IP or credentials yet, so I’m not tying them to either of the Day 1 actors.

The public key and fingerprints derived from the dropped private key are useful for hunting in authorized_keys files and SSH auth logs:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO94S34m0hVkYFUhtWQe92S9Cp0yJp+7n8gw696Uf/LG dlr@sftp
SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg
MD5:26:41:89:c9:07:fb:ff:09:27:a2:cd:39:97:62:2b:62

I’m not publishing the private key itself.

A Printer Probe, for Completeness

#

The printer emulator on port 9100 recorded a 15-byte payload: the PJL Universal Exit Language header, <ESC>%-12345X@PJL. It’s a printer-discovery probe of the kind internet-wide scanners send to fingerprint devices. No print job and no malware, but it rounds out the picture of what reaches an exposed IP in a day.

Indicators of Compromise

#

Source IP addresses are intentionally withheld. The SMB sources are almost certainly infected hosts rather than attacker-owned infrastructure, so publishing them would name victims without giving defenders anything a hash or domain doesn’t already provide. Sensor timestamps are also omitted.

Network

#

File hashes (SHA-256)

#

launcher.dll MD5: ae12bb54af31227017feffd9598a6f5e

Host and behavioral

#

• C:\WINDOWS\mssecsvc.exe, a service named mssecsvc2.0, or tasksche.exe
• DNS lookups for the kill-switch domain from internal hosts
• Inbound SMB sessions with a high count of Trans2 SESSION_SETUP requests
• SSH key SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg (dlr@sftp) in any authorized_keys file or auth log
• An ~/.ssh/config containing StrictHostKeyChecking no and UserKnownHostsFile /dev/null on a server that shouldn’t need it

Detection Takeaways

#

Kill-switch lookups are an infection signal. A DNS query for the WannaCry kill-switch domain from inside your network means something there is running the worm. It’s one of the cheapest high-fidelity detections available, and it still works.

DoublePulsar has a network shape. An unusually large number of Trans2 SESSION_SETUP requests in a single SMB session is the backdoor’s upload channel. Existing IDS signatures for DoublePulsar and EternalBlue are mature, and it’s worth confirming they’re enabled rather than retired as legacy.

SMBv1 should be off. Disabling SMBv1 removes the protocol EternalBlue depends on. If something in the environment still needs it, that host is a known exception that belongs on a segmentation and monitoring list.

Outbound SSH from servers is worth baselining. The staged key and config only matter if the host can reach the attacker’s server. Servers that never initiate outbound SSH are a good candidate for egress restrictions, and an unexpected outbound session on 22 is a useful alert.

Watch for client configs that disable host-key checking. Legitimate automation sometimes sets these options, but a new ~/.ssh/config with both of them on a production host is worth a look.

What’s Next

#

The sensors stay up. Day 1 was SSH and Telnet commodity malware. Day 2 showed that the SMB surface is mostly catching worms that have been propagating on their own for years. I’ll keep pulling and sharing as long as there’s something new to report.