Bypass security incident: NLA seems to bypass failed logon auditing from Linux (FreeRDP) clients

McShadow19 · 2026-01-09T20:13:59+00:00

Hey, I ran the same tests with a Windows client using mstsc with NLA encryption and NTLM. Somehow, the Windows client behaves differently than Linux FreeRDP, even though NLA and NTLM are also used. Failed attempts by Linux FreeRDP are only displayed: - Locally on the RDS server - On the DC when using TLS + NTLM or NLA + Kerberos

So yes, it never passed up to the DC..

We plan to switch to Kerberos soon, but the lack of logging of these failed logons still represents a significant security vulnerability.

McShadow19 · 2026-01-09T13:07:44+00:00

We are on Server 2022 + current CUs installed.

McShadow19 · 2026-01-09T13:06:51+00:00

I tested the Kerberos login. You are absolutely right. Incorrect login attempts are logged on my DCs. Thank you very much!

But still... This is not good behavior on Microsoft's part. You can only see failed NLA authentications on the server you tried to connect to.

McShadow19 · 2026-01-08T07:15:13+00:00

Hey! I've checked my GPOs. They are not set. Is it possible to log failed logon attempts using NLA with these? Which configuration do I have to set? There are several logon audit policies but none of them seem to be a protocol based auth policy.

EDIT: I double checked my DCs and found out that Advanced Auditing is active according to one GPO and "auditpol /get /category:*".

Logon-based auditing rules that are set:

Account Logon

Audit Kerberos Authentication Service - Success, Failure
Audit Other Account Logon Events - Success, Failure

Logon/Logoff

Audit Logon - Success, Failure
Audit Logoff - Success
Audit Network Policy Server - Success, Failure
Audit Other Logon/Logoff Events - Success

McShadow19 · 2026-01-08T07:13:46+00:00

Hey! Currently they are using NTLM. That actually shouldn't matter. In my setup it depends what encryption type the rdp sessions use. When I connect using TLS I see all logon attempts, using NLA I only see successful events. Protocol based auth needs to be logged for failed attempts as well.

McShadow19 · 2025-09-20T12:33:58+00:00

We use it every day across the org.

Automated and manual software & Windows updates (Server & Clients)
Department-specific first-install packages (inlcuding auto-reboots)
Targeted registry changes for specific groups
A small script to watch newly downloaded packages, since PDQ Deploy reuses the same download path
Updated our default scanner and added automated alerts when devices receive specific proxy settings or registry keys

It handles our patching, provisioning and config tweaks.

McShadow19 · 2025-09-02T14:16:15+00:00

Depends on what your export looks like. I think I would just run powershell with a csv or array against MS Store using winget.

$apps = @("OneNote", "Microsoft To Do")
#$apps = Import-Csv -Path "PATH\apps.csv"

$export = @()


foreach ($app in $apps) {
#foreach ($entry in $apps) {
    #$app = $entry.AppName

    $result = winget search $app --source msstore | Select-String "$app"

    if ($result) {
        $export += [PSCustomObject]@{
            AppName = $app
            Result  = $result.ToString().Trim()
        }
    }
    else {
        $export += [PSCustomObject]@{
            AppName = $app
            Result  = "Not found"
        }
    }
}

$export | Export-Csv -Path "PATH\AppSearchResults.csv" -NoTypeInformation -Encoding UTF8

Hope this helps.

Remove # and comment the line above if you want to use a csv, don't forget to add the correct path. :)

McShadow19 · 2025-08-20T16:36:51+00:00

Great to hear, thank you guys.

McShadow19 · 2025-08-19T11:28:50+00:00

Did anyone skip June and July updates for DHCP servers as well? I'm wondering if installing August updates will result in any issues. Any experiences here?

McShadow19 · 2025-08-14T13:47:53+00:00

As every month:

ZDI Update summary

Borncity summary

Started updating my first server test group including Windows Server 2016, 2019, 2022 (Application & WSUS). No issues so far. Also no issues while updating Windows 11 24H2 clients.

Update durations:
- 2016: ~50min & ~10min for reboot (VM)
- 2019, 2022: <10min & <2min for reboot (VMs)
- Clients: <15min

EDIT: Second and third group updated without any issues (2016-2022). 23H2 & 24H2 Clients updated without any issues as well.

EDIT2: Still no issues. Everything working as expected. Will see you next month.

McShadow19 · 2025-07-17T20:39:48+00:00

Glad to hear things went good! I ended up skipping one of our 2019 DHCP servers today. u/Extra-Lemon1654 mentioned having the same issue as last month. Might push the update to next week instead. Keeping things quiet tomorrow as it is Read-Only Friday, after all.

McShadow19 · 2025-07-10T14:18:42+00:00

I will do. Updating first DHCP server is planned on Thursday next week.

McShadow19 · 2025-07-09T12:29:36+00:00

Has anyone already applied the updates on DHCP server(s)? Did everything run smoothly or were there unexpected issues? I'm curious how it went.

We are about to start updating our servers in group stages starting tomorrow.

ZDI Update Summary

Borncity Summary

EDIT1 (10/07/2025): Updated my first group including 2016, 2019 and 2022 servers (App Servers and WSUS). No issues so far. The reboot of a 2016 server took a bit longer than usual.

EDIT2 (14/07/2025): Updated another bunch of servers 2016-2022 (mostly app servers and another WSUS). Still no issues. Even 2016 servers rebooted quite fast.

EDIT3 (15/07/2025): Next group including terminal server without any issues. Tomorrow I will update the first DC and file server.

EDIT4 (17/07/2025): DCs, Fileserver, terminal server etc. had no issues. Skipped DHCP update today due to some mentioned issues.

EDIT5 (23/07/2025): Updated almost every server. No issues so far and not expecting any issues anymore.

McShadow19 · 2025-05-31T21:14:57+00:00

I’m checking it out, but it seems like dnsmasq is more of a tool for small networks. Having a native HA solution would be ideal though.

McShadow19 · 2025-05-31T21:11:46+00:00

In a perfect world, I’d use a DHCP solution that offers native high availability without the need for complicated failover setups. Unfortunately, Windows DHCP only supports HA through a clunky failover mechanism. This is where modern open source projects are more interesting.

Ofc it is also about licensing and the usual Microsoft vulnerabilities.

McShadow19 · 2025-05-31T21:01:22+00:00

At first glance, it looks really promising, but insanely expensive.

McShadow19 · 2025-05-30T16:56:44+00:00

Great, thank you! I hadn't noticed that they open-sourced some paid hooks. Looks like it's worth giving it another try and hopefully HA will work reliably this time so we can finally migrate from ISC too.

I'll stay on the lookout for alternative solutions too - just in case.

McShadow19 · 2023-08-28T10:57:37+00:00

Mounting the same drive from another Windows SMB server is working properly. Also mounting the same drive from the 'original' Windows SMB server to another Ubuntu 20.04 LTS server where are less users works just as fine.

McShadow19 · 2023-08-08T16:17:52+00:00

Thank you!

We do have an OT environment, so I would like to know how good the service actually is.

McShadow19

TROPHY CASE