Incident Response · Topic 3 of 6
Responding to Application and Email Security Incidents
Learn how a SOC responds to web application attacks such as SQL injection and XSS, and to phishing and email compromise, for the CSA 312-39 exam.
- 5 min
- Web, WAF, application and database logs show application attacks; response codes add context.
- A virtual patch at the WAF is containment; the code fix is eradication.
- SPF checks the sending server, DKIM checks the signature, DMARC checks alignment and sets policy.
What it is
An application security incident is an attack on a web or business application, such as SQL injection, cross site scripting (XSS), command injection, broken authentication or abuse of an API. An email security incident is an attack delivered by email, such as phishing, spear phishing, a malicious attachment, or business email compromise (BEC).
Both are among the most common incidents a SOC handles, and both have well known response steps.
How it works
Recognizing application attacks in logs
| Attack | What the analyst sees |
|---|---|
| SQL injection | Request strings with quote characters, UNION SELECT, OR 1=1, database errors returned with HTTP 500 |
| Cross site scripting | Request parameters containing <script> tags or encoded script |
| Directory traversal | Paths with repeated ../ aiming at files like /etc/passwd |
| Command injection | Shell separators such as a semicolon or a pipe character followed by system commands |
| Brute force on login | Many HTTP 401 responses or failed logins, then a success |
| Web shell | Requests to a new script file in an upload folder, often with HTTP 200 |
Web server access logs, WAF logs and application logs together show the request, the response code and what the application did.
Responding to an application incident
| Stage | Typical action |
|---|---|
| Contain | Block the source at the WAF, add a virtual patch rule, disable the vulnerable function or take the app offline if data is leaking |
| Evidence | Preserve web, WAF, application and database logs and a copy of any uploaded file |
| Eradicate | Fix the code (parameterized queries, input validation, output encoding), patch the framework, remove web shells |
| Recover | Rotate database and API credentials, restore altered data, retest, return to service |
| Notify | If personal data was exposed, involve legal for breach notification |
A virtual patch is a WAF rule that blocks the exploit pattern until developers fix the code. It buys time but is not the permanent fix.
Recognizing email attacks
Analysts examine the full message header and body.
| Check | What it tells you |
|---|---|
| SPF result | Whether the sending server is allowed to send for that domain |
| DKIM result | Whether the message was signed by the domain and not altered |
| DMARC result | Whether SPF or DKIM pass and align with the visible From domain, and the domain's policy |
| Received headers | The path through mail servers, read from the bottom up |
| Reply-To and Return-Path | A different address from the From line is a common phishing sign |
| Links and attachments | Lookalike domains, shortened URLs, macro documents, archives or executables |
Responding to phishing and malicious email
- Collect the original message with headers, not a forwarded copy that loses them.
- Analyze the links and attachment in a sandbox and check reputation.
- Search the mail system for every recipient of the same message.
- Remove the message from all mailboxes and block the sender, domain, URLs and file hashes.
- Find users who clicked or entered credentials, reset their passwords and revoke sessions, and check their devices.
Responding to business email compromise
BEC uses a spoofed or taken over mailbox to request payments or data. Look for new inbox rules that forward or hide mail, logins from unusual locations, and changed payment details.
Response is to reset the account password, revoke sessions, enforce multifactor authentication, remove malicious rules, alert finance, and contact the bank quickly if money was sent.
A worked example
Three users report an email from "IT Support" asking them to revalidate a mailbox. The header shows DMARC failed and the link points to a lookalike domain.
The analyst finds 120 recipients, purges the message, blocks the domain at the proxy and gateway, and sees two users entered credentials. Their passwords are reset, sessions revoked, and sign in logs checked for attacker access.
How the exam asks about this
- "A web log shows
' OR 1=1--in a login parameter followed by HTTP 200. Which attack is this?" → SQL injection. - "Which WAF technique blocks an exploit while developers fix the vulnerable code?" → A virtual patch.
- "After confirming a phishing email, what should the SOC do to protect other users?" → Find all recipients and remove the message from every mailbox, then block its indicators.
What to remember for the exam
- Web, WAF, application and database logs show application attacks; response codes add context.
- A virtual patch at the WAF is containment; the code fix is eradication.
- SPF checks the sending server, DKIM checks the signature, DMARC checks alignment and sets policy.
- Read Received headers from bottom to top to trace the true origin.
- For credential phishing, reset passwords and revoke sessions for every user who clicked and entered details.
Ask users to send the original email as an attachment, not a forward. A forward loses the original headers the analyst needs.
Common mistakes
Blocking one sender and stopping there. The same campaign often reached many mailboxes; purge it everywhere and block its links and hashes.
Treating the WAF rule as the fix. The vulnerable code is still there until developers correct it.
Forgetting credential cleanup. Resetting a password without revoking active sessions can leave the attacker logged in.
Check yourself
What does a DMARC failure tell the analyst?
The message did not pass SPF or DKIM in alignment with the visible From domain, a strong sign of spoofing.
What is the permanent fix for SQL injection?
Fixing the code, for example with parameterized queries and input validation; a WAF rule is only a stopgap.
What signs suggest business email compromise in a mailbox?
New forwarding or hiding inbox rules, logins from unusual locations and requests to change payment details.
Topic 3 of 6 in Incident Response
Test yourself on Incident Response
The full EC-Council 312-39 question bank has 700 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.