Browser Pivot for Chrome

[Nytro]

Browser Pivot for Chrome

March 11, 2019 ~ cplsec

Hey all,

Today’s post is about Browser Pivoting with Chrome. For anyone unaware of Browser Pivoting, it’s a technique which essentially leverages an exploited system to gain access to the browser’s authenticated sessions. This is not a new technique, in fact, Raphael Mudge wrote about it in 2013. Detailed in the linked post, the Browser Pivot module for Cobalt Strike targets IE only, and as far as I know, cannot be used against Chrome. In this post we’re trying to achieve a similar result while taking a different approach – stealing the target’s Chrome profile in real time. Just a FYI, if you have the option to use Cobalt Strike’s Browser Pivot module instead, do so, it’s much cleaner.

You might be thinking – “why go through the trouble?” If I’ve exploited the system I can mimikatz or keylog to get the target’s credentials and by extension, the resources they have access to. Well, one major application that comes to mind is multi-factor authentication (MFA). Organizations are catching on that a single password alone is not nearly sufficient in protecting valued network resources, which is fantastic news! Personally, I have the opportunity to do offensive engagements on OT targets which often have multiple tiers of authentication and networking; it’s my generalization that MFA-less sites tend to fall much quicker than MFA sites – hours or days vs weeks or not at all, respectively. In my opinion, MFA at a security boundary is one of the most important security controls one can implement.

You also might be thinking – “here you are touting the potency of MFA, yet you are talking about hijacking MFA sessions”. Again, this technique has been around since 2013 and the specific code developed for this PoC is all publicly accessible. Advanced adversaries have access to and are most likely employing this technique. Our offensive engagements need to emulate these threats because that’s how we get better from a defensive standpoint – steel sharpens steel.

How To Defend

First off, if you’ve forced an attacker to go beyond traditional credential theft to gain access to critical network resources, congratulations! This walkthrough has quite a few (loud) indicators that can point to malicious activity. We’re starting and stopping services, modifying system32 files, modifying registry, creating and deleting VSS snapshots, and ending it with a remote desktop session to the target. All this activity can easily be detected.

What Does It Do?

High level, this PoC attempts to do the following:

1. Modify the system to allow multiple Remote Desktop connections and remove RemoteApp restrictions.
2. Using VSS, copy the target’s in-use Chrome profile to another file folder.
3. Using RemoteApp and proxychains, remotely open a Chrome instance pointing to that copied profile path.
   • If you prefer, I think the profile could be copied over to the attacking VM and leveraged using proxychains and chromium. That being said, I would imagine this type of technique is time sensitive.

 

Code

To all the readers – this is proof of concept code, use at your own risk. ThunderRApp modifies system32 files and ThunderVSS interfaces with VSS. Just a recommendation, don’t run (shoddy) code from some rando on the internet without testing it first.

• ThunderChrome
  • ThunderRApp (x64 DLL) – Modifies the system to accept multiple RDP and RemoteApp sessions
  • ThunderVSS (x64 DLL) – Copies the target Chrome profile using VSS to get around file locks.
  • ThunderChrome.cna – Aggressor script which runs the DLLs
• Enumerate Chrome Tabs (Not Included)

Scenario

The attackers once again have a foothold on BLANPC-0004 under the context of BLAN\Jack. Jack uses his browser to access a vCenter server in the ADMIN domain. ADMIN\Jack has different credentials than BLAN\Jack when authenticating to the vCenter server. This domain segmentation eliminates several traditional credential theft methods and pushes us into a situation where we might have to keylog or do something else. For this example, let’s also assume that the organization employs hard-token MFA, really restricting our options … way to go defenders! To give you an idea of what MFA brings to the table.

• Without MFA: mimikatz or keylog –> done!
• With MFA: mimikatz or keylog, modify system32 files, start and stop services, copy in-use files via VSS, and establish RDP sessions –> done?

Multi-RemoteApp Sessions

In this example, we’re trying to leverage RemoteApp to gain access to Chrome sessions. However, on unmodified Windows Workstation OSes, we cannot use RemoteApp on a target which has an active session. Below describes an attempted RDP connection to a system with an active session.

Detailed in this post, termsrv.dll can be modified to permit multiple Remote Desktop sessions and by extension, RemoteApp sessions. Note, this process requires patching Windows\System32\termsrv.dll which can have major consequences, so beware.

With termsrv.dll modified, multiple RemoteApp sessions can now be established while the user is active on the target system. In this example, we’re waiting for ADMIN\Jack to authenticate to the ADMIN vCenter server.  So essentially, we’re continuously monitoring Chrome tabs for something vSphere related. To enumerate the tabs I used this PoC.

Seeing that Jack has a vSphere tab in Chrome, we assume that session cookies for vCenter are in Jack’s Chrome profile. However, we have a major problem, when Chrome is open, profile files and other goodies are locked and inaccessible. We can get around this by creating a VSS snapshot and copying the profile files to another directory we control.

With the copied Chrome profile in C:\users\public\documents\thunderchrome\default\, we start a Chrome instance with the –user-data-dir switch which points to the copied profile path. Just a FYI, when using RemoteApp With xfreerdp, I was unable to open Chrome with /app-cmd so I used c:\windows\explorer.exe instead. RemoteApp automatically opens child windows for you, pretty handy.

And finally, the hijacked vCenter session through proxychains and RemoteApp.

 

Sursa: https://ijustwannared.team/2019/03/11/browser-pivot-for-chrome/