About the 5-Minute Hunt: The 5-Minute Hunt is a feature available in the Vectra AI Platform under the Investigate tab. Each hunt highlights a specific attacker behavior and provides a ready-to-run query you can use immediately.

‍

This week’s hunts focus on Iranian state-linked threat groups, including OilRig (APT34) and Charming Kitten (APT35), which continue to target organizations through identity compromise and covert command-and-control infrastructure.

Iran-aligned groups rarely rely on a single entry point. A typical intrusion chain begins with credential phishing or password spraying, followed by quiet persistence in cloud identity systems and outbound communication to attacker infrastructure. Network traffic and SaaS identity logs often hold the earliest evidence.

The following 5-minute hunts are designed to surface those signals quickly inside the Vectra AI Platform.

Hunting for APT35 – Charming Kitten

APT35 Pupy Malware Infrastructure

APT35 has been observed deploying the Pupy remote administration tool during targeted espionage campaigns.

Pupy is a cross-platform RAT that enables attackers to remotely control compromised hosts, execute commands, and exfiltrate sensitive data. Once deployed, infected systems communicate with external command-and-control servers to receive instructions and transmit collected information.

Monitoring communication with known Pupy infrastructure can help identify compromised systems early in the attack lifecycle.

Query Objective

This search identifies:

• Network sessions where either the source or destination IP matches known infrastructure associated with APT35 Pupy activity
• The protocol used for communication (proto_name)
• The number of connections between hosts (connection_count)
• The most recent time the activity was observed (last_seen)

SELECT
    id.orig_h AS source_ip,
    id.resp_h AS dest_ip,
    proto_name,
    COUNT(*) AS connection_count,
    MAX(timestamp) AS last_seen
FROM network.isession._all
WHERE
    (id.orig_h IN ('154.12.20.218', '144.172.107.157', '149.28.52.61', '66.55.159.84', '172.235.235.80')
     OR id.resp_h IN ('154.12.20.218', '144.172.107.157', '149.28.52.61', '66.55.159.84', '172.235.235.80'))
    AND timestamp BETWEEN date_add('day', -14, now()) AND now()
GROUP BY id.orig_h, id.resp_h, proto_name
ORDER BY connection_count DESC
LIMIT 100

What to look for

Analysts should pay particular attention to:

• Internal hosts repeatedly communicating with the same suspicious external IP
• Connections occurring over unexpected protocols for the system
• Persistent or recurring connections that may indicate beaconing behaviour

How to investigate further

1. Validate the suspicious IPs against threat intelligence sources and internal allow-lists
2. Pivot into DNS, HTTP, SSL, and endpoint telemetry to identify related activity
3. Investigate processes on the host generating the network traffic using EDR or Sysmon
4. If confirmed malicious, block the infrastructure and isolate the affected endpoint for remediation

Related MITRE techniques:

• T1071 – Application Layer Protocol
• T1105 – Ingress Tool Transfer
• T1059 – Command and Scripting Interpreter

Failed Device Registration Linked to APT35 Reconnaissance

APT35 often performs reconnaissance inside Microsoft 365 environments after harvesting credentials.

One common technique involves attempting to register new devices to user accounts. When these attempts fail, the activity can still provide valuable signals that an attacker is testing credentials or probing tenant policies before attempting persistence.

Repeated failed device registrations may indicate attackers validating stolen credentials or exploring device trust policies before launching a more targeted intrusion.

Query Objective

This search identifies:

• Microsoft 365 directory audit events where device registration attempts failed
• The user account initiating the attempt (user_principal_name)
• The originating IP address
• The failure reason (result_reason)
• Associated resources involved in the attempted registration

SELECT
    id,
    activity_date_time,
    activity_display_name,
    initiated_by.user.user_principal_name,
    initiated_by.user.ip_address,
    result,
    result_reason,
    target_resources
FROM m365.directory_audits._all
WHERE
    LOWER(activity_display_name) LIKE '%register device%'
    AND LOWER(result) = 'failure'
    AND timestamp > date_add('day', -14, DATE(NOW()))
ORDER BY activity_date_time DESC
LIMIT 100

What to look for

Analysts should pay particular attention to:

• Multiple failed attempts from the same IP address
• Attempts targeting multiple users within the tenant
• Device registration failures originating from unfamiliar geographic locations
• Activity occurring shortly after suspicious sign-in attempts or phishing alerts

How to investigate further

1. Review sign-in logs and authentication events associated with the user account
2. Validate whether the IP address is associated with VPNs, anonymization services, or known attacker infrastructure
3. Check for subsequent successful authentication or device registration attempts
4. If suspicious activity is confirmed, enforce password resets, revoke sessions, and monitor the account for further anomalous behaviour

Related MITRE techniques:

• T1078.004 – Valid Accounts (Cloud Accounts)
• T1595 – Active Scanning
• T1598 – Phishing for Information

Suspicious Device Registration Linked to APT35 Phishing

‍APT35, often referred to as Charming Kitten, is known for credential harvesting campaigns targeting Microsoft 365 users. After obtaining valid credentials, attackers often register a new device inside the tenant.

This tactic helps them maintain access even if the password changes and may bypass conditional access rules tied to trusted devices. In practice, it allows the attacker to operate as a legitimate endpoint inside the environment.

Device registration events are recorded in Microsoft 365 directory audit logs, which makes them a valuable signal when hunting for post-phishing persistence.

Query Objective

This search identifies:

• Microsoft 365 directory audit events related to device registration activity
• The user account performing the registration (user_principal_name)
• The IP address used during the activity
• The outcome of the registration attempt (result)
• Associated resources involved in the action (target_resources)

SELECT
    id,
    activity_date_time,
    activity_display_name,
    initiated_by.user.user_principal_name,
    initiated_by.user.ip_address,
    result,
    target_resources
FROM m365.directory_audits._all
WHERE
    LOWER(activity_display_name) LIKE '%register device%'
    AND timestamp > date_add('day', -14, DATE(NOW()))
ORDER BY activity_date_time DESC
LIMIT 100

What to Look For in Results

Analysts should pay particular attention to:

• Device registrations originating from unfamiliar or foreign IP addresses
• Registrations occurring shortly after suspicious sign-in activity
• Accounts that have never previously registered devices
• Multiple device registrations within a short timeframe

How to Investigate Further

1. Confirm whether the device belongs to the legitimate user.
2. Cross-reference the activity with Microsoft 365 sign-in logs and risky sign-in alerts.
3. Look for other identity manipulation events such as new authentication methods, password resets, or token creation.
4. If the activity appears malicious, revoke sessions, reset credentials, and remove unauthorized devices from the tenant.

Related MITRE techniques:

• T1078.004 – Valid Accounts (Cloud Accounts)
• T1098 – Account Manipulation

Hunting for APT34 – OilRig

Detecting OilRig (APT34) Command-and-Control Infrastructure

OilRig, also known as APT34, routinely operates long-running espionage campaigns targeting government, financial, and energy organizations.

One common pattern in these campaigns is persistent communication with attacker-controlled infrastructure hosted on compromised servers or low-cost VPS providers.

Even when malware is heavily obfuscated, the infrastructure used for command-and-control tends to remain active long enough to detect network communication patterns.

Monitoring for traffic to known OilRig infrastructure can quickly expose compromised hosts or staging systems used during early attack phases.

Query Objective

This search identifies:

• Network sessions where either the source or destination IP matches known OilRig infrastructure
• The protocol used for communication (proto_name)
• The total number of connections between hosts
• The most recent time the activity was observed (last_seen)

SELECT
    id.orig_h AS source_ip,
    id.resp_h AS dest_ip,
    proto_name,
    COUNT(*) AS connection_count,
    MAX(timestamp) AS last_seen
FROM network.isession._all
WHERE
    (id.orig_h IN ('103.61.224.102', '178.209.51.61', '185.76.78.177')
     OR id.resp_h IN ('103.61.224.102', '178.209.51.61', '185.76.78.177'))
    AND timestamp BETWEEN date_add('day', -14, now()) AND now()
GROUP BY id.orig_h, id.resp_h, proto_name
ORDER BY connection_count DESC
LIMIT 100

What to look for

Analysts should pay particular attention to:

• Internal hosts repeatedly contacting the same suspicious IP
• Connections occurring over unusual or unexpected protocols
• Persistent communication patterns suggesting beaconing behavior

How to investigate further

1. Validate the suspicious IPs against threat intelligence feeds and recent OilRig infrastructure reports
2. Pivot into DNS, HTTP, SSL, and endpoint telemetry for the affected host
3. Review process execution logs to identify malware or scripts generating the connections
4. Block confirmed malicious infrastructure at perimeter controls and isolate compromised hosts for remediation

Related MITRE techniques:

• T1071 – Application Layer Protocol
• T1105 – Ingress Tool Transfer
• T1090 – Proxy

OilRig SpyNote Infrastructure Activity

OilRig campaigns have been observed deploying the SpyNote malware family.

SpyNote frequently communicates with attacker infrastructure hosted behind dynamic DNS services or port-forwarding platforms. These domains often rotate quickly but follow recognizable patterns tied to services like localto.net or portmap.host.

Even when the malware is dormant, infected hosts tend to perform repeated DNS lookups to these domains while attempting to reconnect to command-and-control servers.

Those DNS queries can expose infected systems before the attacker actively issues commands.

Query Objective

This search identifies:

• DNS queries to domains previously associated with OilRig SpyNote activity
• The internal host (source_ip, source_hostname) generating the DNS request
• The number of times the domain was queried (query_count)
• The most recent time the activity occurred (last_seen)

SELECT
    query AS queried_domain,
    id.orig_h AS source_ip,
    orig_hostname.name AS source_hostname,
    COUNT(*) AS query_count,
    MAX(timestamp) AS last_seen
FROM network.dns._all
WHERE
    query IN (
        'hecker12345-61516.portmap.host',
        'software-garlic.gl.at.ply.gg',
        'dohinukss.localto.net',
        'suzrbgndb.localto.net',
        '49lwbineu.localto.net',
        'idi-nahuy.net',
        'utoigzdol.localto.net',
        'cyqahoxnt.localto.net',
        'xnd4x3ezm.localto.net',
        '5z6y8mkfe.localto.net',
        'fqq121qq-33728.portmap.host',
        'shabi9988-64207.portmap.host',
        'shzkagxdv.localto.net',
        'artemmakarov-30233.portmap.host',
        'hssshsh-33054.portmap.host',
        '0p7wfcoia.localto.net',
        'wq4x0gt8l.localto.net',
        'cezamail.com.cezamail.com',
        'cezamail.com.localto.net',
        'buglwf041.lo'
    )
    AND timestamp BETWEEN date_add('day', -14, now()) AND now()
GROUP BY query, id.orig_h, orig_hostname.name
ORDER BY query_count DESC
LIMIT 100

What to look for

Analysts should pay particular attention to:

• Hosts repeatedly querying the same suspicious domain
• Queries to dynamic DNS infrastructure such as localto.net or portmap.host
• Queries occurring shortly after suspicious process execution or user activity

How to investigate further

1. Investigate the host generating the queries using endpoint telemetry (EDR, Sysmon, etc.)
2. Pivot into HTTP/SSL sessions to determine if follow-up connections occurred
3. Validate domains against threat intelligence feeds and sandbox reports
4. If malicious activity is confirmed, isolate the host, block the domains, and perform full remediation

Related MITRE techniques:

• T1071.004 – Application Layer Protocol (DNS)
• T1105 – Ingress Tool Transfer
• T1090 – Proxy

Hunting for QasarRAT Infrastructure Activity

QasarRAT is a widely used open-source remote access trojan frequently adopted in espionage and surveillance campaigns. Once deployed, it gives attackers persistent control over compromised systems, allowing them to execute commands, monitor activity, and exfiltrate data.

Many QasarRAT campaigns rely on dynamic DNS providers to host command-and-control infrastructure. These services allow attackers to rotate backend servers while keeping the same domain name active, making the infrastructure harder to track.

Even when the malware is idle, infected systems typically continue resolving the C2 domain. Monitoring DNS queries tied to known QasarRAT infrastructure can reveal compromised hosts attempting to reach attacker-controlled servers.

Query Objective

This search identifies:

• DNS queries to domains previously observed in QasarRAT infrastructure
• Internal hosts (source_ip, source_hostname) performing the queries
• Frequency of requests (query_count)
• The most recent time activity was observed (last_seen)

SELECT
    query AS queried_domain,
    id.orig_h AS source_ip,
    orig_hostname.name AS source_hostname,
    COUNT(*) AS query_count,
    MAX(timestamp) AS last_seen
FROM network.dns._all
WHERE
    query IN (
        'luvxcide.duckdns.org',
        'projectindia999.loseyourip.com',
        'cia.anondns.net',
        'skittlesforlife.anondns.net',
        'bnli8khzo.localto.net',
        'isof63umlw.loclx.io',
        'docsc.ddns.net'
    )
    AND timestamp BETWEEN date_add('day', -14, now()) AND now()
GROUP BY query, id.orig_h, orig_hostname.name
ORDER BY query_count DESC
LIMIT 100 

What to look for

Analysts should pay particular attention to:

• Hosts repeatedly querying the same suspicious domain
• Domains hosted on dynamic DNS providers (e.g., duckdns.org, ddns.net, anondns.net, localto.net, loclx.io)
• DNS activity that coincides with suspicious process execution or unexpected outbound traffic

How to investigate further

1. Investigate the source host using endpoint telemetry (EDR, Sysmon, etc.) to identify processes generating the queries
2. Pivot to network session data (isession, ssl, http) to determine if connections were established after DNS resolution
3. Validate domains against threat intelligence sources and malware reports
4. If confirmed malicious, block the domains and isolate the affected system for remediation

Related MITRE techniques:

• T1071.004 – Application Layer Protocol (DNS)
• T1105 – Ingress Tool Transfer
• T1059 – Command and Scripting Interpreter

Closing Thoughts

Iran-linked threat actors rely heavily on credential abuse, cloud identity manipulation, and covert command-and-control channels. Many of these activities blend into legitimate traffic and user behavior, which makes them difficult to detect with traditional perimeter defenses alone.

Running targeted hunts like these allows analysts to surface early indicators before attackers escalate privileges, stage data, or move deeper into the environment.

If you are already using the Vectra AI Platform, you can run these queries directly in the Investigate tab and pivot immediately into identity and network telemetry to determine whether activity is benign or malicious.

New 5-Minute Hunts are released regularly to help SOC teams identify attacker behavior faster and reduce the time between intrusion and response.

Not a customer yet? Explore our self-guided demos to see how behavioral detection surfaces these threats automatically.