Credential_access — CraftedSignal Threat Feed

Entra ID Excessive Account Lockouts Detected

hello@craftedsignal.io — Wed, 22 Apr 2026 18:43:05 +0000

This 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 “familiar” and “unfamiliar” 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.

Attack Chain

Initial Access: The attacker attempts to gain access to Entra ID accounts using compromised or guessed credentials.
Password Spraying/Credential Stuffing: 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.
Authentication Failure: The sign-in attempts fail due to incorrect credentials, resulting in authentication failure events in Entra ID sign-in logs.
Smart Lockout Triggered: Entra ID’s Smart Lockout feature detects the repeated failed sign-in attempts from unfamiliar IPs, triggering account lockouts and generating error code 50053.
Account Lockout: The target user accounts are locked out, preventing legitimate users from accessing their accounts.
Potential Enumeration: Prior to the lockouts, the attacker may perform username enumeration, resulting in error code 50034 (user not found) in the sign-in logs.
MFA Bypass Attempt (if applicable): If MFA is not enforced or bypassed, the attacker may attempt to gain access using single-factor authentication.
Account Compromise (if successful): If the attacker successfully guesses the password before lockout or bypasses MFA, the account is compromised, allowing unauthorized access to resources.

Impact

A 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.

Recommendation

Deploy the Sigma rule “Entra ID Excessive Account Lockouts Detected” to your SIEM to detect high counts of failed sign-in attempts resulting in account lockouts.
Investigate alerts generated by the Sigma rule by pivoting to the raw logs in Discover or Timeline using the provided query and focusing on event.dataset: "azure.signinlogs" and azure.signinlogs.properties.status.error_code: 50053.
Block suspicious source IPs identified in the investigation using Conditional Access named locations to prevent further brute-force attempts.
Implement Conditional Access policies to block legacy authentication protocols like IMAP, SMTP, and POP, which are often targeted in password spraying attacks.
Review and enhance Conditional Access policies to ensure comprehensive MFA coverage and prevent MFA bypass attempts.

PowerShell Kerberos Ticket Request via KerberosRequestorSecurityToken

hello@craftedsignal.io — Tue, 09 Jan 2024 18:45:00 +0000

This detection identifies PowerShell scripts leveraging the KerberosRequestorSecurityToken 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 KerberosRequestorSecurityToken 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.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system, potentially through phishing, compromised credentials, or exploiting a vulnerability.
Execution: The attacker executes a PowerShell script, either interactively or via a scheduled task or other means of remote execution.
Obfuscation (Optional): The PowerShell script may be obfuscated to evade detection, using techniques such as Base64 encoding or string manipulation.
Ticket Request: The script uses the KerberosRequestorSecurityToken class to request Kerberos service tickets for one or more SPNs.
Data Collection: The script collects the requested service tickets and potentially saves them to a file or transmits them over the network.
Credential Access: The attacker extracts the Kerberos hashes from the collected tickets.
Offline Cracking: The attacker uses tools like John the Ripper or Hashcat to crack the service account passwords offline.
Privilege Escalation/Lateral Movement: Upon successfully cracking the passwords, the attacker uses the compromised credentials to escalate privileges or move laterally within the network.

Impact

Successful 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’s medium severity reflects the potential for significant impact if the attack succeeds.

Recommendation

Enable PowerShell Script Block Logging to capture the PowerShell script content necessary for detection, and ensure the logs are being ingested into your SIEM. Reference: Setup instructions.
Deploy the Sigma rule “PowerShell Kerberos Ticket Request” to your SIEM to detect suspicious use of KerberosRequestorSecurityToken in PowerShell scripts.
Investigate 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.
Review Windows Security event logs on domain controllers for event ID 4769, filtering for the TargetUserName associated with the alerting user to identify related Kerberos ticket requests.

Suspicious AWS EC2 Key Pair Creation from Non-Cloud AS

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or a misconfigured IAM role.
The attacker attempts to enumerate existing EC2 instances and associated key pairs.
The attacker uses the CreateKeyPair 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.
The attacker stores the private key material for later use in accessing EC2 instances.
The 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 RunInstances or ImportKeyPair operations.
The attacker uses the new key pair to SSH into the newly created or compromised EC2 instances.
Once inside the instances, the attacker performs malicious activities, such as data exfiltration, lateral movement, or installing malware.

Impact

Successful 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 CreateKeyPair event raises the risk profile.

Recommendation

Deploy the Sigma rule “AWS EC2 CreateKeyPair from Non-Cloud AS Organization” to your SIEM and tune the source.as.organization.name exclusions based on your environment.
Review AWS CloudTrail logs for any CreateKeyPair events and correlate with other suspicious activity, as mentioned in the investigation steps in this brief.
Implement stricter IAM policies to limit the ability to create key pairs to only authorized users and roles.
Monitor for RunInstances or ImportKeyPair events using the newly created key names as identified from aws.cloudtrail.request_parameters / response_elements.
Enable and review AWS Config rules to detect and remediate misconfigurations related to IAM and EC2 key pair management.

Potential Kerberos Relay Attack via Coerced Authentication against a Computer Account

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

Attacker compromises a machine within the target network.
Attacker 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.
The target server attempts to authenticate to the attacker-controlled machine.
The attacker relays the Kerberos authentication attempt to a service on another server, impersonating the target server.
A Kerberos authentication event (Event ID 4624 or 4625) is generated, indicating a network logon attempt using Kerberos. The account used ends with ‘$’, signifying a computer account.
The source IP address of the authentication event is different from the target server’s IP address, indicating the authentication attempt originated from a different host.
If successful (Event ID 4624), the attacker gains unauthorized access to the service on the second server, impersonating the target server’s computer account.
The attacker executes commands or performs actions on the compromised service, potentially leading to data exfiltration, system compromise, or further lateral movement.

Impact

A 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.

Recommendation

Deploy the Sigma rule “Potential Kerberos Relay Attack against a Computer Account” to your SIEM to detect this activity and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on the sequence of events and the source IP address involved.
Patch CVE-2025-33073 on all affected Windows servers to prevent reflective Kerberos relay attacks.
Enable SMB signing or service-specific signing/sealing/channel binding on affected service tiers to mitigate relay attacks.
Monitor Windows Security Event Logs for Event ID 5145 (file access) and Event IDs 4624/4625 (authentication attempts) for suspicious activity.
Restrict coercion-prone RPC and named-pipe exposure to limit the attack surface.

Kubernetes Pod Exec Cloud Instance Metadata Access

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

Attacker gains initial access to a Kubernetes cluster.
Attacker identifies a vulnerable pod within the cluster.
The attacker uses kubectl exec to gain shell access to the pod.
Inside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.
The command, often using curl or wget, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.
The IMDS responds with the requested data, which may include credentials or configuration details.
The attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.
Attacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.

Impact

Compromised 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.

Recommendation

Deploy the Sigma rule Kubernetes Pod Exec IMDS Access to detect suspicious command-line activity within Kubernetes pods.
Block access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.
Regularly review and tighten RBAC permissions related to pods/exec to limit the ability of attackers to gain shell access.
Monitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.
Implement workload identity solutions to avoid the need to expose instance metadata to pods.
Baseline approved images and tune exclusions narrowly to avoid false positives.

LSASS Memory Dump Creation Detection

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This 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 lsass*.dmp, dumpert.dmp, Andrew.dmp, SQLDmpr*.mdmp, and Coredump.dmp. 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.

Attack Chain

An attacker gains initial access to a Windows system (e.g., through phishing or exploiting a vulnerability).
The 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.
The tool writes the LSASS memory dump to a file with a name matching a known pattern, such as lsass.dmp, dumpert.dmp, or SQLDmpr0001.mdmp.
The file is created in a location that is not a known legitimate crash dump location (e.g., not in \Windows\System32\config\systemprofile\AppData\Local\CrashDumps\).
The attacker may move, copy, or archive the dump file to avoid detection or to prepare it for exfiltration.
The attacker uses another tool, such as Mimikatz, to parse the LSASS memory dump and extract credentials.
The attacker uses the extracted credentials to move laterally to other systems or to access sensitive data.
The final objective is often to gain domain administrator privileges or to exfiltrate sensitive data.

Impact

Successful 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.

Recommendation

Enable Sysmon FileCreate events (Event ID 11) to capture the creation of LSASS memory dump files.
Deploy the Sigma rule LSASS Memory Dump Creation to your SIEM to detect suspicious LSASS memory dump creation events and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on the process executable, parent process, file path, and user context.
If a suspicious LSASS memory dump is found, isolate the affected host and begin credential hygiene for implicated accounts and systems.
Block known malicious tools like Dumpert and AndrewSpecial from running on your network.
Monitor for related credential-access, staging, privilege, or lateral-movement alerts for the same user or host.