Timestomping, log clearing and hidden data

Lesson 7.1 dealt with destroying data. This lesson covers three ways of misleading an examiner instead: changing timestamps, clearing or editing logs, and hiding data. Each leaves a mismatch between sources that record the same event independently; the examiner's job is to find it, measure it and state how strongly it supports manipulation.

Timestomping

Timestomping means changing a file's timestamps so that it blends in or looks older. Most tools change only the $STANDARD_INFORMATION ($SI) values, through SetFileTime (created, accessed, modified) or NtSetInformationFile with the FileBasicInformation class (all four, including the MFT entry modified time). Neither needs administrator rights, and $FILE_NAME ($FN) is harder to fake (Lesson 3.2). Some published techniques also bring $FN into line by combining $SI changes with a rename or move within the volume, during which NTFS copies the $SI values into the new $FN. That can produce matching $SI and $FN values, but it adds rename records to the journal.

Layered detection

No single check is conclusive, because archivers, installers and sync clients also set times. Apply the checks in layers and report how many agree.

1. $SI against $FN. $SI B earlier than $FN B, or an $SI C matching no operation, is the first lead.
2. Zero sub-seconds. A FILETIME counts 100-nanosecond intervals, so a genuine time is an exact second only about once in ten million. Several tools write whole seconds. Newer ones randomize the fraction, so a non-zero fraction proves nothing.
3. MFT neighbors. Entry numbers are a rough creation order, because the $MFT grows as files are added. An entry whose neighbors were all created on one day, but whose $SI says years earlier, is suspicious. Freed entries are reused, so this only supports other findings.
4. Older than the system. Compare $SI B with InstallDate (reset by feature upgrades) and with the $SI B of the volume's own metadata files, such as $MFT (entry 0) and $Volume (entry 3), which normally record when the volume was formatted. Copied or extracted files can carry older times, but their $SI C and $FN values then show the arrival.
5. $UsnJrnl. Setting times writes a record with BASIC_INFO_CHANGE (0x00008000) for the file's reference number, timestamped by the clock at the real time of the change. The flag also covers attribute changes, so read it with the $SI values. Copy and extraction tools usually set times while the file is still open, in the same burst as FILE_CREATE; a separate burst later is more telling. Rename records beside it point to the $FN technique.
6. $LogFile. An UpdateResidentValue on the $SI attribute holds the old timestamps in its undo data and the new ones in its redo data, if the log still covers that moment (minutes to hours).
7. Other artifacts that recorded the file. An LNK file keeps the target's $SI created, accessed and modified times, as they were when the link was written, at header offsets 0x1C, 0x24 and 0x2C (Lesson 2.4). Prefetch, Amcache and Jump Lists show when the file was used. If every reference dates from 2026, a 2019 creation time stands alone.
8. Internal times. A PE file's TimeDateStamp (Unix seconds in the COFF header, at the e_lfanew offset + 8; shown as LinkDate by Amcache parsers) cannot logically be later than the file's creation. Document metadata such as dcterms:created in Office files (Explorer's Details tab) works the same way. Both can be forged, and deterministic builds put a hash instead of a time in TimeDateStamp.

Clock manipulation is different

Someone may instead set the system clock back, create the file and restore the clock. Then $SI, $FN, USN records and event logs carry the false time together, with normal sub-seconds. The signs are those of Lesson 3.5: System Kernel-General event 1 (OldTime, NewTime) and Security event 4616 (PreviousTime, NewTime), and sequence numbers (USN, EventRecordID) that increase while times jump backward. Timestomping shifts one attribute; clock changes shift everything written in that window.

Log clearing

Windows

Clearing the Security log writes Security event 1102 ("The audit log was cleared") as the first record of the new log; clearing any other log writes System event 104, which names the channel. Both come from provider Microsoft-Windows-Eventlog and record SubjectUserName, SubjectDomainName and, for 1102, SubjectUserSid and SubjectLogonId. Clearing Security requires the "Manage auditing and security log" right, which administrators hold by default.

Find the means too: wevtutil cl <log> leaves a Prefetch file for WEVTUTIL.EXE on client editions, and 4688 if process creation is audited (with the command line only if command-line logging is also enabled); Clear-EventLog appears in PowerShell/Operational 4104 when script block logging is enabled, and in ConsoleHost_history.txt.

Other signs of tampering:

• EventRecordID. A cleared log restarts at 1. A log that rolled over normally starts higher and has no internal gaps, so a jump inside one file needs explaining.
• Time coverage and size. A Security log that begins minutes before the incident on a system used for months, or a file far below its MaxSize, fits a recent clear. Silent periods while other sources show activity also matter.
• Selective deletion. Some tools remove or hide single records by rewriting the file. Look for ID gaps, CRC32 checksum errors in the file or chunk headers, and records that parsers report as hidden or damaged. Treat these as leads.
• Service and policy tampering. Security 1100 ("The event logging service has shut down") and System 6006 (Event log service stopped) are normal at shutdown; without a following boot (6005) they suggest the service was stopped. Security 4719 records an audit policy change. Techniques that suspend logging in memory write nothing; only gaps against other sources show them.

Cleared records are often recoverable: older copies in Volume Shadow Copies (Lesson 2.9), 64 KB ElfChnk chunks carved from unallocated space, pagefile.sys or hiberfil.sys (EVTXtract, for example), and copies forwarded to a collector or SIEM.

Linux

Compare sources that log the same events (Lesson 6.4). A truncated /var/log/auth.log, or one missing session lines that journalctl still shows for sshd, indicates editing. Each wtmp record is 384 bytes on x86-64 Linux; utmpdump /var/log/wtmp shows a zeroed record as type 0 with a 1970 time, and a removed record as a login without its logout or a hole in the sequence of boots. journalctl --verify reports damaged journal files; "corrupted or uncleanly shut down" messages and .journal~ files often have innocent causes. Archived journal file names carry the sequence number of their first entry, so a missing file in the middle of the series shows as a gap; normal vacuuming removes only the oldest. Lesson 6.3 covers shell history tricks such as unsetting HISTFILE.

Hidden data

• Alternate data streams (Lesson 1.4). Any stream other than Zone.Identifier and known system streams deserves a look. MFTECmd (HasAds, IsAds), istat and dir /r list them; adding one writes STREAM_CHANGE.
• Extension against signature. Compare the first bytes with the extension: 4D 5A (MZ) is a PE file, 50 4B 03 04 a ZIP container (including .docx), 25 50 44 46 (%PDF) a PDF, FF D8 FF a JPEG. Autopsy's extension mismatch module and file automate this.
• Slack and unallocated space (Lesson 1.2). Non-zero RAM slack on a modern NTFS volume, or structured data across many slack areas, suggests deliberate placement.
• Hidden partitions and gaps (Lesson 1.1). Compare the partition table with the disk size and look for unpartitioned space beyond normal 1 MiB alignment. On GPT, attribute bits 62 (hidden) and 63 (no drive letter) hide basic data partitions from Explorer.
• Steganography. Statistical tests (chi-square or RS analysis of least significant bits) in tools such as StegExpose or zsteg flag images, with false positives. Data appended after a JPEG's FF D9 or a PNG's IEND, or stego software in execution artifacts, are often better leads.
• Encrypted containers disguised as files. Shannon entropy near 8.0 bits per byte, no recognizable header and a size that is an exact multiple of 512 bytes fit a container (Lesson 7.3). Compressed formats also score high but begin with a signature.
• Attributes and names. Hidden and System attributes, Unix names beginning with a dot, names copying system files in the wrong folder, the right-to-left override character U+202E, and $Recycle.Bin subfolders named after SIDs that do not exist in the ProfileList key.

Worked example: svc.dll and a cleared Security log

The triage collection from ana's laptop shows this MFT entry:

Sub-second check. The $SI value is 132,073,632,000,000,000 (bytes 00 40 8E BF 44 38 D5 01). Divided by 10,000,000 that is 13,207,363,200 seconds, remainder 0. The $FN value 134,179,718,913,301,447 ÷ 10,000,000 = 13,417,971,891 remainder 3,301,447, that is .3301447 s. The difference, 2,106,086,913,301,447 intervals or 210,608,691.33 s, is 2,437 days 14 h 24 min 51.33 s.

Reasoning. $SI B is 6 years 8 months before $FN B and before the volume was formatted; it has zero sub-seconds; the neighboring entries were created four seconds before and 35 seconds after the $FN time; and the journal records a timestamp change in a separate burst 12 seconds after creation, with no rename. $LogFile had wrapped and no longer covered 14:25. The defensible statement is that the name svc.dll was created on this volume at 2026-03-14T14:24:51Z, and its $SI timestamps were set to 2019-07-12T00:00:00Z at about 14:25:03Z, consistent with timestomping. The journal does not show who did it.

The log. Security.evtx begins with EventRecordID 1, a 1102 at 2026-03-14T14:38:55Z with SubjectUserName ana and SubjectUserSid S-1-5-21-…-1001. The Security log was cleared by ana's account 13 min 52 s after the timestamp change, and that account held the right to do so. Any 4616 time change event was lost with it, so check System Kernel-General 1 before trusting the 14:25:03Z journal time; there is none. Next: Prefetch for WEVTUTIL.EXE, 4104, shadow copies and carved chunks.

Technique, detection and confidence

Confidence refers to the manipulation; who did it needs separate evidence such as logons and execution artifacts.

Exam focus: Expect to report a file's true arrival time from $FN or the journal when $SI is forged, and the time of the change from a BASIC_INFO_CHANGE record. Be ready to do the sub-second check on a raw FILETIME and to read 1102 or 104 for who cleared which log and when. Questions may ask you to tell timestomping from a clock change, or where cleared records can be recovered.

Key points

• Timestomping usually changes $SI only; compare with $FN, sub-seconds, MFT neighbors, volume creation, $UsnJrnl, $LogFile, LNK and internal times, and count how many agree.
• BASIC_INFO_CHANGE records the real time timestamps or attributes were set; a separate burst after creation is stronger than one inside it.
• A clock change shifts every artifact together and leaves Kernel-General 1 or 4616; timestomping shifts one attribute.
• 1102 (Security) and 104 (System) name the account that cleared a log; record IDs restart at 1, and old records may survive in shadow copies, carved chunks and forwarded copies.
• On Linux, compare text logs with the journal, read wtmp with utmpdump, and check journal sequence numbers.
• Hidden data shows itself through structure: extra $DATA attributes, signature mismatches, odd slack, unpartitioned space, and high-entropy files without headers.