Tag Archive: powershell windows forensics

Latest version: 1.8 update 1 – Azure ATP and ATA v1.9 planned for Q1 2019

News from Ignite event 2017:   

Azure ATP: https://www.youtube.com/watch?v=KX-xpFc0sBw

Technet resource: https://docs.microsoft.com/en-us/advanced-threat-analytics/

ATA 1.8 simulation playbook:


ATA powershell module:


(copied under \\ncecdlib.nce.amadeus.net\microsoft\microsoft ATA\)

News from pentesters:




What’s new in ATA version 1.8

Suspicious activity guide:


New & updated detections

  • NEW! Abnormal modification of sensitive groups – As part of the privilege escalation phase, attackers modify groups with high privileges to gain access to sensitive resources. ATA now detects when there’s an abnormal change in an elevated group.
  • NEW! Suspicious authentication failures (Behavioral brute force) – Attackers attempt to brute force credentials to compromise accounts. ATA now raises an alert when an abnormal failed authentication behavior is detected.
  • NEW! Remote execution attempt – WMI exec – Attackers can attempt to control your network by running code remotely on your domain controller. ATA added detection for remote execution leveraging WMI methods to run code remotely.Reconnaissance using directory services queries– In ATA 1.8, a learning algorithm was added to this detection allowing ATA to detect reconnaissance attempts against a single sensitive entity and improve the results for generic reconnaissance.
  • Kerberos Golden Ticket activity ATA 1.8 includes an additional technique to detect golden ticket attacks, detecting time anomalies for Kerberos tickets.
  • Enhancements to some detections, to remove known false positives:
    • Privilege escalation detection (forged PAC)
    • Encryption downgrade activity (Skeleton Key)
    • Unusual protocol implementation
    • Broken trust


  • NEW! More actions can be made to suspicious activities during the triage process.
    • Exclude some entities from raising future suspicious activities. Prevent ATA from alerting when it detects benign true positives (i.e. an admin running remote code or using nslookup) or known false positives (don’t open a Pass-The-Ticket alert on a specific IP).
    • Suppress a reoccurring suspicious activity from alerting.
    • Delete suspicious activities from the timeline.
  • A more efficient triage – The suspicious activities time line has gone through a major process of re-design. In 1.8, a lot more suspicious activities will be visible at the same time, and will contain better information for triage and investigation purposes.


  • NEW! Summary report. An option to see all the summarized data from ATA, including suspicious activities, health issues and more. It’s possible to define a reoccurring report.
  • NEW! Modification to sensitive groups report to see all the changes made in sensitive groups during a certain period.


  • Lightweight Gateways can now read events locally, without configuring event forwarding
  • Feature flags were added for all detection, periodic tasks and monitoring alerts
  • Accessibility ramp up – ATA now stands with Microsoft in providing an accessible product, for everyone.
  • E-mail configuration for monitoring alerts and for suspicious activities are separated


  • NEW! Single sign on for ATA management.
    • Gateway and Lightweight gateway silent installation scripts will use the logged on user’s context, without the need to provide credentials.
  • Local System privileges removed from Gateway process
    • You can now use virtual accounts (available on stand-alone GWs only), managed service accounts and group managed service accounts to run the ATA Gateway process.
  • Auditing logs for ATA Center and Gateways were added and all actions are now logged in the event viewer.Added support for KSP Certificates


Version: 1.7

Reference articles:

ATA on Technet: https://technet.microsoft.com/en-us/library/dn707706.aspx

ATA events: https://docs.microsoft.com/en-us/advanced-threat-analytics/understand-explore/ata-threats

ATA deployment demo: https://www.youtube.com/watch?v=xvWJssUpU6w

Blog: https://social.technet.microsoft.com/Forums/security/en-US/home?forum=mata

Additional resources:

Powershell windows forensics: https://github.com/Invoke-IR/PowerForensics

Powershell windows forensics: https://github.com/gfoss/PSRecon

Powershell windows forensics: https://github.com/davehull/Kansa




Windows forensics:

Powershell windows forensics: https://github.com/Invoke-IR/PowerForensics

Powershell windows forensics: https://github.com/gfoss/PSRecon

Powershell windows forensics: https://github.com/davehull/Kansa


Ref: http://windowsir.blogspot.fr/

The situation was pretty straight-forward; a system (Win7SP1) had been identified as having been infected with malware at one point.  What had been determined from the initial analysis that had been conducted was that the system have been infected in Sept, 2014.  As it turned out, the malware in question had been deleted by an AV scan around mid-Aug, 2015, and the image had been acquired near the end of Sept, 2015.  Two user profiles had been identified as having been involved in the initial infection.

The goal of this analysis was pretty simple.  Essentially, the initial analysis work had already been done, and a report had been delivered to the client. My objective for this analysis was to gain greater insight into the infection process, and to see if I could develop threat intelligence from anything else that I found.

I performed all of my work using free and open-source tools.

I conducted my analysis using Notepad++.

I created a timeline of system activity using:

  • File system metadata
  • Selected Windows Event Logs
  • Registry hives (Software, System, Security)
  • NTUSER.DAT and USRCLASS.DAT from the two profiles of interest
  • User WebCacheV01.DAT IE browser history files

The process I used to create my timeline is pretty much exactly what’s listed in Windows Forensic Analysis 4/e, in ch. 7.  The process took only a couple of minutes to put together a timeline and begin analyzing it.  From the time I opened the image in FTK Imager, I had a timeline in less than 30 min. Also, something I really like about it is that the process can be used in such a manner that only those files required are sent to another analyst to construct a timeline.

The system did have Prefetch files but given the time frame, there were no files of interest in the Prefetch folder.

Once I created the timeline, I was able to easily add context to what I was looking at using other tools.  For example, I parsed the user’s WebCacheV01.dat files initially using esedbexport.exe, and then using ESEDatabaseView.  An important take-away from this is data interpretation…entries have several time stamps associated with each visited URL, and the incorrect identification and interpretation of those time stamps can significantly impact your findings.  For example, the visited URL has an expiry date time stamp; assuming that this is when the site was last accessed can have a significant (and perhaps detrimental) impact on your overall analysis.

I took a look at IE session recovery files using the Structured Storage Viewer; I got what I needed out of the particular streams of interest, and added notes to my timeline.

Mapping the user’s TypedURLs values with the TypedURLsTime values was pretty fascinating, although all it really did was support findings that didn’t pertain directly to the malware.  Still…it was pretty cool.

User shellbags proved to be very illuminating, and the UserAssist information added additional context to what I was seeing.  In the case of one user profile, the combination of those two artifacts illustrated intentional, purposeful activity…the user navigated to a specific subfolder, and double-clicked a specific .exe file, launching it.  File system and Registry events following this activity indicated the execution of the application.

Hibernation File
It turned out that the system was a laptop, and had a hibernation file.  I extracted the file, and used Volatility 2.5 to convert it to raw format.  The “imageinfo” command told me that the hibernation file had been created on 13 Sept 2015,  a bit before the image was acquired.  I didn’t expect to find anything of value from the memory image, but I ran a couple of commands (pslist, psxview) anyway.  Doing so essentially validated my suspicions, but better to do it than not.  Besides, I wasn’t stopping my other analysis…the command prompt where I ran the commands simply went to the background, and I examined the output files when the commands completed.

The previous analysis had indicated that strings/IOCs associated with the malware had been found in the hibernation file.  I used strings.exe, and then the Volatility ‘strings’ command, and found that those strings were in free space.

Working with VSCs
A quick check of the image indicated that there were volume shadow copies (VSCs) available, which was great.  Most corporate systems I’ve dealt with for the past couple of years have had VSCs disabled for some reason, and here was one that didn’t.  I ran vhdtool.exe to “convert” the image, which essentially added a footer to the file.  As my analysis system is Windows 10, I renamed the file to have the “.vhd” file extension.  I opened the Disk Management utility and attached the newly-created VHD, and used the following command to list the available VSCs:

vssadmin list shadows /for=g:

Interestingly, I basically followed the process laid out in this blog post.  The output of the vssadmin command showed me that there was a VSC that had been created on 13 Jul 2015, which was about a month prior to the malware being detected and quarantined by AV.  I linked the VSC to a folder on my analysis system, and added the contents of the folder to FTK Imager; however, this didn’t give me the level of access I wanted, as I wanted to get, among other things, a copy of the $MFT from the VSC.

That’s where Jimmy’s blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:\, which appeared as a RAM image.  I then added the logical volume to FTK Imager, and was able to extract the $MFT, as well as other files.   By creating a timeline using files extracted from the VSC, I was able to create a bit more context around the

Creating the timeline in the manner that I did allowed me to get started on my analysis in fairly short order, identify what needed a closer look, and then add context and notes to the timeline.  I didn’t have to wait for an automated tool to complete, and then trudge through a lot of data that didn’t pertain to what I was trying to determine.  I admit, I had a bit of a leg up because of the initial analysis that had been conducted, but the process I used would have led me to the initial indicators pretty quickly.  Specifically, the use of eventmap.txt in parsing Windows Event Logs allows for a number of event records to be auto-tagged, and then easily searched for in the timeline.  Searching the timeline for the “[MalDetect]” tag would’ve taken me to the “Symantec Endpoint Protection Client” event ID 51 record that identified what would be my initial pivot point.

As it turns out, there were a number of “Symantec Endpoint Protection Client/51” events in the timeline, so an easy fix to that would have been to do something like this:

type events.txt | find “[MalDetect]” > av_events.txt

The above command runs through the events file and locates all malware detection events, putting them into a separate file.  From there, I could have run:

parse -f av_events.txt > av_tln.txt

This would give me a nano-timeline of just AV detection events, giving me a much smaller set of data to analyze, and on which I could pivot.  This would also pick up all malware detection events, for any such events mapped in the eventmap.txt file.

Accessing the shadow volume allowed me to collect copies of files that were not otherwise accessible, as well as get a look at the state of the system prior to the malware being removed.  In this case, the malware employed two persistence mechanisms, which meant that two copies of the malware existed on the system.  My initial timeline provided an indication of this, as immediately prior to the AV writing it’s detection and quarantine message to the Windows Event Log, there were changes to two locations within the file system, and to one Registry key.  Accessing the shadow volume from a time when the malware existed on the system allowed me to confirm what I had suspected.  It only took a few minutes, and to be honest, it was worth time to close the loop on the speculation.

I should note that I exported the hibernation file from the shadow volume, but once I converted it to raw format, the “imageinfo” command showed me that it had the same “image date and time” as the one from the image.  Running “pslist” and “psxview” gave me the exact same information as running those commands on the original hibernation file.  I need to look into this more, but it seems that the hibernation file is not tracked in shadow volumes, although the $MFT is.