Resource-Development - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/resource-development/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 02 Jan 2024 12:00:00 +0000AWS SNS Topic Created by Rare Userhttps://feed.craftedsignal.io/briefs/2024-01-02-aws-sns-topic-rare-user/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-02-aws-sns-topic-rare-user/An AWS SNS topic was created by a user who does not typically perform this action, potentially indicating resource development for data exfiltration or other malicious activities.This detection identifies when an AWS Simple Notification Service (SNS) topic is created by a user or role that doesn't typically perform this action. Adversaries might create SNS topics to stage capabilities for data exfiltration, lateral movement, or other malicious activities within the AWS environment. This detection leverages a "New Terms" rule, specifically designed to flag the initial occurrence of this behavior for a given user or role within an AWS account. The rule focuses on identifying anomalous SNS topic creation events, providing an early warning signal for potentially malicious activity related to resource development within AWS. It is triggered by the CreateTopic event in AWS CloudTrail logs, ensuring comprehensive coverage of SNS topic creation attempts.

Attack Chain

  1. An attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed IAM role. (T1566)
  2. The attacker attempts to create a new SNS topic using the AWS CLI, SDK, or Console. The CreateTopic API call is made.
  3. The CreateTopic request includes parameters such as the topic name, display name, and other attributes related to the SNS topic configuration.
  4. AWS CloudTrail logs the CreateTopic event, capturing details such as the user identity (ARN, type, access key ID), source IP, user agent, and request parameters.
  5. The "New Terms" rule analyzes the CloudTrail logs and identifies that the user or role creating the SNS topic has not previously performed this action within the observed timeframe.
  6. The newly created SNS topic can be used by the attacker to subscribe to events and receive notifications about activities within the AWS environment. (T1496)
  7. The attacker can then configure the SNS topic to trigger Lambda functions or S3 events, which allows persistence in the environment.
  8. Ultimately, the adversary may use the SNS topic for data exfiltration, lateral movement, or other malicious purposes, leveraging the messaging capabilities of SNS.

Impact

Successful exploitation allows attackers to stage capabilities within the AWS environment. While creating an SNS topic is not inherently malicious, it can be a precursor to more serious attacks. Depending on the subsequent actions taken by the attacker, this could lead to data exfiltration, resource hijacking, or other forms of impact within the AWS infrastructure. The severity depends on the scope of access available to the compromised user or role and the configurations of the newly created SNS topic.

Recommendation

  • Deploy the Sigma rule provided in this brief to your SIEM and tune for your environment to detect unusual SNS topic creation activities (see rule: "AWS SNS Topic Created by Rare User").
  • Investigate any alerts generated by the Sigma rule, focusing on the user identity, source IP, and request parameters associated with the SNS topic creation event.
  • Monitor for further SNS modifications, such as Publish or Subscribe events, following the initial topic creation event (see Overview).
  • Enforce least privilege IAM policies and enable multi-factor authentication (MFA) to reduce the risk of unauthorized access to AWS resources (see Overview).
]]>lowadvisorycloudawssnsresource-developmentimpactAWS Route 53 Domain Transferred to Another Accounthttps://feed.craftedsignal.io/briefs/2024-01-aws-route53-domain-transfer/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-aws-route53-domain-transfer/An AWS Route 53 domain was transferred to another AWS account, potentially leading to unauthorized control over DNS records and traffic redirection for malicious purposes, such as phishing or establishing persistence.This threat brief addresses the unauthorized transfer of an AWS Route 53 domain to another AWS account. Route 53 is a scalable DNS web service, and control over a domain allows an attacker to modify DNS records, reroute traffic, and request certificates. The adversary could gain control by compromising an IAM user or leveraging long-lived credentials. Such a transfer can lead to persistence, traffic redirection, phishing attacks, or the staging of infrastructure for more extensive malicious operations. This activity is detected via CloudTrail logs when the TransferDomainToAnotherAwsAccount event is successfully invoked.

Attack Chain

  1. An attacker gains unauthorized access to an AWS account through compromised credentials or IAM role exploitation.
  2. The attacker identifies a target domain within the Route 53 service.
  3. The attacker may disable the domain transfer lock using DisableDomainTransferLock.
  4. The attacker initiates a domain transfer to an AWS account under their control using the TransferDomainToAnotherAwsAccount API call.
  5. The transfer is successful, granting the attacker administrative control over the domain's DNS records.
  6. The attacker modifies DNS records to redirect traffic to malicious servers they control.
  7. The attacker sets up phishing sites or redirects legitimate traffic to a command-and-control infrastructure.

Impact

A successful Route 53 domain transfer enables an attacker to fully manage the domain's DNS resources, potentially leading to traffic redirection, service outages, or domain hijacking for phishing or command-and-control. While the exact number of victims and sectors targeted is unknown, unauthorized domain transfers can severely impact any organization relying on AWS for DNS services. This could disrupt service availability, compromise sensitive data through phishing, or enable persistent access to internal networks.

Recommendation

  • Deploy the Sigma rule AWS Route 53 Domain Transferred to Another Account to detect successful TransferDomainToAnotherAwsAccount events in AWS CloudTrail logs.
  • Monitor AWS CloudTrail logs for DisableDomainTransferLock events followed by TransferDomainToAnotherAwsAccount as it indicates a possible domain transfer preparation.
  • Restrict domain transfer permissions to a minimal set of roles using IAM Conditions such as aws:PrincipalArn and aws:MultiFactorAuthPresent as recommended in the AWS Knowledge Center – Security Best Practices.
  • Implement change-management tracking for domain ownership modifications, correlating with approved internal requests as noted in the overview.
]]>highadvisoryawsroute53domain-transferpersistenceresource-development