A DEATHCON Thrunting Workshop Overview Part 3: ⚡ Hypothesis-Driven Threat Hunting
Detecting /etc/passwd File Access and Exfiltration in HTTP Traffic
If you’re just tuning in now, welcome! This is part 3 of a series on a workshop previously given at DEATHCon 2024. Head over here if you want to start from the beginning.
Drumroll please 🥁
We’re excited to share what you’ve all been waiting for—the scenarios of the workshop! We have three for you, each covering a different approach to threat hunting, which the PEAK Threat Hunting Framework defines.
We’re going to walk through this as you typically would, working through each phase of PEAK. Not to worry, we will provide you with all you need to follow!
We will start off with a hypothesis-driven example, which is the most common way to hunt and probably the type you are most familiar with from your own experience. In hypothesis-driven hunting, we begin with a theory about what is happening in our environment. If you recall, PEAK has three main phases (Prepare, Execute, and Act) with Knowledge incorporated throughout. Let’s kick it off with Prepare.
Let’s examine a hypothesis in which attackers attempt to access sensitive system files - specifically the /etc/passwd file - through HTTP requests. This scenario is based on real attack patterns observed, in which adversaries attempt to exploit web applications to gain unauthorized access to critical system files.
Prepare Phase - Understanding the Threat
Before diving into our hypothesis, we need to do research on our topic. You may know NOTHING about your topic when you start, but by the end, you will be a mini subject matter expert (SME). For this hunt, we are digging into the /etc/passwd file access and exfiltration.
Why Attackers Target /etc/passwd:
Contains critical system information: usernames, user IDs, group IDs, home directories, and default shells
Enables user enumeration and potential privilege escalation paths
Common target in Local File Inclusion (LFI) and directory traversal attacks
Reveals system configuration details valuable for reconnaissance
Common Attack Techniques:
Direct path traversal: ../../../etc/passwd
URL-encoded variants: %2F%65%74%63%2F%70%61%73%73%77%64
Null byte injection: /etc/passwd%00
Double encoding: %252F%252E%252E%252F
Parameter manipulation: ?file=/etc/passwd
Expected Artifacts in HTTP Traffic:
GET requests containing /etc/passwd in various encodings
Automated tool signatures in user agent strings
High-frequency requests from single source
Sequential scanning patterns across multiple hosts
Successful responses (200 ✅) indicating potential file access
Hypothesis
Attackers are targeting HTTP web servers to access /etc/passwd files using web exploitation techniques, leveraging path traversal, encoding tricks, and injection methods to bypass security controls and exfiltrate data.
Let’s break it down:
Technique: Path traversal, encoding tricks, & injection attacks against web applications
Target: Linux HTTP web application servers hosting /etc/passwd files
Actions on Objectives: Exfiltrating /etc/passwd data to identify system accounts, validate access, or stage privilege escalation
Remember that hypotheses can be written and approached in many different ways - there's no single correct format. As you work through this scenario (and future ones), you might find yourself wondering about alternative angles or related threats to investigate. That's the essence of threat hunting! Keep track of these ideas (open a backlog or just jot in your notes), as they often lead to valuable hunting opportunities in the future. The key is to start with a clear, testable hypothesis that guides your initial investigation while remaining open to discovering unexpected patterns or behaviors along the way.
We now have everything we need to wrap the Prepare phase and dive in to Execute the thrunt! Are you ready to thrunt?
Execute the thrunt
Step 1: Initial Data Exploration - Understanding Our Environment
Why this step? As Lauren discussed in Part 2 of our series, you shouldn’t start thrunting without knowledge about your data. Before diving into the specific attempts to access the /etc/passwd file, we need to understand our environment and establish what "normal' looks like. This helps us:
Establish baseline activity for /etc directory access
Identify commonly used user agents
Discover legitimate business processes that might access these paths
This search finds the most frequent combinations of accessed paths and user agents under the /etc directory, helping us understand normal access patterns before hunting for suspicious activity.
index=thrunt sourcetype=stream:http http_method=GET uri=*/etc/*
| stats count by uri_path, http_user_agent
| sort - count
| head 10
SPL Breakdown
This query hunts for potential directory traversal attacks by searching for HTTP GET requests containing "/etc/" in the URI path
It summarizes the findings by counting how many times each URI path was accessed and which user agents were used, helping identify patterns of reconnaissance or automated scanning
The results show the top 10 most frequently accessed paths, prioritizing the most targeted paths
Let’s analyze these results together:
Looking at the output from our first search, we can already spot some concerning patterns. First up, /index.php has the highest access count at 150 hits using a generic "UserAgent" string - not unusual for a web server, but let's keep an eye on it.
Now here's where it gets spicy 🌶️ - the second and third most accessed paths are /etc/passwd and /etc/passwd%00 with 66 hits each. That's a major red flag since these attempts:
Use identical counts (suggesting automated tooling)
Include a null byte injection technique (%00)
Are directly targeting our sensitive passwd file
The remaining paths show expected web activity (/layouts/, /libraries/), with some legacy browser traffic mixed in.
The good news is this baseline tells us exactly what we might expect for normal activity (/layouts, /libraries, /icons), making the sus traffic stick out like a sore thumb. The bad news? We've got some serious /etc/passwd hunting to do!
While this search is VeRy BaSiC, it is often the first of a query we will iterate on and continue to narrow our scope until we get a higher fidelity query for our hypothesis. I promise we will run more fun SPL later 😈
Leading to Step 2: After understanding our baseline, we'll specifically focus on attempts to access the /etc/passwd file, looking for potential malicious patterns.
Step 2: Identifying Suspicious Access Patterns
Why this step? Now that we understand normal behavior, we'll look specifically for attempts to access /etc/passwd. Attackers often use various encoding techniques to bypass security controls, so we need to search for multiple variants.
index=thrunt sourcetype=stream:http uri=*passwd* OR uri=*%passwd* OR uri=*%2Fpasswd* OR uri_path=*/../etc/passwd*
| stats count values(uri) as attempts values(http_user_agent) as user_agents by src_ip
| sort - count
Let’s analyze these results together:
Whoaaa check out what our search uncovered! 🔍 Let's break down the most interesting findings:
Looking at our top offender, IP 172.16.50.206 (internal IP alert! 🚨) made 546 attempts with a variety of suspicious requests. Let's dissect what they tried:
First attempt is basically throwing something at the wall to see if it would stick:
Command injection (cmd.exe)
Path traversal (/etc/passwd)
Shell command execution (/bin/sh)
SQL injection test (SELECT%20)
XSS attempts (<script>alert(1)) This looks like automated vulnerability scanning behavior.
Then we a smattering of /etc/passwd access attempts:
Typical requests: /etc/passwd
Null byte injection: /etc/passwd%00
Parameter adding: error=login and error=fpError
Different view parameters suggesting they're testing multiple application paths
Our second attacker (31.171.154.114) took a different approach:
Single attempt using curl 7.72.0
A little OSINT research and we can see they were trying to access a vulnerable VPN path! (/dana/html5acc/guacamole/) Holy 🥑.
Thoughts so far on this activity:
Internal actor doing broad automated scanning
External actor making targeted attempts through VPN infrastructure
Leading to Step 3: Now that we've identified suspicious attempts, let's focus on which ones were successful - these represent our highest risk.
Step 3: Analyzing Successful Access Attempts
Why this step? Successful access to /etc/passwd (HTTP status 200) indicates potential security control failures. These events require immediate investigation as they could represent exposure of actual data. 🤯
index=thrunt sourcetype=stream:http (uri=*passwd* OR uri=*%passwd*) status=200
| table _time src_ip dest_ip uri http_user_agent status bytes content_type
| sort - _time
SPL Breakdown
This query builds on the previous but looks for successful (status 200) access attempts, showing events where attackers may have retrieved sensitive data rather than just attempted access
It displays key details about each successful attempt including timestamp, source/destination IPs, exact URI accessed, user agent, and response size (bytes) - giving investigators the full context needed to assess the impact
Let's analyze these results together:
Uhoh. We've got successful access! 🚨 Let's break down what we're seeing in chronological order:
First, a concerning pattern emerges:
All successful access (status 200) is from our internal IP 172.16.50.206
All attempts target the same destination (172.16.50.42)
This happened in a tight timeframe (around 20:22-20:23 on August 27)
Looking at the attack evolution:
Started with simple direct path attempts through /layouts and /libraries
Escalated to more sophisticated parameter manipulation via /index.php
Used multiple encoding variations:
Direct: /etc/passwd
URL encoded with null byte: file:/etc/passwd%00
Parameter injection through different modules
The response sizes are telling:
We see consistent ranges between 500-1200 bytes
These sizes align with typical /etc/passwd file content
Multiple successful extractions suggest full file access
What makes this particularly concerning:
Internal to internal traffic (lateral movement?)
Systematic testing of different access methods
Multiple successful retrievals
Clear evidence of automated tool usage due to timing and patterns
Looks like we've confirmed our hypothesis about passwd file access!
Leading to Step 4: With our successful attempts identified, let's look for signs of coordinated campaigns or systematic scanning.
Step 4: Identifying Attack Campaigns
Why this step? Automated tools and coordinated attacks often show distinct patterns in their timing and frequency. By analyzing hourly patterns, we can identify systematic scanning and potential campaigns. The bin command here groups events into 1-hour intervals. This command adjusts field values (in this case _time) so all items in a particular time window have the same value. Using span=1h means all events within the same hour will be grouped together. See the bin command documentation if you need more info.
index=thrunt sourcetype=stream:http (uri=*passwd* OR uri=*%passwd*)
| bin _time span=1h
| stats count values(uri_path) as paths values(status) as response_codes by _time, src_ip, http_user_agent
| where count > 10
| sort - count
SPL Breakdown
This query builds on the previous and groups events into hourly windows, revealing attackers who make multiple attempts within short timeframes
It collects all paths attempted and their response codes for each source IP and user agent combination, showing the full scope of an attacker's reconnaissance
The filter for counts > 10 and descending sort helps identify the top activity
Let's analyze these results together:
Our hourly breakdown reveals a concentrated attack, so let's dig into what we found:
From an our internal actor (172.16.50.206) in the 20:00 hour on August 27:
546 attempts (that's about 9 requests per minute)
Using a single "UserAgent" string (hello automation 👋)
Methodically working through the system
The attack pattern shows an interesting method:
Root directory enumeration (/)
Direct passwd attempts (/etc/passwd, /etc/passwd%00)
Systematically enumerated through:
Layout paths
Library paths
Response codes tell a story:
200s - successful access 🚩
301s - redirects (they found some valid paths)
404s - failed attempts
What's particularly interesting:
No other IPs show up in our filtered results (>10 attempts)
All activity concentrated in a single hour
Very structured enumeration pattern suggesting a specific tool or script
This isn't random probing - we're looking at a methodical, automated campaign targeting our web application. Let's move to Step 5 to build our final timeline and see the full attack progression! 🕵️♀️
Leading to Step 5: Finally, let's create a comprehensive timeline of the attack activity to understand the full scope of the campaign.
Step 5: Building the Attack Timeline
Why this step? A complete timeline helps us understand the progression of attacks, identify the most active periods, and correlate successful compromises with initial probing attempts.
index=thrunt sourcetype=stream:http (uri=*passwd* OR uri=*%passwd*)
| eval success=if(status=200, "Yes", "No")
| bin _time span=1h
| stats count(eval(status=200)) as successful_attempts count as total_attempts values(uri) as uris values(http_user_agent) as agents by _time, src_ip, dest_ip
| where successful_attempts > 0
| sort - _time
SPL Breakdown
The query searches HTTP traffic for URIs with
passwd
.It focuses on successful attempts (HTTP 200 status) and groups them by hour, giving a clear view of when attackers successfully accessed sensitive files disregarding the noise from failed attempts.
The results show patterns of activity by grouping source/destination IPs, collecting the specific URIs accessed, and the user agents used. This helps identify both the tools attackers use and which password files they're targeting.
Let's analyze these results together:
Time to put all the pieces together! 🧩 Our timeline analysis reveals a clear attack story:
Breaking down the activity by our successful attacker (172.16.50.206 → 172.16.50.42):
Total attempts: 546
Successful attempts: 10
Time window: Concentrated around 20:22-20:23 UTC on August 27
The attack progression shows sophistication:
Initial Phase (20:22:25-20:22:30):
Started with /layouts/?v=file:/etc/passwd
Quick success led to directory variation attempts
Escalation Phase (20:22:44-20:22:51):
Moved to /libraries/ path testing
Multiple successful retrievals
Advanced Phase (20:23:11-20:23:20):
Switched to parameter manipulation
Used combinations of modules, parents, and views
Added null byte injection for evasion
Key observations:
All successful attempts used a single user agent (the very clever UserAgent)
Progressed from simple to complex techniques
Achieved repeated successful access
Maintained persistent access for nearly a minute
This wasn't just random scanning - we're seeing a deliberate, well-orchestrated attack that successfully compromised sensitive system files.
From Hypothesis to Act
Key takeaway from this hunt
Well thruntlings, we’ve made it! We have concluded the Execute phase and are at the Act phase, the third phase of PEAK. This is where we put everything we’ve found during our /etc/passwd hunting expedition into action. But wait—what about all that Knowledge we gained along the way? Finding evil is only half the battle—now we need to share those insights and turn them into key deliverables. That’s how we make not just ourselves better, but the entire team/org/company stronger. Let’s wrap up our findings and talk next steps!
What We Caught in Our Net 🕸️
Our initial hypothesis about attackers targeting passwd files? Proved.
We uncovered a sophisticated internal actor (IP 172.16.50.206) who:
Made 540 successful (and redirect) attempts in under an hour
Successfully accessed the file at least 10 different times
Used multiple techniques as part of their attack, from basic path traversal to null byte injection
Systematically probed our web application
Time to Lock It Down 🔒
In the Short Term (Do This ASAP):
That internal IP needs some attention - time to escalate to our incident response team to have a chat with its owner
Review the compromised /etc/passwd files for signs of tampering and identify any exposed creds. Escalate to the appropriate teams to rotate those creds and mitigate the risk!
Patch up our web server config so this doesn’t happen again
Future Hunt Ideas
What other sensitive files might they have accessed?
Check endpoint logs and see where else they've been looking at
Follow that lateral movement trail - attackers rarely stop at one system
In the Long Term:
WAF rules need updating (because one /etc/passwd access is enough)
Set up detections with the SPL you created (see For the Detection Engineers)
Document everything (as a wise leader previously told me - if it’s not in the ticket , it didn’t happen)
For the Detection Engineers 🛠️
Let's turn this hunt into an automated detection. We need alerts for:
Rapid-fire attempts at sensitive files (looking at you, 546 attempts!)
Successful sensitive file access (because 200 responses shouldn't happen here)
Those unusual user agent patterns we spotted
Traffic patterns that suggest an attacker is using a suspicious automated scanning tool rather than manual testing (might be noisy, focus on those successful attempts)
Stay curious and happy thrunting!
Looking for other hunt ideas?
That’s exactly why we built HEARTH, the Hunting Exchange and Research Threat Hub. It’s a community-driven repository where hunters can share ideas, experiment with new approaches, and contribute to a growing collection of threat hunting ideas. Every contribution gets a unique hunt number and a sticker!
🔥 Want to submit an idea or see what others are hunting? Check out HEARTH.
What’s next?
Stay tuned for future posts covering two other threat hunting approaches - baseline (exploratory) and model-assisted threat hunting (M-ATH). We’ve also deep dive into how to build better hypotheses. Thanks for tuning in!