Listen to this Post
Introduction:
In the world of cybersecurity, the most dangerous attacks are often the quietest. A single anomalous DNS query or an unusual HTTP request might seem benign in isolation, but when correlated with other seemingly insignificant data points, these small clues can paint a picture of a full-blown security incident, from phishing campaigns and malware communication to DNS tunneling and active Command-and-Control (C2) channels. This guide provides a practical, step-by-step workflow for Security Operations Center (SOC) analysts to leverage Zeek, an open-source network security monitoring tool, to investigate and correlate HTTP and DNS logs, transforming raw data into actionable threat intelligence.
Learning Objectives:
- Analyze Zeek Logs: Learn to navigate and extract critical information from Zeek’s `http.log` and `dns.log` files using command-line tools like
zeek-cut. - Detect Network Threats: Identify indicators of compromise (IoCs) such as DNS tunneling, phishing attempts, malware callbacks, and data exfiltration.
- Correlate Log Sources: Understand how to connect evidence from different log files to build a comprehensive picture of attacker behavior and determine the root cause of an alert.
You Should Know:
1. Setting Up Your Zeek Analysis Environment
Before diving into log analysis, you need a functioning Zeek instance. Zeek is a powerful network analysis framework that can be run on a live interface or against stored packet capture (PCAP) files.
- Installation on Linux (Ubuntu/Debian): The simplest method is to use the official package repositories.
sudo apt update sudo apt install zeek
For other distributions or to build from source, refer to the official Zeek documentation.
- Basic Zeek Workflow: To analyze a PCAP file, navigate to its directory and run the following command:
zeek -C -r your_capture_file.pcap
The `-C` flag ignores any checksum errors, which is useful for analyzing traffic from various sources, and `-r` specifies the file to read. This command will generate several log files in the current directory, including
conn.log,dns.log, andhttp.log. - Key Log Files: The most important logs for this exercise are:
conn.log: A summary of all connections (IP, ports, duration, bytes).dns.log: Details every DNS query and response.http.log: Records HTTP requests, including URIs, methods, user-agents, and hostnames.
- Investigating Suspicious DNS Activity: A Case Study in Tunneling
DNS is a fundamental protocol often allowed through firewalls, making it a prime vector for covert communication channels like DNS tunneling. In this scenario, an alert for “Anomalous DNS Activity” has been triggered. Our goal is to confirm if it’s a true positive.
- Step 1: Generate the Logs. Run Zeek against the provided PCAP.
zeek -C -r dns-tunneling.pcap
- Step 2: Identify the Suspicious Host. A host involved in DNS tunneling will generate an abnormally high volume of DNS requests. We can find the source IP by counting the number of DNS queries per internal host.
cat dns.log | zeek-cut id.orig_h | sort | uniq -c | sort -1r
This command counts (
uniq -c) and sorts (sort -1r) the occurrences of each source IP (id.orig_h) in descending order. The top result is likely the compromised host. - Step 3: Analyze the Queries. DNS tunneling often uses long, random-looking subdomains to encode data. To see this, extract the `query` field from the DNS log.
cat dns.log | zeek-cut query
If you see a pattern like
[random-string].cisco-update.com, it is a strong indicator of a Domain Generation Algorithm (DGA) or tunneling. - Step 4: Count Unique Domains. To quantify the scale, count the number of unique second-level domains (SLDs). This helps avoid being overwhelmed by the random subdomains.
cat dns.log | zeek-cut query | rev | cut -d '.' -f 1-2 | rev | sort | uniq | wc -l
This command reverses the domain (
rev), cuts the first two parts (the SLD and TLD), reverses it back, and then counts the unique entries. A very low number (e.g., 6 unique domains) against thousands of queries confirms a tunnel to a specific destination.
- Uncovering Phishing Campaigns and Malware Callbacks via HTTP Logs
HTTP logs are a goldmine for detecting phishing attempts and malware callback traffic. When a user clicks a malicious link or malware phones home, it leaves a trail in the http.log.
- Step 1: Isolate the Suspicious Source. Start by identifying the source of the malicious traffic from the `conn.log` or
http.log.cat http.log | zeek-cut id.orig_h | sort | uniq -c | sort -1r
- Step 2: Examine HTTP Requests. The `http.log` contains critical fields like
host,uri, anduser_agent. A phishing attempt might involve a user downloading a malicious document from a suspicious domain.cat http.log | zeek-cut host uri user_agent method
Look for requests to domains that don’t match your organization’s business. For instance, a request for `smart-fax.com` in a corporate environment would be highly suspect.
- Step 3: Hunt for Malicious Files. Zeek can extract files transferred over HTTP and log their metadata in
files.log. This is crucial for identifying malware payloads.cat files.log | zeek-cut md5 sha1 mime_type filename
You can then take the extracted MD5 hash and look it up on a threat intelligence platform like VirusTotal. For example, finding an MD5 hash associated with a malicious `.exe` file named `PleaseWaitWindow.exe` confirms the infection.
- Step 4: Correlate Evidence. By correlating the `http.log` (which shows the download of `Invoice&MSO-Request.doc` from
smart-fax.com) with the `files.log` (which reveals the file contains VBA macros), you can confirm a phishing attempt designed to deliver malware.
4. Correlating Logs for a Complete Picture
The power of a SOC analyst lies in connecting the dots. A single alert is just a starting point. The true investigation begins when you correlate data across multiple log sources.
- Scenario: An alert fires for a suspicious domain in the
dns.log. Don’t stop there. Take the source IP and pivot to theconn.log.cat conn.log | grep [bash]
This will show you all the connections that host made, including destination ports. Does it connect to an external IP on port 4444 (a common C2 port) shortly after a DNS query to a malicious domain?
- Pivot to HTTP: Check the `http.log` for the same source IP to see if it downloaded any files or sent any unusual POST requests to the C2 server.
- The Analyst Mindset: This process of pivoting from one log to another is what separates good analysts from great ones. You are not just looking for an alert; you are building a timeline of the attacker’s actions.
5. Advanced Techniques: Detecting C2 Beaconing
Command and Control (C2) beaconing is a technique where malware periodically checks in with its server to receive instructions or exfiltrate data. This activity has a distinct pattern that can be detected in conn.log.
- Analyze Connection Duration: A C2 channel might establish long-lived connections. You can find the longest connection duration to investigate further.
cat conn.log | zeek-cut duration | sort -1 | tail -1
- Identify Beaconing Patterns: Look for regular, periodic connections from an internal host to the same external IP. Tools like RITA (Real Intelligence Threat Analytics) can automate this analysis, but you can manually spot it by examining the `conn.log` for a specific destination IP and source port.
cat conn.log | grep [bash] | zeek-cut ts id.orig_h
If you see connections occurring every 60 seconds like clockwork, you have likely found a beaconing C2 channel.
What Undercode Say:
- Key Takeaway 1: Correlation is King. A single log entry is a clue, but a collection of correlated logs is evidence. The ability to pivot between
dns.log,http.log, and `conn.log` to build a timeline of an attack is the most critical skill for a SOC analyst. - Key Takeaway 2: Master Your Tools. Proficiency with command-line tools like
zeek-cut,grep,sort, and `uniq` is non-1egotiable. These utilities allow you to quickly parse and analyze massive log files, turning raw data into actionable intelligence.
Analysis: The guide provides a solid, hands-on foundation for network security monitoring. The step-by-step approach makes complex concepts like DNS tunneling and C2 beaconing accessible. However, it remains a manual process. In a real enterprise environment, analysts would use a SIEM (Security Information and Event Management) to automate the correlation and alerting, and tools like RITA to automatically detect beaconing patterns. The core analytical mindset of hypothesis-driven investigation, however, remains the same.
Prediction:
- -1 (Negative): As encryption (TLS/HTTPS) becomes ubiquitous, the visibility provided by clear-text `http.log` will continue to diminish. Attackers will increasingly hide their C2 traffic within encrypted tunnels, making detection more challenging and forcing analysts to rely more heavily on metadata from `conn.log` and TLS certificates.
- +1 (Positive): The increased adoption of AI and machine learning in SIEM and NDR (Network Detection and Response) platforms will automate the detection of subtle anomalies, such as those found in this guide. This will allow analysts to focus on higher-level investigation and threat hunting rather than manual log parsing, significantly reducing detection and response times.
- +1 (Positive): The demand for skilled SOC analysts who possess a deep understanding of network protocols and log analysis will remain exceptionally high. Hands-on skills with tools like Zeek are becoming a prerequisite for entry-level cybersecurity roles, and mastering them is a powerful career differentiator.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Kakarlaanandamohancybersecurityexpert Soc – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
