Which SIEM platforms have a THREAT-VPN-CredentialStuffing detection rule?

df00tech provides THREAT-VPN-CredentialStuffing (VPN and Remote Access Credential Stuffing / Brute Force) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the THREAT-VPN-CredentialStuffing detection?

The THREAT-VPN-CredentialStuffing detection is rated high severity with high confidence.

What are common false positives for THREAT-VPN-CredentialStuffing?

Common false positives for THREAT-VPN-CredentialStuffing include: Legitimate users with incorrect VPN credentials due to recent password change (brief surge then success with new credentials); Misconfigured VPN clients that retry with old credentials on every connection attempt; Automated backup or monitoring systems with outdated credentials attempting VPN authentication.

THREAT-VPN-CredentialStuffing

VPN and Remote Access Credential Stuffing / Brute Force

Q: What data sources are required to detect VPN and Remote Access Credential Stuffing / Brute Force (THREAT-VPN-CredentialStuffing)?

Detecting VPN and Remote Access Credential Stuffing / Brute Force requires the following data sources: CommonSecurityLog (CEF from VPN appliances), Syslog (VPN appliance native logging), Azure Sentinel built-in connectors for Fortinet, Palo Alto, Cisco.

Credential Access Initial Access Last updated: June 20, 2026

Credential stuffing and brute force against VPN and remote access gateways is a persistent initial access vector for ransomware operators and nation-state actors. NCSC and CISA have repeatedly warned about Fortinet, Cisco ASA/FTD, Ivanti Connect Secure, Palo Alto GlobalProtect, and SonicWall VPN gateways being targeted. Attackers use credential databases from prior breaches and automated tools to test credentials at scale against VPN login portals. Unlike password spraying against M365, VPN credential stuffing often targets a single account at high frequency (bypassing account lockout through IP rotation) or uses a large pool of breached credential pairs. Volt Typhoon (China-nexus) specifically targets small business routers and VPN gateways for SOHO Living-off-the-Land access. Compromised VPN access gives attackers direct network access, bypassing perimeter defences entirely.

What is THREAT-VPN-CredentialStuffing VPN and Remote Access Credential Stuffing / Brute Force?

VPN and Remote Access Credential Stuffing / Brute Force (THREAT-VPN-CredentialStuffing) maps to the Credential Access and Initial Access tactics — the adversary is trying to steal account names and passwords in MITRE ATT&CK.

This page provides production-ready detection logic for VPN and Remote Access Credential Stuffing / Brute Force, covering the data sources and telemetry it touches: CommonSecurityLog (CEF from VPN appliances), Syslog (VPN appliance native logging), Azure Sentinel built-in connectors for Fortinet, Palo Alto, Cisco. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic: Credential Access Initial Access

Microsoft Sentinel / Defender

kusto

// THREAT: VPN / Remote Access Credential Stuffing
// Detects brute force and credential stuffing against VPN authentication
// Sources: CommonSecurityLog (CEF from firewall/VPN appliances), Syslog

// Alert 1: High-volume authentication failures against VPN
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor has_any ("Fortinet", "Cisco", "Palo Alto", "SonicWall", "Pulse Secure", "Ivanti", "Juniper")
| where Activity has_any ("vpn", "ipsec", "ssl-vpn", "remote-access", "authentication")
| where Message has_any ("failed", "failure", "invalid", "rejected", "denied")
    or LogSeverity >= 5
| summarize
    FailureCount=count(),
    UniqueUsers=dcount(DestinationUserName),
    TargetUsers=make_set(DestinationUserName),
    UniqueSourceIPs=dcount(SourceIP),
    SourceIPs=make_set(SourceIP)
  by DeviceAddress, DeviceVendor, bin(TimeGenerated, 15m)
| where FailureCount >= 20 or UniqueUsers >= 5
| extend ThreatType = "VPN_CredentialStuffing"
| extend Severity = iff(FailureCount >= 100, "Critical", iff(FailureCount >= 50, "High", "Medium"))
| sort by FailureCount desc;
// Alert 2: Successful VPN connection from previously-failing IP
let VPNFailingIPs = CommonSecurityLog
| where TimeGenerated > ago(24h)
| where Activity has_any ("vpn", "ssl-vpn", "remote-access")
| where Message has_any ("failed", "failure", "invalid", "rejected")
| summarize Failures=count() by SourceIP
| where Failures >= 10
| distinct SourceIP;
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where Activity has_any ("vpn", "ssl-vpn", "remote-access")
| where Message has_any ("success", "established", "connected", "authenticated")
| where SourceIP in (VPNFailingIPs)
| project TimeGenerated, SourceIP, DestinationUserName, DeviceVendor,
    DeviceAddress, Activity, Message
| extend ThreatType = "VPN_SuccessAfterCredentialStuffing"
| extend Severity = "Critical"

Two-stage VPN credential stuffing detection: (1) high-volume authentication failures from single or multiple sources against VPN gateway — the stuffing pattern; (2) successful VPN authentication from an IP that previously failed 10+ times — the compromise indicator. Alert 2 should trigger immediate investigation as it indicates a successful account takeover via credential stuffing.

high severity high confidence

Data Sources

CommonSecurityLog (CEF from VPN appliances) Syslog (VPN appliance native logging) Azure Sentinel built-in connectors for Fortinet, Palo Alto, Cisco

Required Tables

CommonSecurityLog Syslog

False Positives

Legitimate users with incorrect VPN credentials due to recent password change (brief surge then success with new credentials)
Misconfigured VPN clients that retry with old credentials on every connection attempt
Automated backup or monitoring systems with outdated credentials attempting VPN authentication
Multiple users behind a shared corporate NAT connecting to VPN simultaneously (same source IP, multiple users)

IBM QRadar (AQL)

sql

SELECT
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:mm') AS TimeWindow,
  sourceip AS SourceIP,
  destinationip AS DeviceAddress,
  username AS TargetUser,
  LOGSOURCETYPENAME(devicetype) AS VendorType,
  COUNT(*) AS FailureCount,
  COUNT(DISTINCT username) AS UniqueUsers,
  COUNT(DISTINCT sourceip) AS UniqueSourceIPs
FROM events
WHERE
  LOGSOURCETYPENAME(devicetype) ILIKE ANY ('%Fortinet%', '%Cisco%', '%Palo Alto%', '%SonicWall%', '%Pulse Secure%', '%Ivanti%', '%Juniper%')
  AND (
    LOWER(category) ILIKE ANY ('%vpn%', '%ssl-vpn%', '%ipsec%', '%remote-access%', '%authentication%')
    OR LOWER(qidname(qid)) ILIKE ANY ('%vpn%', '%remote access%')
  )
  AND (
    LOWER(eventdirection) IN ('l2r', 'r2l')
    AND (
      LOWER(category) ILIKE ANY ('%fail%', '%failure%', '%invalid%', '%rejected%', '%denied%')
      OR magnitude >= 5
    )
  )
  AND starttime >= NOW() - 86400000
GROUP BY
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:mm'),
  sourceip,
  destinationip,
  username,
  LOGSOURCETYPENAME(devicetype)
HAVING COUNT(*) >= 20 OR COUNT(DISTINCT username) >= 5
ORDER BY FailureCount DESC

Detects high-volume VPN authentication failures indicative of credential stuffing or brute force against VPN/remote access gateways (Fortinet, Cisco, Palo Alto, SonicWall, Ivanti, Juniper). Alerts when 20+ failures or 5+ unique users are targeted within a 15-minute window from a source IP.

high severity high confidence

Data Sources

Fortinet FortiGate Cisco ASA Cisco FTD Palo Alto Networks SonicWall Ivanti Connect Secure Juniper Networks

Required Tables

events

False Positives

Misconfigured VPN clients repeatedly failing authentication due to expired certificates or wrong credentials
Automated service accounts or monitoring tools performing repeated VPN connectivity checks
Legitimate mass remote access during large-scale business events such as all-hands days or system migrations
Security teams running authorised penetration tests or VPN stress tests
Users with forgotten or recently changed passwords generating repeated failures across multiple devices

Sumo Logic CSE

sql

// Alert 1: High-volume VPN authentication failures
(_sourceCategory="network/vpn" OR _sourceCategory="firewall/fortigate" OR _sourceCategory="firewall/cisco/asa" OR _sourceCategory="firewall/cisco/ftd" OR _sourceCategory="firewall/paloalto" OR _sourceCategory="firewall/sonicwall" OR _sourceCategory="vpn/ivanti" OR _sourceCategory="firewall/juniper")
| where (action in ("failure","failed","denied","rejected") or (type in ("vpn","ssl-vpn","ipsec","remote-access","auth")))
| where !(action in ("success","established","connected","authenticated"))
| timeslice 15m
| stats count as FailureCount, dcount(user) as UniqueUsers, dcount(src_ip) as UniqueSourceIPs, values(user) as TargetedUsers by dest_ip, _timeslice
| where FailureCount >= 20 or UniqueUsers >= 5
| if (FailureCount >= 100, "CRITICAL", if (FailureCount >= 50, "HIGH", "MEDIUM")) as Severity
| fields _timeslice, dest_ip, FailureCount, UniqueUsers, UniqueSourceIPs, TargetedUsers, Severity
| sort by FailureCount desc

// Alert 2: Successful VPN login from IP with prior failures
// Step 1 — collect failing IPs (run as subquery or scheduled lookup)
// (_sourceCategory="network/vpn" OR _sourceCategory="firewall/*")
// | where action in ("failure","failed","denied","rejected") and type in ("vpn","ssl-vpn","remote-access")
// | stats count as Failures by src_ip | where Failures >= 10
// Step 2 — join successes against that list
(_sourceCategory="network/vpn" OR _sourceCategory="firewall/fortigate" OR _sourceCategory="firewall/cisco/asa" OR _sourceCategory="firewall/paloalto" OR _sourceCategory="firewall/sonicwall" OR _sourceCategory="vpn/ivanti")
| where action in ("success","established","connected","authenticated") and type in ("vpn","ssl-vpn","remote-access")
| lookup Failures from path://"/shared/VPN_FailingIPs" on src_ip
| where Failures >= 10
| fields _messageTime, src_ip, user, dest_ip, action, type, Failures
| concat("CRITICAL") as Severity

Two-part detection for VPN credential stuffing in Sumo Logic. Part 1 aggregates authentication failures per destination device over 15-minute windows and alerts on high failure counts or many unique targeted users. Part 2 cross-references successful VPN logins against IPs that previously generated 10+ failures.

high severity high confidence

Data Sources

Fortinet FortiGate Cisco ASA Cisco FTD Palo Alto Networks SonicWall Ivanti Connect Secure Juniper Networks

Required Tables

network/vpn firewall/fortigate firewall/cisco/asa firewall/cisco/ftd firewall/paloalto firewall/sonicwall vpn/ivanti firewall/juniper

False Positives

Automated VPN reconnection loops from mobile devices with unstable connectivity
Large-scale password resets causing waves of authentication failures across the user base
Vulnerability scanners or network health monitors probing VPN endpoints
Branch office routers performing scheduled VPN tunnel renegotiations that briefly appear as failures
Outsourced IT or MSP teams authenticating from shared IP ranges that trigger volume thresholds

Google Chronicle / SecOps

yaral

rule vpn_credential_stuffing {
  meta:
    author = "df00tech"
    description = "Detects credential stuffing and brute force against VPN and remote access gateways"
    severity = "HIGH"
    priority = "HIGH"
    reference = "NCSC Advisory AA24-060A, CISA Advisory AA23-347A"
    threat_actors = "Volt Typhoon, LockBit affiliates"
    mitre_attack_tactic = "Initial Access"
    mitre_attack_technique = "T1110.004"
    version = "1.0"

  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = /(?i)(fortinet|cisco|palo alto|sonicwall|pulse secure|ivanti|juniper)/
    (
      $auth.security_result.action = "BLOCK"
      OR $auth.security_result.action_details = /(?i)(fail|failure|invalid|reject|denied|bad.password)/
    )
    (
      $auth.target.application = /(?i)(vpn|ssl.vpn|ipsec|remote.access)/
      OR $auth.network.application_protocol = /(?i)(ipsec|ssl)/
    )
    $auth.principal.ip = $src_ip
    $auth.target.ip = $dest_ip

  match:
    $src_ip, $dest_ip over 15m

  outcome:
    $failure_count = count_distinct($auth.metadata.id)
    $unique_users = count_distinct($auth.target.user.userid)
    $targeted_users = array_distinct($auth.target.user.userid)
    $vendor = array_distinct($auth.metadata.vendor_name)
    $severity_label = if($failure_count >= 100, "CRITICAL",
                       if($failure_count >= 50, "HIGH", "MEDIUM"))

  condition:
    #auth >= 20 or $unique_users >= 5
}

YARA-L 2.0 rule for Google Chronicle SIEM that detects VPN credential stuffing by aggregating blocked or failed login events from VPN/remote access vendors over 15-minute windows. Triggers when 20+ failures originate from the same source IP targeting the same VPN gateway, or when 5+ unique user accounts are targeted.

high severity high confidence

Data Sources

Fortinet FortiGate Cisco ASA Cisco FTD Palo Alto Networks SonicWall Ivanti Connect Secure Juniper Networks

Required Tables

USER_LOGIN UDM events with vendor_name matching VPN appliance vendors

False Positives

Scheduled network monitoring or SIEM health-check tools generating repeated authentication attempts
VPN clients with cached stale credentials retrying automatically after password changes
Corporate proxy or NAT devices making all remote workers appear as a single source IP, inflating per-IP failure counts
Red team or penetration testing engagements against VPN infrastructure
ISP CGNAT causing unrelated users to share an IP that collectively exceeds thresholds

CrowdStrike LogScale (CQL)

cql

// Alert 1: High-volume VPN authentication failures (CrowdStrike Falcon LogScale / Next-Gen SIEM)
#event_simpleName = "NetworkConnectionIP4"
| vendor = /(?i)(fortinet|cisco|palo.alto|sonicwall|pulse.secure|ivanti|juniper)/i
| activity = /(?i)(vpn|ssl-vpn|ipsec|remote-access|authentication)/i
| action = /(?i)(fail|failure|invalid|reject|denied|blocked)/i
| groupBy([RemoteAddressIP4, LocalAddressIP4, vendor], function=[
    count(aid, as=FailureCount),
    count(distinct=UserName, as=UniqueUsers),
    collect(UserName, max=50, as=TargetedUsers),
    count(distinct=RemoteAddressIP4, as=UniqueSourceIPs)
  ],
  limit=max, start=24h
)
| FailureCount >= 20 OR UniqueUsers >= 5
| eval Severity := case {
    FailureCount >= 100 => "CRITICAL",
    FailureCount >= 50  => "HIGH",
    default             => "MEDIUM"
  }
| eval ThreatType := "VPN_CredentialStuffing"
| eval ThreatActors := "Volt Typhoon, LockBit affiliates, GhostSec"
| sort(FailureCount, order=desc, limit=1000)

// Alert 2: Successful VPN login from previously-failing IP
// Step 1 — build failing IP set
// #event_simpleName = "NetworkConnectionIP4"
// | action = /(?i)(fail|failure|reject|denied)/i
// | activity = /(?i)(vpn|ssl-vpn|remote-access)/i
// | groupBy([RemoteAddressIP4], function=count(aid, as=Failures), limit=max, start=24h)
// | Failures >= 10
// | saveToLookup("VPN_FailingIPs", field=RemoteAddressIP4, ttl=86400)
// Step 2 — match successes to that set
#event_simpleName = "NetworkConnectionIP4"
| action = /(?i)(success|established|connected|authenticated)/i
| activity = /(?i)(vpn|ssl-vpn|remote-access)/i
| match("VPN_FailingIPs", field=RemoteAddressIP4, include=[])
| eval ThreatType := "VPN_SuccessAfterCredentialStuffing"
| eval Severity := "CRITICAL"
| select([timestamp, RemoteAddressIP4, UserName, LocalAddressIP4, vendor, action, ThreatType, Severity])

Two-part CrowdStrike Falcon LogScale (Next-Gen SIEM) detection for VPN credential stuffing. Part 1 groups network authentication failures by source IP and VPN gateway over a 24-hour window and alerts on high failure volumes or many targeted accounts. Part 2 identifies successful VPN connections from IPs that previously generated 10+ failures, indicating a successful credential stuffing compromise.

high severity high confidence

Data Sources

CrowdStrike Falcon Network Containment Third-party VPN syslog ingested via Falcon LogScale collector Fortinet FortiGate via LogScale connector Cisco ASA/FTD via syslog forwarder

Required Tables

NetworkConnectionIP4 VPN_FailingIPs (LogScale lookup populated by scheduled query)

False Positives

Legitimate remote workers reconnecting after office Wi-Fi drops cause repeated fast-reconnect failures before a successful session
VPN load balancers presenting a single destination IP that aggregates failures from many unrelated source IPs
Security awareness training platforms simulating phishing that also test VPN credential reuse
Authorised red team exercises targeting VPN gateways
Travelling employees repeatedly failing due to geo-blocked IP ranges or MFA prompt timeouts before eventually succeeding

Sigma rule & cross-platform mapping

The detection logic for VPN and Remote Access Credential Stuffing / Brute Force (THREAT-VPN-CredentialStuffing) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for THREAT-VPN-CredentialStuffing Sigma rules on detection.fyi

Platform-specific guides for THREAT-VPN-CredentialStuffing

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)

Last updated: 2026-06-20 Research depth: deep

References (4)

Testing Methodology

Validate this detection against 1 adversary technique 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 1VPN Credential Stuffing Simulation via Python Requests
Expected signal: VPN authentication logs record multiple failures (error: invalid credentials) for multiple usernames from the test IP within the 15-minute window.

Response Playbook

Triage

Identify the source IP(s) of the credential stuffing. Check AbuseIPDB, Shodan, and VirusTotal for IP reputation. Stuffing typically originates from VPS hosts, botnets, or residential proxies.
For successful VPN authentications following stuffing: immediately identify the account and their last legitimate authentication. When did they last successfully VPN in? From where? Has their device changed?
Verify with the user: contact them via phone or secondary communication channel to confirm whether they initiated the VPN session.
If VPN access is confirmed as unauthorised: immediately terminate the VPN session, disable the account, and assess what the attacker accessed during the session.
Review VPN session logs for the compromised account: which resources did they access? Did they attempt lateral movement? Did they download or access sensitive files?

Containment

Block the stuffing source IP(s) at the perimeter firewall and in the VPN gateway IP blacklist.
For accounts with successful authentication from stuffing IP: terminate active sessions, disable account, reset password, require MFA re-enrollment.
Implement VPN geo-blocking if your workforce is geographically concentrated — block VPN connections from countries where you have no employees.
Deploy multi-factor authentication on the VPN if not already implemented — credential stuffing is ineffective against VPN MFA.
Consider implementing client certificate authentication for VPN as an additional factor — certificates cannot be stuffed.
Apply temporary IP rate limiting on the VPN login endpoint to slow credential stuffing operations.

Evidence Collection

VPN authentication logs: all failure/success events for the incident window, including usernames and source IPs
VPN session logs: resource access, traffic volume, duration for successful sessions from stuffing IPs
Network flow logs from authenticated VPN session: lateral movement attempts, scanning activity
Threat intelligence lookups for source IPs

Escalation Criteria

! Successful VPN authentication from a credential-stuffed IP — immediate incident declaration
! Post-VPN-access lateral movement indicators (net use, SMB connections to file servers, RDP to internal hosts)
! VPN access to domain controllers or sensitive server segments
! Data transfer volume significantly above baseline during the suspicious VPN session

Investigation Guide

Forensic Artifacts

> VPN authentication logs with timestamps, usernames, source IPs, and success/failure
> VPN session records: connected IP, session duration, traffic volume
> RADIUS/LDAP authentication logs if VPN authentication is federated
> Network flow logs from VPN-to-internal-network segment during suspicious session

Tuning Guidance

VPN credential stuffing thresholds depend heavily on your environment. For small organisations with few remote users, even 5 failures from a single source in 15 minutes may be anomalous. For large organisations with many remote workers, failure rates may be higher due to legitimate connection issues. The most actionable signal is the success-after-failure detection — tune the failure prerequisite threshold down for high-security environments (as low as 5 failures) since a successful authentication following any unusual failure pattern warrants investigation. Also consider alerting on VPN logins outside business hours for accounts that have never historically accessed VPN at those times.

Hunting Queries

Hunt for IPs with both high failure rates and at least one success against VPN authentication — the credential stuffing to compromise pattern across any time window.

Hunting — KQL

kql

CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("Fortinet", "Cisco", "Palo Alto", "SonicWall", "Ivanti")
| where Activity has_any ("vpn", "ssl-vpn", "remote-access")
| summarize
    TotalAttempts=count(),
    Failures=countif(Message has_any ("fail", "invalid", "reject")),
    Successes=countif(Message has_any ("success", "connected", "established"))
  by SourceIP, bin(TimeGenerated, 1d)
| where Failures >= 10 and Successes >= 1
| extend SuccessAfterFailure = (Successes >= 1 and Failures >= 10)
| sort by Failures desc

Hunting — SPL

spl

index=network sourcetype IN ("fortigate:vpn","cisco:asa","panos:traffic")
  (action="failure" OR action="success") type="vpn"
| eval result=if(action="success", "success", "failure")
| bin _time span=1d
| stats sum(eval(if(result="failure",1,0))) AS Failures,
        sum(eval(if(result="success",1,0))) AS Successes
  BY src_ip, _time
| where Failures >= 10 AND Successes >= 1
| sort - Failures

Atomic Red Team Tests

Test 1 VPN Credential Stuffing Simulation via Python Requests

linux

Simulates a credential stuffing attack against a VPN web portal by iterating through a list of username/password pairs. This tests detection of high-volume authentication failures from a single source.

Command

bash

python3 -c "
import requests, time
creds = [('[email protected]','password123'),('[email protected]','Spring2025!'),
         ('[email protected]','Admin123!'),('[email protected]','Welcome1!')]
for user, pwd in creds * 5:
    r = requests.post('https://<VPN_PORTAL>/login', data={'username':user,'password':pwd}, verify=False)
    print(f'{user}: {r.status_code}')
    time.sleep(1)
"

Expected Telemetry

VPN authentication logs record multiple failures (error: invalid credentials) for multiple usernames from the test IP within the 15-minute window.

Expected Detection

Alert fires when FailureCount >= 20 or UniqueUsers >= 5 within the 15-minute aggregation window.

Related Detections

What is THREAT-VPN-CredentialStuffing VPN and Remote Access Credential Stuffing / Brute Force?

MITRE ATT&CK

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Sigma rule & cross-platform mapping

Platform-specific guides for THREAT-VPN-CredentialStuffing

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Expected Telemetry

Expected Detection

Related Detections

Tactic Hubs

Parent Technique

Related Techniques

Same Tactic: Credential Access

Popular Detections

Get new detections in your inbox