Security+ 801 Countdown, T-25: Indicators of Compromise Now Name Hashes, Timestamps, and Log Tampering

An intrusion leaves evidence. A dropped executable has a hash, a beacon goes to an IP address or a domain, a process runs from a folder where no legitimate process should, a file acquires a creation time that contradicts its own metadata, and an attacker who wants to stay hidden clears the log that recorded all of it. An indicator of compromise (IoC) is a piece of that evidence: an artifact or observation that an analyst can search for, pivot on, and share, and that points to an intrusion that is coming, in progress, or already over.

Detection and response run on indicators. A threat report arrives as a list of hashes, addresses, and domains; a SOC turns the list into blocklists and searches; an incident responder reads a Master File Table (MFT) row or a Windows event and decides whether the host was touched. Each kind of indicator is produced by a different mechanism, is evaded at a different cost to the attacker, and proves something narrower than it first appears.

In SY0-801 the topic sits in objective 2.5, “Given a scenario, analyze indicators of malicious activity,” whose list, now headed “Indicators of compromise,” is expanded with hash, Internet Protocol (IP) address, domain, malicious processes, file system artifacts, timestamp, log manipulation, and plaintext strings, beside account lockout, impossible travel, concurrent sessions, and excessive resource consumption (CompTIA 2025). A scenario question can hand you an MFT row or an Event 1102 and ask what it proves, and answering takes mechanism rather than memorized names.

Observables, indicators, and the Pyramid of Pain

NIST SP 800-150 separates an observable, “an event (benign or malicious) on a network or system,” from an indicator, which suggests an attack is imminent, underway, or already happened (NIST 2016). A process start is an observable; svch0st.exe starting from C:\ProgramData is an indicator.

Hutchins, Cloppert, and Amin (2011) supply the taxonomy vendors borrow. Atomic indicators “cannot be broken down into smaller parts and retain their meaning”: IP addresses, email addresses, vulnerability identifiers. Computed indicators, such as hash values and regular expressions, are derived from incident data. Behavioral indicators combine both with counts and logic, which is why a parent-child process chain reads as behavior rather than as a single artifact. The trap is that a hash feels atomic, since it is one opaque value, but it is computed from the file’s bytes.

David J. Bianco’s Pyramid of Pain ranks indicators by what detecting them costs the attacker (Bianco 2013). It is a blog concept (2013, revised in 2014 to give hashes their own level), not a standard or a CompTIA term. The right column is my mapping to the SY0-801 list:

Level, bottom to top	Bianco’s label	Nearest SY0-801 indicator
Hash values	Trivial	Hash
IP addresses	Easy	IP address
Domain names	Simple	Domain
Network/host artifacts	Annoying	File system artifacts; Timestamp; Log manipulation; Plaintext strings
Tools	Challenging	Fuzzy hashes (Bianco’s placement for ssdeep)
TTPs	Tough	Malicious processes read as behavior, e.g., parent-child chains

Basically, the bottom is precise and fast to block but cheap to evade; Bianco notes it is “so easy for hash values to change.” Domains cost slightly more than IPs (registration, payment, hosting), but domain generation algorithms (T1568.002) churn out thousands. Detecting tools and behavior forces the attacker to retool, so the most durable detection sits high on the pyramid. The sections that follow climb it from the bottom.

Hashes: exact match, brittle by design

A cryptographic hash identifies exact bytes; changing a single bit “will cause a completely different message digest to be generated” (NIST 2006). Microsoft’s Get-FileHash Example 4 hashes Hello world (Microsoft n.d.-b); capitalizing one letter flips one input bit (0x77 to 0x57):

PS> $s = [IO.MemoryStream]::new([Text.Encoding]::ASCII.GetBytes('Hello world')); (Get-FileHash -InputStream $s).Hash
64EC88CA00B268E5BA1A35678A1B5316D212F4F366B2477232534A8AECA37F3C
PS> $s = [IO.MemoryStream]::new([Text.Encoding]::ASCII.GetBytes('Hello World')); (Get-FileHash -InputStream $s).Hash
A591A6D40BF420404A011733CFB7B190D62C65BF0BCDA32B57B277D9AD9F146E

Of 256 output bits, 119 differ. A known-bad SHA-256 match therefore proves “this exact file” and nothing about the recompiled variant; a build that differs by one byte is, to the hash list, a file nobody has seen. Hashing algorithms themselves are covered at T-34.

Similarity hashes answer a different question, how close two files are, and their scores run in opposite directions:

• ssdeep (context triggered piecewise hashing) scores 0 to 100, higher meaning more similar; its documentation shows one appended character changing the MD5 completely while ssdeep still scores 99 (ssdeep Project 2018).
• TLSH reports a difference score where 0 means almost identical, and it needs at least 50 bytes of sufficiently complex input (Trend Micro n.d.).
• imphash is the MD5 of a PE file’s ordered, lowercased import list; it links recompiled variants, but Mandiant warns a shared imphash proves neither the same actor nor the same malware family (Mandiant 2014).

Sysmon can log IMPHASH beside SHA1, MD5, and SHA256 for each process image (Microsoft 2026). One distinction to hold onto: a known-bad hash match is an indicator of compromise, while a mismatch against a known-good baseline is file integrity monitoring, covered at T-8.

Timestamps and logs: anti-forensics leaves tracks

The indicators in the middle of the pyramid are the ones an attacker creates while trying to erase the others. Changing a file’s dates and clearing a log are both attempts to remove evidence, and both tend to produce evidence of their own.

Timestomping and the Master File Table

NTFS stores timestamps twice per MFT record: $STANDARD_INFORMATION ($SI, 0x10), which Explorer and most APIs show, and $FILE_NAME ($FN, 0x30), which the kernel maintains. Timestomping (T1070.006, tactic Stealth) usually rewrites $SI through user-level calls such as SetFileTime; changing $FN typically needs kernel interaction or a move-and-rename trick (MITRE 2026b). Eric Zimmerman’s MFTECmd flags the resulting mismatch. Column names and time format below are real; files and times are invented:

FileName,SI<FN,uSecZeros,Copied,Created0x10,Created0x30,LastModified0x10
wuauhelper.dll,True,True,False,2019-12-07 09:08:12.0000000,2026-10-20 02:14:37.5541872,2019-12-07 09:08:12.0000000
Q3-budget.xlsx,False,False,True,2026-10-19 14:03:11.2276410,,2026-09-30 16:45:02.8812004

Row 1 claims a 2019 install date to blend into System32, but $FN holds the real creation time, and the $SI fractions are zeroed, typical of tools that set whole seconds (Zimmerman n.d.). Row 2 is the trap: Modified earlier than Created is a normal copy, which resets creation time and keeps modification time (NIST 2006), so MFTECmd flags it Copied (the blank Created0x30 field means it matches 0x10). A third clue is Sysmon Event ID 2, “A process changed a file creation time,” though Sysmon cautions that many processes do this legitimately (Microsoft 2026). “Double timestomping” rewrites both attributes and defeats the $SI and $FN comparison.

Clearing, disabling, and editing logs

Log manipulation covers clearing, disabling, and selective editing, and it is narrower than a log that is simply absent. Logs go missing for benign reasons (rotation, retention limits, a broken forwarder); manipulation implies intent, and on Windows the act of manipulating usually leaves a record of its own:

• Event 1102, Security channel: “The audit log was cleared,” naming the account that did it (Microsoft 2021).
• Event 104, System channel: a named log was cleared; its Channel field says which, and Sigma lists agent rollout and system provisioning as false positives (SigmaHQ n.d.).
• Event 4719: audit policy changed; “Success removed” or “Failure removed” means auditing was switched off (Microsoft n.d.-a).
• EventRecordID gaps: a weak clue, because the DanderSpritz eventlogedit tool renumbers records and recalculates checksums, though Fox-IT recovered the hidden records (Jansen 2017).

wevtutil cl security is enough to produce a 1102. ATT&CK files that under T1685.005, Clear Windows Event Logs (tactic Defense Impairment); older material says T1070.001, revoked when ATT&CK v19 split Defense Evasion on April 28, 2026 (MITRE 2026a; MITRE 2026c). The practical defense is to get the record off the host before it can be cleared; log forwarding and integrity checks are covered at T-8.

Strings, files, processes, and load

The objectives list plaintext strings without defining the term. The likely primary reading is readable text extracted from a binary or memory; a second is cleartext credentials found where they should not be. Here is a synthetic lab file, sample.bin, scanned with an eight-character minimum:

$ strings -n 8 sample.bin
http://203.0.113.45/gate.php
Mozilla/5.0 (Windows NT 10.0; Win64; x64)
cmd.exe /c vssadmin delete shadows /all /quiet
Global\Mtx_7f3a9c21
update.example.net
README_RESTORE.txt
YOUR FILES ARE ENCRYPTED

Each line pivots to another indicator: an IP, a domain, a mutex name, a shadow-copy deletion (T1490), and ransom-note text. The file also holds a UTF-16LE path, C:\ProgramData\svc\svch0st.exe, that a single-byte scan misses; GNU strings needs -e l to find it (GNU Project n.d.). Obfuscation (T1027) hides strings outright, which is why FLOSS exists to recover stack, tight, and decoded strings (Mandiant n.d.). Strings are static evidence: a C2 address inside a binary shows intent, and only network logs show contact.

File system artifacts are what the intrusion left on disk: an executable in C:\ProgramData, a new .lnk in the user’s Startup folder under AppData\Roaming (T1547.001), svchost.exe outside System32 (T1036.005), or a Zone.Identifier “mark of the web” stream, which Sysmon Event ID 15 records on downloads. Malicious processes are the running form of that evidence, and the most durable way to read them is as behavior: which parent started the process, from what path, and what it did next. Parent-child chains are covered at T-30.

Excessive resource consumption is a symptom until attributed. Sustained CPU from an unsigned binary plus a long-lived outbound connection fits T1496.001 Compute Hijacking, which names cryptocurrency mining (MITRE 2025); disk and bandwidth spikes can mean data staging (T1074). Backups draw the same graph, so tie load to an image, a path, and a connection before calling it an indicator. The identity indicators (account lockout, impossible travel, concurrent sessions) get their log patterns at T-28.

Sharing indicators has a standard form. STIX is practitioner context rather than exam vocabulary, but it is how the pivots above travel: a STIX 2.1 Indicator for the sample could carry the pattern [file:hashes.'SHA-256' = '6447161f8c1b5431ca42e6669c8bba7f63d5c0459e6e41b0032ff82c749a82b7'] OR [domain-name:value = 'update.example.net'] (OASIS 2021a), and TAXII 2.1 moves it over HTTPS (OASIS 2021b).

What each indicator proves

Analysis means stating what a piece of evidence shows and, just as carefully, what it does not. The table collects the claim each indicator supports and the claim a careless reading would add.

Evidence in the stem	Indicator	Shows	Does not show
SHA-256 on a known-bad list	Hash	This exact file is known malware	Anything about the next variant
Beacon every 60 s to 198.51.100.23	IP address	Contact with suspect infrastructure	Exclusive use (shared hosting)
Random-looking subdomains of example.net	Domain	Possible DGA or C2	Which process asked
svchost.exe running from C:\ProgramData	Malicious processes	Masquerading	The parent chain
New .lnk in a Startup folder	File system artifacts	Persistence attempt	Who placed it
$SI 2019, $FN 2026, zeroed fractions	Timestamp	Deliberate backdating	Double timestomping
Event 1102 at 02:20 by a help-desk account	Log manipulation	Anti-forensics	What was erased
100% CPU, unsigned binary, long outbound session	Excessive resource consumption	Likely compute hijacking	Anything, if load is the only fact
http://203.0.113.45/gate.php inside a binary	Plaintext strings	Embedded C2 address	That it was ever contacted

What you need to know for SY0-801

• An observable is any event on a network or system; an indicator is an observable that suggests an attack is imminent, underway, or already happened (NIST SP 800-150).
• Hash is computed; IP address and domain are atomic; behavioral indicators add counts and logic.
• SHA-256 matches identical bytes; ssdeep (higher is closer) and TLSH (0 is closest) match similar bytes; imphash matches PE import tables.
• A known-bad hash match is an indicator of compromise; a mismatch against a known-good baseline is file integrity monitoring.
• On the Pyramid of Pain, hashes, IP addresses, and domains are cheap for the attacker to change; tools and behavior are expensive, so detection built on behavior survives recompilation and new infrastructure.
• Modified before Created usually means a copy; $SI earlier than $FN means timestomping.
• 1102: Security log cleared. 104: another named log cleared; needs context. 4719 with “Success removed”: auditing turned off.
• The absence of a record-number gap proves nothing.
• Log manipulation implies intent; a log that is merely absent can be rotation, retention, or a broken forwarder.
• Excessive resource consumption is a symptom until it is tied to an image, a path, and a connection.
• A plaintext string is static evidence; an embedded C2 address shows intent, and only network logs show contact.

Check yourself

1. MFTECmd output for C:\Windows\System32\wuauhelper.dll shows $SI Created 2019-12-07 09:08:12.0000000 and $FN Created 2026-10-20 02:14:37.5541872. Which indicator does this most directly show?

• A. Log manipulation.
• B. Timestamp manipulation consistent with timestomping.
• C. A file copied from removable media.
• D. Excessive resource consumption.

Answer: B. $SI earlier than $FN, with zeroed fractional seconds, is the timestomp signature. A copy shows Modified earlier than Created, not an $SI and $FN mismatch.

2. A report on a ransomware family lists its SHA-256 hashes, two C2 IP addresses, and its habit of deleting shadow copies with vssadmin. The SOC wants a detection that survives recompilation and new infrastructure. What should it prioritize?

• A. Block the listed hashes on every endpoint.
• B. Block the two IP addresses at the perimeter firewall.
• C. Alert on shadow-copy deletion command lines, regardless of file hash.
• D. Subscribe to a feed that refreshes the hash list daily.

Answer: C. Behavior sits near the top of the Pyramid of Pain and survives recompilation. Hashes and IP addresses are the cheapest indicators for the attacker to change.

3. Event ID 104, naming the Sysmon operational log, appears on a workstation ten minutes after a newly created local administrator logs on. No change ticket or agent rollout covers the host. What is the best assessment?

• A. Benign, because Event 104 is always a normal condition.
• B. Likely log manipulation; pull forwarded log copies and investigate the account.
• C. The Security log was cleared, so search for Event 4625.
• D. Excessive resource consumption caused by log rotation.

Answer: B. Event 104 can be benign during provisioning, but clearing Sysmon telemetry right after a new admin logon, with no change record, fits log manipulation. A cleared Security log appears as Event 1102, not 4625.

This is T-25 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-24: New Objective 2.6 Covers Attacks on AI Models. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Bianco, David J. 2013. “The Pyramid of Pain.” Enterprise Detection & Response (blog). Updated January 17, 2014.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

GNU Project. n.d. “strings.” GNU Binutils Documentation. Accessed October 12, 2026.

Hutchins, Eric M., Michael J. Cloppert, and Rohan M. Amin. 2011. “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains.” Lockheed Martin Corporation.

Jansen, Wouter. 2017. “Detection and Recovery of NSA’s Covered Up Tracks.” Fox-IT Blog, December 8, 2017.

Mandiant. 2014. “Tracking Malware with Import Hashing.” Google Cloud Blog.

Mandiant. n.d. “FLARE Obfuscated String Solver (FLOSS).” GitHub. Accessed October 12, 2026.

Microsoft. 2021. “1102(S) The Audit Log Was Cleared.” Microsoft Learn.

Microsoft. 2026. “Sysmon v15.22.” Microsoft Learn.

Microsoft. n.d.-a. “4719(S) System Audit Policy Was Changed.” Microsoft Learn. Accessed October 12, 2026.

Microsoft. n.d.-b. “Get-FileHash.” Microsoft Learn, PowerShell 7.6. Accessed October 12, 2026.

MITRE. 2025. “Resource Hijacking, Technique T1496.” MITRE ATT&CK Enterprise.

MITRE. 2026a. “Disable or Modify Tools: Clear Windows Event Logs, Sub-technique T1685.005.” MITRE ATT&CK Enterprise, v19.

MITRE. 2026b. “Indicator Removal: Timestomp, Sub-technique T1070.006.” MITRE ATT&CK Enterprise, v19.

MITRE. 2026c. “Updates: April 2026.” MITRE ATT&CK.

NIST. 2006. Guide to Integrating Forensic Techniques into Incident Response. NIST Special Publication 800-86.

NIST. 2016. Guide to Cyber Threat Information Sharing. NIST Special Publication 800-150.

OASIS. 2021a. STIX Version 2.1. OASIS Standard, June 10, 2021.

OASIS. 2021b. TAXII Version 2.1. OASIS Standard, June 10, 2021.

SigmaHQ. n.d. “Eventlog Cleared.” Sigma rule repository, GitHub. Accessed October 12, 2026.

ssdeep Project. 2018. “Getting Started with ssdeep.” ssdeep Project.

Trend Micro. n.d. “TLSH README.” trendmicro/tlsh, GitHub. Accessed October 12, 2026.

Zimmerman, Eric. n.d. “MFTECmd Source Code, Program.cs.” GitHub. Accessed October 12, 2026.