DEV Community: Vimal Mudalagi

Threat Hunting: What I Learned from TryHackMe

Vimal Mudalagi — Fri, 02 Oct 2026 13:35:22 +0000

Task 1 — Introduction

What the room covers

What Threat Hunting is.
Difference between Threat Hunting and Incident Response.
What threat hunters search for.
Different hunting approaches.
Hunting methods and techniques.
Applying concepts to realistic scenarios.

Task 2 — What Is Threat Hunting?

Threat Hunting

Systematic, proactive search for malicious activity that may have evaded detection systems.
Hunters do not wait for alerts.
They search systems, logs and networks for missed malicious activity.
Goal is to find threats before attackers achieve their objectives.

Why it is needed

Security systems are not perfect.
Attackers may:
- Use zero-day exploits.
- Modify tools to evade detection.
- Operate slowly to avoid alarms.

Threat Hunting vs Incident Response

Aspect	Threat Hunting	Incident Response
Trigger	Self-initiated	Security alert/detection
Approach	Proactive	Reactive
Timeline	Before compromise is obvious	After threat is detected
Outcome	Improve detections	Containment + remediation
Example	Hunter finds suspicious PowerShell before an alert	Alert fires → IR investigates and contains

Threat hunting finds threats missed by detection.
IR contains/removes discovered threats.
IR findings can improve future detection and hunting.
Both disciplines work together. citeturn1view0

Dwell Time

Dwell time: average time an attacker remains undetected after initial compromise.
Room states typical 2024–2025 dwell times as 20–30 days.
Advanced attackers may remain for months/years.
During dwell time attackers can:
- Perform reconnaissance.
- Steal credentials.
- Move through the network.
- Exfiltrate data.
Longer dwell time → potentially greater damage.
Threat hunting aims to reduce dwell time.

Real-world example

Financial organization receives intelligence about an attack group.
Hunter searches logs for related indicators.
Finds unusual PowerShell activity.
Attacker had been inside for 14 days without automated detection.
Attacker was mapping the network and identifying valuable targets.
Hunting allowed IR to contain/remove the attacker before deeper progression. citeturn1view0

Task 3 — Hunting Approaches

Three foundational approaches:

Hypothesis-Driven
Intelligence-Driven
Indicator-Driven

The selected approach depends on:

Available information.
Question being investigated.
Resources.
Threat priorities.
Organizational circumstances/maturity.

1. Hypothesis-Driven Hunting

Starts with a question or suspicion.
Hunter creates a hypothesis and searches for evidence to prove/disprove it.
Useful for a specific:
- User.
- System.
- Department.
- Attack scenario.

Example

Finance workstations suspected of phishing compromise.

Hunter searches for:

Suspicious PowerShell.
Unusual network connections.
Credential dumping.
Unexpected process spawning.

When to use

Specific concern exists.
Need focused investigation.
Domain knowledge about environmental risks is available.

2. Intelligence-Driven Hunting

Starts with external Threat Intelligence.
Hunter learns about threats affecting their industry/geographic region.
Searches the environment for evidence of those threats.
Uses research from:
- Security researchers.
- Vendors.
- Global security community.

MITRE ATT&CK

Organizes adversary tactics and techniques based on real-world observations.
Provides standardized technique IDs.

Examples:

T1566.002 — Phishing / Spearphishing Link
T1059.001 — PowerShell
T1055 — Process Injection
T1041 — Exfiltration Over C2 Channel

Example

APT group targeting financial institutions:

T1566.002 → initial access.
T1059.001 → command execution.
T1041 → data theft.

Hunter searches for:

Matching indicators.
Related behavioral patterns.
Connections to known C2 servers.

When to use

Published intelligence matches your threat profile.
Relevant industry/geography/business model.
Detailed threat feeds, vendor reports or incident reports are available.

3. Indicator-Driven Hunting

Focuses on concrete Indicators of Compromise (IOCs).

Examples:

File hashes.
IP addresses.
Domain names.
Email addresses.
Command-line patterns.

Example

Threat feed provides 150 malicious file hashes.
Hunter searches for process execution/file creation matching those hashes.
Result: indicator either exists or does not.

When to use

Large IOC lists are available.
Clear/objective results are needed.
Automation is useful.

Selecting an Approach

Situation	Approach
Specific concern about asset/user	Hypothesis-driven
Threat intelligence about industry threat	Intelligence-driven
Known hashes/IPs/domains from trusted source	Indicator-driven

Organizations may use all three.

Questions hunters consider

Where might the attacker move?
What systems could they access?
How might they establish persistence?
Where could they go from here? citeturn1view0

Task 4 — Hunting Targets

Targets = WHAT we hunt for.

Attackers create artifacts by:

Executing commands.
Creating files.
Establishing network connections.
Modifying settings.
Interacting with applications.

Three main targets:

1. Known Malware

Search for malware already known/reported.
Repositories/threat feeds contain:
- File hashes.
- Signatures.
- Behavioral analysis.

Tool/resource

VirusTotal

Example — Emotet

Possible hunting targets:

Emotet file hashes.
Launch command-line patterns.
C2 connections.
Credential-stealing behavior.
Lateral-movement behavior.

Challenges

Malware changes constantly.
Attackers can:
- Recompile malware.
- Add obfuscation.
- Change infrastructure.
- Create variants.
Old hashes may not match newer variants.
Zero-day malware has no known indicators.

Sources

Malware repositories.
Threat intelligence feeds.
Incident reports.
Security vendor publications.
Information-sharing platforms.

2. Attack Residues

Artifacts left behind while attackers execute their attack chain.
Attackers must:
- Execute code.
- Run commands.
- Access files.
- Create persistence.
- Establish C2 communication.

Example

Attacker uses lsass.exe to dump password hashes.

Hunter may observe:

Unusual process creation.
Unexpected parent process.
Abnormal memory access.

Possible commands:

whoami
net user
ipconfig
tasklist

Why useful

Attack residues can be independent of specific malware.
Different attackers/tools may leave similar residues.
Can help detect unknown malware or zero-days.

Common residues

Unusual process spawning.
cmd.exe/PowerShell from unexpected parents.
Administrative-tool command execution.
Unexpected external IP connections.
Suspicious file creation.
Registry modifications.
Unusual privilege escalation.

3. Known Vulnerabilities

Hunt for evidence that known vulnerabilities were exploited.
Attackers can develop exploits quickly after disclosure.
Vulnerable systems remain exposed during the patching window.

Example — Log4Shell

CVE-2021-44228
Critical Log4j vulnerability.
Exploitation through specially crafted messages.

Hunter searches for:

HTTP requests containing exploit patterns.
Unusual Java behavior.
Unexpected network connections.
Unexpected child processes.
Unusual filesystem activity.

Why it matters

Vulnerability exploitation is a common initial-access method.
Hunting can identify exploitation earlier.

Integrating the 3 Targets

One hunt can combine:

Known malware.
Attack residues.
Vulnerability exploitation evidence.

Targets = WHAT evidence we hunt for. citeturn1view0

Task 5 — Hunting Techniques

Techniques = HOW we hunt.

Where Threat Hunters Search

Data sources include:

Event logs.
EDR data.
SIEM systems.
Network traffic/flow data.
DNS logs.
Web proxy logs.
Firewall logs.
Application logs.
System registry.
Memory.
Configuration files.
Temporary directories.
Backup systems.
Cloud services.

Important point

No single data source gives the complete story.
Hunters correlate:
- Logs.
- Network data.
- Endpoint information.
Mature programs continuously expand visibility and data collection.

Method 1 — Attack Signatures

Attack signature = pattern indicating malicious activity.

Examples:

Known malware file hash.
Malicious command-line parameters.
Unusual process parent.
Known malicious URL pattern.
Registry modification at persistence location.

Example:

powershell.exe + -EncodedCommand + DownloadString

cmd.exe spawned from winword.exe

Example registry location:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Used in

EDR.
SIEM.
Antivirus logs.
Firewall logs.

MITRE connection

PowerShell signature → T1059.001
Registry persistence → T1547

Effectiveness

Good against known threats.
Can miss variations and zero-days.
Produces clear/objective results.

Method 2 — Indicators of Compromise (IOCs)

Specific attacker artifacts:

File hashes.
IP addresses.
Domains.
Email addresses.
URLs.
Registry keys.

Hunting examples

Hashes → EDR/SIEM.
IPs → firewall/network logs.
Domains → DNS logs.
Emails → email logs.
URLs → web proxy logs.

Tools/platforms

SIEM.
MISP
Recorded Future
EDR.
Firewall logs.
DNS logs.

Effectiveness

Clear/objective results.
Attackers frequently change infrastructure.
IOCs become outdated.
Recent/relevant IOCs are most useful.

Method 3 — Behavioral Pattern Analysis

Looks for sequences of events that together indicate malicious activity.

Examples

Process chain

Word.exe → cmd.exe → powershell.exe → external IP

File access

One user accesses hundreds of sensitive files within minutes.

Lateral movement

Remote execution on A
→ process creation on B
→ credential access on B

Privilege escalation

Normal user process
→ SYSTEM permissions
→ sensitive file access

Data collection

Database query
→ bulk file reads
→ archive creation
→ network transmission

Used in

Advanced SIEM.
EDR process-tree analysis.
Behavioral analysis tools.

MITRE connection

Attack chains can correspond to combinations of MITRE techniques.

Effectiveness

Can detect attacks without known malware/IOCs.
Focuses on attacker actions rather than specific tools.
False positives are possible.
Normal administrative activity can resemble attack behavior.

Method 4 — Logical Queries & Anomaly Detection

Uses conditional logic to identify suspicious activity that differs from normal behavior.

Examples

Administrator commands at 3 AM.
SYSTEM account running interactive commands.
User accessing normally unused data directories.
Internal system connecting to unusual ports.
Password change for inactive account.
Non-IT user downloading large amounts of files.

Example query patterns

EventCode=4688
where ParentProcessName NOT IN [explorer.exe, cmd.exe]
AND User = SYSTEM
AND CommandLine IN [whoami, net user, ipconfig]

EventCode=4663
where TargetUserName NOT IN [IT_team]
AND ObjectName LIKE "*\sensitive_data\*"
AND count > 50

Network
where SourceIP IN [10.*, 192.168.*]
AND DestinationPort NOT IN [80, 443, 53, 22, 21]
AND BytesSent > 1000000

EventCode=4723
where TargetUserName NOT IN [active_users]
AND SubjectUserName = Administrator

Used in

Splunk SPL
ELK / Elasticsearch Query Language
Azure KQL
EDR advanced hunting.
Security data lakes.

MITRE connection

Queries can target techniques such as:

T1087 — Account Discovery
T1005 — Data from Local System

Effectiveness

Highly customizable.
Can detect unknown attacks through abnormal behavior.
Requires understanding normal environment behavior.
Effective query construction can be difficult.

Combining Hunting Methods

Effective hunts rarely use only one method.

Example:

Load IOC lists into SIEM.
Search for behavioral patterns matching known attackers.
Create logical queries for similar activity from unknown attackers.

Layered hunting → known + unknown threat detection. citeturn1view0

Task 6 — Practical

Scenario

You are a threat hunter at a financial-services organization.

Threat intelligence identifies APT-Serpent.
APT-Serpent targets organizations in the sector.
No alerts have fired.
Goal: proactively determine whether the attacker has gained a foothold.

Practical questions

Number of known APT-Serpent campaigns since 2021.
Phase where CustomBackdoor gets dropped.
Primary initial-access vector used by APT-Serpent.
Time interval between CustomBackdoor HTTPS C2 beacons.
Flag received after selecting the correct hunting approach + target. citeturn1view0

Task 7 — Conclusion

Core concepts

Threat Hunting

Fundamentally proactive.
Does not wait for alerts.
Searches for threats detection systems missed.
Especially useful during early attack stages.

3 Approaches

Hypothesis-driven
Intelligence-driven
Indicator-driven

3 Targets

Known malware
Attack residues
Vulnerability exploitation

4 Methods

Attack signatures
IOCs
Behavioral pattern analysis
Logical queries

Mindset

Suspicious thinking.
Methodical analysis.
Continuous learning.

Result of every hunt

Find active threats.
Identify detection gaps.
Strengthen future detection.
Improve understanding of attackers and the environment.

🧠 One-page memory map

                 THREAT HUNTING
                       │
        ┌──────────────┴──────────────┐
        │                             │
       WHAT                           HOW
     Targets                       Methods
        │                             │
 ┌──────┼──────┐              ┌──────┼────────┐
 │      │      │              │      │        │
Malware Residues Vulns    Signatures IOCs  Behavioral
                                      │
                                Logical Queries

Approaches

Specific suspicion     → Hypothesis-driven

Threat Intelligence    → Intelligence-driven
        ↓
    MITRE ATT&CK

Known hashes/IPs/etc.  → Indicator-driven

Core distinction

Incident Response → ALERT → Investigate → Respond
Threat Hunting    → HUNT  → Find threat → Improve detection

Core objective emphasized by the room

Find threats proactively and reduce the time attackers remain undetected. citeturn1view0

Next rooms: Threat Hunting: Foothold → Pivoting → Endgame → Hunt Me I: Payment Collectors → Hunt Me II: Typo Squatters.

Learning Web Security #1: Broken Access Control (OWASP Top 10 #1 - Beginner's Guide)

Vimal Mudalagi — Tue, 07 Jul 2026 06:38:35 +0000

Disclaimer: I'm currently learning web security through PortSwigger Web Security Academy. These are my beginner-friendly notes rewritten as a blog to help reinforce my understanding. If you're just starting out, I hope this makes the topic easier to understand.

What you'll learn:

In this article you'll learn:

✔ What Broken Access Control is

✔ Vertical Privilege Escalation

✔ Security by Obscurity

✔ Parameter-Based Access Control

✔ Platform Misconfiguration

✔ Horizontal → Vertical Escalation

✔ IDOR

✔ Lessons learned from PortSwigger labs

Concept Map:

What is Broken Access Control?

Broken Access Control happens when a user is able to access data, pages, or perform actions that they are not supposed to.

Why should you care?

Broken Access Control has ranked #1 in the OWASP Top 10 (2021) because it can expose sensitive data, allow privilege escalation, and let attackers perform actions they should never be able to perform.

Think of a website with two types of users:

Normal User
Admin

A normal user should only be able to view their own profile and perform basic actions.

An admin, however, can manage users, delete accounts, change settings, etc.

If a normal user somehow gains access to those admin features, that's Broken Access Control.

In interview terms:

Broken Access Control is the failure to properly enforce authorization, allowing users to perform actions beyond their intended permissions.

1. Vertical Privilege Escalation

Vertical Privilege Escalation means moving up the permission hierarchy.

Example:

Normal User
      ↓
Admin

A normal user should never be able to become an administrator.

1.1 Unprotected Functionality

One of the simplest forms of Broken Access Control is Unprotected Functionality.

Imagine a website has an admin page:

/admin

The developer removes the Admin button from the normal user's dashboard.

Problem solved?

No.

If a user manually visits:

/admin

and the server doesn't verify whether they're actually an admin, the page opens.

The mistake here is relying on the user interface instead of enforcing authorization on the server.

Attacker's mindset

When testing a website, an attacker may ask:

Can I manually visit hidden pages?
Can I guess common admin URLs?
Can I inspect robots.txt?
Can I brute-force directories?

PortSwigger Lab

In the lab, the admin panel wasn't linked anywhere.

However, visiting:

/robots.txt

revealed:

/administrator-panel

Opening that URL directly gave access to the admin panel, where I was able to delete the user carlos.

Key takeaway

robots.txt is public.

Hiding an admin URL is not the same as protecting it.

The server must always verify permissions before allowing access.

1.2 Security by Obscurity

Sometimes developers try to make admin pages "secret" by giving them strange URLs like:

/administrator-panel-yb556

This is called Security by Obscurity.

The idea is simple:

"If attackers can't guess the URL, they can't access it."

Unfortunately, that isn't real security.

The hidden URL may still appear inside:

JavaScript files
HTML source code
Network requests

Anyone can inspect these using the browser's Developer Tools.

Once the URL is discovered, if the server doesn't perform authorization checks, the page becomes accessible.

Key takeaway

A hidden URL is not a protected URL.

Always implement proper server-side authorization.

1.3 Parameter-Based Access Control

Some applications make another dangerous mistake.

Instead of storing a user's role securely on the server, they store it somewhere the user can modify.

Examples include:

Cookies
Hidden HTML fields
URL parameters
JSON request bodies

Imagine the application uses:

/login/home.jsp?admin=false

/login/home.jsp?role=0

If the server blindly trusts these values, an attacker can simply change them to:

admin=true

role=1

and gain administrator privileges.

This is why client-side data should never be trusted.

PortSwigger Lab 1 – Cookie Manipulation

In this lab:

The admin panel existed at /admin
Access was denied initially

Using Burp Suite, I intercepted the login response and found the cookie:

Admin=false

I changed it to:

Admin=true

After forwarding the modified response, I could access the admin panel and delete carlos.

What I learned

Cookies belong to the client.

Anything stored on the client can be modified.

The server should never trust role information stored in cookies.

PortSwigger Lab 2 – JSON Parameter Manipulation

This lab required users to have:

roleid = 2

I updated my email address while intercepting the request in Burp Suite.

Inside the JSON request body, I found my current role.

I modified it to:

"roleid": 2

After sending the modified request, my role changed to administrator.

I could then access /admin and delete carlos.

What I learned

Just because data is sent inside JSON doesn't mean it's secure.

If the server trusts user-controlled JSON values, privilege escalation becomes possible.

Final Thoughts

The biggest lesson from this learning was surprisingly simple:

*Never trust client-controlled data. Always validate authorization on the server or in simple words: Never trust anything coming from the browser *

Whether it's:

a URL
a cookie
a hidden field
a request parameter
or a JSON value

all of them can be modified by an attacker.

The responsibility of deciding who is allowed to do what always belongs to the server.

That's the core idea behind preventing Broken Access Control.

Now that we've seen common authorization mistakes, let's look at another interesting case where access control fails due to platform misconfiguration.

1.4 Platform Misconfiguration and Access Control Bypass

Another interesting form of Broken Access Control happens because of platform misconfiguration.

This sounds complicated at first, but the idea is simple:

The website has security checks, but the security layer and the application do not interpret requests in the same way.

Imagine the application has a rule like:

DENY:
POST /admin/deleteUser

This means users should not be able to access that admin functionality.

Normally, a request looks like this:

POST /admin/deleteUser

The security layer sees the request and blocks it.

However, some frameworks support special headers such as:

X-Original-URL
X-Rewrite-URL

These headers can internally change where a request is routed.

An attacker may send:

POST /
X-Original-URL: /admin/deleteUser

Now something unexpected happens:

Security layer sees:

POST /

Application sees:

/admin/deleteUser

The security system thinks the request is harmless, while the application executes the admin functionality.

This can lead to access control bypass.

Another technique: HTTP Method Bypass

Sometimes security rules only restrict one HTTP method.

Example:

DENY:
POST /admin/deleteUser

Developers assume deletion will only happen through POST requests.

An attacker may test:

GET /admin/deleteUser?user=carlos

If the application accidentally accepts GET requests as well, the action still executes.

The security rule only checked:

POST

but the application accepted:

GET

What I learned

Security checks should not rely only on proxies, URLs, or request methods.

Authorization should always be validated on the server for every sensitive action.

The biggest takeaway:

If the security layer and application interpret requests differently, access control bypasses can happen.

2. Horizontal to Vertical Privilege Escalation

Earlier, we looked at Vertical Privilege Escalation, where a normal user directly gains administrator access.

But sometimes attackers take a different route.

They first compromise another user's account (Horizontal Privilege Escalation) and then use that account to become an administrator.

Imagine your account page is accessed using:

/myaccount?id=123

If the application doesn't verify ownership, an attacker might simply change the URL to:

/myaccount?id=456

If User 456 happens to be an administrator, the attacker now has access to an admin account.

In the PortSwigger lab using Burp Suite, changing the user identifier exposed the administrator's account page, which revealed the administrator's password. Using those credentials, I logged in as the administrator.

What I learned

Horizontal privilege escalation isn't always the final goal.

Sometimes it's just the first step toward gaining administrator privileges.

3. Insecure Direct Object References (IDOR)

An Insecure Direct Object Reference (IDOR) occurs when an application directly uses user-supplied input to access resources without checking whether the user is actually authorized to access them.

These resources (called objects) can include:

User profiles
Chat transcripts
Documents
Images
Orders
Database records

For example, suppose a chat transcript is stored as:

/download/2.txt

If I manually change it to:

/download/1.txt

and the server returns another user's transcript without checking ownership, that's an IDOR vulnerability.

The problem isn't that the URL can be changed.

The real problem is that the server trusts the user-supplied object reference without verifying whether the user should have access to it.

PortSwigger Lab

In this lab, chat transcripts were stored as text files with predictable names such as:

1.txt
2.txt
3.txt

After viewing my own transcript, I noticed the filename pattern.

I changed:

2.txt

to:

1.txt

The server returned another user's chat transcript, which contained Carlos's password.

I then used those credentials to log into Carlos's account.

What I learned

If an application exposes predictable object references without verifying ownership, attackers can access data that belongs to other users.

How to Prevent Broken Access Control

Most Broken Access Control vulnerabilities exist because the server trusts information that comes from the client.

Some simple security principles can prevent many of these issues:

Deny access by default unless explicitly allowed.
Perform authorization checks on the server for every request.
Never rely on hidden URLs or secret page names for security.
Verify that users own the resources they are trying to access.
Use a centralized authorization mechanism across the application.
Regularly audit and test access control rules.

Final Takeaway

Throughout these labs, one idea kept appearing again and again:

Never trust the client. Always enforce authorization on the server.

Whether an attacker modifies a URL, cookie, request parameter, JSON value, or filename, the server should always verify who is making the request and whether they are allowed to perform that action.

That's the foundation of secure access control.

References

OWASP Top 10
PortSwigger Web Security Academy (Broken Access Control labs)