Website Redirect Malware Analysis.

In this guided lab, customers of yummyrecipesforme.com reported that the site asked them to download and run a file to get free recipes, and their computers had been slow ever since. The website owner also found they could no longer log in to the web server's admin account. The analyst in the scenario opened the site in a sandbox, captured the traffic with tcpdump, and was sent to greatrecipesforme.com after running the file. A senior analyst later found JavaScript added to the site's source code that prompted visitors to download it.

I analyzed the provided scenario and tcpdump log data, traced the redirect in the traffic, and wrote the incident report. The scenario and the log were provided by the course lab.

1. ReviewRead the scenario and the provided tcpdump log
2. BaselineFollowed the first DNS lookup, TCP handshake, and HTTP GET to the real site
3. SpotFound the new DNS lookup for a lookalike domain in the middle of the session
4. ConfirmTied the log to the scenario's other evidence, including the changed source code
5. ReportWrote the incident report and a brute force remediation

• The protocol involved is HTTP at the application layer. The malicious file and the redirect were both delivered over HTTP, and both sites used plain, unencrypted HTTP on port 80.
• The new DNS lookup for greatrecipesforme.com happened with no new site typed in, right after the real page loaded and the file ran.
• Every line comes from your.machine. The changing numbers (52444, 36086, 56378) are source ports, so each one is a new connection from the same machine.
• The provided log shows greatrecipesforme.com resolving to 192.0.2.17, while the course guide lists 192.0.2.172. I used the address shown in the log itself.

• Application layer: HTTP carried the page, the malicious file, and the traffic to the fake site. DNS looked up the addresses for both domains.
• Transport layer: TCP set up each web connection with the three-way handshake, and the ports show which connection is which.
• Internet layer: IP carried every packet between the machine, the DNS server, and the two websites.

On its own, the log could look like someone browsing to a second website. What makes it a redirect is the context: the timing of the second lookup, the lookalike name, and the added JavaScript found in the source code. In a real investigation, I would confirm a redirect like this by checking the HTTP responses from the original site or the site's source code, not the log by itself.

The attacker, a former employee, got into the admin account with a brute force attack because it still used its default password and nothing limited repeated login attempts. My recommendation is one measure: a password policy that bans default passwords, requires a strong and unique admin password, and locks the account after a small number of failed login attempts, for example five.

• tcpdump Packet Analysis
• DNS Lookups
• TCP Three-Way Handshake
• HTTP
• TCP/IP Model
• Brute Force Prevention
• Incident Documentation

• A new DNS lookup in the middle of a session is worth a closer look, especially when the new name is close to the original.
• Changing source port numbers usually mean new connections from the same machine, not a different machine.
• A packet capture shows what happened on the network, but proving how it happened can take other evidence, like the site's source code.
• A default password on an admin account can let an attacker take over a whole website and use it against its own visitors.