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:

1. Use identical counts (suggesting automated tooling)

2. Include a null byte injection technique (%00)

3. 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:

1. 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.

2. 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:

1. Started with simple direct path attempts through /layouts and /libraries

2. Escalated to more sophisticated parameter manipulation via /index.php

3. 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:

1. Internal to internal traffic (lateral movement?)

2. Systematic testing of different access methods

3. Multiple successful retrievals

4. 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:

1. Root directory enumeration (/)

2. Direct passwd attempts (/etc/passwd, /etc/passwd%00)

3. 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:

1. Initial Phase (20:22:25-20:22:30):

   • Started with /layouts/?v=file:/etc/passwd

   • Quick success led to directory variation attempts

2. Escalation Phase (20:22:44-20:22:51):

   • Moved to /libraries/ path testing

   • Multiple successful retrievals

3. 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):

1. That internal IP needs some attention - time to escalate to our incident response team to have a chat with its owner

2. 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!

3. 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!

---