Fix "Potential AS-REP Roasting via Kerberos TGT Requests"

[GrepItAll]

Summary of the Pull Request

Fix the PreAuthType selection field in the Potential AS-REP Roasting via Kerberos TGT Requests rule. Windows event viewer displays the human readable "Pre-Authentication Type", but EventData field is actually PreAuthType. Additionally, PreAuthType is a "Data" field, so must be treated as a string, not an integer

Changelog

fix: Potential AS-REP Roasting via Kerberos TGT Requests - use the correct PreAuthType selection field name

Example Log Event

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> 
    <EventID>4768</EventID> 
    <Version>0</Version> 
    <Level>0</Level> 
    <Task>14339</Task> 
    <Opcode>0</Opcode> 
    <Keywords>0x8020000000000000</Keywords> 
    <TimeCreated SystemTime="2024-05-28T06:32:40.2463627Z" /> 
    <EventRecordID>6231</EventRecordID> 
    <Correlation /> 
    <Execution ProcessID="752" ThreadID="3188" /> 
    <Channel>Security</Channel> 
    <Computer>DC01.acme.corp</Computer> 
    <Security /> 
  </System>
  <EventData>
    <Data Name="TargetUserName">john.smith</Data> 
    <Data Name="TargetDomainName">acme.corp</Data> 
    <Data Name="TargetSid">REDACTED</Data> 
    <Data Name="ServiceName">krbtgt</Data> 
    <Data Name="ServiceSid">REDACTED</Data> 
    <Data Name="TicketOptions">0x40800010</Data> 
    <Data Name="Status">0x0</Data> 
    <Data Name="TicketEncryptionType">0x17</Data> 
    <Data Name="PreAuthType">0</Data> 
    <Data Name="IpAddress">::ffff:10.0.0.1</Data> 
    <Data Name="IpPort">61965</Data> 
    <Data Name="CertIssuerName" /> 
    <Data Name="CertSerialNumber" /> 
    <Data Name="CertThumbprint" /> 
  </EventData>
</Event>

Fixed Issues

SigmaHQ Rule Creation Conventions

• If your PR adds new rules, please consider following and applying these conventions

[github-actions]

Welcome @GrepItAll 👋

It looks like this is your first pull request on the Sigma rules repository!

Please make sure to read the SigmaHQ conventions document to make sure your contribution is adhering to best practices and has all the necessary elements in place for a successful approval.

Thanks again, and welcome to the Sigma community! 😃

[GrepItAll]

Original rule submitted in PR #5428

[phantinuss]

Hi @GrepItAll, thanks for bringing this to our attention and providing a fix.

[phantinuss]

FYI: in Sigma integers shouldn't be quoted. There's no difference where in the source it is found. If it is important for the conversion target, then the sigma backend has to take care of it.

[GrepItAll]

FYI: in Sigma integers shouldn't be quoted. There's no difference where in the source it is found. If it is important for the conversion target, then the sigma backend has to take care of it.

Ok interesting, I noted when testing the rule using Chainsaw (WithSecureLabs/chainsaw#219) that Chainsaw only successfully reported a detection when the 0 was wrapped in quotes. Is this something that needs modifying in Chainsaw, or within the Sigma project?

Apologies, first time contributing anything to either so want to ensure I'm asking the right thing of the right project :)

Just found WithSecureLabs/chainsaw#94 which states that chainsaw supports casting of types. I can therefore modify the Chainsaw mapping, allowing the PreAuthType value to remain as an int rather than a string in Sigma.

Thanks for the clarity!