4.4 - Detecting Attacks on Devices
System Logging and Indicators of Compromise
Devices log an enormous amount about their own activity: processes, settings, login attempts, file downloads, user actions, config changes, and software installs, all of which helps reconstruct exactly what happened before, during, and after an incident.
Example reconstruction: a login from a normal internal IP in the morning, followed hours later by a login from an unfamiliar IP, followed almost immediately by an unusually large batch of file downloads, followed by a connection to an unfamiliar external server and a large outbound data transfer, tells a clear story once you line up the timestamps: the account got compromised at that second login, and the attacker exfiltrated data in the minutes right after.
Indicators of compromise (IoCs) are evidence that something's been breached, generally falling into host-based (system logs and configs), file-based (malware files, suspicious executables), and behavior-based (unusual login patterns, privilege escalation attempts) categories.
Where each type of IoC shows up:
IoC type | Where it's found | Examples |
Host-based | Authentication logs, user activity logs, and system configuration files | Unusual files created or modified, unexpected processes or services, unauthorized configuration changes, unauthorized software installs or updates |
File-based | The files on the device, usually executable files | A file whose hash matches known malware, file names known to be created by a certain malware, file paths tied to malicious activity |
Behavior-based | Authentication logs and access logs | Multiple failed logins, unusual login times or locations, unauthorized attempts to access sensitive data, attempts to elevate privileges |
Authentication Logs
Auth logs record every login attempt, successful or failed, including timestamp, username, source IP, and outcome. Patterns worth watching for include multiple failed attempts (brute force), logins at unusual times (someone logging in at 2 AM who normally works 9 to 5), unusual locations (a login from a country the user's never been to), or multiple different accounts getting tried from one single IP (password spraying).
Host-Based Indicators of Compromise
Unusual files created or modified: files showing up in system directories, hidden files, suspicious names mimicking legitimate system files, or system files modified without any corresponding legitimate update. For example, a file named to closely mimic a real Windows process but sitting in the wrong location, created at 2:47 AM, often turns out to be malware disguising itself as something legitimate.
Unexpected processes or services: unknown processes running, processes eating unusual amounts of CPU or memory, processes connecting to strange IPs, or services suddenly set to auto-start that weren't before. A process named almost identically to a legitimate Windows process but with a subtle typo, using unusually high CPU and connecting to an IP in an unexpected part of the world, is a classic red flag.
Unauthorized configuration changes: security software getting disabled, new user accounts appearing, registry changes, new startup programs, or new scheduled tasks. For example, Windows Defender getting disabled by an admin account at 2:47 AM with no scheduled maintenance planned, paired with a new scheduled task quietly running an unfamiliar executable every 5 minutes, points strongly toward an attacker disabling security and setting up persistence.
Unauthorized software installation: unfamiliar applications appearing, software installed outside the approved list, or software installed without going through the normal IT ticket process. A remote access tool installed manually at 2:51 AM with no corresponding IT ticket, and which turns out to be a known RAT, is a clear sign of malicious installation.
File-Based Indicators of Compromise
Hash matching known malware: calculating a suspicious file's hash and checking it against threat intelligence databases, where a strong match against a known malware family (confirmed by many antivirus engines flagging it, for instance) is essentially confirmation. EDR tools do this automatically and continuously.
Malware-associated file names: certain file names are strongly associated with specific malware types, like a ransom note file appearing on the desktop with content describing encrypted files and payment demands, which is basically a confirmed ransomware infection requiring immediate isolation.
Malicious file paths: certain locations are common hiding spots for malware, like temp folders, auto-start directories, or world-writable public folders. An unsigned executable sitting in a temp folder, created minutes ago, and already connecting out to an unfamiliar server, with no legitimate software associated with it, is a strong sign of malware that should be quarantined for analysis.
Behavior-Based Indicators of Compromise
Multiple failed login attempts: a single account seeing dozens of failed password attempts in quick succession from one IP is a classic brute force pattern, typically triggering an alert somewhere around 5 to 10 failures in a short window.
Unusual login times or locations: a login at an odd hour compared to someone's normal schedule is worth flagging for investigation, and a login from a location that's physically impossible given the timing of their last login (like being in New York and then Russia eight minutes later) is a strong sign of account compromise, warranting an immediate block and verification.
Unauthorized access to sensitive data: someone accessing files well outside their normal role and scope, especially after hours, like a marketing intern suddenly opening executive payroll data at midnight, is worth investigating as either a compromised account or a potential insider threat.
Privilege escalation attempts: a standard user repeatedly trying to add themselves to an admin group, modify the registry, or disable User Account Control within a short span of time is a strong sign their account has been compromised and someone's trying to gain administrative access, warranting immediate account disablement and workstation isolation.
Choosing Detection Methods for Devices
Performance impact matters a lot here. Signature-based detection is lightweight, low CPU and memory usage, suitable for pretty much any device including lower-powered ones. Anomaly-based detection is much heavier, using significant CPU, memory, and disk I/O for statistical analysis and machine learning, better suited to powerful servers or dedicated security appliances. Many embedded devices simply don't have the resources to run any local detection tool at all and have to rely entirely on network-based monitoring instead.
Cost varies by licensing model, whether per-device, per-user, or a flat enterprise fee. EDR (Endpoint Detection and Response) services from third-party vendors provide much more comprehensive protection, combining signature and behavioral detection with centralized monitoring, automated response, and expert analyst oversight, but they cost significantly more (commonly $50 to $150 per endpoint per year) compared to standalone antivirus. The decision usually comes down to budget, actual risk level, and whether the organization has the expertise to manage something more comprehensive.
Device criticality should drive the choice too. Critical servers holding sensitive data deserve hybrid detection with 24/7 monitoring and automated containment. Standard workstations do fine with signature-based detection plus some behavioral monitoring and daily review. Low-criticality devices like a lobby kiosk with no sensitive data can get by with basic signature detection and periodic scans, since reimaging after a compromise carries essentially no real loss.
Evaluating Detection Method Impact
Three factors decide how much a detection method helps on a device: speed and performance, the phase of the attack, and false positives versus ease of bypassing detection.
Signature-based detection is fast (millisecond detection, minimal CPU hit) and works fine even on lower-end hardware. Anomaly-based detection is slower and heavier, taking noticeably more processing power, which can cause real sluggishness on standard laptops and simply can't run at all on embedded devices.
The phase of the attack matters because, to act on a device, an adversary first has to get past physical and network protective, deterrent, and detective controls. Device-level detection is one of the last chances to catch them before they reach sensitive data or disrupt critical services. For example, an attacker who tailgates past physical security, gets onto the network, and guesses a weak password might still get caught at the device level when their unusual file access pattern trips an alert, meaning the device layer stopped a breach that had already defeated three earlier layers.
There's a real tradeoff between false positives and how hard a method is to bypass: signature-based detection has a very low false positive rate but is easier for attackers to dodge just by modifying their malware slightly or using polymorphic code. Anomaly-based detection has a much higher false positive rate but is genuinely hard to evade, since an attacker would need to make their activity look completely normal. Whether to prioritize fewer false alarms or catching more novel attacks really comes down to an organization's risk tolerance and how much alert volume its analysts can actually handle.
On devices, the balance usually tips toward signatures: most device-level detection tools are signature-based, which keeps false positives low but means slightly modified malware can slip past them.
Detecting Password Attacks on Devices
Online attacks show up clearly in logs: a single account seeing dozens of different password attempts in rapid succession from one IP is a brute force attack, warranting an account lock, security alert, and investigation of the source. If a password database itself gets stolen, the safe assumption is that every password in it is compromised, meaning the right response is forcing a reset for all users, invalidating all active sessions, enabling MFA if it wasn't already on, and watching closely for unauthorized access attempts.
Location and time anomalies are useful signals too: a login from a country the user's never connected from before is high-confidence evidence of compromise and should trigger a block plus verification, while a login at an unusual hour compared to someone's normal pattern is a more moderate signal worth an extra authentication step rather than an outright block.
Password spraying shows up as many different usernames all being tried with the same password in a short window, all from one IP, in rapid succession, which is quite different from typical brute force (which is many passwords against one account). Detecting it means blocking the source IP, forcing a password change for any account that succeeded, and alerting affected users.
Credential stuffing looks like a sequence of common default username-password combinations tried rapidly, one after another, across different accounts, which is distinguishable from brute force (many attempts on one account) by the fact that it's testing pre-known default combos rather than an actual list of guesses.
Offline password attacks are the trickiest to detect because the actual cracking happens entirely on the attacker's own hardware with zero interaction with the target, meaning nothing in the target's logs will ever show the cracking attempts themselves. All the target typically sees is the original breach (if detected) and then, potentially weeks later, a successful login using the correctly cracked password, which looks completely legitimate in the logs. If a database breach is suspected, the right response is to immediately force password resets and invalidate sessions, enable MFA right away, investigate exactly what was accessed and whether hashes were stolen (and how strongly they were protected, salted vs. unsalted, strong algorithm vs. weak), and then keep monitoring closely for unusual login activity over the following weeks while strengthening password requirements going forward.
Reading an authentication log: here's part of one company's authentication log. The company's own network uses
10.0.4.x addresses, VPN-GW is the VPN gateway remote workers log in through, CAM-07 is a security camera, and kpatel normally works 8 to 5 from the office.Date Time Device User Source IP Result Mar 9 08:03:12 WS-114 kpatel 10.0.4.37 SUCCESS Mar 9 08:10:45 WS-120 rmorales 10.0.4.52 SUCCESS Mar 10 02:13:40 VPN-GW aguzman 198.51.100.23 FAILED Mar 10 02:13:41 VPN-GW bchen 198.51.100.23 FAILED Mar 10 02:13:41 VPN-GW cdavis 198.51.100.23 FAILED Mar 10 02:13:42 VPN-GW dnguyen 198.51.100.23 SUCCESS Mar 10 02:13:43 VPN-GW eokafor 198.51.100.23 FAILED Mar 10 02:13:44 VPN-GW fsmith 198.51.100.23 FAILED Mar 10 02:31:05 CAM-07 admin 203.0.113.77 FAILED Mar 10 02:31:06 CAM-07 admin 203.0.113.77 FAILED Mar 10 02:31:07 CAM-07 root 203.0.113.77 FAILED Mar 10 02:31:08 CAM-07 default 203.0.113.77 FAILED Mar 10 02:31:09 CAM-07 support 203.0.113.77 FAILED Mar 10 03:12:44 VPN-GW kpatel 192.0.2.150 SUCCESS Mar 10 09:15:20 VPN-GW tlee 203.0.113.45 FAILED Mar 10 09:15:21 VPN-GW tlee 203.0.113.45 FAILED Mar 10 09:15:22 VPN-GW tlee 203.0.113.45 FAILED Mar 10 09:15:23 VPN-GW tlee 203.0.113.45 FAILED Mar 10 09:15:24 VPN-GW tlee 203.0.113.45 FAILED Mar 10 09:15:25 VPN-GW tlee 203.0.113.45 LOCKED OUT
02:13:40 to 02:13:44, password spraying: six different accounts tried within four seconds, all from one outside IP (
198.51.100.23), in the middle of the night. Each account gets just one try, which stays under any lockout limit. Spraying can also come from many unusual IP addresses at once, so many accounts tried seconds apart is the pattern to watch for even when the IPs differ. The one SUCCESS means dnguyen's password was a common one. Block the IP, reset dnguyen's password, and check what that account did after 02:13.02:31:05 to 02:31:09, credential stuffing: a fast series of default usernames (
admin, root, default, support) against the camera, all from 203.0.113.77. Nobody at the company has those usernames, so these are factory default accounts. Most logs don't record the password that was tried (storing it would be a risk of its own), so the usernames and the speed are the clue. Every attempt failed, so it looks like the camera's default login was changed. Block the IP, and find out why a camera can be reached from the internet at all.03:12:44, unusual time and IP address: kpatel's password worked on the first try, but at 3 AM and from an IP address that never shows up for kpatel. Nothing failed, so this isn't guessing. The password was probably stolen some other way (phishing, a reused password, or a hash cracked offline). Treat the account as compromised: disable it, reset the password, and turn on MFA.
09:15:20 to 09:15:25, online password attack: one account, tlee, gets five wrong passwords in five seconds from one IP, and then the lockout kicks in. No person types that fast, so this is an automated tool. The lockout did its job. Block the IP and let tlee know.
Notice what's missing: no line in this log could ever show an offline attack, since that cracking happens on the adversary's own computer.
Bringing It All Together
Solid device attack detection comes down to comprehensive logging (authentication, file access, system changes, process activity), regularly reviewing those logs both manually and with automated tools like SIEM or EDR, understanding the different types of indicators of compromise (host-based, file-based, behavior-based), matching detection methods to a device's actual criticality and resource constraints, and responding quickly once something's flagged.
Example of it all working together: on a high-value executive laptop, an EDR agent flags a suspicious PowerShell execution through behavioral analysis, a separate alert catches a newly created file in a temp directory with a high-risk hash, and network monitoring flags an unusual outbound connection to an unfamiliar region. None of these alone might be definitive, but a SIEM correlating all three together produces a high-confidence alert, triggering automatic network isolation of the device and a manual investigation by a security analyst, successfully containing the compromise before any data actually gets exfiltrated. That kind of layered detection, matched appropriately to how critical the device is, is what gives the best real-world protection against the wide range of threats out there.