← All hunts high TLP:CLEAR

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

  1. Identify authoritative IDP sign-ins

    Query · scoping

    Narrow the hunt to users and source IPs associated with successful logins through authoritative identity providers.

    reads hb_auth_signinsql
    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')

    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.

  2. Auth process DNS to proxy domains

    Query · detection candidate

    Detect DNS queries for proxy infrastructure originating specifically from authentication-related processes like lsass.exe or securityd.

    reads hb_dns_activitysql
    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')

    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.

  3. Rare source IP logins

    Query · baseline

    Stack-rank source IPs for successful logins to identify anomalous or new locations for authoritative users.

    reads hb_auth_signinsql
    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

    What a hit looks like. IPs that have successfully authenticated only a few users. Silence suggests all logins come from known, high-prevalence infrastructure.

  4. Triage early obfuscation and identity

    Agent triage

    Correlate proxy-related DNS activity with IDP sign-ins to find potentially compromised sessions.

  5. Pivot to rare admin connections

    Query · baseline

    Identify outbound connections to internal networks on administrative ports that are rare across the fleet.

    reads hb_network_connectionsql
    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

    What a hit looks like. Internal administrative access (SSH, RDP, SMB) performed by a small number of hosts, suggesting lateral movement rather than routine noise.

  6. Rare local context execution

    Query · baseline

    Identify process execution in a 'local' user context that is rare across the fleet, avoiding hardcoded user names.

    reads hb_process_activitysql
    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

    What 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.

  7. Synthesize full intrusion chain

    Agent triage

    Connect the early obfuscation results with the subsequent internal access and execution activity.

  8. Route on intrusion verdict

    Decision

    Direct the response based on the synthesis of the multi-stage evidence and temporal correlation.

  9. Isolate suspect host

    Response action

    Contain the potentially compromised beachhead to prevent further lateral movement.

  10. Analyst forensic review

    Analyst task

    Verify the findings and investigate the extent of the local entity activity.

  11. Close out and reporting

    Analyst task

    Finalize the investigation and document the observed entity identifiers.

Coverage

Scenario coverage

StageCoveredHow, 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

ParameterTypeDefaultWhat it is
admin_portslist[string]22, 445, 3389, 5985Administrative ports associated with lateral movement.
auth_providerslist[string]okta, entra_id, microsoft_365, active_directoryAuthoritative identity providers to monitor.
lookback_daysnumber14Days of history to examine.
proxy_indicatorslist[domain]tunnel.us.ngrok.com, tunnel.eu.ngrok.com, onion.city, onion.direct, hiddenservice.net, onion.ca, onion.cab, onion.casaProxy and tunneling domains identified in the research.
scope_hostslist[host]Specific hostnames to focus on for the follow-on phase.

Telemetry

SourceCategoryTelemetry
Endpoint telemetry (hb_ surfaces)endpointendpoint
Identity / sign-in telemetryidentityidentity
Network telemetrynetworknetwork

Source

Download hunt.md Definition (JSON) An open hunt.md file; it runs anywhere that reads the format.
---
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.