Topic 4.4 Notes – Detecting Attacks on Devices

How Device Attacks Show Up on a System

Device protections like updates, anti-malware, firewalls, and authentication try to block attacks. Detection matters when an attacker gets past those controls or when you need proof of what happened.

Logs are your main evidence source. A system may record:

• login attempts
• process starts and stops
• service changes
• file downloads
• file creation or modification
• software installs or updates
• privilege attempts
• config changes
• user or admin actions

A typical log entry includes:

• timestamp which tells you when it happened
• user/account tied to the event
• source IP or location showing where it came from
• device or service involved
• action that was attempted
• result such as success, fail, denied

On exams, the key skill is reading several entries together instead of treating each line by itself. In a login log, a short burst of failed attempts followed by a success from the same source can suggest a compromise and gives you a timeline to analyze.

SSH log timeline

Why this matters on tests and FRQs: one entry alone can be vague, but a sequence tells a story. You reconstruct the timeline in order and connect account + source + file path + process + outcome.

Three limits matter:

• Logs only show what the system was set up to record.
• No log evidence does not prove no attack happened.
• Detection only helps if someone or something responds.

Types of Indicators of Compromise

An IoC is evidence that a device or network has been compromised.

Host-based IoCs

These come from logs and config settings. Common signs include:

• unusual files created or changed
• unexpected processes running
• unexpected services enabled or created
• unauthorized config changes
• unauthorized software install or update

High-yield examples the AP exam likes:

• anti-malware disabled
• firewall settings changed
• remote-access service enabled
• account added to admin group

These are strong because they often show persistence or weakened security.

File-based IoCs

These come from examining files on the device.

• Hash match to known malware is strong evidence.
• Known-malware filename is weaker.
• Suspicious file path is also weaker and needs context.

A hash is a fixed fingerprint of file contents. Even a tiny file change creates a different hash, so signature matching can miss modified malware.

Behavior-based IoCs

These come from auth, access, and activity logs.

• multiple failed logins
• unusual login time
• unusual login location or IP
• unauthorized access to sensitive data
• privilege escalation attempts

Context matters. A 2 a.m. login is suspicious only if that does not fit normal use.

Authentication Logs and Password Attack Patterns

Auth logs record every login attempt and whether it succeeded or failed. When reading them, scan for:

• frequency
• time spacing
• one account or many
• one IP or many
• failed-only or failed-then-success
• whether time, location, and device fit expected use

Online attacks you can detect

1. Many wrong passwords for one user
   This points to brute force or password guessing against one account.

2. Repeated failures followed by a success
   This may mean the attacker finally got in.

3. Successful login from unusual time, location, or IP
   This can mean the password was compromised.

Multi-account attack patterns

• Password spraying means one likely password tried across many users.
• Credential stuffing means many known username-password pairs tried quickly.

That difference gets tested a lot.
Spraying = one password, many accounts.
Stuffing = many credential pairs.

Offline password attacks are different. If an attacker stole a password-hash database, the cracking happens on the attacker’s machine, so auth logs will not show the guesses. The response is to force password resets for all affected users.

Choosing and Evaluating Detection Methods

Three models show up here.

Choosing between them depends on:

• performance
  Low-power and embedded/IoT devices may only handle signature-based detection, or no on-device tool at all.

• cost
  Per-device licenses add up. EDR gives centralized monitoring across endpoints, which is powerful but expensive.

• sensitivity or criticality
  Devices holding sensitive data or running critical services justify stronger detection, often hybrid if resources allow.

That decision also fits into a broader defense-in-depth strategy, where detection is just one layer protecting the most important target, the data.

Defense in depth

Detection happens fairly late in the attack chain, after other controls were bypassed. It still matters because catching the attack on the device can stop data theft, persistence, privilege abuse, or service disruption.