Obfuscated Identity and Host Access
An adversary is using multi-hop proxies or tunnels to mask their origin during authentication to cloud identity providers, subsequently using that access to reach internal hosts and execute local commands.
Based on research by Elastic Security Labs 2026-09-20 12 steps · 5 queries T1021.001 T1059 T1078 T1090.003
Brief
Why this hunt
Adversaries often hide behind proxies to reach cloud-managed identity providers. This technique allows them to blend in with a global workforce and bypass geographic or IP-based restrictions. The recent research by Elastic Security Labs, titled How a team of entity maintainers monitors, connects and scores entities in Elastic Security (https://www.elastic.co/security-labs/blog/entity-resolution-identity-scoring-elastic-security), highlights how tracking entities requires connecting disparate identifiers. This hunt bridges the gap between network-level obfuscation and identity-level activity to find hidden threats.
Hunt Flow
The first phase uses the hb_auth_signin surface to identify successful logins. We scope the hunt to authoritative identity providers like Okta, Entra ID, or Microsoft 365. By identifying the source IPs and user names associated with these successes, we establish the foundation for our investigation. We focus on logins occurring within the last 14 days to capture active sessions and ignore stale data. The second phase runs two queries in parallel to identify signs of origin masking. One query monitors hb_dns_activity for requests to known tunneling domains such as ngrok or Tor hidden services. We specifically filter for these requests coming from sensitive authentication processes like lsass.exe or securityd. At the same time, we baseline hb_auth_signin to find source IPs that have authenticated only one or two unique users across the fleet. This identifies potential single-use proxy nodes that are not part of known corporate infrastructure or public carrier gateways. In the third phase, we pivot to internal activity using the hb_network_connection surface. We look for outbound connections from the hosts identified in the previous steps to internal IP addresses. We target common administrative ports such as SSH (22), RDP (3389), SMB (445), and WinRM (5985). By stacking these connections, we isolate activity that is rare across the environment, which helps us ignore routine administrative noise and focus on potential lateral movement from a suspect entry point. The final phase examines hb_process_activity for local command execution. We search for processes running in a local user context that are rare across the fleet. This identifies the use of shells or specialized tools that an adversary might use once they have established a beachhead. By correlating the timing of this execution with the earlier identity provider logins and proxy DNS activity, an analyst can confirm a full intrusion chain. The hunt uses an automated synthesis agent to verify if these events occurred within 60 minutes of each other.
Blind Spots
The hunt has two primary blind spots. First, it lacks context on MFA disposition. If a user successfully passes a strong hardware MFA challenge from a proxy IP, the activity might be legitimate remote work. Without this data in the hb_auth_signin surface, the hunt may produce false positives for remote employees in unusual locations. Second, short DNS retention periods can hide the initial connection to tunneling infrastructure if it occurred more than 14 days ago, breaking the correlation chain.
Steps
-
Identify authoritative IDP sign-ins
Query · scopingNarrow the hunt to users and source IPs associated with successful logins through authoritative identity providers.
reads hb_auth_signinsqlSELECT DISTINCT actor_user_name, provider, src_endpoint_ip, dst_endpoint_name, time FROM hb_auth_signin WHERE status_id = 1 AND instr(',' || '{{auth_providers}}' || ',', ',' || LOWER(provider) || ',') > 0 AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. A list of successful cloud/SaaS logins. This identifies the active identities and source IPs that form the basis of the hunt.
-
Auth process DNS to proxy domains
Query · detection candidateDetect DNS queries for proxy infrastructure originating specifically from authentication-related processes like lsass.exe or securityd.
reads hb_dns_activitysqlSELECT device_hostname, process_name, query_hostname, time FROM hb_dns_activity WHERE (LOWER(process_name) LIKE '%lsass.exe' OR LOWER(process_name) LIKE '%securityd') AND instr(',' || '{{proxy_indicators}}' || ',', ',' || LOWER(query_hostname) || ',') > 0 AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. DNS resolutions from sensitive processes to known proxy domains. This is a high-fidelity indicator of a host being used as a masked point of origin.
-
Rare source IP logins
Query · baselineStack-rank source IPs for successful logins to identify anomalous or new locations for authoritative users.
reads hb_auth_signinsqlSELECT src_endpoint_ip, COUNT(DISTINCT actor_user_name) AS user_count, COUNT(*) AS login_count, MIN(time) AS first_seen FROM hb_auth_signin WHERE status_id = 1 AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY src_endpoint_ip HAVING user_count <= 2 ORDER BY user_count ASCWhat a hit looks like. IPs that have successfully authenticated only a few users. Silence suggests all logins come from known, high-prevalence infrastructure.
-
Triage early obfuscation and identity
Agent triageCorrelate proxy-related DNS activity with IDP sign-ins to find potentially compromised sessions.
-
Pivot to rare admin connections
Query · baselineIdentify outbound connections to internal networks on administrative ports that are rare across the fleet.
reads hb_network_connectionsqlSELECT device_hostname, dst_endpoint_ip, dst_endpoint_port, COUNT(DISTINCT device_hostname) AS host_count, MIN(time) AS first_seen FROM hb_network_connection WHERE direction = 'outbound' AND instr(',' || '{{admin_ports}}' || ',', ',' || CAST(dst_endpoint_port AS TEXT) || ',') > 0 AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY dst_endpoint_ip, dst_endpoint_port HAVING host_count <= 3 ORDER BY host_count ASCWhat a hit looks like. Internal administrative access (SSH, RDP, SMB) performed by a small number of hosts, suggesting lateral movement rather than routine noise.
-
Rare local context execution
Query · baselineIdentify process execution in a 'local' user context that is rare across the fleet, avoiding hardcoded user names.
reads hb_process_activitysqlSELECT device_hostname, user_name, process_path, process_cmd_line, COUNT(DISTINCT device_hostname) AS host_count, MIN(time) AS first_seen FROM hb_process_activity WHERE (LOWER(user_name) LIKE '%local%') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY process_path, process_cmd_line HAVING host_count <= 3What a hit looks like. Shell or tool execution within a local context that is unique to a few hosts. This matches the behavior of a user with host-scoped local activity.
-
Synthesize full intrusion chain
Agent triageConnect the early obfuscation results with the subsequent internal access and execution activity.
-
Route on intrusion verdict
DecisionDirect the response based on the synthesis of the multi-stage evidence and temporal correlation.
-
Isolate suspect host
Response actionContain the potentially compromised beachhead to prevent further lateral movement.
-
Analyst forensic review
Analyst taskVerify the findings and investigate the extent of the local entity activity.
-
Close out and reporting
Analyst taskFinalize the investigation and document the observed entity identifiers.
Coverage
Scenario coverage
| Stage | Covered | How, or why not |
|---|---|---|
| Multi-hop Proxy and Tunneling T1090.003 |
Yes | proxy-dns-check |
| Identity Provider Authentication T1078 |
Yes | idp-auth-scoping, external-ip-prevalence |
| Access to Hosts and Services T1021.001 |
Yes | internal-access-pivot |
| Local Host Activity T1059 |
Yes | rare-local-execution |
Blind spots
- Needs hb_auth_signin with full MFA disposition. A login from a proxy might be benign if MFA is verified; without it, the hunt may over-alert on legitimate remote work. It would answer Was MFA challenged and satisfied for the suspicious login?.
- Needs hb_dns_activity with 30+ day retention. If the beachhead was established beyond the retention window, the proxy activity will be invisible, breaking the correlation chain. It would answer When was the tunneling infrastructure first contacted by this host?.
Parameters & data
Parameters
| Parameter | Type | Default | What it is |
|---|---|---|---|
admin_ports | list[string] | 22, 445, 3389, 5985 | Administrative ports associated with lateral movement. |
auth_providers | list[string] | okta, entra_id, microsoft_365, active_directory | Authoritative identity providers to monitor. |
lookback_days | number | 14 | Days of history to examine. |
proxy_indicators | list[domain] | tunnel.us.ngrok.com, tunnel.eu.ngrok.com, onion.city, onion.direct, hiddenservice.net, onion.ca, onion.cab, onion.casa | Proxy and tunneling domains identified in the research. |
scope_hosts | list[host] | — | Specific hostnames to focus on for the follow-on phase. |
Telemetry
| Source | Category | Telemetry |
|---|---|---|
| Endpoint telemetry (hb_ surfaces) | endpoint | endpoint |
| Identity / sign-in telemetry | identity | identity |
| Network telemetry | network | network |
Source
---
analysis: This hunt connects proxy-related DNS activity specifically from auth processes
to authoritative cloud sign-ins and subsequent rare internal movement, providing
the multi-plane context and temporal correlation needed to verify a breach that
single rules miss.
blind_spots:
- id: missing-auth-context
question: Was MFA challenged and satisfied for the suspicious login?
requires: hb_auth_signin with full MFA disposition
risk: A login from a proxy might be benign if MFA is verified; without it, the hunt
may over-alert on legitimate remote work.
stage: cloud-identity-authentication
- id: short-dns-retention
question: When was the tunneling infrastructure first contacted by this host?
requires: hb_dns_activity with 30+ day retention
risk: If the beachhead was established beyond the retention window, the proxy activity
will be invisible, breaking the correlation chain.
stage: proxy-tunneling-obfuscation
coverage:
- stage: proxy-tunneling-obfuscation
status: covered
steps:
- proxy-dns-check
- stage: cloud-identity-authentication
status: covered
steps:
- idp-auth-scoping
- external-ip-prevalence
- stage: internal-host-service-access
status: covered
steps:
- internal-access-pivot
- stage: endpoint-process-execution
status: covered
steps:
- rare-local-execution
guardrails:
claims: no_unsupported
evidence: citation_required
missing_data: not_benign
telemetry: untrusted
hunt:
applicability: campaign-specific
handoff: keep-as-periodic-hunt
justification: Adversaries use proxies to blend into administrative login traffic;
a phased hunt linking external obfuscation to internal access is required to distinguish
this activity from legitimate remote work.
methodology: model-assisted
trigger: intel-report
hypothesis: An adversary is using multi-hop proxies or tunnels to mask their origin
during authentication to cloud identity providers, subsequently using that access
to reach internal hosts and execute local commands.
labels:
- hunt
- attack.t1090.003
- attack.t1078
- attack.t1021.001
- attack.t1059
name: Obfuscated Identity and Host Access
parameters:
admin_ports:
default:
- '22'
- '445'
- '3389'
- '5985'
description: Administrative ports associated with lateral movement.
from:
kind: manual
observed: '2024-05-22'
ref: standard-admin-ports
type: list[string]
auth_providers:
default:
- okta
- entra_id
- microsoft_365
- active_directory
description: Authoritative identity providers to monitor.
from:
kind: article
observed: '2024-05-22'
ref: elastic-security-labs
type: list[string]
lookback_days:
default: '14'
description: Days of history to examine.
from:
kind: manual
observed: '2024-05-22'
ref: default
type: number
proxy_indicators:
default:
- tunnel.us.ngrok.com
- tunnel.eu.ngrok.com
- onion.city
- onion.direct
- hiddenservice.net
- onion.ca
- onion.cab
- onion.casa
description: Proxy and tunneling domains identified in the research.
from:
kind: article
observed: '2024-05-22'
ref: elastic-security-labs
type: list[domain]
scope_hosts:
default: []
description: Specific hostnames to focus on for the follow-on phase.
from:
kind: manual
observed: '2024-05-22'
ref: analyst-defined
type: list[host]
provenance:
authors:
- name: Huntbase hunt generation
org: huntbase.io
generated:
by: huntbase-hunt-generation
from: https://www.elastic.co/security-labs/blog/entity-resolution-identity-scoring-elastic-security
gates:
- dry-run
- lint
model: hb_google/gemini-3-flash-preview
rationale: Start with logins from authoritative providers (Okta, Entra ID) and focus
on source IPs that authenticate very few users. Widen the search if no tunneling
DNS matches are found initially.
references:
- name: How a team of entity maintainers monitors, connects and scores entities in
Elastic Security
url: https://www.elastic.co/security-labs/blog/entity-resolution-identity-scoring-elastic-security
related:
- hunt: internal-management-port-misuse
reason: Focuses on management protocol abuse without the origin-masking correlation.
relation: sibling
scenario:
stages:
- name: Multi-hop Proxy and Tunneling
observables:
- tunnel.us.ngrok.com
- tunnel.eu.ngrok.com
- .onion.city
- .onion.direct
- Tor exit nodes
slug: proxy-tunneling-obfuscation
tactic: command-and-control
techniques:
- T1090.003
- name: Identity Provider Authentication
observables:
- jane.doe@example.com
- okta
- entra_id
- microsoft_365
slug: cloud-identity-authentication
tactic: initial-access
techniques:
- T1078
- name: Access to Hosts and Services
observables:
- host:9f86d081-1e0c-4b3f-8a2d-2c1e7bed425e
- service:api-gateway
- host.name
- host.hostname
slug: internal-host-service-access
tactic: lateral-movement
techniques:
- T1021.001
- name: Local Host Activity
observables:
- user:jdoe@local
- process_cmd_line
- host.id
slug: endpoint-process-execution
tactic: execution
techniques:
- T1059
summary: The campaign involves an adversary utilizing multi-hop proxies and tunneling
services like ngrok or Tor to obfuscate their origin while authenticating to corporate
identity providers such as Okta or Entra ID. Once authenticated, the actor accesses
specific internal hosts and services, establishing a local presence that is tracked
through entity resolution and risk scoring.
severity: high
targets:
analyst:
name: Tier-2 analyst
role: analyst
endpoint:
category: endpoint
name: Endpoint telemetry (hb_ surfaces)
telemetry:
- endpoint
hunter:
agent: true
name: Hunt agent
identity:
category: identity
name: Identity / sign-in telemetry
telemetry:
- identity
network:
category: network
name: Network telemetry
telemetry:
- network
tlp: clear
type: investigation
---
# Obfuscated Identity and Host Access
This hunt correlates network obfuscation with identity provider authentication and subsequent internal host activity. It follows a phased flow: first, it identifies proxy usage by authentication processes and authoritative sign-in events from identity providers; second, it pivots to observe rare internal network connections on administrative ports and suspicious process execution in the local context. This traces the full chain from an external proxy-originating login to local host execution, providing the context necessary to distinguish a breach from normal administrative access.
## idp-auth-scoping
<!-- Identify authoritative IDP sign-ins -->
Narrow the hunt to users and source IPs associated with successful logins through authoritative identity providers.
```sqlite target=identity role=scoping params=(lookback_days=lookback_days, auth_providers=auth_providers)
~~~yaml
expected: A list of successful cloud/SaaS logins. This identifies the active identities
and source IPs that form the basis of the hunt.
reads:
- actor_user_name
- provider
- src_endpoint_ip
- dst_endpoint_name
- status_id
- time
silence: not_evidence_of_absence
source: hb_auth_signin
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT DISTINCT actor_user_name, provider, src_endpoint_ip, dst_endpoint_name, time FROM hb_auth_signin WHERE status_id = 1 AND instr(',' || '{{auth_providers}}' || ',', ',' || LOWER(provider) || ',') > 0 AND time >= datetime('now', '-{{lookback_days}} days')
```
## early-stage-parallel
<!-- Monitor proxies and login prevalence -->
parallel:
- → proxy-dns-check
- → external-ip-prevalence
join: → early-triage-agent
## proxy-dns-check
<!-- Auth process DNS to proxy domains -->
Detect DNS queries for proxy infrastructure originating specifically from authentication-related processes like lsass.exe or securityd.
```sqlite target=endpoint role=detection-candidate params=(lookback_days=lookback_days, proxy_indicators=proxy_indicators)
~~~yaml
expected: DNS resolutions from sensitive processes to known proxy domains. This is
a high-fidelity indicator of a host being used as a masked point of origin.
reads:
- device_hostname
- process_name
- query_hostname
- time
silence: not_evidence_of_absence
source: hb_dns_activity
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT device_hostname, process_name, query_hostname, time FROM hb_dns_activity WHERE (LOWER(process_name) LIKE '%lsass.exe' OR LOWER(process_name) LIKE '%securityd') AND instr(',' || '{{proxy_indicators}}' || ',', ',' || LOWER(query_hostname) || ',') > 0 AND time >= datetime('now', '-{{lookback_days}} days')
```
## external-ip-prevalence
<!-- Rare source IP logins -->
Stack-rank source IPs for successful logins to identify anomalous or new locations for authoritative users.
```sqlite target=identity role=baseline params=(lookback_days=lookback_days)
~~~yaml
baseline:
compare: first_seen
window: '{{lookback_days}}d'
expected: IPs that have successfully authenticated only a few users. Silence suggests
all logins come from known, high-prevalence infrastructure.
prevalence:
by: actor_user_name
key:
- src_endpoint_ip
rare_below: 3
reads:
- src_endpoint_ip
- actor_user_name
- status_id
- time
silence: not_evidence_of_absence
source: hb_auth_signin
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT src_endpoint_ip, COUNT(DISTINCT actor_user_name) AS user_count, COUNT(*) AS login_count, MIN(time) AS first_seen FROM hb_auth_signin WHERE status_id = 1 AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY src_endpoint_ip HAVING user_count <= 2 ORDER BY user_count ASC
```
## early-triage-agent
<!-- Triage early obfuscation and identity -->
```agent target=hunter
cite: required
context:
- idp-auth-scoping
- proxy-dns-check
- external-ip-prevalence
max_iterations: 4
objective: Determine if any identity provider login originated from a source IP associated
with proxy DNS activity or is otherwise anomalous within the scope.
success_criteria: The agent identifies high-risk logins and potential beachhead hosts
for the follow-on phase.
tools:
- endpoint
- identity
- network
```
## follow-on-parallel
<!-- Hunt follow-on access and execution -->
parallel:
- → internal-access-pivot
- → rare-local-execution
join: → phased-synthesis-agent
## internal-access-pivot
<!-- Pivot to rare admin connections -->
Identify outbound connections to internal networks on administrative ports that are rare across the fleet.
```sqlite target=network role=baseline params=(lookback_days=lookback_days, scope_hosts=scope_hosts, admin_ports=admin_ports)
~~~yaml
baseline:
compare: first_seen
window: '{{lookback_days}}d'
expected: Internal administrative access (SSH, RDP, SMB) performed by a small number
of hosts, suggesting lateral movement rather than routine noise.
prevalence:
by: device_hostname
key:
- dst_endpoint_ip
- dst_endpoint_port
rare_below: 3
reads:
- device_hostname
- dst_endpoint_ip
- dst_endpoint_port
- direction
- time
silence: not_evidence_of_absence
source: hb_network_connection
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT device_hostname, dst_endpoint_ip, dst_endpoint_port, COUNT(DISTINCT device_hostname) AS host_count, MIN(time) AS first_seen FROM hb_network_connection WHERE direction = 'outbound' AND instr(',' || '{{admin_ports}}' || ',', ',' || CAST(dst_endpoint_port AS TEXT) || ',') > 0 AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY dst_endpoint_ip, dst_endpoint_port HAVING host_count <= 3 ORDER BY host_count ASC
```
## rare-local-execution
<!-- Rare local context execution -->
Identify process execution in a 'local' user context that is rare across the fleet, avoiding hardcoded user names.
```sqlite target=endpoint role=baseline params=(lookback_days=lookback_days, scope_hosts=scope_hosts)
~~~yaml
baseline:
compare: first_seen
window: '{{lookback_days}}d'
expected: Shell or tool execution within a local context that is unique to a few hosts.
This matches the behavior of a user with host-scoped local activity.
prevalence:
by: device_hostname
key:
- process_path
- process_cmd_line
rare_below: 3
reads:
- device_hostname
- user_name
- process_path
- process_cmd_line
- time
silence: not_evidence_of_absence
source: hb_process_activity
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT device_hostname, user_name, process_path, process_cmd_line, COUNT(DISTINCT device_hostname) AS host_count, MIN(time) AS first_seen FROM hb_process_activity WHERE (LOWER(user_name) LIKE '%local%') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY process_path, process_cmd_line HAVING host_count <= 3
```
## phased-synthesis-agent
<!-- Synthesize full intrusion chain -->
```agent target=hunter
cite: required
context:
- early-triage-agent
- internal-access-pivot
- rare-local-execution
max_iterations: 5
objective: Determine if the rare internal connections and local shell execution constitute
a direct continuation of a suspect identity compromise. Specifically, verify if
the proxy-related DNS activity and the identity provider authentication occurred
within 60 minutes of each other.
success_criteria: The agent provides a verdict citing the timing and linkage between
network obfuscation, authentication, and internal activity.
tools:
- endpoint
- identity
- network
```
## route-decision
<!-- Route on intrusion verdict -->
if~: "the phased-synthesis-agent confirms a malicious intrusion where proxy-related DNS activity and identity provider authentication occur within 60 minutes of each other, followed by rare internal access or local execution" (confidence: high, judge=hunter)
then: → isolate-host
indeterminate: → analyst-review
unavailable: → analyst-review (blind_spot: missing-auth-context)
else: → analyst-review
## isolate-host
<!-- Isolate suspect host -->
```action target=endpoint
~~~yaml
approval: required
~~~
Isolate the host identified by the triage agent. Rotate credentials for the involved identity provider account and revoke any active OAuth sessions.
```
→ analyst-review
## analyst-review
<!-- Analyst forensic review -->
```manual target=analyst
Examine the process activity and network logs for the suspect hosts. Confirm if the local user execution aligns with the timing of the identity provider sign-in. Review the EUID derivation logic to see if multiple accounts were resolved into the same malicious actor.
```
→ close-out
## close-out
<!-- Close out and reporting -->
```manual target=analyst
Document the Entity Unique IDs (EUIDs) involved across providers. Record any tuning notes regarding the baseline of internal connections or local context execution. Provide feedback on proxy domain efficacy.
```
→ end
Run it
Take this hunt into your environment.
Open it in Huntbase to run every step against your own connections, with Scout weighing the evidence and your analysts in command. Or take the open hunt.md file anywhere that reads the format.
Machine-drafted by huntbase-hunt-generation using hb_google/gemini-3-flash-preview, gated by dry-run, lint, then reviewed by a person.