ASSURED
Quick reference

Telemetry sources

About 22 min read

On this page
Uncover: Data sources Field reference

The per-source detail behind the Data sources pillar. Read the pillar first: it starts from the question and names the first source to try. Come here when you need to know what one source records, when to reach for it, and where it goes blind.

Start from the question, not this list

On a live case, the question-to-source table and the blind-spot summary are faster. Default retention by source is on the pillar too: typical default retention. Vendor defaults change, so verify every retention and logging default in your own tenant. Export before containment or the calendar destroys it: Preserve before you contain.

The sources at a glance

SIEM alerts and correlations

The alert layer the SIEM builds on top of the other sources.

EDR logs

Process creation, command lines, file changes at the endpoint level.

OS audit logs and host artifacts

Windows Security and Sysmon, auditd, macOS logs; Prefetch and Amcache.

Network traffic

NetFlow, DNS, proxy, firewall, IDS. What the wire saw.

Remote access and edge

VPN, ZTNA and SSE, firewall and gateway system logs.

WAF, CDN and web server

Request-level records for public-facing applications.

Identity and access

Authentication, SSO, role assumption, privilege grants.

Cloud activity

CloudTrail, Azure Activity, GCP audit. API and configuration.

SaaS audit logs

Mailbox rules, file sharing, OAuth consents inside each tenant.

Kubernetes audit

API-server events: exec, secret reads, RBAC changes.

Developer platform and CI/CD

Source control, pipelines, package publishing, secret scanning.

AI assistant and agent logs

Interaction events, tool calls, connectors and scopes.

Threat intelligence

IOCs and TTPs from external sources. Hypothesis fuel.

Vulnerability & patch

What is exposed, what is exploited in the wild, what is patched.

File integrity (FIM)

Changes to critical files and configs against a baseline.

Email security

Inbound/outbound mail metadata, attachment scanning, URL rewriting.

Application & database

Row-level access, query history, business-logic evidence.

Asset, configuration & IP

What exists, who owns it, which host held which IP.

Data loss prevention

What sensitive data moved where.

Deception

Honeypot interactions: high-confidence adversary signal.

Backup & snapshot

When systems were last clean. Sabotage detection too.

Physical security

Badge swipes, camera events. Location corroboration.

SIEM alerts and correlated detections

The alert layer: the detections and correlation-rule outputs the Security Information and Event Management (SIEM) The platform that collects, normalizes and searches log data from many sources and runs correlation rules over it. Most alerts reach triage through it, and most Uncover queries run in it. It sees only its intake: a source never onboarded, or rolled off retention, is a gap, not a clean result. raises from the sources below, plus the alerts that IDS/IPS and other security products forward to it. This is usually where the case starts, and it shows what else fired around the same entity and window. The raw firewall, proxy and IDS device logs behind those alerts are covered under network traffic.

When to use

  • Establishing the initial alert trail and identifying upstream/downstream events.
  • Grouping related alerts on the same entity and window into one case.
  • Reviewing the rule’s fidelity history and triage metadata.
  • Building a first-pass timeline across security products.

Limitations

  • Alert volume includes significant noise and false positives; the rule’s history tells you how much.
  • An alert is a summary. The SIEM often keeps only the fields the rule needed, so go to the underlying source for the full event.
  • Ingestion lag and silent sources create timing gaps: a source that stopped sending looks the same as a quiet one.

Endpoint detection and response logs

EDR platforms monitor Endpoint A device that runs an operating system and applications and connects to the network: workstation, laptop, server, virtual machine, phone, tablet. Endpoints are where execution-based tradecraft (malware, scripts, hands-on-keyboard commands) shows up, which is why EDR exists. Identity, SaaS and cloud-control-plane attacks, and attacks on network appliances that cannot run EDR, may never touch one, so endpoint silence is not proof of absence. activity in real time. Process creation, parent-child relationships, registry changes, file system activity, network connections, memory execution. This data lets analysts reconstruct attacker behavior at a granular level, from initial execution to Lateral Movement Moving from the initial foothold to other hosts, identities or tenants to find sensitive data or reach higher-value targets (ATT&CK tactic TA0008). It usually rides legitimate remote-access protocols (RDP, SMB, WinRM, SSH) with stolen credentials, or replays a stolen session into a cloud or SaaS tenant, so the signal is an account authenticating where it does not normally go. Each hop widens the blast radius, and confirmed lateral movement is an escalation criterion. and Persistence The ATT&CK tactic for keeping access across reboots, updates and password changes. Mature actors plant several anchors: Run keys, scheduled tasks, services, WMI event subscriptions, and in the cloud, OAuth apps and added MFA methods. .

Key EDR data points
  • Process execution with full command-line arguments
  • Parent-child Process Relationships How processes on a host connect: parent and child, the user each runs as, the handles and pipes they share. Most endpoint verdicts turn on lineage, such as an Office application spawning a shell. See Process relationships. and process-tree visualization
  • File creation, modification, and deletion events
  • Registry modifications and persistence-mechanism creation
  • Network connection attempts with destination information
  • Memory manipulation and code-injection attempts
  • User account activity and privilege-elevation events

When to use

  • Identifying execution chains and suspicious child processes.
  • Detecting unauthorized file modifications or malicious payloads.
  • Investigating persistence mechanisms or privilege misuse.
  • Reconstructing attack timelines at the endpoint level.
  • Validating suspicious network connections seen in other logs.

Limitations

  • Requires an agent: unmanaged and BYOD endpoints have little or no coverage.
  • Legitimate binaries abused by attackers ( LOLBins Living Off the Land Binaries: trusted, signed system executables (certutil, rundll32, mshta) weaponized so the malicious part is the argument line, not the file on disk. The evasion face of the Living Off The Land technique covered under Execution. such as rundll32, mshta, certutil, regsvr32) are recorded but often not flagged: they blend into normal activity unless hunted for.
  • Sensors can be disabled or blinded (EDR-killer tools, vulnerable-driver abuse; ATT&CK T1685). Check sensor health for the whole window before treating silence as absence; the dry-thread checks walk through it.
  • Console retention is often days to weeks depending on license; export what the case needs early.

Operating-system audit logs and host artifacts

The operating system’s own logging, and the traces it leaves on disk. This is the evidence when EDR is absent, blinded, or out of retention. On Windows: the Security event log and, where someone deployed it, Sysmon Microsoft Sysinternals service that writes detailed endpoint telemetry (process creation with command lines, network connections, driver and DLL loads, file-time changes) to the Windows event log for SIEM ingestion. Now also a built-in optional feature on Windows 11 and Server 2025 (rendered messages are localized, so parse the XML); Sysmon for Linux exists too. . On Linux: auditd and journald. On macOS: the unified log and Endpoint Security events. Host artifacts (Prefetch, Amcache, ShimCache, SRUM on Windows) can show that a program was present, and often that it ran, after the event logs have rolled over.

Event IDs worth knowing
  • Windows Security 4624 and 4625: successful and failed logon (the logon type separates interactive, network, and remote sessions)
  • Windows Security 4688: process creation (the command line is recorded only if the audit policy enables it)
  • Windows Security 1102: the Security log was cleared
  • Windows System 7045: a service was installed
  • PowerShell 4104: script block logging
  • Sysmon 1 (process creation), 3 (network connection), 22 (DNS query)
  • Linux auditd execve records; macOS Endpoint Security exec and authentication events

When to use

  • Confirming execution on a host with no EDR, or outside the EDR’s retention.
  • Reading the logon type and source behind a host-level sign-in.
  • Finding service installs and scheduled tasks created for persistence.
  • Cross-checking EDR on a host whose sensor may have been tampered with.

Limitations

  • Audit policy is thin by default: 4688 command-line capture is off, and Sysmon is not installed unless someone deployed it.
  • Local logs roll over within days on a busy host unless they are forwarded.
  • Attackers clear these logs (ATT&CK T1685.005, Clear Windows Event Logs). A gap, or a 1102 event, is itself evidence.

Network traffic and communication logs

Network telemetry covers how data moves across internal and external environments: NetFlow Cisco's flow-export format: per-connection metadata (5-tuple, bytes, packets, timestamps) without payloads. Standardized as IPFIX (RFC 7011); cloud equivalents are AWS VPC Flow Logs, Azure VNet flow logs and GCP VPC Flow Logs. , DNS, full packet capture (PCAP), proxy and web gateway logs, and the device logs of firewalls and IDS/IPS sensors. Analysts use it to trace lateral movement, identify C2 channels, detect Beaconing Periodic network communication from an infected host to a C2 server. Legitimate software beacons too (updaters, telemetry and EDR agents), so baseline known-good cadences before you pivot. , and examine Data Exfiltration Deliberate and unauthorized transfer of data from a system or network to an external location (ATT&CK tactic TA0010). The covert routes, sometimes called data leakage channels, include the C2 channel itself, cloud storage, DNS tunneling and other protocol tunnels; each has its own entry on this page. . Network logs matter most where endpoint telemetry is missing or untrustworthy: unmanaged, BYOD, IoT and OT devices, network and edge appliances that cannot run an agent, and hosts whose sensor has been disabled or subverted. They also give the cross-host view. A DGA pattern or a beacon schedule is often clearest when resolver or proxy logs show it across the whole fleet.

When to use

  • Tracing the source or destination of suspicious traffic.
  • Detecting exfiltration techniques (DNS tunneling, HTTPS uploads).
  • Correlating DNS or proxy logs to identify attacker infrastructure.
  • Mapping lateral movement patterns across the network.
  • Identifying beaconing or periodic communication indicative of C2.

Limitations

  • Full PCAP is storage-intensive; retention is often short.
  • TLS encryption obscures payload content without decryption. Encrypted DNS (DoH/DoT) and Encrypted Client Hello also hide the domain names DNS and proxy logs rely on, so expect less SNI and resolver visibility over time. TLS fingerprints (JA4) and flow metadata remain.
  • Cloud and remote-work traffic that never crosses a corporate sensor is invisible here.
  • High-volume environments sample flows, so a short connection may be missing.

Remote access and edge appliances

VPN concentrators, ZTNA and SSE services, and the system logs of the firewalls and gateways themselves. Exploitation of internet-facing systems, very often edge devices, leads current breach reporting as an initial-access vector (vulnerability exploitation is 31% in Verizon’s 2026 DBIR and exploits are 32% in M-Trends 2026), and these appliances rarely run EDR. Their logs are frequently the only record of who connected from outside, from where, and what the appliance itself did.

When to use

  • Tying a remote session to a user, a source IP, and the internal address the appliance assigned.
  • Checking remote sign-ins for unfamiliar locations, devices, or posture failures.
  • Looking for appliance compromise: configuration changes, new admin accounts, crashes or unexpected processes, outbound connections from the appliance itself.
  • Establishing when a known-exploited vulnerability on the device was first hit.

Limitations

  • Appliance logs often live in small rolling buffers on the device and are not forwarded by default.
  • A compromised appliance can edit or suppress its own logs; the vendor’s integrity-check tool and external flow data are the cross-check.
  • Fields vary by vendor and firmware, and the assigned internal IP (the join key to everything else) is the field most often missing.

WAF, CDN and web-server access logs

Request-level records for public-facing applications: the web application firewall’s verdicts, the CDN’s edge logs, and the web server’s own access log. Exploitation of a public-facing application (ATT&CK T1190) leaves its probing here first: scanning paths, injection payloads, unusual methods, and the one request that returned a 200 where the rest returned errors.

When to use

  • Finding probing and exploitation attempts against a public application.
  • Identifying the first request that succeeded, and the source behind it.
  • Tying a web shell or new file on the server back to the request that planted it.
  • Scoping which sources and user agents hit the vulnerable path.

Limitations

  • Many WAFs log only blocked requests by default, so the allowed request that succeeded may be missing.
  • Request bodies are rarely logged: a POST-based payload shows only its path and size.
  • Behind a CDN or load balancer, the client IP is in a forwarded header, not the connection source.

User identity and access management logs

Logs from identity providers (Active Directory, Okta Identity platform with SSO, MFA, lifecycle management, and federation across thousands of apps. , Microsoft Entra ID (formerly Azure AD) Microsoft's cloud identity provider: SSO, MFA, Conditional Access. Triage evidence lives in the sign-in logs (interactive and non-interactive), audit logs, and Microsoft Entra ID Protection risk detections. ), SSO platforms, MFA systems, and directory services. They record login attempts, access denials, role escalations, password resets and token activity. This source is critical for account compromise, Password Spraying Trying a small number of common passwords against many accounts to avoid lockouts. , session hijacking, and unauthorized access. The cloud and identity parsing page covers reading a sign-in record.

User authentication

Login attempts, successes, failures, lockouts across identity systems. Reveals brute force or credential stuffing.

Privilege management

Role assignments, permission changes, elevation requests. The path of any privilege-escalation attempt.

MFA activities

Enrollment, verification, bypass attempts. The trail of sophisticated account-takeover tactics.

Session management

Token issuance, validation, expiration. Helps detect token theft and session manipulation.

When to use

  • Validating whether access to sensitive systems was legitimate.
  • Detecting anomalies (logins at odd hours or unfamiliar locations).
  • Investigating failed authentication, lockouts, or MFA bypass.
  • Tracking privilege escalation across user accounts.
  • Correlating identity events with endpoint and network activity.

Limitations

  • Non-interactive and service-principal sign-ins live in separate logs (Entra) and are often not forwarded; check both before concluding a token was not used.
  • The log shows authentication, not what the session did afterward. That lives in the SaaS and cloud audit logs.
  • Federated and hybrid setups split one sign-in across several logs (on-premises AD, the federation service, the cloud IdP).
  • Retention can be as short as 7 days; see the retention table.

Cloud activity and configuration logs

Cloud-native logs: AWS CloudTrail Records API activity in an AWS account: the audit trail for security and forensic work. Management events are on by default (90 days in Event history); data events such as S3 object reads and Lambda invokes must be enabled on a trail or event data store. , Azure Activity Logs, GCP Audit Logs. API calls, configuration changes, login activity, resource provisioning. Foundational for detecting cloud misconfigurations, account abuse, Privilege Escalation The ATT&CK tactic for gaining higher permissions: on the endpoint, standard user to admin to SYSTEM; in the directory or cloud, a regular account to domain admin or a privileged cloud role. , and exposure of cloud storage or compute.

When to use

  • Tracking IAM changes (user/role creation, key usage, permission escalation).
  • Auditing bucket and compute resource policies.
  • Investigating provisioning of new cloud resources.
  • Detecting exfiltration through cloud storage or automation.
  • Reconstructing actions across multiple cloud accounts.

Limitations

  • Control-plane audit logs are on by default but limited: CloudTrail Event history keeps 90 days of management events per Region and account, Azure’s Activity Log keeps 90 days, and GCP Admin Activity audit logs are always written and kept for 400 days. Data-plane logs (S3 and other CloudTrail data events, GCP Data Access logs other than BigQuery, Azure resource logs) stay off until someone enables them, and longer retention or cross-account search needs a trail, event data store, or export.
  • Interpretation requires familiarity with each provider’s services and API names.
  • Rapid provisioning and teardown complicate timeline reconstruction: the resource may be gone before the alert is read.

SaaS audit logs

Every sanctioned SaaS tenant keeps its own audit trail: the Microsoft 365 unified audit log, Google Workspace audit logs, and the per-app equivalents in Salesforce, Slack, GitHub, and the rest. This is where tenant-level attacker behavior lives: inbox rules created, files shared or mass-downloaded, OAuth applications granted consent, admin settings changed. For a business-email-compromise or token-theft case, this source is the investigation.

When to use

  • Reconstructing what a hijacked session actually did after the IdP alert: mailbox rules, delegations, sharing changes.
  • Investigating OAuth consent abuse: which app was granted which scopes, by whom, when.
  • Detecting exfiltration through sharing links, mass downloads, or third-party sync apps.
  • Auditing admin and configuration changes inside the tenant.
  • Scoping a compromise across every user who touched the same attacker artifact (rule name, app ID, sharing target).

Limitations

  • Audit depth is often license-gated; the events you need most may require the premium tier.
  • Ingestion lag of minutes to hours between the action and its appearance in the log.
  • Default retention is short unless deliberately extended or forwarded to the SIEM.
  • Every app logs in its own schema; cross-app correlation is manual without normalization.
  • Only sanctioned tenants are covered. Shadow SaaS produces no audit trail you can reach.

The identity chain is the join

SaaS audit events rarely share a host or PID with anything. They join to the rest of the case through the identity chain: the user, the session ID, and the source IP and user agent the IdP recorded at sign-in. The cloud and identity parsing page covers reading that chain.

Kubernetes audit logs

The Kubernetes The dominant container orchestration platform and an attack surface in its own right: exposed API servers, over-permissioned service account tokens, and container escapes can turn one compromised workload into a path across the cluster. Analysts meet it through Kubernetes audit logs and runtime telemetry, where short-lived pods complicate reconstructing what was running when an alert fired. API server can record every request it handles: who ran kubectl exec into which pod, who read which secret, what changed in RBAC, which workloads were created and from which images. Paired with container runtime telemetry, this is the visibility layer for cluster-native attacks that never touch a traditional endpoint.

When to use

  • Investigating suspected service-account token theft: what did the token do, from which source address?
  • Tracing interactive access into workloads: exec, attach, and port-forward events.
  • Auditing secret reads and RBAC changes around a suspected escalation.
  • Spotting unusual workload creation: cryptominers, privileged pods, unfamiliar images.
  • Reconstructing what a compromised CI/CD credential deployed and when.

Limitations

  • Audit logging is off or minimal by default in many distributions; the policy has to be configured before the incident.
  • Volume at scale is enormous; unfiltered policies overwhelm storage and search.
  • Pods are ephemeral: names and IPs recycle in minutes, so capture has to be fast and joins need the pod UID.
  • The API server sees control-plane actions only; in-container process activity needs a runtime sensor.
  • Managed offerings expose different subsets of the audit stream with different retention. EKS control-plane audit logging is off until someone enables it per cluster, and AKS needs a diagnostic setting; GKE writes Admin Activity audit logs by default.

Developer platform and CI/CD telemetry

Source-control, pipeline and package-registry audit trails: GitHub or GitLab audit logs, workflow and runner logs, package publish events on registries such as npm and PyPI, and secret-scanning alerts. Supply-chain intrusions such as the 2025 Shai-Hulud npm worm run through this layer, and the code they plant later executes inside signed, trusted processes on developer endpoints and build servers.

When to use

  • Tracing who changed a workflow, added a deploy key or token, or approved a merge.
  • Tying a malicious package version to the publish event and the credential that pushed it.
  • Finding which builds and hosts pulled a compromised dependency.
  • Checking secret-scanning hits for credentials an attacker could reuse.

Limitations

  • Audit depth and retention are plan-gated; enterprise tiers keep more.
  • Runner logs are often ephemeral and expire with the job.
  • What runs on the developer’s machine (IDE extensions, MCP servers, package-manager scripts) shows up only in endpoint telemetry, and a trusted signer and install path do not clear code running inside a signed host.

AI assistant and agent activity logs

Assistant interaction events (for example, Copilot interaction records in the Microsoft Purview audit log), cloud model-invocation logs, AI gateway and MCP gateway logs, and each agent’s connector inventory with the scopes it holds. When an AI agent is a subject of the case, this is where its actions and its data diet are recorded; see entity types and AI agents as subjects. When the agent is your own triage automation, the same logs are the audit trail for the governed automation tier, and governing automated triage samples its tool-call log as evidence for the logging gate.

When to use

  • Reconstructing what an assistant retrieved, generated, or did through its tools for a given user and session.
  • Checking whether a prompt-injection payload in a document or email preceded unexpected tool calls or outbound links.
  • Inventorying which connectors and scopes an agent held at the time.

Limitations

  • Logging is uneven and often license-gated; some tools record only that an interaction happened, not the prompt or the response.
  • Tool calls made by local agents or MCP servers on an endpoint may appear only in EDR process and network telemetry.
  • Prompt and response content can itself hold sensitive data, so access to it needs the same care as mailbox content.

Threat intelligence and IOC feeds

Structured data on known malicious indicators: domains, IPs, Hash A fixed-size value computed from data by a hash function. Cryptographic hashes (SHA-256) identify an exact file. Fuzzy and structural hashes (ssdeep, TLSH, imphash) find near-identical variants, which matters because one changed byte defeats an exact-hash IoC. MD5 and SHA-1 are broken for collisions, so pivot on SHA-256 where you can. , URLs. Commercial, community, or internal. Matching internal activity against these indicators lets analysts assess credibility quickly and link activity to known malware families or threat actors. This entry covers the feed as evidence; the discipline of using intel (indicator matching, attribution, TTP hunting, validation) is the threat-intelligence pillar, and the platform that operationalizes feeds is the TIP in the tool catalog.

Commercial providers offer curated, high-confidence indicators with context, at higher cost. Open-source feeds are broader but noisier. Industry ISACs deliver sector-specific intelligence. The best programs balance multiple sources and apply explicit validation. Treat threat intel as a hypothesis source, not a verdict.

When to use

  • Enriching indicators (hash, domain) with threat-actor attribution.
  • Prioritizing activity involving known malicious infrastructure.
  • Correlating internal observations with campaign data or bulletins.
  • Expanding searches via related indicators in the same campaign.

Limitations

  • Includes outdated or overused indicators (sandbox IPs, expired domains).
  • False positives from benign reuse of known infrastructure: shared hosting, reassigned cloud IPs.
  • Presence of an IOC does not confirm compromise; requires validation.

Vulnerability and patch management logs

Logs from scanners ( Qualys Cloud-based vulnerability management, policy compliance, and web app scanning across enterprise estates. , Tenable Vulnerability management vendor whose Nessus scanner underpins Tenable Vulnerability Management (cloud), Tenable Security Center (on-premises) and the Tenable One exposure platform. , Rapid7 InsightVM / Nexpose Rapid7's vulnerability management: Nexpose is the on-premises scanner, and InsightVM is the Insight-platform product built on it, with exploitability-based prioritization; pairs with Metasploit. Rapid7 now also sells Exposure Command. , now also packaged in Rapid7 Exposure Command) and patch management tooling: Microsoft Configuration Manager (ConfigMgr; formerly MECM and SCCM), Microsoft Intune, and WSUS (deprecated in September 2024 but still widely deployed, and still the engine under ConfigMgr’s software update point). They show exposed vulnerabilities, patch application status and security baselines. Paired with threat intelligence and exploit telemetry, they help identify at-risk systems and likely exploit vectors.

Key vulnerability data points
  • CVE identifiers and vulnerability descriptions
  • CVSS base and environmental scores (note whether v3.1 or v4.0; see CVSS adaptation for triage)
  • Exploitation evidence: CISA KEV listing, EPSS probability, public exploit or proof-of-concept availability
  • Affected software versions and components
  • Remediation status and patch application history
  • Asset exposure duration (time since vulnerability discovery)
  • Compensating controls and mitigation status

When to use

  • Determining if exploited CVEs are present in the environment.
  • Verifying which systems are unpatched or missing mitigations.
  • Identifying likely attack vectors based on known vulnerabilities.
  • Assessing exploitability of systems involved in incidents.

Limitations

  • Scan coverage may be incomplete or out of date: assets added since the last scan are missing.
  • Scanners report false positives, especially when they infer vulnerability from version banners and miss backported patches.
  • Patch status is not proof of safety: a host patched today may already have been exploited before the patch.
  • Freshly disclosed vulnerabilities appear only after the scanner’s checks catch up.

File integrity monitoring (FIM)

FIM tools record changes to files, directories, registry keys and configurations against a baseline; deciding whether a change was authorized means correlating it with change records. They are used to detect tampering with critical system files, injection of malicious binaries, or modification of application code.

When to use

  • Detecting unauthorized changes to system binaries or config files.
  • Identifying tampering attempts post-intrusion.
  • Confirming presence of malware implants or backdoors.
  • Tracking modifications to sensitive application code.
  • Validating whether critical security controls were disabled.

Limitations

  • Noisy if baselines are not tuned, especially on hosts that change often.
  • Does not distinguish legitimate from malicious changes; the change record does.
  • Blind to memory-only or fileless attacks.

Email security logs

Logs from Secure Email Gateways (SEGs), spam filters, and Phishing Deceptive messages (email, SMS, QR codes, chat apps, phone) that impersonate a trusted sender to steal credentials or session tokens or to get malware run. Modern kits proxy the real login page (adversary-in-the-middle) to capture the MFA-authenticated session cookie, so MFA alone does not stop them. Some lures skip credentials and get the user to paste a command into the Run dialog or a terminal. See AiTM Phishing, Device Code Phishing, Illicit Consent Grant and ClickFix. -detection platforms. Sender domains, attachment hashes, headers, click-through behavior on malicious links. Email is still one of the top initial-access vectors; these logs are invaluable for tracing the origin of many incidents.

The variant these logs are weakest against is the one that carries no payload. Business Email Compromise (BEC) Phishing's no-payload variant: an email impersonating an executive, vendor, or counterparty that asks the recipient to move money or change payment details. With no attachment to detonate and no link to rewrite, gateway verdicts stay quiet; the evidence lives in lookalike domains, display-name and reply-to mismatches, and hijacked threads sent from a compromised counterparty's real mailbox. Consistently among the costliest crime types by reported losses in the FBI IC3 Internet Crime Reports (about $3 billion in the 2025 report). and Pretexting Social engineering built on an invented scenario rather than a malicious payload: the caller claiming to be IT support, the "CEO" emailing about an urgent confidential deal, the vendor with new bank details. The pretext gives the target a plausible reason to comply. The delivery mechanism behind business email compromise and most voice phishing. ask the recipient to act, not to click: a wire transfer to updated account details, a payroll change, gift cards for the “CEO”. With no attachment to detonate and no URL to rewrite, the verdict fields stay quiet. Read these fields instead:

  • Authentication results on a lookalike domain: it passes SPF and DKIM for itself, so “pass” proves nothing about the brand it imitates.
  • Display-name or reply-to mismatch: a familiar name over an unfamiliar address, or replies routed somewhere else.
  • First-contact flag: a sender seen for the first time who claims an established relationship.
  • A reply inside a legitimate thread: the counterparty’s mailbox is compromised and the attacker answers in the real conversation (thread hijacking).

When the case smells like BEC, pivot next to the SaaS audit logs above for the inbox rules and sign-in anomalies that usually travel with it.

User reports are a second way into the same mail. A user-reported phishing case starts from the message the user forwarded, and these logs answer who else received it and who clicked. Any user who reached the credential step of a phishing kit is credential-exposed until the password is reset, sessions are revoked and MFA methods are reviewed.

Key email security data points
  • Sender information (email, domain, IP, Geolocation The process of determining the physical location of a device or IP address. IP geolocation is a database estimate, not a fact: mobile, VPN, residential-proxy and cloud egress addresses routinely map to the wrong city or country. Treat impossible-travel alerts as a prompt to check the ASN and device, not as proof. )
  • Authentication results (SPF, DKIM, DMARC)
  • Subject lines and content snippets
  • Attachment details (filename, type, size, hash)
  • Embedded URL information and reputation scores
  • User interaction data (opens, clicks, forwards, replies)
  • Detection verdicts and quarantine actions

When to use

  • Tracing suspected phishing campaigns or credential harvesting.
  • Investigating BEC and pretexting: authentication results, lookalike domains, reply-to divergence, thread hijacking.
  • Reviewing user interaction with malicious links or attachments.
  • Identifying every recipient of the same campaign.
  • Correlating email-based attacks with other security events.

Limitations

  • Limited visibility into content without sandboxing or deep inspection; encrypted attachments pass unread.
  • Mail that never crosses the gateway is invisible: internal-to-internal messages, including lateral phishing from a compromised mailbox (ATT&CK T1534, Internal Spearphishing), usually appear only in the tenant’s own message trace or in API-based integrated cloud email security (ICES) tools.
  • Sophisticated social engineering can lack obvious indicators.
  • Personal email on corporate devices is often invisible.

Application and database logs

Application and database logs offer visibility into use and abuse of business-critical systems. Transaction anomalies, privilege escalations, SQL Injection Code injection where crafted input changes the SQL query an application sends to its database, letting the attacker read or change data, bypass logins, and sometimes run commands on the database server. Prevented by parameterized queries; web application firewalls catch common payloads but not all of them. attempts, unauthorized queries. Particularly useful for investigating data breaches or access to sensitive records.

Authentication events

Login attempts, session management, role and permission changes, account lockouts, password resets.

Data access activities

Query execution, record CRUD operations, bulk exports, access to sensitive fields.

System operations

Configuration changes, backups and restores, schema modifications, integration API calls.

When to use

  • Investigating activity within custom or sensitive applications.
  • Detecting unauthorized queries or privilege escalation.
  • Confirming access to regulated or sensitive data sets.
  • Tracing the business impact of technical compromises.
  • Establishing evidence for breach notification or compliance.

Limitations

  • Logging is application-specific: check what the application actually records before relying on it.
  • Often not forwarded to the SIEM, so the application owner may have to pull it.
  • Verbose data-access logging is often off for performance, so reads of sensitive records may not be recorded at all.

Asset inventory, configuration and IP assignment

ServiceNow CMDB, Lansweeper IT asset discovery and inventory; CMDB foundations and continuous visibility into devices, software, and users. , AWS Config. Current and historical asset state: ownership, software versions, hardware specs, business functions. Analysts use these to assess Asset Criticality The level of importance or sensitivity of an asset, which determines the level of protection it requires. In ASSURED, asset criticality is one of the four RATM dimensions; with business impact it sets the impact axis (impact is the higher of the two). Score the highest-value asset in confirmed reach, not just the entry point. See the priority matrix. , validate baselines, and map IPs/hostnames to physical or virtual systems. DHCP leases and IPAM records belong here too: they answer the question every network-based alert eventually asks, which host held this IP at that moment.

Key asset data elements
  • System identifiers (hostname, IP, MAC, asset tag)
  • DHCP lease history (which MAC and hostname held which IP, and when)
  • Hardware specifications and physical location
  • Installed software inventory and versions
  • Operating system details and patch levels
  • Ownership and responsible teams
  • Business criticality and data classification
  • Network segment and security zone information
  • Relationships and dependencies with other systems

When to use

  • Identifying asset owners for follow-up or scope assessment.
  • Verifying whether a system is production, test, or abandoned.
  • Determining system criticality and potential business impact.
  • Resolving an IP to the host that held it at a specific time.

Limitations

  • CMDB entries go stale without regular maintenance, and untagged assets are missing entirely.
  • DHCP lease logs are often kept briefly on the DHCP server and not forwarded; once the history is gone, the IP cannot be tied to a host.
  • Limited visibility into cloud or shadow IT resources.

Data loss prevention (DLP)

DLP platforms monitor and control Sensitive Data Information whose exposure would cause harm: regulated data (personal data, PHI, cardholder data), credentials and keys, intellectual property, confidential business records. Regulated data plausibly accessed by the activity sets Scope's regulatory flags and is a Level 2 trigger; data merely in reach is a Scope flag. movement across endpoints, email, cloud, and network. They record when protected information (PII, intellectual property, source code, financial data) is accessed, transferred, or potentially exfiltrated.

Email DLP

Outbound email and attachment monitoring. Detects sensitive content leaving via corporate or personal mail channels.

Endpoint DLP

File operations, clipboard use, device transfers on workstations. Identifies unauthorized data handling at the user level.

Network DLP

Inspects traffic for sensitive content. Catches unauthorized transfers over web upload, FTP, or other protocols.

Cloud DLP

Monitors data movement to and between cloud services. Detects inappropriate sharing or storage of sensitive information.

When to use

  • Confirming whether sensitive data was accessed or exfiltrated.
  • Reviewing policy violations related to data movement.
  • Investigating unusual outbound transfers or clipboard use.
  • Assessing the scope and impact of data breaches.
  • Identifying unauthorized cloud-service usage.

Limitations

  • High false-positive rate from generic rule matching.
  • Can be bypassed by encrypted or obfuscated channels.
  • Limited visibility into unmanaged devices or networks.

Deception and honeypot logs

Deception platforms deploy decoys throughout the environment: fake credentials, deceptive files, memory lures, simulated services. Because these decoys have no business use, interaction with them strongly indicates malicious activity. The result is high-fidelity alerts with very few False Positive A detection-axis verdict: the alert's logic matched something it should not have, because the behavior the rule claims did not occur. ASSURED records two kinds: false positive (logic), a logic flaw or an over-broad pattern, and false positive (data), a parsing error, a missing field or bad telemetry. The fix is detection-side: tune, refine, or repair the data feed. Distinct from a benign true positive, where the behavior really happened but was authorized; that is never a false positive. Platform labels differ: Microsoft Sentinel's False Positive and Defender XDR's False positive mean this, while their Benign Positive and Informational, expected activity mean a benign true positive. . The benign hits that do occur come from vulnerability scanners, EDR and AV sweeps, and backup or inventory tools touching a decoy: benign true positives, which are excluded by source at deployment. This entry covers the logs those platforms emit; the platform capabilities, limitations, and vendor landscape live in the tool catalog.

Credential honeypots

Fake user accounts, tokens, or access keys. Triggered alerts on authentication use reveal credential harvesting or brute force.

System decoys

Simulated servers and workstations that appear legitimate. Detect lateral movement and reconnaissance with high confidence.

File lures

Deceptive documents with enticing names placed strategically. Identify data theft attempts and reveal attacker interests.

Application honeypots

Fake services that emulate production. Capture attacker techniques without risk to real assets.

When to use

  • Detecting lateral movement and credential harvesting.
  • Triggering high-fidelity alerts on credential reuse or scanning.
  • Assessing attacker intent through decoy interactions.
  • Gathering intelligence on attacker TTPs.

Limitations

  • Rarely deployed comprehensively, so a decoy that stayed quiet proves little.
  • Attackers may avoid honeypots if they suspect their presence; decoys need upkeep to stay believable.
  • Value against automation depends on targeting: indiscriminate automation (scanners, worms, ransomware sweeping SMB shares) trips decoys reliably, but automation aimed at known real assets (credential stuffing against a SaaS login, exploitation of one specific host) never touches them, and the intent and TTP intelligence from decoy interactions assumes a human operator.

Backup and snapshot metadata

Veeam Backup and recovery across virtual, physical, and cloud workloads with cloud-mobility options. , Druva SaaS-delivered data protection for endpoints (via the installed inSync client), SaaS apps such as Microsoft 365 and Google Workspace, and data center and cloud workloads; backups live in Druva's cloud rather than on customer-run backup storage. , AWS Backup, EBS snapshots, Azure disk snapshots. Backup metadata is both a forensic resource and a recovery lifeline. Investigators use it to establish historical context, to detect sabotage (deleted or encrypted backups, a common Ransomware Malware that encrypts a victim's files and demands payment for the key. Modern ransomware often adds data theft and extortion, and increasingly encrypts virtual machines from the hypervisor (ESXi) where endpoint agents cannot see it. Some groups skip encryption and extort on stolen data alone, so the absence of encrypted files does not rule out a ransomware-class incident. tactic), and to check whether backup repositories were accessed.

Key backup metadata elements
  • Backup job execution times and status
  • Systems and data included in each backup
  • Backup storage locations and retention periods
  • Verification and validation results
  • Access logs for backup management interfaces
  • Restoration testing activity
  • Modifications to backup policies or schedules

When to use

  • Confirming whether clean backups exist pre-compromise.
  • Detecting attempts to delete or encrypt backups.
  • Identifying forensic artifacts in historical snapshots.
  • Determining the earliest known clean state for affected systems.

Limitations

  • Visibility is limited to the systems and storage the backup actually protects.
  • Often managed by separate IT or operations teams; request access early in the case.
  • Metadata for cloud-based or offsite backups is often incomplete.

Physical security and access control logs

Badge swipes, biometric authentication, visitor records, video surveillance, secure-zone access. These logs add a dimension digital telemetry cannot. By establishing the physical location of individuals at specific times, they help validate or refute hypotheses about who performed certain actions.

Badge data and local sessions

If an interactive console logon happens on a workstation inside a badge-controlled area while the owner’s badge places them somewhere else, someone else probably used the credentials. That inference holds only for local, physical sessions: badge data says nothing about VPN or remote sessions, absence from the building is normal for hybrid staff, tailgating leaves no badge record, and an insider who shares credentials produces the same pattern. Treat the correlation as one input, and follow the insider-analysis guardrails (HR and legal involvement) before badge or video data enters a case.

When to use

  • Correlating console logon times with building entry logs.
  • Investigating physical theft or unauthorized access to secure areas.
  • Corroborating or contradicting where an account’s owner physically was when the account acted.

Limitations

  • Access is usually restricted: biometric and video records fall under privacy law (for example GDPR and Illinois BIPA) and employee agreements. Request them through the insider-analysis process with HR and legal rather than pulling them directly.
  • Often not real-time or centralized, and policies vary by facility.
  • Badge sharing and tailgating compromise accuracy.
← Data sources pillarField reference →

Technical details verified . Product names, defaults and retention change; check your own tenant.

Edit this page on GitHub Report a correction