Product Capability · E-ITDR

Identity threat and
lateral movement detection

Once inside, an attacker usually works with real accounts and the tools the operating system already provides. E-ITDR looks at what that activity leaves behind at the identity layer: where credentials were accessed, whether the authentication chain is abnormal, and whether processes and connections fit how that identity normally behaves.

Request a demo Back to overview

Detection Signals

Four signals that together judge one suspicious move

Any one of them on its own can be routine administration. Only when credentials, authentication, execution and host changes are compared within the same identity context can “an admin at work” be told apart from “an attacker moving”.

Credential access

Abnormal access to the system credential store and to process memory, directory replication requests that should not come from this host, and unusual certificate or shadow-credential writes.

Rule domains: Credential Access · AD CS

Abnormal authentication

Correlates normal and anomalous system authentication to identify rapid credential reuse across hosts, unusual ticket requests or lifetimes, relay and downgrade patterns. Successful authentication still requires account and access-path context.

Rule domains: Kerberos · NTLM and relay

Remote execution

Cross-host execution started through remote services, judged together with the initiating identity, the target asset tier and delegation settings — not by whether the process itself is legitimate.

Rule domain: Delegation and lateral movement

Host-side signals

Correlates service, task, autostart and Linux host changes with WebShell file and process evidence and suspicious C2 connections to investigate persistence and attack activity.

Rule domains: Persistence · Web and network behaviour

Rule Domains

Detection rule domains and their mapped techniques

Rules are organised along the attack path, from obtaining credentials through to persistence and destruction. Each carries a stable identifier, version, severity, applicable scope, evidence fields and technique mapping.

Rule domain	Representative scenarios	Main ATT&CK techniques
Kerberos and authentication	AS-REP Roasting, Golden Ticket, Silver Ticket, Golden Key, PKINIT anomalies	T1558, T1649
Credential access	DCSync, LSASS Handle, NTDS / SAM export, Shadow Credentials	T1003, T1556
NTLM and relay	NTLM Relay, abnormal authentication chains and protocol delivery	T1557.001
AD CS	ESC1/2/3/4/6/7/8, CertiFried, certificate request and issuance anomalies	T1649
Delegation and lateral movement	Constrained and unconstrained delegation, RBCD, ZeroLogon, remote execution	T1134.001, T1210
Windows persistence	WMI Subscription, service abuse, scheduled tasks, autostart	T1053, T1546, T1543
Linux host	WebShell, preload, SUID, kernel modules, authentication anomalies, file tampering	T1505.003, T1547, T1548
Defence evasion and destruction	VSS / WBAdmin deletion, BCD tampering, wiper patterns	T1490, T1542.003, T1561.002
Web and network behaviour	WebShell file / hash / path / process, suspected C2 connections and protocol features	T1071, T1505.003
Agent and platform health	Collector failure, resource exhaustion, clock drift, degraded health	Detection prerequisites and data quality

These rules describe supported Windows and Linux scenarios; not every rule is enabled by default on every platform; what actually alerts depends on the platform, collection level, runtime permissions, audit policy and log visibility. The last domain watches whether collection itself is trustworthy — when collectors degrade, confidence in the other conclusions should degrade with them.

How Rules Run

From a single event to a conclusion that explains itself

Rules do more than match one event. Field combinations, time windows and multi-event relationships all take part, and the result is deduplicated and aggregated before it reaches investigation.

Single event

Field combination

Time window

Multi-event relation

Dedup and aggregate

Every rule has an identity

Stable identifier, version, severity, applicable scope, detection conditions, evidence fields and technique mapping. An investigation can answer “which rule fired and on what fields”, not just what the verdict was.

Updates keep versions and change records

After a rule changes, historical alerts still map to the version that was in force at the time. Otherwise one edit makes past events unexplainable and later review loses its baseline.

Available ≠ visible on every platform

A disabled collector, insufficient runtime permissions, an audit policy that was never switched on, or a blind spot on the network all create coverage differences for the same rule. Those differences are visible in collection health, not filled in by inference.

Platform Coverage

Windows and Linux do not draw on the same sources

The same class of signal comes from different system mechanisms on each platform, and the two are not at the same stage. Reading this table against your actual endpoint mix tells you more than a single headline number.

Signal source	Windows	Linux (distribution-specific adaptation)
Processes and parent-child	ETW, process collection	proc, eBPF / process collection
Logon, authentication, sessions	Security log, sessions and ETW	PAM / auth, auditd, sessions
Connections and interface changes	ETW network, periodic snapshots	Network collection, eBPF, interface snapshots
Services, tasks, persistence	Services, scheduled tasks, registry, WMI	systemd, services, autostart, preload
Files and integrity	Agent self-integrity; excludes general file monitoring	File tracking, file integrity, SUID / capabilities
Network protocol characteristics	Mainly ETW / network events; excludes Linux protocol fingerprints	TLS / JA3 / JA4, SSH / HASSH, HTTP, SMB, LDAP, MySQL, PostgreSQL

On Windows, TLS fingerprinting, HTTP side-channel analysis, SSH HASSH, general file-change monitoring and DNS event bridging are outside the current coverage described on this page. Domestic Linux distributions need separate adaptation for kernel, package manager, log paths and service manager; server testing does not substitute for desktop testing.

Alert Evidence

An alert has to explain itself

An alert is the entry point to an investigation, not its conclusion. These fields decide whether an analyst can judge what to do without opening three other systems.

Field	Content	What it is for
Rule and version	The rule matched, the version in force and its severity	Fixes the baseline for later review
Trigger	The combination of fields behind the verdict, not just the rule name	Judging a false positive
Technique	The corresponding ATT&CK technique ID	Aligning with existing threat models
Identity involved	Account, host, related processes and target asset	Determining scope and what to act on
Time and raw evidence	Event time and the original fields you can trace back to	Moving into path investigation
Collection state	Whether the relevant collectors were healthy in that window	Judging how far to trust the conclusion

A structural description, not a product screenshot. Actual fields vary by rule domain and product version; values in a demonstration environment come from a product demonstration scenario, not one customer's incident record.

Conditions & Boundaries

What this capability rests on, and what it does not do

Detection effectiveness is not a fixed number; it moves with the environment. Knowing the prerequisites is what makes a pilot check the right things.

Collection and permissions

The relevant collectors are enabled, and agent permissions and system audit policy meet what the rule domain needs.

Platform difference

Linux supports protocol characteristic analysis; Windows primarily uses authentication, process and network events. Check detection scope against actual collection capabilities.

How judgements are made

Driven by rules, protocol characteristics and threat intelligence, so a verdict can be explained and traced. No large language model inference engine.

Scope

Focused on identity behaviour at the endpoint. Cloud identity directories such as Entra ID and Okta are not covered; the product complements an existing IAM.

Detecting behaviour associated with a class of tooling does not confirm a specific actor or group; equally, a miss does not prove the behaviour is absent from the environment. Legitimate administration tools, shared infrastructure and common task names are not malicious on their own. We suggest checking coverage against agreed scenarios in a pilot rather than treating a detection-rate figure as an acceptance criterion.

What Comes Next

Related capabilities

The five capabilities share one body of evidence. Follow the investigation onward, or return to the overview.

Attack Investigation & Correlation

Capability 02

Authentication, processes and connections organised by time and object, reconstructing the path with gaps marked.

View capability

Asset Identity & Telemetry Management

Capability 05

Agent identity decoupled from network attributes, changes kept as snapshots, collection gaps visible as first-class data.

View capability

E-ITDR Product Overview

Product and deployment

Architecture, how the five capabilities divide the work, supported environments and boundaries.

Back to overview

Expert Consultation

Check coverage against one scenario from your own environment

Tell us about your endpoint mix, domain environment and existing security products, and we will demonstrate detection and list the collection prerequisites for the techniques you care about:

Collection prerequisites

Permissions, audit policy, collector settings

Scenario-based demonstration

Alerts and evidence for the techniques you name

Platform differences

What actually differs between Windows and Linux

Scan with Feishu to consult

Consultation +86 10 8071 6066

Business email services@wuthreat.com