{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/credential_access/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Entra ID"],"_cs_severities":["high"],"_cs_tags":["azure","entra_id","credential_access","brute_force"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies a surge in failed Microsoft Entra ID sign-in attempts (error code 50053) due to account lockouts, suggesting potential brute-force attacks. Attackers often employ password spraying, credential stuffing, or automated guessing to compromise accounts. This detection uses a threshold-based approach to identify coordinated campaigns targeting multiple users. The Entra ID Smart Lockout feature triggers error code 50053, utilizing IP-based tracking to differentiate between \u0026ldquo;familiar\u0026rdquo; and \u0026ldquo;unfamiliar\u0026rdquo; locations, with lockouts primarily originating from unfamiliar IPs. Successful exploitation can lead to unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker attempts to gain access to Entra ID accounts using compromised or guessed credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePassword Spraying/Credential Stuffing:\u003c/strong\u003e The attacker performs password spraying attacks by attempting common passwords across multiple accounts, or credential stuffing attacks by using lists of breached credentials obtained from other sources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Failure:\u003c/strong\u003e The sign-in attempts fail due to incorrect credentials, resulting in authentication failure events in Entra ID sign-in logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSmart Lockout Triggered:\u003c/strong\u003e Entra ID\u0026rsquo;s Smart Lockout feature detects the repeated failed sign-in attempts from unfamiliar IPs, triggering account lockouts and generating error code 50053.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Lockout:\u003c/strong\u003e The target user accounts are locked out, preventing legitimate users from accessing their accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePotential Enumeration:\u003c/strong\u003e Prior to the lockouts, the attacker may perform username enumeration, resulting in error code 50034 (user not found) in the sign-in logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMFA Bypass Attempt (if applicable):\u003c/strong\u003e If MFA is not enforced or bypassed, the attacker may attempt to gain access using single-factor authentication.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Compromise (if successful):\u003c/strong\u003e If the attacker successfully guesses the password before lockout or bypasses MFA, the account is compromised, allowing unauthorized access to resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful brute-force attack against Entra ID can lead to widespread account compromise. This could result in unauthorized access to sensitive data, business disruption, and potential financial loss. An attacker could leverage compromised accounts to move laterally within the network, escalate privileges, and exfiltrate data. This attack can affect any organization using Microsoft Entra ID for identity and access management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Entra ID Excessive Account Lockouts Detected\u0026rdquo; to your SIEM to detect high counts of failed sign-in attempts resulting in account lockouts.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by pivoting to the raw logs in Discover or Timeline using the provided query and focusing on \u003ccode\u003eevent.dataset: \u0026quot;azure.signinlogs\u0026quot; and azure.signinlogs.properties.status.error_code: 50053\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eBlock suspicious source IPs identified in the investigation using Conditional Access named locations to prevent further brute-force attempts.\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies to block legacy authentication protocols like IMAP, SMTP, and POP, which are often targeted in password spraying attacks.\u003c/li\u003e\n\u003cli\u003eReview and enhance Conditional Access policies to ensure comprehensive MFA coverage and prevent MFA bypass attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T18:43:05Z","date_published":"2026-04-22T18:43:05Z","id":"/briefs/2024-01-30-entra-id-lockouts/","summary":"A high volume of failed Microsoft Entra ID sign-in attempts resulting in account lockouts indicates potential brute-force attacks, such as password spraying or credential stuffing, targeting user accounts.","title":"Entra ID Excessive Account Lockouts Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-30-entra-id-lockouts/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Security"],"_cs_severities":["high"],"_cs_tags":["kerberoasting","credential_access","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies PowerShell scripts leveraging the \u003ccode\u003eKerberosRequestorSecurityToken\u003c/code\u003e class to request Kerberos service tickets. Attackers often use this technique to perform Kerberoasting, where they obtain service tickets for various service principal names (SPNs) and crack the associated service account passwords offline. This activity can be indicative of an attacker attempting to gain unauthorized access to sensitive resources within the network. The rule is designed to trigger on potentially malicious uses of \u003ccode\u003eKerberosRequestorSecurityToken\u003c/code\u003e while attempting to filter out legitimate uses, such as those within Sentinel breakpoints or authorized Kerberos diagnostic scripts. Defenders should investigate any instances of this activity to determine whether it represents a genuine threat.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains initial access to a Windows system, potentially through phishing, compromised credentials, or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExecution:\u003c/strong\u003e The attacker executes a PowerShell script, either interactively or via a scheduled task or other means of remote execution.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eObfuscation (Optional):\u003c/strong\u003e The PowerShell script may be obfuscated to evade detection, using techniques such as Base64 encoding or string manipulation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTicket Request:\u003c/strong\u003e The script uses the \u003ccode\u003eKerberosRequestorSecurityToken\u003c/code\u003e class to request Kerberos service tickets for one or more SPNs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Collection:\u003c/strong\u003e The script collects the requested service tickets and potentially saves them to a file or transmits them over the network.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The attacker extracts the Kerberos hashes from the collected tickets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOffline Cracking:\u003c/strong\u003e The attacker uses tools like John the Ripper or Hashcat to crack the service account passwords offline.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation/Lateral Movement:\u003c/strong\u003e Upon successfully cracking the passwords, the attacker uses the compromised credentials to escalate privileges or move laterally within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful Kerberoasting attacks can lead to the compromise of service accounts, potentially granting attackers unauthorized access to critical systems and sensitive data. The impact can range from data breaches and financial losses to complete system compromise and disruption of business operations. The rule\u0026rsquo;s medium severity reflects the potential for significant impact if the attack succeeds.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable PowerShell Script Block Logging to capture the PowerShell script content necessary for detection, and ensure the logs are being ingested into your SIEM. Reference: \u003ca href=\"https://ela.st/powershell-logging-setup\"\u003eSetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;PowerShell Kerberos Ticket Request\u0026rdquo; to your SIEM to detect suspicious use of \u003ccode\u003eKerberosRequestorSecurityToken\u003c/code\u003e in PowerShell scripts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on reconstructing the full script content, identifying the targeted SPNs, and analyzing the process execution context to determine if the activity is malicious.\u003c/li\u003e\n\u003cli\u003eReview Windows Security event logs on domain controllers for event ID 4769, filtering for the \u003ccode\u003eTargetUserName\u003c/code\u003e associated with the alerting user to identify related Kerberos ticket requests.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:45:00Z","date_published":"2024-01-09T18:45:00Z","id":"/briefs/2024-01-09-kerberos-ticket-request/","summary":"This rule detects PowerShell scripts that request Kerberos service tickets using KerberosRequestorSecurityToken, potentially indicating Kerberoasting attacks for offline password cracking of service accounts.","title":"PowerShell Kerberos Ticket Request via KerberosRequestorSecurityToken","url":"https://feed.craftedsignal.io/briefs/2024-01-09-kerberos-ticket-request/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon EC2"],"_cs_severities":["medium"],"_cs_tags":["aws","ec2","keypair","persistence","credential_access","lateral_movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft"],"content_html":"\u003cp\u003eThis alert identifies suspicious activity related to the creation of EC2 key pairs within an AWS environment. Specifically, it focuses on instances where a new IAM principal (user) creates an EC2 key pair from a network source (IP address) whose autonomous system organization is not commonly associated with major cloud providers like Amazon, Google, or Microsoft. Adversaries often create key pairs for persistence or to enable unauthorized access to EC2 instances, potentially leading to data exfiltration or further malicious activities. The rule uses a new terms approach to baseline user activity, reducing noise from repeated actions while still flagging the initial suspicious key pair creation. This activity is flagged as suspicious due to originating from outside trusted ASNs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate existing EC2 instances and associated key pairs.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateKeyPair\u003c/code\u003e API call to generate a new SSH key pair within the AWS account. The request originates from a network with an autonomous system organization not attributed to common cloud providers.\u003c/li\u003e\n\u003cli\u003eThe attacker stores the private key material for later use in accessing EC2 instances.\u003c/li\u003e\n\u003cli\u003eThe attacker may then use the new key pair to launch new EC2 instances or import the key to existing instances. This can be done through \u003ccode\u003eRunInstances\u003c/code\u003e or \u003ccode\u003eImportKeyPair\u003c/code\u003e operations.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the new key pair to SSH into the newly created or compromised EC2 instances.\u003c/li\u003e\n\u003cli\u003eOnce inside the instances, the attacker performs malicious activities, such as data exfiltration, lateral movement, or installing malware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to EC2 instances, potentially compromising sensitive data and disrupting services. A compromised AWS account can allow the attacker to steal data, establish persistence, and move laterally within the cloud environment. The lack of expected cloud provider ASN for the source IP of the \u003ccode\u003eCreateKeyPair\u003c/code\u003e event raises the risk profile.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS EC2 CreateKeyPair from Non-Cloud AS Organization\u0026rdquo; to your SIEM and tune the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions based on your environment.\u003c/li\u003e\n\u003cli\u003eReview AWS CloudTrail logs for any \u003ccode\u003eCreateKeyPair\u003c/code\u003e events and correlate with other suspicious activity, as mentioned in the investigation steps in this brief.\u003c/li\u003e\n\u003cli\u003eImplement stricter IAM policies to limit the ability to create key pairs to only authorized users and roles.\u003c/li\u003e\n\u003cli\u003eMonitor for \u003ccode\u003eRunInstances\u003c/code\u003e or \u003ccode\u003eImportKeyPair\u003c/code\u003e events using the newly created key names as identified from \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e / \u003ccode\u003eresponse_elements\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable and review AWS Config rules to detect and remediate misconfigurations related to IAM and EC2 key pair management.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-aws-ec2-keypair-creation/","summary":"An AWS EC2 CreateKeyPair event triggered by a new principal originating from a network autonomous system (AS) organization not associated with major cloud providers, indicating potential unauthorized access or persistence activity.","title":"Suspicious AWS EC2 Key Pair Creation from Non-Cloud AS","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-ec2-keypair-creation/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2025-33073"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kerberos","relay","credential_access","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies potential Kerberos relay attacks targeting Windows systems. The attack involves coercing a target server to authenticate to an attacker-controlled system, which then relays the authentication to another service. The initial coercion leverages commonly abused named pipes like Spoolss, netdfs, and lsarpc. By capturing and relaying the Kerberos authentication, attackers can impersonate the target server and potentially execute code with elevated privileges. This activity is often associated with lateral movement and privilege escalation within a Windows domain. The detection focuses on the sequence of events, specifically a file access event (5145) against a named pipe, followed by a Kerberos authentication event (4624/4625) originating from a different IP address. Defenders should be aware that successful exploitation may lead to full domain compromise.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker compromises a machine within the target network.\u003c/li\u003e\n\u003cli\u003eAttacker initiates a coerced authentication attempt against a target server, triggering a file access event (Event ID 5145) on the target. This leverages a named pipe such as Spoolss, netdfs, lsarpc, lsass, netlogon, samr, efsrpc, FssagentRpc, eventlog, winreg, srvsvc, dnsserver, dhcpserver or WinsPipe.\u003c/li\u003e\n\u003cli\u003eThe target server attempts to authenticate to the attacker-controlled machine.\u003c/li\u003e\n\u003cli\u003eThe attacker relays the Kerberos authentication attempt to a service on another server, impersonating the target server.\u003c/li\u003e\n\u003cli\u003eA Kerberos authentication event (Event ID 4624 or 4625) is generated, indicating a network logon attempt using Kerberos. The account used ends with \u0026lsquo;$\u0026rsquo;, signifying a computer account.\u003c/li\u003e\n\u003cli\u003eThe source IP address of the authentication event is different from the target server\u0026rsquo;s IP address, indicating the authentication attempt originated from a different host.\u003c/li\u003e\n\u003cli\u003eIf successful (Event ID 4624), the attacker gains unauthorized access to the service on the second server, impersonating the target server\u0026rsquo;s computer account.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands or performs actions on the compromised service, potentially leading to data exfiltration, system compromise, or further lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful Kerberos relay attack can lead to a full compromise of the targeted server, potentially allowing the attacker to execute arbitrary code with SYSTEM privileges. This can result in data exfiltration, service disruption, and further lateral movement within the network. The scope of the impact depends on the privileges of the compromised computer account and the services accessible to it. Organizations that do not properly patch CVE-2025-33073 or implement SMB signing/sealing/channel binding are at higher risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential Kerberos Relay Attack against a Computer Account\u0026rdquo; to your SIEM to detect this activity and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the sequence of events and the source IP address involved.\u003c/li\u003e\n\u003cli\u003ePatch CVE-2025-33073 on all affected Windows servers to prevent reflective Kerberos relay attacks.\u003c/li\u003e\n\u003cli\u003eEnable SMB signing or service-specific signing/sealing/channel binding on affected service tiers to mitigate relay attacks.\u003c/li\u003e\n\u003cli\u003eMonitor Windows Security Event Logs for Event ID 5145 (file access) and Event IDs 4624/4625 (authentication attempts) for suspicious activity.\u003c/li\u003e\n\u003cli\u003eRestrict coercion-prone RPC and named-pipe exposure to limit the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kerberos-relay-via-coerced-auth/","summary":"Detects potential Kerberos relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host, indicating an attacker has captured and relayed Kerberos authentication material to execute code on behalf of the compromised system.","title":"Potential Kerberos Relay Attack via Coerced Authentication against a Computer Account","url":"https://feed.craftedsignal.io/briefs/2024-01-kerberos-relay-via-coerced-auth/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IMDS","GCP Compute Metadata","Azure IMDS"],"_cs_severities":["high"],"_cs_tags":["kubernetes","cloud","credential_access","execution"],"_cs_type":"advisory","_cs_vendors":["AWS","Google","Azure"],"content_html":"\u003cp\u003eThis alert focuses on detecting Kubernetes pod exec sessions that attempt to access cloud instance metadata endpoints. The activity is flagged when the decoded command line of a pod exec session contains references to cloud instance metadata services across AWS, GCP, and Azure. Attackers may exploit this to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor. This is a high-risk behavior because it can expose short-lived cloud credentials to code running inside a container, particularly concerning in multi-tenant and regulated environments. This detection classifies the cloud target and whether the command indicates credential theft or reconnaissance.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eAttacker identifies a vulnerable pod within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e to gain shell access to the pod.\u003c/li\u003e\n\u003cli\u003eInside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.\u003c/li\u003e\n\u003cli\u003eThe command, often using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.\u003c/li\u003e\n\u003cli\u003eThe IMDS responds with the requested data, which may include credentials or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.\u003c/li\u003e\n\u003cli\u003eAttacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised credentials can lead to unauthorized access to sensitive data, lateral movement within the cloud environment, and potential data exfiltration. A successful attack could impact multiple organizations sharing the same Kubernetes cluster. The impact could include financial losses, reputational damage, and regulatory fines, depending on the type of data compromised and the extent of the breach.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Pod Exec IMDS Access\u003c/code\u003e to detect suspicious command-line activity within Kubernetes pods.\u003c/li\u003e\n\u003cli\u003eBlock access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.\u003c/li\u003e\n\u003cli\u003eRegularly review and tighten RBAC permissions related to \u003ccode\u003epods/exec\u003c/code\u003e to limit the ability of attackers to gain shell access.\u003c/li\u003e\n\u003cli\u003eMonitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.\u003c/li\u003e\n\u003cli\u003eImplement workload identity solutions to avoid the need to expose instance metadata to pods.\u003c/li\u003e\n\u003cli\u003eBaseline approved images and tune exclusions narrowly to avoid false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kubernetes-metadata-access/","summary":"Detection of Kubernetes pod exec sessions accessing cloud instance metadata endpoints, indicating potential credential theft from AWS, GCP, or Azure.","title":"Kubernetes Pod Exec Cloud Instance Metadata Access","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-metadata-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel","SQL Server","SQL Server Reporting Services"],"_cs_severities":["medium"],"_cs_tags":["credential_access","lsass","memory_dump","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","SentinelOne"],"content_html":"\u003cp\u003eThis detection rule identifies the creation of LSASS memory dump files on Windows systems, which is a common technique used by attackers to extract credentials. The rule focuses on specific filenames associated with LSASS dumps and tools used for creating these dumps, such as \u003ccode\u003elsass*.dmp\u003c/code\u003e, \u003ccode\u003edumpert.dmp\u003c/code\u003e, \u003ccode\u003eAndrew.dmp\u003c/code\u003e, \u003ccode\u003eSQLDmpr*.mdmp\u003c/code\u003e, and \u003ccode\u003eCoredump.dmp\u003c/code\u003e. The rule excludes known legitimate crash analysis paths and SQLDumper dump locations to reduce false positives. The rule aims to detect credential access attempts through trusted utilities such as Task Manager or SQLDumper, or known tooling such as Dumpert and AndrewSpecial. It is designed to work with data from Elastic Defend, Microsoft Defender XDR, SentinelOne Cloud Funnel, and Sysmon.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker executes a tool or utility to create a memory dump of the LSASS process. This can be done using built-in tools like Task Manager or SQLDumper, or third-party tools like Dumpert or AndrewSpecial.\u003c/li\u003e\n\u003cli\u003eThe tool writes the LSASS memory dump to a file with a name matching a known pattern, such as \u003ccode\u003elsass.dmp\u003c/code\u003e, \u003ccode\u003edumpert.dmp\u003c/code\u003e, or \u003ccode\u003eSQLDmpr0001.mdmp\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe file is created in a location that is not a known legitimate crash dump location (e.g., not in \u003ccode\u003e\\Windows\\System32\\config\\systemprofile\\AppData\\Local\\CrashDumps\\\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker may move, copy, or archive the dump file to avoid detection or to prepare it for exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker uses another tool, such as Mimikatz, to parse the LSASS memory dump and extract credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to move laterally to other systems or to access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe final objective is often to gain domain administrator privileges or to exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and credential extraction can lead to complete domain compromise, unauthorized access to sensitive data, and significant financial or reputational damage. The impact is amplified if the compromised system is a domain controller, jump host, or privileged admin workstation. The rule is designed to detect the initial stage of credential access and prevent further damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon FileCreate events (Event ID 11) to capture the creation of LSASS memory dump files.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eLSASS Memory Dump Creation\u003c/code\u003e to your SIEM to detect suspicious LSASS memory dump creation events and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process executable, parent process, file path, and user context.\u003c/li\u003e\n\u003cli\u003eIf a suspicious LSASS memory dump is found, isolate the affected host and begin credential hygiene for implicated accounts and systems.\u003c/li\u003e\n\u003cli\u003eBlock known malicious tools like Dumpert and AndrewSpecial from running on your network.\u003c/li\u003e\n\u003cli\u003eMonitor for related credential-access, staging, privilege, or lateral-movement alerts for the same user or host.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-lsass-dump-creation/","summary":"This rule identifies the creation of LSASS memory dump files, often indicative of credential access attempts using tools like Task Manager, SQLDumper, Dumpert, or AndrewSpecial, by monitoring for specific filenames and excluding legitimate dump locations.","title":"LSASS Memory Dump Creation Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-lsass-dump-creation/"}],"language":"en","title":"CraftedSignal Threat Feed — Credential_access","version":"https://jsonfeed.org/version/1.1"}