TL;DR
Mitiga Threat Researchers identified a new potential attack vector leveraging recently introduced functionality in AWS that allows transferring IP Addresses to other organizations.
By exploiting the AWS Elastic IP Transfer feature, a threat actor with existing control over an AWS account can compromise an IP address, then use it for other things (such as allow listing circumvention).
This is a new vector for post-initial-compromise attack, which was not previously possible (and does not yet appear in the MITRE ATT&CK Framework), which organizations may not be aware of its possibility.
We already notified AWS security team about our findings before publishing this blog and incorporated the feedback we got as part of this blogpost.
Introduction
In October 2022, AWS announced a new Amazon VPC (Virtual Private Cloud) feature, “Elastic IP transfer”, which allows transfer of Elastic IP addresses from one AWS Account to another. This feature makes it easier to move Elastic IP addresses during AWS Account restructuring. Here is the announcement:
The feature enables you to transfer the EIP (Elastic IP) to any AWS account, even AWS accounts that are not owned by you or your organization.
But as often happens with a useful new feature, a malicious actor with the right credentials and permissions could potentially misuse the feature to cause harm.
In this blog, we will walk you through the process of “Elastic IP Transfer,” how an adversary with the proper permissions inside your environment might abuse this feature, how it can be detected, and what can you do to mitigate the risk.
Background
What is an Elastic IP?
An Elastic IP (EIP) address is a public and static IPv4 address that is reachable from the internet. These addresses are normally provided by AWS out of a large regional pool available to all customers, although customers can also use a feature called “BYIOP” (bring your own IP), through which they transfer their own CIDR blocks to AWS and allocate EIPs from that pool.
An Elastic IP address is initially allocated to your AWS account upon request and is yours to use in numerous ways until you release it. You can associate an Elastic IP address with a single instance or elastic network interface (ENI). You can also associate it with some AWS managed networking services with the ENIs of a Network Load Balancer (NLB) or a NAT Gateway.
For the rest of this blog, we will only concern ourselves with the use of an EIP on an instance or ENI. That’s because EIPs, once assigned, cannot be disassociated from NLBs or NAT Gateways. As for EIPs from a BYOIP block, they can be freely associated and disassociated just like any other EIP, and they can even be shared across AWS accounts using Resource Access Manager (RAM), but they cannot be transferred.
For more information, follow the link to AWS documentation:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html
What is the New “Elastic IP Transfer” Feature?
Before AWS announced this new feature, transferring an EIP from one AWS account to another was a cumbersome procedure that involved opening support tickets from both the source and destination AWS accounts requesting the transfer.
You can find the full historical procedure in this AWS answer:
With this new feature, the transfer is entirely API-driven. It includes a two-step handshake between AWS accounts — the source account (either a standard AWS account or an AWS Organizations account) and the transfer account — making the procedure far easier for the organization (and for hackers). Let’s look at the possibilities.
The Attack
What does a malicious Elastic IP transfer look like?
We assume that the adversary has the right IAM permissions (the exact permission required will be discussed) to start the transfer inside your environment:
Scenario 1 — Transfer Non-Associated EIP
This is the most naïve scenario but shows the basic idea. Normally, EIPs will be associated, but organizations may keep disassociated EIP because of an unmanaged environment that keeps unused resources, or it could be because keeping the EIP that was previously used in some fashion for later use is easier than update updating any associated resources, such as DNS "A" records, or all the organizational firewall rules.
Either way, the attacker only needs to enable the EIP transfer, then accept it in another account before any security tool or worker detects it and revokes the transfer (which is possible via the DisableAddressTransfer API prior to acceptance in the transfer account), and the IP address is theirs.
Scenario 2 — Disassociate EIP from stopped instance or an unattached network interface & transfer the EIP
In this scenario, where the EIP is already associated (which is usually the case), the EIP must be first disassociated to be transferred. Associating EIP with a stopped instance or an unattached network interface imposes a small hourly charge from AWS. Nonetheless, keeping such a standby EIP is common practice as part of disaster recovery plans, when recovering from a failure by just turning the instance up. In this scenario, the adversary disassociates the EIP from the instance/network interface and then enables the transfer of the EIP. This scenario is also the most beneficial for the attacker, as the attacked organization may not notice the transfer for a long time (as it does not currently use the IP address). This requires an added IAM permission (ec2:DisassociateAddress) that the user/attacker must also have.
Scenario 3 — Disassociate EIP from a running instance & transfer the EIP
In case an EIP is disassociated from a running instance or active ENI, at the API and IAM level this scenario is just like the previous one. No additional permissions are required. This scenario is more likely to be noticed vs. the previous ones, because the victim may quickly notice something isn’t right with the running instance and can even cause denial of service within a system or application. Like Scenario 2, the adversary only needs to disassociate the EIP from the running instance and then enable the transfer of the EIP.
You might wonder what happens from an IP addressing perspective when an EIP is removed from an active resource. It could be one of two things:
- If the instance or ENI has a local or subnet property set that a dynamic IP address should be automatically applied, removal of an EIP will result in the automatic substitution within a few seconds of a different public IP address.
- If the automatic assignment property is not set, nothing will happen. Removal of the EIP will result in the resource not having any public IP at all.
What kind of permissions does the adversary need on the victim account for this attack?
First, unless there is some other way to obtain knowledge of ownership, the adversary will need to “see” the existing elastic IP addresses and their status (if they are already associated with other compute resources). Then, the adversary will need to enable Elastic IP address transfer.
For the actions above, the adversary must have the following actions in its attached IAM (Identity and Access Management) policy: ec2:DescribeAddresses on all the IP addresses (`*` on resource element) and ec2:EnableAddressTransfer on the elastic IP address the attacker wants to transfer.
In case the adversary wants to transfer already associated EIP, the adversary must have the ec2:DisassociateAddress action on the elastic IP addresses and the network interfaces the IP addresses are attached to disassociate the address.
In sum, the adversary will likely need at least two and possibly three API permissions to use this feature for bad purposes. That said, the defender can make this attack harder, as we discuss below in Detection and Mitigation sections.
What can a malicious actor do after a successful IP transfer?
Despite increased understanding of the risks associated with IP address-based security, organizations still heavily rely on IP addresses to authenticate and verify identity of 3rd party services, servers, users, etc.
The following is a list of some common potential attacks that can take advantage of taking over an IP address when there are security controls which rely on said IP address for security.
These are only examples, and there is a wide range of potential attacks, all depending on what type of trust and reliance others have in relation to the hijacked IP.
- In a public VPC network, if the victim configured security groups with ingress rules that included the transferred IP address that previously belonged to them, the adversary can communicate with resources using those security groups.
- In other external firewalls that the victim uses, if there is an allow rule on the specific elastic IP address that has been transferred, the adversary can communicate with the network endpoints that are found behind those firewalls. For example, the adversary can start connection with a database hosted in the victim’s on-premises infrastructure that is behind the company security systems.
- In cases where there are DNS “A” records that point to the Elastic IP address, the adversary can spoof the previous owner’s public network presence. For example, the adversary can abuse it by hosting a malicious web server under a legitimate victim’s domain, then the adversary can use it for malicious actions, such as phishing attacks. However, in such a case, HTTPS (TLS) connection will not work properly because of mis-matched server certificates, and modern browsers will typically keep all but the most careless customer from connecting.
- Conducting malicious activities using the Elastic IP address, such as C&C (command and control) server, for malware campaigns that may then go under the radar of defensive tools.
- In cases of dissociating the Elastic IP from a running endpoint and transferring it, the adversary can potentially cause denial of service (DOS) to the victim’s public services, communicating with unresponsive IP address.
Detection and Response
How to detect a malicious elastic IP transfer?
One: By searching the event name EnableAddressTransfer in CloudTrail logs, you can detect when the API has been called:
- The principal which initiated the transfer
- The Elastic IP that was transferred
- The destination AWS account:
In this example, the principal that started the transfer is AAAAAAAAAAAA, the elastic IP is: 18.116.233.126 and the AWS account which accepted the transfer is: 222222222222.
Unfortunately, CloudTrail logs don’t show you if the transfer was accepted from the destination AWS account.
That information is available, however, via an API call (see below). That said, especially if you add automation (discussed further below), if you observe this event in CloudTrail you may be able to block the transfer before completion.
Two: (Optional) In case the adversary disassociated EIP before transferring it, you can find DisassociateAddress event in CloudTrail. Here is an example of such an event:
Three: To know the status of the transfer, you can call the DescribeAddressTransfers EC2 service API, which will show you all the transfers and their status:
In this example, you can see the elastic IP address that was transferred, the destination AWS account, when the offer was accepted, and the status of the transfer. The record of the transfer provided by this API appears to last for 3 days, so if you monitor that list you will have visibility into relevant activity.
Four. It is important to remember that after a successful elastic IP transfer, you can no longer see the elastic IP in the source AWS account. If you check the console or call the EC2 service API DescribeAddresses you will not see the EIP. Even the new AWS service, AWS Resource Explorer, will not show the EIP. You might mistakenly think the IP address was released without knowing it was transferred.
How should the recovery process look like?
We have already discussed some of the risks of an inappropriate EIP transfer above. Using an EIP probably involves configuring the public static IP address in various important places, such as on-premises firewalls rules, DNS records, CDNs, and even firewalls in other cloud providers. The IP address might even be shown even in publicly shared company documents and tutorials.
You can try opening a support ticket to AWS to report any questionable activity. as well as request assistance assisting in recovering the lost EIP: https://www.apn-portal.com/knowledgebase/articles/FAQ/How-Do-I-Open-a-Support-Ticket-with-AWS-Support
You should also report to AWS’s Trust & Safety team any activity by a bad actor using AWS infrastructure, in violation of their Terms of Service, see: https://aws.amazon.com/premiumsupport/knowledge-center/report-aws-abuse/
Finally, and, although listed at the end, this step should be carried out immediately to minimize impact or harm — in case you cannot recover the EIP, you must remove the IP address from all allowlists in network security solutions and services. If you are using IaC (infrastructure as code) solutions for configuring your resources, it may make the procedure less painful.
How to mitigate malicious transfer
After contacting AWS security team and working with them on this issue, we have compiled together a list of steps one can do to mitigate this attack:
Mitigation #1: Service Control Policies
Following the principle of least privilege can reduce the possibility the adversary could have permissions to transfer the EIP. You can use native the AWS Organizations feature “service control policies” (SCPs), which offers central control over the maximum available permissions for all accounts in your organization. You can create a policy that denies `EnableAddressTransfer` entirely:
Unfortunately, you can’t restrict the EIP transfer to AWS accounts inside the same AWS organization, so the only option left is to deny ec2:EnableAddressTransfer entirely (or denying specific IP addresses).
Mitigation #2: Automated detection and response
As we demonstrated above, the use of the EnableAddressTransfer API results in a CloudTrail log record. It can, therefore, also fire an AWS EventBridge event that allows you to respond automatically. For example, you can write a Lambda function that warns you of the behavior via SMS or email (using Simple Notification Service) and attempts to block the transfer automatically by calling DisableAddressTransfer. If you want transfers to succeed when taking place within a set of accounts under your control, the automation can contain an allow-list and ignore the API if the target account is on the allow-list, but otherwise warn you and attempt to block the transfer.
Mitigation #3: Use of BYOIP
As noted above, EIP transfer does not work in the case of AWS’s “bring your own IP” (BYOIP) feature. If you want to be able to freely share (and in that sense “transfer”) EIPs among a set of accounts, without any risk of the loss of control of those IP addresses, you can do so by creating a BYOIP address pool, and then use AWS’s RAM to share (transfer) them freely among the set of accounts you control.
Mitigation #4: Reverse DNS protections
Elastic IP transfer doesn’t work if the EIP has a reverse DNS name associated with it. Any EIP can have a reverse DNS name associated with it by first creating a public forward “A” record that references the EIP, and then calling the ModifyAddressAttribute API (or corresponding command line interface (CLI)) with the public DNS name as a parameter. Thereafter, EIP transfer will not work unless the reverse DNS name is first removed using the ResetAddressAttribute API.
You may wonder if this mitigation is very valuable, considering that an attacker with valid credentials in your account might also have the privilege to call this additional API. That’s true, but there is still value here. To begin with, this API is asynchronous; it takes some number of seconds to complete, and meanwhile transfers will not work. This can give you a head start in detecting and reacting to any misuse of the EnableAddressTransfer API. The automation solution discussed above, for example, can trigger on an EventBridge event for this action, and not only alert you sooner but also be able to call DisableAddressTransfer in a loop on the impacted address, making it much harder for the transfer to succeed. Meanwhile, based on the notification you can take action to evict the attacker from your environment.
Summary
The EIP transfer feature is very useful, but it creates a new attack dimension that was not previously seen on AWS. Stealing static public IP addresses can affect organizations greatly, risking not only company assets but the company customers, too.
As an AWS partner, we already notified AWS security team about our findings before publishing this blog and incorporated the feedback we got as part of this blogpost. We continue to communicate with AWS about potential opportunities to further improve the security and logging visibility of the feature.
