This vulnerability allows low privileged users to hijack file that are owned by NT AUTHORITY\SYSTEM by overwriting permissions on the targeted file. Successful exploitation results in "Full Control" permissions for the low privileged user.

This vulnerability allows low privileged users to hijack file that are owned by NT AUTHORITY\SYSTEM by overwriting permissions on the targeted file. Successful exploitation results in "Full Control" permissions for the low privileged user.

Intro

First of all I would like to thank fellow researchers for giving me inspiration to dive into this type research.

Now let's talk about this particular vulnerability. All Windows Apps have a settings.dat file which keeps track of the (registry) settings of the App. That file is a registry file which can be loaded into registry and modified there.
However once you launch a Windows App such as Microsoft Edge the settings.dat file it is used by NT AUTHORITY\SYSTEM and as a low privileged user you have full access to that file.
Now the question arises how can we abuse the privileged file access.

Vulnerability

Let's focus on the settings.dat file of Microsoft Edge.
All Windows Apps user configuration files are stored under the current users' AppData folder.

C:\Users\<username>\AppData\Local\Packages\<Packagename>

Windows 10 already has a number of default Apps installed as shown above.
Each package has a settings.dat file, as mentioned before this file is used by NT AUTHORITY\SYSTEM to writes any configuration changes.
Once the Windows App is started the system uses an OpLock operation (Exclusive Lock) to prevent other processes to use/access that file while the App is running.
In our case when we start Microsoft Edge the settings.dat file is opened as NT AUTHORITY\SYSTEM, which can be seen in the screenshot below.
Once opened, some basic integrity checks are performed in the following manner:

Check file permissions

If file permissions are incorrect, then correct the file permissions with the correct

Read the file content

If content is corrupted, then delete the file

Reset the configuration by copying the settings template file from "C:\Windows\System32\settings.dat"

Get "Exclusive Lock" on the newly copied file

Proceed to start the Windows App

This procedure can be seen in the following screenshot when performing our attack
As mentioned before it first sets the correct file permissions during the SetSecurityFile operation after which it continues on reading the contents of the file, in our case the contents do not correspond to a correct settings.dat file. After which it deletes the file, copies the settings template file and proceeds with starting up the Windows App.
Now most of these operations are performed by impersonating the current user access which prevent abuse of these operations as they won't be any different as performing these operations as the current user.

We can use this behaviour to set the file permissions on "any" file (there are some pre-requisites, I'll come back to that later) by using hardlinks.
Huge thanks to James Forshaw and Google P0 again for providing us with the SymbolicLink Testing Toolkit. Using his toolkit we can create hardlinks to files where we want to have "Full Control" over as a regular user.

Exploit

We know that file permissions set on a hardlink will result changes on the original file.
Below we will hijack the HOSTS file located at C:\Windows\System32\drivers\etc\hosts. As a regular user you don't have modify access to that file as seen below.
I've written an exploit that automates the entire process of creating a hardlink and triggering the vulnerability. The result of a successful exploitation can be seen below.
1. The exploit first checks if the targeted file exists, if it does it will check its permissions. Since we are using Microsoft Edge for this exploit it will kill Microsoft Edge in order to get access to the settings.dat file.
2. After Microsoft Edge is killed it will check for the "setting.dat" file and delete it in order to create a hardlink to the requested targeted file (in our case that was the HOSTS file)
3. Once a hardlink is created Microsoft Edge is fired up again to trigger the vulnerability. Concluding with a final check if indeed "Full Control" permissions have been set for the current user.

As I mentioned previously above there are some pre-requisites you have to take into account before abusing this vulnerability. These are the following:

NT AUTHORITY\SYSTEM should have "Full Control" over the targeted file

The low privileged user or the Users group should have "Read/Execute" rights

The "Read/Execute" rights should be inherited, explicit "Read/Execute" are not sufficient

Intro

This weakness allows us to bypass the URL filtering on the RH parameter which could be used to hijack the session of any user when following a particularly crafted link. In summary, phishing heaven !

Intro

Oracle Authentication Manager (OAM) 10G or OAM 11g with Webgates 10g parse SSO cookies in an HTTP GET parameter.
OAM sets a cookie based on the ‘obrareq.cgi’ parameters that are sent (see examples below)
Once a user authenticates he/she will be redirected to the domain that was specified in the ‘RH’ parameter.
The HTTP GET request will contain the ‘ObSSOCookie’ value as one of the parameters.
Prior to this blog Tom and I already did some research in this area which can be found here.
Back then Oracle pointed out that this issue was related to a configuration issue and to prevent abuse the 'SSODomains' parameter should be defined in OAM or WebGates.

Bypassing the 'SSODomains' restriction

We moved the focus of our research to bypassing the ‘SSODomains’ parameter as defined in the configuration which essentially results in the same weakness as explained in the previous blog post. After testing numerous possibilities we successfully managed to bypass the SSODomains restriction by using both weaknesses in Oracle OAM and how modern day browsers treat certain URI schemes.

Example Decoded URL:

Affected "RH" parameter

The "RH" parameter is affected in the sense that there are some values that are accepted but not properly checked.
In the example above the original domain (RH=redirect host) is https://www.somedomain.com.
Modifying this domain as follows causes an error for example:

After testing we found the following (URL encoded) values seem to be working (this list is not a definitive list!!):

%3A (encoded value for a colon)

%20 (space is allowed)

%3D (equal sign is allowed)

…

So following our example above and the URL scheme (https://en.wikipedia.org/wiki/Uniform_ Resource _Identifier), it makes it possible to modify the domain with the accepted values mentioned previously and bypass the 'SSODomains' restriction which is set to only allow authentication against 'www.somedomain.com'.
Our new "RH" parameter will look something like this: https://www.somedomain.com:test%20@maliciousdomain.com

This is the protocol that is used (HTTP over SSL)

These values are considered to be authentication values (username, password respectively)

This value is considered the domain where the browser has to authenticate.

OAM fails to validate the "RH" parameter,it sees the "www.somedomain.com" domain and no forbidden characters therefore simply accepts this input as the accepted value for the "RH" parameter.

Hence resulting in a redirect to "maliciousdomain.com" domain with the ObSSOCookie in the URL.
Because this HTTP GET request to the malicious domain will contain the ObSSOCookie, the attacker will have a fully functional session identifier to access the legitimate web application and resources. (more details can be found in the blog post in the link above)

CVSS rating

Windows Remote Assistance allows someone you trust take over your PC and fix a problem from anywhere around the world.
It relies on the Remote Desktop Protocol to establish a secure connection with the person in need.

-MSDN

Background

Windows Remote Assistance allows someone you trust take over your PC and fix a problem from anywhere around the world.
It relies on the Remote Desktop Protocol to establish a secure connection with the person in need.

-MSDN

Background

I stumbled upon this functionality during my research and was curious whether this functionality would allow me to abuse it in any sort of way. So let's fire up MSRA (Microsoft Remote Assistance).

It gives you 2 options:

Invite someone to help you

Respond to someone who needs help

If you selected the first option you will get a follow-up screen with another set of 2 options:

Save invitation to an .msrcincidentfile

Send invitation via email with the .mrcincidentfile as an attachment

We'll choose to save the file locally and analyze it's contents, so evidently we choose the first option.
Opening the Invitation.msrcincident file reveals XML data with a lot of parameters and values.

The password encryption flow looks as follows.

However whenever you see XML data being fed to a program you have to think about XML External Entity (XXE) vulnerabilities, in the past these vulnerabilities lead from information disclosure to RCE (see this, that and many more...)

So first I was curious which parser MSRA used to handle the invitation file. ProcessMonitor revealed the following:
It's using MSXML3 to parse the XML data so immediately I started looking for potential existing vulnerabilities related to MSXML3 in the past.
MSXML3 has had it's fair share of vulnerabilities (here), however no details were ever released about the vulnerabilities.
So let's see if the MSXML3 parser will allow me to use SYSTEM entities.

Vulnerability

The first problem is how will I confirm the existence of an XXE vulnerability if no output is shown of the requested resource. Basic XXE payload looks something like this:

Whereas the result of this XML (after parsing) should be that inside the <foo> tags the content of the file passwd should be displayed.

MSRA does not show you the output of the processed XML, making it hard to validate BUT to weaponize this attack I need to be able to exfiltrate the requested data from the victim to my machine.
Therefore I need to use a technique called Out-of-Band Data Retrieval discovered by the researchers Alexey Osipov and Timur Yunusov that allow the construction of a URL with data coming from other entities.

That looks like this:
Using the same technique I modified the Invitation.msrcincident file with the following XML:

Opening the modified Invitation.msrcincident file with our XML XXE payload resulted in the following:
The result is the contents of C:\Windows\win.ini are sent as part of a GET request to my server. If we URL decode the GET values sent to the server we get the following:

I just confirmed an XXE vulnerability affecting MSRA using the MSXML3 parser.

Conclusion

This XXE vulnerability can be genuinely used in mass scale phishing attacks targeting individuals believing they are truly helping another individual with an IT problem.
Totally unaware that the .msrcincident invitation file could potentially result in loss of sensitive information.
An attacker could target specific log/config files containing username/passwords.
GDSSecurity also made a tool to automate XXE exfiltration of multiple files by brute-forcing certain directory locations. The tool can be found here.

Intro

Late last year while setting up a fuzzer to target the SMB protocol, I discovered a vulnerability so simple yet so effective in disrupting large enterprises. TL;DR: A Denial-of-Service bug allowing to BSOD Windows 8.1 and Windows Server 2012

Intro

Late last year while setting up a fuzzer to target the SMB protocol, I discovered a vulnerability so simple yet so effective in disrupting large enterprises. TL;DR: A Denial-of-Service bug allowing to BSOD Windows 8.1 and Windows Server 2012 R2 machines with a one single packet.
Big thanks to Eric Schayes for joining me during the Root Cause Analysis.

Targets

The following vulnerability has been tested and validated on:

Windows 8.1 (x86)

Windows Server 2012 R2 (x64)

Background

To understand the root cause of this vulnerability, it is important to understand how SMB packets are built.
Let’ have a look on the SMBv1 header:
Source: https://msdn.microsoft.com/en-us/library/ee441774.aspx
As we can see, the protocol field begins with FF byte.
Now let’s check what’s happening with SMBv2
Source: https://msdn.microsoft.com/en-us/library/cc246528.aspx
The protocol field begin now with the FE byte.
What about SMBv3? The v3 of SMB protocol is encrypted and will use a specific header called SMB2_Transform for encrypted communications: SMBv3 is always encrypted, and as it can be learned in official documentation, the negotiation of SMBv3 session begin with a SMBv2 session.

Here are the packets involved in the setup of a SMBv3 session:
In the packets from 1 to 8, the SMB header looks like that:
As we can see, the byte sequence used is still 0xFE which is the SMBv2 code as indicate in Microsoft documentation.

From frame 9, encryption is on and the byte sequence used in the header will be 0xFD:
As you can see in the PoC, the crash happens when sending immediately a SMB packet with the 0xFD header without negotiating the session for the first time.
Let’s have a deeper look at crash dump to understand the root cause of this crash.

Root Cause Analysis

REMARK: the root cause analysis is only performed on Windows 8.1 (x86)
Sending a specially crafted packet causes a kernel panic, because it wants to read a value from memory which is protected (null page protection) on address 0x00000030.
The module where this crash occurs is “mrxsmb.sys” which is a Microsoft Server Message Block (SMB) redirector. The exact place of the crash is mrxsmb!SmbWksReceiveEvent+8539 where a move occurs from [ecx+30h] to register EAX, the value of ECX is pointing to 0x00000000.
When we follow the flow in IDA it looks as follows:
The packet is handled and check if encryption is enabled or not which relates to SMB 3.0 that uses encrypted SMB packets.
In WinDBG it looks like this:
Essentially it will check if encryption is enabled, if this is the case it will follow the “false” path and move to the next function:
It will perform some moves and the second last instruction a compare happens which will check if register ECX with hex value 0x34. If ECX is below or equal to 0x34 which in our case is false.
I will follow the “false” path:
Another compare instruction occurs and in this case if register EDX (attacker controllable value) is higher than the value of [ESP+4C] it will follow the “true” path
The next following instruction simply put values in the various registers:
The next instruction again compares the value of ECX with 0x34 and it will follow the “true” path if ECX is higher than 0x34.
In our case it will follow the true path since the value of ECX is higher than 0x34.
The following instruction block performs a test between the value of _Microsoft_Windows_SMBClientEnableBits to 0x80000000.
In WinDBG we can see that the test will result in a “false” and subsequently will follow the “false” path.
Leading us to a test instruction which will be always “true”, moving to function “locA0F20E05”.
After putting zeros on the stack it goes to function “locA0F20E15” in this case:
At instruction where it moved ECX+30h to EAX the crash occurs because ECX is 0x00000000 and it will try to read the value from 0x00000030 which is protected memory space.
This causes a kernel panic and will force the machine to reboot.
As you might have noticed there are number of times where our attacker controlled values were stored in various registers, but we did not find a way to use those registers to gain full control over the flow.

Late last year Tom and I were engaged in a security assessment which proved to be quite a challenge. We stumbled upon a very complex Single Sign-On (SSO) authentication scheme which consisted of 18 different request in order to access the resource that was requested.

After mapping and creating a flow chart of all the cookies and parameters that were used in these series of requests. By singling out the most important set of cookies we discovered that the “ObSSOCookie” was quite powerful and allowed authentication on various sets of web applications available.

After doing some quick research on the internet this cookie is related to the SSO implementation of Oracle Access Manager. Now that we know which cookie is the most critical one we need to find a way to get our hands on this super Cookie :).

Oracle OAM Authentication flow

Before proceeding we need to understand how a user authenticates on this Oracle SSO implementation.
As you can see in the image above the user requests a protected resource let’s say https://somewebsite.com/protected/, the OAM server simply validates whether the resource is indeed protected or not. (Steps 1 and 2)
The OAM server evaluates the request and responds back with a decision saying that the resource requested is indeed protected. The Oracle OAM server responds back to the user and redirects the user to a login page to collect credentials from the user.

The OAM Server sets the OAMREQ cookie in the user's browser, with the information that the requested resource is located at https://somewebsite.com. That way on the next request the OAM server knows for which resource the user is authenticating.

At this point the user will be on the login screen and needs to submit his credentials (even 2FA).
This brings us to the second part of the authentication flow.
As the screenshot above shows; the user submits its credentials and the OAM server verifies the credentials and serves back various cookies one of them being “ObSSoCookie” which is given to the user after successful logon.
The user submits his credentials, the OAM server validates its credentials. If the credentials are valid the OAM Server gives the user a cookie and a valid session and redirects the user to the protected resource.
The raw HTTP requests/responses look as follows:

So far the crash course in Oracle Authentication Manager, we can move on to the juicy stuff.

Hijacking the session

You might have noticed some obvious red flags in the request/response flow demonstrated above.

The parameter called rh=, which is the domain of the protected resource.

The cookie that is sent via a GET request...

Yes... in the GET request...

Now the challenge is to steal that cookie value and hijack the user's session.
But according to Oracle documentation the OAM server validates whether the resource is protected or not therefore asking a resource that doesn't exist should fail on first glance...

Our request will ask the OAM server to give us access to http://localhost/this/does/not/exist.html which doesn't exist at all...
Instead of complaining the OAM server redirects us to the login screen and asks for our credentials... this looks promising :)

We received an OAMREQ cookie from the OAM server, this will be used by the OAM server to determine where to send the user after successful authentication!

However still having a lot of doubt that this will work, because why would OAM Server give us a valid set of cookies to authenticate against a non-existing resource...

Anyway we submitted our credentials...

To our surprise we get a redirect from the OAM server to something like:

http://localhost/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE>

Wait... did we just receive a cookie for a non-existing resource??

Maybe we just received a cookie only to work for http://localhost and the cookie wouldn't work on the real resource...

We changed the GET request from http://localhost/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE> to http://<valid_domain_of_proteced_resource>/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE>

Since we can control where the user has to go and since we also can read the cookie value that is coming from the user we can hijack his session...

All we have to do is entice the victim to click on the link that we provide him and log in, since he's logging in on the real login portal we are not raising any suspicion. If the user is already logged-in we will get his cookie without a problem and the victim won't notice a thing!!

Global Exposure

It started us thinking maybe this might be a stand-alone case of misconfiguration and this would be impossible to abuse on another OAM 10g setup.

Boy were we wrong about that statement...

We found hundreds of hundreds of high profile organisation with the same misconfiguration, all of them exposed against session hijacking. We analyzed 100 high profile domains and only 1 was properly secured against this attack! Unfortunately we cannot share the domains that are affected, but if you look for it you'll be able to find them.

We started looking for an organisation that used OAM SSO scheme with a similar setup and had a bug bounty program running. We quickly stumbled upon https://my.telekom.ro which is from Deutsche Telekom.

Users that want to access my.telekom.ro website get a redirect that looks as follows: https://my.telekom.ro/oam/server/obrareq.cgi?wh%3DIAMSuiteAgent+wu%3D%2Fms_oauth%2Foauth2%2Fui%2Foauthservice%2Fshowconsent+wo%3DGET+rh%3Dhttps%3A%2F%2Fmy.telekom.ro%3A443%2Fms_oauth%2Foauth2%2Fui%2Foauthservice+ru%3D%2Fms_oauth%2Foauth2%2Fui%2Foauthservice%2Fshowconsent+rq%3Dresponse_type%253dcode%26client_id%253d98443c86e4cb4f9898de3f3820f8ee3c%26redirect_uri%253dhttp%25253A%25252F%25252Fantenaplay.ro%25252Ftkr%26scope%253dUserProfileAntenaPlay.me%26oracle_client_name%253dAntenaPlay

Clicking on the link above will redirect the user to: https://my.telekom.ro/ssologin/ssologin.jsp?contextType=external&username=string&OverrideRetryLimit=0&contextValue=%2Foam&password=sercure_string&challenge_url=https%3A%2F%2Fmy.telekom.ro%2Fssologin%2Fssologin.jsp&request_id=-9056979784527554593&authn_try_count=0&locale=nl_NL&resource_url=https%253A%252F%252Fmy.telekom.ro%253A443%252Fms_oauth%252Foauth2%252Fui%252Foauthservice%252Fshowconsent%253Fresponse_type%25253Dcode%252526client_id%25253D98443c86e4cb4f9898de3f3820f8ee3c%252526redirect_uri%25253Dhttp%25253A%25252F%25252Fantenaplay.ro%25252Ftkr%252526scope%25253DUserProfileAntenaPlay.me%252526oracle_client_name%25253DAntenaPlay

Where the user has to submit his credentials in order to gain access to his information. If we change the first request as follows:

We entice the victim (e.g. via phishing mail) to click on the link (which on first sight looks perfectly legitimate), it is important to note that all SSL communication remains intact, we are not setting up any other website to capture credentials like in a traditional phishing campaign.
He/she will be redirected to the login page and will be asked to submit their credentials. After submitting the credentials the server will reply back with a HTTP 302 redirect pointing to http://our_malicious_domain.

Our webserver on "http://our_malicious_domain" will steal the users cookie and use it log in on his account and finally our webserver will send a redirect to the victim with the same cookie information to the appropriate domain.
The result is that both the attacker and the victim are logged in, both sessions are independent from each other and most importantly the victim will never notice that something is wrong.

CVSS rating

]]>This is the presentation video from the HIP 16 presentation Tom and I did earlier this summer.
I hope you enjoy it!
]]>http://krbtgt.pw/video-hack-in-paris-2016-from-zero-to-system-on-fde-windows-system/8ec2a336-718e-4e2c-a792-508117fd92deThu, 08 Sep 2016 09:21:13 GMTThis is the presentation video from the HIP 16 presentation Tom and I did earlier this summer.
I hope you enjoy it!
]]>http://krbtgt.pw/abusing-kerberos-to-ntlm-fallback-to-defeat-windows-authentication/bc98ae8b-b89a-4c14-9972-5c325e852a28Thu, 11 Aug 2016 01:45:35 GMTIntro

This vulnerability is related to the initial vulnerbility which I and my collegue Tom found back in February, namely the Microsoft Security Bulletin MS16-014.
More information about the MS16-014 attack can be found in my earlier blog post here.

Bypassing patch MS16-014

Past experience tells me that Microsoft doesn't always properly patch the vulnerabilities correctly. (see MS15-122 and MS16-014)
That being said I was rather sceptic if they fixed it well this time. So I starting thinking of different scenarios which could lead to new exploitation ways.

After spending a few days testing out different scenarios I was coming up empty handed. Well maybe they did fix it well this time? =)
The last scenario that was on my list was "What would happen if a KDC goes down in the middle of a password change process?".

I had setup a rogue DC which was untrusted by the client and would not allow me to perform the password change. However it still allowed me to get to the password change step.

So I reset the password of the user on the fake domain controller, the user corresponds with the user that has been logged on in the past (credentials are cached!).

I go back to the client machine and type in the password I just set as "expired" and you get the following:

Followed by:

At this point I decided to block all Kerberos traffic from reaching the "rogue" Domain Controller by using Window Firewall:

Went back to the client and pressed "Enter" to start the password change procedure:

And I waited... and waited...

Then suddenly...after 6 minutes...

It worked!??

How/Why did it work?

To get the answer to the question I had to look at the traffic.
So again I reset the account and went to all the steps and started to look at the Wireshark captures.

After going quickly through the wireshark capture, I can see that the client machine is sending a bunch of retransmissions on port 88 which is the port used for Kerberos communication. After 6 minutes it falls back to NTLM and tries to change the password.
So Microsoft fixed the trust relationship issue with Kerberos (MS15-122/MS16-014) but didn't change it for NTLM.

But why 6 minutes?
As an attacker you want the attack to be completed as fast as possible to avoid detection of some sorts!
The 6 minutes has to do with the TCP Connect Timeout value, for Windows the default is set to 72 seconds for initial connections and has a default of 5 retransmissions before timing a connection out.

72 sec x 5 = 360 sec / 6 minutes.

So I started playing around with the timeout, in the hope there is some sort of improper handling on the client side that makes it fallback much faster.
So i tried 30 seconds, blocked the ports 88 and 464 in Windows Firewall.
Continued with the password change on the client machine and allowed the ports again. No luck :(
So stepped it up to 1 minute... and it worked!??

Now I needed to know why it falls back to NTLM after just 1 minute?
I don't have a clear answer to that question and Microsoft has been very vague about the details. However I think it is some sort of race-condition, when it sends the 5th retransmission it starts to look for other ways to complete the password change request.
So when I enable the Kerberos ports again it skips Kerberos and goes into NTLM eventhough the TCP Connect Timeout value is has only been expired for the first retransmission.

However for my point of view it's still unclear what exactly is causing the speed up the Kerberos to NTLM fallback procedure. If you think you know the answer feel free to contact me on Twitter or send me an email.

Again this vulnerability wasn't too complex to find but still required some out-of-the-box thinking. It's a sneaky and dirty way to defeat BitLocker FDE, especially like this.

PoC Demo

Timeline

Vulnerability discovered (23rd of February 2016)

Disclosed vulnerability details to MSRC (4th of April 2016)

Vulnerability acknowledged (25th of June 2016)

Vulnerability patched (9th of August 2016)

]]>Intro

On the 30th of June, Tom and I gave a presentation at Hack In Paris about the vulnerabilities we discovered and which could be abused to bypass BitLocker FDE.
These slides were used during the presentation a video of the presentation will be released soon and I will update

On the 30th of June, Tom and I gave a presentation at Hack In Paris about the vulnerabilities we discovered and which could be abused to bypass BitLocker FDE.
These slides were used during the presentation a video of the presentation will be released soon and I will update this post when that happens. :)

This blog post is a continuation of my previous post which can be found here.
The reason I devided is because two seperate vulnerabilities come in to play in order to successfully retrieve the original user password and install your favourite malware :)
So without further ado, let's escalate our privileges to SYSTEM.

Step 3 – Privilege escalation to SYSTEM

We know that the trust between the client and Domain Controller (DC) is not always properly validated, we have a working Active Directory set-up and we have a working rogue DC.
The question is are there any other Windows functionality that is failing to properly validate the trust?

How about Group Policies?

It works on all supported Windows versions

There is no need for any additional (vulnerable) software

No specific configuration requirements

There are 2 types of Group Policy Objects (GPO), Computer Configuration and User Configuration Policies.

Computer Configuration Policies are applied before logon, the machine account is used to authenticated to the DC in order to retrieve the policies and finally all policies are executed with SYSTEM privileges. Since we don't know the machine account password using Computer Configuration Policies is not an option.

However User Configuration Policies are applied after a user is logged in, user's account is used to authenticated to the DC to retrieved the User Configuration Policies and the policies are either executed as the current logged-on user or as SYSTEM.

Now this last type of Policy is interesting because we know the password of the user as we reset it to our likings. (see Part 1)

Let's create a Scheduled Task GPO that will execute NetCat as SYSTEM and finally will connect to the listening NetCat service as a the current user.
The "Listen" Scheduled task will simply run NetCat with the following command-line argument:

nc.exe -l -v -p 3333 -e cmd.exe

In the Security options you can select NT AUTHORITY\System as the user account that will be used to run this scheduled task as shown below.

eThe "Run" Scheduled task will be simply connect to port 3333 using the following command-line argument:

nc.exe 127.0.0.1 3333

You run this scheduled task as the current logged on user.

Windows 7

Now that we have a GPO that will execute some Scheduled Tasks, let's see if it works right out of the box?
Unless if there is some sort of trust validation implemented before the GPO is executed there is honestly no reason why this shouldn't work right?

Let's force a Group Policy Update on our Windows 7 client...

GAME OVER! =)

At this point I notified Microsoft (November 25th 2015) about this issue and they acknowledged (January 27th 2016) the problem and started working on a patch.

So why did it work?

Windows 7 fails to validate if the DC from where the Group Policies are being applied is indeed a trusted DC.
It is assumed that the user credentials are sufficient to acknowledge the trust relationship.
In this attack all encrypted traffic remains intact and doesn't require any modification whatsoever.

Is this really new?

Early last year in March 2015 a security researcher called Luke Jennings from MWR Labs demonstrated how he could gain SYSTEM level privileges through a Man-in-The-Middle attack.
By modifiying the SMB calls he was able to execute his own malicious code to get higher privileges. Microsoft responded with two patches MS15-011 and MS15-014.

Jennings conclusion was the following:

Even on Vista/2008 onwards, user settings group policy can be exploited if you know a user’s password to conduct a form of privilege escalation to gain SYSTEM on domain members. Microsoft have shown no intention thus far of providing a control to protect against this.

Windows 8.1 and 10

We know that Microsoft was aware of the fact that group policies could be abused to gain SYSTEM privileges, so maybe ... they implemented some additional security features in newer versions of the Windows OS.

Let's take Windows 10 and simply do the same as we did in Windows 7 and force a group policy update.

It didn't work :'(
As you can see it does however say that the User Policy update was successful but still throws out an error during policy processing.

Let's review the event log as the error suggests for any hints.

Looking around on the internet for "EventID 7016" and "ErrorCode 2" didn't help me any further.
Maybe there were any changes in the communication between the DC and the Windows 10 machine.

Below you can see the basic LDAP operations performed when a group policy update is requested on Windows 7.
Nothing out of the ordinary, basic LDAP operations such as Bindrequests, BindResponse, SearchRequests and SearchResponse.

LDAP Windows 10

As you can see in the screenshot below there is a new request added to the LDAP calls. It is a SearchRequest LDAP operation that requests a lookup for the SID (S-1-5-21-114261664-662940058-2894158534-1104) of the current logged-on user on the client machine.
If you look closely you can also see that the response fails, because this particular SID does not exist (NO_OBJECT error) on our rogue DC.

So we need to tackle this by setting the correct SID with the corresponding user on our rogue DC. There are however some difficulties.
If you are familiar with SIDs, you know that an SID of a domain user consists of a Domain Security Identifier (Domain SID) and a Relative Identifier (RID)
In our case "114261664-662940058-2894158534" is the Domain SID and "1104" is the RID.
Domain SIDs are randomly generated everytime a new Domain forest is created so matching it correctly is tricky. There are however multiple ways to still set it to the SID you want:

Change Machine SID to the one you want before promoting Server to PDC of a new domain

Use SAMBA NT4 Server, change the SID, upgrade it to SAMBA AD-DC

Use commercial tools (SIDCHG)

However these techniques are lengthy, complex and prone to errors.

On May 6th 2016 Mimikatz developer Benjamin Delpy (@gentilkiwi) pushed a new version of Mimikatz with a new added module.

Mimikatz makes it possible to lookup, query, modify and add SIDs to various objects.

Let's change the SID of the user on our rogue DC to the one matching on the client.
Run Mimikatz as Administrator and run the following commands:

privilege::debug

sid::patch

sid::modify /sam:[domainuser] /new:[new_sid]

NOTE: replace values between brackets accordingly

Now that we have changed the SID of the user object on our rogue DC let's try and force a group policy update again.

gpupdate /target:user /force

IT WORKS!! ^^

Congratulations! Now you have the keys to the kingdom ;)

MS16-072 / CVE-2016-3223

After long 8 months Microsoft released a patch for this vulnerability on the 14th of June 2016.
And then this happened:

Microsoft still managed to break lots of Group Policy configurations around the world.
The patch changes the behaviour of how GPOs are being retrieved.
As previously mentioned user accounts were used to retrieve User Configuration policies, however after the patch the machine account is used to retrieve both the User and Computer Configuration policies.
Microsoft forgot to mention that the Computer objects need to have read access in order to retrieve the Group Policy configuration files.
More information about the issue can be found here.

Bypassing patch MS16-014

Yes, you've read it right! There is still a way to bypass the Windows Login screen and bypass Authentication ;) More details will be released soon!
You can read the details here

Whether you want to protect the operating system components or your personal files, a Full Disk Encryption (FDE) solution allows you to keep track of the confidentiality and integrity. One of the most commonly used FDE solutions is Microsoft Bitlocker®, which due to its integration with the Trusted Platform Module (TPM) as well as the Active Directory environment makes it both user-friendly and manageable in a corporate environment.
When the system is protected with a FDE solution, without a pre-boot password, the login or lock screen makes sure attackers with physical access are not able to gain access to the system.
In this post we will explain how an attacker with physical access to an active directory integrated system (e.g. through stealing) is able to bypass the login or lock screen, obtain a clear-text version of the user’s password and elevate his privileges to that of a local administrator or SYSTEM. This can be accomplished via two security vulnerabilities which affects all Windows versions (from Vista to 10) and abusing a standard “security” feature.

Step 1 – Hibernation – Your friendly neighbourhood password dumper

Speaking for myself, and probably a lot of other users, shutting down a laptop has become a thing of the past. In order to be able to rapidly start using your system when travelling from one place to another, we put it into sleep (or hibernation) mode, essentially putting all processes on hold to be easily resumed when needed.
Although in order to resume your session after sleep or hibernation, you’ll have to enter your password on the lock screen (or at least I hope so), the system has your password stored somewhere in memory in order to resume the different processes. We want the system to dump the contents of the memory on disk so we can recover it later. Hibernation is there to the rescue, but we need to be able to force the system into hibernation, creating the HIBERFIL.SYS.
Luckily, the default configuration of a laptop running Windows depicts going into hibernation if the battery hits a critical low. This feature, by default at set 5%, ensures you don’t lose any unsaved documents when your battery dies.

So the first step, in case the laptop is running but put in sleep (or hibernation), is letting the battery die by playing the waiting game...
Once we force the laptop into hibernation mode we reboot it and move to the next step.

Step 2 – Bypassing the login or lock screen

Before we move on, we would like to give credit to Ian Haken, who discovered the original vulnerability affecting Windows Authentication. He presented his findings at BlackHat Europe 2015 which inspired us to investigate further.
In order for the original attack to work, the following prerequisites should be met:

The target machine is member of a Windows domain

The domain user (the target) has previously logged into the machine and his password is cached locally

If these conditions were met, an attacker needed to create a rogue Kerberos server with the targets user account’s password set to a value of choice and indicated as expired.
Upon login attempt, Windows would then prompt the user to change the password before continuing.

Once the password change procedure is completed, the cached credentials on the machine are updated with the new password set by the attacker.
Because the system is not able to establish a secure connection, the password is not updated on the Kerberos server but still allows the attacker to login when the system no longer has an active network connection (using the cached credentials)

A pretty straight forward attack but the vulnerability has been out there for years overlooked by many people.
Now that the original vulnerability is clear, we want to explain how we managed to bypass this. (More information about the original vulnerability can be found in Ian’s whitepaper here.)
The original patch which was rolled out by Microsoft (KB3105256 - Microsoft Security Bulletin MS15-122) actually changes the flow of the password change feature. It first checks if there is a trust between the domain controller and the target machine before changing the password on the target machine.

We had to find a way to make the workstation believe the Kerberos server, in our case a rogue Windows domain controller with the same FQDN is a genuine one.
In a normal situation, when a computer joins a domain a computer object is created in the active directory which holds various attributes from this system. One of those is the Service-Principal-Name (SPN) attribute which is used for mutual authentication with an instance of a service on the workstation.
This SPN is the name by which a client uniquely identifies an instance of a service.
Knowing that this information is used to establish mutual authentication we created a computer object with the name of our target machine (which can be easily found). We then moved on to change the servicePrincipalName attribute by adding the following values:

HOST/computername

HOST/computername.domain

Now follow the same procedure as before (change the user’s password and mark it as expired) and you will be able to change the change the cached password. Disconnect the system from the network and use the newly set password to bypass the login screen and gain full access to the system as the original user.
Although the authentication has been bypassed, we still only have the (limited) privileges of the victim’s account (taking into consideration this is not an local administrator). This is where the next step comes in, in which we explain how you can obtain full local administrative privileges just by using standard Windows functionalities and thus not relying on any vulnerable installed software.

Step 3 – Privilege escalation to SYSTEM

At the time of writing, the vulnerability has not yet been patched by Microsoft and thus cannot be disclosed. Once more information can be safely shared, this post will be updated.
Read it here.