Entity boundaries

Primary vs. secondary

The first call Scope makes is splitting Subjectโ€™s Entity A person, system, or organization that interacts with or affects a security incident. map into two tiers. The split is what makes investigation depth proportional to evidence rather than spending equal time on every identity in the graph.

Primary

Entities directly implicated by the alert. The user whose account fired the alert. The host that produced the telemetry. The service account that authenticated the action. The cloud resource the action targeted. Primary entities receive full investigation depth: every dimension, every available data source, the full historical window the threat type warrants.

Secondary

Entities connected to the primary set but not directly named in the alert. Peer accounts that share a trust path. Systems the primary entities have access to. Parent services that issued credentials. Secondary entities receive baseline-comparison depth: are they behaving normally? They are investigated more thoroughly only if a primary investigation surfaces them.


๐Ÿ”ด Primary entities by type

Primary entities require immediate, rigorous scrutiny. They are the foundation for everything Uncover will do, and capturing volatile or early-stage evidence depends on getting their scoping right at this moment. Four common categories cover most cases.

USER ACCOUNT

๐Ÿ‘ค User accounts

Often the initial access vector via credential theft or phishing. Once inside, attackers use the account to escalate and move laterally.

  • Analyze authentication patterns: geolocation, time anomalies, login spikes.
  • Review group membership changes, role escalations, MFA resets.
  • Investigate use of remote execution tools (PowerShell, PsExec).
  • Correlate access attempts with sensitive resource interactions.
COMPROMISED ENDPOINT

๐Ÿ’ป Endpoints

Execution platforms for malware, persistence mechanisms, and attacker tooling. Often hold key forensic artifacts that reveal intrusion methods.

  • Examine process trees and parent-child anomalies.
  • Inspect file system and registry paths for persistence (Startup, %APPDATA%).
  • Check for unauthorized services, scheduled tasks, local admin creation.
  • Analyze outbound traffic and DNS queries for C2 activity.
CLOUD RESOURCES

โ˜๏ธ Cloud resources

Common target for privilege escalation, data access, and persistence via misconfigurations or stolen credentials. Abnormal API usage is often the first sign.

  • Investigate IAM changes: user/role creation, key usage, permission escalation.
  • Audit bucket and compute resource policies for unauthorized changes.
  • Review CloudTrail, Azure Activity Logs, GCP audit logs for suspicious behavior.
  • Monitor for exfiltration via storage, automation misuse, or unusual geographies.
APPLICATIONS

โš™๏ธ Applications

Compromised via vulnerabilities, misconfigured APIs, or weak authentication. Often act as pivot points to backend systems and data.

  • Examine logs for injection attempts, RCE indicators, auth bypasses.
  • Audit admin interface activity and role/permission changes.
  • Review session tokens and API key behavior.
  • Correlate frontend activity with backend database or storage access.

๐ŸŽฏ Tiering high-value entities

Not every primary entity carries the same weight. Three tiers of โ€œhigh-valueโ€ entities deserve elevated attention from the moment they appear in the investigation.

TIER 0

Crown-jewel infrastructure

Domain controllers (DC01, DC02), cloud control planes (AWS Organizations management account), security vaults (HashiCorp Vault instances, Azure Key Vault). Compromise at this tier has organization-wide blast radius.

BUSINESS CRITICAL

Revenue and operations systems

Finance applications (SAP, payment gateways), HR platforms (Workday, ADP), healthcare systems (Epic EHR, PACS servers). Direct impact on business operations and regulated data.

PRIVILEGED

Administrative identities

Enterprise Admins group members, cloud IAM roles with iam:* permissions, database sa accounts. Capability to bypass controls and rewrite the security posture itself.


๐ŸŒฟ Scope evolution: the decision tree

Entity scope is not a one-time decision. It evolves as evidence develops. The evolution should follow a structured, documented pattern.

IF

Compromised workstation accessed shared file drive \\fileserver\finance\

THEN

Incorporate fileserver into scope. Pull access logs, file modification history, share-permission changes.

IF

User authenticated to VPN within 48 hours of compromise

THEN

Examine MFA logs and add VPN concentrators to scope. Validate session origin, device fingerprint, and concurrent-session behavior.

IF

PowerShell remoting was enabled on the endpoint

THEN

Include WinRM configuration and Event ID 4688 process-creation events in scope. Look for cross-host script invocation.

IF

Service account assumed a cloud role during the relevant window

THEN

Add the cloud role and all resources it can touch to scope. Review STS AssumeRole call patterns against the roleโ€™s normal usage.


๐Ÿ”— Secondary entities: three modeling techniques

Secondary entities are not in the alert. They get into scope through analysis of the operational topology and identity fabric. Three techniques surface them in a structured way.

๐Ÿ—บ๏ธ Relationship mapping

Document technical trust relationships: Active Directory two-way trusts, privileged service accounts with elevated access, AWS cross-account roles, Kubernetes service-account tokens. These reveal potential compromise paths the alert did not directly name.

๐Ÿ”‘ Access modeling

Identify all identities with access during the relevant timeframe: contractors with SSO access, DevOps engineers with privileged cloud roles, recently-terminated employees with lingering credentials. The access model is the immediate-blast-radius estimate.

๐Ÿ”— Dependency tracing

Analyze data flows and credential pathways: automated synchronization jobs, cached authentication tickets, cross-account access mechanisms, hardcoded API credentials. Dependencies turn a single compromised identity into a network of potentially-affected systems.

Prioritizing secondary entities during triage

Not every secondary entity deserves equal attention. Assess each one against proximity and likely adversary goals:

  • Immediate-priority secondaries. Direct management, authentication, or automation ties to a compromised entity. (A service account that authenticates against the same identity provider. A peer in the same AD security group.)
  • Mid-priority secondaries. Trust relationships that bridge to higher-value systems. (Cross-account IAM roles. Federated SAML trusts. Shared service principals.)
  • Distal secondaries. Shared Infrastructure The underlying systems, networks, and architecture that support an organization's operations. nodes or vendor-managed services. Assess based on exposure level, Credential Whatever the system accepts as proof of identity: a password, an API key, an OAuth token, a Kerberos ticket, an NTLM hash. Credentials are the highest-value loot in most intrusions; their theft is usually the pivot point. reuse, and control boundaries. Often watched, not investigated, unless a closer signal pulls them in.

Documenting this tiering keeps Uncover from spreading effort evenly across a long list and instead drives focused work where the methodology says the risk lives.


Containment and the entity scope

Entity scope informs Containment The incident-response phase between detection and eradication: isolate the affected hosts, revoke the compromised credentials, block the C2 destinations, freeze the situation so it stops getting worse while the investigation continues. decisions, and containment carries its own dependency risks. Isolating a host or disabling an account can break business operations as collateral.

๐Ÿ”Œ Host isolation

Pulling a host from the network stops the compromise but interrupts any production work the host was doing. Validate dependencies before isolating: scheduled jobs, shared services, real-time workloads.

๐Ÿ”’ Account disable

Disabling a service account can break automation pipelines, sync jobs, or production deployments. Check what depends on the account before disabling; have a rollback plan.

๐Ÿšช Credential rotation

Rotating an API key invalidates every consumer of that key. For shared keys, the rotation needs a coordinated cutover across all consumers, or pre-staged replacement credentials.

๐Ÿ“› DNS/firewall block

Blocking a domain or IP range can stop C2 but may also block legitimate traffic if the indicator is reused infrastructure (cloud-CDN edge IPs, shared SaaS hosts). Validate uniqueness before blocking.

Next up

Infrastructure boundaries

What the SOC can actually see. Network segments, cloud accounts, geography, retention, and tooling.

Read infrastructure