In October, AWS unveiled a feature that allows users to easily transfer an Elastic IP address between accounts. An EIP is a public, static IPv4 address that can be assigned to an EC2 instance and used for internet communications.
Threat actors have discovered a way to take advantage of the new feature to hijack public EIPs and launch attacks in various ways. Researchers from cloud incident response firm Mitiga identified four scenarios where attackers can exploit this capability.
What is EIP?
In October 2022, AWS unveiled a feature that allows you to transfer EIPs (Elastic IP addresses) between accounts – even those owned by someone else – without updating DNS records. This capability is especially attractive to DevOps teams since it provides them with an easier way to provision services and make global changes in the cloud without needing to modify DNS records.
Upgrades of software releases require upgrading, and this new feature can be exploited by malicious actors. They find a way to misuse AWS Elastic IP Transfer and transfer an EIP from one account to another, giving them full access to its underlying public IP address.
To take advantage of this feature, the attacker must possess the required credentials and permissions. This includes Identity and Access Management (IAM) rights that enable them to’see’ existing elastic IP addresses, their statuses, as well as to enable IP transfer in a policy attachment. Furthermore, they need the ec2:DescribeAddresses and ec2:EnableAddressTransfer actions within their policy.
They can also dissociate an existing EIP from any associated compute resources, like Elastic Compute Service (ECS) instances, Classic Load Balancer (CLB) instances, Application Load Balancer (ALB) instances or secondary elastic network interfaces (ENIs), so they can transfer it to another account before any security tools or workers detect and revoke the transfer.
Once an attacker obtains an unused IP address, they can use it for malicious activities like hosting a C&C server for malware campaigns that may go undetected by defensive tools. This could include phishing attacks and campaigns run on compromised accounts.
Amazon Web Services recommends that you only enable EIP transfer if you absolutely require the IP address for your business, and after having properly removed all associated resources from your account. Moreover, AWS recommends disabling EIP transfers completely if you do not require them or have concerns about their potential misuse.
If you suspect your environment has been compromised by a threat actor using this feature, reach out to your IT security team for investigation. They can advise you on what steps should be taken and how to reduce the potential risks.
Amazon Web Services recently unveiled “Elastic IP Address Transfer,” an innovative feature designed to make moving Elastic IP addresses between accounts faster and less costly.
However, this feature can be exploited by malicious actors to gain access to other systems within an AWS environment. A blog post published last week by Mitiga researchers detailed a new method by which adversaries could take advantage of this feature and gain unauthorized access to systems within that same environment.
Researchers discovered that a threat actor with the appropriate credentials can leverage AWS Elastic IP Transfer to gain unauthorized access to systems within an account. This new attack vector represents an “post-exploitation attack” not previously possible, according to the blog post.
To execute this attack, the attacker would require identity and access management (IAM) permissions that permit them to view existing elastic IP addresses as well as enable its misuse. They also need permissions for transferring both the elastic IP address itself, along with any network interfaces it is attached to, into their control.
Once an attacker has these permissions and the capability to enable an EIP transfer, they can take control of the victim’s environment and move it away from them. They could take advantage of trust in security controls by launching a phishing campaign or social engineering attack that might go undetected by defensive tools and endpoints.
For instance, an attacker can launch a malware campaign or command-and-control (C&C) server hidden behind the victim’s firewall to steal data. They could even use hijacked elastic IP addresses for spoofed public network access using DNS “A” records.
In addition to these scenarios, an attacker could launch a DDoS attack against a target’s infrastructure. While naive, this method can be effective in gaining unauthorized access and denying service, according to Mike Parkin, senior technical engineer at Vulcan Cyber.
Last October, AWS introduced a feature that allows organizations to transfer Elastic IP addresses (EIPs) between accounts. This makes it simpler for an organization to alter its IP address when moving accounts or changing locations. Unfortunately, malicious actors with the appropriate permissions and credentials could potentially abuse this feature to steal victims’ EIPs and take control of their environment.
Mitiga researchers identified that a threat actor with control over an AWS account can take advantage of the new functionality to compromise an IP address and use it for malicious activities. The threat actor could then utilize that IP address to launch various attacks, such as credential theft and phishing attempts.
The attacker could also leverage the compromised EIP to access other cloud resources and alter DNS “A” records, potentially leading to a denial of service or data exfiltration.
According to research, an attacker can transfer an EIP into their own AWS account through a single API call, effectively taking control of it. From there, they could launch various attacks against the victim’s infrastructure – from theft of credentials to impersonating other criminals’ underworld souks – by simply making one single API call.
Mike Parkin, senior technical engineer at Vulcan Cyber, noted that while this isn’t a direct attack, it serves as an example of how malicious actors can exploit new features to gain control in an environment. The feature was intended to be two-step process between source and transfer accounts; however, with some creativity an attacker could easily bypass it.
AWS also notes there are some limitations to this feature, such as providing both source and target accounts with written confirmation that they want to transfer an IP address, acceptance of said EIP in their own account before it’s associated with an EC2 instance or other compute resource, and permissions at both API and IAM levels for it to be completed.
AWS recently introduced a new feature in October that allows users to transfer Elastic IPs (EIPs) between active accounts. According to Mitiga researchers, this functionality could be used by threat actors with pre-existing control over an AWS account to hijack static public IP addresses for malicious purposes.
The attacker would need at least two API permissions: the ability to’see’ existing elastic IP addresses and their statuses, and to enable EIP transfer. They would also need to have the ‘DisassociateAddressTransfer’ action applied to the elastic IP addresses they wanted to transfer, as well as any network interfaces they were attached to.
This is a more naive scenario than the first two, but it still involves enabling an EIP transfer and then accepting it into another account before any security tools or workers detect it and revoke the transfer. The EIP will be theirs and they will have the ability to do all sorts of malicious things with it, such as communicating with network endpoints found behind other external firewalls that are using an allow rule on the specific elastic IP address transferred.
In addition, it’s possible that the attacked organization may not even notice the transfer, as they might not use the IP address. This is especially true if the EIP has been associated with a stopped instance or an unattached network interface. This could result in a small hourly charge from AWS, but it also means that the EIP is not being used, which makes it easier to transfer the IP address.
Scenario 3: The Adversary Can Disassociate and then Transfer the EIP This can be done if an adversary finds that a running instance or an active ENI has a local or subnet property that says it should automatically get its own IP address as soon as it is removed from that resource. This is common in disaster recovery environments, where a stopped or disassociated EIP can be transferred without causing a problem as long as the victim keeps its permissions on the transfer account high enough.
AWS is aware of this attack vector and is working to mitigate the vulnerability, but organizations should take precautions as well.