LogIntegrity

Last updated 10 Nov 2026

On this page

LogIntegrity answers: can the host's logs be trusted? Read it before you trust any other module's silence.

At a glance

Question	Can the host's logs be trusted?
Reads	The audit policy and what Group Policy set, the Security and System logs (always whole), the other logs Signal reads, and the GroupPolicy log.
Parameter	`LogIntegrity.max_rows`: the most rows of each table (default 10000).
Rule prefix	`LOGINT`

Check	Why it matters
Audit policy against the events present	A subcategory audited with no events, or events of one not audited, tells you the policy changed.
Each layer of policy	What the local GPO sets, what Group Policy applied, and what is in force - and which one decided. A setting Group Policy turns on that is off in force stands out.
The Security log's window, size and freshness	A short window means older activity is gone. A log silent for days is not recording.
The other logs	For each log Signal reads: recording or turned off, how far back it reaches, its size and what it does when full.
Logs cleared	Security 1102 and System 104 (from the Event Log service only - other providers use 104 too).
The system time changed	Security 4616, with the old and new time and the process that did it.
Records of other computers	Interleaved computer names in one log can mean records were imported or forged.
Unexpected shutdowns	System 6008: a crash or a power cut - or a host stopped to interrupt logging.

10 rules: 2 high, 5 medium, 3 low. The full text of each is in the rule catalog.

ID	Severity	Title	Evidence	ATT&CK
`LOGINT-LOG-CLEARED`	high	An event log was cleared	`system_event`	`T1685.005`
`LOGINT-SECURITY-LOG-CLEARED`	high	Security log was cleared	`security_event`	`T1685.005`
`LOGINT-AUDIT-DISABLED`	medium	Security auditing is effectively disabled	run facts	`T1685.001`
`LOGINT-AUDIT-GPO-NOT-IN-FORCE`	medium	Auditing that Group Policy applied is off on this host	run facts	`T1685.001`
`LOGINT-LOG-TURNED-OFF`	medium	A log that records from the start is turned off	run facts	`T1685.001`
`LOGINT-POLICY-CHANGED`	medium	Audit policy was changed by an account other than the computer	`security_event`	`T1685.001`
`LOGINT-SILENT-SINCE-BOOT`	medium	Nothing has been recorded in the Security log since the host last started	run facts	`T1685.001`
`LOGINT-AUDIT-WRITE-FAILURE`	low	The audit log could not be written	`security_event`	-
`LOGINT-MULTIPLE-COMPUTER-NAMES`	low	Events from different computer names are interleaved in this log	run facts	`T1070`
`LOGINT-TIME-CHANGED`	low	The system time was changed by a program other than the time service	`security_event`	`T1070.006`

Telemetry: Audit policy enabled, Security log recording, Security log window of 7 days or more, Security log maximum of 128 MB or more, No log clear in the log's time window. Every one that is off weakens every other module's answer.
Tables: the audit policy by layer, the logging policy, every log Signal read (event_logs), the event IDs present, the log clears.
Why it reads whole logs: how far a log reaches back is a property of the whole log. The profile's window never shortens it.

Read your audit policy

auditpol /get /category:* - note which subcategories are "No Auditing".
Run LogIntegrity

signal live -m LogIntegrity -o .\
Compare

Find the audit_policy table: does it agree with auditpol? Which layer decided each setting?

Protection: what protects the host, and does it work?