Tales from the field - the degausser

Until recently I had never seen nor used a degausser. Sure I'd read about them, heard folks talk about them, but never had the fun of using one or seeing one in use. The solution of choice had been to ship the drives out for shredding. With the economy being what it is we invested in a degausser that looks something like this



Like anyone else that gets a new toy we were excited to test this thing out. We had a few spare hard drives ready for destruction and wanted to see if degaussing even worked. The instructions were simple: put a drive in the tray, put the gloves on, and step on the peddle. Swirl the tray around in the provided circles for 10 seconds per side, and voila you'll have a cooked drive.

Sounded simple enough....

First we tried a 2.5" drive. BBBBBRRRRRRRRRRMMMMMMMMMMMMM...the degausser sounded off as it did its dirty work. Flip the drive over and BBBBBRRRRRRRRRRMMMMMMMMMMMMM...We pulled the drive off. Yep, it was toasty alright and it was accompanied by the the smell of hot metal. I took the drive back to my workstation after it had cooled off a bit. I wanted to see what had happened and wanted to see if the drive was still usable.

I plugged it in to my trusty writeblocker and turned on the writeblocker. The familiar whirring of the platters was quickly accompanied by a shocked "HOLY @$*%" coming out of my mouth. I could read the drive just fine. Not only was the drive intact, the filesystem was consistent and boy could I read the files. I quickly called over my teammates and we all looked at the drive contents as if we'd never seen a directory before.

Quickly I ran down the hall accompanied by another round of BBBBBRRRRRRRRRRMMMMMMMMMMMMM as the degausser chewed up another drive. This time it was a 3.5". I walked in to the room as the tray rattled around on top of the degausser. Not long after I entered the room was I walking back down the hall with two very hot hard drives in hand. I couldn't wait to see these not work.
I plugged in one drive and wouldn't you know it, I could read that one too. In disbelief I tried the other one. Yep I could read that one too. I pulled the drive from the write blocker and tried to format it. That actually did not work. Ok, so I could read the drive but could not write to it. That's reassuring but I care about someone being able to read it.

It was as if I'd been punched in the face. It was then that I recalled what the gentleman at EDR said when I was talking to him at technosecurity. He said "The problem with degaussers is that yeah sure, it's been marked as degaussed, but that's all you've got. Someone else saying they ran that drive through a degausser. What guarantee do you have that the drive is useless?"

Apparently I had no guarantee that the degausser works. If we couldn't get it to work properly, how would the people at the location actually housing this thing be able to ensure the drives were rendered useless. Promptly the vendor was contacted. They suggested we try to rotate the drive on another axis in addition to laying the drive flat. Willing to give it another try we turned the drive on its side and rotated it for the prescribed time. This time when I plugged in the drive, I could not read it. This was reassuring. Each successive time we tried a drive I was unable to read it.

This certainly reinforced the need to test all new equipment regardless of what its purpose is. It also reinforces the need to periodically verify the equipment to ensure its still working and you can trust it. Degaussing a drive is an interesting experience. I know that I for one would rather see a drive physically shredded, ground or smelted than degaussed. At least that way I can guarantee the drive is useless.

Have any degaussing stories?

Tales from the field

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.dd

OS 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/case
root(sda1)]#mount -t vfat -o offset=16384,ro,noexec,noatime,nosuid,nodev usb.dd /tmp/case


After 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.exe
iams.wearabz.net
svchost.exe
explorer.exe
f424
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 cwsandbox
Results 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 here


Some 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.