Injecting Windows AD Logons within FAC/FSSO through Syslog

Injecting Windows AD Logons within FAC/FSSO through Syslog

This post is a continuity from a previous post on pretty much the same subject. The idea this time is to forward the Windows Security logs through Syslog to our FAC appliance and extract the user / source bits needed to create an FSSO entry. The latter then addressable within your FortiGate's NGFW policies etc..

The 1st thing you'll need is a Syslog Agent on your Windows DC/AD repository. I haven't done extensive researches although it seems that Windows cannot do that natively. To achieve this I found a very simple WinPE/Service which is very easy to deploy and test.

The bits I've tested were from this GitHub repo / Fredrik Mikker:

And you can find the latest published build to date here:

Here is what the Datagram Syslog Agent user manual state's about itself:

The Datagram SyslogAgent is installed as a service on Microsoft Windows clients and servers to provide syslog compatability. The entries in the Event log are sent to the central Syslogserver. Application logging is also supported.

Once you gathered the Datagram Syslog Agent, you can review it's source code if so you want. After what you basically need to store the zip file extracted contents where you'd want them to run from and launch the SyslogAgentConfig configuration utility:

As shown above, you need to give in a Syslog Server (our FAC appliance) and you install the Syslog Agent as a Windows Service. You have a good amount of possible tweaks within the Logging facilities to choose from in order to possibly avoid sending all the logs from any of the given Windows log facilities etc.. I've only left the Windows Security log facility enabled and disabled everything else.

I did as well made some slight modifications onto how the Syslog Agent behaves and sends Syslog data. Specifically on which ASCII characters are used for CR/LF. Here are my moddz:

The Datagram Syslog Agent user manual (part of the zip file) explains all the possible modifications and you're free to set this up to your needs.

Onto the FAC appliance, what we'll need is to enable the Syslog feature on one interface (and yes, preferably the one bound to the IP you've set within the Datagram Syslog Agent above)

We will also need to poll Syslog entries from within the FSSO facility on FAC:

And a few last steps; we need to make a custom parser in order to grab the user logon's witnessed through Syslog. Here is what I've cobbled. Click the [Configure syslog sources] button and then click Create New to add a new entry. Populate it with values that are matching your scheme, here are mine:

Our final twist resides within our previously created Syslog Source "new entry" and specifically its Matching rule setup. Here is what I've setup on my end during my testings:

4648 A logon was attempted using explicit credentials.
4634 An account was logged off.

d:'Account Name:{{:username}}'
Network Address:{{:client_ip}}'

You might wonder why the "d:'Account Name:{{:username}}'". Well upon successful logon's, Windows will send logs embedding both, the computer name account (with an identifier labeled; Account Name) as well as the user credentials used (also labeled; Account Name). Hence within the logs, the line embedding the users credentials used always end up with d:Account Name:USERNAME. Hence a lazy way I found out for matching the correct value.

Currently, I couldn't bring the "Logoff" event to work yet. The Network Address/Client IPv4/6 field is sadly not populated within the Windows Security Event log upon a logoff event, hence not either part of the derived Syslog event. I'll dig in this and update upon success.. Nevertheless, the FSSO hard timeout applies of course.

And here are the resulting FSSO logon's being injected within FAC:

Remember that you can always debug what FAC is processing. The Syslog FSSO facility debug is located here:

Below is an edited debug entry matching the "WinDC-SysLog-rule" shown above:

<38>Jun 24 17:34:32 windc microsoft-windows-security-auditing[success] 4648 A logon was attempted using explicit credentials.''Subject:'Security ID:S-1-5-18'Account Name:COMPUTER$'Account Domain:DOMAIN'Logon ID:0x3e7'Logon GUID:'{00000000-0000-0000-0000-000000000000}''Account Whose Credentials Were Used:'Account Name:obruno'Account Domain:DOMAIN'Logon GUID:'{00000000-0000-0000-0000-000000000000}''Target Server:'Target Server Name:localhost'Additional Information:localhost''Process Information:'Process ID:0x218'Process Name:'C:\Windows\System32\lsass.exe''Network Information:'Network Address:CLIENTIP'Port:56186''This event is generated when a process attempts to log on'an account by explicitly specifying that accounts'credentials.  This most commonly occurs in batch-type'configurations such as scheduled tasks, or when using the'RUNAS command. 
06/24/2021 17:34:39 Extracted IP based on 'Network Address:{{:client_ip}}'': XX.XX.XX.XX
06/24/2021 17:34:39 Extracted user based on 'd:'Account Name:{{:username}}'': obruno
06/24/2021 17:34:39 Login from 'XX.XX.XX.XX' (IPv6=''), user 'obruno', group ''

That's it on this post.

Thanks for all your feedback emails; I'm literally flooded by emptiness while the traffic to this blog never ceases to grow =)


Image Credits: Prometheus (2012 film) / 20th Century Fox

Show Comments