Detect Purchase Technical Data in Sumo Logic CSE
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/
Sumo Detection Query
_sourceCategory=*azure* OR _sourceCategory=*aad*
| json auto
| where isNotNull(userPrincipalName)
| count by userPrincipalName, ipAddress, appDisplayName
| sort by _count descSumo Logic detection for Purchase Technical Data (T1597.002). Uses _sourceCategory path filtering for flexible log routing compatibility, with JSON field extraction and statistical aggregation to surface purchase technical data patterns. Designed for the Sumo Logic Cloud SIEM platform.
Data Sources
Required Tables
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
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.
- 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.
- 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.
- 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.
- 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.
- 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).
References (10)
- https://attack.mitre.org/techniques/T1597/002/
- https://www.zdnet.com/article/a-hacker-group-is-selling-more-than-73-million-user-records-on-the-dark-web/
- https://www.microsoft.com/en-us/security/blog/2022/03/22/dev-0537-criminal-actor-targeting-organizations-for-data-exfiltration-and-destruction/
- https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection
- https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs
- https://haveibeenpwned.com/API/v3
- https://spycloud.com/blog/what-is-credential-stuffing/
- https://www.cisa.gov/sites/default/files/2023-03/threat-actor-leveraging-multiple-ransomware-families_0.pdf
- https://owasp.org/www-community/attacks/Credential_stuffing
- https://www.recordedfuture.com/blog/dark-web-credential-markets
Unlock Pro Content
Get the full detection package for T1597.002 including response playbook, investigation guide, and atomic red team tests.