Tracking Down Attackers

For some initial, crucial findings in Windows during incident and event management, you do not need to look further than the existing Event Viewer logs. After the introduction of Windows Server 2008 and Vista, Microsoft established a more granular approach. The events are sorted into categories along with subcategories for improved monitoring and recording. Typing

auditpol /list /subcategory:*
auditpol /get /category:*

at the command line lists a quick overview of the possibilities and shows the current configuration (Figure 1).

Figure 1: The output for auditpol /get /category:* shows an overview of monitored events.

You will usually control the Advanced Audit Policy Configuration settings with a group policy; you can also set it up at the command line. If you want the configuration to be used, it needs to be enabled. On newly installed systems, the correct value is set by default and does not need to be defined explicitly. However, best practices dictate activating this value with group policy for safety's sake. The reason lies in the legacy Active Directory (AD) installed on Windows Server 2000/2003, whose Default Domain Controllers Policy has never been edited or still uses the obsolete monitoring policy. You can reset the previous configuration to Not configured if the Advanced Audit Policy Configuration is used. Enable item Audit Policy in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options . Enforce the monitoring policy subcategory settings (Windows Vista or later) to disable the existing monitoring policy category settings.

Events: Spoiled for Choice

The most difficult question is which events you want to monitor. The Microsoft Security Baseline for domain controllers (DCs) from the Microsoft Security Compliance Toolkit 1.0 [1] can help you with this question. After unzipping the archive file, you will see a Group Policy Objects (GPOs) backup folder, which you can import in the Group Policy Management Console. Among other things, the folder contains the MSFT Windows Server 2022 – Domain Controller policy. As a first step, you might not want to implement all of the domain controller hardening instructions; some initial testing is recommended. You will probably only want to include the monitoring policy part in the Default Domain Controllers Policy or the default settings for the client or member server. You can do so, with a little trick.

The Advanced Audit Policy Configuration file is stored in a CSV file in the SYSVOL portion of the group policy – the Group Policy Template (GPT) – after importing or after manual configuration (Figure 2). From there, the defined target computer imports the file and processes it in the same way as auditpol.exe [2]. What is slightly more difficult is finding the right audit.csv in the backup folder and then importing it individually.

Figure 2: Importing the desired monitoring policies in CSV format.

The backup creates dynamic folders for each GPO. If a GPO is saved multiple times, you will find it multiple times in the folder. If you look at the manifest.xml file in the Backup folder, you will find a reference as to which globally unique identifier (GUID) contains which version of the policy. You can parse this with a small PowerShell script:

[xml]$Manifest=Get-Content -Path ".\manifest.xml"
$Backup=$Manifest.Backups.BackupInst
foreach ($GPO in $Backup){write-host $GPO.ID."#cdata-section", $GPO.GPODisplayName."#cdata-section"
}

The file can be hidden away in the depths of the backup path (e.g., .\Windows Server 2022 Security Baseline\GPOs\{E2B8214C-729F-4324-A876-F067E58B740B}\DomainSysvol\GPO\Machine\microsoft\windows nt\Audit\audit.csv). The windows nt folder name is not a typo; it just shows you the historical origins of the system and its substructure. Copy the file to the clipboard with Copy As Path and integrate it into any policy of the domain. Some of the policy's client-side extensions (CSE) let you individually import settings without completely replacing the existing settings.

Increasing the Log Storage Space

The events end up in the Windows Security Log . The expected data volume in the security event log is difficult to guess; it depends on the size of the AD and the number of changes. In general, however, the preset 128MB will be too small and cause data to be overwritten very quickly. A minimum of 1GB is recommended. In the baseline itself, Microsoft suggests 192MB but assumes that you are running a Security Information/Incident and Event Management (SIEM) system along with event forwarding and central logging on an external system.

For the next few days, you then need to monitor the behavior of the event log and adjust it to your own retention needs on the basis of the last entries by date and time. A total logging period of seven to 14 days is useful. The policy setting supports a maximum logfile size of up to 2TB. The size of the logs can of course also be specified with group policy: In Computer Configuration | Administrative Templates | Windows Components | Event Log Service | Security you can set the value for Specify the maximum log file size (KB) to suit your needs.

At this point, you should note that each DC in the organization will keep its own log, documenting changes that have taken place. This arrangement can often complicate the process of acquiring events because each DC needs to be checked. In the long run, you will probably not be able to avoid a central solution if your AD comprises more than two to four DCs. It is simply too time-consuming to check the individual systems.

Interesting Safety Events

To stay focused on the discovery of ransomware, look for the first important or noticeable events. Table 1 gives you a small excerpt, and an article online [3] has more information. Microsoft's link uses a criticality rating from Low to Medium to High, in addition to listing the event ID.

As a general rule, the most important events are changes to a user account, such as password resets. Security group changes, tasks created, and group policy changes are also suspicious. Ransomware looks to distribute and spread throughout the enterprise (i.e., lateral movement). Changes to group policies need to be monitored, especially in the Windows Firewall, which often prevents the spread.