Web site forensics

Viewing 9 reply threads
  • Author
    • #8189

      Im seeing a lot of companies and individuals asking for forensics of their website after it gets hacked and was wondering if some of yall have experience in this and how do you go about doing this type of work?

      For example like a WordPress site that gets compromised and is serving up malware, how would you determine what happened or where to look?

    • #51765
    • #51766

      Thanks for the links, ajohnson but im talking about website forensics, not just general computer forensics.  Like which areas on a website do you go to look for intrusion and how to mitigate them.

    • #51767


      IDS/IPS alerts?

      Regardless of whether you’re looking for compromise on a workstation, webserver, or whatever….it all boils down to what logging do you have in place. Without the logs, you can’t do much investigating….

      If adequate logging is in place, the incident response/investigation process does not deviate just because it’s a webserver.

    • #51768

      I agree with ziggy_567.

      Like which areas on a website do you go to look for intrusion and how to mitigate them.

      Mitigating vulnerabilities could be quite a challenge. I will start with OWASP Top 10 vulnerabilities found in web applications:https://www.owasp.org/index.php/Top_10_2010-Main

    • #51769

      Exactly what Ziggy said. The techniques are the same regardless of whether its a web server, a database server, a domain controller, etc. You may be looking at a different log file and ancillary evidence, but its the same general process. The resources I provided will answer your questions. Check out the “Hackers Challenges” books as well; they walk you through real attacks and the ensuing IH/IR.

      You also have to remember that a web app compromise can lead to a full-blown system compromise. You can’t just fix a hole in a web app and call it a day. If a backdoor is left unnoticed and active, you’ll still have a big problem on your hands. So again, regardless of whether the initial vector is a web app or a user downloading malware, you should still check when files were modified, running processes, user activity, network activity, etc.

    • #51770

      The Hackers Challenges books are just what i was looking for.  Thanks ajohnson.

    • #51771

      This one is actually tough.  In forensics, we have live system analysis and dead-box forensics.  In order to do a complete investigation of a hacking/malware attack, you would want to capture RAM, other volatile information, and a forensic image of the box.  This is really the best evidence for an analysis.  Unfortunately, many Word Press, Joomla, and other CMS sites are run on shared hosting.  You will not get access to the actual server (or the virtual machine) in most cases. 

      In that case you are stuck with log files and the malware itself.  Most Word Press compromises are designed to redirect you somewhere.  Although, some will aim for complete access.  You would want to look at the MySQL database and the code base.  Chances are you will find some malicious (and obfuscated) javascript code.  You may also see a ton of strange content stored in the database, fragments of SQLi or other attacks.  You can look at log files and database logs for the source of the injected files.  Most of the time, you will hit a proxy though. 

    • #51772

      Nice point Ketchup!

    • #51773

      Off the top of my head here’s a couple of things you need to look at for forensic exam post-compromise on a web server. No doubt there’s some repetition of what’s been said but here goes.

      • Logs – check the access logs for the web server for attack strings, access to admin pages and anything else that looks anomalous e.g. access to backdoor files.
      • Web root – what files have changed? Check the MAC times for new files and those that have been modified. Are there any new files that look suspicious e.g. .htaccess files, new PHP or JavaScript files. Use the content for malicious code inserts to try and file the bad files but beware of obfuscation.
      • Server config – are there any new configuration added? Check for things like malicious Apache modules.
      • database –  most web applications have some kind of backing store or database. Are there new accounts added? Is there anything else in there that could provide persistent access?

      Your aim ought to be to determine how the compromise occurred, what was carried out after the attack and remedy the situation. Remember to use Google since the attack is probably not unique to you. What web software are you using? Popular packages such as WordPress and Joomla are often the target for automated and effective attacks.


Viewing 9 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?