Rootkit Findings (updated)
A reader who wishes to remain anonymous sent us a nice write-up of findings uncovered while investigating an intrusion. Below is the entire note, minus identifying details. (New information is available below...)
I got caught out by the recent MailEnable buffer overflow vulnerability by a few hours. I'd been running the patch in pre-live for a few days for testing but was too slow in getting the live server patched unfortunately.
The rootkit seemed to be running 2 ServU deamons one on port 43958 and the other on port 1050 using an SSL connection. There were a host of other ports opened by the rootkit and I couldn't figure out what they were for... The server I had to fix is 200 miles away so it was all done via a remote desktop connection.
I used a heap load of sysinternal tools to figure out what was going on and compared services etc to the build manifest that I created for that server before it was put into production. Using the manifest I was able to ascertain exactly what services had been installed and how to remove them.
The problems came with the rootkit hiding the netsv! and certmngr services along with the associated files in the directory C:\Windows\Congig\system.
I used netstat -a -b a lot to verify information regarding the applications running and used that along with the info from RootKitRevealer to use the sc command from the Windows resource kit to first stop then remove the services.
One thing to note is that the thing renamed the display name of the netlogon service to "System Spooler". If I hadn't been paying attention I might have tried to delete that service too... It would have been a catastrophic mistake to make...
One file that I deleted accidentally was the logon.exe file that resided in the system32 directory. That file was run by the pipext service with the display name of "Windows Media Client (WMC)".
(UPDATE) We asked the person who sent us this information if he would share some additional facts about what he used to build his manifest. Here is his response.
Lesson learned: taking those baseline snapshots, building records of what a "normal system" looks like, anything you can do to establish something as a reference point to compare to when you are investigating an intrustion is a life-saver!
I got caught out by the recent MailEnable buffer overflow vulnerability by a few hours. I'd been running the patch in pre-live for a few days for testing but was too slow in getting the live server patched unfortunately.
The rootkit seemed to be running 2 ServU deamons one on port 43958 and the other on port 1050 using an SSL connection. There were a host of other ports opened by the rootkit and I couldn't figure out what they were for... The server I had to fix is 200 miles away so it was all done via a remote desktop connection.
I used a heap load of sysinternal tools to figure out what was going on and compared services etc to the build manifest that I created for that server before it was put into production. Using the manifest I was able to ascertain exactly what services had been installed and how to remove them.
The problems came with the rootkit hiding the netsv! and certmngr services along with the associated files in the directory C:\Windows\Congig\system.
I used netstat -a -b a lot to verify information regarding the applications running and used that along with the info from RootKitRevealer to use the sc command from the Windows resource kit to first stop then remove the services.
One thing to note is that the thing renamed the display name of the netlogon service to "System Spooler". If I hadn't been paying attention I might have tried to delete that service too... It would have been a catastrophic mistake to make...
One file that I deleted accidentally was the logon.exe file that resided in the system32 directory. That file was run by the pipext service with the display name of "Windows Media Client (WMC)".
(UPDATE) We asked the person who sent us this information if he would share some additional facts about what he used to build his manifest. Here is his response.
For every machine I build and put into production I use tools like tlist to dump out the status of the services and then I put the information into a spreadsheet. The spreadsheet is then kept in an SVN repository. Any changes are logged and the spreadsheets are altered.
I also keep records for firewall configurations, IP filter settings etc all of the things that you would need to reference if an incursion took place.
To be honest, this is the first time in six years that I have ever had to use the information that I log. Most people in the past when I tell them what I do tell me I am mad for doing all the extra work. This one incident proves them all wrong :)... Without it I would have had to reformat and re-install without question and that would have taken quite some time with a 350/400 mile round trip into the bargain too...
I also keep records for firewall configurations, IP filter settings etc all of the things that you would need to reference if an incursion took place.
To be honest, this is the first time in six years that I have ever had to use the information that I log. Most people in the past when I tell them what I do tell me I am mad for doing all the extra work. This one incident proves them all wrong :)... Without it I would have had to reformat and re-install without question and that would have taken quite some time with a 350/400 mile round trip into the bargain too...
Lesson learned: taking those baseline snapshots, building records of what a "normal system" looks like, anything you can do to establish something as a reference point to compare to when you are investigating an intrustion is a life-saver!
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments