initial investigation of suspected compromised Windows system
Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: initial investigation of suspected compromised Windows system

  1. #1
    Member
    Join Date
    Jun 2004
    Posts
    77

    initial investigation of suspected compromised Windows system

    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

  2. #2
    Super Moderator: GMT Zone nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,190
    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 you cannot do someone any good: don't do them any harm....
    As long as you did this to one of these, the least of my little ones............you did it unto Me.
    What profiteth a man if he gains the entire World at the expense of his immortal soul?

  3. #3
    Banned
    Join Date
    May 2003
    Posts
    1,004
    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

  4. #4
    Member
    Join Date
    Jun 2004
    Posts
    77
    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 thanks for replying

    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.

  5. #5
    Member
    Join Date
    Jun 2004
    Posts
    77
    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 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...

  6. #6
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  7. #7
    Computer Forensics
    Join Date
    Jul 2001
    Posts
    672
    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!
    Antionline in a nutshell
    \"You\'re putting the fate of the world in the hands of a bunch of idiots I wouldn\'t trust with a potato gun\"

    Trust your Technolust

  8. #8
    Banned
    Join Date
    May 2003
    Posts
    1,004
    Sorry for not making clear. Ok..here's another
    No, you were very clear... I don't think you read that first link carefully enough.

    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.
    Ok fair enough.

    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.
    Good.

    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.
    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.

    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?
    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)

    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
    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.

    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...
    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.

    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.

  9. #9
    Member
    Join Date
    Aug 2005
    Posts
    98
    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

  10. #10
    Banned
    Join Date
    Aug 2001
    Posts
    11
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •