Initial-Access — CraftedSignal Threat Feed

Remote Desktop File Opened from Suspicious Path

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

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

Attack Chain

The attacker crafts a spearphishing email containing a malicious RDP file as an attachment.
The victim receives the email and, lured by social engineering, downloads the attached RDP file to a local directory, often the Downloads folder.
The victim double-clicks the RDP file, initiating the execution of mstsc.exe.
mstsc.exe reads the connection settings from the RDP file, which may include malicious configurations such as altered gateway settings or credential theft mechanisms.
mstsc.exe attempts to establish a remote desktop connection based on the RDP file’s settings.
If the connection is successful, the attacker gains unauthorized access to the remote system.
The attacker may then perform reconnaissance, move laterally, and escalate privileges within the compromised network.
The final objective could be data exfiltration, ransomware deployment, or establishing persistent access.

Impact

A 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’s objectives and the scope of the compromised network.

Recommendation

Deploy the Sigma rule Remote Desktop File Opened from Suspicious Path to your SIEM and tune for your environment, focusing on the specified file paths and mstsc.exe execution.
Enable process creation logging with command-line arguments to capture the execution of mstsc.exe and the paths of the RDP files being opened.
Educate users on the risks associated with opening RDP files from untrusted sources, particularly those received as email attachments.
Implement strict email filtering to block or quarantine emails with RDP attachments from external sources.
Monitor network connections for unusual RDP traffic originating from systems where suspicious RDP files were executed.

Potential Remote File Execution via MSIEXEC

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

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

Attack Chain

An attacker gains initial access via phishing (T1566) or other means to execute commands on the target system.
The attacker uses msiexec.exe with the /V parameter to initiate the installation of a remote MSI package. This allows the attacker to bypass typical execution restrictions.
Msiexec.exe attempts a network connection (T1105) to retrieve the remote MSI package from a malicious server.
Msiexec.exe spawns a child process to handle the installation of the downloaded MSI package.
The spawned child process executes malicious code embedded within the MSI package.
The malicious code performs actions such as installing malware, modifying system settings, or establishing persistence.
The attacker leverages the compromised system for further lateral movement or data exfiltration.

Impact

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

Recommendation

Deploy the Sigma rule provided below to your SIEM to detect suspicious usage of msiexec.exe to install remote packages. Tune the rule for your environment by adding exceptions for legitimate software installation processes.
Enable 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).
Review the “Possible investigation steps” section in the Elastic rule’s documentation to investigate potential false positives and legitimate uses of msiexec.exe.
Implement application control policies to restrict the execution of unauthorized applications, including potentially malicious MSI packages.

Google Workspace Login Attempt with Government Attack Warning

hello@craftedsignal.io — Tue, 28 Apr 2026 00:48:14 +0000

This alert focuses on identifying potentially malicious login attempts within Google Workspace environments. The detection is based on Google’s own flagging of a login as a potential “gov_attack_warning,” suggesting that Google’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.

Attack Chain

Initial Access: An attacker attempts to log into a Google Workspace account using compromised or brute-forced credentials.
Login Attempt: The login attempt triggers a “gov_attack_warning” within Google Workspace, indicating a potential government-backed threat actor.
Privilege Escalation (Potential): If the compromised account has elevated privileges, the attacker may attempt to escalate privileges within the Google Workspace environment.
Defense Evasion (Potential): The attacker may attempt to disable security features or modify audit logs to evade detection.
Persistence (Potential): The attacker may establish persistent access through methods such as creating rogue apps or modifying account settings.
Data Access: The attacker gains access to sensitive data stored within Google Workspace, such as documents, emails, and files.
Exfiltration (Potential): The attacker exfiltrates the stolen data to an external location.
Impact: The organization suffers a data breach, reputational damage, and potential financial losses.

Impact

A 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’s access and the sensitivity of the compromised data.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect “gov_attack_warning” events in Google Workspace logs.
Investigate any triggered alerts promptly, focusing on the affected user account and associated activity.
Review the Google Workspace audit logs for any suspicious activity leading up to the “gov_attack_warning” event.
Implement multi-factor authentication (MFA) for all Google Workspace accounts, especially those with elevated privileges.
Monitor Google Workspace activity logs for suspicious patterns, such as unusual login locations, failed login attempts, and changes to account settings.

Large-Scale OAuth Device Code Phishing Campaign Observed in April 2026

hello@craftedsignal.io — Fri, 24 Apr 2026 19:52:35 +0000

In 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 “Riding the Rails” 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.

Attack Chain

The attacker sends a phishing email to the victim, impersonating a legitimate service.
The email contains a link that redirects the victim to a fake application authorization page.
The fake page prompts the victim to enter a device code.
Unbeknownst to the victim, the device code is associated with a malicious OAuth application controlled by the attacker.
The victim is redirected to a legitimate Microsoft login page, where they enter the provided code and authenticate.
Upon successful authentication, the malicious application receives an access token.
The attacker uses the access token to access the victim’s account and sensitive data.
The attacker may then perform actions such as reading emails, accessing files, or initiating further malicious activity within the compromised account.

Impact

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

Recommendation

Monitor Azure AD sign-in logs for device code flow usage to identify suspicious authentications (logsource: azuread, category: authentication).
Implement the Sigma rule provided below to detect suspicious application registrations in Azure AD (logsource: o365, category: configuration).
Educate users on the risks of device code phishing and how to identify malicious authorization requests.
Regularly audit OAuth applications authorized within your environment and revoke access for any suspicious or unused applications.
Investigate any alerts related to anomalous OAuth application activity promptly.

AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure

hello@craftedsignal.io — Wed, 22 Apr 2026 17:45:55 +0000

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

Attack Chain

An attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.
The 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.
The attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.
The attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker’s source IP address and ASN.
The attacker performs reconnaissance activities, such as calling sts:GetCallerIdentity, ListBuckets, DescribeInstances, or ListUsers, to understand the AWS environment and identify potential targets.
The attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.
The 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.

Impact

Successful 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’s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.

Recommendation

Deploy the Sigma rule “AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure” to your SIEM and tune for your environment to detect suspicious usage patterns.
Rotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.
Implement OIDC-based authentication (aws-actions/configure-aws-credentials with role-to-assume) instead of long-lived access keys as mentioned in the rule documentation.
If using OIDC, add IP condition policies to the IAM role trust policy to restrict AssumeRoleWithWebIdentity to known GitHub runner IP ranges, based on the information in the rule documentation.

Suspicious RDP File Execution

hello@craftedsignal.io — Mon, 20 Apr 2026 21:38:09 +0000

This detection identifies the execution of mstsc.exe (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’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.

Attack Chain

The attacker crafts a spearphishing email with a malicious RDP file attachment (T1566.001).
The victim receives the email and downloads the RDP file to a common location such as the Downloads folder.
The user executes the downloaded RDP file, initiating the mstsc.exe process (T1204.002).
The mstsc.exe process attempts to establish a remote connection to a malicious server controlled by the attacker.
The attacker may exploit vulnerabilities in the RDP service or use credential harvesting techniques to gain access to the remote system.
Upon successful connection, the attacker performs reconnaissance activities, such as network scanning and user enumeration.
The attacker moves laterally within the network, exploiting additional vulnerabilities or using stolen credentials.
The attacker achieves their objective, such as data exfiltration or deploying ransomware.

Impact

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

Recommendation

Enable Sysmon process creation logging to detect the execution of mstsc.exe and capture the command-line arguments used to launch the process.
Deploy the Sigma rule “Remote Desktop File Opened from Suspicious Path” to your SIEM to detect RDP files opened from suspicious locations.
Educate users about the risks of opening RDP files from untrusted sources, especially those received via email.
Implement application control policies to restrict the execution of mstsc.exe from untrusted directories.
Monitor network connections originating from systems where mstsc.exe has been executed to identify suspicious remote connections.

Elastic Defend Alert from Package Manager Install Ancestry

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

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

Attack Chain

A developer or system administrator initiates a package installation using a package manager like npm, pip, or cargo.
The package manager downloads and installs the requested package and its dependencies.
The installed package contains malicious code embedded within a post-install script or a dependency.
The package manager executes the malicious post-install script (e.g., using node, python, or cargo).
The malicious script executes arbitrary commands, such as downloading and executing a payload from a remote server.
The downloaded payload establishes persistence on the system, potentially through scheduled tasks or registry keys.
The attacker gains initial access to the system and begins lateral movement and privilege escalation.
The attacker achieves their objective, such as data exfiltration, ransomware deployment, or system compromise.

Impact

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

Recommendation

Deploy the following Sigma rules to your SIEM to detect malicious activity related to package manager installations.
Review and tune the Sigma rules for your specific environment to reduce false positives.
Implement strict code review and dependency management practices to prevent the introduction of malicious packages.
Monitor Elastic Defend alerts for suspicious activity in the process tree of package manager installations, as surfaced by this detection rule.
Investigate any alerts related to package manager install ancestry to identify and remediate potential supply chain attacks.
Enable process monitoring with command-line logging to capture the full context of package manager installations.

Azure Service Principal Sign-In Followed by Arc Cluster Credential Access

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

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

Attack Chain

Initial Compromise: An attacker gains unauthorized access to a service principal’s credentials (e.g., through credential stuffing, phishing, or exposed secrets).
Service Principal Authentication: The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the ServicePrincipalSignInLogs.
Credential Listing Request: 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 MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION in the Activity Logs.
Credential Retrieval: The attacker retrieves the Arc cluster credentials.
Proxy Tunnel Establishment: The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.
Kubernetes Access: 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.
Lateral Movement & Privilege Escalation: The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.
Data Exfiltration or Ransomware Deployment: The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.

Impact

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

Recommendation

Deploy 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.
Review 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’s note.
Enable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule’s note.
Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION events to identify potential unauthorized access attempts.
Rotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule’s response and remediation steps.

AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts

hello@craftedsignal.io — Mon, 06 Apr 2026 14:37:37 +0000

This 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 “AWS Long-Term Access Key First Seen from Source IP” 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 kibana.alert fields to identify related events.

Attack Chain

An 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.
The attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the “AWS Long-Term Access Key First Seen from Source IP” rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).
The attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.
The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.
The attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.
The attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.
The correlation rule identifies the co-occurrence of the “AWS Long-Term Access Key First Seen from Source IP” alert and other elevated severity alerts associated with the same access key ID.
The security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.

Impact

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

Recommendation

Deploy the “AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts” rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.
Investigate alerts triggered by the rule by pivoting on the aws.cloudtrail.user_identity.access_key_id in CloudTrail and IAM to understand the context of the access key usage.
Review the sibling alerts identified by the rule using Esql.kibana_alert_rule_name_values and Esql.kibana_alert_rule_id_values to understand the scope and impact of the potential compromise.
Configure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that kibana.alert.risk_score >= 47 corresponds to medium or higher severity alerts.
Rotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.
Enable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.
Implement the “AWS Long-Term Access Key First Seen from Source IP” rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.

Unsecured Zoom Meeting Creation

hello@craftedsignal.io — Wed, 01 Apr 2026 15:53:12 +0000

The absence of passcodes on Zoom meetings creates a significant vulnerability, allowing malicious actors to engage in “Zoombombing.” 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.

Attack Chain

An attacker identifies a Zoom meeting ID without a passcode, often through social media or shared links.
The attacker joins the meeting using the Zoom client or web interface.
Once inside, the attacker disrupts the meeting by sharing offensive content (images, videos, audio) via screen sharing or chat.
The attacker may attempt to gather sensitive information shared during the meeting, such as personal data or confidential business details.
Participants react to the disruption, causing further chaos and potentially escalating the situation.
The meeting host is forced to end the meeting abruptly to stop the disruption, impacting productivity.
The incident may lead to reputational damage for the organization hosting the meeting.

Impact

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

Recommendation

Deploy the Sigma rule “Zoom Meeting with no Passcode” to detect the creation of meetings without passcodes in your environment.
Review Zoom account settings to enforce mandatory passcodes for all new meetings.
Enable the Zoom Filebeat module or similar structured data collection for comprehensive Zoom event logging.
Educate meeting hosts about the risks of unsecured meetings and best practices for securing their sessions.
Implement 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.

Potential Abuse of msDS-ManagedAccountPrecededByLink for Privilege Escalation

hello@craftedsignal.io — Mon, 30 Mar 2026 10:27:13 +0000

This threat brief focuses on the modification of the msDS-ManagedAccountPrecededByLink 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 ‘BadSuccessor’ privilege escalation vulnerability in Windows Server 2025. The vulnerability, as outlined in Akamai’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 .Put("msDS-ManagedAccountPrecededByLink' and CN=, 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.

Attack Chain

Initial Access: 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).
Discovery: The attacker uses PowerShell to enumerate existing dMSAs and their associated msDS-ManagedAccountPrecededByLink attributes.
Attribute Modification: The attacker crafts a PowerShell script to modify the msDS-ManagedAccountPrecededByLink attribute of a target dMSA. This involves using the .Put("msDS-ManagedAccountPrecededByLink" command and specifying a new distinguished name (CN=) for the preceding account.
Persistence: The attacker leverages the modified dMSA link to establish a persistent foothold in the environment by gaining control over the targeted dMSA.
Privilege Escalation: By manipulating the dMSA links, the attacker effectively inherits the permissions and privileges associated with the compromised dMSA, thereby escalating their own privileges.
Defense Evasion: The attacker may attempt to evade detection by obfuscating the PowerShell script or using other techniques to hide their activity.
Lateral Movement: With elevated privileges, the attacker can move laterally within the network, accessing sensitive resources and systems.

Impact

Successful exploitation of the ‘BadSuccessor’ vulnerability through modification of the msDS-ManagedAccountPrecededByLink 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.

Recommendation

Deploy 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).
Investigate any alerts triggered by the Sigma rule to determine if the activity is legitimate or indicative of an attempted exploitation of the ‘BadSuccessor’ vulnerability.
Implement strict access controls and monitoring for systems and accounts with the ability to modify Active Directory attributes.
Review and harden Active Directory security configurations to prevent unauthorized modification of sensitive attributes.

Device Code Phishing Campaign Targeting Cloud Platforms

hello@craftedsignal.io — Wed, 25 Mar 2026 12:00:00 +0000

An active phishing campaign is leveraging Microsoft’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.

Attack Chain

The attacker sends a phishing email impersonating a cloud-based file storage or document workflow service.
The email contains a message prompting the user to “activate” or “authenticate” their account.
The email includes a device code and instructs the user to visit a Microsoft login page (e.g., microsoft.com/devicelogin).
The user, believing the request is legitimate, enters the provided device code on the Microsoft login page.
The Microsoft login page prompts the user to grant permissions to an application controlled by the attacker.
If the user approves the permissions, the attacker gains OAuth tokens that allow access to the user’s account on the targeted cloud platform.
The attacker can then access, modify, or exfiltrate data stored on the compromised account.
The attacker may use the compromised account to further propagate the phishing campaign to other users within the organization.

Impact

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

Recommendation

Implement user awareness training to educate employees about device code phishing and the risks of entering unknown codes on login pages.
Monitor 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 “Detect Suspicious Device Code Authentication” Sigma rule to identify anomalous activity.
Implement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to trusted devices and locations.
Investigate any successful device code authentications where the application requesting permissions is not recognized or approved by the organization.

Azure Service Principal Sign-In Followed by Arc Cluster Credential Access

hello@craftedsignal.io — Tue, 17 Mar 2026 15:06:47 +0000

This 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 listClusterUserCredential action retrieves tokens enabling kubectl 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.

Attack Chain

The attacker compromises or obtains valid credentials for an Azure Service Principal.
The attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.
The attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION.
If successful, the listClusterUserCredential action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.
The attacker uses the acquired credentials to interact with the Kubernetes cluster via kubectl proxied through Azure Arc.
The attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.
The attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.
The attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.

Impact

Compromise 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’s objectives and the compromised environment.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the described attack chain, tuning the maxspan value based on observed authentication patterns and network latency.
Investigate 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).
Implement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).
Review and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).
Enable 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).

Fortigate VPN CVE-2023-27997 Exploitation Attempt

hello@craftedsignal.io — Sat, 28 Feb 2026 00:46:45 +0000

On 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 /remote/logincheck 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…

Suspicious AWS EC2 Key Pair Import Activity

hello@craftedsignal.io — Thu, 19 Dec 2024 00:00:00 +0000

The 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’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.

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role.
The attacker attempts to enumerate existing EC2 instances to identify potential targets.
The attacker generates or obtains an SSH key pair, which they intend to use for unauthorized access.
The attacker uses the ImportKeyPair API call within the EC2 service to import the generated or obtained SSH key pair.
The attacker modifies the EC2 instance’s configuration to associate the newly imported key pair with the instance. This might involve stopping and restarting the instance.
The attacker uses the imported SSH key pair to gain SSH access to the EC2 instance.
Once inside the instance, the attacker attempts to escalate privileges and move laterally within the AWS environment.
The attacker exfiltrates sensitive data, deploys malware, or disrupts critical services.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect ImportKeyPair events in CloudTrail logs (logsource: aws, service: cloudtrail).
Review IAM policies to ensure that only authorized users and roles have the necessary permissions to import key pairs (eventSource: ’ec2.amazonaws.com’, eventName: ‘ImportKeyPair’).
Investigate any detected ImportKeyPair events, validating the user identity, user agent, and source IP address to ensure they are expected (detection block).
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.

GitHub SSH Certificate Configuration Changed

hello@craftedsignal.io — Sat, 02 Nov 2024 14:00:00 +0000

Attackers 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 ssh_certificate_authority.create or ssh_certificate_requirement.disable 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’s resources. The GitHub audit log streaming feature must be enabled to detect this activity.

Attack Chain

Initial Compromise: An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.
Privilege Escalation: The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.
SSH Certificate Authority Creation: The attacker creates a new SSH certificate authority within the GitHub organization (ssh_certificate_authority.create).
Disable SSH Certificate Requirement: Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (ssh_certificate_requirement.disable). This action allows attackers to bypass security controls that enforce SSH certificate usage.
Unauthorized Access: The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.
Lateral Movement: The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.
Data Exfiltration/Malicious Code Injection: The attacker exfiltrates sensitive data or injects malicious code into the organization’s repositories.
Persistence: The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.

Impact

Successful 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’s access and the sensitivity of the compromised data.

Recommendation

Enable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).
Deploy the provided Sigma rule to detect ssh_certificate_authority.create or ssh_certificate_requirement.disable events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).
Regularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.

Suspicious Child Processes Spawned by JetBrains TeamCity

hello@craftedsignal.io — Wed, 15 May 2024 12:00:00 +0000

JetBrains 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 cmd.exe, powershell.exe, and msiexec.exe. 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.

Attack Chain

Initial Access: An attacker exploits a vulnerability (e.g., CVE-2023-42793) in the TeamCity server to gain initial access.
Code Execution: The attacker leverages the vulnerability to execute arbitrary code on the TeamCity server.
Process Spawning: The attacker spawns a command interpreter, such as cmd.exe or powershell.exe, from the TeamCity Java process (java.exe).
Discovery: The attacker uses discovery commands via the spawned shell to enumerate users, network configuration, and running processes using tools like whoami.exe, ipconfig.exe, and tasklist.exe.
Defense Evasion: The attacker leverages system binary proxy execution using tools like mshta.exe or regsvr32.exe to evade detection.
Persistence: While not explicitly mentioned, the attacker could establish persistence by creating scheduled tasks or modifying registry keys via spawned processes.
Lateral Movement: The attacker uses discovered credentials to move laterally to other systems within the network.
Impact: The attacker injects malicious code into software builds, compromises sensitive data, or deploys ransomware.

Impact

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

Recommendation

Deploy the “Suspicious JetBrains TeamCity Child Process” rule to your SIEM to detect potential exploitation attempts.
Enable Sysmon process creation logging to capture process execution events, which are essential for triggering the detection rule.
Review and patch any known vulnerabilities in JetBrains TeamCity, focusing on remote code execution flaws as described in the referenced Trend Micro report.
Implement network segmentation to limit the impact of a compromised TeamCity server and prevent lateral movement.
Continuously monitor TeamCity server logs for any unusual activity or unauthorized access attempts.
Tune the “Suspicious JetBrains TeamCity Child Process” rule by creating exceptions for legitimate build scripts that invoke command-line utilities to reduce false positives, as mentioned in the rule’s documentation.

OpenCanary SSH Login Attempt Detection

hello@craftedsignal.io — Thu, 02 May 2024 14:30:00 +0000

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

Attack Chain

The attacker gains initial access to the network, possibly through phishing, exploiting a vulnerability, or compromised credentials.
The attacker performs network scanning to identify potential targets, including the OpenCanary node masquerading as a legitimate SSH server.
The attacker attempts to establish an SSH connection to the OpenCanary node, attempting to authenticate using various usernames and passwords.
The OpenCanary service logs the failed SSH login attempt, recording the source IP address and attempted credentials.
Security monitoring tools ingest the OpenCanary logs and trigger an alert based on the detected SSH login attempt.
Security analysts investigate the alert, analyzing the source IP address and other relevant information to determine the scope and severity of the potential breach.

Impact

A 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’s source IP address and attempted usernames can provide valuable insights into their tactics and objectives, preventing damage.

Recommendation

Deploy the Sigma rule “OpenCanary - SSH Login Attempt” to your SIEM to detect unauthorized SSH login attempts on OpenCanary nodes.
Investigate and block any identified malicious source IP addresses from network access using firewall rules.
Review OpenCanary configuration to ensure it is deployed in strategically valuable network segments (references: OpenCanary documentation).
Correlate OpenCanary alerts with other security events to identify potential broader attack campaigns.

Okta Admin Console Unusual Behavior Detection

hello@craftedsignal.io — Thu, 02 May 2024 10:00:00 +0000

This threat brief focuses on detecting unusual behaviors within the Okta Admin Console, as identified by Okta’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’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.

Attack Chain

An attacker gains initial access to an Okta account, possibly through credential phishing or brute-force attacks.
The attacker attempts to log in to the Okta Admin Console.
Okta’s behavior detection engine analyzes the login attempt, considering factors like the user’s location, device, and time of day.
The system logs record a policy.evaluate_sign_on event when a sign-on policy is evaluated.
The target.displayName field within the log specifies “Okta Admin Console” indicating the user is attempting to access the administrative interface.
If Okta identifies the behavior as unusual, the debugContext.debugData.behaviors or debugContext.debugData.logOnlySecurityData fields will contain “POSITIVE”.
An alert is triggered based on the identified unusual behavior.
The attacker, if successful in bypassing initial checks, may proceed to create new admin accounts, modify existing policies, or exfiltrate sensitive data.

Impact

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

Recommendation

Deploy the provided Sigma rule Okta Admin Console Unusual Behavior to your SIEM to detect suspicious Okta Admin Console access based on Okta’s internal behavior analysis.
Investigate any alerts generated by the Sigma rule to determine if the unusual behavior is legitimate or indicative of malicious activity.
Review Okta’s System Log API documentation to understand the various event types and data fields available for monitoring and detection.
Implement multi-factor authentication (MFA) for all Okta accounts, especially administrator accounts, to mitigate the risk of account compromise (related to initial access).
Monitor Okta’s security advisories and announcements for updates on emerging threats and recommended security practices (references).

Bitbucket User Login Failure Detection

hello@craftedsignal.io — Fri, 08 Mar 2024 15:00:00 +0000

This 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 “author.name” field for enhanced accuracy and context. Requires “Advance” log level to receive audit events.

Attack Chain

Initial Access Attempt: An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.
Credential Guessing: The attacker attempts to guess the user’s password through manual attempts or automated tools.
Authentication Failure: Bitbucket records a “User login failed” event due to incorrect credentials. The auditType.category is Authentication, and auditType.action is User login failed.
Multiple Failed Attempts: The attacker repeats the login attempts with different password variations or using a list of compromised credentials.
Account Lockout (Optional): Depending on Bitbucket’s configuration, repeated failed login attempts may trigger an account lockout.
Successful Login (Potential): After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.
Privilege Escalation/Persistence (If Successful): If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.

Impact

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

Recommendation

Deploy the Sigma rule “Bitbucket User Login Failure” to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.
Investigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.
Implement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.
Monitor for unusual activity following any successful login after a series of failures.
Enforce strong password policies to reduce the effectiveness of brute-force attacks.

Detection of New GitHub Actions Secrets Creation

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

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

Attack Chain

An attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).
The attacker authenticates to the GitHub organization or repository.
The attacker navigates to the settings for the organization, environment, codespaces, or repository.
The attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.
The secret is stored within GitHub’s infrastructure, accessible to GitHub Actions workflows.
The attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.
The workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.
The attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.

Impact

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

Recommendation

Enable GitHub audit log streaming to capture the events necessary for this detection (see logsource definition).
Deploy the Sigma rule Github New Secret Created to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on the “actor” involved in creating the secret.

AWS Identity API Access from Rare ASN Organizations

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

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

Attack Chain

An attacker gains access to valid AWS credentials, potentially through phishing, credential stuffing, or exposed secrets.
The attacker uses the compromised credentials to make API calls from their own infrastructure, which is associated with a rare AS organization.
The attacker performs reconnaissance, such as GetCallerIdentity, ListBuckets, or ListSecrets, to understand the AWS environment.
The attacker attempts to escalate privileges by calling AssumeRole, AttachUserPolicy, or CreateAccessKey.
The attacker attempts to access sensitive data using actions such as GetObject or GetSecretValue.
The attacker attempts to create new users or modify existing user profiles using actions such as CreateUser, UpdateLoginProfile, or AddUserToGroup.
The attacker may attempt to invoke cloud ML models using InvokeModel or Converse to further their objectives.
The attacker persists in the environment by creating new IAM users, roles, or policies, or by modifying existing ones.

Impact

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

Recommendation

Enable AWS CloudTrail logging in all regions and send logs to a centralized SIEM or logging platform to enable detection capabilities (references).
Deploy the Sigma rule “AWS Rare Source AS Organization Activity” translated from the provided ESQL query to detect unusual source ASNs for AWS API calls.
Investigate alerts generated by the rule, focusing on the user.name, aws.cloudtrail.user_identity.type, Esql.src_asn_values, and Esql.untrusted_suspicious_actions to understand the context of the activity.
Rotate credentials for the affected principal if abuse is suspected and enforce OIDC or short-lived keys for automation.
Tighten IAM and data-plane permissions to limit the impact of compromised credentials.

Google Workspace Suspicious Login Activity

hello@craftedsignal.io — Fri, 26 Jan 2024 10:00:00 +0000

This brief focuses on detecting suspicious login activity within Google Workspace environments, as flagged by Google’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 ‘suspicious_login_less_secure_app’, ‘suspicious_login’, and ‘suspicious_programmatic_login’.

Attack Chain

Initial Access: An attacker gains initial access using compromised credentials or brute-force techniques targeting Google Workspace accounts.
Login Attempt: 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.
Suspicious Activity Detection: Google’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.
Event Logging: Google Workspace logs the suspicious login event, including the reason for the classification (e.g., ‘suspicious_login_less_secure_app’).
Potential Privilege Escalation: Upon successful login, the attacker may attempt to escalate privileges within the Google Workspace environment to gain broader access.
Defense Evasion: The attacker might use techniques to evade detection, such as disabling security features or modifying audit logs.
Persistence: The attacker establishes persistence by creating new accounts, modifying existing ones, or installing malicious apps.
Data Exfiltration/Malicious Activity: The attacker uses the compromised account to exfiltrate sensitive data or perform other malicious activities, such as sending phishing emails.

Impact

Successful 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’s ability to escalate privileges. Targeted sectors are broad, affecting any organization relying on Google Workspace for collaboration and data storage.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious login activity classified by Google Workspace (logsource: gcp, service: google_workspace.login).
Investigate 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.
Enforce multi-factor authentication (MFA) for all Google Workspace accounts to mitigate the risk of credential compromise.
Disable or restrict the use of less secure apps within Google Workspace to reduce the attack surface.
Monitor Google Workspace audit logs for other suspicious activities, such as unusual file access or data exfiltration attempts.

Detecting External RPC Traffic for Initial Access

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

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

Attack Chain

An attacker scans the internet for systems with exposed RPC services on TCP port 135.
The attacker establishes a TCP connection to the target system’s port 135.
The attacker attempts to negotiate an RPC connection, potentially exploiting vulnerabilities in the RPC service.
Successful exploitation allows the attacker to execute commands remotely on the target system.
The attacker uses the compromised system to perform reconnaissance, gathering information about the internal network.
The attacker attempts lateral movement to other systems within the network, using the initial foothold.
The attacker installs malware or creates a backdoor for persistent access.

Impact

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

Recommendation

Deploy the Sigma rule “Detect RPC from Internet” to your SIEM to identify potentially malicious connections to port 135.
Review and harden systems that provide RPC services to ensure they are not directly exposed to the internet, as detected by the rule “Detect RPC from Internet”.
Enforce 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).
Investigate 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).

Successful AWS Console Login Without MFA

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

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

Attack Chain

An attacker obtains valid AWS credentials, possibly through phishing, credential stuffing, or by exploiting a vulnerable service.
The attacker uses the compromised credentials to attempt to log in to the AWS Management Console.
The attacker successfully authenticates without providing an MFA code, indicating MFA is not enabled or is bypassed for the compromised user.
After successful login, the attacker enumerates existing AWS resources, including EC2 instances, S3 buckets, and IAM roles, using the AWS CLI or Console.
The attacker attempts to escalate privileges by exploiting IAM misconfigurations or vulnerabilities to gain access to more sensitive resources.
The attacker modifies security configurations, such as disabling CloudTrail logging or creating new IAM users with elevated permissions, to establish persistence.
The attacker accesses sensitive data stored in S3 buckets or databases, potentially exfiltrating it to an external location.

Impact

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

Recommendation

Deploy the “AWS Successful Console Login Without MFA” Sigma rule to your SIEM to detect logins without MFA (rule).
Enforce MFA for all AWS IAM users, especially those with administrative privileges to prevent initial access (reference: https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/).
Regularly audit IAM configurations to identify and remediate misconfigurations that could allow privilege escalation.
Monitor CloudTrail logs for suspicious activity following a console login, such as resource enumeration or IAM policy changes (logsource).

Apache Struts CVE-2023-50164 Exploitation Leading to Web Shell Deployment

hello@craftedsignal.io — Fri, 05 Jan 2024 18:22:00 +0000

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

Attack Chain

The attacker sends a malicious HTTP POST request to a vulnerable Apache Struts endpoint (e.g., *.action).
The HTTP POST request contains a multipart/form-data content type with a WebKitFormBoundary string.
The request exploits CVE-2023-50164, leveraging a path traversal vulnerability in the file upload process.
The attacker bypasses security controls due to the path traversal vulnerability.
The attacker uploads a malicious JSP file (web shell) to a web-accessible directory, such as Tomcat’s webapps directory.
A Java process (e.g., Tomcat) creates the JSP web shell file in the webapps directory.
The attacker accesses the deployed web shell via HTTP.
The attacker executes arbitrary commands on the server through the web shell.

Impact

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

Recommendation

Deploy the Sigma rule “Apache Struts CVE-2023-50164 Webshell Creation” to detect JSP file creation events in webapps directories following suspicious POST requests as described in the overview.
Deploy the Sigma rule “Apache Struts CVE-2023-50164 Suspicious POST Request” to detect suspicious POST requests to Struts endpoints with multipart/form-data content containing WebKitFormBoundary, as indicated in the Attack Chain.
Patch 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.
Enable 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.

Suspicious PDF Reader Child Process Activity

hello@craftedsignal.io — Thu, 04 Jan 2024 18:45:00 +0000

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

Attack Chain

A user receives a malicious PDF document via phishing or other means.
The user opens the PDF document using a vulnerable PDF reader application (e.g., Adobe Acrobat, Foxit Reader).
The PDF document exploits a vulnerability or uses a malicious script to execute an arbitrary command.
The 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).
The spawned process executes commands to gather system information (e.g., ipconfig.exe, systeminfo.exe, whoami.exe).
The attacker may attempt to discover network configuration, user accounts, or running processes.
The attacker could leverage the spawned process to download and execute further payloads.
The attacker gains a foothold on the system and can proceed with lateral movement, data exfiltration, or other malicious activities.

Impact

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

Recommendation

Enable process creation logging with command line arguments to capture the execution of suspicious child processes (Sysmon Event ID 1, Windows Security Event Logs).
Deploy the Sigma rule “Suspicious PDF Reader Child Process” to your SIEM and tune for your environment to detect the execution of suspicious processes spawned by PDF reader applications.
Monitor for network connections originating from PDF reader applications to unusual or external IP addresses.
Implement application control policies to restrict the execution of unauthorized or unknown executables.

Suspicious AWS SAML Activity Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 18:22:30 +0000

This detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for AssumeRoleWithSAML and UpdateSAMLProvider 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.

Attack Chain

The attacker compromises or creates a malicious SAML identity provider.
The attacker configures the AWS environment to trust the malicious SAML provider using UpdateSAMLProvider.
The attacker crafts a SAML assertion to assume a specific role within the AWS environment.
The attacker uses the AssumeRoleWithSAML API call to authenticate with AWS using the crafted SAML assertion.
AWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.
The attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.
The attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.
The attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.

Impact

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

Recommendation

Deploy the Sigma rule for AssumeRoleWithSAML events to detect suspicious role assumptions (see “AssumeRoleWithSAML Detection Rule”).
Deploy the Sigma rule for UpdateSAMLProvider events to detect unauthorized SAML provider modifications (see “UpdateSAMLProvider Detection Rule”).
Investigate any AssumeRoleWithSAML events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.
Monitor UpdateSAMLProvider events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.
Tune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.

Azure AD Temporary Access Pass Added to Account

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

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

Attack Chain

Initial Compromise (Optional): An attacker gains initial access to an Azure AD account through compromised credentials or other means.
Privilege Escalation (Optional): The attacker escalates privileges to an account with sufficient permissions to manage TAPs.
TAP Generation: The attacker, using an account with appropriate permissions, generates a temporary access pass (TAP) for a target account.
TAP Activation: The attacker uses the TAP to authenticate to the target account.
Resource Access: Once authenticated, the attacker gains access to resources and applications associated with the target account.
Lateral Movement (Optional): The attacker uses the compromised account to access other resources or accounts within the environment.
Persistence (Optional): The attacker establishes persistence by creating new credentials or modifying existing ones, if permissions allow.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect TAP additions in Azure AD audit logs (see rules).
Investigate any instances where TAPs are added to privileged accounts in Azure AD, as highlighted in the rule description and references.
Review Azure AD audit logs for suspicious activity surrounding the TAP generation event, including the source IP address and user agent (see rules).
Monitor for anomalous sign-in activity using TAPs, specifically focusing on unusual locations or devices.

Okta Alerts Following Unusual Proxy Authentication

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

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

Attack Chain

An attacker obtains valid Okta credentials through phishing, credential stuffing, or other means. (T1078)
The attacker initiates an Okta user session from behind a proxy (VPN, Tor, etc.) to mask their origin.
Okta classifies the connection as originating from a proxy.
The user successfully authenticates and starts a session.
Post-authentication, the attacker attempts to access sensitive applications or data. (T1078.004)
The attacker’s activity triggers an Okta security alert, such as unusual access patterns or MFA bypass attempts.
The detection rule correlates the proxy authentication event with the subsequent security alert.
Security team investigates and responds to the potential account compromise.

Impact

A successful attack can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the organization’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.

Recommendation

Deploy the Sigma rule “Okta Alerts Following Unusual Proxy Authentication” to your SIEM and tune for your environment to detect suspicious activity after proxy authentication.
Investigate correlated security alerts triggered after proxy authentication events for affected users, as highlighted by the Sigma rule.
Monitor Okta system logs for authentication events originating from known malicious proxy IP addresses and block them at the network perimeter.
Review user’s Okta activity for signs of account takeover (MFA changes, new devices, unusual app access) after proxy authentication.
Implement multi-factor authentication (MFA) to reduce the risk of account compromise via stolen credentials, as this attack relies on valid accounts.

Azure AD User Password Reset Detection

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

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

Attack Chain

An attacker gains initial access to a user’s credentials through phishing, credential stuffing, or malware.
The attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.
The attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.
The attacker initiates a password reset request using the “Forgot password” feature or a similar mechanism.
Azure AD sends a password reset verification code or link to the user’s registered email address or phone number.
If the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.
The attacker uses the verification code or link to set a new password for the user’s Azure AD account.
The attacker logs in to the Azure AD account with the new password, gaining unauthorized access.

Impact

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

Recommendation

Deploy the Sigma rule Password Reset By User Account to your SIEM to detect user-initiated password resets in Azure AD audit logs.
Investigate any detected password resets, especially those initiated by users who have not recently requested a password change.
Review and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.
Monitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.

Suspicious PowerShell Execution via Windows Script Host

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

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

Attack Chain

The user receives a phishing email with a malicious attachment (e.g., a .vbs or .js file).
The user opens the attachment, which is processed by either wscript.exe or cscript.exe.
The scripting engine executes the embedded malicious code.
The script downloads a PowerShell script from a remote server or contains an embedded, obfuscated PowerShell command.
The script uses wscript.exe or cscript.exe to launch powershell.exe to execute the downloaded or embedded PowerShell script.
PowerShell executes, performing malicious actions such as downloading additional payloads, modifying system settings, or establishing persistence.
PowerShell attempts to connect to external command-and-control servers to receive further instructions.
The attacker gains initial access to the system and can proceed with lateral movement, data exfiltration, or other malicious activities.

Impact

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

Recommendation

Enable Sysmon process creation logging to capture the necessary event data for the rules below.
Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Investigate process execution chains where cscript.exe or wscript.exe spawn powershell.exe using the provided Sigma rules.
Implement email security measures to block phishing emails with script attachments.
Monitor network connections originating from PowerShell processes for suspicious outbound traffic.

RDP (Remote Desktop Protocol) from the Internet

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

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

Attack Chain

An attacker identifies a publicly accessible RDP service.
The attacker attempts to brute-force RDP login credentials or exploits a known RDP vulnerability (e.g. BlueKeep CVE-2019-0708).
Upon successful authentication or exploitation, the attacker gains remote access to the targeted system.
The attacker uses the compromised system as a pivot point to perform reconnaissance on the internal network.
The attacker moves laterally within the network using stolen credentials or by exploiting other vulnerabilities.
The attacker installs malware or establishes persistence mechanisms (e.g., creating new user accounts or modifying system configurations).
The attacker gathers sensitive data from internal systems.
The attacker exfiltrates the stolen data to an external server or deploys ransomware.

Impact

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

Recommendation

Deploy the “RDP (Remote Desktop Protocol) from the Internet” Sigma rule to your SIEM to detect unauthorized RDP connections from outside the network.
Review 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.
Enable and monitor network traffic logs (category: network_traffic, product: windows|linux|macos) to provide data for the Sigma rule.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address and user accounts involved in the RDP connection.
Implement network segmentation to limit the blast radius of a potential RDP compromise.

Detecting RPC Traffic to the Internet

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

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

Attack Chain

The attacker compromises a host within the internal network, potentially through phishing or exploiting a vulnerability.
The compromised host initiates an RPC connection to an external IP address on TCP port 135.
The attacker uses the RPC connection to enumerate network resources and identify potential targets for lateral movement.
Using the RPC connection, the attacker attempts to authenticate to other systems within the network.
Upon successful authentication, the attacker remotely executes commands on the target system via RPC.
The attacker installs malware or a backdoor on the target system for persistence.
The attacker leverages the established foothold to further propagate within the network, compromising additional systems.

Impact

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

Recommendation

Implement the provided Sigma rule to detect RPC traffic from internal IP ranges to external destinations on TCP port 135, focusing on network traffic logs.
Investigate any alerts generated by the Sigma rule, prioritizing systems exhibiting suspicious RPC activity (Sigma rule, logsource: network_connection).
Ensure that RPC services are not directly exposed to the internet. Implement firewall rules to restrict access to authorized internal IP ranges only.
Continuously monitor network traffic for anomalous RPC activity and correlate with other security events (logsource: network_connection).
Review and update firewall configurations to block unauthorized outbound connections on port 135 (logsource: firewall).

Suspicious Execution via Microsoft Office Add-Ins

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

Attackers 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’s network.

Attack Chain

A user receives a phishing email containing a malicious Microsoft Office document.
The user opens the document, which prompts them to enable macros or install an add-in.
The 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%.
The user executes an Office application (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, MSACCESS.EXE), which loads the malicious add-in.
The malicious add-in executes arbitrary code, potentially downloading and executing a second-stage payload.
The add-in may establish persistence by modifying registry keys or creating scheduled tasks.
The attacker gains initial access to the system and can perform reconnaissance, lateral movement, and data exfiltration.
The attacker achieves their objective, which could include data theft, ransomware deployment, or intellectual property theft.

Impact

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

Recommendation

Deploy the Sigma rule Office Add-In Loaded From Suspicious Path to detect add-ins loaded from temporary or download directories based on process.args and process.name.
Deploy the Sigma rule Office Add-In Loaded By Suspicious Parent to detect add-ins loaded by cmd.exe or powershell.exe based on process.parent.name.
Investigate any instances of VSTOInstaller.exe executing with the /Uninstall argument, as this may indicate suspicious activity, correlating with the exclusion rule in the provided query.
Monitor for Office applications launching add-ins with parent processes of explorer.exe or OpenWith.exe using process creation logs and the provided query logic.
Implement stricter email filtering to prevent phishing emails containing malicious Office documents from reaching end-users.

WebPros cPanel & WHM and WP2 Authentication Bypass Vulnerability (CVE-2026-41940)

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

WebPros cPanel & 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 & 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.

Attack Chain

The attacker identifies a vulnerable cPanel & WHM or WP2 instance.
The attacker crafts a malicious HTTP request exploiting the authentication bypass vulnerability in the login flow.
The request is sent to the target server, bypassing authentication checks.
The server incorrectly processes the request, granting the attacker an authenticated session.
The attacker leverages the authenticated session to access administrative interfaces and settings.
The attacker modifies server configurations, potentially creating new administrative accounts.
The attacker installs malicious plugins or software through the control panel.
The attacker achieves full control over the web server and hosted websites.

Impact

Successful exploitation of CVE-2026-41940 can lead to complete compromise of the affected cPanel & 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 & WHM in web hosting environments. Compromised servers could be leveraged for further attacks against other systems and networks.

Recommendation

Apply mitigations provided by WebPros as detailed in their security update advisory to address CVE-2026-41940.
Deploy the Sigma rule “Detect cPanel/WHM Authentication Bypass Attempt” to identify potential exploitation attempts in web server logs.
If mitigations cannot be immediately applied, follow BOD 22-01 guidance for cloud services, potentially isolating the affected system until patched.
Consider discontinuing use of the affected product if patches or mitigations are unavailable, as advised in the original CISA KEV entry.

Unused Privileged Identity Management (PIM) Roles in Azure

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

This alert identifies a condition where users have been assigned privileged roles within Azure’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.

Attack Chain

An administrator assigns a privileged role to a user within Azure PIM.
The user is granted the role but does not activate or use it to perform any privileged actions.
Azure PIM monitors role usage and detects the lack of activity for the assigned role.
The “redundantAssignmentAlertIncident” event is triggered within the Azure PIM logs.
An attacker gains access to the user’s account through credential compromise or other means.
The attacker activates the unused privileged role.
The attacker leverages the now-active privileged role to perform unauthorized actions, such as modifying system configurations, accessing sensitive data, or escalating privileges further.
The attacker achieves their objective, such as data exfiltration or system compromise, without being detected due to the pre-existing role assignment.

Impact

The 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’s objectives. Failure to identify and address these unused roles can also result in unnecessary license costs and increased attack surface.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect redundantAssignmentAlertIncident events indicating unused PIM roles in Azure (see “Roles Are Not Being Used” rule).
Investigate all detected instances of unused PIM roles to determine the reason for inactivity and potential risks.
Revoke the assigned role if the user no longer requires it, or provide training and guidance to ensure proper role utilization.
Review and refine PIM role assignment policies to minimize the allocation of unnecessary privileges.
Implement regular audits of PIM role assignments to identify and address unused roles promptly.
Configure security alerts within Azure PIM to receive notifications about unused roles and other potential security incidents.

Unauthorized Guest User Invitation Attempt in Azure

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

This 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’s audit logs.

Attack Chain

An internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.
The Azure Active Directory service checks the inviter’s permissions against the organization’s guest invitation policies.
The system determines the user lacks the necessary permissions to invite guest users.
Azure Audit Logs record the “Invite external user” event with a “failure” status.
The failed invitation attempt is blocked, preventing the external user from gaining access.
The attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.
If successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.

Impact

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

Recommendation

Deploy the Sigma rule “Guest User Invited By Non Approved Inviters” to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.
Review and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.
Monitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).

Suspicious MS Office Child Process

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

This 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 cmd.exe, powershell.exe, mshta.exe, wscript.exe, and others being spawned by Office applications.

Attack Chain

A user receives a malicious Microsoft Office document (e.g., Word, Excel) via email or downloads it from a compromised website.
The user opens the document, triggering the execution of a malicious macro or exploitation of a vulnerability within the Office application.
The Office application (e.g., winword.exe, excel.exe) spawns a suspicious child process such as cmd.exe or powershell.exe.
The spawned process executes a command to download a malicious payload from a remote server using bitsadmin.exe or certutil.exe.
The downloaded payload is a reverse shell or a malware dropper, which establishes a connection to an attacker-controlled server.
The attacker gains initial access to the compromised system and attempts to escalate privileges and perform reconnaissance.
The attacker uses discovery commands with net.exe, ipconfig.exe, tasklist.exe, and whoami.exe to map the environment and identify valuable targets.
The 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.

Impact

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

Recommendation

Enable process creation logging (Sysmon Event ID 1 or Windows Security Event Logs) to ensure the visibility required to detect suspicious child processes.
Deploy the Sigma rule Suspicious MS Office Child Process to your SIEM and tune the rule based on your environment to reduce false positives.
Investigate any alerts generated by the Suspicious MS Office Child Process Sigma rule by examining the parent process tree and associated network connections.
Implement application control policies to restrict the execution of unauthorized processes from Microsoft Office applications.
Regularly update Microsoft Office applications to patch known vulnerabilities.
Block known malicious domains or IPs associated with malware delivery and command and control, based on threat intelligence feeds and IOCs from external sources.

Suspicious HTML File Creation Leading to Potential Payload Delivery

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

This 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 (>=5) and large size (>=150,000 bytes) or very large size (>=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., –single-argument, -url). The detection aims to uncover initial access attempts, defense evasion, and user execution of malicious files delivered through HTML smuggling techniques.

Attack Chain

A user receives a phishing email containing a malicious HTML attachment.
The user opens the attachment, triggering the download of a large HTML file to the Downloads folder.
The HTML file contains obfuscated JavaScript code that, when executed, reconstructs a malicious payload (e.g., a Cobalt Strike beacon).
The file is saved with an .htm or .html extension in a temporary or download directory.
A browser process (chrome.exe, firefox.exe, etc.) is initiated to open the HTML file, often with specific arguments like “–single-argument” or “-url”.
The browser renders the HTML, executing the embedded JavaScript.
The JavaScript deobfuscates and executes the smuggled payload, initiating a reverse shell connection to a command-and-control server.
The attacker gains initial access to the compromised system and can proceed with lateral movement or data exfiltration.

Impact

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

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM and tune the file path and browser process filters for your environment.
Enable file integrity monitoring (FIM) on common download and temporary directories to detect the creation of suspicious HTML files as described in the Sigma rules.
Implement network egress filtering to block connections to known malicious command-and-control servers and domains to prevent payload execution.
Educate users about the risks of opening attachments from untrusted sources and train them to recognize phishing emails as outlined in the Overview.
Utilize endpoint detection and response (EDR) solutions to monitor process execution and network connections for anomalous behavior associated with HTML smuggling.

Suspicious Execution from VS Code Extension

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

A 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 .vscode/extensions/ 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.

Attack Chain

A user installs a malicious VS Code extension.
The extension is configured with activationEvents: ["onStartupFinished"] to run automatically when VS Code starts.
The VS Code extension host (Code.exe or node.exe) spawns a script interpreter (e.g., powershell.exe, cmd.exe) from within the .vscode/extensions/ directory.
The script interpreter executes a command to download a malicious payload from a remote server using tools like curl.exe, bitsadmin.exe, or mshta.exe.
The downloaded payload is saved to disk, often in a temporary directory outside of Program Files.
The script interpreter executes the downloaded payload, leading to further malicious activity. For example, ScreenConnect might be installed.
Persistence mechanisms are established (e.g., via registry keys or scheduled tasks).
The attacker gains remote access to the compromised system.

Impact

A successful attack can lead to the complete compromise of a developer’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.

Recommendation

Deploy the “Suspicious Execution from VS Code Extension” Sigma rule to your SIEM to detect malicious process execution from VS Code extensions.
Monitor process creation events for script interpreters and LOLBins spawned from the .vscode/extensions/ directory.
Implement application control policies to restrict the execution of unsigned or untrusted executables.
Regularly review and audit installed VS Code extensions for suspicious activity or unnecessary permissions.
Educate developers about the risks of installing extensions from untrusted sources.
Block the C2 domains associated with ScreenConnect and other RATs at the firewall/DNS resolver.

Execution from Removable Media with Network Connection

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

This 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’s environment. The detection logic is based on Elastic Defend telemetry.

Attack Chain

An attacker copies malware onto a USB drive from an infected system.
The attacker physically inserts the USB drive into a target Windows system.
The 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.
The executed process, now running on the target system, lacks a valid code signature, raising suspicion.
The malicious process attempts to establish a network connection, potentially to a command and control server or to exfiltrate data.
The network connection attempt is logged, capturing details about the destination IP address and port.
The attacker gains initial access to the system and can potentially perform reconnaissance, privilege escalation, or lateral movement.

Impact

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

Recommendation

Enable process creation and network connection logging to detect this type of activity (logs-endpoint.events.process-* and logs-endpoint.events.network-*).
Deploy the Sigma rule “Execution from a Removable Media with Network Connection” to your SIEM and tune for your environment.
Disable Autorun features on all systems to prevent automatic execution of programs from removable media.

Detection of Privileged Account Creation in Azure

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

This 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 “Add user” and “Add member to role” events within Azure audit logs.

Attack Chain

An attacker gains initial access to an Azure environment, possibly through compromised credentials (T1078.004).
The attacker leverages their access to enumerate existing accounts and roles within the Azure Active Directory.
The attacker attempts to create a new user account with elevated privileges, such as Global Administrator or other custom administrative roles.
The 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 “Add member to role”.
The attacker uses the newly created privileged account to perform reconnaissance, identify sensitive data, or deploy malicious applications.
The attacker establishes persistence by maintaining access through the newly created account, even if the initial entry point is detected and remediated.
The attacker escalates privileges to gain control over critical resources and services within the Azure environment.
The attacker uses the privileged account to exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect privileged account creation events within Azure Audit Logs.
Investigate any detected instances of privileged account creation to determine whether the activity is legitimate.
Implement multi-factor authentication (MFA) for all user accounts, especially those with privileged roles, to mitigate the risk of credential compromise (T1110).
Regularly review and audit user account privileges to identify and remove unnecessary or excessive permissions.
Monitor Azure Audit Logs for suspicious activities, such as unusual sign-in attempts, changes to security settings, and modifications to privileged roles.
Implement alerting for changes to privileged roles and groups within Azure AD.

Azure Subscription Permission Elevation via Activity Logs

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

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

Attack Chain

The attacker gains initial access to an Azure account, potentially through compromised credentials (T1078.004).
The attacker authenticates to the Azure portal or uses Azure CLI/PowerShell with the compromised account.
The attacker attempts to elevate their permissions using the MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION operation.
Azure Activity Logs record the attempt to elevate permissions.
If successful, the attacker gains management access to all Azure subscriptions within the tenant.
The attacker can then provision resources, modify configurations, and access data within those subscriptions.
The attacker might establish persistence by creating new user accounts with elevated privileges or modifying existing roles.
The attacker can then exfiltrate sensitive data or disrupt services within the Azure environment.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION operations in Azure Activity Logs.
Investigate any detected instances of MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION immediately, as outlined in the rule description.
Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.
Review and enforce the principle of least privilege for Azure role assignments.
Monitor Azure Activity Logs for other suspicious activities, such as unusual resource creation or modification.

AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

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

This detection rule identifies instances of successful AWS AssumeRoleWithWebIdentity 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 Amazon.com, Inc.), 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.

Attack Chain

Attacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.
Attacker exfiltrates the service account token from the Kubernetes cluster.
The attacker uses the exfiltrated token to call the AWS STS AssumeRoleWithWebIdentity API.
The AssumeRoleWithWebIdentity call is made from a network with an ASN organization name that is not Amazon.com, Inc..
AWS CloudTrail logs the successful AssumeRoleWithWebIdentity event, including details about the user, source IP, and ASN organization.
The compromised IAM role is used to perform unauthorized actions within the AWS environment.
These actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.

Impact

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

Recommendation

Deploy the Sigma rule AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule by following the investigation steps in the rule’s note field.
Expand the source.as.organization.name exclusions in the Sigma rule for known and trusted egress paths if needed.
Enable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of AssumeRoleWithWebIdentity calls.
Regularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.
Revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.

Azure AD Account Created and Deleted Within a Close Time Frame

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

The 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’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.

Attack Chain

An attacker gains initial access to an Azure AD environment, potentially through compromised credentials or a phishing attack.
The attacker creates a new user account within the Azure AD. This can be achieved through the Azure portal, PowerShell, or the Azure CLI.
The 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.
The attacker uses the newly created account to perform malicious activities, such as accessing confidential data, modifying system configurations, or deploying malicious applications.
After completing the malicious tasks, the attacker removes the elevated privileges from the account to reduce the chances of detection during privilege reviews.
The attacker deletes the created account from Azure AD. This step is performed to remove the traces of the account’s existence and hinder forensic investigations.
The 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.
The attacker aims to maintain stealth and evade detection while gaining unauthorized access to resources or establishing persistence within the Azure AD environment.

Impact

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

Recommendation

Deploy the Sigma rule “Account Created And Deleted Within A Close Time Frame” to your SIEM and tune for your environment to detect suspicious account creation/deletion events in Azure AD audit logs.
Investigate any alerts generated by the Sigma rule “Account Created And Deleted Within A Close Time Frame” to determine the scope and impact of the potential compromise.
Implement multi-factor authentication (MFA) for all user accounts, especially those with elevated privileges, to reduce the risk of credential compromise (reference: attack.initial-access).
Regularly review Azure AD audit logs for unusual account activity, focusing on accounts created and deleted within a short timeframe (logsource: azure, service: auditlogs).

AWS Root Account Usage Detected

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

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

Attack Chain

An attacker gains access to the AWS root account credentials through credential theft or other means.
The attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.
The attacker enumerates AWS resources to identify potential targets for privilege escalation.
The attacker creates or modifies IAM policies to grant themselves additional permissions.
The attacker may create new IAM users or roles with elevated privileges.
The attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.
The attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.
The attacker could disable logging features to cover tracks.

Impact

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

Recommendation

Deploy the Sigma rule “AWS Root Credentials” to your SIEM to detect root account usage based on CloudTrail logs.
Investigate all instances of root account usage identified by the “AWS Root Credentials” Sigma rule to determine legitimacy.
Enforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in AWS documentation.
Implement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.
Regularly audit IAM policies and user permissions to identify and remove unnecessary privileges.
Disable or restrict root account access wherever possible, delegating tasks to IAM users/roles.

SMB (Windows File Sharing) Activity to the Internet

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

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

Attack Chain

An internal host is compromised, often through phishing or other social engineering techniques.
The compromised host attempts to establish an SMB connection to an external IP address on TCP ports 139 or 445.
The attacker leverages the SMB protocol to attempt authentication, potentially exploiting vulnerabilities like credential stuffing or known SMB exploits.
Upon successful authentication or exploitation, the attacker gains unauthorized access to shared resources or system services on the external system.
The attacker may upload malicious payloads, such as malware or backdoors, via the SMB connection to the external host.
The attacker uses the SMB protocol to exfiltrate sensitive data from the internal network to the external system.
The attacker maintains persistence on the compromised internal host, using SMB for command and control or lateral movement.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect SMB traffic to the internet and tune for your environment.
Review 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.
Investigate 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.
Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs to prevent false positives, as mentioned in the investigation guide.

First Time Seen Removable Device Registry Modification

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

This 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 “FriendlyName” value associated with USB storage devices (“USBSTOR”). 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.

Attack Chain

A user connects a removable device (e.g., USB drive) to a Windows system.
The operating system detects the new device and attempts to enumerate its properties.
The system queries the registry for device-specific settings, including the “FriendlyName,” under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR key.
If the device is new to the system, the registry is modified to record the device’s information, including its friendly name.
The event generates a registry modification event, which is logged by Sysmon, Elastic Defend, Microsoft Defender XDR, or SentinelOne.
An attacker may use the USB device to deploy malware or exfiltrate sensitive data.
The attacker copies files to the USB device.
The attacker removes the USB device, completing the exfiltration.

Impact

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

Recommendation

Enable Sysmon registry event logging to detect registry modifications related to USB devices and activate the Sigma rules below.
Deploy the Sigma rules provided to your SIEM to detect and monitor first-time seen USB devices.
Investigate any alerts generated by the Sigma rules, correlating with user activity and file access events.
Maintain 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.
Monitor for subsequent file access or transfer events involving the new device as described in the rule documentation.

Unauthorized Guest User Invitations in Azure AD

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

This 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’s Azure environment. It is important to ensure that only authorized personnel can invite external users to maintain security and prevent potential abuse.

Attack Chain

An attacker compromises a low-privilege user account within the Azure AD tenant or uses existing compromised credentials.
The attacker attempts to invite an external guest user to the tenant using the compromised account.
The Azure AD audit logs record the “Invite external user” operation under the UserManagement category.
The audit log event is generated, capturing details such as the user who initiated the invitation (InitiatedBy) and the target guest user’s information.
The detection logic evaluates if the InitiatedBy user is within the list of approved guest inviters.
If the inviting user is not on the approved list, the detection rule triggers, indicating a potentially unauthorized guest invitation.
The attacker may then attempt to leverage the newly invited guest account for lateral movement or data exfiltration.
The attacker uses the guest account to access resources and data within the Azure AD environment, potentially leading to data breaches or other security incidents.

Impact

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

Recommendation

Implement the provided Sigma rule to detect unauthorized guest user invitations in Azure AD audit logs and tune the filter with a list of approved inviters.
Review and restrict the number of users authorized to invite guest users to the Azure AD tenant based on business needs.
Implement multi-factor authentication (MFA) for all user accounts, including guest accounts, to prevent unauthorized access (related to audit logs).
Regularly audit Azure AD logs for any suspicious activity related to user management (related to audit logs).

Suspicious Explorer Child Process via DCOM

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

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

Attack Chain

The attack begins with an initial access vector such as spearphishing (T1566).
A user clicks a malicious link or opens an attachment, leading to code execution.
The initial payload exploits explorer.exe through DCOM using the -Embedding argument.
Explorer.exe spawns a child process such as powershell.exe, cmd.exe, or mshta.exe (T1059, T1218).
The spawned process executes malicious commands or scripts.
These commands might download or execute additional payloads.
The attacker achieves code execution, potentially gaining persistence on the system.
The ultimate objective is often lateral movement, data exfiltration, or deploying ransomware.

Impact

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

Recommendation

Enable process creation logging with command line details to detect suspicious explorer.exe child processes.
Deploy the Sigma rule “Suspicious Explorer Child Process - PowerShell” to identify instances of PowerShell spawned by explorer.exe with suspicious arguments.
Deploy the Sigma rule “Suspicious Explorer Child Process - Scripting Engines” to detect other scripting engines launched by explorer.exe.
Monitor 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 “-Embedding” via process creation logs.
Implement application control policies to restrict execution of unsigned or untrusted scripts and executables.

Masquerading Business Application Installers

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

Attackers 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’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.

Attack Chain

The user visits a compromised website or clicks on a malicious advertisement.
The user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.
The downloaded executable is placed in the user’s Downloads folder (e.g., C:\Users*\Downloads*).
The user executes the downloaded file.
The executable, lacking a valid code signature, begins execution.
The malicious installer may drop and execute additional malware components.
The malware establishes persistence, potentially using techniques such as registry key modification.
The malware performs malicious activities, such as data exfiltration or lateral movement.

Impact

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

Recommendation

Implement the Sigma rule Potential Masquerading as Business App Installer to detect unsigned executables resembling legitimate business applications in download directories.
Enable process creation logging to capture the execution of unsigned executables.
Educate users on the risks of downloading and executing files from untrusted sources.
Implement application whitelisting to restrict the execution of unauthorized applications.
Regularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.
Monitor process execution events for processes originating from the Downloads folder that lack valid code signatures.

Detection of Office Macro File Creation

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

The 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’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.

Attack Chain

An attacker crafts a malicious Office document (e.g., .docm, .xlsm) containing a VBA macro.
The attacker sends the malicious document as an attachment via email (spearphishing).
The user receives the email and opens the attached Office document.
The user is prompted to enable macros within the document.
If the user enables macros, the embedded VBA code executes.
The VBA code may execute PowerShell or other scripting languages to download a malicious payload.
The downloaded payload is saved to disk (e.g., in the user’s temp directory).
The payload executes, establishing persistence or performing other malicious actions, such as ransomware deployment.

Impact

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

Recommendation

Deploy the Sigma rule Office Macro File Creation to your SIEM to detect the creation of suspicious Office macro files (logsource: file_event/windows).
Investigate any alerts generated by the Sigma rule, focusing on the parent processes of the file creation event.
Implement user awareness training to educate employees about the risks of opening unsolicited attachments and enabling macros.
Enable Sysmon file creation logging to capture the necessary events for the Sigma rule to function effectively.

Azure Domain Federation Settings Modified

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

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

Attack Chain

The 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.
The attacker authenticates to the Azure portal or uses PowerShell/CLI to interact with Azure resources.
The attacker enumerates existing domain federation settings to understand the current configuration and identify potential targets for modification.
The attacker modifies the federation settings on the domain using commands like Set-MsolDomainFederationSettings or through the Azure portal interface. This may involve altering the trusted certificate, changing the issuer URI, or modifying other federation parameters.
The attacker tests the modified federation settings to ensure they can successfully authenticate using the altered configuration.
The attacker leverages the modified federation settings to impersonate users or applications, gaining unauthorized access to protected resources and services.
The attacker establishes persistence by creating backdoors or alternate authentication methods using the modified federation settings.

Impact

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

Recommendation

Implement the Sigma rule “Azure Domain Federation Settings Modified” to detect suspicious modifications to federation settings in Azure audit logs.
Regularly review and validate changes to Azure domain federation settings, focusing on unfamiliar users and unexpected modifications.
Monitor Azure audit logs for the “Set federation settings on domain” event to identify potential tampering.
Enforce multi-factor authentication (MFA) for all accounts with administrative privileges to reduce the risk of unauthorized access.
Implement the principle of least privilege, granting users only the necessary permissions to perform their tasks.

Suspicious MS Outlook Child Process

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

This 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’s machine. The rule focuses on identifying processes such as cmd.exe, powershell.exe, 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.

Attack Chain

A user receives a spear phishing email with a malicious attachment (e.g., a Microsoft Office document or PDF).
The user opens the attachment, unknowingly triggering embedded malicious code (e.g., macros or exploits).
The malicious code executes within the context of Microsoft Outlook (outlook.exe).
The malicious code spawns a suspicious child process, such as cmd.exe, powershell.exe, mshta.exe, or wscript.exe.
The spawned process executes commands to download and execute further malicious payloads from external sources.
The downloaded payload establishes persistence on the compromised system.
The attacker gains initial access and begins reconnaissance activities.
The attacker moves laterally within the network, escalating privileges and compromising additional systems.

Impact

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

Recommendation

Deploy the Sigma rule “Suspicious MS Outlook Child Process Spawning Command Interpreter” to your SIEM to detect potential initial access attempts (see rule below).
Enable Sysmon process creation logging (Event ID 1) to provide the necessary data for the Sigma rules.
Block the execution of commonly abused system binaries (e.g., cmd.exe, powershell.exe, wscript.exe) as child processes of Outlook using application control policies where possible.
Implement and enforce strict macro policies in Microsoft Office applications to prevent the execution of malicious code within documents.
Regularly review and update email security policies to prevent spear phishing emails from reaching users.