Forensics Blog: Unmasking Private Browsing
Embedded Files
What is Defender for Endpoint?
Like you didn't know already, but for blog completeness here's an intro:
Defender for Endpoint is Microsoft's Endpoint Detection and Response (EDR) solution, allowing analysts to respond to alerts triggered by on devices. For forensic analysis, the solution enables the collection of data in the form of 'Investigation Packages' and a view into historic device activity though an interactive Timeline.
I use EDR products for incident response a lot, but I recently conducted a forensic investigation of a device where the information from Defender for Endpoint played a crucial role in identifying the root cause of a malware infection which might have otherwise not been possible using dead-box forensic techniques.
In this case, the malware had been sitting undetected in the device user's Download folder for approximately 3 months until it was interacted with and subsequently identified by Windows Defender. Fortunately the malware hadn't been allowed to run, but how and where it was downloaded from wasn't immediately obvious.
If you're anything like me, simply stating in your forensics report that "the malicious file was possibly (hopefully) downloaded by the user... maybe using a browser" simply won't do! So, keep reading to see how I set out to find the root cause of the infection using Microsoft's EDR solution.
Stock image of Defender for Endpoint's Device Timeline
Dodgy Download - It's always Chrome right?!
I started my investigation by gathering some basic information about the device and checking out the installed applications from the various tabs in the Device page. By doing so, it became apparent that the user had multiple potentially offending applications running on the device: Viber, Telegram, Edge and Chrome. All of which where potential vectors for malware infection and could have written the file to the user's 'Downloads' folder.
I continued to collect an Investigation Package for the endpoint but, sadly browser history didn't come as part of the EZ-download Investigation Package (come on Microsoft, Cortex XDR has easy access browser history now), so I grabbed it with the collection tool KAPE, preferring that over some PowerShell wizardry in a Live Response session.
Once obtained, the Chrome browser history wasn't found to contain the 'smoking gun' that I would have liked i.e. a visit to windowz-updatez-downloadz[.]xyz and a record of the malicious file in the History database's Downloads table (is that really so much to ask for?!). Instead, a single visit to the corporate homepage 5 minutes prior to the malware being written to disk was all I had to go off for now. But at least the single homepage visit suggested the Chrome had been opened at that time.
Collecting an Investigation Package in Defender for Endpoint
Defender For Endpoint Device Timeline
Not giving up on Google Chrome yet, I returned to Defender For Endpoint, this time turning to the Timeline tab for the affected device. Once I had got over how verbose the logging and how impressive the log/event retention was in the Timeline (process create and TCP connection events dating back 6 months if I remember correctly!), and once I had also got over how fiddly and frustrating the time and date selector was: I could see that as expected, just prior to the corporate homepage visit identified in browser history, the chrome.exe process was created confirming Google Chrome was launched at that time. As a bonus, just before that I could even see, the process explorer.exe opened chrome.lnk suggesting the user had opened the browser using a shortcut file.
Google Chrome lnk file on the Desktop
Exposing Incognito Mode
Unfortunately there was no specific event which stated "the user has switched to incognito mode" (you win this round Google Chrome!) however, Defender for Endpoint reported on the connections being made by the chrome.exe process (touché Defender). And seeing as there was no browser history available for this time period, it was a safe bet that browsing activity Defender for Endpoint had monitored was conducted using Incognito Mode.
Following the Timeline's incredibly verbose breadcrumb trail, I could easily track the connections being made by the process right up until the point of download in events like:
Chrome.exe established a connection with hxxps[://]bad-domain[.]info
...until finally, the 'smoking gun' itself:
Chrome.exe created Flash_Player_Update.zip
I've got this far, what's your point?
With the evidence provided by Defender for Endpoint, I was able to demonstrate with high confidence that:
1) Google Chrome was started via a shortcut file.
2) The user switched to Incognito Mode shortly after the browser opened.
3) Various (silly) websites were visited in Incognito Mode.
4) A malicious file was downloaded in the Incognito Mode.
As the malicious file was downloaded months before it was interacted with and the alarm was sounded, without Defender for Endpoint's Timeline of historic process and connection activity, I'd have likely struggled to tie the downloaded file to Chrome. I certainly wouldn't have been able to assess it was downloaded with Chrome with high confidence without prolonging the investigation to examinine the (now known to be dead-ends) Telegram and Viber and possibly conducting a threat hunt on the device. But with the evidence from Defender for Endpoint, not only could I present the pieces of forensic fact above, but I also had enough information to re-enact the user's website visits and identify the exact site the file had been downloaded from, which (as well as being pretty fun) was a nice bit of case closure.
Published by John, Senior Security Researcher in January 2023.
Page updated
Google Sites
Report abuse