Tuesday, February 9, 2010

Linkfest

To tide everyone over while I finish up writing part 5 of my exploit tutorials (which will hopefully be done by the end of this week), I have a number of interesting links that I have collected recently.

Didier Stevens has been up to some very interesting things recently with getting dlls loaded from memory (so a copy of the DLL does NOT have to be stored on the hard disk).  This has very interesting implications for those who are looking for a way to avoid leaving a trail that can be picked up by forensic investigation of the hard drive.  He has implementing this dll loading in shellcode and has also managed to create dll based versions of cmd.exe and regedit.exe.  I'll leave it up to you to ponder the possibilities/implications of this from a pen testing and/or incident response perspective. Links are here.

The dll loading method used by Didier is also an interesting reference, not least because of the detail it provides on the Windows PE format.


I have already written about how to analyse a malicious pdf document (and if you read that post you may want to know that the PDF tools from Didier Stevens have been updated since), but if you want more information on the topic I have since discovered a number of other references that you might find interesting.

And if you want to analyse other document types such as Word documents, Excel documents, etc?  Well, you can try the strings method I mentioned im my PDF post, or you could refer to this or this.


Everyones favorite network scanning tool Nmap (well, maybe its not everyones favorite tool, but its certainly mine) now has the ability to send UDP application level probes when UDP port scanning, giving a much greater chance of getting accurate results from a UDP scan.  Given that on the protocol level the correct response for an open port is... no response most UDP port scans can be unreliable.  Is that port really open, or is a firewall blocking our probes or the port unreachable responses?  Now NMap can send application level data for certain well known UDP services, which should trigger a UDP response at the application level if the associated services is running on the appropriate port.  Getting one of these responses gives you positibe proof that a port is actually open.  More information here.

An interesting post on bypassing DEP that I ran across.

Last but not least,

No comments:

Post a Comment