Detection by Log Source and Security Device
Atlas home · Research path · Operational families · Anomaly models · Visual index
Consolidated 27 September 2026 from the revised publication. Source-reported incidents, proposed models, functional tests, and synthetic results remain separate evidence classes. Provenance and review scope.
A telemetry contract states what must actually be collected: provider/channel, event version, fields, entity keys, clock, parser, retention, collection health and enrichment. A vendor feature list is not a measurement of coverage. Verify prerequisites with generated test activity and raw records before writing analytics against normalized fields.
Text equivalent and full-size diagram
Validate raw records before treating a normalized table as detection coverage.
- Source. Provider, channel, event version.
- Collection. Policy, filters, delivery health.
- Normalization. Parser, units, keys, clock.
- Analytic. Tested fields and explicit gaps.
- Distinct pipelines. Security 4688 and Sysmon 1 are separate process-creation sources. Validate each adapter.
- Missing observations. No event can mean no activity, disabled auditing, filtering, delay or failed collection.
Windows Security Event Log
Do not infer effective audit settings from a universal default. OS version, machine role, policy inheritance and forwarding filters matter. Event 4648 belongs to Logon auditing; the earlier blanket statement that it is disabled by default was wrong. Inspect effective policy with the read-only auditpol /get /category:*, then test generation and forwarding. Microsoft audit recommendations.
| Event / channel | Required collection or meaning | Interpretation boundary |
|---|---|---|
| 4624, 4625, 4648 / Security | Audit Logon, with relevant success/failure policy | Successful/failed logon and explicit credentials are different events; none alone identifies credential theft. |
| 4672 / Security | Audit Special Logon | Privileges assigned to a session are not proof of an exploit or unexpected escalation. |
| 4688 / Security | Audit Process Creation; separate command-line inclusion policy | Native process creation and Sysmon are independent pipelines. Command lines may contain sensitive information. |
| 4662 / Security, on DC | Directory Service Access auditing and an applicable object SACL | Missing events can mean missing auditing. A SACL selects audited actions; it does not grant replication permission. |
| 4720, 4728, 4732, 4756 / Security | Appropriate account/group-management auditing | Windows objects only; not arbitrary application-database accounts. |
| 4769 / Security, on DC | Audit Kerberos Service Ticket Operations | Successful service-ticket requests are normal. Capture encryption type, requester and target fields available in that event version. |
| 4776 / Security | Audit Credential Validation | Appears on the authority validating credentials: a DC for domain accounts or the relevant computer for local accounts. |
| 4697, 4698, 5140 / Security | Security System Extension, Other Object Access Events, File Share respectively | Confirm effective policy; service/task/share activity has legitimate uses. |
| 7045 / System | Service Control Manager | New service installation; a separate provider/channel from Security 4697. |
| 1102 / Security; 104 / System | Security-log clearing versus Eventlog-provider log-clear records | Inspect the actual cleared channel. A cleared log and a forwarding interruption are different observations. |
| 5001, 5007 / Defender Operational | Real-time protection disabled; configuration changed | Preserve old/new settings and actor context where available; maintenance can be legitimate. |
Field definitions: 4688, 4662, 4776. Verify fields against raw XML rather than assuming that an indexer's aliases are universal.
Text equivalent and full-size diagram
A SACL selects auditing; it does not grant permissions. A successful logon or privileged session is not by itself evidence of credential theft.
Selected Security-channel reference: 4624 is successful logon; 4625 is failed logon; 4648 is a logon attempt using explicit credentials; 4672 records special privileges assigned to a new logon.
4688 records a new process, with separate command-line inclusion policy. 4662 records directory-service object access when the applicable auditing and SACL conditions are met. 4769 concerns service-ticket requests; 4776 concerns credential validation.
4720 records creation of a Windows user. 4728, 4732 and 4756 concern addition to global, local and universal security groups, respectively. These are Windows objects, not arbitrary application accounts.
4697 records service installation and 4698 scheduled-task creation in Security. 1102 records Security-log clearing. System 7045 is a separate Service Control Manager source for service installation.
Verify effective audit policy, host role, event version and forwarding. Keep actor and session context. A cleared log and failed forwarding are different observations; this table is selected guidance, not a complete event inventory.
Sysmon
Use the Sysmon event reference and record the installed version and configuration hash. Useful event families include process creation (1), network connections (3), driver/image loads (6/7), remote threads (8), process access (10), file creation (11), registry changes (12–14), pipes (17/18), DNS (22) and supported process-tampering observations (25).
Collection and filtering determine availability. Image-load events do not guarantee coverage of manual mapping. Event 8's inferred start-module/function fields can be empty; an empty field or parser-generated Unknown is not proof of shellcode. Likewise an unresolved event-10 call trace is not proof of injected code. Named pipes associated with tooling are leads, not immutable tool identities.
Text equivalent and full-size diagram
A documented event type is not proof that your sensor generates, forwards or retains it. Test the actual configuration before claiming detection coverage.
Event 1: process creation, including ProcessGuid and command line. Event 3: process-linked TCP/UDP network connections. Events 6 and 7: driver and image loads.
Event 8: CreateRemoteThread, with potentially empty inferred start-module/function fields. Event 10: process access, with access rights and available call trace. Event 11: file creation or overwrite.
Events 12–14: registry object creation/deletion, value setting and renaming. Events 17/18: named-pipe creation/connection. Event 22: DNS queries. Event 25: supported process-image tampering observations.
Record the installed version and configuration hash. Exercise inclusion and exclusion filters; inspect actual network and image-load records rather than assuming availability.
The ten grouped rows are a selection. Correlate process identity, host role and timing; missing metadata, unfamiliar pipes or a single access event are investigation leads, not automatic attack verdicts.
EDR Platforms
EDR can supply process, file, memory, identity and network evidence that raw audit logs lack. Preserve raw event IDs, sensor health, event times, host identity and detection provenance. Vendor-reported capabilities and detections must remain labeled as such; this research does not rank products, reproduce proprietary models, or guarantee built-in alert names and licensing.
For example, Microsoft documents DeviceProcessEvents as an advanced-hunting table. Confirm the available columns and ingestion before porting a process-lineage analytic. Exact sensor-event counts, proprietary model inventories and unsupported release-year claims have been removed from the operational guidance. Microsoft table reference.
Text equivalent and full-size diagram
A table name or vendor alert does not establish complete telemetry or a confirmed intrusion. Missing fields must remain unknown, not silently fabricated.
Conceptual workflow: sensor observations become hunting records, which support analyst review and testing of competing explanations. This is not a ranking of EDR products.
The image lists DeviceId and Timestamp for context, plus ProcessUniqueId and InitiatingProcessUniqueId for process correlation. They are Microsoft schema examples, not universal field names.
Key clarification: ReportId is a repeating counter. Microsoft documents using it together with DeviceName and Timestamp for unique event identification. Do not deduplicate solely by ReportId, DeviceId plus time, or a process-instance identifier.
Confirm sensor deployment, health, retention and actual populated columns. Scope process-lineage joins to the correct device and time; ordinary process IDs can be reused. Preserve the original source record and distinguish vendor detection from the analyst’s finding.
Network Detection and Response
For Zeek, record sensor placement, packet loss, version, loaded scripts and packages. dns.log uses TTLs, not TTL; conn.log provides directional connection metadata. TLS, certificate, file-hash and fingerprint fields depend on analyzers and configuration. JA3/JA3S are not guaranteed stock fields in every ssl.log. Zeek DNS schema, Zeek TLS logging.
TLS-extension randomization weakens order-sensitive JA3 stability for affected browsers. JA4 addresses extension-order sensitivity, but neither fingerprint is an actor identity or proof of malware; libraries are shared and fingerprints can be imitated. Record the implementation and normalize consistently before comparing sensors. Cloudflare's JA4 explanation.
Text equivalent and full-size diagram
Placement, packet loss and encryption constrain visibility. Connection metadata alone cannot reveal encrypted application payloads or establish estate-wide coverage.
The monitored path runs from a client or service, through a network link, to a destination. A TAP/SPAN copy feeds a Zeek sensor; traffic need not pass through the sensor itself.
conn.log supplies directional connection metadata; dns.log supplies available queries, answers and TTLs; ssl.log supplies observable TLS metadata. Missing fields must be interpreted against the analyzer and event schema.
Record sensor placement, packet loss, Zeek version, scripts and packages. Certificates, hashes and fingerprints are not guaranteed in every protocol or configuration.
Shared libraries, client changes and imitation limit fingerprint attribution. The supplied notes reference the moving master DNS page; the caption links the verified 8.2.1 DNS reference and 8.2.0 TLS reference instead of claiming one universal schema.
Identity and Access Management Platforms
Entra risk detections mix behavioral analytics, threat intelligence, leaked credentials and user reporting. Do not describe every detection as an anomaly model or every denied MFA challenge as a user fraud report. Verify the actual detection type, licensing, configuration and retained events. Entra risk catalog.
Okta's catalog includes user.mfa.factor.update, user.session.impersonation.initiate and user.account.privilege.grant. Their identifiers are not invented. Interpret outcome, reason, factor, actor and target together; a generic failure does not establish MFA fatigue. Okta event catalog.
Text equivalent and full-size diagram
Approved support, recovery and privilege changes can produce similar records. Validate the tenant, session, configuration and retained events before correlating activity.
Interpret the actor, action and result, and target together: who performed the action, what succeeded or failed, and whose state changed.
Okta examples: user.mfa.factor.update concerns factor updates; user.session.impersonation.initiate concerns starting an impersonation session; user.account.privilege.grant concerns changes to a user’s administrative privileges.
Retain the literal event type, outcome, reason, actor, target and available session keys. Correlate within the correct tenant, identity and bounded time; inspect approved support and role changes.
Entra detections are not all statistical anomaly models. A denied MFA prompt and an explicit user report are distinct, and a generic authentication failure does not demonstrate an MFA-fatigue attack. Local licensing, collection and retention still need verification.
Cloud Security Services
Cloud analytics require the relevant accounts, regions, event categories and resource-level logging. A control-plane log does not automatically contain every data access. Provider-native detections may use context unavailable in exported logs; a local reproduction must declare that difference.
AWS documentation inconsistency: GuardDuty lists GenerateDbAuthToken among credential-access anomalous APIs, while RDS states that CloudTrail does not track token generation. Preserve both statements rather than calling the article's vendor citation invented or assuming an observable CloudTrail event. This revision does not implement a detector dependent on that event. GuardDuty IAM findings, RDS IAM authentication limitations.
Sentinel anomaly rules provide deviations for investigation and correlation. Use the selected template's documented requirements rather than asserting a universal learning period or assuming that an anomaly is an incident. Sentinel anomaly-rule guidance.
Text equivalent and full-size diagram
A native finding is not a raw audit record. No cloud account was exercised here, and no detector dependent on the disputed token-generation event was implemented.
Three separate evidence streams: configuration and management activity; resource-level access and actions; provider-generated findings. Validate each stream independently.
Scope accounts, regions, resources, categories and delivery. CloudTrail data events require explicit collection choices; a management log is not automatically a full record of data access.
Provider-native analytics may use context absent from exported logs. A local query cannot claim to reproduce that proprietary context without evidence.
Documentation boundary: the GuardDuty IAM finding reference names GenerateDbAuthToken, while the RDS IAM-authentication limitations say CloudTrail does not track token generation. Both statements were located during this review; the implementation does not resolve them by inventing a raw event.
DNS Security
Full DNS labels allow lexical analysis. Resolver logs, endpoint DNS events and network sensors observe different parts of the path; caches, encryption and collection gaps affect coverage. Specify whether the metric concerns a leftmost label, all labels below a registrable domain, or the entire name. A public-suffix-aware parser is required if the analytic groups by registrable domain.
Shannon Entropy for DNS Anomaly Detection
Empirical character entropy is H = -sum(p(c) * log2(p(c))), in bits per character. It measures the symbol-frequency distribution, not semantic randomness or maliciousness. For a label of length n over alphabet A, its upper bound is log2(min(n, |A|)). A short word's low maximum entropy does not calibrate a cutoff for a long encoded label; a structured sequence with distinct characters can have high empirical entropy.
Normalize casing and label selection, handle internationalized names explicitly, and test legitimate encoded names. Section 8's implementation is an ASCII-label feature extractor, not a tunneling verdict. No SUNBURST-specific entropy range or universal alert threshold is claimed.
Text equivalent and full-size diagram
For nonempty labels of length n over alphabet A, H ≤ log₂(min(n, |A|)). This bound and the three examples do not establish a useful tunneling detector.
The plotted quantity is empirical character-frequency entropy: H = −Σ p(c) log₂ p(c), measured in bits per character. All three illustrated labels contain four characters.
aaaa: one symbol with probability 1, giving 0 bits per character. abab: two equally frequent symbols, giving 1. abcd: four equally frequent symbols, giving 2. The last label is plainly structured despite its higher value.
Choose which label or labels to score before analysis. Normalize case, handle internationalized names explicitly, use public-suffix-aware parsing for registrable-domain grouping, and keep length alongside entropy.
Resolver, endpoint and network logs observe different parts of DNS activity. Caching and encrypted DNS can limit particular observation points. Include legitimate encoded-name controls; this is not a SUNBURST-specific entropy range or universal maliciousness cutoff.
[
{
"label": "aaaa",
"value": 0
},
{
"label": "abab",
"value": 1
},
{
"label": "abcd",
"value": 2
}
]SaaS Audit Logs
Separate event counts, distinct objects, records and bytes. The example below counts download audit events; it does not infer bytes from OfficeObjectId. If authoritative object sizes or transfer counters are available, document that separate enrichment and its limitations.
For Microsoft 365, verify workload auditing and retention for operations such as MailItemsAccessed, FileDownloaded and FileSyncDownloadedFull. Current mailbox auditing must not inherit historical licensing assumptions. Application grants and service-principal activity may require Entra audit data in addition to workload logs. Mailbox investigation guidance, OfficeActivity schema.
Text equivalent and full-size diagram
Deduplicate evidence records separately from counting objects. Quantify bytes only from validated counters or explicitly qualified enrichment, retaining unknown values.
Illustrative records E1, E2 and E3 each have operation FileDownloaded and object identifier A. The event identifiers are distinct; the object identifier is shared.
The resulting counts are 3 audit events and 1 distinct object. Transferred bytes are unknown. The example does not establish three full transfers, one full transfer, or zero transferred bytes.
Verify MailItemsAccessed, FileDownloaded and FileSyncDownloadedFull against their workload’s auditing and retention. The figure’s O1 schema source is supplemented here with the operation catalog and mailbox guidance.
Keep record identity, object identity and units separate. Entra application-consent and service-principal evidence may complement workload logs. Validate transfer counters or document the limits of size enrichment rather than treating an identifier as a size.
{
"records": [
{
"illustrative_event_id": "E1",
"operation": "FileDownloaded",
"object_id": "A"
},
{
"illustrative_event_id": "E2",
"operation": "FileDownloaded",
"object_id": "A"
},
{
"illustrative_event_id": "E3",
"operation": "FileDownloaded",
"object_id": "A"
}
],
"audit_events": 3,
"distinct_objects": 1,
"transferred_bytes": null,
"unknown_is_not_zero": true
}Detection Source Prioritization Matrix
Unmeasured fidelity ratings have been replaced with a planning matrix. No universal deployment order is implied.
| Decision | Evidence to collect before choosing |
|---|---|
| Which source closes an important visibility gap? | Threat model, important assets and currently missing behaviors |
| Can the proposed fields actually be collected? | Raw samples, policy, sensor health, schema and license verification |
| Can operations sustain the source? | Measured volume, storage/retention, privacy needs and ownership |
| Does the analytic add value? | Held-out alerts, legitimate workload controls, missed cases and analyst workload |
| Is prioritization justified? | Local benefit and cost, not a vendor name or an unsupported High/Medium/Low score |
Text equivalent and full-size diagram
Pilot a defined use case, measure local costs and outcomes, and assign collection ownership. A numbered planning row is not a calibrated priority score.
Visibility gap: identify important assets, the threat model and currently unobserved behavior. Collectability: obtain raw samples and verify policy, schema, sensor health and required entitlements.
Operational fit: measure volume, retention needs, privacy requirements and ownership. Analytic value: examine held-out candidates, benign controls, missed cases and analyst workload.
Priority justification: record local benefit and cost without unsupported source-fidelity ratings. The five numbered questions are not a vendor ranking or mandatory deployment order.
Pilot one defined use case on important assets before scaling. Include ordinary workload changes and known misses; measure retained evidence and review effort. Assign an owner and recurring health check while documenting remaining blind spots.