An adversary can pivot from a compromised host to Web Applications and Internet Services by stealing authentication cookies from browsers and related processes. At the same time this technique bypasses most multi-factor authentication protocols.
The reason for this is that the final authentication token that the attacker steals is issued after all factors have been validated. Many users persist cookies that are valid for an extended period of time, even if the web application is not actively used. Cookies can be found on disk and also in process memory. Additionally other applications on the targets machine might store sensitive authentication tokens in memory (e.g. apps which authenticate to cloud services). This pivoting technique can be extended to bearer tokens, JWT and the likes.Pass the Cookie is a post-exploitation technique to perform session hijacking. So, let's Pass the Cookie and Pivot to the Clouds.
Disclaimer: Always make sure you have proper authorization before pen testing.
Pass the Cookie is done via the following steps (variations exist):
When it comes to detections a few things come to mind:
To protect from these attacks it's important to stay up to date with security patches, etc. to ensure your host does not get compromised. As seasoned security engineer you assume the worst, and here are some ideas on how to mitigate implications of an attack:
In case you don't won't to write your own toolset, there are a couple of options available to gain access to cookies:
Below is a list of some "cookies of interest" for valuable web applications your organization might use. An adversary might be after those and you could emulate to see if your organization catches the attack. This list might change over time or have inaccuracies - feel to provide feedback or help amend.
|Amazon Web Services||aws-userInfo|
|Google Cloud Platform||OSID, HSID, SID, SSID|
APISID, SAPISID, LSID
OSID has to be set on console.cloud.google.com,
others on .google.com
LSID needed for cross app auth (e.g. GCP to Gmail).
|Facebook for Work||c_user|
|.facebook.com||Also works for regular Facebook|
|Hotmail, Calendar, People||RPSSecAuth||.live.com||Access to hotmail,... (No OneDrive)|
|Gmail||OSID, HSID, SID, SSID|
APISID, SAPISID, LSID
For basic mail access only first 4 seem needed.
Notice: When setting cookies through the web console, each cookie has to be set individually via document.cookie="". You can always view the currently set cookies via document.cookie
Also when setting cookies ensure to set them on the correct domain. If in doubt you can try setting them on the root domain.
Pass the Cookie is a powerful post-exploitation technique to pivot from on-premise machines to cloud assets. It can be leveraged to bypass 2FA techniques as the cookie is in the end still a single factor.
Hopefully this was helpful, so you can build better detections, improvements and tests into your infrastructure to catch malicious activity. If you have any questions or ideas feel free to send me an email at firstname.lastname@example.org, or create a ticket.
Browse to www.google.com in private mode. We aren't logged in.
Open Developer Console and set the appropriate cookies (see cheat sheet for cookie details)
Switch to the Applications tab and look at the cookies. You can see that they got set on www.google.com, which is not what we want.
Update the domain setting of the cookies to .google.com. The cookie for OSID has to be set to console.cloud.google.com for GCP (it works on .google.com as well, but you might observe cookie mismatch errors later if you want to go to different services outside of GCP). So this can be a bit of a hiccup at times.
Finally, navigate to https://console.cloud.google.com and observe being magically logged in. If you set the LSID cookie you can also go to GMail or the Accounts settings page.
Browse to the website and observe not being authenticated. No cookies.
Set the appropriate cookie for the website domain (e.g via developer tools of the browser).
Refresh the page and observe being authenticated. :)
This page uses w3.css