"Lab 19 — Web Application Attack Investigation"

Mission Information

Item	Details
Lab	19
Lab Name	Web Application Attack Investigation
Track	CompTIA CySA+
Difficulty	Intermediate–Advanced
Estimated Time	150–180 minutes
Primary Role	SOC Analyst / Cybersecurity Analyst
Environment	CySA+ Web Security Investigation Lab
Primary Systems	Web Server + SIEM + Analyst Workstation
Primary Data Sources	Web Access Logs, Application Logs, WAF Alerts, Zeek, Suricata, Authentication Logs, File Telemetry
Skills	Web Log Analysis, HTTP Investigation, Attack Detection, IOC Analysis, Server Investigation, Incident Scoping

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

The SOC receives several security alerts involving a public-facing web application.

The activity begins with unusual requests from an external source.

Within minutes, the environment records:

Repeated HTTP Requests
        ↓
Authentication Failures
        ↓
Suspicious URL Parameters
        ↓
Unexpected Server Errors
        ↓
New File Activity
        ↓
Outbound Network Communication

A web administrator also reports that an unexpected file appeared inside the application’s web directory.

The security team suspects that someone may have attempted to exploit the application.

You must determine:

• what source generated the activity

• which URLs were targeted

• which HTTP methods were used

• whether authentication was attacked

• whether injection patterns appeared

• whether path traversal was attempted

• whether malicious files were uploaded

• whether a web shell or similar artifact exists

• whether server-side execution occurred

• whether the attacker established outbound communication

• whether user accounts or application data were affected

• whether the application must be isolated

Mission Objective: Investigate a simulated web application attack using web logs, security alerts, server telemetry, and network evidence to determine whether exploitation succeeded and what systems, users, and data may be affected.

Mission Objectives

By completing this lab, you will be able to:

• investigate HTTP access logs

• interpret HTTP methods

• analyze status codes

• identify high-volume source activity

• investigate web authentication attacks

• identify suspicious parameters

• recognize SQL injection indicators

• recognize cross-site scripting indicators

• recognize path traversal indicators

• recognize command-injection indicators

• identify suspicious file uploads

• investigate potential web shells

• correlate web and operating-system telemetry

• review WAF and IDS alerts

• investigate outbound network activity

• enrich suspicious IPs and domains

• construct a web attack timeline

• determine whether exploitation succeeded

• determine incident scope

• recommend containment actions

1. Understand the Web Investigation Workflow

Use:

Web Alert
   ↓
Identify Source
   ↓
Analyze HTTP Requests
   ↓
Identify Targeted Application
   ↓
Review Authentication
   ↓
Analyze Parameters
   ↓
Identify Exploit Indicators
   ↓
Review Server Activity
   ↓
Investigate Files
   ↓
Review Network Connections
   ↓
Determine Impact
   ↓
Scope Incident
   ↓
Contain / Escalate

The most important question is:

Did the attacker only probe the application, or did exploitation actually succeed?

2. Start the Lab Environment

Start:

CYSA-ANALYST
10.10.10.10

CYSA-SIEM
10.10.10.40

CYSA-WEB01
10.10.10.50

Use a safe lab web application or instructor-provided web logs.

Do not attack public systems.

3. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB19/{WebLogs,ServerLogs,Network,IOCs,Screenshots,Findings,Reports}

Create:

touch ~/CySA-Lab/Investigations/LAB19/investigation-notes.md

Use:

Incident ID:
LAB19-WEB-001

4. Record the Initial Alert

Document:

Incident:
LAB19-WEB-001

Asset:
CYSA-WEB01

IP:
10.10.10.50

Application:
GHC Training Web Application

Alert Time:
<timestamp>

Detection:
Suspicious Web Request Activity

Capture:

Source IP
Destination
Requested URI
HTTP Method
Signature
Severity

5. Define the Investigation Window

If the first alert occurs at:

14:30

begin with:

14:15–15:00

Then expand backward or forward based on evidence.

6. Identify Web Log Sources

Common sources include:

Apache access.log
Apache error.log
Nginx access.log
Nginx error.log
Application Logs
Reverse Proxy Logs
WAF Logs

Determine which are available.

7. Understand Access Log Fields

A common access-log entry may contain:

Source IP
Timestamp
HTTP Method
URI
Status Code
Response Size
Referer
User-Agent

Example:

203.0.113.25 - - [26/Aug/2026:14:30:02]
"GET /login HTTP/1.1" 200 5421

8. Review Recent Web Requests

On the web server:

sudo tail -n 100 /var/log/apache2/access.log

or for Nginx:

sudo tail -n 100 /var/log/nginx/access.log

Use the path appropriate to your environment.

9. Filter by Source IP

Suppose the suspicious source is:

203.0.113.25

Search:

grep "203.0.113.25" /var/log/apache2/access.log

Record:

First Request
Last Request
Request Count
Targeted URLs
HTTP Methods
Status Codes
User-Agent

10. Count Requests from the Source

Run:

grep "203.0.113.25" /var/log/apache2/access.log | wc -l

High volume may indicate:

Scanning
Brute Force
Automation
Load Testing

Context is required.

11. Identify Top Source IPs

Run:

awk '{print $1}' /var/log/apache2/access.log |
sort |
uniq -c |
sort -nr |
head

This helps identify unusually active systems.

12. Investigate HTTP Methods

Common methods include:

GET
POST
HEAD
PUT
DELETE
OPTIONS
PATCH

Count methods used by the suspicious source.

For example:

grep "203.0.113.25" /var/log/apache2/access.log |
awk -F'"' '{print $2}' |
awk '{print $1}' |
sort |
uniq -c

13. Understand Suspicious HTTP Methods

An unexpected:

PUT
DELETE

request may deserve investigation if the application does not normally use those methods.

Do not assume malicious intent purely from the method.

14. Analyze HTTP Status Codes

Common codes:

Code	Meaning
200	Success
301 / 302	Redirect
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
500	Internal Server Error

Large sequences of:

404

may suggest discovery/scanning.

Repeated:

401
403

may indicate unauthorized access attempts.

15. Count Status Codes

Run:

grep "203.0.113.25" /var/log/apache2/access.log |
awk '{print $9}' |
sort |
uniq -c |
sort -nr

Look for unusual patterns.

16. Identify Targeted Paths

Extract requested paths:

grep "203.0.113.25" /var/log/apache2/access.log |
awk -F'"' '{print $2}' |
awk '{print $2}'

Look for:

/admin
/login
/api
/upload
/config
/.env
/backup
/phpmyadmin

depending on the application.

17. Identify Reconnaissance Behavior

Requests to many unrelated paths such as:

/phpmyadmin
/wp-login.php
/.git/
/.env
/admin/
/backup.zip

may indicate automated web reconnaissance.

This does not mean exploitation succeeded.

18. Investigate Authentication Attacks

Search requests targeting:

/login
/auth
/signin

Look for repeated POST requests.

Example pattern:

POST /login
POST /login
POST /login
POST /login

from one source.

19. Correlate Authentication Logs

If the application records authentication separately, search:

Failed Login
Successful Login
Username
Source IP
Timestamp

Determine:

Did failures eventually become a success?

20. Investigate Password Spraying Indicators

Web authentication activity such as:

Source A
   ↓
user01 — fail
user02 — fail
user03 — fail
user04 — fail

may resemble password spraying.

Compare with Lab 10 concepts.

21. Investigate Brute-Force Indicators

Another pattern:

Source A
   ↓
admin — fail
admin — fail
admin — fail
admin — success

may resemble brute force.

22. Investigate Query Parameters

Web attacks often target user-controlled parameters.

Example:

/search?q=test

or:

/product?id=10

Review suspicious requests for unusual parameter values.

23. Recognize SQL Injection Indicators

Potential indicators can include strings resembling:

'
"
OR
UNION
SELECT
--

For example:

/product?id=1'...

Do not reproduce or test exploit payloads outside the safe lab.

The analyst’s goal is to identify evidence already present in logs.

24. Search Logs for SQL-Related Indicators

Use safe text searches against the stored logs.

For example:

grep -Ei "union|select|%27|%22" /var/log/apache2/access.log

Expect false positives.

Validate manually.

25. Recognize Cross-Site Scripting Indicators

Potential XSS-related requests may contain HTML or script-like content.

Look for encoded or literal references resembling:

<script
javascript:
onerror=

Again, do not replay suspicious payloads.

26. Search for XSS Indicators

Example:

grep -Ei "script|javascript|onerror" /var/log/apache2/access.log

Inspect matches in context.

27. Recognize Path Traversal Indicators

Path traversal attempts may include sequences resembling:

../
..\
%2e%2e

The goal may be to access files outside the intended web directory.

28. Search for Traversal Indicators

Run:

grep -Ei "\.\./|%2e%2e" /var/log/apache2/access.log

Review:

Requested Path
Status Code
Response Size
Timestamp
Source IP

29. Recognize Command-Injection Indicators

Potential command-injection attempts may include shell-related syntax or commands.

Do not replay or execute any suspicious payload.

Instead, investigate:

Request
Server Response
Application Error
Subsequent OS Process Activity

Successful exploitation should create corroborating server-side evidence.

30. Correlate HTTP Requests with Server Processes

This is critical.

Suppose:

14:32:04
Suspicious HTTP Request

and:

14:32:05
Unexpected shell process spawned by web service

Together:

Web Request
     +
Server Process
     =
Potential Exploitation

31. Identify the Web Server Process

Depending on the stack, the web process may include:

apache2
httpd
nginx
php-fpm
node
java
python

Determine which account runs the service.

32. Investigate Child Processes of the Web Service

Unexpected lineage such as:

apache2
   ↓
shell / script interpreter

or:

php-fpm
   ↓
unexpected OS process

requires investigation.

Record:

Parent Process
Child Process
User
Command Line
Timestamp

33. Investigate Error Logs

Review:

sudo tail -n 100 /var/log/apache2/error.log

or:

sudo tail -n 100 /var/log/nginx/error.log

Look for:

Application Exceptions
Permission Errors
Unexpected File Access
Script Errors
Backend Errors

34. Investigate Application Logs

If the application maintains logs, review:

Authentication
Database Errors
Upload Activity
API Requests
Session Activity
Application Exceptions

Application logs often provide context not visible in access logs.

35. Investigate Suspicious File Uploads

Look for requests targeting:

/upload
/files
/images
/import

Identify:

Filename
Extension
Size
Source IP
Timestamp
User
HTTP Response

36. Review Web Directory File Activity

Identify recently created files inside the web root.

Example on Linux:

sudo find /var/www -type f -mmin -60 -ls

Adjust the path to your lab web root.

Do not execute suspicious files.

37. Investigate Unexpected Script Files

Potentially interesting extensions include:

.php
.jsp
.aspx
.py
.sh

depending on the technology stack.

An unexpected script inside an upload directory may require urgent investigation.

38. Preserve Suspicious Files

Copy suspicious files safely into:

LAB19/Evidence/

Do not open them through a browser.

Calculate:

sha256sum <suspicious-file>

Record the hash.

39. Investigate Potential Web Shell Indicators

A web shell is a server-side artifact that can provide remote command functionality.

Potential indicators include:

Unexpected server-side script
Recently created file
Small obfuscated script
Requests repeatedly targeting one unusual file
Web process spawning OS commands
Outbound network connections

Do not execute or interact with the suspected shell.

40. Search Access Logs for the Suspicious File

If the file is:

support.php

search:

grep "support.php" /var/log/apache2/access.log

Determine:

Who accessed it?
When?
How often?
Which HTTP methods?
What status codes?

41. Correlate File Access with Process Activity

Example:

14:40
GET /uploads/support.php

14:40
Web service spawns unexpected process

This combination strongly increases concern.

42. Investigate Outbound Network Connections

On the server:

sudo ss -antp

Review:

Remote IP
Remote Port
Process
State

Unexpected outbound connections from the web service require investigation.

43. Correlate with Zeek

Search:

10.10.10.50

in network telemetry.

Review:

External destinations
Ports
Protocols
Duration
Bytes
DNS
HTTP/TLS

44. Correlate with Suricata

Search for:

10.10.10.50

and the attacker’s IP.

Review:

Signature
Category
Severity
Timestamp
Source
Destination

45. Review WAF Alerts

If a Web Application Firewall is present, inspect:

Rule ID
Attack Category
URI
Parameter
Source IP
Action
Timestamp

Possible categories include:

SQL Injection
XSS
Traversal
Protocol Violation
Suspicious Upload

46. Understand WAF Alert Limitations

A WAF alert means:

Request matched security logic

not:

Server definitely compromised

You must correlate with:

HTTP Response
Application Logs
Process Activity
File Activity
Network Activity

47. Determine Whether the Attack Was Blocked

Review:

WAF Action
HTTP Status
Application Response

Example:

WAF:
Blocked

HTTP:
403

This suggests the request may not have reached the application.

But validate additional evidence.

48. Determine Whether Exploitation Succeeded

Evidence of successful exploitation may include:

HTTP Request Accepted
      +
Unexpected Server Process
      +
New Suspicious File
      +
Network Connection

The stronger the correlation, the stronger the conclusion.

49. Investigate Database Activity

If SQL injection is suspected, review database or application telemetry where available.

Look for:

Unexpected Queries
Database Errors
Unusual Account Activity
Large Data Responses
Schema Access

Do not infer database compromise solely from an SQL-injection-looking HTTP request.

50. Investigate Data Access

Ask:

Was sensitive information requested?

Were administrative APIs accessed?

Were large responses returned?

Were unusual exports generated?

This helps determine confidentiality impact.

51. Investigate Session and Account Activity

If the web application uses sessions, review:

User Account
Session ID
Login Time
Source IP
Privilege
Account Changes

Determine whether a legitimate user’s session may have been abused.

52. Investigate Privileged Application Accounts

Look for activity involving:

Administrator
Support
Service Account
API Account

Compromise of privileged application identities can increase impact.

53. Enrich the Source IP

Use the Lab 16 process.

Investigate:

ASN
Hosting Provider
Reputation
Scanning History
Malware Associations
Related Domains

Assign:

Confidence:
Low / Medium / High

54. Enrich Suspicious Domains and Hashes

If server-side activity references:

Domain
IP
Hash

enrich those indicators.

Then search your SIEM for internal matches.

55. Determine Whether Other Applications Were Targeted

Search the source IP across all relevant web logs.

Ask:

Did the same source target additional applications?

Were the same payload patterns used?

Were multiple web servers involved?

56. Search for the Suspicious File Hash Across Hosts

If a suspicious server-side artifact has a SHA-256 value, search the SIEM or endpoint telemetry.

Determine:

One Server
or
Multiple Systems

57. Build an IOC Inventory

Create:

Type	Indicator	Source	Confidence
IP	<source IP>	Access Log	High
URL	<target URI>	Access Log	Contextual
Hash	<SHA-256>	Web Server	High
File	<filename>	Web Root	High
Domain	<domain>	Network	Medium/High
User-Agent	<value>	HTTP	Contextual

58. Identify Behavioral Indicators

Static IOCs may change.

Also document behaviors:

High-volume path enumeration

Repeated login failures

Suspicious parameter manipulation

Unexpected upload

Web service spawning OS process

Outbound connection from web server

These can be valuable for detection engineering.

59. Map Observed Activity to MITRE ATT&CK

Where supported by evidence, relevant context may include:

Exploit Public-Facing Application
Valid Accounts
Web Shell
Command and Scripting Interpreter
Ingress Tool Transfer
Application Layer Protocol

Only map techniques supported by observed behavior.

60. Build the Attack Timeline

Example:

Time	Source	Activity
14:20	Web	Path enumeration
14:24	Web	Login attempts
14:30	WAF	Injection alert
14:33	Web	Suspicious POST
14:34	Server	Unexpected file created
14:35	Web	New file accessed
14:35	Process	Web process spawned child
14:36	Network	External connection
14:40	SOC	Incident escalated

Your timeline must use actual lab evidence.

61. Distinguish Reconnaissance, Attempted Exploitation, and Compromise

Use:

Reconnaissance

Attack attempts observed,
no evidence of successful exploitation

Attempted Exploitation

Exploit-like requests observed,
success unconfirmed

Confirmed Compromise

Server-side evidence confirms unauthorized execution or modification

62. Determine Incident Scope

Classify:

Affected Application
Affected Server
Affected Users
Affected Database
Other Internal Systems
External Infrastructure

Use statuses:

Confirmed Compromised
Suspected
Exposed
Unaffected
Unknown

63. Assess Confidentiality Impact

Ask:

Was sensitive application data accessed?

Were user records exposed?

Were credentials exposed?

Was database content retrieved?

Was data transmitted externally?

64. Assess Integrity Impact

Ask:

Were files created?

Were application files changed?

Was database content modified?

Were accounts created or altered?

65. Assess Availability Impact

Ask:

Did the application become unavailable?

Were services stopped?

Did the attack cause errors or crashes?

Was a denial-of-service condition created?

66. Determine Severity

Use factors such as:

Exploitation success
Asset criticality
Privileged access
Data exposure
Persistence
Lateral movement
Business disruption

Classify:

Low
Medium
High
Critical

67. Determine Immediate Containment

Potential actions include:

Block confirmed malicious source
Place WAF rule
Disable compromised account
Remove affected application from service
Isolate web server
Restrict outbound connectivity
Preserve suspicious files
Rotate exposed credentials

Follow organizational policy.

68. Preserve Evidence Before Remediation

Before:

Delete Suspicious File
Patch Server
Restart Application
Rebuild Host

preserve:

Web Logs
Application Logs
Process Evidence
File Hashes
Suspicious Files
Network Telemetry
Authentication Logs

69. Determine Root Cause

Possible conclusions:

Public Application Vulnerability

Credential Compromise

Unsafe File Upload

Application Misconfiguration

Unknown

If evidence does not support a conclusion:

Root Cause:
Undetermined

70. Create a Web Incident Summary

Use:

Incident:
LAB19-WEB-001

Asset:
CYSA-WEB01

Source:
<source IP>

Attack Type:
<classification>

Initial Activity:
<finding>

Successful Exploitation:
Confirmed / Suspected / Not Confirmed

Suspicious File:
<file>

Server-Side Execution:
Confirmed / Not Confirmed

External Communication:
<finding>

Data Exposure:
Confirmed / Suspected / Not Observed / Unknown

Scope:
<number of assets/users>

Severity:
<severity>

Containment:
<required action>

71. Mission Challenge — Web Application Attack

The SOC reports:

A public-facing application received suspicious web requests followed by unexpected server-side file and process activity. Determine whether the application was compromised.

Investigate:

1. What source IP generated the activity?

2. When did it begin?

3. How many requests were generated?

4. Which URLs were targeted?

5. Which HTTP methods were used?

6. Which status codes were returned?

7. Was reconnaissance observed?

8. Were login attempts observed?

9. Did authentication succeed?

10. Were SQL injection indicators present?

11. Were XSS indicators present?

12. Was path traversal observed?

13. Were command-injection indicators present?

14. Did the WAF generate alerts?

15. Were requests blocked?

16. Did application errors occur?

17. Was a suspicious file uploaded?

18. What is the file hash?

19. Was the suspicious file accessed?

20. Did the web service spawn unexpected processes?

21. Did the server initiate outbound connections?

22. What external infrastructure was contacted?

23. Did threat intelligence identify relevant indicators?

24. Was database activity suspicious?

25. Was sensitive data accessed?

26. Were privileged accounts affected?

27. Are other web servers affected?

28. Is exploitation confirmed?

29. What is the incident severity?

30. What containment actions are required?

72. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB19/investigation-notes.md

Use:

# LAB19 Web Application Attack Investigation

## Incident ID

LAB19-WEB-001

## Application

- Host:
- IP:
- Application:
- Investigation Window:

## Initial Alert

Document:
- source
- destination
- signature
- severity
- timestamp

## HTTP Analysis

Document:
- request count
- methods
- URIs
- parameters
- status codes
- user agents

## Reconnaissance

Document path and resource enumeration.

## Authentication

Document:
- attempts
- accounts
- failures
- successes

## Exploit Indicators

### SQL Injection

Observed / Not Observed

### XSS

Observed / Not Observed

### Path Traversal

Observed / Not Observed

### Command Injection

Observed / Not Observed

## WAF Evidence

Document:
- rule
- action
- source
- request
- timestamp

## Server Evidence

Document:
- processes
- parent-child relationships
- command lines
- application errors

## File Activity

Document:
- filename
- path
- creation time
- SHA-256
- access history

## Network Activity

Document:
- destination IPs
- domains
- ports
- Zeek
- Suricata

## Threat Intelligence

Document enrichment findings.

## Data Impact

Document:
- data access
- data modification
- possible exfiltration

## Scope

Document:
- applications
- servers
- users
- databases
- related systems

## Exploitation Status

Reconnaissance / Attempted Exploitation / Confirmed Compromise / Inconclusive

## Severity

Low / Medium / High / Critical

## Root Cause

Confirmed / Suspected / Undetermined

## Containment

Document immediate actions.

## Final Assessment

Summarize the investigation.

73. Example Analyst Findings

A simulated assessment might resemble:

Incident:
LAB19-WEB-001

Asset:
CYSA-WEB01

Initial Activity:
High-volume reconnaissance and suspicious parameter manipulation were observed from one external source.

WAF:
Multiple web-attack signatures were generated.

Application:
Unexpected server errors were observed shortly after the suspicious requests.

File Activity:
A previously unknown server-side script appeared within the web directory.

Process Activity:
The web-service process subsequently spawned unexpected child activity.

Network Activity:
The server established an outbound connection shortly afterward.

Assessment:
The combined web, filesystem, process, and network evidence is consistent with successful exploitation in the simulated laboratory.

Classification:
Confirmed Web Application Compromise

Scope:
One web server currently confirmed affected. Additional infrastructure requires IOC hunting.

Severity:
High

Containment:
Isolate or remove the affected application from service, preserve evidence, block validated malicious indicators, restrict server outbound connectivity, rotate potentially exposed credentials, and investigate the application vulnerability that enabled compromise.

74. Evidence to Capture

Capture:

01-initial-web-alert.png
02-access-log.png
03-source-ip-activity.png
04-request-count.png
05-http-methods.png
06-status-codes.png
07-targeted-paths.png
08-authentication-attacks.png
09-injection-indicators.png
10-path-traversal.png
11-waf-alert.png
12-error-log.png
13-suspicious-upload.png
14-file-hash.png
15-web-shell-access.png
16-process-lineage.png
17-network-connections.png
18-zeek-correlation.png
19-suricata-correlation.png
20-threat-intelligence.png
21-ioc-inventory.png
22-attack-timeline.png
23-incident-scope.png
24-final-assessment.png

75. Validation Checklist

• Initial web alert was preserved

• Investigation window was established

• Web log sources were identified

• Suspicious source IP was investigated

• Request volume was analyzed

• HTTP methods were analyzed

• Status codes were analyzed

• Targeted URLs were identified

• Reconnaissance behavior was investigated

• Authentication activity was analyzed

• Password attack patterns were considered

• Request parameters were investigated

• SQL injection indicators were reviewed

• XSS indicators were reviewed

• Path traversal indicators were reviewed

• Command-injection indicators were reviewed

• Server-side process telemetry was investigated

• Error logs were reviewed

• Application logs were reviewed

• Suspicious file uploads were investigated

• Recently created web files were reviewed

• Suspicious files were preserved

• SHA-256 was calculated

• Potential web-shell activity was investigated

• Suspicious file access was correlated with server activity

• Outbound network connections were investigated

• Zeek telemetry was correlated

• Suricata telemetry was correlated

• WAF alerts were analyzed

• WAF block status was determined

• Database activity was considered

• User/session activity was investigated

• Threat intelligence enrichment was performed

• Related systems were searched

• IOC inventory was created

• Behavioral indicators were documented

• ATT&CK mapping was performed where supported

• Attack timeline was built

• Reconnaissance was distinguished from compromise

• Confidentiality impact was assessed

• Integrity impact was assessed

• Availability impact was assessed

• Incident severity was assigned

• Containment requirements were documented

• Root cause was investigated

• Evidence was captured

76. Mission Review

In this mission, you learned that a web attack investigation cannot stop at:

Suspicious HTTP Request

You must determine whether the activity progressed:

Reconnaissance
      ↓
Authentication Attack
      ↓
Exploit Attempt
      ↓
Application Response
      ↓
Server-Side Execution
      ↓
File Modification
      ↓
Network Activity
      ↓
Potential Data Impact

The critical lesson is:

An exploit-looking request is only one piece of evidence. Confirmed web compromise requires correlation between web activity and server-side impact.

A strong analyst combines:

Web Logs
   +
WAF
   +
Application Logs
   +
Process Telemetry
   +
File Evidence
   +
Network Evidence
   +
Threat Intelligence
   =
Web Incident Context

Skills Developed

After completing this mission, you should be able to:

• investigate web application security alerts

• analyze web access logs

• analyze HTTP methods and status codes

• identify reconnaissance behavior

• investigate web authentication attacks

• recognize common injection indicators

• identify path traversal patterns

• investigate suspicious upload activity

• identify potential web-shell evidence

• correlate HTTP requests with server processes

• investigate outbound server connections

• analyze WAF alerts

• correlate Zeek and Suricata evidence

• enrich web-related IOCs

• assess data impact

• determine whether exploitation succeeded

• scope a web application incident

• recommend containment

• document web compromise findings

What’s Next?

Lab 20 — SOC Analyst Capstone Investigation

You have now completed focused investigations across:

Windows
Linux
Network Traffic
Zeek
Suricata
SIEM
Authentication
Phishing
Malware
Vulnerability Management
Threat Intelligence
Incident Response
Ransomware
Web Applications

In the final CySA+ lab, you will receive a multi-stage enterprise incident without being told exactly what happened.

You will need to determine:

• initial access

• affected identity

• compromised endpoint

• suspicious network activity

• malicious file activity

• persistence

• privilege use

• lateral movement

• web or application activity

• indicators of compromise

• incident scope

• attack timeline

• MITRE ATT&CK mapping

• severity

• containment priorities

• remediation

• executive summary

• technical incident report

The final workflow becomes:

Raw Alerts
   ↓
Triage
   ↓
Investigation
   ↓
Correlation
   ↓
Scope
   ↓
Evidence
   ↓
Attack Story
   ↓
Containment
   ↓
Reporting

➡️ Next: Lab 20 — SOC Analyst Capstone Investigation