hi
so right now i have a Windows 2K/XP computer which i suspect that is compromised. There is possibility that rootkits are being installed and so i have to investigate using clean tools.
Just wondering, how would u go about doing an initial investigation on this machine like dumping the network connections, memory, processes, etc ? Using Live CDs??
thanks
Hi,
What is the purpose of this "investigation"? the answer to that question will very much determine the advice that you need.
Your first move, however, should be to disconnect it from the network.
:)
If the system is configured correctly, this shouldn't be required. (What is the integrity of your logs? What users have access to those logs?) If it is required, check out the forensic server project and the CERT windows compromise response documents.
The following links should get you started (in this order):
http://www.shebeen.com/win32-forensics/index.html
http://www.windowsitlibrary.com/Cont...81/08/toc.html
http://www.cert.org/tech_tips/win-UN...ompromise.html
cheers,
catch
hi thanks for replyingQuote:
Originally posted here by catch
If the system is configured correctly, this shouldn't be required. (What is the integrity of your logs? What users have access to those logs?) If it is required, check out the forensic server project and the CERT windows compromise response documents.
The following links should get you started (in this order):
http://www.shebeen.com/win32-forensics/index.html
http://www.windowsitlibrary.com/Cont...81/08/toc.html
http://www.cert.org/tech_tips/win-UN...ompromise.html
cheers,
catch
Sorry for not making clear. Ok..here's another
1) I suspect a machine (call it SUSPECT) is compromised. Don't know if there are root kits but i rather believe it has and whatever system files, libraries in SUSPECT are not trusted.
2) So i have tools to do that, like from the first site you mentioned, there are tools like nmap, tcpview, pslist..etc.. I burn it into CD.
3) Next , i pop this CD into the SUSPECT, and i execute , say tcpview. It shows me the network connections, but at the same time, it uses system dlls from the SUSPECT machine.
4) So now, how to really use "clean" dlls ? Since this is the case, can i burn "clean" dlls that the tools uses so next time when i execute tcpview (likewise for other tools), it uses the "clean" dlls from the CD?
5) Some of the tools can be used remotely. Example, from a machine CLEAN , i connect to SUSPECT and use nmap, winfingerprint (tools from the same first site) to gather information. But wouldn't CLEAN be "not trusted" anymore, becos it have a connection to SUSPECT? And, can we
also gather memory dumps, network connections, processes remotely as well?
thanks and pardon me for asking that much.
sorry forgot to mention, not every environment is perfect. I agree with you that if the system is configured correctly, i shouldn't have to use them. But just imagined that you are a forensic expert and you earn a living by providing forensics investigation when your customer suspect something happening to his/her computer and they called you to lead an investigation. surely you can't say "If the system is configured correctly, this shouldn't be required" to your customer rite? hehe...just a thought... :)Quote:
Originally posted here by catch
If the system is configured correctly, this shouldn't be required. (What is the integrity of your logs? What users have access to those logs?) If it is required, check out the forensic server project and the CERT windows compromise response documents.
The following links should get you started (in this order):
http://www.shebeen.com/win32-forensics/index.html
http://www.windowsitlibrary.com/Cont...81/08/toc.html
http://www.cert.org/tech_tips/win-UN...ompromise.html
cheers,
catch
Hi
Just to remember: In general, one classifies two levels of rootkits[1]:
user-land and kernel-land rootkits. If you download tools, as provided
in the excellent links by catch, you will defeat user-land rootkits - as you
already know :). But the links also provide you with detailed information,
such as the detection of the AFX rootkit, and further reading material.
Anyway, your question seems to be: What can I do if the machine is compromised
with a kernel-land rootkit? Although there are a couple of rookit-revelears
out there, e.g. RootkitRevelear[2], modGreper[3], Strider[4], and check
rootkit.com[5] for Klister, Patchfinder2 and VICE, it is in principle possible
to even hide from these detectors, and to complicate things - false positives
often occur. However, most of the above detectors will identify standard
rootkits used, such as Vanquish and HackerDefender.
What options are left?
One possibilty is to compare md5 hashes of system files on the compromised
machine (a tool is given in catch's first link) with md5-hashes of trustworthy
system files. Tedious work.
Another or additional possibilty (unfortunately you will be in a passive state) is
to capture and analyse the traffic from and to the compromised machine, using
an external "sniffer". Port-scanning is not a final mean to reveal possible
"active" ports (portknocking-like approaches).
Keep us updated :)
Cheers
[1] http://www.antionline.com/showthread...r=2#post829358
[2] http://www.sysinternals.com/utilitie...trevealer.html
[3] http://invisiblethings.org/tools.html#modgreper
[4] http://research.microsoft.com/rootkit/
[5] http://www.rootkit.com
Incident Handling 099. Details saved for 101 :)
The steps to handling an incident should be as follows(fine points and details excluded).
Detect and analyze the compromise
contain the known threat and alert stakeholders
scan for more compromises based on pattern detected(ports open type of traffic etc)
analyze machine image
Write RCA -Root Cause Analysis
Report to stakeholders
I assume this is a client's machine. So you've detected the compromise. Now search for patterns and analyze the machine. Use the FSP or Helix or a commercial product like Prodiscover to respond and gather live system information. Depending on the sensitivity of the machine, you may need to contain the threat before you analyze the machine.
Next step is, as Nihil said "contain the threat", either by disconnecting the cable or disabling the port on the switch or blocking elsewhere.
Now, alert the stakeholders i.e, anyone that will be affected by the compromise.
Next, search for other machines matching the patterns that may be involved in the incident.
If deemed neccessary, image the machine for offline analysis. Again, this can be at the same time you are scanning for other machines.
Write your RCA or Root Cause Analysis. If you don't do this, you will never know what the hell actually happened and how, or how to prevent it from happening again.
Report the RCA to the stakeholders and then determine next steps.
Oh yeah..document document document...everything!
No, you were very clear... I don't think you read that first link carefully enough.Quote:
Sorry for not making clear. Ok..here's another
Ok fair enough.Quote:
1) I suspect a machine (call it SUSPECT) is compromised. Don't know if there are root kits but i rather believe it has and whatever system files, libraries in SUSPECT are not trusted.
Good.Quote:
2) So i have tools to do that, like from the first site you mentioned, there are tools like nmap, tcpview, pslist..etc.. I burn it into CD.
This is true, however do you have any idea the scale and quality of the attack required to defeat that entire suite of tools? Even root kits for open source systems don't tend to work that flawlessly, much less on a closed source system.Quote:
3) Next , i pop this CD into the SUSPECT, and i execute , say tcpview. It shows me the network connections, but at the same time, it uses system dlls from the SUSPECT machine.
You don't need to, assume they are all dirty, but look for inconsistancies. Cause seriously, it would be a monumental effort, light years ahead of any existing projects to replaces so many libraries so cleanly. (On a machine that must have been very badly configured to start with)Quote:
4) So now, how to really use "clean" dlls ? Since this is the case, can i burn "clean" dlls that the tools uses so next time when i execute tcpview (likewise for other tools), it uses the "clean" dlls from the CD?
CLEAN doesn't become untrusted simply by connecting to SUSPECT, an attack/infection needs to take place. None of these connection tools have (at this time) known attack/infection paths.Quote:
5) Some of the tools can be used remotely. Example, from a machine CLEAN , i connect to SUSPECT and use nmap, winfingerprint (tools from the same first site) to gather information. But wouldn't CLEAN be "not trusted" anymore, becos it have a connection to SUSPECT? And, can we
Who said anything about the system being perfect, simply following the standard Windows security guidelines about segregating administrators and operators would have preserved the logs. If I was hired to do forensics work, you can bet yor ass that I would tell the customer how to avoid this kind of problem in the future.Quote:
sorry forgot to mention, not every environment is perfect. I agree with you that if the system is configured correctly, i shouldn't have to use them. But just imagined that you are a forensic expert and you earn a living by providing forensics investigation when your customer suspect something happening to his/her computer and they called you to lead an investigation. surely you can't say "If the system is configured correctly, this shouldn't be required" to your customer rite? hehe...just a thought...
cheers,
catch
PS. sec_ware's post is on the ball. If it were me, I'd pull the drive and run hash check all the system utilities from a seperate system or a live CD. Also, if I were really paranoid, I'd check the NIC's cache for any irregularities.
I am sure someone will have a go at me for posting a reply to an old thread but anyway :-) I only signed up today and thought I could add something to this discussion.
Attached document is something I put together about initial behavioural analysis of suspected malware. I was going to post this as a tutorial but decided against it as I am not sure if the if the audience is right.
Hope this provides something
WOW, that Hogfly is some technician. I don't think the question is clear. Are you trying to determine if the machine is compromised or are you trying to learn who compromised the machine and find them?
One leads to the other. I would watch the network from a clean machine and evaluate the traffic to and from. Record open ports and look into the suspected traffic. If your on a switch, you'll need a SPAN port, if its a hub, just use tcpdump and isolate the IP you would like to watch.
Hope this makes sense and is correct.
HI HOG!!!!!!! REMEMBER ME?
no...I'm afraid I don't.
Ok, think way back to the old chat room. I don't know if they have one anymore. Oh, was my answer semi-correct anyway? I would hate to post bad information.
Your old friend!!!!!