Devices automatically log logins, file activity, and system changes, and those logs are where you spot an attack. To detect attacks, you analyze logs for indicators of compromise (IoCs), pick a detection method that fits the device's resources and importance, and read authentication logs to recognize specific password attacks. Some attacks, like offline password cracking, leave no log trail at all.

more resources to help you study

practice questions

Why This Matters for the AP Cybersecurity Exam

Detecting attacks on devices is the final defensive layer in Unit 4, after authentication and protection. This topic builds your ability to read logs as evidence, name what kind of attack a pattern shows, and justify which detection method fits a given device. Expect to explain how IoCs are found, compare signature-based and anomaly-based detection using real tradeoffs (performance, cost, false positives), and interpret authentication log entries to identify password attacks. Being able to look at a short log sample and say "that is password spraying" or "that is an online password attack" is exactly the kind of analysis this part of the course expects.

Key Takeaways

An indicator of compromise (IoC) is evidence that an adversary has compromised a device or network. IoCs are host-based, file-based, or behavior-based.
Authentication logs record every login attempt and are the main place password attacks show up.
Signature-based detection is faster, lighter, and has fewer false positives, but it is easier to bypass. Anomaly-based detection catches more but uses more resources and triggers more false alarms.
Choose a detection method based on performance limits, cost, and how sensitive or critical the device is. Many embedded devices cannot run detection tools at all.
Online password attacks, password spraying, and credential stuffing each leave a recognizable log pattern. Offline password attacks cannot be detected because they happen on the adversary's computer.

How to Detect Attacks Against Devices

Computers log a lot automatically: system processes and settings, login attempts, file download attempts, and user actions. When something goes wrong, security analysts pull these logs to reconstruct what happened before, during, and after an incident. Think of it like reviewing security footage after a break-in.

When analysts find evidence that an attacker actually got in, that evidence is called an indicator of compromise (IoC). An IoC is proof that a device or network has been compromised. IoCs come in three main types, and you should know all of them.

Host-Based IoCs

Host-based IoCs are clues you find by analyzing logs and configuration settings on the device itself. You look at authentication logs, user activity logs, and system config files for signs like:

Unusual files being created or modified (a random .exe showing up in a system folder)
Unexpected processes or services running in the background
Unauthorized changes to system configuration settings (like firewall rules being turned off)
Unauthorized software installation or updates

If your computer suddenly has a new "service" running that you have never heard of, that is a host-based IoC worth investigating.

File-Based IoCs

File-based IoCs show up when you analyze files on a device, usually executable files. These include:

Files whose hash matches known malware (a hash is a unique fingerprint of a file, so if a file has the same hash as a known virus, that is a problem)
File names known to be created by specific malware
File paths associated with malicious activity (malware often hides in odd locations like C:\Users\Public\AppData\Temp\)

Antivirus software relies heavily on file-based IoCs because they are concrete and easy to match against a database.

Behavior-Based IoCs

Behavior-based IoCs come from analyzing patterns in logs, especially authentication and access logs. Instead of looking for a specific file, you look for behavior that does not make sense:

Multiple failed login attempts in a short window
Unusual login times or locations (an account logs in at 3 AM from another country)
Unauthorized attempts to access sensitive data
Attempts to elevate user privileges (a regular user suddenly trying to gain admin access)

Authentication logs (often called auth logs) record every attempted login on a system, successful or not. They are valuable for catching behavior-based IoCs because most attacks start with someone trying to get in.

Choosing Controls for Detecting Attacks

Not every detection method works for every device. When picking what to use, organizations weigh three main criteria.

Performance

Detection tools use memory and processing power. Anomaly-based detection (which watches for unusual behavior) uses more system resources than signature-based detection (which matches activity against a database of known threats).

For devices with limited resources, signature-based detection is the smarter pick because it is lighter. Many embedded devices, like smart thermostats or industrial sensors, do not have enough system resources to run any detection tools on the device itself.

Cost

Detection software is not free. An organization that monitors thousands of devices needs enough licenses for all of them, and that adds up fast. Some organizations buy an endpoint detection and response (EDR) service from a third-party vendor. EDR is expensive, but it gives a holistic, unified view of threats across an organization's devices, usually with a centralized alert platform where security teams monitor every device in one place.

Sensitivity or Criticality of the Device

A device that holds sensitive information or runs a critical service is more attractive to attackers than an ordinary machine. Devices like these are more likely to be targeted and benefit from a hybrid-detection model when possible, meaning signature-based and anomaly-based detection work together for maximum protection.

Evaluating the Impact of a Detection Method

Once you have picked a method, you need to think about how it affects the device and the bigger security picture.

Speed and Performance

Signature-based detection is generally faster than anomaly-based detection because it matches activity against a known list. Anomaly-based tools have to learn what "normal" looks like and constantly compare, which takes more CPU and memory. That effect is compounded on devices, which often lack the processing power to run anomaly-based tools effectively. Resource-intensive detection tools can degrade device performance.

Phase of the Attack

Before an attacker can act on a device, they have to get past a combination of physical-layer or network-layer protective, deterrent, and detective controls. Detecting and stopping an attack at the device level can prevent adversaries from accessing sensitive data or disrupting critical services. Device-level detection is essentially the last line of defense, so it matters a lot.

False Positives vs. Ease of Bypassing

Most device-level detection is signature-based, which has a low rate of false positives (it does not cry wolf often). The tradeoff is that signature-based detection is easier to bypass. If an attacker tweaks their malware slightly, the hash changes and the signature no longer matches. This balance between accuracy and resilience is the core tension in choosing a detection method.

Detecting Password Attacks in Log Files

Authentication logs are where password attacks reveal themselves. Different attacks leave different fingerprints, so being able to read auth logs is a key skill.

Online Password Attacks

An online password attack tries passwords directly against a live login system. These show up in auth logs as repeated failed login attempts from a single user. If one account has dozens of failed login attempts in a couple of minutes, that is a strong indicator.

Here is a simplified auth log showing an online attack:

</>Code
2024-03-15 14:22:01 FAIL user=jsmith ip=203.0.113.45
2024-03-15 14:22:03 FAIL user=jsmith ip=203.0.113.45
2024-03-15 14:22:05 FAIL user=jsmith ip=203.0.113.45
2024-03-15 14:22:07 FAIL user=jsmith ip=203.0.113.45
2024-03-15 14:22:09 FAIL user=jsmith ip=203.0.113.45

One user, one IP, many failures, all within seconds. That is a classic online attack.

Also note: if a user:password hash database is stolen, every password in it should be treated as insecure. All users need to reset their passwords, because the adversary can crack those hashes offline at their own pace.

Compromised Account Indicators

If a legitimate user suddenly logs in from a different location, a new IP address, or at an unusual time (a 9-to-5 employee logging in at 3 AM from a different country), their password may already be compromised. The login succeeds, but the context is suspicious.

Password Spraying

Password spraying is when an attacker tries one common password against many different usernames. This avoids triggering account lockouts because each individual account only sees one or two failed attempts.

In the logs, password spraying looks like many different users failing to log in within seconds of each other, often from the same IP or a few unusual IPs:

</>Code
2024-03-15 09:00:01 FAIL user=alice    ip=198.51.100.7
2024-03-15 09:00:02 FAIL user=bob      ip=198.51.100.7
2024-03-15 09:00:03 FAIL user=carlos   ip=198.51.100.7
2024-03-15 09:00:04 FAIL user=diana    ip=198.51.100.7
2024-03-15 09:00:05 FAIL user=ethan    ip=198.51.100.7

Different users, same IP, all failing back to back. That pattern is the giveaway.

Credential Stuffing

Credential stuffing uses default or leaked username and password combos. Attackers try these known pairs on a new system in quick succession, betting that people reuse passwords. The indicator is a rapid series of default user:password combinations being attempted on a device, usually from the same IP.

The difference from password spraying: spraying uses one password against many users, while stuffing tries known pairs (often defaults like admin:admin or leaked combos) against a system.

Offline Password Attacks Cannot Be Detected

Here is the catch: offline password attacks are invisible to your logs. In an offline attack, the adversary already has a stolen hash database and is cracking passwords on their own computer, completely off your system. Your auth logs show nothing because no login attempts are happening on your server. The only defense is preventing the hash database from being stolen in the first place, and forcing password resets if it ever is.

That is why protecting password databases matters so much. Once a hash file leaves your system, the attack moves to a place where you cannot see it.

How to Use This on the AP Cybersecurity Exam

Reading Log Files

When you see an auth log sample, check three things fast: how many users appear, how many IPs appear, and how quickly the attempts happen.

One user, one IP, many fast failures means an online password attack.
Many different users, one IP, fast back-to-back failures means password spraying.
Known or default username:password pairs tried in quick succession means credential stuffing.
A successful login from an unexpected location, IP, or time suggests a compromised account, not a brute-force attempt.

Classifying IoCs

Decide where the evidence comes from. If it comes from logs and config settings on the machine, it is host-based. If it comes from analyzing files (hashes, file names, file paths), it is file-based. If it comes from suspicious patterns in login and access logs, it is behavior-based. The same auth log can hold both host-based and behavior-based indicators, so focus on what the question is pointing at.

Comparing Detection Methods

If a question asks you to pick or justify a detection method, anchor your answer in the actual tradeoffs:

Limited resources or embedded devices favor signature-based detection (or no on-device detection at all).
Sensitive or critical devices favor a hybrid model when possible.
Signature-based wins on speed and low false positives but loses on being easy to bypass.
Anomaly-based catches more but uses more resources and produces more false positives.

Common Trap

Do not assume every detection method can catch every attack. Offline password attacks happen on the adversary's machine and never touch your logs, so the only real answer is prevention plus forced password resets after a hash database is stolen.

Common Misconceptions

"Any failed login spike is a brute-force attack on one account." Look at the pattern. Many users failing from one IP is password spraying, not a single-account online attack.
"A successful login is always safe." A successful login from an odd location, IP, or time can be the clearest sign that a password has already been compromised.
"Anomaly-based detection is always better because it catches more." It uses more resources and produces more false positives, and many devices cannot run it at all. Signature-based detection is often the right fit, especially for low-resource and embedded devices.
"Signature-based detection is hard to beat." It has few false positives, but attackers can bypass it by changing malware just enough to alter the hash so it no longer matches a known signature.
"Logs can catch every attack." Offline password attacks leave no trace in your logs because the cracking happens entirely on the adversary's computer.
"IoC just means a virus was found." An indicator of compromise is any evidence of an adversary compromising a device or network, including unusual processes, config changes, suspicious files, or strange login behavior.

Vocabulary

The following words are mentioned explicitly in the AP® course framework for this topic.

Term	Definition
anomaly-based detection	A detection technique that identifies potential threats by analyzing deviations from normal network behavior patterns.
authentication logs	Records of login attempts and authentication events that can be analyzed to detect suspicious activity or unauthorized access attempts.
behavior-based IoCs	Indicators of compromise discovered by analyzing logs, including multiple failed login attempts, unusual login times or locations, unauthorized access attempts, or privilege escalation attempts.
cost	A criterion for determining detection methods, including the expense of purchasing software licenses and detection services for multiple devices.
credential stuffing	An attack where default or previously compromised user:password combinations are attempted in rapid succession on a device, typically from the same IP address.
cyber incident	A security event involving unauthorized access or attack on a computing system or network.
detection method	A technique or tool used to identify and alert to potential security attacks or threats on a device.
detective security controls	Security measures designed to identify and detect attacks or unauthorized activities after they occur.
deterrent security controls	Security measures designed to discourage or prevent adversaries from attempting attacks.
device performance	The speed and efficiency with which a device operates, which can be degraded by resource-intensive security tools.
embedded devices	Specialized computing devices with limited system resources that may lack sufficient processing power to run detection tools.
endpoint detection and response (EDR)	A third-party service that provides centralized, unified threat detection and monitoring across an organization's devices with a centralized alert platform.
false positives	Instances where a detection method incorrectly identifies legitimate activity or files as malicious threats.
file-based IoCs	Indicators of compromise discovered by analyzing files on a device, including files with hashes matching known malware, suspicious file names, or file paths associated with malicious activity.
host-based IoCs	Indicators of compromise discovered by analyzing logs and configuration settings, such as unusual files, unexpected processes, unauthorized system changes, or unauthorized software installations.
hybrid-detection model	A detection approach that combines multiple detection methods to provide maximum protection for devices storing sensitive information or providing critical services.
indicator of compromise (IoC)	Evidence that an adversary has compromised a device or network.
IP address	A unique numerical identifier assigned to a device on a network, used to track the source of login attempts and network activity.
network-layer protective controls	Security measures that protect against unauthorized access and attacks transmitted through network connections.
offline password attacks	Password attacks that occur on an attacker's own computer using stolen password hashes, making them undetectable through log file analysis.
password attack	Adversarial techniques used to compromise user passwords and gain unauthorized access to accounts or systems.
password spraying	An attack where many users are targeted with common passwords from one or a few IP addresses, often to avoid detection by spreading attempts across multiple accounts.
performance	A criterion for selecting detection controls, considering how detection tools impact a device's system memory and processing power.
phase of the attack	The stage of an attack sequence, such as initial access, lateral movement, or data exfiltration, at which detection and prevention can occur.
physical-layer protective controls	Security measures that protect against physical access to devices and infrastructure.
sensitivity or criticality of the device	A criterion for selecting detection methods based on whether a device stores sensitive information or provides critical services that make it a likely target for adversaries.
signature-based detection	A detection technique that identifies known malware and attacks by matching network traffic against predefined patterns or digital signatures.
system configuration settings	Parameters and options that control how a computing system operates, which are logged and can reveal unauthorized changes.
system processes	Programs and operations running on a computing system that are logged and can be analyzed to detect attacks.
user:password hash database	A database containing encrypted representations of user passwords that, if compromised, requires all users to reset their passwords.

Frequently Asked Questions

What is an indicator of compromise (IoC) in AP Cybersecurity?

An indicator of compromise (IoC) is evidence that an adversary has compromised a device or network. IoCs are grouped into three types: host-based (found in logs and config settings), file-based (found in executable files, such as a file whose hash matches known malware), and behavior-based (found in patterns like multiple failed logins or unusual login times).

What is the difference between signature-based and anomaly-based detection?

Signature-based detection matches activity against a database of known threats, runs faster, uses fewer system resources, and produces fewer false positives, but is easier for adversaries to bypass. Anomaly-based detection watches for unusual behavior, catches more novel threats, but uses significantly more memory and processing power and generates more false positives.

How do you identify password spraying vs. credential stuffing in an authentication log?

Password spraying appears in auth logs as many different usernames failing to log in within seconds of each other from the same IP address, because the attacker tries one common password across many accounts. Credential stuffing shows a rapid series of known or default username-and-password combinations attempted in quick succession, also often from the same IP.

Why can't offline password attacks be detected in authentication logs?

Offline password attacks happen entirely on the adversary's own computer, where they crack a stolen password hash database without ever sending login attempts to your system. Because no login attempts reach your server, nothing is recorded in your authentication logs.

What criteria should you use to choose a detection method for a device?

The three main criteria are performance (anomaly-based tools use more resources, so resource-limited or embedded devices may need signature-based detection or none at all), cost (including software licenses or the expense of an EDR service), and the sensitivity or criticality of the device (high-value devices benefit from a hybrid-detection model when possible).