I am often finding myself discussing Windows Defender Advanced Threat Protection (WDATP) with clients of late. I want to discuss briefly what Windows Defender ATP is (and isn’t), and illustrate the behaviour of some of the main features of WDATP. I’ll include some screen-grabs of the automated investigation and remediation capability, as well as how it integrates with Office 365 Threat Intelligence (O365TI) and Azure ATP (AzATP) to provide investigation capability across all of these 3 platforms. This blog isn’t a technical step-by-step or how-to walkthrough, rather just clarifying what WDATP is and illustrating some of it’s key features for those who may be interested in the product and want to know a bit more about it.
Something I want to briefly talk about is a point which customers are sometimes not quite clear about; that is, conceptually, WDATP provides advanced threat detection, preventative protection and remediation for your clients, say for example, in the case where a threat is not detected by the endpoint antivirus on a client or other tiers of protection. WDATP acts as a central administration console to manage this functionality. Clients are onboarded to the WDATP tenant via a simple deployment script (that can be run manually, by group policy, Config Manager, Intune, etc.). Once this is done, clients upload relevant data, events, etc. to the tenant where WDATP can then analyse, report and take actions on any detected threats. WDATP is obviously built to be used in conjunction with the Windows Defender client and sensors built into Windows 10, but it can be used with third party endpoint protection products also. I wanted to talk about these general distinctions because often when discussing this product, it is assumed that WDATP is a new version of Windows Defender, which isn’t the case. Windows Defender has improved dramatically in its own right by the way and is well worth a look. This article talks about this topic.
Also, AzATP is actually the cloud-based version of Microsoft’s Advanced Threat Analytics (ATA). This naming convention can be confusing so it is just something to be aware of. Being the cloud version of ATA, architecturally it is obviously different, however the functionality is similar. For more information on AzATP refer to What is Azure Advanced Threat Protection? In terms of functionality and detection, you can also refer to my previous blog post Advanced Threat Analytics – Demonstrating Attack Detection, which is based on the on-premises version of the product, but as I mentioned, has similar functionality.
All 3 features (WDATP, AzATP & O365TI) are a part of the Microsoft 365 E5 suite, comprising of Office 365 E5, EM+S E5 and Windows 10 E5. Whilst stand-alone SKUs are available for the Office 365 and Azure advanced features, WDATP can only be purchased as part of the Windows 10 E5 SKU currently.
The screen-grabs that I’ll show below are from running one of the simulation tutorials from the WDATP portal. In the simulation, a Word document is received via email and opened. The document is weaponized with crafted macro code which silently drops a malicious executable file onto the machine (benign executable file for the simulation.) The executable is a backdoor file that attains persistence on the machine using an ASEP run key registration (that runs every time machine starts up) and a scheduled task (to run the code straight away). The benign simulated attack activity stops there, which is enough to demonstrate WDATP alerting.
Below is the landing page for the WDATP portal. As can be seen at the top, after I have run the simulated attack, there are active alerts, so I click here to display the existing alerts.
Notice the other areas in the dashboard, i.e. the automated investigation tiles (which I will get to), as well as machines and users at risk. You can click on either of these to start investigating in the context of the entity you clicked.
Clicking on the alerts takes me to the information displayed below. Highlighted are 2 alerts related to running the attack simulation.
Clicking on one of the alerts takes me to the page displayed below. From here you can take click on ‘Actions’ to manage or investigate the alert further. Information is displayed about the alert process tree also, which is an ordered representation of the processes and events involved in the alert. You can drill down further on these also.
Something I find helpful is the navigation display at the top (shown in the screen-grab below), which displays the areas you have drilled down on, and clicking on any one of these will take you back to that area. When you are investigating an alert, you can drill down on hyperlink after hyperlink, which provides good information obviously, but you can quickly drill down many levels, so this comes in handy to keep track of where you are and how you got there.
Next I will click on the link at the bottom to look at the machine timeline. Note the highlighted area informing that an Automatic investigation (with an ID of 4) is running. I’ll come back to that.
Flowing on from the alert into the context of the machine timeline, you can see that there are other alerts relating to the machine. In a real-life scenario from here, given there are multiple alerts on the one machine, you may choose to isolate the machine by clicking the ‘Actions’ button. This will stop the machine from connecting to any other network resource/endpoint with the exception of the WDATP service, so that the investigation and remediation work flows can still happen.
Also note that with an alert selected (see the highlighted alert below), the timeline displayed at the bottom is in the context of the time around that alert, so you can see the events immediately before and after it to assist in getting an idea of what is happening. This is helpful as there are heaps of events collected for each machine.
Note the highlighted link to Check Azure ATP Integration. I do not have this enabled in my lab environment (requires on-premises AD), but if it was enabled you could click this link to Azure ATP to enter that portal and investigate related activities there.
In the above picture, clicking on the little icon highlighted next to ‘powershell.exe’ in the timeline expands that event to show more detailed information in the screen-grab below. This can be done with many events in the timeline. Notice below it gives detail regarding the actual powershell command that was run and the malicious code program (WinATP-Intro-Backdoor.exe).
After reviewing this information, I navigated back to the alerts page, where I started from. Notice below the highlighted ‘Investigation State’ of the alerts indicating ‘Running’. I have enabled full automated remediation for the machine in question to display this feature. I can click on the icon next to ‘Running’ in the picture to go to the automatic investigation page.
The automated investigation page links all an incident’s related entities, threats and logs into a graphical representation, and provides detailed information under each tab. The below screen grab was taken as the automatic remediation was in progress for the above 2 alerts. If more machines were related to this incident they would be displayed below also.
More information is added to the graph and in the detailed tabs as the investigation proceeds, until ideally the threat(s) are fully remediated, which is what is displayed below.
And the Automated Investigation page shows the completed status also.
Remember that you can drill down on all the related entities of an alert or investigation (user, machine, file, etc.). For example, the below diagram is in the context of the file (containing the malicious code) that was emailed to the user to start this simulated attack.
From here you could use the ‘Action’ button to block the file if you thought that was an appropriate measure.
You will also note that at the bottom of the above screen-grab, another machine is also alerting that it has the same or similar file related to the previous alert. I went back to the relevant alert and in the incident graph of the alert shown in the below screen-grab, this machine was now displayed within the same incident as shown. From here you could then go and investigate and manage this further by clicking on the link to the machine, checking automated investigations, etc.
Also notice from the file information screen-grab above, that information is displayed about the file prevalence in mailboxes (extracted in below screen-grab), listing the affected mailboxes and providing a link (highlighted) to the Office 365 Security & Compliance portal. This functionality is provided by the integration between WDATP and O365TI. I will click on this link.
In the Office 365 Security & Compliance portal under ‘Threat Management’ I can manage the affected mailboxes, choosing, for example, to Hard Delete the mail message with the attached file from the affected mailboxes as shown in the screen grab below.
Going back to the executable file that was dropped on the machine as a part of this simulation, I could have selected to block or stop and quarantine the file on onboarded clients, as shown below.
On the Windows Defender client, when this file was detected again, note the below threat details in the Windows Defender logs, in particular the details indicating it is blocked due to the WDATP policy.
I hope this has helped to provide some high-level guidance of what Windows Defender ATP is for you and how it relates to other services and clients. I have heard that there will be some announcements made mid July by Microsoft regarding updates to WDATP, AzATP and Office 365 ATP (the 3 ATP’s), so we’ll look to post another blog about these new features not long after then.