Incident Response and Computer Forensics on Rootkits

Lets pick up where we left off with the rootkit and post-exploitation video (https://www.youtube.com/watch?v=izv1b-BTQFw). Except, we are now doing incident response.

First you’ll see some normal live forensics on the victim and come up with nothing. Then we show how using network forensics techniques (looking at the victim from the outside) we start to see clear evidence of “doh! we’ve been owned”.

We walk through how to see these signs and prove to them that what Windows and traditional forensics is telling them is a LIE in this particular investigation.

You’ll learn how to do this type of forensics technique and many more from our InfoSec Institute Computer Forensics Boot Camp and Incident Response Boot Camp.

After we own the page and make it a browse by attack page, we then exploit the server again, create an .ini file for a rootkit to make the rootkit hide the infected page from every windows service (including windows itself mostly), except for the w3wp service (which actually serves the page out). The kit also makes netcat listen on port 100, then hides netcat, and even HIDES the open port 100! So taskmgr, netstat, Anti-virus et al are useless. You wont find anything. We then prove that the port is open by telneting to it and gaining yet another shell. Then we go back to the victim (playing the victim) run netstat -an to see all open ports, and show that 100 doesn’t show up.

Then we go to task manager, and tasklist to see there’s no netcat running. And lastly, but most importantly, I show that there is no way to actually see the infected page unless you browse to the actual web page. You cannot see it from the victim side by doing any command line stuff nor by looking at it through windows explorer. Traditional live forensics will NOT help you…we need to do some rootkit forensics, which we do in-depth on this exact case coming up next (will be linked here when live tomorrow).