{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/attack.stealth/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EC2"],"_cs_severities":["high"],"_cs_tags":["attack.privilege-escalation","attack.initial-access","attack.persistence","attack.stealth","attack.t1078","attack.t1078.002"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis activity focuses on the potential misuse of AWS Instance Metadata Service (IMDS) credentials. When an EC2 instance is compromised, an attacker can extract the temporary credentials stored within the IMDS. These credentials, associated with an assumed role, grant the attacker the ability to interact with other AWS services. The abnormal use of these credentials outside of the expected AWS Simple Systems Manager (SSM) service may indicate malicious activity such as lateral movement, data exfiltration, or resource compromise. This is particularly concerning when the compromised instance is being used as a pivot point to access other AWS resources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn EC2 instance is compromised through an initial access vector (e.g., software vulnerability, misconfiguration, or credential compromise).\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the compromised EC2 instance\u0026rsquo;s operating system.\u003c/li\u003e\n\u003cli\u003eThe attacker queries the IMDS endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/) to obtain temporary AWS credentials associated with the instance\u0026rsquo;s IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their local AWS CLI or SDK with the exfiltrated credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to perform actions against other AWS services using the exfiltrated credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges or move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access, modify, or exfiltrate sensitive data from other AWS services.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by creating new IAM users or roles with excessive permissions.\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 sensitive data stored in AWS services such as S3, DynamoDB, and RDS. This could result in data breaches, financial loss, and reputational damage. Attackers can also leverage the compromised credentials to pivot to other AWS resources, potentially impacting critical infrastructure and services. Organizations with lax security configurations and overly permissive IAM roles 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;Malicious Usage Of IMDS Credentials Outside Of AWS Infrastructure\u0026rdquo; to your SIEM and tune for your environment to detect anomalous use of IMDS credentials.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM roles assigned to EC2 instances to follow the principle of least privilege, limiting the scope of potential damage from credential exfiltration.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for unusual API calls originating from EC2 instances with assumed roles, specifically those not related to SSM.\u003c/li\u003e\n\u003cli\u003eHarden EC2 instances to prevent initial compromise by applying security patches, configuring strong authentication, and regularly scanning for vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-11T00:00:00Z","date_published":"2024-07-11T00:00:00Z","id":"/briefs/2024-07-aws-imds-abuse/","summary":"Compromised EC2 instances may be leveraged to exfiltrate and misuse AWS Instance Metadata Service (IMDS) credentials to perform actions outside of the expected AWS Simple Systems Manager (SSM) service, indicating potential lateral movement or data exfiltration.","title":"Malicious Usage of AWS IMDS Credentials Outside of Expected Services","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-imds-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Entra ID"],"_cs_severities":["high"],"_cs_tags":["attack.stealth","attack.t1078","attack.persistence","attack.privilege-escalation","attack.initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting suspicious sign-in activity within Azure Active Directory (Azure AD). Specifically, it targets sign-ins originating from countries or regions that are new or unusual for a given user. This behavior can be indicative of compromised credentials, travel without notification, or the use of VPN/proxy services to mask the true origin of the sign-in. Microsoft Entra ID Protection identifies \u0026ldquo;new country\u0026rdquo; as a risk event when a user signs in from a location that is drastically different from their recent sign-in history. Detecting these anomalies is crucial for preventing unauthorized access and mitigating potential data breaches. The detection uses Azure AD\u0026rsquo;s risk detection logs to identify such events.\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 access to a valid user\u0026rsquo;s credentials, potentially through phishing, credential stuffing, or malware. (T1078)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnomalous Login:\u003c/strong\u003e The attacker attempts to sign in to Azure AD using the compromised credentials from a country or region not typically associated with the user.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRisk Detection Trigger:\u003c/strong\u003e Azure AD Identity Protection identifies the sign-in as high-risk due to the new country/region and logs a \u0026ldquo;newCountry\u0026rdquo; risk event.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker may establish persistent access by creating new accounts or modifying existing ones.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e If the compromised account has elevated privileges, the attacker may attempt to escalate their privileges within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker may use the compromised account to move laterally within the organization, accessing other resources and data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker accesses sensitive data and attempts to exfiltrate it from the environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objectives, which could include data theft, financial fraud, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack following a sign-in from a new country can result in unauthorized access to sensitive data, compromised user accounts, and potential data breaches. Organizations may experience financial losses, reputational damage, and legal liabilities. The number of victims and the extent of the damage depend on the privileges of the compromised account and the attacker\u0026rsquo;s objectives. Immediate containment is crucial to prevent further damage if a new country sign-in is verified as malicious.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM or security analytics platform to detect \u0026ldquo;newCountry\u0026rdquo; risk events in Azure AD (logsource: azure, service: riskdetection).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule in the context of other sign-in activities for the affected user to rule out false positives.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users to mitigate the risk of account compromise (T1078).\u003c/li\u003e\n\u003cli\u003eMonitor user activity logs for other suspicious behaviors, such as unusual access patterns or attempts to escalate privileges.\u003c/li\u003e\n\u003cli\u003eReview and enforce conditional access policies to restrict access based on location, device, and other factors.\u003c/li\u003e\n\u003cli\u003eEducate users about phishing and other social engineering tactics to prevent credential theft.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-30-azure-new-country-signin/","summary":"Detection of Azure AD sign-ins originating from countries or regions not previously associated with a user, indicating potential account compromise or anomalous activity.","title":"Azure AD Sign-in from New Country/Region","url":"https://feed.craftedsignal.io/briefs/2024-01-30-azure-new-country-signin/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.initial-access","attack.stealth","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert focuses on detecting potentially risky authentication events within Azure Active Directory. Specifically, it flags successful logins to applications deemed \u0026ldquo;important\u0026rdquo; where the authentication process only involved a single factor. This bypasses the added security of multi-factor authentication (MFA), potentially exposing these applications to compromise if the single factor (e.g., password) is weak, stolen, or compromised. The alert is designed to identify deviations from a secure authentication baseline, particularly in environments where MFA is expected for sensitive resources. The applications considered \u0026ldquo;important\u0026rdquo; must be pre-defined by the defender for this detection to function effectively.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to a valid username and password through phishing, credential stuffing, or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to a pre-defined, high-value application within the Azure AD environment.\u003c/li\u003e\n\u003cli\u003eAzure AD processes the authentication request.\u003c/li\u003e\n\u003cli\u003eThe application is configured to allow single-factor authentication.\u003c/li\u003e\n\u003cli\u003eAzure AD verifies the supplied username and password against its directory.\u003c/li\u003e\n\u003cli\u003eUpon successful verification, Azure AD grants the attacker access to the application.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the application\u0026rsquo;s data and functionality.\u003c/li\u003e\n\u003cli\u003eDepending on the application and attacker\u0026rsquo;s motives, this could lead to data exfiltration, privilege escalation, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe impact of successful single-factor authentication to critical applications can range from minor data breaches to significant compromises of sensitive systems. The number of potential victims depends on the application\u0026rsquo;s user base and the sensitivity of the data it manages. Sectors most at risk include those handling financial, healthcare, or sensitive personal information. A successful attack could lead to data theft, financial loss, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePopulate the \u003ccode\u003eAppId\u003c/code\u003e field in the Sigma rule with the Application IDs of your organization\u0026rsquo;s critical applications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the single-factor authentication.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all users accessing critical applications to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and update Azure AD Conditional Access policies to ensure appropriate authentication requirements are in place.\u003c/li\u003e\n\u003cli\u003eTune the Sigma rule based on observed false positives in your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-03-azure-single-factor-auth/","summary":"Detection of successful Azure AD authentications to critical applications that only required single-factor authentication, potentially indicating a security lapse or policy violation leading to unauthorized access.","title":"Azure AD Authentication to Important Apps Using Single-Factor Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-single-factor-auth/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.initial-access","attack.stealth","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting unauthorized elevation of privileges within Azure environments. Specifically, it addresses the assignment of the \u0026lsquo;User Access Administrator\u0026rsquo; role to a user, which allows managing access to all Azure subscriptions. This activity can be indicative of malicious actors attempting to gain control over an Azure environment or an insider threat escalating their privileges without proper authorization. The detection is based on Azure Audit Logs and can help identify potentially compromised accounts or misconfigurations. A successful elevation can lead to unauthorized access, data breaches, and service disruptions. Defenders should closely monitor these events and investigate any unexpected privilege escalations.\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 Azure account, possibly through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to assign the \u0026lsquo;User Access Administrator\u0026rsquo; role to themselves or another account they control.\u003c/li\u003e\n\u003cli\u003eThis assignment generates an \u0026lsquo;Administrative\u0026rsquo; audit log event with the OperationName \u0026lsquo;Assigns the caller to user access admin\u0026rsquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker now has the ability to manage user access to all Azure subscriptions within the tenant.\u003c/li\u003e\n\u003cli\u003eThe attacker creates new user accounts with elevated privileges within the subscriptions.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly created accounts to access sensitive resources and data.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities to identify critical assets and data stores.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or deploys malicious workloads within the compromised subscriptions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation to the \u0026lsquo;User Access Administrator\u0026rsquo; role can have severe consequences. It grants the attacker complete control over the Azure subscriptions, allowing them to access sensitive data, disrupt services, and potentially compromise the entire cloud environment. The number of affected subscriptions depends on the scope of the compromised account. This attack targets any organization utilizing Azure subscriptions and is particularly impactful for those storing sensitive data or running critical applications in the cloud.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Azure Subscription Permission Elevation Via AuditLogs\u0026rdquo; to your SIEM and tune it for your environment to detect the \u0026lsquo;Assigns the caller to user access admin\u0026rsquo; event in the Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of this event to determine if the privilege elevation was authorized and legitimate.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all Azure accounts to minimize the impact of potential compromises; reference the Microsoft Entra documentation for guidance.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to prevent unauthorized access via compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-03-azure-privilege-elevation/","summary":"Detection of a user being assigned the 'User Access Administrator' role, which grants the ability to manage all Azure Subscriptions, potentially leading to privilege escalation and unauthorized access.","title":"Detection of Azure Subscription Permission Elevation","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-privilege-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Simple Email Service"],"_cs_severities":["medium"],"_cs_tags":["attack.stealth","attack.t1070","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of the \u0026ldquo;DeleteIdentity\u0026rdquo; event within AWS Simple Email Service (SES) logs. An adversary who has gained unauthorized access to an AWS environment and utilized SES for malicious purposes, such as sending phishing emails or distributing malware, might attempt to erase their activity by deleting the SES identity (email address or domain) used in the attack. This action is a form of obfuscation and aims to hinder forensic investigations. While legitimate users may occasionally delete SES identities, the event warrants scrutiny, especially in the context of other suspicious cloud activity.\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 exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker explores the AWS environment, identifying SES as a service to abuse for sending malicious emails.\u003c/li\u003e\n\u003cli\u003eThe attacker configures SES, verifies an email address or domain, and establishes sending capabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts and sends phishing emails or emails containing malicious attachments to external targets.\u003c/li\u003e\n\u003cli\u003eAfter the malicious campaign, the attacker attempts to cover their tracks by deleting the SES identity to remove evidence of their activity.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u0026ldquo;DeleteIdentity\u0026rdquo; API call within SES, specifying the identity to be removed.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs record the \u0026ldquo;DeleteIdentity\u0026rdquo; event, capturing details such as the event source, event name, and user identity.\u003c/li\u003e\n\u003cli\u003eThe attacker may further attempt to delete or modify other CloudTrail logs to eliminate the traces of their actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful deletion of an SES identity hinders incident response and forensic investigations. If an attacker successfully removes the SES identity, it becomes more difficult to trace the origin of malicious emails and attribute the activity to a specific actor. The deletion itself does not directly cause harm, but it obstructs the ability to understand the full scope and impact of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the provided Sigma rule (\u003ccode\u003eSES Identity Has Been Deleted\u003c/code\u003e) to detect SES identity deletion events within your CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eDeleteIdentity\u003c/code\u003e events, correlating them with other suspicious AWS activity, such as unusual IAM role usage or unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eEnable and monitor AWS CloudTrail logs for all regions within your AWS account to ensure comprehensive event capture.\u003c/li\u003e\n\u003cli\u003eImplement strong IAM policies and multi-factor authentication (MFA) to prevent unauthorized access to AWS accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-ses-identity-deleted/","summary":"Detection of an AWS Simple Email Service (SES) identity deletion event, potentially indicating an adversary attempting to cover their tracks after malicious activity.","title":"AWS SES Identity Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-ses-identity-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.initial-access","attack.stealth","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies a potentially malicious increase in successful sign-ins within an Azure Active Directory environment. An attacker who has compromised credentials may attempt to leverage them repeatedly, resulting in a higher-than-normal volume of successful authentications. While not definitive proof of compromise, a sudden spike warrants further investigation. This behavior is typically observed during the initial access, persistence, privilege escalation, or stealth phases of an attack. This detection focuses on identifying increases of 10% or greater, providing a starting point for identifying anomalous activity. Defenders should investigate the source of the increase, focusing on specific users, applications, or geographic locations involved.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e The attacker obtains valid user credentials through phishing, brute-force, or credential stuffing attacks against Azure AD.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker uses the compromised credentials to successfully authenticate to Azure AD, gaining initial access to the environment (T1078).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEnumeration:\u003c/strong\u003e The attacker enumerates available resources, applications, and user accounts within the Azure AD environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in Azure AD or related applications. This may involve authenticating to multiple resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence mechanisms, such as creating new accounts or modifying existing ones, to maintain access to the environment. This may involve repeatedly authenticating to refresh tokens or maintain sessions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker uses the compromised account to access other resources or accounts within the Azure AD environment, potentially triggering further successful sign-ins.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Damage:\u003c/strong\u003e The attacker uses the compromised access to exfiltrate sensitive data or disrupt business operations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCovering Tracks:\u003c/strong\u003e The attacker attempts to cover their tracks by disabling logging or deleting audit trails to avoid detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack following a measurable increase in authentications can lead to unauthorized access to sensitive data, financial loss, reputational damage, and disruption of business operations. The specific impact depends on the level of access gained by the attacker and the resources they are able to compromise. For example, an attacker gaining access to an administrator account could potentially take control of the entire Azure AD environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Measurable Increase Of Successful Authentications\u0026rdquo; Sigma rule to your SIEM and tune for your environment. This rule detects increases of 10% or greater in successful sign-ins (rule, logsource: azure, service: signinlogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the source of the increased authentications and the users/applications involved.\u003c/li\u003e\n\u003cli\u003eReview the Microsoft Entra ID Protection reports for unusual sign-in activity, as referenced in the source material: \u003ca href=\"https://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins\"\u003ehttps://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor for other suspicious activities, such as unusual sign-in locations, access to sensitive resources, or changes to user accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-azure-auth-increase/","summary":"This detection identifies a statistically significant (10% or greater) increase in successful sign-ins to Azure Active Directory, potentially indicating credential compromise or account takeover attempts.","title":"Azure AD Successful Authentication Increase","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-auth-increase/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["attack.stealth","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe removal of an owner from an Azure application or service principal can be indicative of malicious activity. An attacker who has gained initial access to an Azure environment might attempt to remove owners from service principals or applications to hinder incident response, establish persistence, or escalate their privileges. This action could be part of a broader attack aimed at compromising cloud resources and data. Detecting this activity is crucial for identifying potentially compromised accounts and preventing further damage within the Azure environment. The activity is logged within the Azure Activity Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account through compromised credentials or by exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available applications and service principals within the Azure environment to identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies an application or service principal with elevated permissions that would be beneficial to compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to remove the existing owner from the target application or service principal via the Azure portal, PowerShell, or Azure CLI.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record an event indicating \u0026ldquo;Remove owner from service principal\u0026rdquo; or \u0026ldquo;Remove owner from application\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker may assign themselves as the new owner or further modify the permissions of the application or service principal to achieve their objectives.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised application or service principal to access sensitive resources, exfiltrate data, or deploy malicious workloads.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful removal of an owner from an Azure application or service principal can lead to a significant compromise of cloud resources. This action can disrupt normal operations, allow unauthorized access to sensitive data, and provide a persistent foothold for attackers within the Azure environment. The lack of an owner can prevent proper oversight and incident response, potentially leading to prolonged compromise and increased damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Owner Removed From Application or Service Principal\u0026rdquo; to your SIEM and tune for your environment to detect suspicious owner removal activity in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on unfamiliar user identities and unusual user agents in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise, which is often the initial access vector.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit the permissions assigned to applications and service principals to identify and remediate any excessive or unnecessary privileges.\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-azure-owner-removed/","summary":"An adversary may remove an owner from an Azure application or service principal to weaken access controls, persist in the environment, or escalate privileges.","title":"Azure Owner Removed from Application or Service Principal","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-owner-removed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.initial-access","attack.persistence","attack.privilege-escalation","attack.stealth","attack.t1098.003","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may attempt to add new members to administrative roles in Azure Active Directory to establish persistence and elevate privileges. This allows them to perform actions as a highly privileged user, potentially bypassing security controls and accessing sensitive resources. The activity is logged within Azure Activity Logs, specifically when the \u0026lsquo;Add member to role\u0026rsquo; operation is executed within the \u0026lsquo;AzureActiveDirectory\u0026rsquo; workload, targeting roles with names ending in \u0026lsquo;Admins\u0026rsquo; or \u0026lsquo;Administrator\u0026rsquo;. Monitoring these events can help detect unauthorized privilege escalation and potential malicious activity within the Azure environment. This activity could be the result of compromised credentials or an insider threat.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eCompromise an existing user account with sufficient permissions to modify Azure AD roles.\u003c/li\u003e\n\u003cli\u003eAuthenticate to the Azure portal or utilize Azure CLI with the compromised account.\u003c/li\u003e\n\u003cli\u003eIdentify a target Azure AD administrative role (e.g., Global Administrator, Security Administrator).\u003c/li\u003e\n\u003cli\u003eExecute the \u0026lsquo;Add member to role\u0026rsquo; operation, adding the attacker-controlled user to the target role. This can be performed via the Azure portal, PowerShell, or Azure CLI.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record the \u0026lsquo;Add member to role.\u0026rsquo; event, with the \u0026lsquo;Workload\u0026rsquo; as \u0026lsquo;AzureActiveDirectory\u0026rsquo;.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eModifiedProperties{}.NewValue\u003c/code\u003e field reflects the addition of the user to the admin role, containing strings like \u0026ldquo;Admins\u0026rdquo; or \u0026ldquo;Administrator.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates as the newly added user, inheriting the privileges of the administrative role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive data, modify configurations, or deploy malicious applications.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful addition of a user to an Azure AD administrative role grants the attacker extensive control over the Azure environment. This can lead to data breaches, service disruptions, and the deployment of malicious applications.  Compromised administrator accounts can be used to disable security features, modify audit logs, and create backdoors for persistent access. Detection is critical to limit the scope and duration of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect instances of users being added to Azure AD administrative roles (logsource: azure, service: activitylogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of the \u0026ldquo;Add member to role.\u0026rdquo; operation in Azure AD Activity Logs where the ModifiedProperties{}.NewValue ends with \u0026lsquo;Admins\u0026rsquo; or \u0026lsquo;Administrator\u0026rsquo; to validate legitimate administrative changes.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of compromised credentials.\u003c/li\u003e\n\u003cli\u003eRegularly review Azure AD role assignments to identify and remove unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual activity from newly added members of administrative roles after the \u0026lsquo;Add member to role\u0026rsquo; event.\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-azuread-admin-role-add/","summary":"An adversary adds a user to an Azure Active Directory administrative role to gain initial access, persist in the environment, escalate privileges, and potentially operate stealthily.","title":"Azure AD User Added to Administrator Role","url":"https://feed.craftedsignal.io/briefs/2024-01-azuread-admin-role-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["attack.stealth","attack.t1140"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers can create inbox manipulation rules in cloud email environments like Microsoft 365 to hide their activity, exfiltrate data, or conduct further phishing attacks. These rules automatically delete, move, or forward emails based on sender, subject, or keywords. This can be used to hide evidence of a compromised account, or to intercept communications for Business Email Compromise (BEC). The \u003ccode\u003emcasSuspiciousInboxManipulationRules\u003c/code\u003e risk event type in Azure Identity Protection flags such suspicious rules, allowing defenders to proactively identify and remediate compromised accounts. This detection focuses on unusual mailbox rule activity indicative of malicious intent, rather than legitimate business workflows.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a user\u0026rsquo;s Azure account, potentially through credential theft or phishing (T1140).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the user\u0026rsquo;s Microsoft 365 account.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new inbox rule or modifies an existing one using the Exchange admin center, PowerShell, or the Microsoft Graph API.\u003c/li\u003e\n\u003cli\u003eThe rule is configured to automatically delete emails containing specific keywords related to financial transactions or security alerts (T1566).\u003c/li\u003e\n\u003cli\u003eAlternatively, the rule might forward all emails from specific internal addresses to an external account controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the manipulated inbox to conceal their activities, such as unauthorized financial transactions or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe legitimate user remains unaware of the attacker\u0026rsquo;s actions due to the automatic deletion or redirection of relevant emails.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring the inbox rule remains active and undetected, allowing for continued unauthorized access and activity.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to conceal malicious activity within the compromised account, intercept sensitive information, and maintain persistence. This can lead to significant financial losses due to BEC, data breaches, and reputational damage. Undetected inbox manipulation can also hinder incident response efforts by preventing security teams from identifying and containing the attack in a timely manner.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Inbox Manipulation Rules\u0026rdquo; to your SIEM and tune the \u003ccode\u003efalsepositives\u003c/code\u003e list with known good inbox rule behaviors in your organization.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts by examining the details of the created/modified inbox rules, focusing on their conditions and actions.\u003c/li\u003e\n\u003cli\u003eReview user sign-in logs for unusual activity preceding the creation of suspicious inbox rules, as described in the Microsoft documentation (\u003ca href=\"https://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#unusual-sign-ins)\"\u003ehttps://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#unusual-sign-ins)\u003c/a\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:30:00Z","date_published":"2024-01-02T14:30:00Z","id":"/briefs/2024-01-suspicious-inbox-rules/","summary":"This brief focuses on detecting malicious inbox manipulation rules set within a user's Azure environment, often indicative of account compromise or insider threats aiming to conceal illicit activities.","title":"Detection of Suspicious Inbox Manipulation Rules in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-inbox-rules/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","pim","role-assignment","attack.initial-access","attack.stealth","attack.t1078","attack.persistence","attack.privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized assignment of privileged roles outside of Azure Privileged Identity Management (PIM) represents a significant security risk. Attackers may attempt to bypass PIM controls to gain persistent access, escalate privileges, or move laterally within the Azure environment. Detecting these anomalous role assignments is crucial for identifying potentially compromised accounts or malicious insiders. This activity is a common tactic used by attackers to establish persistence and maintain control over cloud resources. Monitoring for this behavior can help security teams quickly identify and respond to potential breaches, limiting the impact of successful attacks. This activity can be associated with lateral movement, privilege escalation, and persistence within the cloud environment.\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 compromised user account or service principal within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to identify existing privileged roles and permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses PIM to directly assign themselves a privileged role (e.g., Global Administrator, Security Administrator) using Azure CLI, PowerShell, or the Azure portal.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates their permissions without triggering PIM alerts or requiring approval.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly assigned privileged role to access sensitive data, modify configurations, or create new resources.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new accounts or modifying existing ones with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally to other Azure resources or subscriptions using their increased access.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, service disruption, or deployment of malicious code.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising privileged roles within Azure can have severe consequences, potentially impacting all resources within the affected Azure Active Directory tenant. Successful attacks can lead to unauthorized data access, service disruption, financial loss, and reputational damage. The scope of the impact depends on the level of privilege gained by the attacker and the sensitivity of the targeted resources. Without proper detection and response, organizations may remain unaware of the breach, allowing attackers to maintain persistent access and continue their malicious activities undetected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eRoles Assigned Outside PIM\u003c/code\u003e to your SIEM to detect unauthorized role assignments within your Azure environment.\u003c/li\u003e\n\u003cli\u003eInvestigate all instances flagged by the Sigma rule \u003ccode\u003eRoles Assigned Outside PIM\u003c/code\u003e to determine the legitimacy of the role assignment and the identity of the assigner.\u003c/li\u003e\n\u003cli\u003eImplement controls to restrict the ability to assign privileged roles outside of PIM, as described in the Microsoft documentation reference.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege to minimize the potential impact of compromised accounts.\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-azure-pim-role-assigned-outside/","summary":"Detection of privilege role assignments outside of Azure Privileged Identity Management (PIM) can indicate potential attacker activity related to initial access, stealth, persistence, or privilege escalation within the Azure environment.","title":"Azure PIM - Role Assignment Outside of Privileged Identity Management","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-role-assigned-outside/"}],"language":"en","title":"CraftedSignal Threat Feed — Attack.stealth","version":"https://jsonfeed.org/version/1.1"}