Correlating Proxy-Obscured Identity and Endpoint Activity
An adversary is using multi-hop proxy infrastructure to authenticate via Okta and subsequently execute discovery commands on an endpoint, obscured by network egress to proxy relay ports.
Based on research by Red Canary 2026-09-21 12 steps · 5 queries T1059 T1078 T1090.003
Brief
Why this hunt
In the article How threat hunting evolves at scale (https://redcanary.com/blog/threat-detection/threat-hunting-scaled/), the author explains that effective hunting requires connecting disparate signals across the environment. This hunt targets identity obfuscation, a common tactic where adversaries use Tor or VPS proxies to mask their location during login. By correlating identity logs with endpoint-level DNS and process activity, we can confirm if a remote session is tied to unauthorized internal actions.
How the hunt flows
The first phase establishes a baseline by identifying successful Okta logins. The hunt scopes all authentication activity to provide a list of users and source IPs that accessed the environment during the lookback window. This step creates the pool of potential sessions for further analysis. The hunt then initiates two parallel enrichment steps. The first query searches DNS logs for any host resolving domains associated with proxy services like Tor. Simultaneously, the second query flags Okta logins coming from known proxy exit nodes or source IPs that are highly unique across the organization, typically appearing for three or fewer users. An analyst triages these findings by looking for a temporal overlap between a suspicious authentication event and proxy-related DNS resolution on a specific host. This link bridges the identity provider telemetry with host-based behavior, allowing the investigator to deanonymize the session origin. The follow-on phase gathers evidence of activity following the suspected compromise. The hunt queries for network egress to standard proxy ports like 9001 and 9050 and monitors for the execution of discovery tools like whoami, hostname, or ipconfig. This final layer of evidence confirms the full intrusion chain from login to execution.
What the hunt cannot see
This hunt has two primary blind spots. It cannot detect activity on unmanaged hosts where an EDR agent is missing, as there will be no process or network telemetry to correlate. Additionally, if the adversary uses a private or ephemeral proxy that has not been indexed by threat intelligence, the IP and DNS filters will not trigger.
Steps
-
Scope Okta Authentication Activity
Query · scopingEstablish a baseline of successful Okta logins to identify active users and potential beachhead IPs.
reads hb_auth_signinsqlSELECT actor_user_name, src_endpoint_ip, dst_endpoint_name, auth_protocol, time FROM hb_auth_signin WHERE provider = 'okta' AND status_id = 1 AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. A list of successful Okta logins. Silence indicates no Okta telemetry is available for the period.
-
DNS Resolutions for Proxy Infrastructure
Query · enrichmentDetect endpoints resolving domains associated with proxy services like Tor or onion routing.
reads hb_dns_activitysqlSELECT device_hostname, process_name, query_hostname, time FROM hb_dns_activity WHERE (instr(',' || '{{proxy_domains}}' || ',', ',' || LOWER(query_hostname) || ',') > 0 OR LOWER(query_hostname) LIKE '%.hiddenservice.net') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. Hosts resolving Tor-related domains. Silence suggests no active use of these proxy gateways via DNS.
-
Suspicious Okta Login Source IPs
Query · baselineIdentify Okta logins from known proxy IPs or IPs used by very few users across the fleet.
reads hb_auth_signinsqlSELECT src_endpoint_ip, COUNT(DISTINCT actor_user_name) AS user_count, COUNT(*) AS login_count FROM hb_auth_signin WHERE provider = 'okta' AND status_id = 1 AND (instr(',' || '{{proxy_ips}}' || ',', ',' || src_endpoint_ip || ',') > 0 OR src_endpoint_ip IN (SELECT src_endpoint_ip FROM hb_auth_signin WHERE provider = 'okta' GROUP BY src_endpoint_ip HAVING COUNT(DISTINCT actor_user_name) <= 3)) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY src_endpoint_ipWhat a hit looks like. Successful logins from known proxy exit nodes or highly unique IPs. Silence suggests no anomalous authentication source IPs.
-
Early Stage Evidence Triage
Agent triageCorrelate rare identity authentication events with endpoint proxy infrastructure resolution.
-
Network Egress to Proxy Relay Ports
Query · baselineDetect TCP connections to standard proxy ports like 9001 and 9050 that often signal Tor or multi-hop traffic.
reads hb_network_connectionsqlSELECT device_hostname, dst_endpoint_ip, dst_endpoint_port, process_name, time FROM hb_network_connection WHERE dst_endpoint_port IN (9001, 9050) AND protocol = 'tcp' AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. Established connections to proxy relay ports. Silence means no egress to these specific ports was observed.
-
Endpoint Discovery Command Execution
Query · detection candidateFind discovery commands executed on the host that correlate with the suspected proxy session.
reads hb_process_activitysqlSELECT device_hostname, user_name, process_name, process_cmd_line, time FROM hb_process_activity WHERE (instr(',' || '{{discovery_commands}}' || ',', ',' || LOWER(process_name) || ',') > 0 OR instr(',' || '{{discovery_commands}}' || ',', ',' || LOWER(process_cmd_line) || ',') > 0) AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. Process execution of common discovery tools. Silence suggests no discovery activity was logged.
-
Follow-on Evidence Triage
Agent triageFinalize the intrusion chain by linking the suspicious login to follow-on network and process activity.
-
Route Based on Intrusion Chain
DecisionDirect the hunt to containment if a full proxy-to-endpoint chain is confirmed.
-
Isolate Host and Revoke Identity
Response actionContain the threat by isolating the beachhead host and revoking compromised Okta sessions.
-
Analyst Final Validation
Analyst taskConfirm the findings and verify no lateral movement occurred.
-
Close Out and Record ROI
Analyst taskFinal documentation and performance metrics.
Coverage
Scenario coverage
| Stage | Covered | How, or why not |
|---|---|---|
| Proxy Infrastructure DNS Resolution T1090.003 |
Yes | dns-proxy-infra |
| Identity Authentication via Multi-hop Proxy T1078 · T1090.003 |
Yes | auth-suspicious-ips |
| Network Egress to Proxy Nodes T1090.003 |
Yes | network-proxy-egress |
| Identity-Correlated Process Execution T1059 |
Yes | endpoint-discovery |
Blind spots
- Needs hb_process_activity from all endpoints. An adversary could authenticate via proxy and access unmanaged infrastructure without detection. It would answer Did the user execute commands on hosts where no EDR agent is installed?.
- Needs Up-to-date threat intelligence on Tor exit nodes. Static IP lists will miss private relays or fresh VPS infrastructure. It would answer Was the authentication from a newly stood-up VPS not yet in our IP lists?.
Parameters & data
Parameters
| Parameter | Type | Default | What it is |
|---|---|---|---|
discovery_commands | list[string] | whoami, hostname, ipconfig, net user | Discovery commands often run by adversaries immediately after gaining access. |
lookback_days | number | 14 | Days of history to examine. |
proxy_domains | list[domain] | torproject.org, bridge.torproject.org, check.torproject.org | Known proxy infrastructure domains. |
proxy_ips | list[ip] | 185.220.101.0, 176.10.99.200 | Known Tor exit node or VPS IP addresses. |
scope_hosts | list[host] | — | Specific hostnames to narrow the hunt. |
Telemetry
| Source | Category | Telemetry |
|---|---|---|
| Endpoint telemetry (hb_ surfaces) | endpoint | endpoint |
| Identity / sign-in telemetry | identity | identity |
| Network telemetry | network | network |
Source
---
analysis: A single detection rule can trigger on a known Tor IP or a specific discovery
command, but it cannot verify if that IP was used for a successful Okta login that
then led to discovery activity on an internal host. This hunt pivots between Identity,
DNS, Network, and Process surfaces to confirm the behavioral link.
blind_spots:
- id: missing-endpoint-telemetry
question: Did the user execute commands on hosts where no EDR agent is installed?
requires: hb_process_activity from all endpoints
risk: An adversary could authenticate via proxy and access unmanaged infrastructure
without detection.
stage: endpoint-identity-execution
- id: ephemeral-proxy-nodes
question: Was the authentication from a newly stood-up VPS not yet in our IP lists?
requires: Up-to-date threat intelligence on Tor exit nodes
risk: Static IP lists will miss private relays or fresh VPS infrastructure.
stage: okta-authentication-via-proxy
coverage:
- stage: proxy-infrastructure-resolution
status: covered
steps:
- dns-proxy-infra
- stage: okta-authentication-via-proxy
status: covered
steps:
- auth-suspicious-ips
- stage: multi-hop-network-egress
status: covered
steps:
- network-proxy-egress
- stage: endpoint-identity-execution
status: covered
steps:
- endpoint-discovery
guardrails:
claims: no_unsupported
evidence: citation_required
missing_data: not_benign
telemetry: untrusted
hunt:
applicability: campaign-specific
handoff: keep-as-periodic-hunt
justification: Linking identity-provider events to specific host-based activity
is the primary way to deanonymize sessions arriving via multi-hop proxies; this
hunt provides that correlation across siloed telemetry surfaces.
methodology: model-assisted
trigger: intel-report
hypothesis: An adversary is using multi-hop proxy infrastructure to authenticate via
Okta and subsequently execute discovery commands on an endpoint, obscured by network
egress to proxy relay ports.
labels:
- hunt
- attack.t1090.003
- attack.t1078
- attack.t1059
name: Correlating Proxy-Obscured Identity and Endpoint Activity
parameters:
discovery_commands:
default:
- whoami
- hostname
- ipconfig
- net user
description: Discovery commands often run by adversaries immediately after gaining
access.
from:
kind: article
observed: '2026-06-11'
ref: red-canary
type: list[string]
lookback_days:
default: '14'
description: Days of history to examine.
type: number
proxy_domains:
default:
- torproject.org
- bridge.torproject.org
- check.torproject.org
description: Known proxy infrastructure domains.
from:
kind: article
observed: '2026-06-11'
ref: red-canary
type: list[domain]
proxy_ips:
default:
- 185.220.101.0
- 176.10.99.200
description: Known Tor exit node or VPS IP addresses.
from:
kind: manual
observed: '2026-06-11'
ref: threat-intel
type: list[ip]
scope_hosts:
default: []
description: Specific hostnames to narrow the hunt.
type: list[host]
provenance:
authors:
- name: Huntbase hunt generation
org: huntbase.io
generated:
by: huntbase-hunt-generation
from: https://redcanary.com/blog/threat-detection/threat-hunting-scaled/
gates:
- dry-run
- lint
model: hb_google/gemini-3-flash-preview
rationale: Start with high-privilege users in the Okta logs. Focus on authentication
events where the source IP does not match the user's typical office or VPN range.
references:
- name: "How threat hunting evolves at scale \u2014 Red Canary"
url: https://redcanary.com/blog/threat-detection/threat-hunting-scaled/
related:
- hunt: okta-mfa-fatigue-triage
reason: This hunt focuses on proxy-obscured source attribution rather than authentication
mechanism exploitation.
relation: out-of-scope-alternative
scenario:
stages:
- name: Proxy Infrastructure DNS Resolution
observables:
- 'query_hostname: torproject.org'
- 'query_hostname: *.hiddenservice.net'
- 'query_hostname: bridge.torproject.org'
slug: proxy-infrastructure-resolution
tactic: command-and-control
techniques:
- T1090.003
- name: Identity Authentication via Multi-hop Proxy
observables:
- src_endpoint_ip belonging to VPS or known Tor exit node ranges
- 'auth_protocol: SAML'
- 'auth_protocol: OAuth'
- 'provider: okta'
slug: okta-authentication-via-proxy
tactic: initial-access
techniques:
- T1078
- T1090.003
- name: Network Egress to Proxy Nodes
observables:
- 'dst_endpoint_port: 9001'
- 'dst_endpoint_port: 9050'
- 'dst_endpoint_ip: known Tor relays'
- 'protocol: tcp'
slug: multi-hop-network-egress
tactic: command-and-control
techniques:
- T1090.003
- name: Identity-Correlated Process Execution
observables:
- 'process_cmd_line: whoami'
- 'process_cmd_line: hostname'
- user_name matching actor_user_name from Okta authentication events
slug: endpoint-identity-execution
tactic: execution
techniques:
- T1059
summary: Adversaries leverage multi-hop proxies to obscure their origin while authenticating
to identity providers like Okta, subsequently performing unauthorized actions
on endpoints. Detection relies on the difficult task of correlating proxy-anonymized
sign-in events with subsequent host-level process and network telemetry.
severity: medium
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
---
# Correlating Proxy-Obscured Identity and Endpoint Activity
This hunt bridges identity telemetry with endpoint behavior to deanonymize sessions arriving through multi-hop proxies. It starts by identifying successful Okta logins and correlating them with hosts resolving known proxy infrastructure. The hunt then pivots to find network egress to standard proxy ports (9001, 9050) and the execution of post-authentication discovery commands on those same hosts. By linking these disparate surfaces, the analyst can identify compromised credentials even when the source IP is obscured.
## scope-okta-logins
<!-- Scope Okta Authentication Activity -->
Establish a baseline of successful Okta logins to identify active users and potential beachhead IPs.
```sqlite target=identity role=scoping params=(lookback_days=lookback_days)
~~~yaml
expected: A list of successful Okta logins. Silence indicates no Okta telemetry is
available for the period.
reads:
- actor_user_name
- auth_protocol
- dst_endpoint_name
- provider
- src_endpoint_ip
- status_id
- time
silence: not_evidence_of_absence
source: hb_auth_signin
verified: dry-run
verified_at: '2026-09-21'
~~~
SELECT actor_user_name, src_endpoint_ip, dst_endpoint_name, auth_protocol, time FROM hb_auth_signin WHERE provider = 'okta' AND status_id = 1 AND time >= datetime('now', '-{{lookback_days}} days')
```
## early-evidence-gathering
<!-- Parallel Early Evidence Gathering -->
parallel:
- → dns-proxy-infra
- → auth-suspicious-ips
join: → early-stage-triage
## dns-proxy-infra
<!-- DNS Resolutions for Proxy Infrastructure -->
Detect endpoints resolving domains associated with proxy services like Tor or onion routing.
```sqlite target=endpoint role=enrichment params=(proxy_domains=proxy_domains, scope_hosts=scope_hosts, lookback_days=lookback_days)
~~~yaml
expected: Hosts resolving Tor-related domains. Silence suggests no active use of these
proxy gateways via DNS.
reads:
- device_hostname
- process_name
- query_hostname
- time
silence: not_evidence_of_absence
source: hb_dns_activity
verified: dry-run
verified_at: '2026-09-21'
~~~
SELECT device_hostname, process_name, query_hostname, time FROM hb_dns_activity WHERE (instr(',' || '{{proxy_domains}}' || ',', ',' || LOWER(query_hostname) || ',') > 0 OR LOWER(query_hostname) LIKE '%.hiddenservice.net') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')
```
## auth-suspicious-ips
<!-- Suspicious Okta Login Source IPs -->
Identify Okta logins from known proxy IPs or IPs used by very few users across the fleet.
```sqlite target=identity role=baseline params=(proxy_ips=proxy_ips, lookback_days=lookback_days)
~~~yaml
baseline:
compare: first_seen
window: '{{lookback_days}}d'
expected: Successful logins from known proxy exit nodes or highly unique IPs. Silence
suggests no anomalous authentication source IPs.
prevalence:
by: actor_user_name
key:
- src_endpoint_ip
rare_below: 3
reads:
- actor_user_name
- provider
- src_endpoint_ip
- status_id
- time
silence: not_evidence_of_absence
source: hb_auth_signin
verified: dry-run
verified_at: '2026-09-21'
~~~
SELECT src_endpoint_ip, COUNT(DISTINCT actor_user_name) AS user_count, COUNT(*) AS login_count FROM hb_auth_signin WHERE provider = 'okta' AND status_id = 1 AND (instr(',' || '{{proxy_ips}}' || ',', ',' || src_endpoint_ip || ',') > 0 OR src_endpoint_ip IN (SELECT src_endpoint_ip FROM hb_auth_signin WHERE provider = 'okta' GROUP BY src_endpoint_ip HAVING COUNT(DISTINCT actor_user_name) <= 3)) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY src_endpoint_ip
```
## early-stage-triage
<!-- Early Stage Evidence Triage -->
```agent target=hunter
cite: required
context:
- scope-okta-logins
- dns-proxy-infra
- auth-suspicious-ips
max_iterations: 3
objective: Identify if any Okta login session from a rare or known proxy IP (auth-suspicious-ips)
occurred on a host that was also resolving proxy infrastructure domains (dns-proxy-infra).
success_criteria: A verdict citing specific hosts and users where both signals occurred
in close proximity.
tools:
- endpoint
- identity
- network
```
## follow-on-evidence-gathering
<!-- Parallel Follow-on Evidence Gathering -->
parallel:
- → network-proxy-egress
- → endpoint-discovery
join: → follow-on-triage
## network-proxy-egress
<!-- Network Egress to Proxy Relay Ports -->
Detect TCP connections to standard proxy ports like 9001 and 9050 that often signal Tor or multi-hop traffic.
```sqlite target=network role=baseline params=(scope_hosts=scope_hosts, lookback_days=lookback_days)
~~~yaml
expected: Established connections to proxy relay ports. Silence means no egress to
these specific ports was observed.
reads:
- device_hostname
- dst_endpoint_ip
- dst_endpoint_port
- process_name
- protocol
- time
silence: not_evidence_of_absence
source: hb_network_connection
verified: dry-run
verified_at: '2026-09-21'
~~~
SELECT device_hostname, dst_endpoint_ip, dst_endpoint_port, process_name, time FROM hb_network_connection WHERE dst_endpoint_port IN (9001, 9050) AND protocol = 'tcp' AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')
```
## endpoint-discovery
<!-- Endpoint Discovery Command Execution -->
Find discovery commands executed on the host that correlate with the suspected proxy session.
```sqlite target=endpoint role=detection-candidate params=(discovery_commands=discovery_commands, scope_hosts=scope_hosts, lookback_days=lookback_days)
~~~yaml
expected: Process execution of common discovery tools. Silence suggests no discovery
activity was logged.
reads:
- device_hostname
- process_cmd_line
- process_name
- time
- user_name
silence: not_evidence_of_absence
source: hb_process_activity
verified: dry-run
verified_at: '2026-09-21'
~~~
SELECT device_hostname, user_name, process_name, process_cmd_line, time FROM hb_process_activity WHERE (instr(',' || '{{discovery_commands}}' || ',', ',' || LOWER(process_name) || ',') > 0 OR instr(',' || '{{discovery_commands}}' || ',', ',' || LOWER(process_cmd_line) || ',') > 0) AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')
```
## follow-on-triage
<!-- Follow-on Evidence Triage -->
```agent target=hunter
cite: required
context:
- early-stage-triage
- network-proxy-egress
- endpoint-discovery
max_iterations: 6
objective: Confirm whether the suspect users and hosts from early-stage-triage showed
subsequent network egress to proxy nodes or discovery command execution on the same
endpoint.
success_criteria: A final malicious | suspicious verdict citing the temporal link
between auth, network, and process events.
tools:
- endpoint
- identity
- network
```
## route-verdict
<!-- Route Based on Intrusion Chain -->
if~: "the follow-on-triage verdict is malicious for at least one host and user" (confidence: high, judge=hunter)
then: → isolate-host
indeterminate: → analyst-validation
unavailable: → analyst-validation (blind_spot: missing-endpoint-telemetry)
else: → close-out
## isolate-host
<!-- Isolate Host and Revoke Identity -->
```action target=endpoint
~~~yaml
approval: required
~~~
Isolate the endpoint in the EDR console and revoke all active Okta sessions for the identified user.
```
→ analyst-validation
## analyst-validation
<!-- Analyst Final Validation -->
```manual target=analyst
Verify the link between the Okta login IP and the endpoint network/process activity. Investigate any lateral movement (e.g. RDP/SSH) from this host within the same window.
```
→ close-out
## close-out
<!-- Close Out and Record ROI -->
```manual target=analyst
Document the findings and update any baseline filters if the activity was determined to be authorized administrative work. Record the detection of a proxy-obscured session as a successful hunt ROI.
```
→ 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.