This post isn’t an awareness piece or a guide that everyone might find useful. It’s more of a personal log, a part of “my journey” category, where I document what I’m learning as I go.

I’m currently exploring a TryHackMe room called “Detecting Web Attacks.” It’s labeled as easy, so if you’re curious, you can check it out yourself. What I’ll be doing here is jotting down what I learn throughout the room, and if I end up researching anything beyond it, I’ll include that too. Think of it as a mix of notes and insights that could serve as a future reference for me (and hopefully for someone else who stumbles upon it).

Web attacks are one of the most common ways attackers break into target systems. Any public-facing website or application can potentially be vulnerable to them. The main goal of this TryHackMe room is to understand the methodologies and tools used to detect such attacks.

Understanding Client-Side Attacks

As we move through this TryHackMe room, we come across two main categories of web attacks: client-side attacks and server-side attacks. Let’s start with the first one.

Client-side attacks focus on the user rather than the server. These attacks take advantage of weaknesses in user behavior or the user’s device. They often exploit vulnerabilities in web browsers or trick people into performing unsafe actions, things like clicking on a malicious link, downloading something suspicious, or entering credentials on a fake site.

A simple way to understand this: imagine visiting your favorite online store. You click on a product image, and everything looks normal, but behind the scenes, an attacker has hidden a tiny invisible window inside the page. That window secretly loads a malicious site that steals your session cookies (basically, the tiny files that keep you logged in). You wouldn’t notice a thing, but the attacker now has access to your account.

The demand for more dynamic, feature-rich web applications has made this problem worse. With websites relying on multiple third-party plugins and integrations, the attack surface keeps expanding, giving attackers more opportunities to exploit weak spots in browsers and scripts.

In short, client-side attacks target you directly – your device, your browser, or your actions, instead of attacking the server itself. They might abuse outdated software on your system or simply rely on social engineering to trick you into opening the door yourself.

Why Client-Side Attacks Are Hard to Detect

When a client-side attack happens, everything unfolds inside the user’s browser or device, not on the server, and not over the network in any suspicious way.

Now, when analysts investigate anomalies or signs of compromise, they usually rely on things like server logs, firewall logs, or packet captures. These are great for identifying malicious activity that travels through the network or targets the server. But they tell you nothing about what’s happening locally inside a user’s browser. And that’s where client-side attacks live, in the blind spot.

If we look at this from a Security Operations Center (SOC) perspective, their monitoring tools are designed to track network traffic and server-side logs; things like HTTP requests, login attempts, and data transfers between clients and servers. But in attacks like Cross-Site Scripting (XSS) or Clickjacking(which we will be discussing here briefly), the malicious activity starts after the webpage has already been delivered to the user.

Once the page loads, the browser executes everything locally. Unless the malicious script sends something unusual back to the server, there’s nothing in the logs that looks out of place. Even if malicious JavaScript is running, it might just make small, normal-looking requests, nothing large enough or strange enough to raise a red flag. To the SOC, it all appears as regular web traffic: no spikes in data, no weird IPs, no obvious alerts.

Another challenge is endpoint visibility. SOC teams typically don’t have direct access to what’s happening inside each user’s browser or device. Without tools like Endpoint Detection and Response (EDR) solutions or browser-based security extensions, there’s simply no window into that environment making these attacks almost invisible.

And finally, there’s encryption. Modern websites use HTTPS to secure communication between browsers and servers. That’s great for privacy and data protection but it also means analysts can’t easily inspect the traffic content to spot injected scripts or malicious payloads hidden within that encrypted flow.

In short, client-side attacks slip under the radar because they operate where traditional SOC tools can’t see inside the user’s browser.

Common Client-Side Attacks

Now, let’s briefly go over some of the common attacks you’ll come across — Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Clickjacking. We won’t go too deep since that’s outside the scope of this walkthrough, but a quick overview will help us understand what’s happening behind the scenes.

1. Cross-Site Scripting (XSS)

XSS happens when a website allows users to add content like comments, messages, or form inputs without properly filtering or escaping the input. This gives attackers a way to inject malicious JavaScript code into web pages that other users view.

Imagine a blog’s comment section that shows whatever you type directly on the page. If it doesn’t sanitize user input, an attacker could post something as simple as:

<script>alert('You have been hacked');</script>

When someone visits that page, the script runs inside their browser and not the attacker’s. In this harmless example, you’d just see a pop-up. But in a real attack, that script could do far worse, such as steal your cookies or session tokens (which keep you logged in), log your keystrokes, redirect you to phishing sites, or alter the page content entirely.

This kind of attack also highlights why it’s tough for SOC teams to detect it. Since it happens after the webpage is already delivered to the user, it runs locally in the browser, out of the SOC’s line of sight.

There are a few types of XSS attacks worth knowing:

• Stored XSS: The malicious code is permanently stored on the website (like in a database or comment section).
• Reflected XSS: The payload is part of a URL or request and runs as soon as the user clicks the link.
• DOM-based XSS: The attacker manipulates the page directly through the Document Object Model (DOM) on the client side.

That’s a quick overview — we’ll explore these in more detail in a later post.

2. Cross-Site Request Forgery (CSRF)

If XSS targets the browser’s trust in a website, CSRF targets the website’s trust in a browser.

In simple terms, CSRF tricks an authenticated user’s browser into performing actions they didn’t intend to.

Let’s take an example: you’re logged into your bank account in one tab, and in another, you visit a malicious website. That site contains hidden code that silently sends a request to your bank. Since your browser is already logged in, it automatically includes your cookies (the ones that keep your session active). The bank’s server sees this as a valid request coming from you and executes it.

In short, CSRF makes your browser do something bad on your behalf, without your consent and often without you ever realizing it.

3. Clickjacking

Clickjacking (short for click hijacking) is all about visual deception. The attacker tricks you into clicking something different from what you think you’re clicking.

You might have seen those shady sites where multiple “Download” buttons appear and half of them fake. That confusion is the basic idea behind clickjacking.

A more technical example: an attacker embeds a legitimate site (like your social media profile) inside an invisible frame using an <iframe> tag. They then place fake buttons or images on top of that frame. So when you think you’re clicking “Play” or “Like,” you’re actually clicking something hidden maybe approving a payment, liking a malicious post, or changing your account settings.

In short, clickjacking manipulates what you see and what you click, making you interact with an attacker-controlled layer instead of the real site underneath.

These are just brief overviews of three common web attacks we’ll be discussing later in more detail. For now, the goal is to understand how each of them operates and why they’re so challenging to detect from a SOC’s perspective.

Server-side attacks

Server-side attacks target the systems that power a website: the web server, the application code, backend services, and the database. Unlike client-side attacks, which trick users, server-side attacks go after the application itself – its logic, configuration, or the way it handles input. If an online shop mishandles input from any of its forms, login boxes, search fields, file uploads, order lookups. An attacker can use that weakness to access data, break functionality, or take control of the server.

Below are some common server-side attack types:

SQL Injection (SQLi)

When untrusted user input is concatenated directly into SQL queries, an attacker can alter the query’s logic to read, modify, or delete data.
Simple example: an app does:

SELECT * FROM products WHERE name = ' + user_input + ';

If user_input becomes ‘ OR ‘1’=’1, the query may return every row.
Detection clues: unusual query errors, slow queries, logs containing SQL syntax like OR 1=1 or UNION SELECT, large or unexpected result sets, repeated attempts from a single IP.

Server-Side Request Forgery (SSRF)

If the app fetches URLs based on user input, an attacker can force the server to request internal resources the attacker can’t normally reach (internal APIs, cloud metadata, admin endpoints).
Simple example: a URL preview feature fetches a user-supplied address. An attacker submits http://169.254.169.254/latest/meta-data/ to read cloud instance metadata.
Detection clues: outbound requests to internal IP ranges or odd endpoints, unexpected internal API calls after user actions.

Remote Code Execution (RCE)

When attacker-controlled input is executed as code on the server, the attacker can run arbitrary commands and gain control.

Detection clues: unexpected processes or commands, new binaries, suspicious subprocess activity.

Directory traversal and file inclusion

If file paths are built from user input without sanitization, attackers can traverse directories (../) to read sensitive files or force inclusion of malicious files.
Simple example: file=reports/2024.pdf becomes file=../../etc/passwd if not sanitized.
Detection clues: requests with ../ or encoded traversal, errors about missing files, unexpected file reads.

Insecure deserialization

Deserialization rebuilds objects from serialized data. If a server deserializes untrusted data using unsafe methods (like Python pickle or Java object streams), an attacker can craft payloads that execute code or change program flow.
Simple explanation: serialization packs an object to send or store. deserialization unpacks it. some formats can include executable behavior.
Detection clues: exceptions during deserialization, odd object types in logs, suspicious processes started after deserialization.

Authentication and authorization flaws

Bugs in login logic, session handling, or permission checks can let attackers impersonate users, escalate privileges, or access restricted resources.
Common signs: access attempts to admin endpoints from normal accounts, sessions used across many IPs, inconsistent permission checks.
Mitigations: centralize and enforce authorization, strong session management, per-request identity validation, and test for IDOR and privilege escalation scenarios.

Brute Force Attacks

A brute force attack is when an attacker tries to gain access by repeatedly guessing usernames, passwords, or tokens. While the attack is launched from client machines, it targets the server directly. If passwords are weak or reused, the attacker can eventually break in. Signs include lots of failed login attempts, unusual login patterns, or spikes in authentication errors.

One advantage for defenders when dealing with server-side attacks is that they leave a trail of evidence, if you know where to look. Every web request sent to an application is processed by the server and is recorded in logs or other monitoring systems. These requests also travel across the network, meaning network traffic can reveal suspicious behavior.

Using access logs to spot web attacks

Logs are one of the best pieces of evidence defenders have. Every request sent to a web server usually leaves a trace in access and error logs. By scanning those entries, you can pick up on patterns that point to scanning, exploitation attempts, or other malicious activity. Below are the basics and a short real‑world workflow to help you understand how logs are used to detect attacks.

What an access log entry tells you

Not every server uses the exact same format, but most access logs include similar fields. Any of them can look normal or suspicious depending on context:

• Client IP address — useful for spotting known bad actors or requests from unusual geographies.
• Timestamp and requested page — repeated requests in a short time or activity at odd hours can be a red flag.
• Status code — lots of 404 responses may mean the attacker is scanning for hidden pages.
• Response size — responses that are much larger or much smaller than normal can indicate data exfiltration or probing.
• Referrer — a referrer that doesn’t match normal site navigation can indicate a redirected or injected request.
• User-Agent — this can reveal old browsers or automated tools like sqlmap or wpscan.

Example attack sequence you might see in logs

In many lab examples you’ll see a condensed attack chain that looks like this:

1. Directory fuzzing — the attacker probes many directories to find interesting pages. Successful hits return 200 responses.
2. Brute force on a login form — repeated POST requests to login.php in quick succession. A final 302 response signals a successful login, followed by a redirect to /account.
3. SQL injection attempts — after gaining access the attacker tries payloads such as ' OR '1'='1 or 1' OR 'a'='a on a search form. If the app builds SQL queries unsafely, those payloads can dump data.

Note: in some lab setups the query string is logged, so the full SQLi payload is visible in the access log. In real life this depends on server configuration.

Important limitations of access logs

Access logs are helpful but they are not the whole story. For example:

• POST bodies are usually not logged. A login request might appear as:

10.10.10.100 [12/Aug/2025:14:32:10] “POST /login HTTP/1.1” 200 532 “/home.html” “Mozilla/5.0”

• This shows the request happened but not the submitted credentials.
• GET requests may or may not include query strings. Some log formats capture them, some don’t.
• Logs reflect configuration. What you see depends on your web server and how logging was set up. You may need additional logging to capture the data you care about.

How real-life log analysis actually happens

Detecting attacks in the lab is tidy. Real life is noisy. Here’s how analysts typically work through it.

1. Centralize logs first

Logs from web servers, application servers, load balancers, firewalls, and endpoints are collected into a central platform (SIEM or log store). This makes searching, correlating, and alerting possible.

2. Baseline normal behavior

Analysts build a picture of normal traffic: typical user agents, common referrers, response sizes, and request rates. Baselines help turn vague suspicion into concrete alerts.

3. Use automated detection and rules

Rule-based detections flag obvious patterns: repeated 401/403/404 responses, many failed logins, requests containing SQL keywords, or calls to internal IP ranges. Machine learning and statistical models can also surface anomalies that rules miss.

4. Triage alerts

Not every alert is an attack. Analysts triage by looking at context: is the source IP known, is the volume unusual, are there related events across other systems? A triage step separates noise from real incidents.

5. Pivot and investigate

From a suspicious log entry, analysts pivot to other data:

• Check web server error logs for stack traces or exceptions.
• Inspect WAF logs for blocked patterns.
• Pull network captures if needed to see request bodies or payloads.
• Query application logs to link session IDs or user actions.
• Look at endpoint telemetry or EDR for process activity if a server may be compromised.

6. Hunt proactively

Beyond alerts, teams run hunts for subtle indicators: rare user agents, small outbound data transfers, requests to unusual internal endpoints, or signs of credential stuffing across multiple accounts.

7. Respond and harden

If an incident is confirmed, teams block malicious IPs, rotate credentials, patch vulnerabilities, and tune logging and detection rules to prevent the same attack making it past defenses again.

To help you with identifying the request responses, here are some common HTTP Status Codes:

1xx – Informational

• Rarely logged for web browsing. Mostly internal protocol stuff. Usually not relevant for attack detection.

2xx – Success

• 200 OK – The request succeeded. Could be normal traffic, but a high number of 200s in automated sequences (like directory fuzzing) can indicate an attacker is probing pages.
• 201 Created / 204 No Content – Usually for API endpoints; can indicate successful creation or update of resources.

3xx – Redirection

• 301 Moved Permanently / 302 Found – The page redirected. Attackers often use these when login or sensitive pages redirect after success/failure. Unusual patterns can hint at brute force attempts.
• 304 Not Modified – Browser cached content; usually benign.

4xx – Client Errors

• 400 Bad Request – Malformed request. Could happen in attacks like SQLi with malformed payloads.
• 401 Unauthorized – User tried accessing a protected page without valid authentication. Repeated attempts could indicate brute force.
• 403 Forbidden – Access denied. Repeated hits may signal an attacker probing for restricted pages.
• 404 Not Found – Page doesn’t exist. A common sign of directory fuzzing or attackers scanning for hidden pages.
• 408 Request Timeout – Slow requests; occasionally used in DoS attempts.

5xx – Server Errors

502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout – Server issues, often load-related, but repeated failures after unusual requests may hint at attacks.

500 Internal Server Error – Something broke on the server. Could be exploited by attackers if they send unexpected input (e.g., malformed SQL causing a crash).

Quick security insights:

• 200 + unusual sequence → attacker may be accessing valid pages in order.
• 404 spikes → scanning/fuzzing.
• 403/401 spikes → brute force or access attempts.
• 500/502 spikes → malformed input triggering errors, potential exploitation.

While solving the TryHackMe rooms, I noticed that there were questions related to decoding a given payload, so here are some common decoding types and identifiers you can use to decode them, probably via CyberChef.

URL / percent‑encoding

• Look for lots of % followed by two hex digits (e.g. %20, %3D) and + for spaces.

HTML entities

• Look for &…; patterns like <, &, ', or '.

Base64

• Only letters/numbers plus + / and maybe = padding; length usually a multiple of 4.

Hex

• Long strings of 0–9a–f (even length) or 0x prefix; often looks like 4d5a....

Unicode / escape sequences

• \uXXXX, \xNN, or \\u style sequences (common in JS/Python escaped strings).

Data URI / inline binary

• Starts with data: and often contains ;base64, followed by base64-like payload.

Percent / double encoding

• Repeated % sequences like %25 (which decodes to %) — a hint it’s been encoded more than once.

Network traffic analysis — seeing the attack behind the logs

Network captures let you look under the hood. While server logs record that a request happened, packet captures show what was actually exchanged between client and server: full HTTP headers, POST bodies, cookies, uploaded files. That extra detail makes captures invaluable for understanding exactly how an attack played out.

What to expect and the limitations

• More verbose than logs: you can see request/response bodies (unlike many access logs), so you can recover usernames, passwords, SQL payloads, file uploads, and returned data.
• Encryption gets in the way: HTTPS and SSH encrypt payloads, so without the keys (or a proxy / TLS termination) you’ll only see metadata like IPs, ports, and TLS handshakes. For this task we focus on plain HTTP so you can actually read the contents in the capture.
• Be careful with sensitive data: captures often contain secrets. Treat them like evidence.

Replaying the attack in a packet capture (what analysts look for)

When you open a capture in Wireshark (or another tool) you’re often reconciling the same sequence you saw in logs but in richer detail. Typical workflow:

1. Filter to reduce noise
   Narrow to the destination IP or service you care about (e.g. ip.dst == 10.10.20.200) and useful protocol filters (http, tcp.port == 80). You can also filter by user agent: http.user_agent contains "sqlmap" or by request method http.request.method == "POST".
2. Spot the sequence
   • Directory fuzzing: many GETs returning 200 for valid finds.
   • Brute force: repeated POSTs to /login.php, often very close in time.
   • SQL injection: suspicious query strings or POST bodies containing payloads like ' OR '1'='1.
3. Inspect packet details for evidence
   • For brute force you can open the POST packet and read the body. If the traffic is HTTP you’ll see the submitted username and password values.
   • For SQLi you can inspect the request to /search or /passreset and clearly see the injected payload (' OR '1'='1). If the server responded with DB output, the returned HTTP body may contain dumped rows (first name, surname, etc.). Wireshark can even parse some database protocols (MySQL) so you may see query and result fields there too.

Why captures matter for investigations

• Proof and context: logs tell you an event occurred; captures show the exact payload and returned data that is crucial for confirming an exploit and understanding impact.
• Pivoting: with a captured credential or session token you can trace other requests in the capture to see post-exploitation activity.
• Attribution & indicators: captures reveal source IPs, timing, tooling (user agents, request patterns), and any command strings used by attackers.

Practical tips

• When analysing captures, start with broad filters and then narrow to suspicious IPs, endpoints, or times.
• Use http.request.method == "POST" and http filters to find form submissions.
• Search for suspicious keywords in packet bodies: OR '1'='1, UNION SELECT, password=, passwd, Content-Disposition (file uploads).
• Remember TLS will hide payloads; if you need to inspect HTTPS in a lab, use a controlled TLS proxy or capture at the server after TLS termination.
• Keep captures secure and delete or redact sensitive data when possible.

Web Application Firewalls

When we talk about defending web applications, few tools are as vital as Web Application Firewalls (WAFs). While intrusion detection and log analysis help us identify attacks after they occur, a WAF steps in before the malicious request ever reaches the server. Think of it as a security checkpoint inspecting every request, filtering dangerous ones, and letting only the safe traffic through.

Unlike traditional firewalls that focus on IPs and ports, WAFs understand application-level behavior. They can inspect full HTTP requests and even decrypt TLS traffic to spot and block threats hidden inside encrypted sessions much like Wireshark, but in real time.

How WAF Rules Work

WAFs operate based on rules that are either predefined or custom instructions that decide whether to allow, block, or challenge a request. Here are a few common categories:

Rule Type	Description	Example Use Case
Block common attack patterns	Blocks known malicious payloads, keywords, or indicators	Block requests with sqlmap user agents or ' OR '1'='1 SQL payloads
Deny known malicious sources	Uses IP reputation, geo-blocking, or threat intelligence	Block IPs from known botnet campaigns
Custom-built rules	Tailored to your application’s unique behavior	Allow only GET/POST requests to /login
Rate-limiting & abuse prevention	Limits request frequency to prevent brute-force or spam	Limit login attempts to 5 per minute per IP

Example: Blocking SQLMap Scans

Let’s say you notice repeated GET requests to /changeusername with a User-Agent string like sqlmap/1.9. That’s an automated tool designed to test for SQL injection vulnerabilities. After reviewing traffic, you confirm that the requests include SQLi payloads.

A simple WAF rule could block such requests automatically:

If User-Agent contains "sqlmap"
Then BLOCK

Modern WAFs handle this sort of detection natively, but custom rules like this give administrators flexibility to protect against application-specific abuse patterns without interrupting normal traffic.

Challenge–Response Mechanisms

Blocking isn’t always the best move. Some WAFs use challenge-response techniques like CAPTCHAs to distinguish between humans and bots. This is particularly helpful when there’s a risk of false positives, for instance, when the same rule might block legitimate users.

Given that nearly 37% of global web traffic is generated by bots, being able to challenge rather than block outright can make a huge difference in balancing security and user experience.

Threat Intelligence and Ongoing Protection

Modern WAF solutions go beyond static rule sets. They continuously integrate threat intelligence feeds, drawing from global data on malicious IPs, User-Agents, VPNs, and botnets. Many also include built-in rule sets aligned with the OWASP Top 10 to protect against the most common web application vulnerabilities, like SQLi, XSS, and insecure deserialization.

Cloudflare, for example, maintains curated lists of high-risk IPs and user agents, constantly updated as new threats emerge — from botnets and anonymizers to malware command-and-control servers. This global visibility allows WAFs to respond to new exploits in near real time, often before individual administrators even know they exist.