Detecting Attacks on Data and Applications
Prevention isn't perfect — so you need to detect. Step into the security operations center and learn to spot tampered files and application attacks in the logs.
Welcome to the AgriNova Security Operations Center (SOC). Even with strong defenses, attacks slip through — so analysts watch for the traces attackers leave behind. Your job today: verify whether files were tampered with, read application logs for indicators of compromise (IoCs), and report what you find.
Detection is the practice of recognizing that an attack is happening or has happened, using evidence like file hashes, application logs, and monitoring tools. Two big skills here: verify file integrity with a hash, and analyze logs to identify and report indicators of an application attack.
Verify Integrity
Compare a file's hash to a known-good value — a mismatch means the file was altered.
Read the Logs
Hunt application logs for indicators of compromise — suspicious input, errors, and odd access.
Report Clearly
Turn evidence into an incident report the team can act on — the heart of Detect Attacks.
- 1Explain how to detect attacks on data.
- 2Determine controls for detecting attacks against applications or data.
- 3Evaluate the impact of a detection method.
- 4Identify whether a file has been altered by verifying its hash.
- 5Apply detection techniques to identify and report indicators of application attacks by analyzing log files.
AgriNova's web dashboard had a strange night: the orders page threw errors, a config file's timestamp changed, and the access logs show repeated odd requests from one address. You'll verify file hashes to find what was altered, analyze the application log for indicators of compromise, decide which detection controls to add, and write the incident report — all on a safe, fictional system.
Big Idea
You can't stop every attack, but you can detect it fast. Detection turns invisible intrusions into visible evidence — a changed hash, a suspicious log entry — and turns that evidence into a report that drives a response. Faster detection means smaller impact.
You'll verify file integrity with hashes, identify indicators of compromise in application logs, choose detection controls (including a WAF conceptually), evaluate the impact of a detection method, and report an application incident — the AP Detect Attacks skill.
Hashes, Logs, and Indicators of Compromise
How file integrity checks and log analysis reveal attacks on data and applications.
Detection relies on comparing what is to what should be:
- Hash verification / file integrity: a file's hash is a fixed-length fingerprint. Re-hash the file and compare to the known-good hash — if they differ, the file was altered.
- Application logs: records of requests, logins, and errors. Patterns in them reveal attacks.
- Indicators of compromise (IoCs): evidence that an attack occurred — suspicious input patterns, repeated failed logins, unexpected file changes, traffic from unusual addresses.
- Detection controls: tools that surface IoCs — integrity monitoring, log analysis/SIEM, and a web application firewall (WAF) that inspects requests for malicious patterns.
Hash Verification Lab
A known-good hash was recorded for the config file. Edit the file contents and verify — does the hash still match?
Terms for MCQ and Detection Analysis
Definitions you'll need for multiple choice and free-response answers.
| Term | Definition | SOC Example |
|---|---|---|
| Detection | Recognizing that an attack is occurring or has occurred. | Spotting odd requests in logs. |
| Hash verification | Comparing a file's current hash to a known-good value. | Checking the config file. |
| File integrity | Assurance that a file hasn't been altered. | Hash still matches = intact. |
| Application log | A record of requests, logins, and errors in an app. | Dashboard access log. |
| Indicator of compromise (IoC) | Evidence suggesting an attack happened. | Repeated suspicious input. |
| Suspicious input pattern | Input shaped to abuse an app (e.g., odd characters/commands). | Strange query strings in logs. |
| Web application firewall (WAF) | A control that inspects web requests and blocks/logs malicious ones. | Flags injection-style requests. |
| SIEM / log analysis | Tools that collect and analyze logs to surface IoCs. | Alerts on anomalies. |
| Detection method impact | How well a method detects attacks vs its cost/false alarms. | Coverage vs noise trade-off. |
| Incident report | A clear write-up of what was detected and the evidence. | Sent to the response team. |
| Indicator | What it may signal |
|---|---|
| File hash changed | Unauthorized file modification/tampering. |
| Suspicious input in requests | Attempted injection-style application attack. |
| Many errors / 500s in a row | App being probed or abused. |
| Repeated requests from one address | Automated scanning or brute force. |
| Access at unusual times | Possible unauthorized use. |
What the Exam Wants You to Explain
Skill in focus: Detect Attacks — find indicators, choose detection controls, and report them.
For detection, AP expects you to: (1) identify the indicator (e.g., a changed hash or suspicious log entry), (2) name the detection control that surfaces it (integrity check, log analysis, WAF), and (3) evaluate the method's impact — what it catches, what it misses, and its cost/false-alarm trade-off — then report it.
- Confusing detection (finding attacks) with prevention (stopping them).
- Thinking a matching hash proves a file is "safe" — it proves it's unchanged from the known-good version.
- Assuming a WAF replaces logging — you still need logs/IoCs to investigate.
- Ignoring detection impact: more alerts can mean more false positives, not better security.
If a stem says "a config file's contents may have been changed," the detection method is hash verification. If it shows "repeated odd requests in the access log," that's an indicator of compromise found by log analysis — report it as a suspected application attack.
02:14 GET /orders?id=42 — 200 OK (normal)
02:15 GET /orders?id=' OR '1'='1 —
suspicious input02:15 GET /orders?id=99999 — 500 error (x12)
02:16 src=198.51.100.7 —
120 requests/min (automated)
Read it like AP wants: the odd id=' OR ... is a suspicious input pattern (injection-style IoC); the burst of 500 errors and 120 req/min from one source are IoCs of automated probing. Detection control: log analysis (plus a WAF to flag/block such requests). Action: report the indicators.
Lab: Analyze the Application Log for IoCs
The flagship lab. Read a fictional access log, flag the indicators of compromise, then read the AP-style reasoning.
Log analysis is the core of application attack detection. Click each line you believe is an indicator of compromise. Normal lines should be left alone; suspicious ones flagged. Then check your work.
File Alteration Detector
Each file has a known-good hash and a current hash. Click "Check All" to see which files were altered.
Application Log IoC Analyzer
Click the log lines that are indicators of compromise. Then check your analysis.
Fictional dashboard access log — click suspicious lines to flag them.
Prompt: "The dashboard logs show unusual entries. Identify the indicators of compromise and explain how you'd detect and report this application attack."
Model answer: The log contains a suspicious input pattern (id=' OR '1'='1) and a burst of 500 errors plus 120 requests/min from one address — all indicators of compromise consistent with an automated injection-style probe. I detected them through log analysis; a WAF would also flag/block such requests.
Report & impact: I'd document the timestamps, source address, and offending requests in an incident report rated by severity, and verify affected files with hash checks. Evaluating the method: log analysis catches application-layer IoCs well but can produce false positives, so tuning matters — that's the detection method's impact trade-off.
Misconceptions That Cost AP Points
Recognize the wrong answer and you'll avoid writing it.
× "Detection and prevention are the same."
Prevention tries to stop attacks; detection finds them when they happen anyway. AP grades them separately.
AP trap: "detect" asks you to find/report, not block.
× "A matching hash means the file is safe."
A match means the file is unchanged from the known-good version — it doesn't prove the original was safe.
AP trap: hash verifies integrity, not goodness.
× "More alerts always means better detection."
Too many alerts cause false positives and alert fatigue. Evaluate a method's impact: coverage vs noise.
AP trap: weigh detection impact, not just quantity.
× "A WAF removes the need for logs."
A WAF helps detect/block bad requests, but logs and IoC analysis are still needed to investigate and report.
AP trap: detection uses layered controls together.
× "If logs look normal, nothing happened."
Attackers may avoid obvious traces. Combine log analysis with integrity checks — one method alone has blind spots.
AP trap: "no alert" isn't proof of safety.
× "Detecting is enough; no need to report."
An undocumented finding rarely gets fixed. Reporting indicators clearly is part of the detect-attacks skill.
AP trap: include the incident report in your answer.
Detection Reference + Practice Tools
A quick-reference table plus three hands-on tools: a control matcher, a WAF/monitoring decision lab, and an incident report builder.
| Control | What it detects | Impact / trade-off |
|---|---|---|
| Hash / integrity monitoring | Altered files | Strong for tampering; needs known-good baseline. |
| Application log analysis | Suspicious requests, errors, IoCs | Broad coverage; can have false positives. |
| Web application firewall (WAF) | Malicious request patterns | Flags/blocks attacks; needs tuning, not foolproof. |
| SIEM / alerting | Correlated anomalies across logs | Powerful; costly and noisy if untuned. |
| Incident reporting | (Communicates findings) | Turns detection into response. |
Detection Control Matcher
Click an indicator, then click the detection control that best surfaces it. Correct pairs turn green.
Integrity / Hash check
Log analysis
WAF
Incident report
WAF / App Monitoring Decision Lab
For each fictional situation, choose the best detection decision — and weigh its impact. Instant feedback explains why.
Application Incident Report Builder
Turn your detection evidence into a clear incident report — the reporting half of Detect Attacks.
Incident Report
Complete the form and generate a report to see the formatted output here.
Mini AP Quiz + Takeaways
Five quick AP-style questions with instant feedback, then your snapshot for review.
Mini AP-Style Quiz
Choose the best answer. Explanations appear instantly; your score totals at the end.
- 1Hash verification detects file tampering: a current hash that differs from the known-good hash means the file was altered.
- 2Application logs reveal indicators of compromise — suspicious input, error bursts, and odd request rates.
- 3Detection controls include integrity monitoring, log/SIEM analysis, and a WAF; use them in layers.
- 4Evaluate a method's impact: coverage vs cost vs false positives — more alerts isn't always better.
- 5Detection ends in an incident report that drives the response — evidence plus clear communication.
For "detect attacks," name the indicator, the detection control that finds it, the method's impact (what it catches/misses), and the report you'd file. Verify file integrity with a hash comparison.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.