To me, "data hiding" means much more than steganography, from the Greek for "covered writing". To me, it means hiding data, through any means.
The most simple means of hiding data that remains extremely effective today is simply changing the name of the file. This is effective against your usual, everyday admin, who's overtasked, undertrained, and underpaid. Here's one really good example...install a bit of malware, say, a backdoor, on a system. Put it in a temp directory and call it "svchost.exe" (10 points to anyone who can tell me why writing that file to the system32 directory won't be effective). Launch it, and then open Task Manager, and tell me which one of the listed "svchost.exe" processes is the malware, and why (random guessing doesn't count). 'Nuff said.
Many moons ago, I wrote a pretty detailed paper on NTFS Alternate Data Streams (ADSs). I'm not providing a link here, as I'll be updating and moving the paper soon. However, those updates are relatively minor, given the fact that the operating system vendor provides no means of detecting or viewing the existence of arbitrary ADSs within the filesystem. The vendor provides applications (Indexing Server) and functionality (Summary tab in File Properties dialog) that make use of ADSs, but nothing in the Explorer shell to see if there are any ADSs. In the paper I wrote, I suggested that the vendor employ an icon for an alternate data stream that's a scarlet "A".
There are other means of hiding data in a live system...via OLE "structured storage", in the Registry, etc. My hope is that providing this information in my book, via instruction, and via conference presentations, the level of security awareness will be raised and these means will be less effective.
3 comments:
"Put it in a temp directory and call it "svchost.exe" (10 points to anyone who can tell me why writing that file to the system32 directory won't be effective)."Is there something to do with system32\dllcache\ or Windows File Protection?
There's already a svchost.exe in %SystemRoot%\System32 and I don't think you want to mess with it...
Okay, two responses so far, and you guys are both on the right track.
For some reason, not a lot of A/V companies point this out when they talk about how specific malware infects a system. The point is that if malware or a malicious user attempts to write a file called %WINDIR%\system32\svchost.exe, Windows File Protection (if no steps have been taken to disable it) will "wake up" and replace that file with the known good from the dllcache directory and write an entry to the Event Log.
Remember the "Teddy Bear" virus hoax? This was the email that was going around a while back that stated that the user should delete "jdbgmgr.exe"...a file which had a teddy bear as an icon. On Windows 2000, this file is protected by WFP, which is good, b/c one of the users at the company I was at deleted the file, *then* told me about the email.
Post a Comment