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.
- Windows 10 20H2 is used, rather than Windows 7
- Chromium Edge is used, rather then IE
- Device is onboarded Defender for Endpoint
- Device is managed by Endpoint Manager
- 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:
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.
With SmartScreen set to not prevent override, the user is able to choose the ‘Wrong’ option here, and Keep the file.
SmartScreen doesn’t give up that easily though. After choosing Keep, the user is prompted once again to understand the choice they’re making.
The default option here is Delete, with “Keep anyway” hidden under a “Show more” expander link.
Finally, the user clicks “Keep anyway” and…
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.
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…
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…
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…
So, with that Block removed… let’s try again.
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 >
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.
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.
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: