In Day 4, I experimented with gaining meterpreter and shell access to a Windows client, and using a module to gather secrets in plaintext from wdigest.
Today I’m going to cover how the same exploit could be blocked by making use of the free Security Baselines available in Endpoint Manager

Firstly, I’ll go through the major differences between my initial successful attempt, and this one.

  1. Windows 10 20H2 is used, rather than Windows 7
  2. Chromium Edge is used, rather then IE
  3. Device is onboarded Defender for Endpoint
  4. Device is managed by Endpoint Manager
  5. Standard Win10 and Edge Baselines are applied

Delivering the payload

In Windows 7, I delivered the payload by serving the file on a webserver and encouraging the user to click the link, download and run the file. In Windows 10, the experience is substantially different:

Windows 7 / Internet Explorer prompt when downloading payload.
Windows 10 / Edge prompt when downloading payload

As you can see, SmartScreen makes it very difficult for the user to make the wrong choice here.
The “Keep” option shows a briefcase icon, indicating this option is “managed by your organisation”.
In this instance, the attacker would need to try a different method of delivering the payload, perhaps via email.

The specific setting (Prevent bypassing of Microsoft Defender SmartScreen warnings about downloads) preventing my payload delivery is within the Microsoft Edge Endpoint Security baseline, so I’ll switch this to Disabled for the purposes of this discovery exercise.

Microsoft Edge baseline policy

With SmartScreen set to not prevent override, the user is able to choose the ‘Wrong’ option here, and Keep the file.

Option to Keep now available

SmartScreen doesn’t give up that easily though. After choosing Keep, the user is prompted once again to understand the choice they’re making.

Additional warning when choosing to Keep the file, before it’s even downloaded.

The default option here is Delete, with “Keep anyway” hidden under a “Show more” expander link.

Finally, the user clicks “Keep anyway” and…

Download is prevented due to the virus in the payload.

So the download still didn’t work. It appears Defender has stepped in and, detecting the Meterpreter trojan, has told Edge to fail the download. I have to admit, the integration here is really neat. I can imagine any other AV simply deleting the file without warning, and leaving the user unsure as to the problem.

Defender “threats found” message

Choosing “Allow on device” requires Admin elevation, after which Defender identifies another Trojan signature which also needs to be “allowed”.

Finally, the download completes. The file is sat in my test user’s Downloads folder, ready to be run…

Defender to the rescue once again…

Having run the payload executable, Defender SmartScreen prevents the unrecognised app from starting, and doesn’t allow the user to ignore the warning. Back to Endpoint Manager…

Block users from ignoring SmartScreen warnings

The Windows 10 Security Baseline includes a setting which prevents users from ignoring a SmartScreen warning. Now that it’s been removed, we’ll try running that file again…
I don’t mind telling you, SmartScreen continued to block it.
Back to Endpoint Manager…

Once again, Defender Smart Screen saves the day…

So, with that Block removed… let’s try again.

Run Anyway now available

Success! I can now override the Smart Screen warning.

Executing the exploit

Running the app, my meterpreter session springs into life…

[*] Started reverse TCP handler on 172.16.31.148:1337 
[*] Sending stage (175174 bytes) to 172.16.31.151
[*] Meterpreter session 1 opened (172.16.31.148:1337 -> 172.16.31.151:63703) at 2021-01-13 22:35:23 +0000

meterpreter > 

Until…

Defender to the rescue…

Enterprise Unwanted Application decides that my organisation doesn’t want me to run this particular app, and promptly kills it. See? Dead.

meterpreter > 
[*] 10.0.0.102 - Meterpreter session 1 closed.  Reason: Died

The file was even removed from the Downloads section.

So what now? Back to Endpoint Manager of course.

The default setting configures Cloud-delivered protection to High, and PUA action to Block

Having disabled these two items, it’s time to try again.

[*] Started reverse TCP handler on 172.16.31.148:1337 
[*] Sending stage (175174 bytes) to 172.16.31.151
[*] Meterpreter session 3 opened (172.16.31.148:1337 -> 172.16.31.151:64050) at 2021-01-13 23:08:59 +0000

meterpreter > getuid
Server username: AzureAD\LeeGu

Success! I now have meterpreter access as my target user, LeeGu. Next, I’ll need SYSTEM access to be able to run my next exploit. Here we go:

meterpreter > getsystem
<LONG WAIT> 
[-] Error running command getsystem: Rex::TimeoutError Operation timed out.
meterpreter > 
meterpreter > 
meterpreter > 
[*] 10.0.0.102 - Meterpreter session 3 closed.  Reason: Died

Another failure, following quickly by a killed session. No prompts were shown on the target device during this attempt, but it’s success was short lived.

In summary…

Compared to my successful attempt to gain privileged access to my domain joined, SCCM managed Windows 7 machine, this was much more difficult. Running the same tools, with the same techniques, I had to:

  • Allow the user to ignore the Smart Screen warning when downloading the file
  • Allow the user to ignore the Smart Screen warning when running the file
  • Manually “allow” the threat in Defender


Here’s a sneak peek into Part 2:

/Dean

Leave a Reply