Help request - Decoder for undecoded Kerberos logs (ID 4769) on Wazuh

[lngounou]

Hello,

I hope you're doing well.

I'm currently experiencing a log detection problem related to a Kerberoasting attack on my Wazuh server. Here's the background:

Events with ID 4769 do go up in Wazuh (as confirmed by the log files), but they are not correctly decoded, which prevents me from triggering an alert to detect this type of attack.

I'd also like to point out that I don't see these los in the Wazuh Dashboard when applying filters with attaues IOCs.

(Image 1: Checking the arrival of logs in wazuh from the agent)

(Image 2: Matching test with a detection rule)

Here is an example of a raw log from Wazuh:

2024 Dec 12 14:12:11 (APOLLON-DC02-150) any->EventChannel {"win":{"system":{"providerName":"Microsoft-Windows-Security-Auditing","providerGuid":"{54849625-5478-4994-a5ba-3e3b0328c30d}","eventID":"4769","version":"0","level":"0","task":"14337","opcode":"0","keywords":"0x8020000000000000","systemTime":"2024-12-12T13:11:00.878063400Z","eventRecordID":"3189432","processID":"588","threadID":"3672","channel":"Security","computer":"apollon.thunder.olympus.local","severityValue":"AUDIT_SUCCESS","message":"\"A Kerberos service ticket was requested.\r\n\r\nAccount Information:\r\n\tAccount Name:\t\telectra....@THUNDER.OLYMPUS.LOCAL\r\n\tAccount Domain:\t\tTHUNDER.OLYMPUS.LOCAL\r\n\tLogon GUID:\t\t{4bec7cf5-2b71-2aed-f0f3-133fa284e1e0}\r\n\r\nService Information:\r\n\tService Name:\t\tclio.alcyone\r\n\tService ID:\t\tS-1-5-21-2514850342-1308460479-2044018965-1119\r\n\r\nNetwork Information:\r\n\tClient Address:\t\t::ffff:192.168.10.154\r\n\tClient Port:\t\t48296\r\n\r\nAdditional Information:\r\n\tTicket Options:\t\t0x40810010\r\n\tTicket Encryption Type:\t0x17\r\n\tFailure Code:\t\t0x0\r\n\tTransited Services:\t-\r\n\r\nThis event is generated every time access is requested to a resource such as a computer or a Windows service.  The service name indicates the resource to which access was requested.\r\n\r\nThis event can be correlated with Windows logon events by comparing the Logon GUID fields in each event.  The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.\r\n\r\nTicket options, encryption types, and failure codes are defined in RFC 4120.\""},"eventdata":{"targetUserName":"electra....@THUNDER.OLYMPUS.LOCAL","targetDomainName":"THUNDER.OLYMPUS.LOCAL","serviceName":"clio.alcyone","serviceSid":"S-1-5-21-2514850342-1308460479-2044018965-1119","ticketOptions":"0x40810010","ticketEncryptionType":"0x17","ipAddress":"::ffff:192.168.10.154","ipPort":"48296","status":"0x0","logonGuid":"{4bec7cf5-2b71-2aed-f0f3-133fa284e1e0}"}}}

2024 Dec 12 14:17:06 (APOLLON-DC02-150) any->EventChannel {"win":{"system":{"providerName":"Microsoft-Windows-Security-Auditing","providerGuid":"{54849625-5478-4994-a5ba-3e3b0328c30d}","eventID":"4769","version":"0","level":"0","task":"14337","opcode":"0","keywords":"0x8020000000000000","systemTime":"2024-12-12T13:15:55.889248000Z","eventRecordID":"3189562","processID":"588","threadID":"3672","channel":"Security","computer":"apollon.thunder.olympus.local","severityValue":"AUDIT_SUCCESS","message":"\"A Kerberos service ticket was requested.\r\n\r\nAccount Information:\r\n\tAccount Name:\t\tvag...@THUNDER.OLYMPUS.LOCAL\r\n\tAccount Domain:\t\tTHUNDER.OLYMPUS.LOCAL\r\n\tLogon GUID:\t\t{2190600e-9945-78a5-b225-c4cf5301f56e}\r\n\r\nService Information:\r\n\tService Name:\t\tclio.alcyone\r\n\tService ID:\t\tS-1-5-21-2514850342-1308460479-2044018965-1119\r\n\r\nNetwork Information:\r\n\tClient Address:\t\t::ffff:192.168.10.154\r\n\tClient Port:\t\t48694\r\n\r\nAdditional Information:\r\n\tTicket Options:\t\t0x40810010\r\n\tTicket Encryption Type:\t0x17\r\n\tFailure Code:\t\t0x0\r\n\tTransited Services:\t-\r\n\r\nThis event is generated every time access is requested to a resource such as a computer or a Windows service.  The service name indicates the resource to which access was requested.\r\n\r\nThis event can be correlated with Windows logon events by comparing the Logon GUID fields in each event.  The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.\r\n\r\nTicket options, encryption types, and failure codes are defined in RFC 4120.\""},"eventdata":{"targetUserName":"vag...@THUNDER.OLYMPUS.LOCAL","targetDomainName":"THUNDER.OLYMPUS.LOCAL","serviceName":"clio.alcyone","serviceSid":"S-1-5-21-2514850342-1308460479-2044018965-1119","ticketOptions":"0x40810010","ticketEncryptionType":"0x17","ipAddress":"::ffff:192.168.10.154","ipPort":"48694","status":"0x0","logonGuid":"{2190600e-9945-78a5-b225-c4cf5301f56e}"}}}

My aim is to decode this log correctly so as to be able to detect Kerberoasting attacks, with the IOC : 

• EventID : 4769
• Account name that is NOT a service or machine account (ending with $), so any normal domain user account
•  Service Names that do NOT end with $
  
• Ticket encryption type will be 0x17 which is RC4 encryption

Could you help me create a suitable decoder and also a rule, or direct me to resources/documentation specific to this problem? Any help would be greatly appreciated.

Thank you in advance for your support.

Sincerely
 Loic Ngounou

[Kevin Ledesma]

Hello Loic! 

In this case you will only require a custom rule, the event on archives.json is correctly decoded as windows_eventchannel, but as you noticed, that is not the case when testing the event on wazuh-logtest, that is because the tool does not work with Windows events, at least not in the EventChannel format.

So you only have to create a custom rule on the file  /var/ossec/etc/rules/local_rules.xml that could look something like:

<group name="windows,windows_security,">

<rule id="100006" level="3">

<if_sid>60103</if_sid>

<field name="win.system.eventID">^4769$</field>

<description>You custom description for the rule</description>

<options>no_full_log</options>

</rule>

</group>

To test the Windows events you could try this workaround where you basically change the decoder assigned to the main Windows events rule, then you have to convert the event to JSON and then you can use the tool normally (another useful link).

There is also another option, this script tool can be used to directly push a Windows event to the Wazuh-manager queue making it process the event and test if your custom rule matches the event and raises an alert. It needs the event in XML format saved on a local file as input, and nothing else.

I hope you find my answer helpful! If you have any other issue or concern, feel free to post on any of our community channels!

Regards

[lngounou]

Hello Kevin, 

Thank you for your fast replying. I will test your recommandation and let you know you. 

I have another question: if the events are decoded by wazuh, why don't we see these events in the dashboard and especially when we filter the events by IOCs? 

Thank you in advance for your support.

Sincerely
Loic Ngounou

[Kevin Ledesma]

Hello!

That happens because the decoders are not the ones that "raises the alerts" that is the rules' job, the decoders, as the name suggests, decodes the event normalizing its data so then can be matched with a rule.

The ones you are sharing are rules, there is probably something not right in the way the rules are trying to filter the events, I would recommend you to try "simpler" versions, starting by filtering with one field, and adding more filters later to make the rule "finer".

Also I recommend you to take a look to the data analysis user manual section from our documentation!

Have a great day!