This is a great multi-part series from Spider Labs covering lots of tools and techniques for examining suspicious (or just plain malicious) PDF files. Honestly, the flood of malicious PDF tools seems to have slowed down, but eventually everything old is new again, right?
Analyzing PDF Malware - Part 1 - SpiderLabs Anterior:
Journey into Malware Forensics
Friday, August 10, 2012
Tuesday, August 7, 2012
OllyDbg cheat sheet
Excellent cheat sheet for OllyDbg; this one features more commands than most I've seen:
http://www.dc214.org/notes/rev_eng/Docs/OllyDbg%20Shortcuts.pdf
Or you could just go to the source:
http://www.ollydbg.de/quickst.htm
http://www.dc214.org/notes/rev_eng/Docs/OllyDbg%20Shortcuts.pdf
Or you could just go to the source:
http://www.ollydbg.de/quickst.htm
Thursday, September 22, 2011
LM Hash Calculator
LM Hash Calculator: Handy tool for verifying you've got the right result when cracking LM hashes.
Thursday, August 11, 2011
Securing PXE
Interesting post from Matt Weeks (scriptjunkie) on using PXE to exploit a network: http://www.scriptjunkie.us/2011/08/network-nightmare/
You see PXE used a lot for imaging workstations, so Matt's article got me thinking about how one could securely use PXE for that function. When using PXE for system imaging, you've usually got an admin interrupting the normal boot from HDD to prompt a boot from PXE. But if someone managed to insert a DHCP/PXE server on your network there is little you can do to control the source from which a machine will boot.
So how to secure, or do we just need to stop using PXE?
One obvious thing is the need to be aware of and secure against rogue DHCP servers on your network. If someone can do that, PXE exploits are just one of many problems they can cause you.
Another is to disable PXE in BIOS except when you go to re-image. Admins should re-enable when needed and then disable again when complete. It is theoretically possible to create a PXE boot image that would write malware to disk and then quit, and possibly escape detection. But the person re-imaging a device is very likely to notice something amiss.
Of course, all BIOS options are useless if you don't password-protect the BIOS settings and physically secure your cases. I've always been happy when someone says, "Well then I'd just change the BIOS settings," to be able to tell them, "All of our machines' BIOS setups are password-protected." And when they say, "Well then I'd just open the case and flip a jumper/disconnect the battery," to be able to say, "That might work, after you cut off the padlock (or the hasp, which would probably be easier.)" Physical security is your best friend.
So if PXE is enabled only as needed and then disabled immediately after, what is the residual risk?
You see PXE used a lot for imaging workstations, so Matt's article got me thinking about how one could securely use PXE for that function. When using PXE for system imaging, you've usually got an admin interrupting the normal boot from HDD to prompt a boot from PXE. But if someone managed to insert a DHCP/PXE server on your network there is little you can do to control the source from which a machine will boot.
So how to secure, or do we just need to stop using PXE?
One obvious thing is the need to be aware of and secure against rogue DHCP servers on your network. If someone can do that, PXE exploits are just one of many problems they can cause you.
Another is to disable PXE in BIOS except when you go to re-image. Admins should re-enable when needed and then disable again when complete. It is theoretically possible to create a PXE boot image that would write malware to disk and then quit, and possibly escape detection. But the person re-imaging a device is very likely to notice something amiss.
Of course, all BIOS options are useless if you don't password-protect the BIOS settings and physically secure your cases. I've always been happy when someone says, "Well then I'd just change the BIOS settings," to be able to tell them, "All of our machines' BIOS setups are password-protected." And when they say, "Well then I'd just open the case and flip a jumper/disconnect the battery," to be able to say, "That might work, after you cut off the padlock (or the hasp, which would probably be easier.)" Physical security is your best friend.
So if PXE is enabled only as needed and then disabled immediately after, what is the residual risk?
First Post
As I move on to a new role where I can write more about what I'm doing and learning, I wanted to start a blog to capture things.
Subscribe to:
Posts (Atom)