Author Archives: paularquette

Force Create Windows Firewall Log with Group Policy

In my previous blog (https://paularquette.com/windows-server-firewall-logging-via-gpo-log-file-not-created/) I mentioned that simply turning on Group Policy for the Windows Firewall doesn’t actually create the firewall logs.

In order to force create the windows firewall logs for servers that are already out there in the wild I have created a batch script that can be ran in Group Policy as a startup script.

The script is located on my github but I’ve listed here as well because it is a small script. For the latest updates though please visit github as it is unlikely I will individually update this blog post.

https://github.com/paularquette/Windows-Servers/blob/main/CreateFirewallLogs.bat

rem Batch Script to Create Firewall Log Files
rem Written By: Paul Arquette
rem Last Modified: Oct 24, 2022
rem Last Modified For: Github

if exist C:\Windows\System32\LogFiles\firewall\pfirewall.log (
  echo file exists
) else (
  netsh advfirewall set allprofiles logging filename %systemroot%\System32\LogFiles\firewall\pfirewall.log
  netsh advfirewall set allprofiles logging maxfilesize 32767
  netsh advfirewall set allprofiles logging droppedconnections enable
  netsh advfirewall set allprofiles logging allowedconnections enable
)

Override Group Policy for the Windows Firewall

Did you apply a Windows Firewall Policy that blocks the ability to talk to Active Directory and get Group Policies? We all make mistakes….

¯\_(ツ)_/¯

You can no longer login to this box with Active Directory Credentials…..
You try to login as a local administrator and see that everything is grayed out?

On top of that you also turned off the ability to apply local firewall rules?

Don’t fear! There is a way to fix this as long as you have Local Admin rights on the box. Open up the Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall

Right-Click the WindowsFirewall key and delete it and all sub-keys and reboot.

This should fix the issue and you will pull down the corrected Group Policy on reboot.

Windows Server Firewall Logging via GPO – Log File Not Created

When you try to enable Windows Firewall Logging via Group Policy you will notice that the Log Files are not created / do not exist.

You configure the GPO to setup logging:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security (Right-Click -> Properties)

However, no matter how many “gpupdate /force” you run or reboots of the server you do, the “LogFiles” directory still does not contain a “firewall” folder, let alone the actual log files.

How do we fix this?

One thing you could do if are deploying from a template is configure the template so these files are created. However, this only fixes new server deployments going forward, doesn’t do much for the servers already out there running.

The good news is, the same commands that can be used to fix the template can also fix all the servers that are currently running out there in the wild.

The Fix

In order to make a blog that will work for Server GUI or Server Core I’m going to use netsh firewall commands, run these from an elevated “Administrator” command prompt or PowerShell window.

The first command will actually create the folder and files necessary, and group policy should be able to configure everything else.

These commands will create the folder/files, set the maximum file size for the log file to the maximum size allowed by windows, log dropped packets, and allowed packets.

netsh advfirewall set allprofiles logging filename %systemroot%\system32\LogFiles\firewall\pfirewall.log
netsh advfirewall set allprofiles logging maxfilesize 32767
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

CISA, VMware, and Mandiant, Oh My!

CISA released an alert yesterday regarding VMware’s recommendations for threat hunting and securing your VMware environments from Malware due to Mandiant’s report. (https://www.cisa.gov/uscert/ncas/current-activity/2022/09/29/vmware-releases-guidance-virtualpita-virtualpie-and-virtualgate)

Mandiant released a blog yesterday on “Investigating Novel Malware Persistence Within ESXi Hypervisors” (https://www.mandiant.com/resources/blog/esxi-hypervisors-malware-persistence)

So what does this all mean for you?

First, don’t go running down the street with your hands in the air as Mandiant has not uncovered any vulnerabilities that were exploited to gain access to ESXi. Threat actors would still need the proper rights (root) on ESXi to install backdoor VIBs. However, since many people use central authentication systems like Active Directory though, it may be easier for threat actors to pivot into your environment if Active Directory is compromised.

The CISA link above provides all of VMware’s important links to make sure you are secured as possible. I’d highly recommend reading through all of the material here that VMware has put out.

The best thing you can do is setup Defense in Depth.

Resetting Domain Controller Computer Object Passwords Twice

There are times when you may need to reset the Domain Controller computer object passwords.

NOTE: You will have to move the PDC role to another DC in order to perform this task on the DC that currently holds this FSMO role.

Steps:

  1. Logon to a Domain Controller as a Domain Admin with an interactive session.
  2. Temporarily Stop the “Kerberos Key Distribution Center” Service and set it’s Startup to Manual
  3. Run the following command:
    “netdom resetpwd /s:DC01 /ud:DOMAIN\DomAdmin /pd:*
    1. Enter the password the account specified above
  4. Restart the “Kerberos Key Distribution Center” Service and set it’s Startup to Automatic

You can pull the pwdLastSet field of the Domain Controllers to verify that the password did actually update.

In certain instances dealing with Cybersecurity & Incident Response you may need to perform this action twice on all Domain Controllers.

“Double-Tap” reset of the krbtgt account

We recently ran a “double-tap” reset of the krbtgt account in our Active Directory and ran into very few problems. We have the default 10 hour Kerberos ticket lifetime configured.

EDIT: The biggest issue was an internal .NET Portal that was federated with ADFS, it needed to be restarted

We ran the script that is out on Microsoft’s github repository.
https://github.com/microsoft/New-KrbtgtKeys.ps1/blob/master/New-KrbtgtKeys.ps1

We ran this first in our test environment and then scheduled the run for our Production environment a week night evening at 10pm to make sure people would be around if there were issues the following morning.

The recommended way to run this script is using the following modes:

  1. Mode 1 – Informational Run Only
  2. Mode 8 – Create bogus krbtgt test account
  3. Mode 2 – Simulation Run to verify replication
  4. Mode 3 – Simuation Run to verify replication and password reset of bogus krbtgt
  5. Mode 4 – Real Run, Modifying Real krbtgt Account
  6. Mode 9 – Cleanup bogus krbtgt test account

We ran Mode 3 and Mode 4 twice, on the second run of Mode 4 you will see some warning text that there could be a major domain impact.

The only major impact that was noticed in our environment was that remote desktop to many of our servers stopped working if using the fully qualified name. A workaround to this would be to use the IP which will use NTLM authentication.

However, after our 10 hour ticket time all machines were back to working as expected.

This script should be run a couple times a year depending on who you ask for only a single-tap reset of the account. I’ve heard recommendations from every 90 days to every 180 days. It should also be run anytime someone who can forge golden tickets leaves the environment (Twice if there is concern).

Server 2022 KMS: error activating Windows 10 2016 LTSB or 2019 LTSC

Leaving breadcrumbs to update this post. Found these two posts on reddit.

https://www.reddit.com/r/sysadmin/comments/plq1hw/heads_up_windows_server_2022_kms_host_keys_seem/

https://www.reddit.com/r/sysadmin/comments/suqn1l/update_fixed_windows_server_2022_kms_host_keys/

The error we were receiving on the client was:

The client has sent an activation request to the key management service machine.
Info:
0x80072AF9, 0x00000000, <redacted>:1688, <redacted>-<redacted>-<redacted>-<redacted>-<redacted>, 2022/07/14 19:42, 1, 1, 258969, <redacted>-<redacted>-<redacted>-<redacted>-<redacted>, 25

Resolution:

Launch Volume Activation on Server 2022 KMS Server and run through the process to install a new key, and just put the same key back in after you apply the current patches. This was done before July 2022 patches were applied.

After performing these tasks verify that the failed requests will now be processed by the KMS server.

Robocopy Excluding Certain Directories with Wildcards

In this blog I’m revisiting Microsoft’s Robocopy with using the “/XD” flag for excluding certain directories.

We are in the process of migrating about 200TB of data from one file cluster to another due to the underlying storage also changing. So robocopy has been our best friend for quite some time when you have to move these large datasets and retain things like Microsoft ACLs.

This particular command will copy from <source> to <destination> with the following options:

robocopy \\uncsource Y:\LocalDest /TEE /MIR /copyall /zb /w:1 /r:2 /xo /MT:16 /XD "?????1" "?????3" "?????5" "?????7" "?????9"

/TEE: Writes the status output to the console window

/MIR: Mirrors directory tree (adds and deletes based on source data)

/copyall: Copies all file information

/zb: Copies files in restartable mode

/w:1: Specifies wait time between retries in seconds (1 second in this example)

/r:2: Specifies the number of retries on failed copies (2 retries in this example)

/xo: Excludes older files

/MT:16: Creates multi-threaded copies with n threads, must be between 1 and 128, default is 8.

/XD: Exclude directories

Directories are listed after XD in quotes and wildcards can be specified. A question mark (?) can be used for any character and an asterisk (*) can be used to fill in anything else.

For example if you wanted to exclude any directories that started with “ADM”, you could use: 

/XD "ADM*"

For example if you wanted to exclude any directories that start with anything and have a 1, 3, 5, 7, or 9 in them:

 /XD "*1" "*3" "*5" "*7" "*9"

The original first example above (copied again below this paragraph) is saying there can be any character for the first five characters and then if the last character is a 1, 3, 5, 7, 9 than exclude it and do not copy it. 

robocopy \\uncsource Y:\LocalDest /TEE /MIR /copyall /zb /w:1 /r:2 /xo /MT:16 /XD "?????1" "?????3" "?????5" "?????7" "?????9"

**NOTE** If you don’t want directories in directories to get skipped with the same wildcards specify a full path prior to the wildcards.
/XD “C:\Temp\?????1”