Reconnaissance — CraftedSignal Threat Feed

Rapid Enumeration of AWS S3 Buckets

hello@craftedsignal.io — Fri, 01 May 2026 19:43:38 +0000

This threat brief covers suspicious activity related to the rapid enumeration of AWS S3 buckets. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs from the same source IP address within a short timeframe. This pattern is often associated with reconnaissance efforts, security scanning tools, or post-compromise enumeration activities. The behavior is similar to that observed with CSPM tools and by threat actors like Team PCP. The detection specifically excludes AWS service principals and requires programmatic-style sessions (i.e., not Management Console credentials). It focuses on scenarios where resource and identity fields are populated to avoid skewed results from null values. The detection threshold is set to greater than 15 distinct aws.cloudtrail.resources.arn values within a 10-second window.

Attack Chain

An attacker gains initial access to an AWS environment using compromised credentials or through an exposed IAM role. (T1530)
The attacker authenticates to AWS using the obtained credentials, creating a programmatic session.
The attacker issues a series of GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning API calls to S3.
These API calls are directed towards multiple distinct S3 buckets within a short timeframe (10 seconds).
The attacker collects information about the bucket’s access control lists (ACLs), public access blocks, policies, versioning status, and other metadata. (T1526, T1580, T1619)
The collected information is analyzed to identify publicly accessible buckets, misconfigurations, or sensitive data storage locations.
The attacker uses identified vulnerabilities to exfiltrate data.
The attacker attempts lateral movement within the AWS environment, leveraging the discovered information to compromise other resources.

Impact

Successful enumeration of S3 buckets can lead to the discovery of sensitive data, misconfigurations, and publicly accessible resources. This can result in data breaches, unauthorized access, and further compromise of the AWS environment. The enumeration allows an attacker to map out the S3 storage landscape, identifying targets for data exfiltration or privilege escalation. The rapid nature of the enumeration suggests automated scanning or reconnaissance, potentially indicating a larger attack campaign.

Recommendation

Deploy the following Sigma rule to detect rapid S3 bucket enumeration activity based on AWS CloudTrail logs, adjusting the threshold of 15 distinct buckets to suit your environment.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address (source.ip), AWS principal ARN (aws.cloudtrail.user_identity.arn), and the list of accessed buckets (aws.cloudtrail.resources.arn).
Review IAM policies associated with the identified principal to ensure least privilege for S3 read APIs.
Monitor CloudTrail logs for related events, such as ListBuckets, GetObject, PutBucketPolicy, AssumeRole, or IAM changes, occurring within ±30 minutes of the detected enumeration activity.
Implement network-level restrictions on the source IP address if it is not authorized to perform S3 enumeration.
Document approved scanning accounts and add user agent filters to the provided Sigma rule to reduce noise from those identities.

AWS S3 Rapid Bucket Posture API Calls Indicate Reconnaissance

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

This threat brief details detection of rapid enumeration of AWS S3 bucket configurations. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs across numerous buckets within a short timeframe. This pattern is consistent with automated reconnaissance, security scanning, or post-compromise enumeration. The activity is detected by monitoring AWS CloudTrail logs for specific API calls such as GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning. The detection logic excludes AWS service principals and sessions using Management Console credentials to reduce false positives. This activity is relevant for defenders as it can signal early-stage reconnaissance by threat actors like Team PCP, or unauthorized data discovery within the AWS environment. The rule uses a threshold of 15 distinct buckets accessed within 10 seconds to identify suspicious behavior.

Attack Chain

An attacker gains access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
The attacker uses the acquired credentials to authenticate to the AWS environment.
The attacker executes a script or tool that calls multiple S3 APIs (e.g., GetBucketAcl, GetBucketPolicy) to gather information about S3 buckets.
The tool iterates through a list of buckets, querying the configuration of each.
The attacker collects the responses from the S3 API calls, mapping out bucket names, permissions, and access control lists.
The attacker analyzes the collected data to identify potentially sensitive data or misconfigured buckets.
Based on the findings, the attacker may proceed to exfiltrate data from accessible buckets (T1530).
The attacker may also attempt to modify bucket policies or access controls to gain further access or persistence.

Impact

Successful reconnaissance of S3 bucket configurations allows attackers to identify vulnerable buckets, potentially leading to data breaches or unauthorized access to sensitive information. The source material does not provide specific victim counts or sectors. However, the impact can range from exposure of confidential data to full compromise of the AWS environment, depending on the level of access gained and the sensitivity of the data stored in the targeted buckets. Identifying the activity early can prevent further exploitation.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect rapid S3 bucket posture API calls (see: “AWS S3 Rapid Bucket Enumeration”).
Review IAM policies and enforce least privilege on S3 read APIs to limit the scope of potential reconnaissance activities.
Monitor CloudTrail logs for the same aws.cloudtrail.user_identity.arn and source.ip within approximately ±30 minutes for follow-on patterns such as ListBuckets, GetObject, PutBucketPolicy, or AssumeRole activities (see Overview).
Rotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized (see Overview).
Whitelist approved scanning accounts and tune the Sigma rule to reduce noise from those identities (see Overview).

OpenCanary Telnet Login Attempt

hello@craftedsignal.io — Sat, 26 Oct 2024 14:30:00 +0000

OpenCanary is a low-interaction honeypot designed to detect attackers on a network. This detection focuses on Telnet login attempts, a protocol rarely used legitimately in modern networks and thus a strong indicator of malicious activity. When an attacker attempts to log into a Telnet service on an OpenCanary node, it triggers this alert. This provides early warning of potential intrusion attempts, reconnaissance activities, or lateral movement by attackers who have already gained a foothold. The detection is based on OpenCanary’s logging functionality which records such login attempts, generating a log event with code 6001. This event signifies an attacker interacting with the Telnet service, which is unlikely in a well-secured and properly configured environment.

Attack Chain

Attacker scans the network for open ports, identifying a Telnet service.
Attacker attempts to connect to the Telnet service on the OpenCanary node.
Attacker enters credentials (username and password) in an attempt to authenticate.
OpenCanary logs the Telnet login attempt, generating an event with logtype 6001.
The detection rule triggers based on the OpenCanary log event.
Security team investigates the alert to determine the source and intent of the Telnet login attempt.
If the attempt is malicious, the security team takes steps to block the attacker and prevent further access.

Impact

A successful Telnet login could provide an attacker with unauthorized access to the network or specific systems. While Telnet itself may not grant immediate access to sensitive data, it can be used as a stepping stone for further exploitation and lateral movement. The compromise of even a single system can lead to data breaches, ransomware deployment, and significant disruption of services. OpenCanary serves as an early warning system, allowing defenders to identify and respond to such attempts before significant damage occurs.

Recommendation

Deploy the Sigma rule OpenCanary - Telnet Login Attempt to your SIEM to detect unauthorized Telnet login attempts.
Investigate any alerts generated by the OpenCanary - Telnet Login Attempt rule to determine the source and intent of the connection.
Review the OpenCanary configuration to ensure it is properly deployed and monitoring the appropriate network segments.
Consider disabling the Telnet service on all legitimate systems on the network to reduce the attack surface.

OpenCanary SSH Connection Attempt

hello@craftedsignal.io — Wed, 08 May 2024 14:30:00 +0000

The OpenCanary SSH Connection Attempt alert signifies that an SSH service on a deployed OpenCanary node has received a connection attempt. OpenCanary is a low-interaction honeypot designed to detect reconnaissance and lateral movement activities within a network. This event, logged as logtype 4000 by default, suggests that an attacker is actively scanning for or attempting to exploit SSH services. This alert is crucial for defenders because OpenCanary nodes are deliberately placed to attract malicious activity, meaning any interaction is highly suspicious. The alert helps identify potential breaches early, allowing security teams to respond quickly. The configuration of services monitored by OpenCanary is detailed in the project’s documentation.

Attack Chain

Initial Reconnaissance: The attacker conducts network scanning using tools like Nmap or Masscan to identify open ports and services, including SSH (port 22).
Target Identification: The attacker identifies the OpenCanary node, mistaking it for a legitimate SSH server, due to its exposed SSH port.
Connection Attempt: The attacker attempts to establish an SSH connection to the OpenCanary node using a tool like ssh or a custom script.
Authentication Probe: The attacker might attempt to authenticate using default credentials, common usernames and passwords, or brute-force techniques.
Credential Compromise (Simulated): The OpenCanary node logs the failed or successful (simulated) login attempt, triggering the alert. OpenCanary may simulate a successful login for further interaction logging.
Lateral Movement (Attempted): If the attacker believes they have successfully authenticated, they may attempt lateral movement to other systems within the network.
Privilege Escalation (Attempted): The attacker could attempt to escalate privileges on the “compromised” system (OpenCanary) to gain further access.
Data Exfiltration/System Damage (Prevented): Because it’s a honeypot, OpenCanary prevents actual data exfiltration or system damage but logs all attempted actions for analysis.

Impact

An SSH connection attempt on an OpenCanary node, while not directly causing damage, indicates active reconnaissance or attempted unauthorized access within the network. The number of alerts generated can highlight the frequency of malicious scans targeting SSH services. Successful exploitation (simulated on the honeypot) could lead to lateral movement, privilege escalation, and data exfiltration if the attacker were to compromise a real system. This activity is valuable for understanding attacker behavior and improving overall security posture.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect SSH connection attempts to OpenCanary nodes, focusing on logtype: 4000.
Review OpenCanary logs in conjunction with other security logs (firewall, endpoint) to correlate the SSH attempts with other suspicious activities.
Investigate the source IP addresses from which SSH connection attempts originate to identify potential threat actors.
Consult the OpenCanary documentation to ensure proper configuration of the SSH service and logging capabilities.
Use network segmentation to limit the potential impact of a successful breach, even if only simulated on the OpenCanary node.

Kubernetes Multi-Resource Discovery Reconnaissance

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

After gaining initial access to a Kubernetes cluster, adversaries often conduct reconnaissance to understand the environment before further actions like exfiltration or privilege escalation. This involves mapping the cluster’s structure, identifying workloads, and understanding role-based access control (RBAC) configurations. This reconnaissance is achieved by rapidly querying various API resources, including namespaces, pods, roles, ClusterRoles, ConfigMaps, and ServiceAccounts. The activity is characterized by a burst of get and list requests across multiple resource types within a short timeframe, which is atypical for normal cluster operations and may indicate malicious probing or permission reconnaissance. This detection focuses on identifying such cross-resource bursts from a single client to distinguish reconnaissance activities from routine automation.

Attack Chain

The attacker gains initial access to the Kubernetes cluster using compromised credentials or by exploiting a vulnerability. (T1190, T1566)
The attacker authenticates to the Kubernetes API server using the compromised credentials or a valid service account token.
The attacker begins enumerating namespaces to understand the logical divisions within the cluster using kubectl get namespaces or equivalent API calls. (T1068)
The attacker queries pods within the discovered namespaces to identify running workloads and potential targets. (T1068)
The attacker lists roles and cluster roles to understand the existing RBAC configurations and identify potential privilege escalation opportunities. (T1069)
The attacker retrieves service accounts to identify applications and their associated permissions, potentially discovering more attack vectors.
The attacker analyzes the collected information to identify vulnerable services, misconfigured permissions, or sensitive data.
Based on the reconnaissance, the attacker proceeds with lateral movement, privilege escalation, data exfiltration, or other malicious objectives.

Impact

Successful reconnaissance allows attackers to gain a comprehensive understanding of the Kubernetes environment, facilitating further malicious activities such as lateral movement, privilege escalation, and data exfiltration. This can lead to the compromise of sensitive data, disruption of services, and unauthorized access to critical resources. The impact is magnified in clusters with weak RBAC policies or exposed sensitive information.

Recommendation

Deploy the Sigma rule “Kubernetes Multi-Resource Discovery” to your SIEM and tune for your environment to detect reconnaissance activities.
Investigate alerts generated by the Sigma rule by pivoting on user.name, source.ip, and user_agent.original to determine the sequence of API calls.
Correlate the identified activity with RBAC configurations to identify potential violations of the principle of least privilege as described in the rule’s Triage and Analysis section.
Baseline automation by allowlisting known service accounts or source networks that legitimately span multiple resource types in a short window, as described in the rule’s False Positive Analysis section.
Review and tighten RBAC configurations to minimize the impact of compromised credentials as described in the Response and Remediation section.

Detection of Obfuscated IP Addresses via Command Line Tools

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

Attackers may attempt to obscure their activities by using obfuscated IP addresses within command-line tools. This is done to bypass simple pattern matching or detection rules that rely on standard IP address formats. The Sigma rule “Obfuscated IP Via CLI” published on 2022-08-03 and modified on 2026-03-16, focuses on detecting this behavior by identifying command lines containing hexadecimal, octal, or other encoded representations of IP addresses used with ping.exe or arp.exe. This activity can indicate reconnaissance, command and control communication, or lateral movement attempts where attackers are trying to hide the true destination of their network traffic.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker opens a command prompt (cmd.exe) or PowerShell.
The attacker uses ping.exe or arp.exe to test network connectivity.
The attacker crafts a command line that includes an obfuscated IP address (e.g., hexadecimal, octal). For example: ping 0121.04.0174.012
The command is executed, attempting to resolve or connect to the obfuscated IP address.
If the obfuscation bypasses security controls, the tool resolves the address.
The attacker gathers information about the target system (if ping is successful) or network.
The attacker uses this information for further exploitation or lateral movement.

Impact

Successful exploitation of obfuscated IPs can lead to undetected reconnaissance, lateral movement, and data exfiltration. By hiding the true destination of network traffic, attackers can bypass traditional security measures and gain a foothold within the network. The impact includes potential data breaches, system compromise, and disruption of services.

Recommendation

Deploy the “Obfuscated IP Via CLI” Sigma rule to your SIEM to detect command-line execution with obfuscated IP addresses.
Enable process creation logging for ping.exe and arp.exe to ensure the Sigma rule has the necessary data.
Investigate any alerts generated by the Sigma rule to determine if the activity is malicious.
Implement network segmentation to limit the scope of potential lateral movement.
Monitor command-line activity for unusual patterns or arguments.

Active Directory Discovery via ADExplorer Execution

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

ADExplorer is an advanced Active Directory (AD) viewer and editor, it includes the ability to save snapshots of an AD database for offline viewing and comparisons. Adversaries may abuse this utility to perform domain reconnaissance, gather sensitive information about the AD structure, user accounts, and group memberships. The execution of ADExplorer is a potential indicator of malicious activity, especially when observed in environments where its use is not typical or when executed by unauthorized users. This activity can lead to further exploitation, such as privilege escalation and lateral movement within the network.

Attack Chain

An attacker gains initial access to a Windows system through various means (e.g., compromised credentials, phishing).
The attacker downloads the ADExplorer utility (ADExplorer.exe) to the compromised host.
The attacker executes ADExplorer.exe to begin enumeration of the Active Directory environment.
ADExplorer interacts with the Active Directory domain controllers, querying information about users, groups, computers, and organizational units.
The attacker may use ADExplorer to save snapshots of the AD database for offline analysis.
The attacker analyzes the gathered information to identify privileged accounts, critical assets, and potential vulnerabilities within the AD environment.
The attacker uses the discovered information to plan further attacks, such as lateral movement or privilege escalation.

Impact

Successful execution of ADExplorer by malicious actors can lead to the discovery of sensitive information about the Active Directory environment. This information can be leveraged to facilitate lateral movement, privilege escalation, and data exfiltration. While the initial risk score is low, the reconnaissance activity enables follow-on attacks that can have severe consequences, potentially leading to full domain compromise.

Recommendation

Implement the Sigma rule Detect ADExplorer Execution via Process Name to detect the execution of ADExplorer based on process name.
Implement the Sigma rule Detect ADExplorer Execution via Original File Name to detect the execution of ADExplorer based on the process’s original file name.
Monitor process creation events on Windows endpoints for the execution of ADExplorer.exe or processes with an original file name of “AdExp” to detect potential reconnaissance activities.
Investigate and validate any execution of ADExplorer by non-administrator accounts.
Review ADExplorer use and restrict its usage to authorized personnel.

Suspicious PowerShell Reconnaissance via WMI Queries

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

This brief focuses on detecting reconnaissance activities performed through PowerShell using WMI queries. Adversaries often use WMI to gather detailed information about a compromised system, including hardware specifications, operating system details, and installed software. This information can be used to plan further attacks, such as privilege escalation or lateral movement. This detection leverages PowerShell Script Block Logging (EventCode 4104) to identify specific WMI queries that target system information classes like Win32_Bios, Win32_OperatingSystem, Win32_Processor and others. Identifying this behavior early can help defenders disrupt attack chains before significant damage occurs. The analytic is based on the detection logic from the Splunk Security Content project as of April 2026.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
The attacker executes a PowerShell script, either directly or via a command-line interpreter like cmd.exe.
The PowerShell script uses the Get-WmiObject cmdlet or a direct WMI query with SELECT to query system information.
Specific WMI classes are targeted, including Win32_Bios, Win32_OperatingSystem, Win32_Processor, Win32_ComputerSystem, Win32_PnPEntity, Win32_ShadowCopy, Win32_DiskDrive, Win32_PhysicalMemory, Win32_BaseBoard, and Win32_DisplayConfiguration.
The script collects the data returned by the WMI queries.
The gathered information is used to profile the system and identify potential vulnerabilities or weaknesses.
The attacker uses the gathered information to plan subsequent stages of the attack, like lateral movement or privilege escalation.
The attacker executes further commands based on the gathered information.

Impact

Successful reconnaissance can provide attackers with a comprehensive understanding of the target environment, enabling them to tailor their attacks for maximum impact. This can lead to successful privilege escalation, lateral movement, data exfiltration, or ransomware deployment. Organizations that fail to detect and prevent reconnaissance activities are at a higher risk of experiencing significant data breaches and financial losses. The Maze ransomware group, Industroyer2, and LockBit ransomware have been observed using similar reconnaissance techniques.

Recommendation

Enable PowerShell Script Block Logging on all endpoints to capture the necessary data for detection (PowerShell Script Block Logging 4104).
Deploy the Sigma rule Detect Suspicious WMI Reconnaissance via PowerShell to identify PowerShell scripts querying sensitive WMI classes.
Investigate any alerts generated by the Sigma rule, focusing on the user and process context to determine potential malicious intent.
Review and tune the Recon Using WMI Class detection filter (recon_using_wmi_class_filter) to reduce false positives in your environment.

AdFind Tool Used for Active Directory Reconnaissance

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

AdFind is a command-line tool used to retrieve information from Active Directory. While it has legitimate uses for network administrators, threat actors frequently leverage it for post-exploitation Active Directory reconnaissance. The tool allows for quick scoping of AD person/computer objects and understanding subnets and domain information. AdFind has been observed in campaigns associated with various threat actors, including Trickbot, Ryuk, Maze, and FIN6. This reconnaissance activity is typically conducted after initial compromise to gather information for lateral movement and privilege escalation. The detection of AdFind execution, especially with specific command-line arguments, can indicate malicious activity within a compromised environment.

Attack Chain

Initial Access: An attacker gains initial access to a Windows host, possibly through exploitation of a vulnerability or compromised credentials.
Tool Transfer: The attacker transfers AdFind.exe to the compromised host.
Execution: The attacker executes AdFind.exe from the command line or via a script.
Discovery: AdFind is used to enumerate Active Directory objects such as computers (objectcategory=computer), users (objectcategory=person), subnets (objectcategory=subnet), and groups (objectcategory=group).
Information Gathering: The attacker gathers information about domain controllers using commands such as dclist or dcmodes.
Privilege Escalation: The gathered information is used to identify potential targets for privilege escalation, such as accounts with weak passwords or misconfigured permissions.
Lateral Movement: The attacker uses the gathered information to move laterally to other systems within the network.
Objective Completion: The attacker achieves their final objective, such as data exfiltration or ransomware deployment.

Impact

Successful reconnaissance using AdFind can provide attackers with a comprehensive understanding of the Active Directory environment, facilitating lateral movement, privilege escalation, and ultimately, the exfiltration of sensitive data or deployment of ransomware. While the use of AdFind itself may not be directly damaging, it is a strong indicator of malicious activity within a compromised network. The impact can range from data breaches and financial losses to reputational damage and disruption of business operations.

Recommendation

Deploy the Sigma rule “AdFind Command Activity” to your SIEM to detect the execution of AdFind with suspicious command-line arguments.
Enable Sysmon process-creation logging to provide the necessary data for the Sigma rule to function effectively (reference the Sysmon setup documentation).
Investigate any alerts generated by the “AdFind Command Activity” Sigma rule to determine the scope and impact of the potential compromise.
Monitor process execution events for AdFind-related activity, focusing on command-line arguments used to query Active Directory objects (reference the query field in the original rule).
Implement network segmentation to limit the scope of potential lateral movement following a successful compromise.