Anomalous Cloud Identity Behavior
An adversary has compromised an administrative cloud identity and is accessing the environment through multi-hop proxies or Tor to perform discovery and initial access.
Based on research by Unit 42 2026-09-20 11 steps · 3 queries T1078.004 T1090.003 T1190
Brief
Why Behavioral Clustering Matters
Unit 42 recently detailed how behavioral clustering can map cloud identities and reveal anomalies in their operating patterns in the article Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection (https://unit42.paloaltonetworks.com/behavioral-clustering-map-to-cloud-identities/). Traditional detection rules often rely on static lists of known malicious IPs, which adversaries easily bypass using multi-hop proxies or fresh Tor exit nodes. This hunt adopts the behavioral approach by establishing a baseline of normal administrative access and looking for the outliers that suggest an identity has been highjacked.
How the Hunt Flows
The first query scopes privileged authentication events in the hb_auth_signin surface. We target roles matching administrative patterns—such as AWS Reserved SSO or root accounts—that sign in from source IP addresses seen fewer than five times over the last 14 days. This scoping isolates behavioral rarity in sign-in locations to establish leads.
An agent evaluates the risk of these leads by looking for sessions where multi-factor authentication (MFA) was missing. This step gates the hunt. The process only proceeds to network and identity checks if the initial sign-in shows significant risk. If the agent identifies a high-risk lead, the hunt triggers a parallel fan-out phase.
During the fan-out, the hunt searches for evidence across two surfaces. A query on hb_dns_activity finds DNS resolutions to known Tor project domains or .onion addresses from the hosts associated with the suspicious login. Simultaneously, a check on hb_users verifies the identity's security posture for disabled MFA or inactive account statuses that the adversary might use.
A triage agent synthesizes these findings by correlating the rare IP login with any discovered Tor activity or weak identity configurations. If the triage confirms a malicious intersection, the hunt triggers an action to revoke all active cloud sessions for the compromised user.
What the Hunt Cannot See
This hunt has two primary blind spots. First, it lacks visibility into specific cloud resource discovery operations, such as ListBuckets or ListRoles, because these require normalized cloud audit logs which are not part of the initial endpoint-centric surfaces. Second, the hunt depends on behavioral rarity and DNS queries from managed hosts to detect Tor. If an adversary logs in from an unmanaged device using Tor, and that device does not perform Tor-related DNS lookups through monitored infrastructure, the hunt misses the obfuscation signal.
How to Run the Hunt
This hunt is provided as a hunt.md playbook. You can import it into Huntbase or any compatible hunt.md runtime to automate the scoping, agent evaluation, and parallel evidence gathering phases. Adjust the admin_patterns parameter to match specific naming conventions for privileged roles.
In this series
Steps
-
Identify rare administrative sign-ins
Query · scopingEstablish a lead by finding privileged logins from source IPs that have appeared fewer than five times in the lookback window.
reads hb_auth_signinsqlSELECT actor_user_name, src_endpoint_ip, dst_endpoint_name, mfa, COUNT(*) AS login_count, MIN(time) AS first_seen, MAX(time) AS last_seen FROM hb_auth_signin WHERE activity_id = 1 AND status_id = 1 AND (instr(',' || '{{admin_patterns}}' || ',', ',' || LOWER(actor_user_name) || ',') > 0 OR LOWER(actor_user_name) LIKE '%admin%') AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY actor_user_name, src_endpoint_ip, dst_endpoint_name, mfa HAVING login_count < 5 ORDER BY login_count ASCWhat a hit looks like. Rows showing a privileged user logging into a service from an IP they do not typically use. Silence proves no rare administrative logins were recorded for these patterns.
-
Evaluate risk of the sign-in lead
Agent triageDetermine if the identified rare sign-ins are sufficiently anomalous to trigger expensive network and identity checks.
-
Gate deeper analysis
DecisionStop the hunt if the lead agent identifies only benign or expected administrative behavior.
-
Network obfuscation via Tor DNS
Query · enrichmentSearch for DNS lookups to Tor-related domains from the endpoints associated with the suspicious logins.
reads hb_dns_activitysqlSELECT device_hostname, query_hostname, actor_user_name, src_endpoint_ip, time FROM hb_dns_activity WHERE (instr(',' || '{{tor_domains}}' || ',', ',' || LOWER(query_hostname) || ',') > 0 OR LOWER(query_hostname) LIKE '%.onion%') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. Rows mapping a host or user to Tor domain resolutions. Any hit confirms the use of anonymity software.
-
Identity security posture
Query · baselineVerify the current status and MFA configuration of identities identified in the lead.
reads hb_userssqlSELECT name, email, provider, mfa_enabled, status, created_at FROM hb_users WHERE status != 'active' OR mfa_enabled = 'false'What a hit looks like. Identity records showing users without MFA enabled or in a non-active status. This context increases the likelihood that a login anomaly is malicious.
-
Triage the behavioral anomalies
Agent triageSynthesize the rare sign-in evidence with network obfuscation and identity posture results.
-
Route based on triage
DecisionFinal decision to contain or review.
-
Revoke identity sessions
Response actionContain the threat by terminating all active cloud sessions for the compromised user.
-
Post-incident cloud audit
Analyst taskManual verification of the identity's activity in the cloud control plane.
-
Close out hunt
Analyst taskFinal reporting and cleanup.
Coverage
Scenario coverage
| Stage | Covered | How, or why not |
|---|---|---|
| Cloud Identity Authentication | Yes | rare-admin-signins-lead, evaluate-risk-of-lead, identity-posture-check |
| Cloud Resource Discovery | Not visible | Cloud discovery API calls (e.g., ListBuckets) are not recorded in the provided endpoint or auth surfaces; they require CloudTrail-style logs. |
| Multi-hop Proxy Obfuscation T1090.003 |
Yes | network-obfuscation-dns |
| Exploitation of Public-Facing Application T1190 |
Out of scope | Belongs to another part of the 'Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection' series. |
| User Execution of Malicious File T1204.002 |
Out of scope | Belongs to another part of the 'Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection' series. |
Blind spots
- Needs Normalized hb_cloud_audit surface. We can identify the login anomaly but not the subsequent actions taken within the cloud console. It would answer What discovery operations (ListBuckets, ListRoles) did the identity perform?.
- Needs External IP reputation feed. The hunt must rely on behavioral rarity and DNS queries from managed hosts, potentially missing Tor logins from unmanaged devices. It would answer Does the source IP belong to a known Tor exit node or VPN provider?.
Parameters & data
Parameters
| Parameter | Type | Default | What it is |
|---|---|---|---|
admin_patterns | list[string] | awsreservedsso_administratoraccess_, admin, superuser, root | Naming patterns associated with administrative roles. |
lookback_days | number | 14 | Days of activity to examine. |
scope_hosts | list[host] | — | Hostnames to limit the DNS search to; leave empty to scan the entire estate. |
tor_domains | list[domain] | torproject.org, check.torproject.org, exitlist.torproject.org | Domains linked to Tor network infrastructure. |
Telemetry
| Source | Category | Telemetry |
|---|---|---|
| Endpoint telemetry (hb_ surfaces) | endpoint | endpoint |
| Identity / sign-in telemetry | identity | identity |
Source
---
analysis: A static detection rule would only trigger on a known Tor IP list. This
hunt baselines administrative behavior to find rare IPs first, then pivots into
DNS activity from related endpoints and identity security posture to provide a contextual
risk score that reduces false positives from authorized remote administration.
blind_spots:
- id: no-cloud-audit-logs
question: What discovery operations (ListBuckets, ListRoles) did the identity perform?
requires: Normalized hb_cloud_audit surface
risk: We can identify the login anomaly but not the subsequent actions taken within
the cloud console.
stage: cloud-resource-discovery
- id: no-ip-reputation-data
question: Does the source IP belong to a known Tor exit node or VPN provider?
requires: External IP reputation feed
risk: The hunt must rely on behavioral rarity and DNS queries from managed hosts,
potentially missing Tor logins from unmanaged devices.
stage: multi-hop-proxy-obfuscation
coverage:
- stage: cloud-identity-authentication
status: covered
steps:
- rare-admin-signins-lead
- evaluate-risk-of-lead
- identity-posture-check
- blind_spot: no-cloud-audit-logs
reason: Cloud discovery API calls (e.g., ListBuckets) are not recorded in the provided
endpoint or auth surfaces; they require CloudTrail-style logs.
stage: cloud-resource-discovery
status: not_visible
- stage: multi-hop-proxy-obfuscation
status: covered
steps:
- network-obfuscation-dns
- reason: 'Belongs to another part of the ''Unmasking Cloud Identities: From Behavioral
Clustering to Automated Detection'' series.'
stage: exploit-public-application
status: out_of_scope
- reason: 'Belongs to another part of the ''Unmasking Cloud Identities: From Behavioral
Clustering to Automated Detection'' series.'
stage: client-side-execution
status: out_of_scope
guardrails:
claims: no_unsupported
evidence: citation_required
missing_data: not_benign
telemetry: untrusted
hunt:
applicability: campaign-specific
handoff: keep-as-periodic-hunt
justification: Compromise of administrative cloud identities allows for full environment
takeover. Identifying anomalous behavioral clusters (rare IP + proxy usage) is
an essential control where MFA may be bypassed or not enforced.
methodology: model-assisted
trigger: intel-report
hypothesis: An adversary has compromised an administrative cloud identity and is accessing
the environment through multi-hop proxies or Tor to perform discovery and initial
access.
labels:
- hunt
- attack.t1090.003
- attack.t1190
- attack.t1078.004
name: Anomalous Cloud Identity Behavior
parameters:
admin_patterns:
default:
- awsreservedsso_administratoraccess_
- admin
- superuser
- root
description: Naming patterns associated with administrative roles.
from:
kind: article
observed: '2026-09-14'
ref: https://unit42.paloaltonetworks.com/behavioral-clustering-map-to-cloud-identities/
type: list[string]
lookback_days:
default: '14'
description: Days of activity to examine.
type: number
scope_hosts:
default: []
description: Hostnames to limit the DNS search to; leave empty to scan the entire
estate.
type: list[host]
tor_domains:
default:
- torproject.org
- check.torproject.org
- exitlist.torproject.org
description: Domains linked to Tor network infrastructure.
from:
kind: manual
observed: '2024-05-20'
ref: T1090.003
type: list[domain]
provenance:
authors:
- name: Huntbase hunt generation
org: huntbase.io
generated:
by: huntbase-hunt-generation
from: https://unit42.paloaltonetworks.com/behavioral-clustering-map-to-cloud-identities/
gates:
- dry-run
- lint
model: hb_google/gemini-3-flash-preview
rationale: Focus on AWS and Azure cloud tenants. Prioritize accounts that exhibit
'ConsoleLogin' activity without MFA from non-corporate IP ranges.
references:
- name: "Unit 42 \u2014 Unmasking Cloud Identities: From Behavioral Clustering to\
\ Automated Detection"
url: https://unit42.paloaltonetworks.com/behavioral-clustering-map-to-cloud-identities/
related:
- hunt: cloud-api-discovery-clustering
reason: This hunt establishes the login anomaly; a follow-on hunt should examine
clustered API discovery patterns once cloud audit logs are available.
relation: follows
- hunt: public-app-exploitation-cloud-identity-drift
relation: follows
scenario:
stages:
- name: Exploitation of Public-Facing Application
observables:
- Inbound exploitation attempts against internet-facing web servers
- Unauthorized HTTP POST requests to vulnerable endpoints
slug: exploit-public-application
tactic: initial-access
techniques:
- T1190
- name: User Execution of Malicious File
observables:
- Execution of downloaded suspicious documents or binaries
- Process spawning from browser or email client
- Malicious file creation in temporary directories
slug: client-side-execution
tactic: execution
techniques:
- T1204.002
- name: Cloud Identity Authentication
observables:
- ConsoleLogin events
- GetSigninToken activity
- Identity naming patterns containing 'admin'
- AWSReservedSSO_AdministratorAccess_ prefix usage
slug: cloud-identity-authentication
tactic: initial-access
- name: Cloud Resource Discovery
observables:
- ListBuckets
- ListRoles
- ListNotificationHubs
- GetCostAndUsage
- GetCostForecast
slug: cloud-resource-discovery
tactic: discovery
- name: Multi-hop Proxy Obfuscation
observables:
- Sign-in activity from known Tor exit nodes
- Network connections to multi-hop VPS or ORB networks
- Anomalous source IP addresses for administrative sessions
slug: multi-hop-proxy-obfuscation
tactic: command-and-control
techniques:
- T1090.003
summary: Attackers leverage exploited applications or social engineering to gain
access to over-privileged cloud identities, which are then used to perform resource
enumeration and discovery within AWS Management Console. To evade detection, actors
masquerade using benign permission profiles and mask their activity source through
multi-hop proxies or Tor, requiring behavioral clustering to distinguish malicious
reconnaissance from legitimate administrative activity.
series:
index: 2
slug: unmasking-cloud-identities-from-behavioral-clustering-to-automated-detection
title: 'Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection'
total: 2
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
tlp: clear
type: investigation
---
# Anomalous Cloud Identity Behavior
This hunt implements behavioral clustering logic to identify administrative identities operating outside of their normal baseline. It starts by identifying privileged sign-ins from rare source IP addresses. A gated evaluation determines if these logins warrant deeper investigation. If they do, the hunt fans out to look for evidence of network obfuscation, such as Tor DNS resolutions, and verifies the identity's security posture. An agent then synthesizes these results to detect credential abuse masked by multi-hop proxies.
## rare-admin-signins-lead
<!-- Identify rare administrative sign-ins -->
Establish a lead by finding privileged logins from source IPs that have appeared fewer than five times in the lookback window.
```sqlite target=identity role=scoping params=(lookback_days=lookback_days, admin_patterns=admin_patterns)
~~~yaml
baseline:
compare: first_seen
window: '{{lookback_days}}d'
expected: Rows showing a privileged user logging into a service from an IP they do
not typically use. Silence proves no rare administrative logins were recorded for
these patterns.
prevalence:
by: src_endpoint_ip
key:
- actor_user_name
- src_endpoint_ip
rare_below: 5
reads:
- actor_user_name
- src_endpoint_ip
- dst_endpoint_name
- mfa
- time
silence: evidence_of_absence
source: hb_auth_signin
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT actor_user_name, src_endpoint_ip, dst_endpoint_name, mfa, COUNT(*) AS login_count, MIN(time) AS first_seen, MAX(time) AS last_seen FROM hb_auth_signin WHERE activity_id = 1 AND status_id = 1 AND (instr(',' || '{{admin_patterns}}' || ',', ',' || LOWER(actor_user_name) || ',') > 0 OR LOWER(actor_user_name) LIKE '%admin%') AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY actor_user_name, src_endpoint_ip, dst_endpoint_name, mfa HAVING login_count < 5 ORDER BY login_count ASC
```
## evaluate-risk-of-lead
<!-- Evaluate risk of the sign-in lead -->
```agent target=hunter
cite: required
context:
- rare-admin-signins-lead
max_iterations: 3
objective: Review the rare sign-ins and identify users who logged in from rare IPs
without MFA, or users whose names strongly match the sensitive administrative patterns.
success_criteria: A clear list of suspicious users and source IPs that require further
investigation.
tools:
- endpoint
- identity
```
## gate-decision
<!-- Gate deeper analysis -->
if~: "the evaluate-risk-of-lead agent identifies at least one high-risk administrative sign-in from a rare IP address" (confidence: high, judge=hunter)
then: → corroborate-anomalies
indeterminate: → analyst-review
unavailable: → analyst-review (blind_spot: no-ip-reputation-data)
else: → close-out
## corroborate-anomalies
<!-- Corroborate anomalies -->
parallel:
- → network-obfuscation-dns
- → identity-posture-check
join: → triage-verdict
## network-obfuscation-dns
<!-- Network obfuscation via Tor DNS -->
Search for DNS lookups to Tor-related domains from the endpoints associated with the suspicious logins.
```sqlite target=endpoint role=enrichment params=(lookback_days=lookback_days, tor_domains=tor_domains, scope_hosts=scope_hosts)
~~~yaml
expected: Rows mapping a host or user to Tor domain resolutions. Any hit confirms
the use of anonymity software.
reads:
- device_hostname
- query_hostname
- actor_user_name
- src_endpoint_ip
- time
silence: not_evidence_of_absence
source: hb_dns_activity
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT device_hostname, query_hostname, actor_user_name, src_endpoint_ip, time FROM hb_dns_activity WHERE (instr(',' || '{{tor_domains}}' || ',', ',' || LOWER(query_hostname) || ',') > 0 OR LOWER(query_hostname) LIKE '%.onion%') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days')
```
## identity-posture-check
<!-- Identity security posture -->
Verify the current status and MFA configuration of identities identified in the lead.
```sqlite target=identity role=baseline
~~~yaml
expected: Identity records showing users without MFA enabled or in a non-active status.
This context increases the likelihood that a login anomaly is malicious.
reads:
- name
- email
- mfa_enabled
- status
silence: not_evidence_of_absence
source: hb_users
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT name, email, provider, mfa_enabled, status, created_at FROM hb_users WHERE status != 'active' OR mfa_enabled = 'false'
```
## triage-verdict
<!-- Triage the behavioral anomalies -->
```agent target=hunter
cite: required
context:
- evaluate-risk-of-lead
- network-obfuscation-dns
- identity-posture-check
max_iterations: 5
objective: Determine if the anomalous administrative sign-ins indicate account compromise
by correlating the rare IP results from the lead with any Tor DNS activity or weak
identity posture found in the fan-out.
success_criteria: A per-host and per-user verdict citing specific DNS queries or login
timestamps.
tools:
- endpoint
- identity
```
## route-verdict
<!-- Route based on triage -->
if~: "the triage-verdict agent identifies at least one administrative user as malicious due to the intersection of rare IPs and Tor activity" (confidence: high, judge=hunter)
then: → revoke-sessions
indeterminate: → analyst-review
unavailable: → analyst-review (blind_spot: no-cloud-audit-logs)
else: → analyst-review
## revoke-sessions
<!-- Revoke identity sessions -->
```action target=identity
~~~yaml
approval: required
~~~
Revoke all active sessions for the identified administrative users and force an immediate password reset and MFA rotation.
```
→ analyst-review
## analyst-review
<!-- Post-incident cloud audit -->
```manual target=analyst
Examine native cloud audit logs (e.g., AWS CloudTrail) for the users identified in this hunt. Search for discovery operations like ListBuckets, ListRoles, or GetCostAndUsage. Verify if the rare source IP belongs to a known administrative jump box or a public proxy/Tor node.
```
→ end
## close-out
<!-- Close out hunt -->
```manual target=analyst
Record the findings and update the admin_patterns list if legitimate administrative accounts were flagged. If any Tor activity was benign (e.g., research), document the exemption.
```
→ 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.