Alright, since I happen to be in a blog mode I keep the posts coming.
This post continue to explore the hunting capatibilities in Defender ATP by query for Exploit Guard detections.
So what’s this Exploit Guard?
Windows Defender Exploit Guard is a new set of intrusion prevention capabilities which are built-in with Windows 10, 1709 and newer versions.
Exploit Guard consists of 4 components which are designed to lock down the device against a wide variety of attack vectors and block behaviors commonly used in malware attacks, while enabling enterprises to balance their security risk and productivity requirements
Attack Surface Reduction (ASR)
A set of controls that enterprises can enable to prevent malware from getting on the machine by blocking Office-, script-, and email-based threats
Protects the endpoint against web-based threats by blocking any outbound process on the device to untrusted hosts/IP through Windows Defender SmartScreen
Controlled Folder Access
Protects sensitive data from ransomware by blocking untrusted processes from accessing your protected folders
A set of exploit mitigations (replacing EMET) that can be easily configured to protect your system and applications
Example of ASR rules
• Block Office apps from creating executable content • Block Office apps from launching child process • Block Office apps from injecting into process • Block Win32 imports from macro code in Office • Block obfuscated macro code
Exploit Guard is configured through MDM (Intune) or SCCM or GPO’s or PowerShell.
If you have Microsoft 365 E5 license or Threat Protection license package, you don’t have to use Windows Event Forward to get the events in a central log solution. They will automatically be forwarded to your Microsoft 365 security portal https://security.microsoft.com where you have a nice looking dashboard where you can see alerts and configurations of ASR and other things.
This following dashboard is a part from the Monitor and Report section in the portal
Back to Defender ATP and the hunting which this post was supposed to be all about.
We have published some posts now about hunting custom alerts.
In the query console in Defender ATP we started to go backwards to find the ASR events. It’s simple. configure your client, run a few attacks which will trigger the alerts.
We looked in the MiscEvents for all events (filtered on computername and time). Which gaves us ideas of ActionTypes to use in the query.
Examples from the output:
Interesting note “SmartScreenUserOverride” is a separate event which you can query
When we had the raw Actiontypes we created the query to cover as much as we could.
| where ActionType contains "asr" or
ActionType contains "Exploit" or
ActionType contains "SmartScreen" or
ActionType contains "ControlledFolderAccess"
| extend JsonOut = parse_json(AdditionalFields)
| sort by EventTime desc
| project EventTime, ComputerName, InitiatingProcessAccountName, ActionType,
FileName, FolderPath, RemoteUrl, ProcessCommandLine, InitiatingProcessCommandLine,
We are also parsing AdditionalFields to be able to add extra value to events which contained such data.
From this point we can do additional filters. For example, if you want to enable ASR enterprise wide, set them in auditmode and report on the alerts without affect user productivity, remediate and the do a enterprise wide block enrollment
The feature Sandbox available in Windows 10 preview version is very intersting for us who uses a web browsing VM.
The Sandbox feature or disposable VM is a Windows 10 container running on your Windows laptop and gives you the opportunity to launch a temporarily VM if you want to test something or just use it to browse internet to avoid infecting your machine (see the “note” later in this post because bad things can still happen) .
When you close the application all files are removed and possible malware will die.
You might want to test the feature on a VM, which will basically be running VM on a VM (nested).
If you open features you will see that the feature is grayed out and you won’t be able to enable it that way however you can enable the service with DISM.
But when you launch Sandbox it will complain.
To solve this you have to make a change on the VM CPU where you want to run Sandbox.
The only thing you have to do is enabling “Expose Virtualization Extensions”
This feature is perfect instead of using and manage a VM for this kind of work.
Launch Sandbox as any other applications
Note: You will still have access to resources on the network. Therefore malware can still execute and do bad things. But they will not survive a reboot of the Sandbox but they might have already replicate themselves to another system. You can reach other systems via RDP. If you have your host enrolled to WD ATP, and you isolate the host, the Sandbox will still be available The AV Engine doesn’t seem to be running either
But regardless of the “Note” it’s still a very interresting feature and it will help a lot
When you exit the application you will be prompted that all data will be lost
This is a high priority patch for your Windows DHCP server. This RCE is executed by sending a speciallly crafted packet to the DHCP server. We haven’t seen any public available information like Proof of concept or exploit code but that’s just a matter of time.
The Microsoft Security Response Center (MSRC) is pleased to recognize the security researchers who have helped make Microsoft online services safer by finding and reporting security vulnerabilities. Each name listed represents an individual or company who has privately disclosed one or more security vulnerabilities in our online services and worked with us to remediate the issue.
Both Stefan Schörling and Mattias Borg from SEC-LABS R&D is recognized at the Microsoft Security Response Center security researchers list for August 2018.
This was due to a vulnerability discovered with Johan Dahlbom and was reported to Microsoft.
We would like to give our appreciation to the MSRC team and it was a pleasure working with you to resolve this issue!
Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):
Basically all Wireless networks are vulnerable and the vendors are working to get the patches out.
Microsoft was mitigating this on the client side in the October patch release cycle
If you won’t get an update to your router your really only option is to get a new one (if it’s out of support)
Recommendations are to apply patches as soon as they’re available.
A VPN solution which had a device verification functionality which is all fine but the problem was that the verification is executed only on the client side.
And you don’t only want to protect from external attackers but also users connecting their home PC to the internal network.
We only want managed devices on the inside and one unmanaged home device with i.e. no AV and lots of keyloggers and other malicious code running.
When this kind of verifications are executing on the client side there is no guarantee that the outcome is correct (which is why certificate based authentication is prefered as one of the factors since you can assure that it’s your internal device)
In this example there was a client side verification which was querying (amongst other things) a file on the local system.
The endpoint compliancy failed due to some security setting
Let’s do the same thing again with procmon running
The service tries to query for a file in the c:\windows\system32 folder xxx.dll
So we create an empty dummy file, xxx.dll.
When we try to connect again with process monitor running we have a different result.
And we are prompted for user name and password, and hopefully this customer has an extra factor of protection, like SMS or certificate
Certificate is the best way to verify a device, to verify a user it depends on your identity management and how you choose to manage the identities and how to verify them