If you don't know how to investigate a web attack or an email crime, you will never be able to prove who hacked a company's website or who sent that blackmail email. For the CHFI (312-49) exam, you absolutely must understand the step-by-step process of collecting evidence from web servers, email servers, and network logs. This chapter gives you the exact framework investigators use to trace an attack from the initial alert to the final report.
Jump to a section
A simple way to picture Investigating Web Attacks and Email Crimes
Your friend's house was broken into, and 8 items are missing. The police don't just dust for fingerprints. They break the investigation into three separate stages: the initial call, the scene analysis, and the digital trail.
First, the emergency call tells them exactly what was stolen and the time the alarm was triggered. This is like the 'initial alert' in a web attack — a firewall log showing a SQL injection attempt or an email header showing a phishing link.
Second, the scene analysis means checking the broken window for footprints (like checking web server logs for the attacker's IP address), looking at the muddy footprints leading to the jewellery box (like tracing the attacker's path through a web app via HTTP request logs), and examining the CCTV footage (like analysing packet captures that show the exact data the attacker sent).
Third, the digital trail is checking the house's smart lock history (like reading email server logs to see when an attacker accessed a victim's inbox), reviewing the neighbour's doorbell camera (like checking DNS logs for suspicious domain lookups), and verifying the alarm company's call log (like verifying the timestamps in email headers to confirm when a malicious email was sent).
Each stage has its own set of evidence. Without breaking the investigation into these three stages, the police would miss the connection between the broken window and the stolen laptop. In web attack and email crime investigations, forensic examiners use the same three-stage method to connect the attacker's digital footprints to the stolen data.
Let's start with the basics. A web attack is any attempt to exploit a vulnerability in a website or web application. An email crime is any illegal activity that uses email as the primary tool — think phishing, spam, or sending malware. The investigation of these crimes is called 'forensic investigation'. The goal is to find out what happened, who did it, and what evidence exists to prove it in court.
The most common web attacks you will encounter include:
SQL Injection (SQLi): An attacker sends malicious SQL code through a website's input field (like a search box) to trick the database into revealing private information, such as usernames and passwords.
Cross-Site Scripting (XSS): An attacker injects malicious script (usually JavaScript) into a webpage, which runs in the victim's browser. This can steal session cookies, redirect the user to a fake site, or deface the page.
Cross-Site Request Forgery (CSRF): An attacker tricks a logged-in user into performing an action on a website without their knowledge (e.g., changing their email address or transferring money).
File Inclusion: An attacker uploads a malicious file (like a PHP script) to a web server and then executes it, gaining full control of the server.
For email crimes, the most common types are:
Phishing: A fake email that looks like it's from a legitimate company (like your bank) to trick you into entering your login credentials on a fake website.
Spear Phishing: A targeted phishing email that uses personal information (like your name, job role, or recent purchases) to make the email more believable.
Email Spoofing: The attacker fakes the 'From' address in an email header to make it appear the email came from someone else (like your boss or a colleague).
Malware via Email: An email attachment (like a PDF or Word doc) contains a hidden program that, once opened, infects your computer.
Now, how do investigators actually collect evidence? The process follows a standard forensic methodology. It starts with 'preservation'. This means making a bit-for-bit copy of the hard drive or log file without altering the original. The copy is called a 'forensic image'. The original evidence is kept in a secure, tamper-proof bag. Next is 'analysis'. The investigator uses tools to examine the forensic image for clues. For web attacks, this means checking web server logs for unusual HTTP requests (like a long URL containing SQL commands), examining database transaction logs for unauthorised queries, and looking at the web application's error logs for stack traces that reveal the attack path. For email crimes, the investigator looks at 'email headers'. Every email has a header that contains the 'Message-ID', 'Received' lines (which show each mail server the email passed through), and the sender's IP address. The 'Received' lines are read from bottom to top — the last one is the original sender's server. The investigator also checks the 'X-Originating-IP' header, which often reveals the true IP of the sender if they were using a webmail service.
Why does all this matter for the CHFI exam? The exam will test your ability to identify which evidence source to use for which type of crime. For example, if you see a web app log showing '1=1' in a URL parameter, you should immediately think 'SQL injection'. If you see a phishing email and need to find the attacker's IP address, you look at the email headers, not the email body. The exam also loves to ask about the sequence of steps — preservation always comes before analysis.
Preserve the Scene
Immediately isolate the affected web server or email server from the network to prevent further damage. Do not power it off. Make a forensic image of the RAM (volatile memory) using a tool like FTK Imager, and then make a bit-for-bit copy of the hard drive using a write-blocker. Label and secure the original drives in a locked evidence locker with a chain of custody log.
Collect Web Server Logs
Access the web server's access log and error log. For Apache or Nginx servers, these are usually located in /var/log/httpd/ or /var/log/apache2/. Search for entries that contain suspicious SQL commands (for SQL injection) or script tags (for XSS). Extract the attacker's IP address and the timestamp of each suspicious request.
Analyse Email Headers
For email crimes, export the raw email source (headers and body). Locate the 'Received' lines and read them from bottom to top. The bottommost 'Received' line contains the original sender's IP. Check for 'X-Originating-IP' header (often present in webmail services). Also examine 'DKIM-Signature' and 'SPF' headers to determine if the email was forged.
Correlate Network Evidence
Collect network packet captures (if available) from the intrusion detection system (IDS) or firewall. Look for the attacker's IP address in the captures. Correlate the timestamps of the web attack attempts (from the web server logs) with the network traffic to confirm the attacker's activity. Also check DNS logs for any suspicious domain lookups (e.g., the attacker's command-and-control server).
Recover and Analyse Deleted Data
Use forensic tools (like Autopsy or EnCase) to carve deleted files from the forensic image of the hard drive. Look for deleted web server logs, deleted emails, or temporary files created by malware. Also check for log rotation archives (e.g., access.log.1.gz) that attackers often overlook. Reconstruct the timeline of the attack using timestamps from these recovered files.
Document and Report
Write a detailed forensic report that includes the evidence collected (e.g., log entries, email headers, forensic images), the tools used, the chain of custody, and the conclusion (the attack vector and the likely attacker). The report must be written in clear, non-technical language for a non-technical audience (lawyers, executives). Include exhibits for each piece of evidence.
Imagine you work as a forensic analyst for a mid-sized e-commerce company. Your phone rings at 2 AM. The company's website is down, and the security team suspects a web attack. This is a real-world scenario you will face.
First, you connect to the company's VPN (a secure remote connection) to access the network remotely. You ask the system administrator to immediately take the web server offline but to NOT power it off — the server's RAM contains volatile evidence like active network connections and running processes. You create a 'live forensic image' of the RAM using a tool called 'FTK Imager' or 'DumpIt'. This captures everything currently in memory, including the attacker's commands if they were executing them right then.
Second, you make a forensically sound bit-for-bit copy of the web server's hard drive. You use a write-blocker — a hardware device that prevents any data from being written to the original drive during copying. Once you have the forensic image, you store the original drive in a locked evidence locker with a chain of custody log (a document that records every person who handles the evidence, when, and why).
Third, you start the analysis. You open the forensic image in a tool called 'Autopsy' (a free forensic platform). You search the web server's access log (a file that records every HTTP request made to the server). You find an entry at 01:45 AM: 'GET /index.php?id=1 AND 1=1'. This is a classic SQL injection probe. You search for more entries from the same source IP address. You find another entry: 'GET /index.php?id=1 UNION SELECT username, password FROM users'. This confirms a SQL injection attack. The attacker successfully extracted the username and password for the 'admin' account.
Fourth, you turn to the email crimes aspect. The attacker sent a phishing email to the company's IT manager from a spoofed address pretending to be the CEO. The email asked the IT manager to click a link and 'verify his Microsoft account credentials'. The IT manager clicked the link and entered his password. The attacker then used those credentials to log into the company's email server and read all emails in the CEO's inbox — looking for financial data.
To investigate the phishing email, you obtain the forensic copy of the email server's logs. You look at the 'Message Tracking Logs' (which track every email sent and received). You find the phishing email in the logs. You export the email headers. In the headers, you find two 'Received' lines. The first 'Received' line shows an IP address: 203.0.113.45. You check the company's geolocation database (like MaxMind GeoIP) and see that IP address is registered to a hosting company in Eastern Europe. The second 'Received' line shows the internal corporate email server's IP. This confirms the attacker did not use a VPN; they sent the email directly from that Eastern European IP.
Finally, you write a report. The report summarises the evidence: the SQL injection logs, the extracted credentials, the phishing email headers, the attacker's IP address, and the chain of custody documents. You conclude that the attack was a targeted spear phishing campaign combined with a SQL injection. The report is presented to the board for legal action against the attacker.
The 312-49 exam tests your knowledge of web attack and email crime investigation in a very specific way. You must memorise the exact steps, the correct tools, and the key evidence sources.
First, the exam loves to ask about the 'order of volatility'. This concept refers to the order in which you should collect evidence from a live system. The most volatile (easily lost) evidence is the contents of CPU registers and RAM. The least volatile is the hard drive. The exam will give you a scenario where a web server is still running but compromised, and ask which evidence you collect first. The answer is always 'collect RAM and active network connections first' because if you pull the power cord, that evidence is gone forever.
Second, the exam will test your ability to read an email header. You will be shown a list of 'Received' lines and asked which IP address belongs to the original sender. The trap is that the exam might show you incomplete headers or reversed order. Remember: 'Received' lines are added by each mail server as the email travels. The topmost 'Received' line in the email header is the most recent server (the one that delivered the email to the recipient). The bottommost 'Received' line is the original sender's server. So to find the attacker, you always look at the LAST 'Received' line.
Third, they love to test your knowledge of specific attacks. Expect multiple-choice questions like: - 'What type of web attack involves inserting malicious SQL code into a URL parameter?' Answer: SQL injection. - 'What log file on a Linux web server records every HTTP request?' Answer: access log (usually /var/log/httpd/access_log or /var/log/apache2/access.log). - 'What tool is used to capture a forensic image of RAM?' Answer: FTK Imager or DumpIt.
Fourth, memorise the acronyms. The exam loves acronyms like:
SMTP (Simple Mail Transfer Protocol) — used to send emails.
POP3 (Post Office Protocol 3) and IMAP (Internet Message Access Protocol) — used to receive emails.
MIME (Multipurpose Internet Mail Extensions) — the standard that allows email to include attachments and different character sets.
DKIM (DomainKeys Identified Mail) — an email authentication method that allows the receiver to check that an email was not forged.
SPF (Sender Policy Framework) — a DNS record that specifies which servers are authorised to send emails for a domain.
Fifth, the exam will test your understanding of 'chain of custody'. They will describe a scenario where an evidence bag is left unlocked, and ask what legal impact this has. The answer is that the evidence may be declared inadmissible in court because it cannot be proven that the evidence was not tampered with.
Finally, the exam frequently includes a question about 'anti-forensic techniques' that attackers use. For example, an attacker might delete the web server logs after an attack. The examiner must know how to recover deleted files or look for backup logs. The correct approach is to check for 'log rotation' — many servers automatically archive old logs into compressed files (like access.log.1.gz). Attackers often forget to delete these archived logs.
The order of volatility dictates that you collect RAM and active network connections before powering off a web server, because volatile evidence is lost when the system is shut down.
To find the true sender of a spoofed email, read the email headers from bottom to top, focusing on the last 'Received' line.
SQL injection attacks are identified by unusual SQL commands (like '1=1' or 'UNION SELECT') in URL parameters or form inputs recorded in the web server's access log.
A forensic image (bit-for-bit copy) of a hard drive must be made using a write-blocker to preserve the original evidence intact.
The chain of custody document must record every person who handles the evidence, the date, the time, and the reason, to ensure the evidence is admissible in court.
Deleted emails can often be recovered from email server mailstores and backups, as long as the storage space has not been overwritten by new data.
Cross-Site Scripting (XSS) attacks embed malicious JavaScript in webpages, and evidence is found in the web server's access log (the attacker's payload) and the victim's browser cache (the executed script).
Email authentication methods like SPF, DKIM, and DMARC are checked during an investigation to determine if an email was forged or if it came from an authorised server.
These come up on the exam all the time. Here's how to tell them apart.
Web Server Access Log
Records every HTTP request made to the server, including URL parameters.
Used to identify the attacker's requests (e.g., SQL injection payloads).
File location typically /var/log/httpd/access_log or /var/log/apache2/access.log.
Web Server Error Log
Records errors generated by the web application (e.g., SQL syntax errors).
Used to determine if an attack caused an error or succeeded (e.g., database errors).
File location typically /var/log/httpd/error_log or /var/log/apache2/error.log.
Email Header 'From' Field
The displayed sender address in the email body.
Can be easily spoofed (faked) by the attacker.
Not reliable for identifying the actual sender.
Email Header 'Received' Lines
Trace the path the email took through mail servers.
Read from bottom to top to find the original sender's IP address.
Reliable evidence for identifying the true source of the email.
SQL Injection (SQLi)
Targets the database by injecting SQL commands.
Goal: extract data from the database (e.g., passwords).
Evidence found in web server access log (URL parameters with SQL statements).
Cross-Site Scripting (XSS)
Targets the user's browser by injecting malicious script (JavaScript).
Goal: steal session cookies, redirect users, or execute actions on behalf of the user.
Evidence found in web server access log (script tags in parameters) and victim's browser cache.
Live Forensic Acquisition
Performed while the system is still running.
Captures volatile data (RAM, active connections, running processes).
Risk: the attacker may be active and deleting evidence during acquisition.
Dead Forensic Acquisition
Performed after the system has been shut down or powered off.
Does not capture volatile data (that data is lost).
Lower risk of evidence tampering, but valuable volatile evidence is lost.
SMTP (Simple Mail Transfer Protocol)
Used to send emails between mail servers.
Port 25 (default) or 587 (submission).
Relevant for investigating outgoing spoofed emails and server logs.
POP3/IMAP (Email Retrieval Protocols)
Used by email clients (Outlook, Gmail) to receive emails from a server.
POP3 uses port 110 (unencrypted) or 995 (SSL); IMAP uses port 143 or 993.
Relevant for investigating who downloaded or accessed the victim's emails.
Mistake
You can just look at the 'From' address in an email to identify the real sender.
Correct
The 'From' address can be spoofed (faked). You must examine the email headers, specifically the 'Received' lines and the 'X-Originating-IP' header, to find the true sender's IP address.
Most people assume the email address in the 'From' field is verifiable because it looks legitimate (e.g., 'support@amazon.com'). Attackers rely on this trust. The spoofing is so easy to do with basic SMTP commands that beginners think the email 'must' be real.
Mistake
If you find a SQL injection attempt in the web server log, the attack definitely succeeded.
Correct
A SQL injection attempt in the log only shows the attack was attempted. You must check the database query logs or the web application's error logs to see if the injection actually returned data or caused an error.
Security tools (like WAFs — Web Application Firewalls) can block SQL injection attempts before they hit the database. Beginners think any mention of 'SQL injection' in a log equals success, but forensic examiners need to prove the data was actually exfiltrated.
Mistake
Deleted emails can never be recovered.
Correct
Deleted emails can often be recovered from the email server's 'mailstore' (the database or file system where emails are stored) or from backup tapes. Forensic tools can carve (reconstruct) emails even after deletion, as long as the storage space hasn't been overwritten.
This misconception comes from everyday experience on personal computers where emptying the Recycle Bin seems permanent. Beginners don't realise that email servers (especially corporate ones) keep multiple copies and backups that are not immediately erased.
Mistake
All email headers are the same. You can just read them like a regular message.
Correct
Email headers contain many different fields (Received, Message-ID, MIME-Version, Content-Type, etc.), each serving a different purpose. Investigators focus on specific headers like 'Received' for tracing the path, 'DKIM-Signature' for authentication, and 'X-Mailer' to identify the sending software.
The common email client (Gmail, Outlook) shows only a simplified 'header' view. Beginners assume that's the full picture. In forensic investigation, you must view the raw email source, which looks like a block of text, and know which part to inspect.
Mistake
If an attacker used a VPN, you cannot find their real IP address.
Correct
A VPN can hide the attacker's home IP, but other evidence may still identify them. For example, the attacker's browser fingerprint (a unique combination of browser version, fonts, screen resolution, and plugins) can be matched across sessions. Also, if the attacker logs into a web account (like the webmail they sent the email from) without the VPN, that login IP will be recorded.
This misconception arises from pop culture depictions of VPNs as 'total anonymity'. Beginners don't consider that multiple logins from different IPs, session cookies, and browser fingerprinting can still link the attacker to a specific device or account.
Mistake
Web server logs and email logs are the only evidence you need to investigate web attacks.
Correct
You also need to collect evidence from the web application's code (for vulnerabilities), database logs (for data exfiltration), network packet captures (for the actual data flow), and the victim's browser cache (for XSS attacks). Email investigations also require DNS logs (to check SPF/DKIM records) and authentication logs (to see who logged in).
Beginners focus on the most obvious log files because they are easy to find. They don't realise that a complete investigation requires correlating multiple sources to build a timeline and prove the attack path.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Open the raw email source (in Gmail, click 'Show original'). Look for the 'Received' lines. Read them from bottom to top. The bottommost 'Received' line shows the first mail server that handled the email, which usually contains the sender's IP address.
A write-blocker is a hardware or software device that allows you to read data from a hard drive but prevents any data from being written to it. It is essential for creating a forensically sound image because it ensures the original evidence is not altered during the copying process.
The overall forensic methodology (preserve, acquire, analyse, report) is the same, but the specific evidence sources differ. Web attacks focus on web server logs (access, error), database logs, and application code. Email crimes focus on email server logs, email headers, and SMTP transaction logs.
Beginners trust the 'From' address in the email body. The correct approach is to ignore the 'From' field in the email body and instead examine the email headers for the 'Return-Path', 'Received' lines, and SPF/DKIM results. The spoofed 'From' address is trivial to fake.
Look in the web server's error log for SQL syntax errors (like 'You have an error in your SQL syntax') and in the database's query log for successful SELECT statements that returned data. Also check the web server's access log for the presence of data in the HTTP response (like a list of usernames appearing in the URL).
A forensic image is a bit-for-bit copy of the entire hard drive, including all deleted files and unallocated space. A regular backup only copies files that are still accessible by the operating system. Forensic images preserve hidden data that is critical for evidence (like deleted emails or remnants of malware).
You've finished Investigating Web Attacks and Email Crimes. Continue through the 312-49 study guide to build a complete picture of the exam.
Done with this chapter?