Detecting Attacks on Devices
The device is the last line of defense — and its logs are the record of everything that happened. This topic is about reading that record to catch an attacker who slipped past everything else.
Devices log nearly everything: login attempts, system processes, configuration changes, file activity, and user actions. When something looks wrong, those logs let an analyst reconstruct what happened. The clues are indicators of compromise (IoCs) — evidence that an adversary has gotten in.
You'll learn to read authentication, event, and system logs, classify the IoCs you find, choose detection tools that fit a device's limited resources, and — the headline skill — spot the signatures of password attacks in the auth log.
Read the Logs
Authentication, event, and system logs record the activity that reveals an attack after the fact.
4.4.A · LogsSpot the IoCs
Host-, file-, and behavior-based indicators each point to a different kind of compromise.
4.4.A · IoCsTune Device Detection
Devices have limited resources — the right method balances performance, cost, and protection.
4.4.B/C · MethodsA workstation at the office has been behaving strangely. You've pulled its logs — auth, event, and system — into the investigation console. Your task: read the evidence, classify the indicators of compromise, identify any password attacks, and document what you find.
AP Learning Objectives
- 4.4.AExplain how to detect attacks against devices.
- 4.4.BDetermine controls for detecting attacks against a device.
- 4.4.CEvaluate the impact of a device detection method.
- 4.4.DApply detection techniques to identify indicators of password attacks by analyzing log files.
By the time an attack reaches a device, the adversary has already bypassed physical and network defenses. The device's logs are often the only remaining evidence — and catching the attack here can stop real damage to sensitive data and critical services.
What you'll be able to do: classify host/file/behavior IoCs, match detection controls to device constraints, read an authentication timeline for anomalies, analyze device logs to identify attacks, evaluate detection-method impact, and build an analyst incident report.
Logs, Indicators & Device Constraints
What devices record, the three families of indicators, and why detection on a device is a balancing act.
Computing systems log system processes and settings, login attempts, file activity, and user actions. After an incident, these logs reconstruct what happened. An IoC is evidence that an adversary has compromised a device. They come in three families: host-based (unusual files, unexpected processes/services, unauthorized config changes — found in logs and config files), file-based (a file whose hash matches known malware, or a path/name tied to malware — found by analyzing files), and behavior-based (failed logins, unusual times/locations, privilege-escalation attempts — found in auth and access logs).
Detecting attacks on a device is constrained by the device itself. Detection tools consume memory and CPU; anomaly-based tools use more than signature-based ones, so signature-based is the better fit for low-power and embedded devices. For broad coverage, organizations may buy an endpoint detection and response (EDR) service for centralized, unified monitoring.
Diagram · Device detection pipeline
Diagram · IoC evidence chain
IoC Detector
Lab · ClassifySelect each indicator of compromise, then drop it into its family.
Host-based
Logs & config files
File-based
Analyzing files
Behavior-based
Auth & access logs
Concept Check
30 secWhy is signature-based detection often the better choice to run on a low-power device?
Indicators, Attacks & Controls
The IoC families, the password-attack signatures, and the detection controls to choose from.
| Family | Found by / examples |
|---|---|
| Host-based | Logs & config files — unusual files, unexpected processes/services, unauthorized config changes or software installs. |
| File-based | Analyzing files — hash matches known malware, malware-associated file names or paths. |
| Behavior-based | Auth & access logs — failed logins, unusual login times/locations, privilege-escalation or sensitive-data access attempts. |
| Attack | What it looks like in the log |
|---|---|
| Online password attack | A single user account attempting many wrong passwords. |
| Password spraying | Many users attempting logins within seconds of each other from one IP or unusual IPs. |
| Credential stuffing | A series of default user:password combinations tried in quick succession, often from one IP. |
| Compromised credentials | An authorized user logging in from an unexpected location/IP or at an unusual time. |
| Offline password attack | Cannot be detected — it happens on the adversary's own computer. |
Detection Control Matcher
Lab · 5 casesFor each device situation, choose the detection control that fits best.
What the Exam Rewards
This topic is Detect Attacks — skills 3.B (determine detection strategies) and 3.D (detect & classify attacks from digital evidence, with and without AI).
Know the password-attack signatures cold. One user, many failures = online attack. Many users, one IP, seconds apart = spraying. Default credential pairs in quick succession = credential stuffing.
Remember the limits. Offline password attacks can't be detected at all — they run on the adversary's machine, leaving nothing in your logs.
Common MCQ traps
"Offline password attacks show up in the auth log."
They can't be detected — the cracking happens on the adversary's own computer.
"Anomaly detection is always best for devices."
It's resource-heavy; signature-based fits low-power devices, and many embedded devices can't run any tool.
"Signature-based detection is hard to evade."
It has low false positives but is easier for adversaries to bypass than anomaly-based.
Analyst note: a known user suddenly logs in successfully from a foreign IP at 3 AM. No failed attempts, no malware alert — just an authorized account behaving abnormally. That unusual time and location is a behavior-based IoC pointing to compromised credentials, and it warrants a forced password reset.
Authentication Anomaly Timeline
Lab · 5 patternsRead the authentication-log excerpt, then identify which password attack (if any) the pattern indicates.
Analyze the Device Logs
The core skill: read each log entry off the investigation console and classify what it reveals.
Device Log Analyzer
Lab · Analyze (3.D)Each entry comes off the workstation under investigation. Read the evidence and identify what it indicates.
Misconceptions That Cost Points
Each is a planted wrong answer. Learn to see the trap.
"Spraying and brute force look the same in the log."
Brute force is one user, many passwords; spraying is many users from one IP within seconds.
"A successful login is always safe."
A success from an unusual time or location can mean compromised credentials — investigate it.
"All IoCs come from the auth log."
File-based IoCs come from files (malware hashes/paths); host-based from config and system logs.
"Run the heaviest detection tool on every device."
Resource-intensive tools degrade performance; match the method to the device's capabilities.
"If a password database is stolen, only weak passwords are at risk."
If a user:password hash database is compromised, treat all passwords as insecure and force resets.
"Device-level detection is redundant if the network is secured."
By the device level, earlier controls were already bypassed — catching it here can stop real damage.
Evaluate & Report
A reference on detection-method trade-offs, plus two labs: evaluate a method's impact, then write the incident report.
| Method | On a device |
|---|---|
| Signature-based | Light on resources, fast, low false positives — but can't catch new attacks and is easier to bypass. Best for low-power/embedded devices. |
| Anomaly-based | Catches novel attacks but resource-heavy; can degrade device performance and is impractical on weak hardware. |
| Hybrid | Maximum protection for sensitive/critical devices — when the device and budget can support it. |
| EDR (endpoint detection & response) | Third-party, expensive, but holistic and centralized — one platform monitoring many devices. |
Detection Method Impact Evaluator
Lab · 5 judgmentsEvaluate the impact of device detection choices. Pick the best answer for each.
Diagram · Alert-to-report workflow
Analyst Report Builder
Lab · Document (3.D)Assemble an incident report from your findings. Choose values that fit the evidence, then generate the report.
Prove the Investigation
Five AP-style questions with instant feedback, then a snapshot to lock it in.
Mini AP-Style Quiz
Lab · 5 questionsChoose one answer per question, then submit for scored feedback with explanations.
Five Takeaways
Logs hold the evidence. Auth, event, and system logs reconstruct an attack after the fact.
Three IoC families. Host (config/processes), file (malware hashes/paths), behavior (logins, privilege escalation).
Password signatures. One user/many tries = online; many users/one IP = spraying; default pairs = stuffing.
Offline can't be seen. Offline password cracking happens on the adversary's machine — no log trace.
Fit the device. Signature for low-power; hybrid for critical; EDR for centralized fleet monitoring.
Final AP exam tip: for log questions, name the specific indicator that gives the attack away — "one account, dozens of failed passwords, then a success" is an online password attack. For method questions, justify with the device's constraints: performance, cost, criticality, and ease of bypass.
One mistake to avoid: don't assume every detection method runs everywhere. On constrained devices, the lighter signature-based tool is often the only practical option — and on many embedded devices, no on-device tool fits at all.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.