AP® Cybersecurity review sheet from Aim for Five (aimforfive.com/cybersecurity/units/4/4-4)
Unit 4 · Topic 4.4
4.4 Detecting Attacks on Devices
Devices record logins, file activity and system changes, and those records reveal attacks. This topic covers the three kinds of indicators of compromise, how to choose and judge device detection tools, and how to read an authentication log to tell an online password attack, password spraying and credential stuffing apart.
Key terms
- authentication (auth) log
- host-based IoC
- file-based IoC
- behavior-based IoC
- endpoint detection and response (EDR)
Logs and indicators of compromise
Computers log system processes and settings, login attempts, file downloads and user actions. Investigators use these logs to rebuild what happened before and during an incident. An authentication log (auth log) records every attempted login. An indicator of compromise (IoC) is a clue that an adversary has already gotten into a device or network. On devices, IoCs come in three kinds:
- Host-based IoCs, found in logs and configuration settings: unusual files created or changed, unexpected processes or services, unauthorized changes to system settings, and unauthorized software installs or updates.
- File-based IoCs, usually in executable files: a file whose hash matches known malware, a file name known to be created by certain malware, or a file path linked to malicious activity.
- Behavior-based IoCs, found in auth and access logs: many failed logins, logins at unusual times or places, unauthorized attempts to reach sensitive data, and attempts to raise a user's privileges.
Choosing device detection
- Performance: detection tools use memory and processing power. Anomaly-based tools use more than signature-based ones, so signature-based suits less powerful devices. Many embedded devices can't run any detection tool at all.
- Cost: organizations need a license for every device they monitor. Some buy endpoint detection and response (EDR) from an outside vendor. It's expensive, but it covers all the organization's devices together, usually with one central alert dashboard.
- Sensitivity or criticality: devices with sensitive data or critical services are more likely targets, so they benefit from hybrid detection when it's possible.
Judging a detection method
- Speed and performance: signature-based detection is faster, especially on devices that lack the power to run anomaly tools well. Heavy tools can slow a device down.
- Phase of the attack: to act on a device, an adversary has usually already passed physical and network controls. Catching them at the device can still stop them before they reach sensitive data or disrupt services.
- False positives versus bypassing: most device tools are signature-based, with few false positives, but they're easier for adversaries to slip past.
Reading an auth log for password attacks
If a password hash database is ever stolen, assume every password in it is unsafe and force all users to reset their passwords, since an offline attack could be cracking them without leaving a trace.
| Pattern in the log | What it suggests |
|---|---|
| One username, many wrong passwords | Online password attack on that account |
| An authorized user logging in from an unexpected place or IP address, or at an unusual time | That user's password may be compromised |
| Many different usernames tried a few seconds apart, all from one IP address or from unfamiliar ones | Password spraying |
| Default username and password pairs (like admin/admin) tried in quick succession, often from one IP address | Credential stuffing |
| Nothing at all | An offline attack can't be seen, because it runs on the adversary's computer |
Worked examples
Try each one yourself first, then open the solution.
- Example 1
Spraying or stuffing?
Server logs from two devices at Fairview Manufacturing. Device A: 02:14:01 failed login, user jkim, from 203.0.113.60; 02:14:02 failed, user apatel, from 203.0.113.60; 02:14:03 failed, user mlopez, from 203.0.113.60; 02:14:04 failed, user tnguyen, from 203.0.113.60 (and so on for 40 more usernames, about one per second). Device B, a network switch: 11:30:10 failed, admin/admin, from 198.51.100.200; 11:30:11 failed, admin/password, from 198.51.100.200; 11:30:12 failed, root/root, from 198.51.100.200; 11:30:13 failed, guest/guest, from 198.51.100.200. Identify each attack and cite the evidence.
Show the solutionHide the solution
- Step 1: Device A: many different real usernames, one attempt each, seconds apart, all from 203.0.113.60. That's the spraying pattern: one IP trying (likely) one common password across many accounts. The 2 a.m. timing adds suspicion.
- Step 2: Device B: the attempts are factory-default username and password pairs (admin/admin, root/root and so on), one per second from 198.51.100.200. That's the credential stuffing pattern.
- Step 3: Recommend responses: block both IPs, enforce lockout and MFA on Device A's accounts, and change the switch's default credentials (if not already done).
Answer: Device A shows password spraying: dozens of different usernames tried about one second apart from the single IP 203.0.113.60. Device B shows credential stuffing: default pairs like admin/admin and root/root tried in quick succession from 198.51.100.200.
- Example 2
A login that succeeded
The auth log for user dchen, who works 9 to 5 from the office network 198.51.100.0/24, shows: Mon 09:03 success from 198.51.100.44. Tue 09:01 success from 198.51.100.44. Wed 03:27 success from 192.0.2.150. What does the Wednesday entry suggest, and what should happen next?
Show the solutionHide the solution
- Step 1: Compare it to the baseline: dchen normally logs in around 9 a.m. from inside the office range.
- Step 2: Wednesday's login was at 3:27 a.m. and from 192.0.2.150, outside the office range. Both the time and the address are unusual.
- Step 3: A successful login with these signs suggests dchen's password may be compromised, which is a behavior-based IoC.
- Step 4: Next: confirm with dchen, end the session and force a password reset, turn on MFA, and check what the account did after logging in.
Answer: The 3:27 a.m. login from 192.0.2.150, outside dchen's usual hours and network, suggests a compromised password. Verify with dchen, reset the password, enable MFA and review the account's activity.
Common mistakes
- Calling every burst of failures a brute-force attack. Look at the pattern: one user and many passwords, many users from one IP, or default pairs.
- Ignoring successful logins. A success at an odd time or from an odd place can be the most serious line in the log.
- Saying an offline attack can be found in the auth log. Offline attacks happen on the adversary's computer and leave no log entries.
- Choosing anomaly-based tools for every device. Many devices lack the power for them, and some embedded devices can't run any detection tool.
On the exam
- The free-response question gives you logs and expects you to cite them. Name the attack and point to specific line numbers, times, usernames and IP addresses as evidence.
- For detection-tool questions, reason with performance, cost and how critical the device is, and mention trade-offs like false positives versus ease of bypassing.
Connected topics
Videos
Check yourself: 4.4 Detecting Attacks on Devices
5 questions on 4.4 Detecting Attacks on Devices. Pick an answer to see if you got it, and why.
Authentication log from an invented company's web server
Which attack do lines 1–4 most likely show?
Which lines are the strongest evidence of password spraying?
What do lines 5 and 6 most likely show?
| File | Path | SHA-256 hash (first 16 characters) |
|---|---|---|
| report.docx | C:\Users\akim\Documents | fc54daf6865cec63 |
| svchelper.exe | C:\Users\akim\AppData\Temp | 36250873e8640168 |
| notes.txt | C:\Users\akim\Desktop | ab5aa97074c454a0 |
Files on an employee's laptop at an invented company. The company's threat feed lists the hash beginning 36250873e8640168 as known ransomware.
Which finding is a file-based indicator of compromise?
Besides a matching hash, which other detail about svchelper.exe could be a file-based IoC?
0 of 5 answered