{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/initial-access/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["M365 Defender","Sysmon","Elastic Defend","SentinelOne Cloud Funnel","CrowdStrike Falcon"],"_cs_severities":["medium"],"_cs_tags":["initial-access","rdp","phishing","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers are increasingly using malicious Remote Desktop Protocol (RDP) files to gain initial access to systems. These RDP files, often delivered via spearphishing attachments, contain connection settings that, when opened, can compromise a system. This technique allows adversaries to bypass traditional security measures by leveraging a legitimate tool (mstsc.exe) with a malicious configuration file. The observed activity involves opening RDP files from suspicious locations like Downloads, temporary folders (AppData\\Local\\Temp), and Outlook content cache (INetCache\\Content.Outlook). This campaign has been observed as recently as October 2024, where Midnight Blizzard conducted large-scale spear-phishing using RDP files. Defenders should monitor for the execution of mstsc.exe with RDP files from untrusted locations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts a spearphishing email containing a malicious RDP file as an attachment.\u003c/li\u003e\n\u003cli\u003eThe victim receives the email and, lured by social engineering, downloads the attached RDP file to a local directory, often the Downloads folder.\u003c/li\u003e\n\u003cli\u003eThe victim double-clicks the RDP file, initiating the execution of \u003ccode\u003emstsc.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003emstsc.exe\u003c/code\u003e reads the connection settings from the RDP file, which may include malicious configurations such as altered gateway settings or credential theft mechanisms.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003emstsc.exe\u003c/code\u003e attempts to establish a remote desktop connection based on the RDP file\u0026rsquo;s settings.\u003c/li\u003e\n\u003cli\u003eIf the connection is successful, the attacker gains unauthorized access to the remote system.\u003c/li\u003e\n\u003cli\u003eThe attacker may then perform reconnaissance, move laterally, and escalate privileges within the compromised network.\u003c/li\u003e\n\u003cli\u003eThe final objective could be data exfiltration, ransomware deployment, or establishing persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack using malicious RDP files can lead to unauthorized access to sensitive systems and data. The consequences range from data breaches and financial loss to complete system compromise and disruption of operations. The Microsoft Security blog reported a large-scale spear-phishing campaign utilizing RDP files as recently as October 2024. The targets may be across various sectors, with potentially widespread impact depending on the attacker\u0026rsquo;s objectives and the scope of the compromised network.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eRemote Desktop File Opened from Suspicious Path\u003c/code\u003e to your SIEM and tune for your environment, focusing on the specified file paths and \u003ccode\u003emstsc.exe\u003c/code\u003e execution.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging with command-line arguments to capture the execution of \u003ccode\u003emstsc.exe\u003c/code\u003e and the paths of the RDP files being opened.\u003c/li\u003e\n\u003cli\u003eEducate users on the risks associated with opening RDP files from untrusted sources, particularly those received as email attachments.\u003c/li\u003e\n\u003cli\u003eImplement strict email filtering to block or quarantine emails with RDP attachments from external sources.\u003c/li\u003e\n\u003cli\u003eMonitor network connections for unusual RDP traffic originating from systems where suspicious RDP files were executed.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-11-rdp-file-attachment/","summary":"Adversaries may abuse RDP files delivered via phishing from suspicious locations to gain unauthorized access to systems.","title":"Remote Desktop File Opened from Suspicious Path","url":"https://feed.craftedsignal.io/briefs/2024-11-rdp-file-attachment/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows Installer"],"_cs_severities":["low"],"_cs_tags":["msiexec","remote-file-execution","initial-access","defense-evasion","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Citrix"],"content_html":"\u003cp\u003eThe Windows Installer (msiexec.exe) is a built-in Windows component used for installing, modifying, and removing software. Adversaries may abuse msiexec.exe to launch local or network accessible MSI files, bypassing security controls and potentially leading to initial access or defense evasion. This activity is often part of a broader attack chain, used to deliver and execute malicious payloads. The detection rule provided by Elastic identifies suspicious msiexec.exe activity by monitoring process starts, network connections, and child processes. It filters out known benign signatures and paths to highlight potential misuse. This detection is designed to work with Elastic Defend data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access via phishing (T1566) or other means to execute commands on the target system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses msiexec.exe with the \u003ccode\u003e/V\u003c/code\u003e parameter to initiate the installation of a remote MSI package. This allows the attacker to bypass typical execution restrictions.\u003c/li\u003e\n\u003cli\u003eMsiexec.exe attempts a network connection (T1105) to retrieve the remote MSI package from a malicious server.\u003c/li\u003e\n\u003cli\u003eMsiexec.exe spawns a child process to handle the installation of the downloaded MSI package.\u003c/li\u003e\n\u003cli\u003eThe spawned child process executes malicious code embedded within the MSI package.\u003c/li\u003e\n\u003cli\u003eThe malicious code performs actions such as installing malware, modifying system settings, or establishing persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised system for further lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the installation of malware, unauthorized access to sensitive data, and further compromise of the affected system and network. While this specific rule has a low risk score, it can be an early indicator of more serious attacks. It is crucial to investigate any alerts generated by this rule to determine the full scope and impact of the potential compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule provided below to your SIEM to detect suspicious usage of \u003ccode\u003emsiexec.exe\u003c/code\u003e to install remote packages. Tune the rule for your environment by adding exceptions for legitimate software installation processes.\u003c/li\u003e\n\u003cli\u003eEnable process monitoring and network connection logging on Windows endpoints to provide the necessary data for the Sigma rule to function effectively (Data Source: Elastic Defend).\u003c/li\u003e\n\u003cli\u003eReview the \u0026ldquo;Possible investigation steps\u0026rdquo; section in the Elastic rule\u0026rsquo;s documentation to investigate potential false positives and legitimate uses of \u003ccode\u003emsiexec.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unauthorized applications, including potentially malicious MSI packages.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2026-05-msiexec-remote-install/","summary":"The rule detects the execution of the built-in Windows Installer, msiexec.exe, to install a remote package potentially abused by adversaries for initial access and defense evasion.","title":"Potential Remote File Execution via MSIEXEC","url":"https://feed.craftedsignal.io/briefs/2026-05-msiexec-remote-install/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Google Workspace"],"_cs_severities":["medium"],"_cs_tags":["googleworkspace","intrusion","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis alert focuses on identifying potentially malicious login attempts within Google Workspace environments. The detection is based on Google\u0026rsquo;s own flagging of a login as a potential \u0026ldquo;gov_attack_warning,\u0026rdquo; suggesting that Google\u0026rsquo;s threat intelligence attributes the activity to a government-backed actor. While specific targeting information is unavailable, this alert highlights a critical area for investigation within organizations utilizing Google Workspace, especially those handling sensitive data or operating in sectors of interest to nation-state actors. This detection provides an early warning of potential compromise or data exfiltration attempts.\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 attempts to log into a Google Workspace account using compromised or brute-forced credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLogin Attempt:\u003c/strong\u003e The login attempt triggers a \u0026ldquo;gov_attack_warning\u0026rdquo; within Google Workspace, indicating a potential government-backed threat actor.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Potential):\u003c/strong\u003e If the compromised account has elevated privileges, the attacker may attempt to escalate privileges within the Google Workspace environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion (Potential):\u003c/strong\u003e The attacker may attempt to disable security features or modify audit logs to evade detection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Potential):\u003c/strong\u003e The attacker may establish persistent access through methods such as creating rogue apps or modifying account settings.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Access:\u003c/strong\u003e The attacker gains access to sensitive data stored within Google Workspace, such as documents, emails, and files.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExfiltration (Potential):\u003c/strong\u003e The attacker exfiltrates the stolen data to an external location.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The organization suffers a data breach, reputational damage, and potential financial losses.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to the compromise of sensitive data within the Google Workspace environment, including confidential documents, emails, and other business-critical information. The potential consequences range from reputational damage and legal liabilities to financial losses and disruption of business operations. The number of affected users and the severity of the impact will depend on the scope of the attacker\u0026rsquo;s access and the sensitivity of the compromised data.\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 \u0026ldquo;gov_attack_warning\u0026rdquo; events in Google Workspace logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts promptly, focusing on the affected user account and associated activity.\u003c/li\u003e\n\u003cli\u003eReview the Google Workspace audit logs for any suspicious activity leading up to the \u0026ldquo;gov_attack_warning\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Google Workspace accounts, especially those with elevated privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Google Workspace activity logs for suspicious patterns, such as unusual login locations, failed login attempts, and changes to account settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-28T00:48:14Z","date_published":"2026-04-28T00:48:14Z","id":"/briefs/2024-01-23-gworkspace-govattack/","summary":"A Google Workspace login attempt flagged as a potential attack by a government-backed threat actor, indicating potential privilege escalation, defense evasion, persistence, initial access, or impact.","title":"Google Workspace Login Attempt with Government Attack Warning","url":"https://feed.craftedsignal.io/briefs/2024-01-23-gworkspace-govattack/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["oauth","device-code","phishing","initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eIn early April 2026, Arctic Wolf observed a widespread phishing campaign that abused the OAuth device code flow. This campaign targeted organizations across multiple regions and sectors, mirroring the \u0026ldquo;Riding the Rails\u0026rdquo; campaign observed by Huntress in late March. The attackers exploited the device code grant type in the OAuth 2.0 authorization framework to obtain access tokens. By tricking users into entering a code on a legitimate Microsoft login page, attackers bypassed traditional MFA controls. Defenders should be aware of this evolving technique and implement detection strategies focused on anomalous application registrations and device code flow activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a phishing email to the victim, impersonating a legitimate service.\u003c/li\u003e\n\u003cli\u003eThe email contains a link that redirects the victim to a fake application authorization page.\u003c/li\u003e\n\u003cli\u003eThe fake page prompts the victim to enter a device code.\u003c/li\u003e\n\u003cli\u003eUnbeknownst to the victim, the device code is associated with a malicious OAuth application controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe victim is redirected to a legitimate Microsoft login page, where they enter the provided code and authenticate.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the malicious application receives an access token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the access token to access the victim\u0026rsquo;s account and sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker may then perform actions such as reading emails, accessing files, or initiating further malicious activity within the compromised account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis OAuth device code phishing campaign affected numerous organizations across multiple sectors and regions in early April 2026. Successful attacks grant threat actors unauthorized access to user accounts, potentially leading to data exfiltration, financial fraud, and further compromise of internal systems. Due to the nature of OAuth, attackers can maintain persistent access even after password changes, posing a significant long-term risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor Azure AD sign-in logs for device code flow usage to identify suspicious authentications (logsource: azuread, category: authentication).\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule provided below to detect suspicious application registrations in Azure AD (logsource: o365, category: configuration).\u003c/li\u003e\n\u003cli\u003eEducate users on the risks of device code phishing and how to identify malicious authorization requests.\u003c/li\u003e\n\u003cli\u003eRegularly audit OAuth applications authorized within your environment and revoke access for any suspicious or unused applications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts related to anomalous OAuth application activity promptly.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-24T19:52:35Z","date_published":"2026-04-24T19:52:35Z","id":"/briefs/2026-05-oauth-device-code-phishing/","summary":"In early April 2026, Arctic Wolf tracked a large-scale device code phishing campaign across multiple regions and sectors where threat actors abused OAuth device code flow to trick victims into providing authentication codes.","title":"Large-Scale OAuth Device Code Phishing Campaign Observed in April 2026","url":"https://feed.craftedsignal.io/briefs/2026-05-oauth-device-code-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","GitHub Actions"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","github","credential-theft","initial-access","lateral-movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Microsoft","Google"],"content_html":"\u003cp\u003eThis threat involves the unauthorized use of AWS credentials stolen from GitHub Actions secrets. Attackers exfiltrate these credentials and use them from their own infrastructure, bypassing the intended CI/CD environment. The activity is detected by observing AWS access keys appearing in CloudTrail logs originating from both legitimate GitHub Actions runners (identified by Microsoft ASN or the \u003ccode\u003egithub-actions\u003c/code\u003e user agent string) and suspicious infrastructure outside the expected CI/CD provider ASNs (Amazon, Google, Microsoft). This indicates a breach of GitHub repository or organization secrets, leading to potential unauthorized access and control over AWS resources. This activity can begin with compromised Github accounts.\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 GitHub repository or organization with AWS credentials stored as secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker\u0026rsquo;s source IP address and ASN.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities, such as calling \u003ccode\u003ests:GetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eDescribeInstances\u003c/code\u003e, or \u003ccode\u003eListUsers\u003c/code\u003e, to understand the AWS environment and identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim\u0026rsquo;s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure\u0026rdquo; to your SIEM and tune for your environment to detect suspicious usage patterns.\u003c/li\u003e\n\u003cli\u003eRotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.\u003c/li\u003e\n\u003cli\u003eImplement OIDC-based authentication (\u003ccode\u003eaws-actions/configure-aws-credentials\u003c/code\u003e with \u003ccode\u003erole-to-assume\u003c/code\u003e) instead of long-lived access keys as mentioned in the rule documentation.\u003c/li\u003e\n\u003cli\u003eIf using OIDC, add IP condition policies to the IAM role trust policy to restrict \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to known GitHub runner IP ranges, based on the information in the rule documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T17:45:55Z","date_published":"2026-04-22T17:45:55Z","id":"/briefs/2024-01-aws-github-actions-credential-theft/","summary":"Attackers are stealing AWS credentials configured as GitHub Actions secrets and using them from non-CI/CD infrastructure, indicating potential credential theft and unauthorized access to AWS resources.","title":"AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-github-actions-credential-theft/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["rdp","phishing","initial-access","windows"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies the execution of \u003ccode\u003emstsc.exe\u003c/code\u003e (Remote Desktop Connection) with an RDP file located in suspicious directories on Windows systems. Adversaries may use malicious RDP files delivered via phishing campaigns as an initial access vector. These files, containing connection settings, can be placed in locations such as the Downloads folder, temporary directories, or Outlook\u0026rsquo;s content cache. The rule focuses on detecting RDP files opened from unusual paths, which can signal unauthorized access or malicious activity. The behavior was observed in conjunction with the Midnight Blizzard campaign in October 2024. This detection helps defenders identify potential RDP-based attacks and investigate suspicious user behavior.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts a spearphishing email with a malicious RDP file attachment (T1566.001).\u003c/li\u003e\n\u003cli\u003eThe victim receives the email and downloads the RDP file to a common location such as the Downloads folder.\u003c/li\u003e\n\u003cli\u003eThe user executes the downloaded RDP file, initiating the \u003ccode\u003emstsc.exe\u003c/code\u003e process (T1204.002).\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003emstsc.exe\u003c/code\u003e process attempts to establish a remote connection to a malicious server controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker may exploit vulnerabilities in the RDP service or use credential harvesting techniques to gain access to the remote system.\u003c/li\u003e\n\u003cli\u003eUpon successful connection, the attacker performs reconnaissance activities, such as network scanning and user enumeration.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the network, exploiting additional vulnerabilities or using stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation via malicious RDP files can lead to unauthorized access to internal systems, data breaches, and potential ransomware deployment. While the number of victims and targeted sectors is unspecified, the impact can be significant, especially if the compromised systems have access to sensitive data or critical infrastructure. This can result in financial losses, reputational damage, and operational disruptions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation logging to detect the execution of \u003ccode\u003emstsc.exe\u003c/code\u003e and capture the command-line arguments used to launch the process.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Remote Desktop File Opened from Suspicious Path\u0026rdquo; to your SIEM to detect RDP files opened from suspicious locations.\u003c/li\u003e\n\u003cli\u003eEducate users about the risks of opening RDP files from untrusted sources, especially those received via email.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of \u003ccode\u003emstsc.exe\u003c/code\u003e from untrusted directories.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from systems where \u003ccode\u003emstsc.exe\u003c/code\u003e has been executed to identify suspicious remote connections.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-20T21:38:09Z","date_published":"2026-04-20T21:38:09Z","id":"/briefs/2024-11-suspicious-rdp/","summary":"This rule identifies attempts to open a remote desktop file from suspicious paths, indicative of adversaries abusing RDP files for initial access via phishing.","title":"Suspicious RDP File Execution","url":"https://feed.craftedsignal.io/briefs/2024-11-suspicious-rdp/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["supply-chain","initial-access","package-manager","elastic-defend","post-install"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies Elastic Defend alerts triggered by processes with a package manager installation context in their ancestry. This includes package managers such as npm (Node.js), PyPI (pip / Python / uv), and cargo (Rust). The rule is designed to detect supply chain attacks and post-install abuse, where malicious scripts are executed during or after package installation. The rule leverages Elastic Defend alerts to identify suspicious activity within the process tree of package manager installations. This is crucial for defenders because install-time spawn chains are a common attack vector for injecting malicious code into systems. The rule is implemented as an ESQL query and is intended to be used with Elastic Stack version 9.3.0 or later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA developer or system administrator initiates a package installation using a package manager like npm, pip, or cargo.\u003c/li\u003e\n\u003cli\u003eThe package manager downloads and installs the requested package and its dependencies.\u003c/li\u003e\n\u003cli\u003eThe installed package contains malicious code embedded within a post-install script or a dependency.\u003c/li\u003e\n\u003cli\u003eThe package manager executes the malicious post-install script (e.g., using \u003ccode\u003enode\u003c/code\u003e, \u003ccode\u003epython\u003c/code\u003e, or \u003ccode\u003ecargo\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe malicious script executes arbitrary commands, such as downloading and executing a payload from a remote server.\u003c/li\u003e\n\u003cli\u003eThe downloaded payload establishes persistence on the system, potentially through scheduled tasks or registry keys.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the system and begins lateral movement and privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration, ransomware deployment, or system compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete system compromise, data breaches, and supply chain contamination. The compromised system could be used to spread malware to other systems within the network or to external customers through poisoned software packages. The severity is critical due to the potential for widespread impact and the difficulty in detecting and mitigating supply chain attacks. The financial and reputational damage to the organization could be substantial.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the following Sigma rules to your SIEM to detect malicious activity related to package manager installations.\u003c/li\u003e\n\u003cli\u003eReview and tune the Sigma rules for your specific environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eImplement strict code review and dependency management practices to prevent the introduction of malicious packages.\u003c/li\u003e\n\u003cli\u003eMonitor Elastic Defend alerts for suspicious activity in the process tree of package manager installations, as surfaced by this detection rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts related to package manager install ancestry to identify and remediate potential supply chain attacks.\u003c/li\u003e\n\u003cli\u003eEnable process monitoring with command-line logging to capture the full context of package manager installations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-package-manager-ancestry/","summary":"This rule detects Elastic Defend alerts where the alerted process has a package-manager install context in its ancestry (npm, PyPI, Rust), indicating potential supply chain compromise via malicious postinstall scripts.","title":"Elastic Defend Alert from Package Manager Install Ancestry","url":"https://feed.craftedsignal.io/briefs/2026-04-package-manager-ancestry/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":true,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"threat","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies a specific attack sequence targeting Azure Arc-connected Kubernetes clusters. It focuses on the scenario where a service principal authenticates to Microsoft Entra ID and subsequently requests credentials for an Azure Arc-connected Kubernetes cluster. The \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action is used to retrieve tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence is particularly concerning when the service principal authenticates externally and immediately accesses Arc cluster credentials, especially from unexpected locations or Autonomous System Numbers (ASNs). This behavior, observed in attacks like those described by IBM X-Force in 2025, can lead to attackers gaining unauthorized access to and control over Kubernetes clusters. Defenders should investigate such events, particularly when the sign-in originates from an unexpected location or ASN.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains unauthorized access to a service principal\u0026rsquo;s credentials (e.g., through credential stuffing, phishing, or exposed secrets).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Principal Authentication:\u003c/strong\u003e The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the \u003ccode\u003eServicePrincipalSignInLogs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Listing Request:\u003c/strong\u003e Immediately following successful authentication, the attacker leverages the service principal to initiate a request to list the cluster user credentials for an Azure Arc-connected Kubernetes cluster, triggering the \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e in the Activity Logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Retrieval:\u003c/strong\u003e The attacker retrieves the Arc cluster credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProxy Tunnel Establishment:\u003c/strong\u003e The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKubernetes Access:\u003c/strong\u003e With the tunnel established, the attacker can now execute kubectl commands, perform unauthorized actions within the cluster, such as creating, reading, updating, and deleting (CRUD) secrets and configmaps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement \u0026amp; Privilege Escalation:\u003c/strong\u003e The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Ransomware Deployment:\u003c/strong\u003e The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this attack chain can lead to complete compromise of Azure Arc-connected Kubernetes clusters. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and potentially deploy ransomware. The IBM X-Force team has documented cases of attackers using similar techniques for hybrid escalation and persistence. This can impact organizations across all sectors utilizing Azure Arc for managing Kubernetes clusters, potentially affecting dozens or hundreds of clusters per victim organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM and tune for your environment to detect the sequence of service principal sign-in followed by Arc cluster credential access.\u003c/li\u003e\n\u003cli\u003eReview Azure AD Audit Logs for recent changes to service principals, focusing on new credentials, federated identities, and owner changes, based on the investigation steps outlined in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eEnable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e events to identify potential unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eRotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule\u0026rsquo;s response and remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-11-24-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Azure AD followed by listing credentials for an Azure Arc-connected Kubernetes cluster, indicating potential adversary activity with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-11-24-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, published by Elastic, is designed to correlate AWS security alerts and prioritize investigations related to potentially compromised IAM access keys. Specifically, it focuses on scenarios where a long-term IAM access key is observed originating from a new source IP address (detected by the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule, rule ID 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) and is also associated with other open alerts of medium, high, or critical severity. This correlation aims to surface instances where a newly exposed or compromised access key is actively being used for malicious activities, enabling security teams to respond more effectively to potential credential access incidents and initial access attempts. The rule is a higher-order rule that analyzes existing security alerts within an Elastic Security deployment and leverages the \u003ccode\u003ekibana.alert\u003c/code\u003e fields to identify related events.\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 AWS IAM Long-Term Access Key. This could be through phishing, credential stuffing, or exposed credentials in source code.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.\u003c/li\u003e\n\u003cli\u003eThe attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.\u003c/li\u003e\n\u003cli\u003eThe correlation rule identifies the co-occurrence of the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; alert and other elevated severity alerts associated with the same access key ID.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging compromised AWS IAM credentials can lead to significant data breaches, service disruption, and financial losses. Attackers can gain unauthorized access to sensitive data stored in S3 buckets, compromise EC2 instances, and disrupt critical AWS services. The correlation rule aims to reduce the dwell time of attackers by prioritizing the investigation of compromised credentials associated with ongoing malicious activity. This can prevent attackers from further escalating their attacks and minimizing the overall impact of the breach. Failure to detect and respond to these attacks can result in regulatory fines, reputational damage, and loss of customer trust.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts\u0026rdquo; rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the rule by pivoting on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e in CloudTrail and IAM to understand the context of the access key usage.\u003c/li\u003e\n\u003cli\u003eReview the sibling alerts identified by the rule using \u003ccode\u003eEsql.kibana_alert_rule_name_values\u003c/code\u003e and \u003ccode\u003eEsql.kibana_alert_rule_id_values\u003c/code\u003e to understand the scope and impact of the potential compromise.\u003c/li\u003e\n\u003cli\u003eConfigure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that \u003ccode\u003ekibana.alert.risk_score \u0026gt;= 47\u003c/code\u003e corresponds to medium or higher severity alerts.\u003c/li\u003e\n\u003cli\u003eRotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.\u003c/li\u003e\n\u003cli\u003eImplement the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T14:37:37Z","date_published":"2026-04-06T14:37:37Z","id":"/briefs/2026-06-aws-iam-access-key-correlation/","summary":"This rule correlates AWS Long-Term Access Key First Seen from Source IP alerts with other open alerts of medium or higher severity that share the same IAM access key ID to prioritize investigation of potentially compromised accounts, helping identify post-compromise activity.","title":"AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts","url":"https://feed.craftedsignal.io/briefs/2026-06-aws-iam-access-key-correlation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["zoom","zoombombing","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe absence of passcodes on Zoom meetings creates a significant vulnerability, allowing malicious actors to engage in \u0026ldquo;Zoombombing.\u0026rdquo; This involves unauthorized individuals disrupting meetings with offensive content or potentially gaining access to sensitive information discussed during the session. The Elastic detection rule, published initially in 2020 and updated in March 2026, aims to identify these unsecured meetings by monitoring Zoom event logs. This is especially relevant given the increased reliance on teleconferencing platforms and the potential for reputational and data security incidents arising from such breaches. The scope includes all Zoom meetings created where event logs are collected by Filebeat or a similar data collection method.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a Zoom meeting ID without a passcode, often through social media or shared links.\u003c/li\u003e\n\u003cli\u003eThe attacker joins the meeting using the Zoom client or web interface.\u003c/li\u003e\n\u003cli\u003eOnce inside, the attacker disrupts the meeting by sharing offensive content (images, videos, audio) via screen sharing or chat.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to gather sensitive information shared during the meeting, such as personal data or confidential business details.\u003c/li\u003e\n\u003cli\u003eParticipants react to the disruption, causing further chaos and potentially escalating the situation.\u003c/li\u003e\n\u003cli\u003eThe meeting host is forced to end the meeting abruptly to stop the disruption, impacting productivity.\u003c/li\u003e\n\u003cli\u003eThe incident may lead to reputational damage for the organization hosting the meeting.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eUnsecured Zoom meetings can lead to significant disruptions and potential data breaches. A single Zoombombing incident can affect dozens to hundreds of participants, leading to wasted time, emotional distress, and potential exposure of sensitive information. Organizations can suffer reputational damage if such incidents become public. The financial impact includes lost productivity and potential legal liabilities if personal data is compromised.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Zoom Meeting with no Passcode\u0026rdquo; to detect the creation of meetings without passcodes in your environment.\u003c/li\u003e\n\u003cli\u003eReview Zoom account settings to enforce mandatory passcodes for all new meetings.\u003c/li\u003e\n\u003cli\u003eEnable the Zoom Filebeat module or similar structured data collection for comprehensive Zoom event logging.\u003c/li\u003e\n\u003cli\u003eEducate meeting hosts about the risks of unsecured meetings and best practices for securing their sessions.\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T15:53:12Z","date_published":"2026-04-01T15:53:12Z","id":"/briefs/2026-06-19-zoom-meeting-no-passcode/","summary":"The creation of Zoom meetings without passcodes allows unauthorized access and disruption, known as Zoombombing, potentially leading to the exposure of sensitive information or reputational damage.","title":"Unsecured Zoom Meeting Creation","url":"https://feed.craftedsignal.io/briefs/2026-06-19-zoom-meeting-no-passcode/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","defense-evasion","persistence","initial-access","active-directory"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief focuses on the modification of the \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attribute within Active Directory via PowerShell scripts. This activity is flagged as potentially malicious because it could be indicative of an attempt to exploit the \u0026lsquo;BadSuccessor\u0026rsquo; privilege escalation vulnerability in Windows Server 2025. The vulnerability, as outlined in Akamai\u0026rsquo;s research, allows attackers to manipulate managed service account (dMSA) links to gain elevated privileges. The detection is based on identifying specific PowerShell script patterns that include \u003ccode\u003e.Put(\u0026quot;msDS-ManagedAccountPrecededByLink'\u003c/code\u003e and \u003ccode\u003eCN=\u003c/code\u003e, which are used to modify these critical AD attributes. Defenders should be aware that legitimate administrative tasks might also trigger this detection, so careful tuning and validation are necessary.\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 system with sufficient privileges to execute PowerShell scripts, possibly through compromised credentials or other initial access vectors (T1078.002).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker uses PowerShell to enumerate existing dMSAs and their associated \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attributes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAttribute Modification:\u003c/strong\u003e The attacker crafts a PowerShell script to modify the \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attribute of a target dMSA. This involves using the \u003ccode\u003e.Put(\u0026quot;msDS-ManagedAccountPrecededByLink\u0026quot;\u003c/code\u003e command and specifying a new distinguished name (\u003ccode\u003eCN=\u003c/code\u003e) for the preceding account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker leverages the modified dMSA link to establish a persistent foothold in the environment by gaining control over the targeted dMSA.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e By manipulating the dMSA links, the attacker effectively inherits the permissions and privileges associated with the compromised dMSA, thereby escalating their own privileges.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker may attempt to evade detection by obfuscating the PowerShell script or using other techniques to hide their activity.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With elevated privileges, the attacker can move laterally within the network, accessing sensitive resources and systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of the \u0026lsquo;BadSuccessor\u0026rsquo; vulnerability through modification of the \u003ccode\u003emsDS-ManagedAccountPrecededByLink\u003c/code\u003e attribute can lead to complete domain compromise. An attacker can gain control over critical services and data, potentially resulting in data breaches, service disruptions, and significant financial losses. The impact is amplified in environments heavily reliant on Active Directory for authentication and authorization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM and tune for your environment to detect potentially malicious modifications to dMSA link attributes via PowerShell (logsource: ps_script, product: windows).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule to determine if the activity is legitimate or indicative of an attempted exploitation of the \u0026lsquo;BadSuccessor\u0026rsquo; vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and monitoring for systems and accounts with the ability to modify Active Directory attributes.\u003c/li\u003e\n\u003cli\u003eReview and harden Active Directory security configurations to prevent unauthorized modification of sensitive attributes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-30T10:27:13Z","date_published":"2026-03-30T10:27:13Z","id":"/briefs/2024-01-30-dmsa-link-mod/","summary":"Detection of PowerShell scripts modifying the msDS-ManagedAccountPrecededByLink attribute, potentially indicating exploitation of the BadSuccessor privilege escalation vulnerability in Windows Server 2025.","title":"Potential Abuse of msDS-ManagedAccountPrecededByLink for Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-30-dmsa-link-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","initial-access","phishing","oauth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAn active phishing campaign is leveraging Microsoft\u0026rsquo;s Device Code OAuth flow to target users of cloud-based file storage and document workflow platforms. Unlike traditional phishing attacks that aim to steal usernames and passwords directly, this campaign exploits a legitimate authentication mechanism to gain unauthorized access. The campaign impersonates popular cloud services, enticing users to enter a provided device code on a Microsoft login page. By doing so, victims inadvertently grant the attacker access to their accounts on the targeted platforms. This campaign highlights the evolving tactics of phishing actors and the need for robust detection mechanisms beyond simple credential harvesting alerts. The scope and scale of the campaign are currently unknown.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a phishing email impersonating a cloud-based file storage or document workflow service.\u003c/li\u003e\n\u003cli\u003eThe email contains a message prompting the user to \u0026ldquo;activate\u0026rdquo; or \u0026ldquo;authenticate\u0026rdquo; their account.\u003c/li\u003e\n\u003cli\u003eThe email includes a device code and instructs the user to visit a Microsoft login page (e.g., microsoft.com/devicelogin).\u003c/li\u003e\n\u003cli\u003eThe user, believing the request is legitimate, enters the provided device code on the Microsoft login page.\u003c/li\u003e\n\u003cli\u003eThe Microsoft login page prompts the user to grant permissions to an application controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eIf the user approves the permissions, the attacker gains OAuth tokens that allow access to the user\u0026rsquo;s account on the targeted cloud platform.\u003c/li\u003e\n\u003cli\u003eThe attacker can then access, modify, or exfiltrate data stored on the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised account to further propagate the phishing campaign to other users within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful attacks can lead to unauthorized access to sensitive data stored in cloud-based file storage and document workflow platforms. This can result in data breaches, financial loss, and reputational damage for affected organizations. The use of a legitimate Microsoft authentication flow makes this campaign difficult to detect with traditional phishing detection methods. The lack of credential harvesting may also bypass security controls focused on monitoring password theft. The specific number of victims and sectors targeted remains unknown, but the potential impact is significant given the widespread use of cloud services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement user awareness training to educate employees about device code phishing and the risks of entering unknown codes on login pages.\u003c/li\u003e\n\u003cli\u003eMonitor Microsoft Entra ID (Azure AD) logs for unusual device code authentication patterns, focusing on applications requesting broad permissions (reference: Attack Chain steps 5 and 6). Deploy the \u0026ldquo;Detect Suspicious Device Code Authentication\u0026rdquo; Sigma rule to identify anomalous activity.\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to trusted devices and locations.\u003c/li\u003e\n\u003cli\u003eInvestigate any successful device code authentications where the application requesting permissions is not recognized or approved by the organization.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T12:00:00Z","date_published":"2026-03-25T12:00:00Z","id":"/briefs/2026-03-device-code-phishing/","summary":"A phishing campaign abuses Microsoft's Device Code OAuth flow to gain access to cloud-based file storage and document workflow platforms, bypassing traditional credential harvesting.","title":"Device Code Phishing Campaign Targeting Cloud Platforms","url":"https://feed.craftedsignal.io/briefs/2026-03-device-code-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies a specific attack chain targeting Azure Arc-connected Kubernetes clusters. The attack begins with a service principal authenticating to Microsoft Entra ID and immediately requesting credentials for an Azure Arc-connected Kubernetes cluster. This \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action retrieves tokens enabling \u003ccode\u003ekubectl\u003c/code\u003e access via the Arc Cluster Connect proxy. This behavior is indicative of adversaries using stolen service principal secrets to gain unauthorized access and establish a proxy tunnel into Kubernetes environments. The rule prioritizes external service principal authentications (excluding managed identities) followed by Arc cluster credential access, particularly when sign-in origins are from unexpected locations or Autonomous System Numbers (ASNs). This activity was observed in attacks documented by IBM X-Force and Microsoft, as referenced below.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or obtains valid credentials for an Azure Service Principal.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf successful, the \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to interact with the Kubernetes cluster via \u003ccode\u003ekubectl\u003c/code\u003e proxied through Azure Arc.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of service principal credentials and subsequent access to Azure Arc-connected Kubernetes clusters can lead to significant data breaches, service disruption, and unauthorized resource access. Successful exploitation allows attackers to gain control over Kubernetes clusters, potentially leading to lateral movement within the environment, exfiltration of sensitive data, and deployment of malicious workloads. The number of victims and specific sectors targeted vary based on the attacker\u0026rsquo;s objectives and the compromised environment.\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 the described attack chain, tuning the \u003ccode\u003emaxspan\u003c/code\u003e value based on observed authentication patterns and network latency.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on unexpected sign-in locations or ASNs for the service principal (refer to the investigation fields in the rule definition).\u003c/li\u003e\n\u003cli\u003eImplement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).\u003c/li\u003e\n\u003cli\u003eReview and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).\u003c/li\u003e\n\u003cli\u003eEnable logging for Azure sign-in logs and activity logs to ensure the data sources are available for the detection rule (refer to Azure Monitor documentation).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-17T15:06:47Z","date_published":"2026-03-17T15:06:47Z","id":"/briefs/2024-01-02-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Microsoft Entra ID and then listing credentials for an Azure Arc-connected Kubernetes cluster within a short time window, indicating potential unauthorized access to Kubernetes clusters via stolen service principal secrets.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["fortigate","vpn","cve-2023-27997","exploit","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOn February 28, 2026, network intrusion detection systems (IDS) flagged suspicious activity indicative of a potential exploit targeting Fortigate VPN servers. The activity involves a series of repeated GET requests directed towards the \u003ccode\u003e/remote/logincheck\u003c/code\u003e endpoint, a known attack vector associated with CVE-2023-27997. This vulnerability allows unauthenticated attackers to execute arbitrary code via specially crafted requests. The observed traffic originates from the IPv6 address…\u003c/p\u003e\n","date_modified":"2026-02-28T00:46:45Z","date_published":"2026-02-28T00:46:45Z","id":"/briefs/2026-02-fortigate-vpn-cve-2023-27997/","summary":"IDS alerts indicate a potential exploitation attempt against a Fortigate VPN server using CVE-2023-27997, characterized by repeated GET requests to the /remote/logincheck endpoint originating from a specific IPv6 address.","title":"Fortigate VPN CVE-2023-27997 Exploitation Attempt","url":"https://feed.craftedsignal.io/briefs/2026-02-fortigate-vpn-cve-2023-27997/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Compute Cloud (EC2)"],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","ec2","keypair","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe unauthorized import of SSH key pairs into Amazon Elastic Compute Cloud (EC2) is a technique that malicious actors can leverage to gain unauthorized access to EC2 instances. By importing their own key pairs, attackers can bypass existing security measures and gain persistent access to compromised systems. This activity is often part of a broader attack campaign aimed at compromising sensitive data, disrupting services, or establishing a foothold within an organization\u0026rsquo;s cloud infrastructure. The initial publication of the detection rule was in December 2024, highlighting the ongoing relevance of this technique in cloud security. Monitoring for this activity can help defenders identify and respond to potential security breaches in a timely manner.\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 misconfigured IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate existing EC2 instances to identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker generates or obtains an SSH key pair, which they intend to use for unauthorized access.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eImportKeyPair\u003c/code\u003e API call within the EC2 service to import the generated or obtained SSH key pair.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the EC2 instance\u0026rsquo;s configuration to associate the newly imported key pair with the instance. This might involve stopping and restarting the instance.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the imported SSH key pair to gain SSH access to the EC2 instance.\u003c/li\u003e\n\u003cli\u003eOnce inside the instance, the attacker attempts to escalate privileges and move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data, deploys malware, or disrupts critical services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful key pair import can lead to complete compromise of the affected EC2 instances, potentially impacting dozens of servers depending on the environment. Sensitive data stored on or accessible from these instances could be exfiltrated, leading to financial loss, reputational damage, and regulatory fines. Furthermore, compromised instances can be used as a launchpad for further attacks within the AWS environment, leading to a wider breach. The financial impact can range from tens of thousands to millions of dollars, depending on the scale of the breach and the sensitivity of the data compromised.\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 \u003ccode\u003eImportKeyPair\u003c/code\u003e events in CloudTrail logs (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview IAM policies to ensure that only authorized users and roles have the necessary permissions to import key pairs (eventSource: \u0026rsquo;ec2.amazonaws.com\u0026rsquo;, eventName: \u0026lsquo;ImportKeyPair\u0026rsquo;).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003eImportKeyPair\u003c/code\u003e events, validating the user identity, user agent, and source IP address to ensure they are expected (detection block).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-12-19T00:00:00Z","date_published":"2024-12-19T00:00:00Z","id":"/briefs/2024-12-aws-key-pair-import/","summary":"The import of SSH key pairs into AWS EC2, as detected by CloudTrail logs, may indicate unauthorized access attempts, persistence establishment, or privilege escalation by an attacker.","title":"Suspicious AWS EC2 Key Pair Import Activity","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-key-pair-import/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["medium"],"_cs_tags":["github","ssh","certificate","initial-access","persistence","privilege-escalation","stealth","t1078.004"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eAttackers can abuse SSH certificate authorities in GitHub to gain unauthorized access to repositories. By creating or disabling SSH certificate requirements, attackers can bypass existing security controls and establish persistent access. This activity is logged in the GitHub audit logs, specifically when \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e actions are performed. Successful exploitation allows attackers to commit malicious code, steal sensitive data, or disrupt development workflows, impacting the integrity and confidentiality of the organization\u0026rsquo;s resources. The GitHub audit log streaming feature must be enabled to detect this activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSSH Certificate Authority Creation:\u003c/strong\u003e The attacker creates a new SSH certificate authority within the GitHub organization (\u003ccode\u003essh_certificate_authority.create\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisable SSH Certificate Requirement:\u003c/strong\u003e Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (\u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e). This action allows attackers to bypass security controls that enforce SSH certificate usage.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Access:\u003c/strong\u003e The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Code Injection:\u003c/strong\u003e The attacker exfiltrates sensitive data or injects malicious code into the organization\u0026rsquo;s repositories.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of SSH certificate configurations in GitHub can lead to unauthorized code commits, data breaches, and supply chain attacks. This could result in financial losses, reputational damage, and legal repercussions for the affected organization. The number of affected repositories and the severity of the impact depend on the scope of the attacker\u0026rsquo;s access and the sensitivity of the compromised data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).\u003c/li\u003e\n\u003cli\u003eRegularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T14:00:00Z","date_published":"2024-11-02T14:00:00Z","id":"/briefs/2024-11-github-ssh-cert-config-changed/","summary":"Attackers can modify SSH certificate configurations in GitHub organizations to gain unauthorized access, persist in the environment, escalate privileges, and operate stealthily.","title":"GitHub SSH Certificate Configuration Changed","url":"https://feed.craftedsignal.io/briefs/2024-11-github-ssh-cert-config-changed/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2023-42793"}],"_cs_exploited":false,"_cs_products":["TeamCity"],"_cs_severities":["medium"],"_cs_tags":["teamcity","supply-chain","initial-access"],"_cs_type":"advisory","_cs_vendors":["JetBrains"],"content_html":"\u003cp\u003eJetBrains TeamCity is a continuous integration and deployment server, making it a high-value target for attackers. Exploitation of TeamCity vulnerabilities can lead to remote code execution, enabling adversaries to compromise the software development pipeline. This activity is detected by monitoring for suspicious child processes initiated by the TeamCity Java executable, focusing on executables like \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, and \u003ccode\u003emsiexec.exe\u003c/code\u003e. The detection logic excludes legitimate operations to reduce false positives. This activity can lead to complete compromise of the build environment, allowing attackers to inject malicious code into software builds.\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 exploits a vulnerability (e.g., CVE-2023-42793) in the TeamCity server to gain initial access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCode Execution:\u003c/strong\u003e The attacker leverages the vulnerability to execute arbitrary code on the TeamCity server.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProcess Spawning:\u003c/strong\u003e The attacker spawns a command interpreter, such as \u003ccode\u003ecmd.exe\u003c/code\u003e or \u003ccode\u003epowershell.exe\u003c/code\u003e, from the TeamCity Java process (\u003ccode\u003ejava.exe\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker uses discovery commands via the spawned shell to enumerate users, network configuration, and running processes using tools like \u003ccode\u003ewhoami.exe\u003c/code\u003e, \u003ccode\u003eipconfig.exe\u003c/code\u003e, and \u003ccode\u003etasklist.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker leverages system binary proxy execution using tools like \u003ccode\u003emshta.exe\u003c/code\u003e or \u003ccode\u003eregsvr32.exe\u003c/code\u003e to evade detection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e While not explicitly mentioned, the attacker could establish persistence by creating scheduled tasks or modifying registry keys via spawned processes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker uses discovered credentials to move laterally to other systems within the network.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker injects malicious code into software builds, compromises sensitive data, or deploys ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of JetBrains TeamCity can lead to a full compromise of the software development lifecycle, resulting in supply chain attacks. Attackers can inject malicious code into software builds, leading to widespread distribution of compromised software. While specific victim counts are unavailable, this type of attack has the potential to affect numerous organizations relying on the compromised software. The Trend Micro research indicates that TeamCity vulnerability exploits can lead to Jasmin ransomware deployment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Suspicious JetBrains TeamCity Child Process\u0026rdquo; rule to your SIEM to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging to capture process execution events, which are essential for triggering the detection rule.\u003c/li\u003e\n\u003cli\u003eReview and patch any known vulnerabilities in JetBrains TeamCity, focusing on remote code execution flaws as described in the referenced Trend Micro report.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the impact of a compromised TeamCity server and prevent lateral movement.\u003c/li\u003e\n\u003cli\u003eContinuously monitor TeamCity server logs for any unusual activity or unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eTune the \u0026ldquo;Suspicious JetBrains TeamCity Child Process\u0026rdquo; rule by creating exceptions for legitimate build scripts that invoke command-line utilities to reduce false positives, as mentioned in the rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-15T12:00:00Z","date_published":"2024-05-15T12:00:00Z","id":"/briefs/2024-05-jetbrains-teamcity-suspicious-child-process/","summary":"Detection of suspicious processes spawned by JetBrains TeamCity indicates potential exploitation of remote code execution vulnerabilities, with attackers using command interpreters and system binaries for malicious purposes.","title":"Suspicious Child Processes Spawned by JetBrains TeamCity","url":"https://feed.craftedsignal.io/briefs/2024-05-jetbrains-teamcity-suspicious-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["OpenCanary"],"_cs_severities":["high"],"_cs_tags":["honeypot","ssh","initial-access"],"_cs_type":"advisory","_cs_vendors":["thinkst"],"content_html":"\u003cp\u003eOpenCanary is a low-interaction honeypot designed to detect attackers on a network. This brief focuses on detecting SSH login attempts on OpenCanary nodes, which are designed to mimic real SSH servers but log any interaction. While the OpenCanary project itself has been around for several years, its integration with modern detection strategies makes it a valuable tool for defenders. An SSH login attempt against an OpenCanary instance signifies that an attacker is actively scanning or attempting to compromise systems within the network. This activity might be part of a broader campaign, including lateral movement, privilege escalation, or data exfiltration. The detection of such attempts allows for timely incident response and mitigation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the network, possibly through phishing, exploiting a vulnerability, or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker performs network scanning to identify potential targets, including the OpenCanary node masquerading as a legitimate SSH server.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish an SSH connection to the OpenCanary node, attempting to authenticate using various usernames and passwords.\u003c/li\u003e\n\u003cli\u003eThe OpenCanary service logs the failed SSH login attempt, recording the source IP address and attempted credentials.\u003c/li\u003e\n\u003cli\u003eSecurity monitoring tools ingest the OpenCanary logs and trigger an alert based on the detected SSH login attempt.\u003c/li\u003e\n\u003cli\u003eSecurity analysts investigate the alert, analyzing the source IP address and other relevant information to determine the scope and severity of the potential breach.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful SSH login attempt on a real server could lead to complete system compromise, data exfiltration, and disruption of services. While OpenCanary is designed to be a honeypot, detecting login attempts early allows for proactive measures to prevent attackers from reaching critical assets. Identifying the attacker\u0026rsquo;s source IP address and attempted usernames can provide valuable insights into their tactics and objectives, preventing damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;OpenCanary - SSH Login Attempt\u0026rdquo; to your SIEM to detect unauthorized SSH login attempts on OpenCanary nodes.\u003c/li\u003e\n\u003cli\u003eInvestigate and block any identified malicious source IP addresses from network access using firewall rules.\u003c/li\u003e\n\u003cli\u003eReview OpenCanary configuration to ensure it is deployed in strategically valuable network segments (references: OpenCanary documentation).\u003c/li\u003e\n\u003cli\u003eCorrelate OpenCanary alerts with other security events to identify potential broader attack campaigns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T14:30:00Z","date_published":"2024-05-02T14:30:00Z","id":"/briefs/2024-05-opencanary-ssh-login/","summary":"Detects instances where an SSH service on an OpenCanary node has had a login attempt, indicating potential reconnaissance, privilege escalation, or lateral movement.","title":"OpenCanary SSH Login Attempt Detection","url":"https://feed.craftedsignal.io/briefs/2024-05-opencanary-ssh-login/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Engine"],"_cs_severities":["high"],"_cs_tags":["okta","identity","privilege-escalation","persistence","defense-evasion","initial-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting unusual behaviors within the Okta Admin Console, as identified by Okta\u0026rsquo;s heuristics. While the specific campaign details are unknown, identifying anomalous access patterns to the Admin Console is crucial for detecting various malicious activities. This includes potential privilege escalation by compromised accounts or insider threats attempting to gain elevated permissions, establishing persistence through unauthorized modifications, evading existing security controls, or gaining initial access through account compromise. The detection relies on Okta\u0026rsquo;s system logs which can signal unusual administrative activity. Defenders should prioritize monitoring and alerting on these events to quickly identify and respond to potential security breaches.\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 Okta account, possibly through credential phishing or brute-force attacks.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to the Okta Admin Console.\u003c/li\u003e\n\u003cli\u003eOkta\u0026rsquo;s behavior detection engine analyzes the login attempt, considering factors like the user\u0026rsquo;s location, device, and time of day.\u003c/li\u003e\n\u003cli\u003eThe system logs record a \u003ccode\u003epolicy.evaluate_sign_on\u003c/code\u003e event when a sign-on policy is evaluated.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003etarget.displayName\u003c/code\u003e field within the log specifies \u0026ldquo;Okta Admin Console\u0026rdquo; indicating the user is attempting to access the administrative interface.\u003c/li\u003e\n\u003cli\u003eIf Okta identifies the behavior as unusual, the \u003ccode\u003edebugContext.debugData.behaviors\u003c/code\u003e or \u003ccode\u003edebugContext.debugData.logOnlySecurityData\u003c/code\u003e fields will contain \u0026ldquo;POSITIVE\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eAn alert is triggered based on the identified unusual behavior.\u003c/li\u003e\n\u003cli\u003eThe attacker, if successful in bypassing initial checks, may proceed to create new admin accounts, modify existing policies, or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of the Okta Admin Console can lead to significant damage, including unauthorized access to sensitive data, modification of security policies, creation of rogue administrator accounts, and ultimately, a complete takeover of the Okta environment. This can impact all applications and services integrated with Okta, potentially affecting thousands of users and causing significant financial and reputational damage. Early detection is crucial to limiting the scope and impact of such attacks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eOkta Admin Console Unusual Behavior\u003c/code\u003e to your SIEM to detect suspicious Okta Admin Console access based on Okta\u0026rsquo;s internal behavior analysis.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine if the unusual behavior is legitimate or indicative of malicious activity.\u003c/li\u003e\n\u003cli\u003eReview Okta\u0026rsquo;s System Log API documentation to understand the various event types and data fields available for monitoring and detection.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta accounts, especially administrator accounts, to mitigate the risk of account compromise (related to initial access).\u003c/li\u003e\n\u003cli\u003eMonitor Okta\u0026rsquo;s security advisories and announcements for updates on emerging threats and recommended security practices (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T10:00:00Z","date_published":"2024-05-02T10:00:00Z","id":"/briefs/2024-05-okta-admin-console-behaviors/","summary":"This brief details detection of anomalous activity within the Okta Admin Console, potentially indicating privilege escalation, persistence, defense evasion, or initial access attempts by malicious actors.","title":"Okta Admin Console Unusual Behavior Detection","url":"https://feed.craftedsignal.io/briefs/2024-05-okta-admin-console-behaviors/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["medium"],"_cs_tags":["bitbucket","authentication","brute-force","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user login failures within Bitbucket environments. Monitoring failed login attempts is crucial as it can indicate various malicious activities, including credential stuffing, brute-force attacks, or attempts to gain unauthorized initial access. The audit logs in Bitbucket record details of these authentication failures, providing valuable data for security monitoring. The rule provided detects these events and can be used for correlation with other security events based on the \u0026ldquo;author.name\u0026rdquo; field for enhanced accuracy and context. Requires \u0026ldquo;Advance\u0026rdquo; log level to receive audit events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access Attempt:\u003c/strong\u003e An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Guessing:\u003c/strong\u003e The attacker attempts to guess the user\u0026rsquo;s password through manual attempts or automated tools.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Failure:\u003c/strong\u003e Bitbucket records a \u0026ldquo;User login failed\u0026rdquo; event due to incorrect credentials. The \u003ccode\u003eauditType.category\u003c/code\u003e is Authentication, and \u003ccode\u003eauditType.action\u003c/code\u003e is User login failed.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMultiple Failed Attempts:\u003c/strong\u003e The attacker repeats the login attempts with different password variations or using a list of compromised credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Lockout (Optional):\u003c/strong\u003e Depending on Bitbucket\u0026rsquo;s configuration, repeated failed login attempts may trigger an account lockout.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Login (Potential):\u003c/strong\u003e After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation/Persistence (If Successful):\u003c/strong\u003e If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.\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 code repositories, intellectual property theft, and potential supply chain compromise. Attackers could inject malicious code, modify existing code, or exfiltrate sensitive data. Detecting these failed login attempts early can prevent significant damage. Although the number of victims cannot be determined with this specific detection, a successful attack can have far-reaching impacts.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Bitbucket User Login Failure\u0026rdquo; to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.\u003c/li\u003e\n\u003cli\u003eInvestigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual activity following any successful login after a series of failures.\u003c/li\u003e\n\u003cli\u003eEnforce strong password policies to reduce the effectiveness of brute-force attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-03-08T15:00:00Z","date_published":"2024-03-08T15:00:00Z","id":"/briefs/2024-03-bitbucket-login-fail/","summary":"Detection of Bitbucket user login failures, potentially indicating credential access attempts, initial access attempts, or other malicious activity.","title":"Bitbucket User Login Failure Detection","url":"https://feed.craftedsignal.io/briefs/2024-03-bitbucket-login-fail/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Actions"],"_cs_severities":["low"],"_cs_tags":["github","persistence","privilege-escalation","initial-access"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis detection identifies the creation of new secrets within GitHub Actions. Threat actors may create or modify secrets to gain unauthorized access, establish persistence, or escalate privileges within the GitHub environment. The activity is captured via GitHub\u0026rsquo;s audit logs. The scope of this detection encompasses the creation of secrets at the organization, environment, codespaces, or repository level. Successful detection of this activity allows security teams to investigate potentially malicious modifications to GitHub Actions secrets, which could lead to supply chain compromise or data exfiltration.\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 GitHub account, potentially through compromised credentials or phishing (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub organization or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings for the organization, environment, codespaces, or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.\u003c/li\u003e\n\u003cli\u003eThe secret is stored within GitHub\u0026rsquo;s infrastructure, accessible to GitHub Actions workflows.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.\u003c/li\u003e\n\u003cli\u003eThe workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.\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, code injection, and supply chain compromise. The impact ranges from low, in cases where the secret is used for benign purposes, to critical if the secret is used to deploy malicious code into production environments. While the number of affected organizations is unknown, the potential for widespread impact across the software supply chain makes this a critical area for monitoring.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable GitHub audit log streaming to capture the events necessary for this detection (see \u003ccode\u003elogsource\u003c/code\u003e definition).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGithub New Secret Created\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u0026ldquo;actor\u0026rdquo; involved in creating the secret.\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-github-secret-creation/","summary":"This analytic detects the creation of new GitHub Actions secrets at the organization, environment, codespaces, or repository level, potentially indicating malicious persistence or privilege escalation.","title":"Detection of New GitHub Actions Secrets Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-github-secret-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","initial-access","credential-access"],"_cs_type":"advisory","_cs_vendors":["Amazon","Google","Microsoft","MongoDB"],"content_html":"\u003cp\u003eThis detection identifies AWS identities that primarily use API traffic originating from well-known cloud providers (e.g., Amazon, Google, Microsoft), but also exhibit a small amount of traffic from less common Autonomous System (AS) organizations. This pattern can indicate that automation or CI credentials are being reused or pivoted outside of their usual hosted cloud environment. The detection focuses on successful API calls and looks for a combination of high volume from trusted cloud providers and at least one sensitive action originating from an uncommon network. This behavior could be indicative of credential compromise and lateral movement. This rule was published by Elastic on 2026-04-22.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to valid AWS credentials, potentially through phishing, credential stuffing, or exposed secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to make API calls from their own infrastructure, which is associated with a rare AS organization.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance, such as \u003ccode\u003eGetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, or \u003ccode\u003eListSecrets\u003c/code\u003e, to understand the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by calling \u003ccode\u003eAssumeRole\u003c/code\u003e, \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, or \u003ccode\u003eCreateAccessKey\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access sensitive data using actions such as \u003ccode\u003eGetObject\u003c/code\u003e or \u003ccode\u003eGetSecretValue\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or modify existing user profiles using actions such as \u003ccode\u003eCreateUser\u003c/code\u003e, \u003ccode\u003eUpdateLoginProfile\u003c/code\u003e, or \u003ccode\u003eAddUserToGroup\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to invoke cloud ML models using \u003ccode\u003eInvokeModel\u003c/code\u003e or \u003ccode\u003eConverse\u003c/code\u003e to further their objectives.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment by creating new IAM users, roles, or policies, or by modifying existing ones.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data stored in S3 buckets, Secrets Manager, or other AWS services. It can also allow the attacker to escalate privileges, create new users, and modify existing configurations, leading to long-term control of the AWS environment. The severity of the impact depends on the level of access granted to the compromised credentials. This can lead to exfiltration of sensitive data, denial of service, or complete compromise of the AWS account.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable AWS CloudTrail logging in all regions and send logs to a centralized SIEM or logging platform to enable detection capabilities (\u003ca href=\"https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html\"\u003ereferences\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Rare Source AS Organization Activity\u0026rdquo; translated from the provided ESQL query to detect unusual source ASNs for AWS API calls.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the rule, focusing on the \u003ccode\u003euser.name\u003c/code\u003e, \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e, \u003ccode\u003eEsql.src_asn_values\u003c/code\u003e, and \u003ccode\u003eEsql.untrusted_suspicious_actions\u003c/code\u003e to understand the context of the activity.\u003c/li\u003e\n\u003cli\u003eRotate credentials for the affected principal if abuse is suspected and enforce OIDC or short-lived keys for automation.\u003c/li\u003e\n\u003cli\u003eTighten IAM and data-plane permissions to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-29-aws-rare-asn/","summary":"This rule detects AWS identities with API traffic dominated by cloud-provider source AS organization labels, but also exhibit traffic from other AS organizations, potentially indicating credential reuse or pivoting.","title":"AWS Identity API Access from Rare ASN Organizations","url":"https://feed.craftedsignal.io/briefs/2024-01-29-aws-rare-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Google Workspace"],"_cs_severities":["medium"],"_cs_tags":["initial-access","privilege-escalation","defense-evasion","persistence","gworkspace"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis brief focuses on detecting suspicious login activity within Google Workspace environments, as flagged by Google\u0026rsquo;s internal risk assessment mechanisms. Google Workspace logs login events and classifies them based on various risk factors, including the use of less secure applications, programmatic logins, and other anomalies. This detection capability is crucial for identifying potential compromises, unauthorized access attempts, and malicious activities within the Google Workspace ecosystem. Analyzing these flagged events allows security teams to proactively respond to threats before they escalate, preventing data breaches and maintaining the integrity of sensitive information. This alert focuses on logins classified as \u0026lsquo;suspicious_login_less_secure_app\u0026rsquo;, \u0026lsquo;suspicious_login\u0026rsquo;, and \u0026lsquo;suspicious_programmatic_login\u0026rsquo;.\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 using compromised credentials or brute-force techniques targeting Google Workspace accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLogin Attempt:\u003c/strong\u003e The attacker attempts to log in to a Google Workspace account using a less secure application (e.g., an older email client without modern authentication) or via programmatic login.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuspicious Activity Detection:\u003c/strong\u003e Google\u0026rsquo;s internal systems analyze the login attempt and flag it as suspicious based on various risk factors, such as unusual location, time of day, or login method.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEvent Logging:\u003c/strong\u003e Google Workspace logs the suspicious login event, including the reason for the classification (e.g., \u0026lsquo;suspicious_login_less_secure_app\u0026rsquo;).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePotential Privilege Escalation:\u003c/strong\u003e Upon successful login, the attacker may attempt to escalate privileges within the Google Workspace environment to gain broader access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Evasion:\u003c/strong\u003e The attacker might use techniques to evade detection, such as disabling security features or modifying audit logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating new accounts, modifying existing ones, or installing malicious apps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Activity:\u003c/strong\u003e The attacker uses the compromised account to exfiltrate sensitive data or perform other malicious activities, such as sending phishing emails.\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 within Google Workspace, including emails, documents, and other files. This can result in data breaches, financial loss, and reputational damage. The number of affected users depends on the scope of the compromised account and the attacker\u0026rsquo;s ability to escalate privileges. Targeted sectors are broad, affecting any organization relying on Google Workspace for collaboration and data storage.\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 suspicious login activity classified by Google Workspace (logsource: \u003ccode\u003egcp\u003c/code\u003e, service: \u003ccode\u003egoogle_workspace.login\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the login attempt and take appropriate action, such as resetting passwords or disabling compromised accounts.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all Google Workspace accounts to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eDisable or restrict the use of less secure apps within Google Workspace to reduce the attack surface.\u003c/li\u003e\n\u003cli\u003eMonitor Google Workspace audit logs for other suspicious activities, such as unusual file access or data exfiltration attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T10:00:00Z","date_published":"2024-01-26T10:00:00Z","id":"/briefs/2024-01-26-gworkspace-suspicious-login/","summary":"Detect Google Workspace login activity that Google has classified as suspicious, potentially indicating initial access, privilege escalation, defense evasion, or persistence attempts.","title":"Google Workspace Suspicious Login Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-26-gworkspace-suspicious-login/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elasticsearch"],"_cs_severities":["high"],"_cs_tags":["initial-access","network","rpc"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies RPC traffic originating from the internet, which can indicate malicious activity. RPC is used for remote system administration and resource sharing but should rarely be exposed to the internet. Threat actors frequently target RPC for initial access or as a backdoor. This rule analyzes network traffic, specifically looking for TCP connections to port 135 (a common RPC port) originating from outside the internal network. The rule aims to detect unauthorized attempts to access or control systems via RPC from external sources, enhancing network security and preventing potential breaches. The rule was last updated on 2026-04-24.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker scans the internet for systems with exposed RPC services on TCP port 135.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes a TCP connection to the target system\u0026rsquo;s port 135.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to negotiate an RPC connection, potentially exploiting vulnerabilities in the RPC service.\u003c/li\u003e\n\u003cli\u003eSuccessful exploitation allows the attacker to execute commands remotely on the target system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised system to perform reconnaissance, gathering information about the internal network.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts lateral movement to other systems within the network, using the initial foothold.\u003c/li\u003e\n\u003cli\u003eThe attacker installs malware or creates a backdoor for persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of exposed RPC services can lead to complete system compromise, allowing attackers to execute arbitrary commands, install malware, and steal sensitive data. This can result in data breaches, financial loss, and reputational damage. The rule aims to prevent attackers from gaining initial access to internal systems, mitigating the risk of wider network compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect RPC from Internet\u0026rdquo; to your SIEM to identify potentially malicious connections to port 135.\u003c/li\u003e\n\u003cli\u003eReview and harden systems that provide RPC services to ensure they are not directly exposed to the internet, as detected by the rule \u0026ldquo;Detect RPC from Internet\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eEnforce network segmentation to limit the exposure of critical systems and services, preventing RPC services from being accessible from the Internet (reference: note section in the rule).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by examining the source and destination IP addresses and related network traffic logs (reference: note section in the rule).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:23:00Z","date_published":"2024-01-09T18:23:00Z","id":"/briefs/2024-01-09-rpc-from-internet/","summary":"This brief focuses on detecting Remote Procedure Call (RPC) traffic originating from the internet, a common initial access vector, by monitoring network connections to TCP port 135 and filtering known internal IP ranges.","title":"Detecting External RPC Traffic for Initial Access","url":"https://feed.craftedsignal.io/briefs/2024-01-09-rpc-from-internet/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Management Console"],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","mfa","initial-access"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe absence of multi-factor authentication (MFA) during AWS console logins presents a significant security risk. Threat actors often target AWS environments due to the high value of data and services hosted within. An attacker gaining initial access through compromised credentials can move laterally, escalate privileges, and potentially exfiltrate sensitive data, deploy malicious workloads, or disrupt critical services. This activity can go unnoticed for extended periods, increasing the potential for damage. Detecting successful console logins without MFA is crucial for identifying potential breaches and ensuring the enforcement of security best practices. This brief focuses on detecting these logins to mitigate the risk of unauthorized access and potential data breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid AWS credentials, possibly through phishing, credential stuffing, or by exploiting a vulnerable service.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to attempt to log in to the AWS Management Console.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully authenticates without providing an MFA code, indicating MFA is not enabled or is bypassed for the compromised user.\u003c/li\u003e\n\u003cli\u003eAfter successful login, the attacker enumerates existing AWS resources, including EC2 instances, S3 buckets, and IAM roles, using the AWS CLI or Console.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting IAM misconfigurations or vulnerabilities to gain access to more sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security configurations, such as disabling CloudTrail logging or creating new IAM users with elevated permissions, to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses sensitive data stored in S3 buckets or databases, potentially exfiltrating it to an external location.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful AWS console login without MFA can lead to a full compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious workloads. The lack of MFA increases the likelihood of successful credential-based attacks, potentially affecting a large number of organizations hosting data and applications in AWS. Consequences include data breaches, financial losses, reputational damage, and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS Successful Console Login Without MFA\u0026rdquo; Sigma rule to your SIEM to detect logins without MFA (rule).\u003c/li\u003e\n\u003cli\u003eEnforce MFA for all AWS IAM users, especially those with administrative privileges to prevent initial access (reference: \u003ca href=\"https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/)\"\u003ehttps://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eRegularly audit IAM configurations to identify and remediate misconfigurations that could allow privilege escalation.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for suspicious activity following a console login, such as resource enumeration or IAM policy changes (logsource).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"/briefs/2024-01-09-aws-console-login-no-mfa/","summary":"Successful AWS console logins without multi-factor authentication can indicate compromised credentials, misconfigured security settings, or unauthorized access attempts.","title":"Successful AWS Console Login Without MFA","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-console-login-no-mfa/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2023-50164"}],"_cs_exploited":false,"_cs_products":["Struts 2"],"_cs_severities":["high"],"_cs_tags":["apache-struts","webshell","cve-2023-50164","initial-access","persistence","command-and-control"],"_cs_type":"advisory","_cs_vendors":["Apache"],"content_html":"\u003cp\u003eCVE-2023-50164 is a critical path traversal vulnerability affecting Apache Struts 2 versions prior to 2.5.33 or 6.3.0.2. The vulnerability resides in the file upload functionality, allowing attackers to manipulate file upload parameters and write malicious files, such as JSP web shells, to arbitrary locations on the web server. Successful exploitation leads to remote code execution. Detection focuses on correlating suspicious file upload requests to Struts endpoints with subsequent creation of JSP files in web-accessible directories, indicating successful exploitation. The attack involves crafting malicious multipart/form-data POST requests with WebKitFormBoundary to Struts .action upload endpoints.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a malicious HTTP POST request to a vulnerable Apache Struts endpoint (e.g., \u003ccode\u003e*.action\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe HTTP POST request contains a \u003ccode\u003emultipart/form-data\u003c/code\u003e content type with a \u003ccode\u003eWebKitFormBoundary\u003c/code\u003e string.\u003c/li\u003e\n\u003cli\u003eThe request exploits CVE-2023-50164, leveraging a path traversal vulnerability in the file upload process.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses security controls due to the path traversal vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uploads a malicious JSP file (web shell) to a web-accessible directory, such as Tomcat\u0026rsquo;s \u003ccode\u003ewebapps\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eA Java process (e.g., Tomcat) creates the JSP web shell file in the webapps directory.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the deployed web shell via HTTP.\u003c/li\u003e\n\u003cli\u003eThe attacker executes arbitrary commands on the server through the web shell.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2023-50164 allows attackers to achieve remote code execution on the affected server. This can lead to complete system compromise, data exfiltration, deployment of malware, and lateral movement within the network. The vulnerability affects Apache Struts 2 applications using the file upload feature, potentially impacting numerous organizations across various sectors using the framework.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Apache Struts CVE-2023-50164 Webshell Creation\u0026rdquo; to detect JSP file creation events in webapps directories following suspicious POST requests as described in the overview.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Apache Struts CVE-2023-50164 Suspicious POST Request\u0026rdquo; to detect suspicious POST requests to Struts endpoints with \u003ccode\u003emultipart/form-data\u003c/code\u003e content containing \u003ccode\u003eWebKitFormBoundary\u003c/code\u003e, as indicated in the Attack Chain.\u003c/li\u003e\n\u003cli\u003ePatch Apache Struts 2 to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability, as noted in the References.\u003c/li\u003e\n\u003cli\u003eEnable HTTP request body capture in network traffic monitoring tools to detect the multipart/form-data content containing WebKitFormBoundary indicators, as required by the rule setup.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-05T18:22:00Z","date_published":"2024-01-05T18:22:00Z","id":"/briefs/2024-01-apache-struts-cve-2023-50164-webshell/","summary":"Exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2, is detected by identifying malicious multipart/form-data POST requests with WebKitFormBoundary targeting Struts .action upload endpoints, followed by JSP web shell creation in Tomcat's webapps directories, indicating remote code execution.","title":"Apache Struts CVE-2023-50164 Exploitation Leading to Web Shell Deployment","url":"https://feed.craftedsignal.io/briefs/2024-01-apache-struts-cve-2023-50164-webshell/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["low"],"_cs_tags":["execution","initial-access","defense-evasion","discovery"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eAttackers are increasingly leveraging PDF reader applications as an initial access vector, exploiting vulnerabilities within these programs or using social engineering to trick users into opening malicious PDF documents. Upon successful exploitation, adversaries often spawn built-in Windows utilities from the compromised PDF reader process to perform reconnaissance, escalate privileges, or establish persistence. This activity is designed to blend in with normal system operations, making it difficult to detect without specific monitoring and detection rules. The targeted software commonly includes Adobe Acrobat, Adobe Reader, and Foxit Reader. Defenders should be vigilant for unexpected child processes of PDF readers, especially command-line interpreters and system administration tools.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user receives a malicious PDF document via phishing or other means.\u003c/li\u003e\n\u003cli\u003eThe user opens the PDF document using a vulnerable PDF reader application (e.g., Adobe Acrobat, Foxit Reader).\u003c/li\u003e\n\u003cli\u003eThe PDF document exploits a vulnerability or uses a malicious script to execute an arbitrary command.\u003c/li\u003e\n\u003cli\u003eThe PDF reader application spawns a command-line interpreter (e.g., cmd.exe, powershell.exe) or a system administration tool (e.g., reg.exe, net.exe).\u003c/li\u003e\n\u003cli\u003eThe spawned process executes commands to gather system information (e.g., ipconfig.exe, systeminfo.exe, whoami.exe).\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to discover network configuration, user accounts, or running processes.\u003c/li\u003e\n\u003cli\u003eThe attacker could leverage the spawned process to download and execute further payloads.\u003c/li\u003e\n\u003cli\u003eThe attacker gains a foothold on the system and can proceed with lateral movement, data exfiltration, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of PDF reader applications can lead to initial access, privilege escalation, and further compromise of the affected system. While individual incidents may have a low risk score, widespread exploitation can lead to significant data breaches, system downtime, and reputational damage. The use of legitimate system utilities for malicious purposes can make detection challenging, allowing attackers to operate undetected for extended periods.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging with command line arguments to capture the execution of suspicious child processes (Sysmon Event ID 1, Windows Security Event Logs).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious PDF Reader Child Process\u0026rdquo; to your SIEM and tune for your environment to detect the execution of suspicious processes spawned by PDF reader applications.\u003c/li\u003e\n\u003cli\u003eMonitor for network connections originating from PDF reader applications to unusual or external IP addresses.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unauthorized or unknown executables.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T18:45:00Z","date_published":"2024-01-04T18:45:00Z","id":"/briefs/2024-01-suspicious-pdf-child-process/","summary":"Adversaries may exploit PDF reader applications to execute arbitrary commands and establish a foothold within a system, often launching built-in utilities for reconnaissance and privilege escalation.","title":"Suspicious PDF Reader Child Process Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-pdf-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS STS"],"_cs_severities":["medium"],"_cs_tags":["aws","saml","cloudtrail","initial-access","lateral-movement","persistence","privilege-escalation","stealth"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e and \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events. An adversary might exploit SAML to gain unauthorized access, escalate privileges, move laterally within the AWS environment, or establish persistent backdoor access. The focus is on detecting unusual or unauthorized modifications to SAML configurations and role assumptions, which could indicate a compromised identity provider or malicious actor leveraging SAML for illicit purposes. Defenders should prioritize monitoring SAML-related API calls to identify and mitigate potential threats early in the attack chain.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or creates a malicious SAML identity provider.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the AWS environment to trust the malicious SAML provider using \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a SAML assertion to assume a specific role within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e API call to authenticate with AWS using the crafted SAML assertion.\u003c/li\u003e\n\u003cli\u003eAWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation via SAML manipulation can lead to a complete compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious infrastructure. The impact includes potential data breaches, financial losses, and reputational damage. The number of affected resources depends on the permissions associated with the roles assumed by the attacker.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule for \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e events to detect suspicious role assumptions (see \u0026ldquo;AssumeRoleWithSAML Detection Rule\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule for \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events to detect unauthorized SAML provider modifications (see \u0026ldquo;UpdateSAMLProvider Detection Rule\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eAssumeRoleWithSAML\u003c/code\u003e events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eUpdateSAMLProvider\u003c/code\u003e events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.\u003c/li\u003e\n\u003cli\u003eTune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:30Z","date_published":"2024-01-03T18:22:30Z","id":"/briefs/2024-01-03-aws-suspicious-saml/","summary":"This rule identifies suspicious SAML activity in AWS, such as AssumeRoleWithSAML and UpdateSAMLProvider events, which could indicate an attacker gaining backdoor access, escalating privileges, or establishing persistence.","title":"Suspicious AWS SAML Activity Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-suspicious-saml/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azuread","temporary-access-pass","privilege-escalation","initial-access","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies when a temporary access pass (TAP) is added to an Azure Active Directory (Azure AD) account. TAPs are intended for temporary use, allowing users to access resources or perform actions without needing a password. While legitimate use cases exist, adversaries can leverage TAPs to gain unauthorized access, escalate privileges, establish persistence, or move laterally within an Azure environment. This activity warrants investigation, especially if the TAP is added to a privileged account. The source material does not indicate a specific campaign or threat actor, but the technique aligns with common cloud-based attack vectors.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise (Optional):\u003c/strong\u003e An attacker gains initial access to an Azure AD account through compromised credentials or other means.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e The attacker escalates privileges to an account with sufficient permissions to manage TAPs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTAP Generation:\u003c/strong\u003e The attacker, using an account with appropriate permissions, generates a temporary access pass (TAP) for a target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTAP Activation:\u003c/strong\u003e The attacker uses the TAP to authenticate to the target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Access:\u003c/strong\u003e Once authenticated, the attacker gains access to resources and applications associated with the target account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Optional):\u003c/strong\u003e The attacker uses the compromised account to access other resources or accounts within the environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence (Optional):\u003c/strong\u003e The attacker establishes persistence by creating new credentials or modifying existing ones, if permissions allow.\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, systems, and applications within the Azure environment. Compromised privileged accounts can grant attackers control over critical infrastructure, leading to data breaches, service disruptions, and reputational damage. The impact depends on the permissions associated with the compromised account and the resources accessible through the TAP.\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 TAP additions in Azure AD audit logs (see rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where TAPs are added to privileged accounts in Azure AD, as highlighted in the rule description and references.\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for suspicious activity surrounding the TAP generation event, including the source IP address and user agent (see rules).\u003c/li\u003e\n\u003cli\u003eMonitor for anomalous sign-in activity using TAPs, specifically focusing on unusual locations or devices.\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-azure-tap-added/","summary":"Detection of a temporary access pass (TAP) being added to an Azure AD account, which could indicate potential privilege escalation, initial access, persistence, or stealth activity.","title":"Azure AD Temporary Access Pass Added to Account","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-tap-added/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["high"],"_cs_tags":["identity","cloud","okta","initial-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eAttackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials. This behavior often triggers additional detection rules after the initial authentication. By correlating the first instance of Okta user authentication via a proxy with subsequent Okta security alerts for the same user, this rule aims to identify potentially compromised accounts. This correlation focuses on activity within a 30-minute window following the initial proxy authentication, helping to pinpoint users whose proxy-based authentication was followed by suspicious activity. The rule leverages Okta system logs and alerts to identify these patterns. This is important for defenders to quickly identify compromised accounts and prevent further damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid Okta credentials through phishing, credential stuffing, or other means. (T1078)\u003c/li\u003e\n\u003cli\u003eThe attacker initiates an Okta user session from behind a proxy (VPN, Tor, etc.) to mask their origin.\u003c/li\u003e\n\u003cli\u003eOkta classifies the connection as originating from a proxy.\u003c/li\u003e\n\u003cli\u003eThe user successfully authenticates and starts a session.\u003c/li\u003e\n\u003cli\u003ePost-authentication, the attacker attempts to access sensitive applications or data. (T1078.004)\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s activity triggers an Okta security alert, such as unusual access patterns or MFA bypass attempts.\u003c/li\u003e\n\u003cli\u003eThe detection rule correlates the proxy authentication event with the subsequent security alert.\u003c/li\u003e\n\u003cli\u003eSecurity team investigates and responds to the potential account compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the organization\u0026rsquo;s cloud environment. Multiple alerts, coupled with proxy authentication, indicate a higher likelihood of account compromise. If successful, attackers could exfiltrate sensitive data, modify configurations, or disrupt services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Alerts Following Unusual Proxy Authentication\u0026rdquo; to your SIEM and tune for your environment to detect suspicious activity after proxy authentication.\u003c/li\u003e\n\u003cli\u003eInvestigate correlated security alerts triggered after proxy authentication events for affected users, as highlighted by the Sigma rule.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for authentication events originating from known malicious proxy IP addresses and block them at the network perimeter.\u003c/li\u003e\n\u003cli\u003eReview user\u0026rsquo;s Okta activity for signs of account takeover (MFA changes, new devices, unusual app access) after proxy authentication.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to reduce the risk of account compromise via stolen credentials, as this attack relies on valid 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-okta-proxy-auth-alerts/","summary":"Attackers use proxy infrastructure to mask their origin when using stolen Okta credentials, and this rule correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user.","title":"Okta Alerts Following Unusual Proxy Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-proxy-auth-alerts/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","password-reset","privilege-escalation","initial-access","persistence","credential-access","stealth"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user-initiated password resets within Azure Active Directory (Azure AD). While legitimate password resets are common, monitoring this activity can help identify potentially malicious behavior, such as an attacker attempting to gain unauthorized access to an account or an insider threat actor escalating privileges. Attackers may leverage compromised credentials or social engineering to initiate password resets, bypassing multi-factor authentication (MFA) if it is not properly configured or enforced. This detection is important for defenders because successful password resets can lead to a complete account takeover, allowing attackers to access sensitive data, resources, and systems.\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 user\u0026rsquo;s credentials through phishing, credential stuffing, or malware.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a password reset request using the \u0026ldquo;Forgot password\u0026rdquo; feature or a similar mechanism.\u003c/li\u003e\n\u003cli\u003eAzure AD sends a password reset verification code or link to the user\u0026rsquo;s registered email address or phone number.\u003c/li\u003e\n\u003cli\u003eIf the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the verification code or link to set a new password for the user\u0026rsquo;s Azure AD account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs in to the Azure AD account with the new password, gaining unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful password resets by attackers can lead to complete account takeover, allowing them to access sensitive data, resources, and systems protected by Azure AD. This can result in data breaches, financial loss, reputational damage, and disruption of business operations. The impact depends on the privileges and permissions assigned to the compromised account.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePassword Reset By User Account\u003c/code\u003e to your SIEM to detect user-initiated password resets in Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected password resets, especially those initiated by users who have not recently requested a password change.\u003c/li\u003e\n\u003cli\u003eReview and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.\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-user-password-reset/","summary":"Detects when a user successfully resets their own password in Azure Active Directory, which may indicate malicious activity or account compromise.","title":"Azure AD User Password Reset Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-user-password-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["initial-access","execution","windows","powershell","script"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne"],"content_html":"\u003cp\u003eThis detection identifies PowerShell execution initiated by Windows Script Host processes (cscript.exe or wscript.exe). Attackers often use Windows Script Host (WSH) to execute malicious scripts as an initial access method. These scripts can act as droppers for second-stage payloads or download tools and utilities necessary for further compromise. The rule focuses on the parent-child process relationship between WSH and PowerShell, highlighting a common technique used to bypass security controls and execute arbitrary commands on a compromised system. This activity is relevant to defenders as it represents a potential entry point for various attacks, including malware deployment and data exfiltration. The detection logic is based on process execution events observed in Windows environments and 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\u003eThe user receives a phishing email with a malicious attachment (e.g., a .vbs or .js file).\u003c/li\u003e\n\u003cli\u003eThe user opens the attachment, which is processed by either wscript.exe or cscript.exe.\u003c/li\u003e\n\u003cli\u003eThe scripting engine executes the embedded malicious code.\u003c/li\u003e\n\u003cli\u003eThe script downloads a PowerShell script from a remote server or contains an embedded, obfuscated PowerShell command.\u003c/li\u003e\n\u003cli\u003eThe script uses wscript.exe or cscript.exe to launch powershell.exe to execute the downloaded or embedded PowerShell script.\u003c/li\u003e\n\u003cli\u003ePowerShell executes, performing malicious actions such as downloading additional payloads, modifying system settings, or establishing persistence.\u003c/li\u003e\n\u003cli\u003ePowerShell attempts to connect to external command-and-control servers to receive further instructions.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the system and can proceed with lateral movement, data exfiltration, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to initial access, allowing attackers to deploy malware, steal sensitive information, or perform other malicious activities. The impact can range from data breaches and financial losses to reputational damage. The severity depends on the attacker\u0026rsquo;s objectives and the level of access they gain. The number of affected systems depends on the scope of the phishing campaign or other initial access methods used to deliver the malicious script.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon process creation logging to capture the necessary event data for the rules below.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate process execution chains where cscript.exe or wscript.exe spawn powershell.exe using the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eImplement email security measures to block phishing emails with script attachments.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from PowerShell processes for suspicious outbound traffic.\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-script-powershell-execution/","summary":"Detection of PowerShell processes launched by cscript.exe or wscript.exe, indicative of potential malicious initial access or execution attempts.","title":"Suspicious PowerShell Execution via Windows Script Host","url":"https://feed.craftedsignal.io/briefs/2024-01-script-powershell-execution/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2019-0708"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["command-and-control","lateral-movement","initial-access","rdp"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eRemote Desktop Protocol (RDP) is a common tool for system administrators to remotely manage systems, however, exposing RDP directly to the internet creates a significant attack surface. Threat actors frequently target and exploit RDP for initial access, lateral movement, and establishing backdoors within compromised networks. This activity is detected by monitoring network traffic for RDP connections originating from outside the internal network (RFC1918 IP ranges). This is important because successful RDP compromise often leads to broader network infiltration and data exfiltration. This detection focuses on the network level characteristics of RDP connections from the internet to internal assets.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a publicly accessible RDP service.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to brute-force RDP login credentials or exploits a known RDP vulnerability (e.g. BlueKeep CVE-2019-0708).\u003c/li\u003e\n\u003cli\u003eUpon successful authentication or exploitation, the attacker gains remote access to the targeted system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised system as a pivot point to perform reconnaissance on the internal network.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the network using stolen credentials or by exploiting other vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker installs malware or establishes persistence mechanisms (e.g., creating new user accounts or modifying system configurations).\u003c/li\u003e\n\u003cli\u003eThe attacker gathers sensitive data from internal systems.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the stolen data to an external server or deploys ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised RDP services can lead to significant data breaches, system downtime, and financial losses. Attackers can leverage RDP access to steal sensitive information, install ransomware, or disrupt critical business operations. While the number of affected organizations varies, RDP exploitation remains a prevalent attack vector, especially for organizations with inadequate security practices. The impact of a successful RDP attack ranges from several thousands to millions of dollars, depending on the size of the organization and the sensitivity of the compromised data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;RDP (Remote Desktop Protocol) from the Internet\u0026rdquo; Sigma rule to your SIEM to detect unauthorized RDP connections from outside the network.\u003c/li\u003e\n\u003cli\u003eReview firewall rules and network configurations to ensure RDP services are not exposed directly to the internet. Implement a VPN or RDP gateway for secure remote access.\u003c/li\u003e\n\u003cli\u003eEnable and monitor network traffic logs (category: \u003ccode\u003enetwork_traffic\u003c/code\u003e, product: \u003ccode\u003ewindows|linux|macos\u003c/code\u003e) to provide data for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the source IP address and user accounts involved in the RDP connection.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of a potential RDP compromise.\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-rdp-internet/","summary":"This rule detects network events indicative of RDP traffic originating from the internet, which poses a significant security risk due to its frequent exploitation as an initial access or backdoor vector.","title":"RDP (Remote Desktop Protocol) from the Internet","url":"https://feed.craftedsignal.io/briefs/2024-01-rdp-internet/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic License v2"],"_cs_severities":["high"],"_cs_tags":["network-traffic","initial-access","lateral-movement","rpc"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThe Remote Procedure Call (RPC) protocol, while essential for legitimate system administration tasks such as remote maintenance and resource sharing within internal networks, poses a significant security risk when exposed to the internet. Threat actors frequently target and exploit RPC services as an initial access vector or to establish backdoors within compromised systems. This exposure allows attackers to remotely execute commands, move laterally within the network, and potentially exfiltrate sensitive data. This brief provides detection strategies to identify such anomalous RPC traffic, enabling security teams to proactively mitigate potential threats. The detection focuses on identifying TCP traffic to port 135 from internal IP ranges to external IP addresses.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises a host within the internal network, potentially through phishing or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe compromised host initiates an RPC connection to an external IP address on TCP port 135.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the RPC connection to enumerate network resources and identify potential targets for lateral movement.\u003c/li\u003e\n\u003cli\u003eUsing the RPC connection, the attacker attempts to authenticate to other systems within the network.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the attacker remotely executes commands on the target system via RPC.\u003c/li\u003e\n\u003cli\u003eThe attacker installs malware or a backdoor on the target system for persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the established foothold to further propagate within the network, compromising additional systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of RPC services exposed to the internet can lead to a complete compromise of the internal network. Attackers can gain initial access, move laterally, exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations. A single exposed RPC service can serve as a gateway for widespread damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the provided Sigma rule to detect RPC traffic from internal IP ranges to external destinations on TCP port 135, focusing on network traffic logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, prioritizing systems exhibiting suspicious RPC activity (Sigma rule, logsource: network_connection).\u003c/li\u003e\n\u003cli\u003eEnsure that RPC services are not directly exposed to the internet. Implement firewall rules to restrict access to authorized internal IP ranges only.\u003c/li\u003e\n\u003cli\u003eContinuously monitor network traffic for anomalous RPC activity and correlate with other security events (logsource: network_connection).\u003c/li\u003e\n\u003cli\u003eReview and update firewall configurations to block unauthorized outbound connections on port 135 (logsource: firewall).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:27:00Z","date_published":"2024-01-03T14:27:00Z","id":"/briefs/2024-01-rpc-internet-access/","summary":"This brief focuses on detecting Remote Procedure Call (RPC) traffic originating from internal networks and reaching the public internet, which is indicative of potential initial access or backdoor activity.","title":"Detecting RPC Traffic to the Internet","url":"https://feed.craftedsignal.io/briefs/2024-01-rpc-internet-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office","Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel","LogiOptions","Sidekick.vsto"],"_cs_severities":["medium"],"_cs_tags":["office-addins","phishing","initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Logitech","Elastic","SentinelOne"],"content_html":"\u003cp\u003eAttackers are increasingly leveraging malicious Microsoft Office Add-Ins to gain initial access and persistence on victim systems. These add-ins, often delivered through phishing campaigns, contain embedded malicious code. This detection identifies unusual execution patterns, such as Office applications (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE, VSTOInstaller.exe) launching add-ins (wll, xll, ppa, ppam, xla, xlam, vsto) from suspicious paths like Temp or Downloads directories, or with atypical parent processes (explorer.exe, OpenWith.exe, cmd.exe, powershell.exe). The detection logic filters out known benign activities to minimize false positives, focusing on anomalies indicative of malicious intent, such as installations of Logitech software. This activity matters because successful exploitation can lead to arbitrary code execution, data theft, and further compromise of the victim\u0026rsquo;s network.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user receives a phishing email containing a malicious Microsoft Office document.\u003c/li\u003e\n\u003cli\u003eThe user opens the document, which prompts them to enable macros or install an add-in.\u003c/li\u003e\n\u003cli\u003eThe malicious add-in (wll, xll, ppa, ppam, xla, xlam, vsto) is downloaded from a remote server or dropped into a suspicious directory, such as %TEMP% or %APPDATA%.\u003c/li\u003e\n\u003cli\u003eThe user executes an Office application (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE), which loads the malicious add-in.\u003c/li\u003e\n\u003cli\u003eThe malicious add-in executes arbitrary code, potentially downloading and executing a second-stage payload.\u003c/li\u003e\n\u003cli\u003eThe add-in may establish persistence by modifying registry keys or creating scheduled tasks.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the system and can perform reconnaissance, lateral movement, and data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, which could include data theft, ransomware deployment, or intellectual property theft.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete system compromise, data theft, and potential ransomware deployment. Organizations across all sectors are at risk, particularly those with a high volume of email traffic. The use of malicious Office Add-Ins provides attackers with a persistent foothold within the victim\u0026rsquo;s environment, allowing for long-term data collection and disruption of business operations. This can lead to significant financial losses, reputational damage, and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eOffice Add-In Loaded From Suspicious Path\u003c/code\u003e to detect add-ins loaded from temporary or download directories based on \u003ccode\u003eprocess.args\u003c/code\u003e and \u003ccode\u003eprocess.name\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eOffice Add-In Loaded By Suspicious Parent\u003c/code\u003e to detect add-ins loaded by \u003ccode\u003ecmd.exe\u003c/code\u003e or \u003ccode\u003epowershell.exe\u003c/code\u003e based on \u003ccode\u003eprocess.parent.name\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003eVSTOInstaller.exe\u003c/code\u003e executing with the \u003ccode\u003e/Uninstall\u003c/code\u003e argument, as this may indicate suspicious activity, correlating with the exclusion rule in the provided query.\u003c/li\u003e\n\u003cli\u003eMonitor for Office applications launching add-ins with parent processes of \u003ccode\u003eexplorer.exe\u003c/code\u003e or \u003ccode\u003eOpenWith.exe\u003c/code\u003e using process creation logs and the provided query logic.\u003c/li\u003e\n\u003cli\u003eImplement stricter email filtering to prevent phishing emails containing malicious Office documents from reaching end-users.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:00:00Z","date_published":"2024-01-03T14:00:00Z","id":"/briefs/2024-01-office-addins/","summary":"This rule detects suspicious execution of Microsoft Office applications launching Office Add-Ins from unusual paths or with atypical parent processes, potentially indicating an attempt to gain initial access via a malicious phishing campaign.","title":"Suspicious Execution via Microsoft Office Add-Ins","url":"https://feed.craftedsignal.io/briefs/2024-01-office-addins/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-41940"}],"_cs_exploited":false,"_cs_products":["cPanel \u0026 WHM","WP2 (WordPress Squared)"],"_cs_severities":["critical"],"_cs_tags":["cpanel","whm","wp2","wordpress","authentication-bypass","cve-2026-41940","initial-access"],"_cs_type":"advisory","_cs_vendors":["WebPros"],"content_html":"\u003cp\u003eWebPros cPanel \u0026amp; WHM (WebHost Manager) and WP2 (WordPress Squared) are affected by an authentication bypass vulnerability, identified as CVE-2026-41940. This flaw exists within the login flow, potentially granting unauthenticated remote attackers unauthorized access to the control panel. Successful exploitation allows attackers to bypass normal authentication mechanisms and directly access sensitive administrative functions within cPanel \u0026amp; WHM and WP2. Defenders should apply vendor-provided mitigations or discontinue use of the product if mitigations are not available. The vulnerability was disclosed in April 2026, and mitigations should be applied by May 3, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a vulnerable cPanel \u0026amp; WHM or WP2 instance.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request exploiting the authentication bypass vulnerability in the login flow.\u003c/li\u003e\n\u003cli\u003eThe request is sent to the target server, bypassing authentication checks.\u003c/li\u003e\n\u003cli\u003eThe server incorrectly processes the request, granting the attacker an authenticated session.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the authenticated session to access administrative interfaces and settings.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies server configurations, potentially creating new administrative accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker installs malicious plugins or software through the control panel.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves full control over the web server and hosted websites.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-41940 can lead to complete compromise of the affected cPanel \u0026amp; WHM or WP2 server. This can result in data breaches, website defacement, malware distribution, and denial-of-service attacks. The impact is significant due to the widespread use of cPanel \u0026amp; WHM in web hosting environments. Compromised servers could be leveraged for further attacks against other systems and networks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply mitigations provided by WebPros as detailed in their security update advisory to address CVE-2026-41940.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect cPanel/WHM Authentication Bypass Attempt\u0026rdquo; to identify potential exploitation attempts in web server logs.\u003c/li\u003e\n\u003cli\u003eIf mitigations cannot be immediately applied, follow BOD 22-01 guidance for cloud services, potentially isolating the affected system until patched.\u003c/li\u003e\n\u003cli\u003eConsider discontinuing use of the affected product if patches or mitigations are unavailable, as advised in the original CISA KEV entry.\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-cpanel-auth-bypass/","summary":"CVE-2026-41940 is an authentication bypass vulnerability in WebPros cPanel \u0026 WHM and WP2 (WordPress Squared) that allows unauthenticated remote attackers to gain unauthorized access to the control panel.","title":"WebPros cPanel \u0026 WHM and WP2 Authentication Bypass Vulnerability (CVE-2026-41940)","url":"https://feed.craftedsignal.io/briefs/2024-01-cpanel-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","pim","privileged-identity-management","role-based-access-control","initial-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies a condition where users have been assigned privileged roles within Azure\u0026rsquo;s Privileged Identity Management (PIM) but are not actively utilizing those roles. This situation can arise from various factors, including misconfiguration of PIM settings, over-allocation of privileged roles due to process gaps or lack of oversight, or the presence of dormant accounts with elevated privileges. Such unused roles represent a potential security risk, as they can be exploited by malicious actors or misused inadvertently, especially if MFA or conditional access policies are not enforced. Regularly auditing and addressing unused PIM roles is crucial for maintaining a strong security posture and optimizing license utilization.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn administrator assigns a privileged role to a user within Azure PIM.\u003c/li\u003e\n\u003cli\u003eThe user is granted the role but does not activate or use it to perform any privileged actions.\u003c/li\u003e\n\u003cli\u003eAzure PIM monitors role usage and detects the lack of activity for the assigned role.\u003c/li\u003e\n\u003cli\u003eThe \u0026ldquo;redundantAssignmentAlertIncident\u0026rdquo; event is triggered within the Azure PIM logs.\u003c/li\u003e\n\u003cli\u003eAn attacker gains access to the user\u0026rsquo;s account through credential compromise or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker activates the unused privileged role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the now-active privileged role to perform unauthorized actions, such as modifying system configurations, accessing sensitive data, or escalating privileges further.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or system compromise, without being detected due to the pre-existing role assignment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe presence of unused privileged roles can lead to significant security breaches and compliance violations. An attacker exploiting an unused role can gain immediate access to sensitive resources and perform unauthorized actions, potentially leading to data breaches, system outages, or financial losses. The number of affected users and resources depends on the scope of the unused role and the attacker\u0026rsquo;s objectives. Failure to identify and address these unused roles can also result in unnecessary license costs and increased attack surface.\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 \u003ccode\u003eredundantAssignmentAlertIncident\u003c/code\u003e events indicating unused PIM roles in Azure (see \u0026ldquo;Roles Are Not Being Used\u0026rdquo; rule).\u003c/li\u003e\n\u003cli\u003eInvestigate all detected instances of unused PIM roles to determine the reason for inactivity and potential risks.\u003c/li\u003e\n\u003cli\u003eRevoke the assigned role if the user no longer requires it, or provide training and guidance to ensure proper role utilization.\u003c/li\u003e\n\u003cli\u003eReview and refine PIM role assignment policies to minimize the allocation of unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eImplement regular audits of PIM role assignments to identify and address unused roles promptly.\u003c/li\u003e\n\u003cli\u003eConfigure security alerts within Azure PIM to receive notifications about unused roles and other potential security incidents.\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-pim-role-not-used/","summary":"Detection of assigned but unused privileged roles in Azure's Privileged Identity Management (PIM) service, indicating potential misconfiguration, license overuse, or dormant privileged access that could be exploited.","title":"Unused Privileged Identity Management (PIM) Roles in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-role-not-used/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","initial-access","persistence","stealth","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert detects instances where a user attempts to invite an external guest user to an Azure environment but fails due to insufficient permissions. This activity can signify several potential security risks, including unauthorized privilege escalation attempts by internal users or malicious insiders attempting to expand access without proper authorization. While legitimate failed attempts may occur, repeated or targeted failures should be investigated. The activity is logged within the Azure Audit Logs. Detecting this activity is crucial for maintaining control over user access and preventing potential data breaches. The relevant log data resides within Azure\u0026rsquo;s audit logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.\u003c/li\u003e\n\u003cli\u003eThe Azure Active Directory service checks the inviter\u0026rsquo;s permissions against the organization\u0026rsquo;s guest invitation policies.\u003c/li\u003e\n\u003cli\u003eThe system determines the user lacks the necessary permissions to invite guest users.\u003c/li\u003e\n\u003cli\u003eAzure Audit Logs record the \u0026ldquo;Invite external user\u0026rdquo; event with a \u0026ldquo;failure\u0026rdquo; status.\u003c/li\u003e\n\u003cli\u003eThe failed invitation attempt is blocked, preventing the external user from gaining access.\u003c/li\u003e\n\u003cli\u003eThe attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.\u003c/li\u003e\n\u003cli\u003eIf successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation could grant unauthorized access to sensitive data and resources within the Azure environment. While this specific detection focuses on failed attempts, repeated failures may indicate a concerted effort to bypass security controls. If successful, unauthorized guest users could be used for lateral movement, data exfiltration, or other malicious activities. The number of affected resources depends on the permissions granted to the guest user if the invitation had been successful.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Guest User Invited By Non Approved Inviters\u0026rdquo; to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.\u003c/li\u003e\n\u003cli\u003eMonitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).\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-guest-invite-failure/","summary":"Detection of a failed attempt to invite an external guest user by an Azure user lacking the necessary permissions, potentially indicating privilege escalation or malicious insider activity.","title":"Unauthorized Guest User Invitation Attempt in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-guest-invite-failure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office","Microsoft Word","Microsoft Excel","Microsoft PowerPoint","Outlook"],"_cs_severities":["medium"],"_cs_tags":["initial-access","defense-evasion","execution","discovery","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies suspicious child processes spawned by Microsoft Office applications (Word, PowerPoint, Excel, Outlook), which are commonly targeted for initial access via malicious documents or macro exploitation. The rule focuses on identifying anomalous process executions originating from these applications, a tactic often employed to execute arbitrary code or download additional payloads. Attackers leverage Office applications due to their widespread use and inherent scripting capabilities. Successful exploitation can lead to arbitrary code execution, lateral movement, and data exfiltration. This detection helps defenders identify and respond to potential security breaches originating from Microsoft Office applications, reducing the attack surface and minimizing potential damage. The rule specifically looks for processes like \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003emshta.exe\u003c/code\u003e, \u003ccode\u003ewscript.exe\u003c/code\u003e, and others being spawned by Office applications.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user receives a malicious Microsoft Office document (e.g., Word, Excel) via email or downloads it from a compromised website.\u003c/li\u003e\n\u003cli\u003eThe user opens the document, triggering the execution of a malicious macro or exploitation of a vulnerability within the Office application.\u003c/li\u003e\n\u003cli\u003eThe Office application (e.g., \u003ccode\u003ewinword.exe\u003c/code\u003e, \u003ccode\u003eexcel.exe\u003c/code\u003e) spawns a suspicious child process such as \u003ccode\u003ecmd.exe\u003c/code\u003e or \u003ccode\u003epowershell.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe spawned process executes a command to download a malicious payload from a remote server using \u003ccode\u003ebitsadmin.exe\u003c/code\u003e or \u003ccode\u003ecertutil.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe downloaded payload is a reverse shell or a malware dropper, which establishes a connection to an attacker-controlled server.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the compromised system and attempts to escalate privileges and perform reconnaissance.\u003c/li\u003e\n\u003cli\u003eThe attacker uses discovery commands with \u003ccode\u003enet.exe\u003c/code\u003e, \u003ccode\u003eipconfig.exe\u003c/code\u003e, \u003ccode\u003etasklist.exe\u003c/code\u003e, and \u003ccode\u003ewhoami.exe\u003c/code\u003e to map the environment and identify valuable targets.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally to other systems within the network, aiming to compromise critical assets and achieve their objectives, such as data theft or ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to arbitrary code execution, allowing attackers to gain initial access to the compromised system. This can result in data theft, installation of malware, lateral movement to other systems, and ultimately, significant disruption to business operations. The widespread use of Microsoft Office makes it a prime target, potentially affecting a large number of users and organizations. Failure to detect and respond to these attacks can result in significant financial losses, reputational damage, and compromise of sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging (Sysmon Event ID 1 or Windows Security Event Logs) to ensure the visibility required to detect suspicious child processes.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious MS Office Child Process\u003c/code\u003e to your SIEM and tune the rule based on your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eSuspicious MS Office Child Process\u003c/code\u003e Sigma rule by examining the parent process tree and associated network connections.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unauthorized processes from Microsoft Office applications.\u003c/li\u003e\n\u003cli\u003eRegularly update Microsoft Office applications to patch known vulnerabilities.\u003c/li\u003e\n\u003cli\u003eBlock known malicious domains or IPs associated with malware delivery and command and control, based on threat intelligence feeds and IOCs from external sources.\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-suspicious-office-child-process/","summary":"Detects suspicious child processes of Microsoft Office applications, indicating potential exploitation or malicious macros for initial access, defense evasion, and execution.","title":"Suspicious MS Office Child Process","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-office-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["medium"],"_cs_tags":["html-smuggling","phishing","initial-access","windows","evasion"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies a suspicious sequence of events indicative of HTML smuggling, where adversaries embed malicious payloads within seemingly benign HTML files to bypass security filters. The rule focuses on Windows systems and monitors for the creation of HTML files exhibiting characteristics such as high entropy (\u0026gt;=5) and large size (\u0026gt;=150,000 bytes) or very large size (\u0026gt;=1,000,000 bytes) within common download and temporary directories (e.g., Downloads, Content.Outlook, AppData\\Local\\Temp). Subsequently, it tracks the execution of browser processes (e.g., chrome.exe, firefox.exe, iexplore.exe) opening these HTML files with specific command-line arguments (e.g., \u0026ndash;single-argument, -url). The detection aims to uncover initial access attempts, defense evasion, and user execution of malicious files delivered through HTML smuggling techniques.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user receives a phishing email containing a malicious HTML attachment.\u003c/li\u003e\n\u003cli\u003eThe user opens the attachment, triggering the download of a large HTML file to the Downloads folder.\u003c/li\u003e\n\u003cli\u003eThe HTML file contains obfuscated JavaScript code that, when executed, reconstructs a malicious payload (e.g., a Cobalt Strike beacon).\u003c/li\u003e\n\u003cli\u003eThe file is saved with an .htm or .html extension in a temporary or download directory.\u003c/li\u003e\n\u003cli\u003eA browser process (chrome.exe, firefox.exe, etc.) is initiated to open the HTML file, often with specific arguments like \u0026ldquo;\u0026ndash;single-argument\u0026rdquo; or \u0026ldquo;-url\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe browser renders the HTML, executing the embedded JavaScript.\u003c/li\u003e\n\u003cli\u003eThe JavaScript deobfuscates and executes the smuggled payload, initiating a reverse shell connection to a command-and-control server.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the compromised system and can proceed with lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation via HTML smuggling can lead to initial access to a targeted system, potentially enabling attackers to perform lateral movement, data exfiltration, or ransomware deployment. While the specific number of victims and targeted sectors are not explicitly stated in the source, the technique is broadly applicable and can affect any Windows user who interacts with malicious HTML attachments or downloads from untrusted sources. The consequences of successful exploitation range from data breaches and financial losses to reputational damage and operational disruption.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM and tune the file path and browser process filters for your environment.\u003c/li\u003e\n\u003cli\u003eEnable file integrity monitoring (FIM) on common download and temporary directories to detect the creation of suspicious HTML files as described in the Sigma rules.\u003c/li\u003e\n\u003cli\u003eImplement network egress filtering to block connections to known malicious command-and-control servers and domains to prevent payload execution.\u003c/li\u003e\n\u003cli\u003eEducate users about the risks of opening attachments from untrusted sources and train them to recognize phishing emails as outlined in the Overview.\u003c/li\u003e\n\u003cli\u003eUtilize endpoint detection and response (EDR) solutions to monitor process execution and network connections for anomalous behavior associated with HTML smuggling.\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-suspicious-html-creation/","summary":"This detection identifies the creation of HTML files with high entropy and large size, followed by execution via a browser process, indicating potential HTML smuggling and malicious payload delivery on Windows systems.","title":"Suspicious HTML File Creation Leading to Potential Payload Delivery","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-html-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["VS Code"],"_cs_severities":["medium"],"_cs_tags":["initial-access","execution","supply-chain-compromise","vscode"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eA malicious VS Code extension, configured to run upon editor startup, can execute arbitrary commands, potentially leading to the installation of remote access trojans (RATs) or other malicious payloads. The attack vector leverages the extension host under \u003ccode\u003e.vscode/extensions/\u003c/code\u003e to spawn processes such as script interpreters or download utilities. This activity has been observed in campaigns like the fake Clawdbot extension that installed ScreenConnect RAT. The execution can involve Living-off-the-Land binaries (LOLBins) or recently created executables from non-standard paths, posing a significant risk to Windows systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user installs a malicious VS Code extension.\u003c/li\u003e\n\u003cli\u003eThe extension is configured with \u003ccode\u003eactivationEvents: [\u0026quot;onStartupFinished\u0026quot;]\u003c/code\u003e to run automatically when VS Code starts.\u003c/li\u003e\n\u003cli\u003eThe VS Code extension host (\u003ccode\u003eCode.exe\u003c/code\u003e or \u003ccode\u003enode.exe\u003c/code\u003e) spawns a script interpreter (e.g., \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003ecmd.exe\u003c/code\u003e) from within the \u003ccode\u003e.vscode/extensions/\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eThe script interpreter executes a command to download a malicious payload from a remote server using tools like \u003ccode\u003ecurl.exe\u003c/code\u003e, \u003ccode\u003ebitsadmin.exe\u003c/code\u003e, or \u003ccode\u003emshta.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe downloaded payload is saved to disk, often in a temporary directory outside of Program Files.\u003c/li\u003e\n\u003cli\u003eThe script interpreter executes the downloaded payload, leading to further malicious activity. For example, ScreenConnect might be installed.\u003c/li\u003e\n\u003cli\u003ePersistence mechanisms are established (e.g., via registry keys or scheduled tasks).\u003c/li\u003e\n\u003cli\u003eThe attacker gains remote access to the compromised system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to the complete compromise of a developer\u0026rsquo;s workstation, potentially affecting intellectual property and sensitive data. The installation of RATs like ScreenConnect can enable persistent remote access, allowing attackers to perform data exfiltration, lateral movement, and further malicious activities. The compromised machine can then be used as a pivot point to attack other systems within the organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Suspicious Execution from VS Code Extension\u0026rdquo; Sigma rule to your SIEM to detect malicious process execution from VS Code extensions.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for script interpreters and LOLBins spawned from the \u003ccode\u003e.vscode/extensions/\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unsigned or untrusted executables.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit installed VS Code extensions for suspicious activity or unnecessary permissions.\u003c/li\u003e\n\u003cli\u003eEducate developers about the risks of installing extensions from untrusted sources.\u003c/li\u003e\n\u003cli\u003eBlock the C2 domains associated with ScreenConnect and other RATs at the firewall/DNS resolver.\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-vscode-extension-execution/","summary":"Malicious VS Code extensions can execute arbitrary commands, leading to initial access and subsequent payload deployment on Windows systems.","title":"Suspicious Execution from VS Code Extension","url":"https://feed.craftedsignal.io/briefs/2024-01-vscode-extension-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend"],"_cs_severities":["low"],"_cs_tags":["initial-access","removable-media","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies potential initial access attempts where adversaries use removable media, such as USB drives, to introduce malware into systems, potentially those on disconnected or air-gapped networks. The attack relies on copying malware to the removable media and taking advantage of Autorun or user execution to initiate the malicious process. The rule focuses on identifying suspicious process executions from USB devices lacking valid code signatures, followed by network connection attempts, indicating a potential attempt to establish command and control or exfiltrate data. This activity is significant as it can bypass traditional network security measures and establish a foothold within an organization\u0026rsquo;s environment. The detection logic is based on Elastic Defend telemetry.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker copies malware onto a USB drive from an infected system.\u003c/li\u003e\n\u003cli\u003eThe attacker physically inserts the USB drive into a target Windows system.\u003c/li\u003e\n\u003cli\u003eThe user, either unknowingly or through social engineering, executes the malicious binary from the USB drive. This could be achieved through Autorun features (if enabled) or by manually clicking on an executable file.\u003c/li\u003e\n\u003cli\u003eThe executed process, now running on the target system, lacks a valid code signature, raising suspicion.\u003c/li\u003e\n\u003cli\u003eThe malicious process attempts to establish a network connection, potentially to a command and control server or to exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe network connection attempt is logged, capturing details about the destination IP address and port.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access to the system and can potentially perform reconnaissance, privilege escalation, or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to unauthorized access to sensitive data, system compromise, and potential lateral movement within the network. Although the risk score is low, such attacks on air-gapped systems are high impact. The number of victims is unknown; however, organizations across all sectors are vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation and network connection logging to detect this type of activity (logs-endpoint.events.process-* and logs-endpoint.events.network-*).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Execution from a Removable Media with Network Connection\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eDisable Autorun features on all systems to prevent automatic execution of programs from removable media.\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-removable-media-execution/","summary":"Detects process execution from removable media by an unusual process with untrusted code signature followed by network connection attempts, potentially indicating malware introduced via removable media for initial access.","title":"Execution from Removable Media with Network Connection","url":"https://feed.craftedsignal.io/briefs/2024-01-removable-media-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","privileged-account","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of new privileged account creation within Azure environments. Attackers often create new admin accounts to establish persistence, escalate privileges, or move laterally within a compromised environment. Monitoring for such activity is crucial, especially given that compromised accounts are a common entry point for various attacks. This activity, if malicious, can lead to significant data breaches, service disruptions, and reputational damage. This detection focuses on identifying \u0026ldquo;Add user\u0026rdquo; and \u0026ldquo;Add member to role\u0026rdquo; events within Azure audit logs.\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 environment, possibly through compromised credentials (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages their access to enumerate existing accounts and roles within the Azure Active Directory.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new user account with elevated privileges, such as Global Administrator or other custom administrative roles.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the newly created user account to one or more privileged roles, granting it administrative access to the Azure environment. This action is logged as \u0026ldquo;Add member to role\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created privileged account to perform reconnaissance, identify sensitive data, or deploy malicious applications.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining access through the newly created account, even if the initial entry point is detected and remediated.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain control over critical resources and services within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the privileged account to exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful creation of a privileged account can provide an attacker with persistent access and the ability to escalate privileges, leading to widespread damage. The attacker can gain control over critical resources, exfiltrate sensitive data, deploy ransomware, or disrupt business operations. This can lead to significant financial losses, reputational damage, and legal liabilities. While the scope and number of victims are unknown, all organizations using Azure Active Directory are potentially at risk.\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 privileged account creation events within Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of privileged account creation to determine whether the activity is legitimate.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with privileged roles, to mitigate the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit user account privileges to identify and remove unnecessary or excessive permissions.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for suspicious activities, such as unusual sign-in attempts, changes to security settings, and modifications to privileged roles.\u003c/li\u003e\n\u003cli\u003eImplement alerting for changes to privileged roles and groups within Azure AD.\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-privileged-account-creation/","summary":"Detects the creation of new privileged accounts in Azure environments, potentially indicating initial access, persistence, privilege escalation, or stealth activities by malicious actors.","title":"Detection of Privileged Account Creation in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-privileged-account-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","privilege-escalation","persistence","initial-access","stealth"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat involves the elevation of user permissions within an Azure environment to manage all Azure subscriptions. While legitimate administrators may perform this action, unauthorized elevation of permissions can grant an attacker significant control over the entire Azure environment. This could be an insider threat or a compromised account being used to broaden access. The activity is logged within Azure Activity Logs, providing an opportunity for detection. Defenders should be aware of this potential escalation path and monitor for unexpected or unauthorized permission changes.\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, potentially through compromised credentials (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure CLI/PowerShell with the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to elevate their permissions using the \u003ccode\u003eMICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION\u003c/code\u003e operation.\u003c/li\u003e\n\u003cli\u003eAzure Activity Logs record the attempt to elevate permissions.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains management access to all Azure subscriptions within the tenant.\u003c/li\u003e\n\u003cli\u003eThe attacker can then provision resources, modify configurations, and access data within those subscriptions.\u003c/li\u003e\n\u003cli\u003eThe attacker might establish persistence by creating new user accounts with elevated privileges or modifying existing roles.\u003c/li\u003e\n\u003cli\u003eThe attacker can then exfiltrate sensitive data or disrupt services within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful elevation of permissions to manage all Azure subscriptions allows an attacker to control all resources, data, and configurations within the Azure environment. This can lead to data breaches, service disruptions, financial loss, and reputational damage. The scope of impact depends on the sensitivity of the data stored within Azure and the criticality of the services hosted there.\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 unauthorized \u003ccode\u003eMICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION\u003c/code\u003e operations in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u003ccode\u003eMICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION\u003c/code\u003e immediately, as outlined in the rule description.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for Azure role assignments.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for other suspicious activities, such as unusual resource creation or modification.\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-subscription-elevation/","summary":"An attacker elevates their Azure subscription permissions to manage all subscriptions, potentially leading to unauthorized access and control over the environment.","title":"Azure Subscription Permission Elevation via Activity Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-subscription-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EKS","STS"],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","iam","kubernetes","initial-access","web-identity"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies instances of successful AWS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the service account token from the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated token to call the AWS STS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e call is made from a network with an ASN organization name that is not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e event, including details about the user, source IP, and ASN organization.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM role is used to perform unauthorized actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThese actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by following the investigation steps in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eExpand the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions in the Sigma rule for known and trusted egress paths if needed.\u003c/li\u003e\n\u003cli\u003eEnable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls.\u003c/li\u003e\n\u003cli\u003eRegularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.\u003c/li\u003e\n\u003cli\u003eRevoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.\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-03-aws-assume-role-external-asn/","summary":"Detects successful AWS `AssumeRoleWithWebIdentity` calls where the caller identity is a Kubernetes service account and the source autonomous system organization is not `Amazon.com, Inc.`, which may indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.","title":"AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-assume-role-external-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","persistence","initial-access","stealth","account-manipulation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe creation and immediate deletion of user accounts within Azure Active Directory can be indicative of various malicious activities. Attackers may create accounts to escalate privileges, establish persistence, or gain initial access to a system. The short lifespan of these accounts suggests an attempt to evade detection. This behavior is particularly concerning as it can be used to perform actions and then quickly remove the evidence of the account\u0026rsquo;s existence from standard audit logs. Monitoring for this activity helps defenders identify and respond to potential security breaches within their Azure environment. This technique is relevant for any organization utilizing Azure Active Directory for user management.\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 AD environment, potentially through compromised credentials or a phishing attack.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new user account within the Azure AD. This can be achieved through the Azure portal, PowerShell, or the Azure CLI.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns elevated privileges to the newly created account. This might involve adding the account to privileged roles such as Global Administrator or assigning specific permissions to access sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created account to perform malicious activities, such as accessing confidential data, modifying system configurations, or deploying malicious applications.\u003c/li\u003e\n\u003cli\u003eAfter completing the malicious tasks, the attacker removes the elevated privileges from the account to reduce the chances of detection during privilege reviews.\u003c/li\u003e\n\u003cli\u003eThe attacker deletes the created account from Azure AD. This step is performed to remove the traces of the account\u0026rsquo;s existence and hinder forensic investigations.\u003c/li\u003e\n\u003cli\u003eThe actions performed by the short-lived account may leave other traces in logs, such as access logs or activity logs related to the resources the account interacted with.\u003c/li\u003e\n\u003cli\u003eThe attacker aims to maintain stealth and evade detection while gaining unauthorized access to resources or establishing persistence within the Azure AD environment.\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 resources, data breaches, and system compromise. The creation and deletion of short-lived accounts can mask malicious activities, making it difficult to trace the attacker\u0026rsquo;s actions. Organizations using Azure AD could experience data exfiltration, financial loss, and reputational damage. Detecting such activity early is critical to preventing further damage and mitigating the impact of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Account Created And Deleted Within A Close Time Frame\u0026rdquo; to your SIEM and tune for your environment to detect suspicious account creation/deletion events in Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u0026ldquo;Account Created And Deleted Within A Close Time Frame\u0026rdquo; to determine the scope and impact of the potential compromise.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with elevated privileges, to reduce the risk of credential compromise (reference: attack.initial-access).\u003c/li\u003e\n\u003cli\u003eRegularly review Azure AD audit logs for unusual account activity, focusing on accounts created and deleted within a short timeframe (logsource: azure, service: auditlogs).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T15:30:00Z","date_published":"2024-01-02T15:30:00Z","id":"/briefs/2024-01-azure-short-lived-account/","summary":"Detection of Azure Active Directory accounts that are created and deleted within a short timeframe, potentially indicating malicious activity such as privilege escalation or persistence attempts.","title":"Azure AD Account Created and Deleted Within a Close Time Frame","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-short-lived-account/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["cloud","aws","privilege-escalation","initial-access","persistence","stealth"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe use of the AWS root account should be strictly limited to specific tasks that cannot be performed with IAM users or roles. This alert indicates that the root account was used, which could signify various security concerns. An attacker with access to the root account can perform any action within the AWS environment, including creating new users, modifying security policies, accessing sensitive data, and deleting resources. Defenders should investigate each instance of root account usage to determine legitimacy. This activity may also indicate a misconfiguration where IAM roles should be used.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to the AWS root account credentials through credential theft or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates AWS resources to identify potential targets for privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies IAM policies to grant themselves additional permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker may create new IAM users or roles with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker could disable logging features to cover tracks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of the AWS root account can lead to a complete breach of the AWS environment, resulting in unauthorized access to sensitive data, data loss, service disruption, and potential financial losses. Attackers can leverage root privileges to perform nearly any action within the AWS account, affecting all services and resources. The number of affected victims depends on the scope and criticality of the AWS environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Root Credentials\u0026rdquo; to your SIEM to detect root account usage based on CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate all instances of root account usage identified by the \u0026ldquo;AWS Root Credentials\u0026rdquo; Sigma rule to determine legitimacy.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html\"\u003eAWS documentation\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.\u003c/li\u003e\n\u003cli\u003eRegularly audit IAM policies and user permissions to identify and remove unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eDisable or restrict root account access wherever possible, delegating tasks to IAM users/roles.\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-02-aws-root-usage/","summary":"The AWS root account, which grants unrestricted access to all resources within an AWS account, was used, potentially indicating unauthorized activity, privilege escalation, or a breach of security best practices.","title":"AWS Root Account Usage Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-02-aws-root-usage/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["initial-access","exfiltration","network"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThe provided Elastic rule identifies instances of Server Message Block (SMB), also known as Windows File Sharing, being transmitted to external IP addresses. SMB is intended for internal network communication for file, printer, and resource sharing. Exposing SMB to the internet presents a significant security risk. Threat actors frequently target and exploit SMB for initial access, deploying backdoors, or exfiltrating sensitive data. This activity warrants immediate investigation as it violates best practices and poses a direct threat to network security. The rule focuses on traffic on TCP ports 139 and 445, originating from internal IP ranges and destined for external IPs, excluding known safe IP ranges, as defined by IANA. The rule was last updated April 24, 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn internal host is compromised, often through phishing or other social engineering techniques.\u003c/li\u003e\n\u003cli\u003eThe compromised host attempts to establish an SMB connection to an external IP address on TCP ports 139 or 445.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the SMB protocol to attempt authentication, potentially exploiting vulnerabilities like credential stuffing or known SMB exploits.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication or exploitation, the attacker gains unauthorized access to shared resources or system services on the external system.\u003c/li\u003e\n\u003cli\u003eThe attacker may upload malicious payloads, such as malware or backdoors, via the SMB connection to the external host.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the SMB protocol to exfiltrate sensitive data from the internal network to the external system.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence on the compromised internal host, using SMB for command and control or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising SMB services can lead to significant data breaches, system compromise, and potential ransomware deployment. Exposed SMB services allow attackers to gain unauthorized access to sensitive files, critical infrastructure, and internal network resources. Successful exploitation can result in complete system takeover, data exfiltration, and disruption of business operations. While the exact number of victims is unknown, the prevalence of SMB vulnerabilities and misconfigurations suggests a widespread risk across various sectors.\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 SMB traffic to the internet and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445, as identified by the rule description.\u003c/li\u003e\n\u003cli\u003eInvestigate the source IP addresses triggering the rule, identifying internal systems initiating SMB traffic and determining if they belong to known devices or users within the organization, as described in the provided investigation guide.\u003c/li\u003e\n\u003cli\u003eRegularly audit network configurations and update the rule exceptions to include any legitimate device IPs to prevent false positives, as mentioned in the investigation guide.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:12:00Z","date_published":"2024-01-02T14:12:00Z","id":"/briefs/2024-01-smb-to-internet/","summary":"This rule detects network events indicating the use of Windows file sharing (SMB or CIFS) traffic to the Internet, which is commonly exploited for initial access, backdoor deployment, or data exfiltration.","title":"SMB (Windows File Sharing) Activity to the Internet","url":"https://feed.craftedsignal.io/briefs/2024-01-smb-to-internet/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["low"],"_cs_tags":["initial-access","exfiltration","windows","registry","usb"],"_cs_type":"advisory","_cs_vendors":["Microsoft","SentinelOne","Elastic"],"content_html":"\u003cp\u003eThis detection identifies the first-time appearance of removable devices on a Windows system by monitoring registry modifications. While not inherently malicious, the activity can indicate potential data exfiltration over removable media or initial access attempts using malware delivered via USB. The rule specifically looks for registry events with the \u0026ldquo;FriendlyName\u0026rdquo; value associated with USB storage devices (\u0026ldquo;USBSTOR\u0026rdquo;). This helps in identifying potentially unauthorized devices connected to the system. The detection 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\u003eA user connects a removable device (e.g., USB drive) to a Windows system.\u003c/li\u003e\n\u003cli\u003eThe operating system detects the new device and attempts to enumerate its properties.\u003c/li\u003e\n\u003cli\u003eThe system queries the registry for device-specific settings, including the \u0026ldquo;FriendlyName,\u0026rdquo; under the \u003ccode\u003eHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USBSTOR\u003c/code\u003e key.\u003c/li\u003e\n\u003cli\u003eIf the device is new to the system, the registry is modified to record the device\u0026rsquo;s information, including its friendly name.\u003c/li\u003e\n\u003cli\u003eThe event generates a registry modification event, which is logged by Sysmon, Elastic Defend, Microsoft Defender XDR, or SentinelOne.\u003c/li\u003e\n\u003cli\u003eAn attacker may use the USB device to deploy malware or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker copies files to the USB device.\u003c/li\u003e\n\u003cli\u003eThe attacker removes the USB device, completing the exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and data exfiltration via USB can lead to the loss of sensitive information, intellectual property theft, or the introduction of malware into the network. Although this alert is low severity, multiple alerts across the environment may indicate an active campaign. The detection focuses on registry modifications, which are early indicators of device connection, allowing for proactive monitoring and response.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Sysmon registry event logging to detect registry modifications related to USB devices and activate the Sigma rules below.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided to your SIEM to detect and monitor first-time seen USB devices.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, correlating with user activity and file access events.\u003c/li\u003e\n\u003cli\u003eMaintain a list of approved USB devices and create exceptions for them in the monitoring system to reduce false positives as described in the rule documentation.\u003c/li\u003e\n\u003cli\u003eMonitor for subsequent file access or transfer events involving the new device as described in the rule documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T14:00:00Z","date_published":"2024-01-02T14:00:00Z","id":"/briefs/2024-01-first-time-usb/","summary":"Detection of newly seen removable devices via Windows registry modification events can indicate data exfiltration attempts or initial access via malicious USB drives.","title":"First Time Seen Removable Device Registry Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-first-time-usb/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["azure"],"_cs_severities":["medium"],"_cs_tags":["azuread","guest-user","privilege-escalation","persistence","initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert focuses on detecting the invitation of guest users to an Azure Active Directory (AD) tenant by accounts that are not pre-approved to perform this action. Unauthorized guest user invitations can be an indicator of various malicious activities. An attacker could be attempting to escalate privileges by adding an account they control, establish persistence by creating a backdoor account, or gain initial access to the environment. This activity might be part of a broader attack aimed at gaining unauthorized access to sensitive resources or data within the organization\u0026rsquo;s Azure environment. It is important to ensure that only authorized personnel can invite external users to maintain security and prevent potential abuse.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises a low-privilege user account within the Azure AD tenant or uses existing compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to invite an external guest user to the tenant using the compromised account.\u003c/li\u003e\n\u003cli\u003eThe Azure AD audit logs record the \u0026ldquo;Invite external user\u0026rdquo; operation under the UserManagement category.\u003c/li\u003e\n\u003cli\u003eThe audit log event is generated, capturing details such as the user who initiated the invitation (InitiatedBy) and the target guest user\u0026rsquo;s information.\u003c/li\u003e\n\u003cli\u003eThe detection logic evaluates if the InitiatedBy user is within the list of approved guest inviters.\u003c/li\u003e\n\u003cli\u003eIf the inviting user is not on the approved list, the detection rule triggers, indicating a potentially unauthorized guest invitation.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to leverage the newly invited guest account for lateral movement or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the guest account to access resources and data within the Azure AD environment, potentially leading to data breaches or other security incidents.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe successful exploitation of this vulnerability can lead to unauthorized access to sensitive data and resources within the Azure AD tenant. While the precise number of potential victims is unknown, the impact could range from a limited breach affecting a small set of resources to a widespread compromise impacting the entire organization. The addition of unauthorized guest accounts can facilitate lateral movement, data exfiltration, and other malicious activities, leading to significant financial and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the provided Sigma rule to detect unauthorized guest user invitations in Azure AD audit logs and tune the \u003ccode\u003efilter\u003c/code\u003e with a list of approved inviters.\u003c/li\u003e\n\u003cli\u003eReview and restrict the number of users authorized to invite guest users to the Azure AD tenant based on business needs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, including guest accounts, to prevent unauthorized access (related to audit logs).\u003c/li\u003e\n\u003cli\u003eRegularly audit Azure AD logs for any suspicious activity related to user management (related to audit logs).\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-02-azuread-guest-invite/","summary":"Detection of unauthorized guest user invitations within an Azure Active Directory tenant, indicating potential privilege escalation, persistence, or initial access attempts.","title":"Unauthorized Guest User Invitations in Azure AD","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azuread-guest-invite/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["initial-access","defense-evasion","execution","explorer.exe","dcom"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","SentinelOne"],"content_html":"\u003cp\u003eAttackers frequently exploit Windows Explorer (explorer.exe) to execute malicious code due to its inherent trust within the operating system. This involves spawning child processes such as PowerShell, cmd.exe, or other scripting engines via Component Object Model (COM) and Distributed Component Object Model (DCOM). This technique enables attackers to bypass security controls, blending malicious activity with legitimate system processes. The detection rule identifies such anomalies by monitoring child processes of Explorer with specific characteristics, excluding known benign activities, to flag potential threats. This activity is frequently associated with initial access and execution of follow-on malware.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attack begins with an initial access vector such as spearphishing (T1566).\u003c/li\u003e\n\u003cli\u003eA user clicks a malicious link or opens an attachment, leading to code execution.\u003c/li\u003e\n\u003cli\u003eThe initial payload exploits explorer.exe through DCOM using the -Embedding argument.\u003c/li\u003e\n\u003cli\u003eExplorer.exe spawns a child process such as powershell.exe, cmd.exe, or mshta.exe (T1059, T1218).\u003c/li\u003e\n\u003cli\u003eThe spawned process executes malicious commands or scripts.\u003c/li\u003e\n\u003cli\u003eThese commands might download or execute additional payloads.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves code execution, potentially gaining persistence on the system.\u003c/li\u003e\n\u003cli\u003eThe ultimate objective is often lateral movement, data exfiltration, or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to execute arbitrary code within a trusted process context, bypassing application whitelisting and other security controls. This can lead to initial access, privilege escalation, and persistence within the compromised system. The compromise can remain undetected for extended periods due to the trusted nature of the parent process (explorer.exe), enabling attackers to perform reconnaissance, deploy malware, exfiltrate data, or disrupt services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable process creation logging with command line details to detect suspicious explorer.exe child processes.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Explorer Child Process - PowerShell\u0026rdquo; to identify instances of PowerShell spawned by explorer.exe with suspicious arguments.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious Explorer Child Process - Scripting Engines\u0026rdquo; to detect other scripting engines launched by explorer.exe.\u003c/li\u003e\n\u003cli\u003eMonitor process execution events for processes like powershell.exe, cmd.exe, cscript.exe, wscript.exe, mshta.exe, regsvr32.exe, and rundll32.exe with a parent process of explorer.exe and the argument \u0026ldquo;-Embedding\u0026rdquo; via process creation logs.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict execution of unsigned or untrusted scripts and executables.\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-suspicious-explorer-child-process/","summary":"Adversaries abuse the trusted status of explorer.exe to launch malicious scripts or executables, often using DCOM to start processes like PowerShell or cmd.exe, achieving initial access, defense evasion, and execution.","title":"Suspicious Explorer Child Process via DCOM","url":"https://feed.craftedsignal.io/briefs/2024-01-suspicious-explorer-child-process/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Slack","WebEx","Teams","Discord","WhatsApp","Zoom","Outlook","Thunderbird","Grammarly","Dropbox","Tableau","Google Drive","MSOffice","Okta","OneDrive","Chrome","Firefox","Edge","Brave","GoogleCloud Related Tools","Github Related Tools","Notion"],"_cs_severities":["medium"],"_cs_tags":["masquerading","defense-evasion","initial-access","malware","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Slack","Cisco","Microsoft","Discord","Zoom","Mozilla","Grammarly","Dropbox","Tableau","Google","Okta","Brave","GitHub","Notion"],"content_html":"\u003cp\u003eAttackers often attempt to trick users into downloading and executing malicious executables by disguising them as legitimate business applications. This tactic is used to bypass security measures and gain initial access to a system. These malicious executables, often distributed via malicious ads, forum posts, and tutorials, mimic the names of commonly used applications such as Slack, WebEx, Teams, Discord, and Zoom. The executables are typically unsigned or signed with invalid certificates to further evade detection. This allows the attacker to execute arbitrary code on the victim\u0026rsquo;s machine, potentially leading to further compromise. This campaign aims to target end-users who are less security-aware, and this makes social engineering attacks like this very effective.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe user visits a compromised website or clicks on a malicious advertisement.\u003c/li\u003e\n\u003cli\u003eThe user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.\u003c/li\u003e\n\u003cli\u003eThe downloaded executable is placed in the user\u0026rsquo;s Downloads folder (e.g., C:\\Users*\\Downloads*).\u003c/li\u003e\n\u003cli\u003eThe user executes the downloaded file.\u003c/li\u003e\n\u003cli\u003eThe executable, lacking a valid code signature, begins execution.\u003c/li\u003e\n\u003cli\u003eThe malicious installer may drop and execute additional malware components.\u003c/li\u003e\n\u003cli\u003eThe malware establishes persistence, potentially using techniques such as registry key modification.\u003c/li\u003e\n\u003cli\u003eThe malware performs malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful execution of a masqueraded business application installer can lead to a complete system compromise. The attacker gains initial access and can deploy various malware payloads, including ransomware, keyloggers, and data stealers. This can result in data breaches, financial loss, and reputational damage. Although the specific number of victims and sectors targeted are not detailed, the widespread use of the applications being spoofed (Slack, Zoom, etc.) suggests a broad potential impact.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003ePotential Masquerading as Business App Installer\u003c/code\u003e to detect unsigned executables resembling legitimate business applications in download directories.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging to capture the execution of unsigned executables.\u003c/li\u003e\n\u003cli\u003eEducate users on the risks of downloading and executing files from untrusted sources.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to restrict the execution of unauthorized applications.\u003c/li\u003e\n\u003cli\u003eRegularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.\u003c/li\u003e\n\u003cli\u003eMonitor process execution events for processes originating from the Downloads folder that lack valid code signatures.\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-masquerading-business-apps/","summary":"Attackers masquerade malicious executables as legitimate business application installers to trick users into downloading and executing malware, leveraging defense evasion and initial access techniques.","title":"Masquerading Business Application Installers","url":"https://feed.craftedsignal.io/briefs/2024-01-masquerading-business-apps/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office"],"_cs_severities":["medium"],"_cs_tags":["initial-access","phishing","macro"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe creation of Office macro files (.docm, .xlsm, .pptm, etc.) can be an indicator of malicious activity, often linked to initial access attempts such as phishing campaigns or malware distribution. Attackers frequently embed malicious macros within these files to execute arbitrary code on a victim\u0026rsquo;s machine upon opening the document and enabling macros. While legitimate use cases for macro-enabled documents exist, their creation should be monitored, especially when originating from unusual processes or locations. This activity is related to the technique T1566.001 (Phishing: Spearphishing Attachment). Defenders need to monitor file creation events for specific Office macro extensions, filtering out common false positives to identify potential threats.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Office document (e.g., .docm, .xlsm) containing a VBA macro.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the malicious document as an attachment via email (spearphishing).\u003c/li\u003e\n\u003cli\u003eThe user receives the email and opens the attached Office document.\u003c/li\u003e\n\u003cli\u003eThe user is prompted to enable macros within the document.\u003c/li\u003e\n\u003cli\u003eIf the user enables macros, the embedded VBA code executes.\u003c/li\u003e\n\u003cli\u003eThe VBA code may execute PowerShell or other scripting languages to download a malicious payload.\u003c/li\u003e\n\u003cli\u003eThe downloaded payload is saved to disk (e.g., in the user\u0026rsquo;s temp directory).\u003c/li\u003e\n\u003cli\u003eThe payload executes, establishing persistence or performing other malicious actions, such as ransomware deployment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to arbitrary code execution, malware installation, data exfiltration, and potentially complete system compromise. The impact can range from individual user infection to widespread organizational damage, depending on the attacker\u0026rsquo;s objectives and the level of access gained. In a widespread attack, numerous systems could be infected, leading to significant downtime, data loss, and financial repercussions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eOffice Macro File Creation\u003c/code\u003e to your SIEM to detect the creation of suspicious Office macro files (logsource: file_event/windows).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the parent processes of the file creation event.\u003c/li\u003e\n\u003cli\u003eImplement user awareness training to educate employees about the risks of opening unsolicited attachments and enabling macros.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon file creation logging to capture the necessary events for the Sigma rule to function effectively.\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-office-macro-creation/","summary":"This brief outlines a threat involving the creation of new Office macro files, potentially indicating malicious activity such as phishing or malware distribution, targeting Windows systems.","title":"Detection of Office Macro File Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-office-macro-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","federation","privilege-escalation","persistence","initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers can modify federation settings on Azure domains to gain unauthorized access and establish persistence. This involves manipulating the trust relationships between the Azure Active Directory and external identity providers. By altering these settings, an attacker can potentially bypass normal authentication mechanisms, assume identities, and maintain a foothold within the environment. This activity is typically carried out by users or applications with administrative privileges, making it crucial to monitor and validate any changes made to the federation settings. Detecting such modifications can be challenging due to the legitimate use of these settings by system administrators. This activity falls under tactics such as privilege escalation, persistence, initial access, and stealth.\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 account with sufficient privileges to manage Azure Active Directory settings, such as a Global Administrator or Privileged Role Administrator.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses PowerShell/CLI to interact with Azure resources.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing domain federation settings to understand the current configuration and identify potential targets for modification.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the federation settings on the domain using commands like \u003ccode\u003eSet-MsolDomainFederationSettings\u003c/code\u003e or through the Azure portal interface. This may involve altering the trusted certificate, changing the issuer URI, or modifying other federation parameters.\u003c/li\u003e\n\u003cli\u003eThe attacker tests the modified federation settings to ensure they can successfully authenticate using the altered configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified federation settings to impersonate users or applications, gaining unauthorized access to protected resources and services.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating backdoors or alternate authentication methods using the modified federation settings.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of Azure domain federation settings can lead to significant consequences, including unauthorized access to sensitive data, privilege escalation, and long-term persistence within the Azure environment. Attackers could potentially compromise entire domains, impacting all users and applications relying on the affected Azure Active Directory. This can result in data breaches, service disruptions, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Azure Domain Federation Settings Modified\u0026rdquo; to detect suspicious modifications to federation settings in Azure audit logs.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate changes to Azure domain federation settings, focusing on unfamiliar users and unexpected modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for the \u0026ldquo;Set federation settings on domain\u0026rdquo; event to identify potential tampering.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all accounts with administrative privileges to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege, granting users only the necessary permissions to perform their tasks.\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-federation-modification/","summary":"An attacker may modify Azure domain federation settings to establish persistence, escalate privileges, or gain unauthorized access to resources.","title":"Azure Domain Federation Settings Modified","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-federation-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Outlook","Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["initial-access","phishing","malware","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic"],"content_html":"\u003cp\u003eThis detection identifies suspicious child processes of Microsoft Outlook, often associated with spear phishing activity and the execution of malicious attachments. Attackers may leverage malicious documents delivered via email to execute arbitrary code on a victim\u0026rsquo;s machine. The rule focuses on identifying processes such as \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, and other system binaries being spawned by Outlook, suggesting the potential execution of malicious attachments or exploitation for initial access. This activity is designed to bypass traditional security measures and gain an initial foothold within the targeted environment. The rule is designed for data generated by Elastic Defend, but also supports third-party data sources like CrowdStrike, Microsoft Defender XDR, SentinelOne Cloud Funnel, Sysmon, and Windows Security Event Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user receives a spear phishing email with a malicious attachment (e.g., a Microsoft Office document or PDF).\u003c/li\u003e\n\u003cli\u003eThe user opens the attachment, unknowingly triggering embedded malicious code (e.g., macros or exploits).\u003c/li\u003e\n\u003cli\u003eThe malicious code executes within the context of Microsoft Outlook (outlook.exe).\u003c/li\u003e\n\u003cli\u003eThe malicious code spawns a suspicious child process, such as \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003emshta.exe\u003c/code\u003e, or \u003ccode\u003ewscript.exe\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe spawned process executes commands to download and execute further malicious payloads from external sources.\u003c/li\u003e\n\u003cli\u003eThe downloaded payload establishes persistence on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker gains initial access and begins reconnaissance activities.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the network, escalating privileges and compromising additional systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to initial access, allowing attackers to gain a foothold within the network, escalate privileges, and potentially exfiltrate sensitive data, deploy ransomware, or conduct other malicious activities. While specific victim counts and sectors are unavailable, similar attacks have targeted a wide range of industries.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Suspicious MS Outlook Child Process Spawning Command Interpreter\u0026rdquo; to your SIEM to detect potential initial access attempts (see rule below).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging (Event ID 1) to provide the necessary data for the Sigma rules.\u003c/li\u003e\n\u003cli\u003eBlock the execution of commonly abused system binaries (e.g., \u003ccode\u003ecmd.exe\u003c/code\u003e, \u003ccode\u003epowershell.exe\u003c/code\u003e, \u003ccode\u003ewscript.exe\u003c/code\u003e) as child processes of Outlook using application control policies where possible.\u003c/li\u003e\n\u003cli\u003eImplement and enforce strict macro policies in Microsoft Office applications to prevent the execution of malicious code within documents.\u003c/li\u003e\n\u003cli\u003eRegularly review and update email security policies to prevent spear phishing emails from reaching users.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T10:00:00Z","date_published":"2024-01-02T10:00:00Z","id":"/briefs/2024-01-02-suspicious-outlook-child-process/","summary":"Detection of suspicious child processes spawned by Microsoft Outlook, indicative of spear phishing and malicious file execution leading to potential initial access and further exploitation.","title":"Suspicious MS Outlook Child Process","url":"https://feed.craftedsignal.io/briefs/2024-01-02-suspicious-outlook-child-process/"}],"language":"en","title":"CraftedSignal Threat Feed — Initial-Access","version":"https://jsonfeed.org/version/1.1"}