Before diving into this blog post, you should consider reviewing our recent post on phishing users with MFA on AWS. The research discussed in this post was discovered during an AWS phishing engagement that Rhino was performing on a client, and our previous post goes much more in depth in how we phish users with MFA on AWS in general.

For those of you who haven’t read the other post, a TL;DR of it is: AWS users with virtual MFA devices can be phished through reverse-proxy tools like Modlishka. This allows for an attacker to proxy and intercept traffic between target users and target pages, with the potential of circumventing MFA controls.

During this recent engagement, Rhino was tasked with phishing a wide range of users with AWS as the primary focus. During this phishing engagement, we discovered that the cookies we were able to extract from the phishing session allowed our assessor to maintain persistence on the account regardless of logouts, password changes, or MFA device changes.

As part of the phishing process with Modlishka, we are able to gather the username, password, and MFA code that our target user used to log in. When using Modlishka for AWS phishing, we get all of the authentication cookies issued by AWS as well. 

We originally stored those cookies in our own browser and then visited the AWS web console to demonstrate proof-of-concept access. A short while later, we realized that our web console sessions would persist, even in the event that the phished user logs themselves out of the web console. This discovery made us question what the limits of these cookies were.

The next step was to see how far we could take this idea. The testing was performed on our own users and accounts so that it wouldn’t affect any ongoing phishing engagements. 

In this testing, we “phished” our own user account and then logged into the web console with the stolen cookies. Acting as if we were a user who was just phished, we changed the password of our user and then logged out in hopes that it would invalidate the session that the attacker stole. We found that after doing this, the session was still valid. This showed us that even after a target user changes their IAM user’s password and logs out, the phished cookies could still create a multi-factor authenticated session to the AWS web console.

We investigated the limitations of the cookies further by removing the MFA device used on that phished user’s account. We then replaced it with a brand new MFA device, changed the password for the user, then logged out of the web console. Even after all of that, we were still able to use the cookies we originally stole to create a multi-factor authenticated session to the AWS web console.

Now that we knew how truly powerful these cookies were, we needed to better understand their limitations. Because nothing was stopping this attack so far, an idea that came to mind was that there must be some sort of “zero-trust” security model implemented on AWS’s side. We thought that because all of this was being done through the same IP address, same web browser (user agent), and the same region of the country, there was inherited trust by AWS. 

If this was the case, then the attack would not work if, for example, our phishing server was hosted in south-eastern Canada, our pentesters were in north-western United States and the browser that the pentesters used had a different user agent than the phishing server. 

We tried this by using a phishing server located in Canada to phish an AWS user who typically logs in from Florida, then had pentesters in Washington state try multiple different web browsers (user agents) to make use of the phished cookies, even after MFA devices/passwords were changed. The diagram below shows our setup for this testing.

We were surprised to find that the full attack process worked, even with variation in the IP, user agent, and region at various steps of the process. This proved that regardless of the location changes, there was no “zero-trust” implementation of AWS’s side.

The only other limitation that we found was that the cookies expire after approximately 12 hours. This means that if you phish a user and steal their cookies, you have 12 hours of unrestricted access to their IAM user, regardless of whether they change their MFA device and/or password and log themselves out. After about 12 hours, however, we found that the cookies no longer worked.

We have seen that the standard “try to invalidate the attacker’s session through password changes or logging out” phishing defensive method will not work in the event that an AWS IAM user is phished. Because of this, we recommend restricting the permissions granted to an IAM user once they are phished. This way, even though the attacker is logged in, they won’t be able to perform any malicious API calls. To do this, you could immediately apply the “AWSDenyAll” AWS-managed IAM policy to the phished user, which would explicitly deny access to all AWS APIs from that user. 

It might even be necessary in certain cases to completely remove the phished IAM user in order to guarantee that the attacker no longer has access to the AWS environment.

While there are ways to react to phishing once you have been targeted, prevention is ultimately the best way to protect against this attack. To prevent AWS IAM phishing, you can follow these techniques::

• Perform regular phishing exercises on your employees so they can become trained to identify and report phishing attempts targeting the organization before they fall victim to them.
• Use hardware-based MFA devices for all IAM users and root account users (such as a properly configured Yubikey) instead of virtual MFA devices (such as Google Authenticator).
• Monitor login attempts to the AWS web console for IP addresses that are outside of your organization’s scope.
• Utilize AWS pentesting to identify and remediate any misconfigurations in the environment to minimize the impact of a successful attack against your organization.

We reported our persistent cookie findings to the AWS Security team and were informed that this functionality is working as intended. The reason for this is because “long-running operations” still need to complete successfully even after a user has logged out or changed their credentials. 

Though this does make sense from a usability standpoint, it is still a concern for security. Because AWS says that the cookies are working as intended, this behavior will likely not change, which makes it very important to implement the prevention techniques described above.

This working-as-intended functionality of the persistent cookies demonstrates the need for hardware-based MFA devices for all root and IAM users. Our findings also show that the traditional “changing the password” or “logging out” incident response techniques do not work for a phished user in AWS. It also points towards the importance of social engineering training and employee awareness, so that no one falls victim to these kinds of attacks.

Additionally, it’s best to identify and remediate any potential misconfigurations in your AWS environments to become aware of what attackers can do after gaining access. Rhino Security Labs offers a robust AWS pentesting program and we can be contacted through our “Request a Quote” form.

If you are aware of any other incident response techniques to help mitigate the risk of phished users (outside of traditional AWS IR) or other ways to completely prevent this kind of attack, feel free to reach out to our team.