Scenario Solution · E-ITDR
Credential abuse and
lateral movement defense
Once one endpoint falls, the attacker usually works with real accounts and the tools the operating system already ships: the process is legitimate, the credential is legitimate, the command is legitimate. E-ITDR starts from identity behaviour, reconstructs the path across hosts, and acts only where authorisation allows.
The Problem
After an endpoint falls, the movement usually looks legitimate
Once an attacker holds one machine, what follows is mostly real accounts and the tools the operating system already provides: remote execution, scheduled tasks, directory queries. A product that judges whether a file is malicious or a process abnormal sees almost nothing but normal work in this stretch.
Where It Applies
Confirm the environment before discussing coverage
Detection depends on collection, and collection depends on the environment. The items below are worth confirming one by one before deployment — they decide whether a given rule can actually see anything in your estate.
| Item | Scope | To confirm before deployment |
|---|---|---|
| Endpoint platforms | Windows and Linux (including domestic Linux) workstations and servers | Version, kernel and distribution differences are adapted separately |
| Identity environment | A domain is the typical case, but not the only one | Directory version, authentication method and log visibility |
| Collection prerequisites | Agent running on a supported endpoint | Run-time permissions, whether audit policy is on, which collectors are enabled |
| Existing security products | Runs alongside a deployed EDR; nothing needs to be removed | Verify coexistence, resource usage and policy compatibility in the pilot |
| Deployment form | On-premises; data stays inside the enterprise | Platform resources, network reachability, whether a relay is needed |
| Response conditions | Authorised commands are executed by the endpoint agent, which reports status | Role permissions, approval flow, agent online status |
Cloud identity directories are not covered. This solution watches identity behaviour on the endpoint and complements IAM-class systems rather than taking over accounts and entitlements in a cloud directory. Protection at web and API entry points belongs to the other product line — see business access and identity protection.
The size of the rule catalogue is the size of a catalogue and does not mean every rule is enabled on every platform. What is actually visible depends on the platform, the collection level, run-time permissions, audit policy and log visibility. Windows primarily uses authentication, process and network events; Linux protocol fingerprinting and general file monitoring coverage are not promised on Windows. No performance figures are given; measure in a pilot environment.
How It Works
What lateral movement leaves at the identity layer
An attacker can change tools, payloads and communication channels. But using someone else's privilege to reach another machine requires a credential, and using a credential leaves traces in authentication and identity. The chain below is organised around that.
| What happens in this stretch | What it leaves at the identity layer | Related rule domain |
|---|---|---|
| Taking credentials on the compromised host | Abnormal access to credential stores and process memory; a directory service receiving a replication request that host should never make | Credential access · AD CS |
| Authenticating with what was taken | One credential appearing across several hosts in a short window; tickets requested or aged in unusual ways; authentication chains that downgrade or relay | Kerberos and authentication · NTLM and relay |
| Executing across hosts | Execution started through a remote service, judged together with the initiating identity, the target's importance and delegation settings | Delegation and lateral movement |
| Gaining a foothold on the target | Services and scheduled tasks created, autostart and registry changes, preload and SUID changes on Linux | Persistence · defense evasion and destruction |
| Access and egress | File access records and outbound connections, placed on the same timeline as the authentication and movement before them | Web and network behaviour · file investigation |
A structural illustration, not a product screenshot. A line is not causation: how complete the correlation is depends on collection scope and log visibility, and gaps are marked as gaps rather than inferred away. The table is also not a fixed attack order, and detecting these behaviours does not attribute them uniquely to one tool or one group.
Division of Responsibility
Complementary to EDR, and most final actions live elsewhere
Keep the EDR you have for breadth; this solution adds identity depth on the endpoint. The table sets out that split, along with the actions that must be carried out by someone else.
| Step | E-ITDR | Handled by existing systems |
|---|---|---|
| Malware detection and removal | Not done here | EDR / anti-virus: file detection and removal |
| Endpoint process and behaviour baselines | Looks at processes and connections related to identity | EDR: general process and behaviour detection |
| Credential activity and authentication anomalies | Detects credential access, ticket anomalies and authentication chain problems | Usually no system owns this — it is the layer added here |
| Reconstructing a cross-host path | Correlates by account, host and time to reconstruct the suspected path | SIEM: cross-system log aggregation and unified triage |
| Host isolation and process action | Executed by the agent under authorisation and approval, with status reported | Whether to execute is decided by the incident response process |
| Disabling accounts and resetting passwords | Not executed on your behalf | IAM / PAM / directory services |
| Network blocking and perimeter policy | Not executed on your behalf | Firewall / NDR / network team |
| Backup and restore | Not executed on your behalf | Backup systems and the business teams |
"Not executed on your behalf" is not a missing feature but a boundary of responsibility: disabling an account, blocking a segment or restoring data all affect the business directly and belong to the owner of that system, inside their own process. What this solution owes them is a clear account of the grounds and the scope of impact.
Rollout
Start where it matters, expand on the result
Get collection and detection working on a set of critical servers and representative workstations first, confirm that this kind of evidence holds up in your environment, and only then talk about scale. Each stage has something to hand over.
- Pick critical servers and representative workstations
- Confirm permissions, audit policy and collector settings
- Validate detection and evidence against agreed scenarios
- Extend to remaining servers and workstations
- Confirm adaptation per platform and distribution
- Mark what collection still does not cover
- Send alerts to SIEM or the ticketing system
- Review coexistence with the existing EDR
- Agree the authorisation path for response actions
- Enable, disable and scope rules
- Review collection health and chase the gaps
- Re-test as new scenarios come up
How long each stage takes depends on endpoint count, change windows and approval flow; no fixed schedule is promised. Close the collection gaps from the previous stage before expanding — widening the scope while gaps remain only enlarges the part you cannot see.
Validation
Validate against an agreed scenario, within authorisation
Scenario validation checks three things: whether this class of behaviour is detected, whether the evidence supports the conclusion, and whether a response can be executed and reviewed. Scope and timing are agreed by both sides in advance.
This site does not publish complete operating commands and carries out no live attack execution; the steps above exist to help agree an authorised test scope with the customer. A receipt may say success, failure or timeout, and success does not mean the threat is gone.
Agree the scenarios, the start and end times, the evidence standard and the operating conditions before the pilot. No detection-rate figures are reported until testing is complete, and no single detection-rate number is used as an acceptance criterion. What the demonstration environment shows is a product demonstration scenario, not any customer's actual incident record.
Expert Consultation
Agree on one lateral movement scenario and check detection against it
Tell us about your endpoint mix, domain environment and existing security products, and we will demonstrate detection for the techniques you name, list the collection prerequisites and state what each response action requires:
Collection prerequisites
Permissions, audit policy, collector settings
Scenario-based demonstration
Alerts and evidence for techniques you name
Response boundaries
What the platform does and what other systems must do
Scan with Feishu to consult