T1597.002 Google Chronicle · YARA-L

Detect Purchase Technical Data in Google Chronicle

Adversaries may purchase technical information about victims that can be used during targeting. Information about victims may be available for purchase within reputable private sources and databases, such as paid subscriptions to feeds of scan databases or other data aggregation services. Adversaries may also purchase information from less-reputable sources such as dark web or cybercrime blackmarkets. Purchased data may include employee credentials, session tokens, infrastructure details, exposed certificates, or vulnerability scan results. LAPSUS$ is a documented threat actor known to purchase credentials and session tokens from criminal underground forums. Because the purchase itself occurs entirely outside the victim's environment, detection must focus on downstream indicators: use of purchased credentials in authentication events, impossible travel patterns, logins from anonymizing infrastructure (Tor, VPN exit nodes), and Identity Protection risk signals.

MITRE ATT&CK

Tactic
Reconnaissance
Technique
T1597 Search Closed Sources
Sub-technique
T1597.002 Purchase Technical Data
Canonical reference
https://attack.mitre.org/techniques/T1597/002/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1597_002_purchase_technical_data {
  meta:
    author = "df00tech"
    description = "Detects Purchase Technical Data (T1597.002)"
    mitre_attack_tactic = "TA0043"
    mitre_attack_technique = "T1597.002"
    confidence = "low"
    severity = "high"
  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid != ""
  condition:
    $e
}
high severity low confidence

Google Chronicle YARA-L 2.0 detection rule for Purchase Technical Data (T1597.002). Uses Unified Data Model (UDM) event field mappings to detect the same behavioral patterns as the KQL rule, with Chronicle's temporal matching and entity correlation capabilities.

Data Sources

Google Chronicle SIEMChronicle UDM

Required Tables

USER_LOGINUSER_RESOURCE_ACCESS

False Positives & Tuning

  • Legitimate user travel to a new country or use of a corporate VPN exit node in an unfamiliar region will trigger the impossible travel and new-country branches
  • Users sharing a corporate NAT or proxy will cause multiple accounts to appear from the same IP, triggering the credential stuffing threshold even for legitimate logins
  • Entra ID Protection risk events may fire for legitimate users connecting from cloud provider IP ranges (AWS, Azure, GCP) that are also abused by attackers
  • Red team or penetration testing exercises using purchased breach data to validate detection coverage will produce high-confidence true positives that are authorized
Download portable Sigma rule (.yml)

Other platforms for T1597.002


Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Check Organization Domain Against Have I Been Pwned Enterprise API

    Expected signal: Network connection to api.haveibeenpwned.com:443 from the executing host. DNS resolution of api.haveibeenpwned.com. HTTP GET request visible in proxy/web gateway logs. No endpoint telemetry generated for the API call itself.

  2. Test 2Simulate Credential Stuffing Authentication Pattern

    Expected signal: Web application access logs: 15 entries with HTTP 401 from the source IP across distinct usernames, followed by 1 HTTP 200. If web app logs feed into Splunk or Sentinel: Authentication datamodel events with action=failure for the 15 attempts and action=success for the final attempt. All events from the same source IP within a 30-second window.

  3. Test 3Query Tor Exit Node List and Check Against Authentication Logs

    Expected signal: DNS resolution of check.torproject.org. Outbound HTTPS connection to check.torproject.org:443. File creation at /tmp/tor_exit_nodes.txt. If cross-referencing login logs, no additional network telemetry is generated for the grep operations.

  4. Test 4Enumerate Exposed Credentials for Domain Using Dehashed API

    Expected signal: DNS resolution of api.dehashed.com. Outbound HTTPS connection to api.dehashed.com:443 with Basic Authentication header. HTTP GET request visible in proxy/web gateway logs. Response body contains credential records if any are found.

  5. Test 5Generate Impossible Travel Event for Detection Validation

    Expected signal: Two SigninLogs entries for the same UserPrincipalName within a short time window, each with a different IPAddress and LocationDetails.countryOrRegion value. The time delta between entries divided by the physical distance between locations should exceed the speed of any known transportation (i.e., physically impossible travel).

Unlock Pro Content

Get the full detection package for T1597.002 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections