• Overview
• Requirements
• Deployment steps
  • 1 - Advanced audit policies and registry keys configuration in Domain Controllers.
  • 2 - Audit LAPS password retrievals: Configure SACL
  • 3 - Microsoft Sentinel: Configure AD integration and events collection
  • 4 - Setup the Custom HTTP Data Collector API (PowerShell script) to populate Custom Logs.
  • 5 - Create the Log Analytics Parser funtions in your Microsoft Sentinel.
  • 6 - Connect your Domain Controllers to Microsoft Sentinel.
  • 7 - Import the Visual Auditing Security Workbook
• Author
• ChangeLog

The Visual Auditing Security Workbook project is a set of scenarios in an Azure Workbook for Microsoft Sentinel that pulls information from your Active Directory Domain Controllers and enables security teams to quickly detect insights about their Active Directory configuration, operations, and risks.

This workbook visualizes information from two Data Sources:

• Security Events from Domain Controllers and common Events.
• Data sent by a Custom HTTP Data Collector API. (Custom Logs format)

The current Visual Auditing Security Workbook includes 11 scenarios below:

1 - User Hygiene: Shows the overall state of the user population based on high-privilege users, users that have not logged in for an extended period, users that have not changed the password for an extended period, and users with Password Never Expired set.

2 - Computer Hygiene: Shows which computers within the domain are active with logins. It will present computers based on the Operating System version, with stale logins and passwords.

3 - LAPS Deploy: Local Administrative Password Solution (LAPS) Deploy tab shows how many computers have been configured by the LAPS solution. It will show which Operating Systems have LAPS deployed and the up-to-dateness vector on the LAPS Password.

4 - LAPS Audit: This tab shows which users retrieve the passwords for the local systems to use locally. LAPS Auditing helps unveil which user account has accessed the local administrator’s password of a given computer.

5 - Non-Existent users activity: This tab tracks the non-existent and potentially sprayed accounts in your environment. These are accounts generating failed logins (4625s) in which the sub-status code references a non-existent account. (Note: these failed logins are distinct from existing accounts with incorrect passwords). You should look especially for machines hosting – or accounts exhibiting – a pattern of non-existent user types of failed logins. These can be early indicators of attack or attempted attack.

6 - Group Changes: This tab will show which Active Directory Groups have been changed. It will also show which users are making the most number of changes.

7 - User Authentication: This tab will show which users are authenticating. It gives an overview of the authentication being performed by a specific user.

8 - SChannel: This tab will show where SChannel authentication is occurring. It will show which computer that was initiating the Schannel authentication. You will need to temporarily install the MMA on the webserver or whatever server you suspect is using SSL or another deprecated encryption method. Then you will be able to see the actual cipher suite used and remediate the deprecated ones in use.

9 - Security Log Clear: This tab shows where the security log has been cleared and by which user.

10 - Audit Policy Changes: This tab shows an attacker’s attempts to cover his tracks as he potentially has created environmental persistence

11 - User Management: This tab shows the most common user management activities within the forest. User Management in a typical environment is relatively static and does not change much unless something is altered.

Note: Apart from this workbook, we recommend using the Insecure Protocols workbook of Microsoft Sentinel to identify their use and help to remove Insecure Protocols from your Active Directory and Azure Active Directory.

To be able to consume all scenarios described, it is necessary to meet the following requirements:

1. Have an enabled Azure Subscription with a Microsoft Sentinel workspace.
2. Create a new Group Policy Object to enable the necessary audit policies and registry keys in your Active Directory (applied to Domain Controllers).
3. Configure SACL for Auditing LAPS
4. Deploy a server as Log Analytics Gateway.
5. Configure the Custom HTTP Data Collector API (PowerShell script).
6. Connect your Domain Controllers to Microsoft Sentinel throughout the Log Analytics Gateway (req. 4) by deploying the Microsoft Monitoring Agent.

To generate the necessary Security Events in the Domain Controllers it is needed to configure a new GPO (applied to Domain Controllers) to enable the following audit policies:

*Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies*

• DS Access
  • Active Directory Services Access - Success
• Account Logon
  • Audit Credential Validation - Success, Failure
  • Audit Kerberos Authentication Service - Success, Failure
  • Audit Kerberos Service Ticket Operations - Success, Failure
• Account Management
  • Audit Security Group Management - Success, Failure
  • Audit User Account Management - Success, Failure
• Logon/Logoff
  • Audit Logon - Success, Failure
  • Audit Account Lockout - Success, Failure
  • Audit Other Logon/Logoff Events - Success, Failure

To generate the Events related with SChannel use, it is needed to configure the following registry key:

• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging
  • Change the value to 7

Make sure that proper audit settings (SACLs) are in place on the objects to audit. Follow next steps to audit LAPS password retrieval by configuring the audit settings at the root of the domain.

1. Open Active Directory Users and Computers.
2. Enable View\Advanced Features.
3. Select root of the domain.
4. Open Properties and go to the Security tab.
5. Click the Advanced button and go to Auditing tab.
6. Click Add to add a new entry.
7. Change the Principal to Eveyone, type to Success, Applies to Descendant Computer objects.
8. Click Clear all at the bottom to uncheck all the prechecked items.
9. Check the box all extended rights.
10. Check the box Read ms-Mcs-AdmPwd.
11. Click ok and close out of all the security properties.

Once advanced audit policies and registry keys are configured, you need to configure the Microsoft Sentinel data sources.

1. Go to your Microsoft Sentinel > Settings > Workspace Settings > Computer Groups > Active Directory and check the Import active directory group memberships from computers.
2. Click Apply.

1. Go to your Microsoft Sentinel > Settings > Workspace Settings > Agents configuration
2. Click +Add windows event log and write System
3. Click on Information box to collect only the Information Events from System log and the apply.

To collect the SecurityEvents from Domain Controllers, there are two options when you use Microsoft Monitoring Agent and Sentinel:

• Use the Sentinel Data Connector Security Events via Legacy Agent.
• Enable Microsoft Defender for Cloud plans over Microsoft Sentinel workspace. The difference between them resides in a billing way. Practically speaking, we need to collect Security Events, so there is no difference in the method chosen for this solution. We recommend you evaluate both options and choose the most interesting for you. Below is the Microsoft Defender for Cloud method because it requires some additional (and simple) steps.

To enable all Microsoft Defender for Cloud plans in the Microsoft Sentinel workspace you need to:

1. Go to Microsoft Defender for Cloud.
2. Go to Environment Settings and expand your Tenant and Azure Subscriptions until find your Log Analytics Microsoft Sentinel workspace.
3. Click on your Microsoft Sentinel workspace.
4. Go to Defender plans and click on Enable all Microsoft Defender for Cloudo plans.
5. Click on save.
6. Go to Data collection.
7. Click on All events and save.

The workbook need Active Directory Objects (users, computers, groups, etc) information to populate Hygiene and LAPS tabs. This information is collected by the custom data collector and uploaded to Microsoft Sentinel as Custom Logs format. Follow the below steps to configure the Custom HTTP Data Collector:

1. Use the Log Analytics Gateway servers to run the Custom HTTP Data Collector.
2. Open an elevated PowerShell console and install the RSAT AD DS Powershell module by running the command:

Install-windowsfeature RSAT-AD-PowerShell

3. Fill and personalize the parameters section of the ADObjectsToALA_v1.1.ps1 PS script.
4. Before executing the PowerShell script you need to create the source for event log "VASWDataToSentinel" by using the cmdlet:

New-EventLog –LogName Application –Source "VASWDataToSentinel"

5. Fill the domainlist.csv according your environment. This file needs to have the headers line (dc,isLAPSDeployed) and one Domain Controller name and isLAPSDeployed value (comma separated) per line from each domain in scope as you can see in the following image.

6. Create a scheduled task to run the PowerShell script daily.
7. To verify that the PowerShell script is running well, execute it manually and check if the Custom Logs are created in the Microsoft Sentinel workspace. Note: First you execute the script you probably need wait 5 to 10 minutes before seeing the logs in Microsoft Sentinel.

The workbook kusto queries refer many times to five Log Analytics Parser functions that need to be created or, on the contrary, the workbook will fail in different sections. These functions process the information received in Custom Logs format and calculate new fields based on raw data. Parser functions need to be created precisely with these names:

• VASWUsersParser
• VASWComputersParser
• VASWGroupParser
• VASWAdminAuditParser
• VASWPawAuditParser

Note: In "Legacy category" field you can use "VASWFunctions" value for all functions.

To connect Domain Controllers to Microsoft Sentinel we use the Microsoft Monitoring Agent (MMA). Network communication between the MMA on Domain Contollers and Microsoft Sentinel is not direct. We use the Log Analytics Gateway as proxy for MMAs on DCs so, as you can see in the following image, the only server with network communication to the Microsoft Sentinel endpoints is the Log Analytics Gateway.

Necessary steps to deploy Log Analytics Gateway and Microsoft Monitoring Agents are:

1. Download and Install the Log Analytics Gateway software on the provided server. This software can be downloaded from the workspace: Microsoft Sentinel > Settings > Workspace Settings > Agents management > Log Analytics Gateway. The Log Analytics Gateway requires access to the four Microsoft Sentinel (Log Analytics) endpoints described here.
   • Note: In the Log Analytics Gateway installation wizard it is needed to configure the Log Analytics Gateway port. This port will be used when Microsoft Monitoring Agent is installed on Domain Controllers, in the proxy configuration step.

2. Install the Microsoft Monitoring Agent and connect it to the Microsoft Sentinel with the WorkspaceId and PrimaryKey which are located in Microsoft Sentinel > Settings > Workspace Settings > Agents management.

1. Install the Microsoft Monitoring Agent and connect it to Microsoft Sentinel throught Log Analtyics Gateway server. Log Analytics Gateway need to be configured in the Proxy Setting tab with the port configured.

1. Go to Microsoft Sentinel > Workbooks.

2. Click on Add workbook.

3. Click on edit and go to Advanced Editor.

4. Remove the default workbook code and paste the code of Visual Auditing Security Workbook.workbook

5. Click apply.

6. Configure the workbook parameters and hide parameters:

   • Azure Subscription: Hidden parameter, only visible in the workbook edition mode. The subscription where you have your Microsoft Sentinel workspace.
   • Microsoft Sentinel workspace.
   • DCsGroup DisplayName: Hidden parameter. You need to enter the display name of your Domain Controllers AD Group (for instance, "Domain Controllers"). It has been created to support any language.
   • LAPSPasswordGUID (ms-mcs-AdmPwd): Hidden parameter. You need to enter the ms-mcs-AdmPwd GUID of your environment. It can be queried by running the following code:

   $rootdse = Get-ADRootDSE
    $GUIDs = Get-ADObject -SearchBase ($rootdse.SchemaNamingContext) -LDAPFilter "(schemaidguid=*)" -Properties lDAPDisplayName,schemaIDGUID
    ForEach ($Guid in $Guids)
    {
    	    If ($guid.lDAPDisplayName -Like "*ms-mcs-admpwd")
      {
    	      $SGuid = ([System.GUID]$guid.SchemaIDGuid).Guid
    	      Write-host $guid.lDAPDisplayName, ([System.GUID]$guid.SchemaIDGuid)
    	    }
    }
    

The Visual Auditing Security Workbook was developed by Diego Martínez Rellán (dmrellan) - Microsoft. It was inspired by the Microsoft Support - Visual Auditing Security Toolkit (VAST) service (currently retired) developed originally by Brian Delaney and Jon Shectman.

• Workbook version: 1.4.
• New workbook global parameter: "DCsGroup Display Name" (to support different languages).
• LAPS Deployment:
  • New "Total count" column to "Total computers by OS and LAPS Deployed" table.
  • Minor improvements.
• LAPS Audit: New table "Updated and outdated computers" added.
• Audit Policy tab: New filter "isComputer".
• Authentication tab:
  • New table: "Top 10 Status messages".
  • New Table: "Total auth events by source (Top 10). Filtered by X account".
  • Display names added to the EventID dropdown filter.
  • Minor improvements in the Details table.
  • Fixed parser logic KQL queries in all tables.
• Group changes tab:
  • Added a new column "Total changes" to the change-makers table. The table ordered by this new column.
• Nonexistent users tab: Visualization improvements.
• Other minor improvements.

• No modifications. You can continue using ADObjectsToALA_v1.1.ps1

• No modifications.

• Fixed typos in the Powershell script.
• Improved logging.
• The maximum number of elements by post is 10k.

• VASWComputersParser.kusto: Fixed an issue when LAPS is not deployed.