Pivot to the Cloud using Pass the Cookie

Web Applications and Services use cookies to authenticate sessions and users.

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.

Update: Pass the Cookie at the Chaos Communication Congress (35C3)



Attack Chain

Disclaimer: Always make sure you have proper authorization before pen testing.

Pass the Cookie is done via the following steps (variations exist):

The appendix shows examples for Github and Google Cloud Platform by using Google Chrome to pass the cookie.

Detections

When it comes to detections a few things come to mind:


Mitigations

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:


Aquiring Cookies, Tools and Techniques

In case you don't won't to write your own toolset, there are a couple of options available to gain access to cookies:

There are also good articles online describing how to access and decrypt the cookies in the SQL Lite databases yourself - if you'd like to do your own research or tool.


Pass The Cookie - Cheat Sheet

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.

ApplicationCookie NameDomainNotes
Amazon Web Servicesaws-userInfo
aws-creds
.amazon.comhttps://console.aws.amazon.com
Google Cloud PlatformOSID, HSID, SID, SSID
APISID, SAPISID, LSID
.google.comhttps://console.cloud.google.com

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).
Microsoft OnlineESTSAUTHPERSISTENT.microsoftonline.com
Facebook for Workc_user
xs
.facebook.comAlso works for regular Facebook
OneLoginsub_session_onelogin.com.onelogin.com
GitHubuser_session.github.com
Hotmail, Calendar, PeopleRPSSecAuth.live.comAccess to hotmail,... (No OneDrive)
GmailOSID, HSID, SID, SSID
APISID, SAPISID, LSID
.google.comhttps://mail.google.com

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.


Conclusion

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 wunderwuzzi23@outlook.com, or create a ticket.



Appendix - Pass the Cookie Examples

Example 1) Google Cloud Platform, Gmail,...

Browse to www.google.com in private mode. We aren't logged in.

not logged in

Open Developer Console and set the appropriate cookies (see cheat sheet for cookie details)

applying cookie

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.

logged in

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.

logged in

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.

logged in


Example 2): Pass the Cookie on Github

Browse to the website and observe not being authenticated. No cookies.

not logged in

Set the appropriate cookie for the website domain (e.g via developer tools of the browser).

applying cookie

Refresh the page and observe being authenticated. :)

logged in

wunderwuzzi23@outlook.com
December 2018

This page uses w3.css