Something I caught over on Weare4n6 recently was that there's a new book on it's way out, due to be available in Oct, 2016, entitled, "Data Hiding Techniques in Windows OS". The description of the book on the blog is kind of vague, with references to steganography, but I'm hoping that it will also include discussions of things like ADSs, and using Unicode to "hide" files and Registry keys/values in plain sight.
My initial reaction to the book, however, had to do with the cover. To the right is a copy of the cover of my latest book, Windows Registry Forensics. Compare that to the book cover at the web site. In short, it looks as if Elsevier is doing it again...previous editions of my books not only had the same color scheme amongst the books, but shared that color scheme with books from other authors. This led to massive confusion; I once received a box of books just before I left for a conference, and I took a couple of copies to give away while I was there. When I tried to give the books away, people told me that they "...already had the book...", which I thought was odd because I had just received the box. It turned out that they were looking at the color scheme and not actually reading the title of the book.
Right now I have nine books on my shelf that have the same or very similar color schemes...black and green. I am the sole author, or co-author, of four of them. The other five have an identical color scheme...a slightly different shade of green...but I am the author of only one of them.
Imaging
Mari's got another great post up, this one about using a Linux distro to image a Mac. Yeah, I know, this blog isn't about Macs, but this same method could potentially be used to image a Windows server that you're having trouble with. Further, Mari is one of the very few people within the community who develops and shares original material, something the community needs to encourage with more analysts.
Carberp Updates
A couple of articles appeared recently regarding changes to Carberp (PaloAltoNetworks, TrendMicro), specifically with respect to the persistence mechanism. The PAN article mentions that this may be used to make sandbox analysis much more difficult, in that it requires user interaction to launch the malware.
The PAN article ends with a bunch of "indicators", which consist of file hashes and domain names. I'd monitor for the creation of the key/value instead.
Some online research indicated that this persistence mechanism had been discussed on the Hexacorn blog over 2 years ago. According to the blog post, the persistence mechanism causes the malware to be launched when the user launches an Office application, or IE with Office plugins installed. This can make IIV determination difficult if the analyst isn't aware of it.
I updated the malware.pl RegRipper plugin accordingly.
IIV?
ReplyDelete@Anonymous,
ReplyDelete"IIV" = Initial Infection Vector
The data hiding book seems interesting. I also covered many of the same topics in my latest book, Hiding Behind the Keyboard, but I didn't focus on an OS (https://www.amazon.com/Hiding-Behind-Keyboard-Uncovering-Communication/dp/0128033401).
ReplyDeleteI would not expect hiding data in the registry to be an effective means of communication between criminal conspirators, but rather more effective at hiding malware. My book's intention was to include finding data hidden inside the CPU as well as data (communications) hidden outside it.