Category Archives: IT Security

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).

Windows Server 2022, IIS Certificate Authentication not working. (Connection Reset)

I was working with a colleague of mine the other day on this issue. If you are using Windows Server 2022 with IIS to setup a website that will use client certificate authentication and notice that you are not prompted for a certificate….. the issue is probably TLS 1.3.

Windows Server 2022 IIS by default uses TLS 1.3. If you check the box to disable TLS 1.3 which will fall back to TLS 1.2 everything works.

Still not sure at this moment who is to blame, Microsoft, or the web browsers.

EDIT: Update from the Microsoft Article

https://docs.microsoft.com/en-us/answers/questions/654803/err-connection-reset-if-asking-client-certificate.html

Yes, I got answer: Microsoft implemented TLS 1.3 in most secure way by RFC. IIS wants to perform post-handshake authentication. Unfortunately common browsers do not support it in default configuration. You can enable it only with Firefox (when I last checked, maybe samething changed in near past). So, de facto IIS default configuration for two-way SSL with common browsers do not work with IIS when TLS 1.3 only is enabled.

You can enable IIS and TLS 1.3 only configuration by enabling in-handshake method for IIS instead on post-handshake method.

Forcing ADFS 3.0 to run TLS 1.2

If you haven’t already forced ADFS to run on TLS 1.2 you are behind the curve. Activating TLS 1.2 on ADFS and turning off all other vulnerable services is relatively easy.

Step 1: Disable SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, RC4 & Enable Strong Auth for .NET

The first step that always goes unsaid is to snapshot your Virtual Machines or get a solid backup state before making any changes to a running production environment. The next unsaid step is to perform these activities on a test/dev environment before taking down Production!

SSL 2.0 and SSL 3.0 should already be disabled, if they are not disable them immediately! The following link from Microsoft provides the registry keys and powershell needed to disable all of these services. Make sure these changes are being made on all Web Application Proxies (WAPs) and ADFS servers.

  • Disable SSL 2.0
  • Disable SSL 3.0
  • Disable TLS 1.0
  • Disable TLS 1.1
  • Disable RC4
  • Enable Strong Authentication for .NET Applications

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

Step 2: Reboot all Virtual Machines / Servers

This step is pretty self explanatory.

Step 3: ADFS is Br0ken, Oh Noes!!

Disabling TLS 1.0 will break ADFS 3.0, more specifically it breaks the connection between the WAPs and the ADFS servers. This is easy to fix though.

Following this article on re-establishing the trust: https://blog.rmilne.ca/2021/11/16/ad-fs-web-application-proxy-re-establish-proxy-trust/

Quick Recap: Change this registry value on the primary Web Application Proxy:

HKLM\Software\Microsoft\ADFS\ProxyConfigurationStatus –> 1

This value normally has a value of 2 (which means configured), change it back to 1, and this change does not even require a reboot.

Open up Server Manager and launch “Remote Access Manager”, select “Web Application Proxy” and put in the required information to re-establish the trust.

You may need to reboot the WAPs one more time, I had to.

Step 4: Verify SSL Services are Correct

Once all services come back up, it would be a good time to verify that all the services you think you turned off are actually off. A SSL Server Test tool would be great for that, like the one by SSL Labs: https://www.ssllabs.com/ssltest/

Step 5: You may need to correct internal .NET Applications pointing to ADFS

Internal .NET Applications may start failing. If you start to receive error messages like “Authentication failed because the remote party has closed the transport stream”, it just means you are not specifying TLS 1.2.

There is a great article on Microsoft Docs here that explains the situation and the fix: https://docs.microsoft.com/en-us/answers/questions/400152/authentication-failed-because-the-remote-party-has.html

The developers will just need to specify the SecurityProtocol in their application.

GrrCon Early Bird Tickets on Sale March 1, 2022

I attended the GrrCon Cyber Security Summit & Hacker Conference for the first time last year. Although it was kind of overwhelming I learned a lot and had a great experience. I’m planning to be back at the conference this year.

GrrCon put out a tweet last week stating that the early bird tickets would be going on sale March 1, 2022.

This year’s conference is scheduled to take place October 13th & 14th at DeVos Place in Grand Rapids, Michigan.

Monitoring Domain Controller Windows Firewall Logs (Part of Active Directory Hardening Series)

The first step before you can monitor the local DC firewall logs is to make sure you have properly setup your domain controllers to log firewall activity. If you have not already turned on firewall logging and increased the log size to the maximum you can configure that by looking at my prior post: https://paularquette.com/lock-down-your-active-directory-domain-controllers-internet-access-part-of-my-active-directory-hardening-series/

I have shared a new script on GitHub to do some basic monitoring of dropped traffic on your Domain Controllers. https://github.com/paularquette/Active-Directory/blob/main/AD_Monitor_DC_Firewall_Logs.ps1

I currently run this script every hour and I get plenty of overlap for logs. The logs roll relatively quick but not that quick. I’m also logging all allows and I may change that in the future to only log drops.

In order to see dropped traffic outbound you would have to have outgoing firewall rules in place. By default traffic is not blocked going out. You can reference my previous post linked above.

In the example below you can see I’m limiting all TCP/UDP outbound traffic on Non HTTP ports to a certain subset of IP ranges:

If this Domain Controller tries to send any NON-HTTP(s) traffic outside of the organization it will show up in the DC firewall logs.

Example of HTML Report:

If your IT Security group has the hardware firewalls super locked down you may not see much if any traffic being dropped on the local DCs, but it still isn’t a bad idea to have another layer of security around such a high profile service!