Sealighter crashes for MOF providers

[ITeaSec]

Hi, I tried starting a trace session for the Provider "Active Directory Domain Services: Core" (GUID: 1C83B2FC-C04F-11D1-8AFC-00C04FC21914) but Sealighter crashes after printing the session info.

    "user_traces": [
        {
            "trace_name": "test_file_trace",
            "provider_name": "{1C83B2FC-C04F-11D1-8AFC-00C04FC21914}"
        }
   ]

Looks like the same happens for other MOF Providers as well.

Since it's not mentioned directly in the documentation - are MOF-Providers generally not supported? KrabsETW does support MOF and I was able to start the session and parse the events directly via Krabs.

Also, is there any flag to activate some verbose debugging output for Sealighter? Thanks!

[pathtofile]

Hey @ITeaSec , sorry you're having an issue, but Sealighter Can get events from MOF providers for me, for example I used this config to sucessfully get events from the Microsoft-Windows-DotNETRuntime provider (I don't have a ADDS machine to test the exact provider you mentioned):

{
    "session_properties": {
        "session_name": "Sealighter-Trace",
        "output_format": "stdout"
    },
    "user_traces": [
        {
            "trace_name": "test",
            "provider_name": "{e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}"
        }
    ]
}

Could I have some more info about your windows version, if you built it yourselv, etc.? Sorry it doesn't have a lot of error logging, if you wanted to look into the code to see where yours might be crashing, the function handle_event_context is where an event first reaches Sealighter, after all the configuration parsing and provider setup.

[ITeaSec]

Hi @pathtofile, sorry for the delayed reply. Thanks for looking into this!

I have tested it with the DC machine from Detection Lab (https://detectionlab.network/), which is using this vagrant box: https://app.vagrantup.com/detectionlab/boxes/win2016

Windows Server 2016 Standard Evaluation OS Version: 10.0.14393

I didn't have time yet to look into the code, but I have done some additional testing with a Windows 10 Client machine (also the DetectionLab Box, see https://app.vagrantup.com/detectionlab/boxes/win10): Windows 10 Enterprise Evaluation OS Version: 10.0.18363

I tested for instance the following config for the Provider "Local Security Authority (LSA)", which also failed:

{
    "session_properties": {
        "session_name": "testsession",
        "output_format": "stdout"
    },
    "user_traces": [
        {
        "trace_name": "test",
        "provider_name": "{cc85922f-db41-11d2-9244-006008269001}"
        }
   ]
}

Regarding your example for Microsoft-Windows-DotNETRuntime: Are you sure, the provider you tested is indeed a MOF provider? As far as I understand, the .NET-Runtime provider is MOF for older .NET-versions and manifest-based for newer versions, but uses the same provider ID as described here: https://github.com/microsoft/krabsetw/issues/143

On my system, it looks like its manifest-based and I was not able to find a corresponding MOF object: Get-CimClass -Namespace root/wmi | ? {$_.CimSuperClassName -like "EventTrace" -and $_.CimClassQualifiers.Item("Guid") -like "*e13c0d23*"}

If you're interested in some more testing, you can print the Descriptions and GUIDs for MOF-Providers on your system via the following code snipped for a quick overview (format is not very pretty though and there might be a better way to do this): Get-CimClass -Namespace root/wmi | ? {$_.CimSuperClassName -like "EventTrace"} | ForEach-Object CimClassQualifiers | ? {$_.Name -like "Description" -or $_.Name -like "guid" }| Format-List -Property Value

[pathtofile]

hey, would you look at that, I got a crash! :D Thanks mate, you were right pointing out the .NET provider now being manifest, for the record I cleaned up your example to make this snippet to list MOF providers using powershell

Get-CimClass -Namespace root/wmi |? {
  $_.CimSuperClassName -like "EventTrace"
} |% {
  [PSCustomObject]@{
    name = ($_.CimClassQualifiers |? {$_.Name -eq "Description"}).Value
    guid = ($_.CimClassQualifiers |? {$_.Name -eq "guid"}).Value
  }
}

I was able to get a crash using the LSA provider, and traced the issue. It was wholey in Sealighter's code, and actually related to feature I added a while ago to KrabsETW - Krabs typically only provides you events that are from ETW Providers you specficially subscribe to, but I added a 'default callback' handler a little while ago, because sometimes you might get events to providers you didn't specficially subscribe to. This was to handle getting events from "provider groups", but I possibly vaguely remeber I might have also added this patch to help handle MOF providers.

Anyway, I failed to properly implement my own Krabs code in Sealighter, leading to the crash. I've fixed it in the main branch, @ITeaSec would you be able to test and confirm it's fixed for you also?

[ITeaSec]

Yep, I tested my config from above on the DC again for the MSAD Trace Provider and I'm getting the data now :)

Thanks a lot for looking into it and fixing it so fast! :)

[pathtofile]

Awesome :-) Alright, built and pushed out a new tag with the fix, so everyone has access to fixed pre-built binaries: https://github.com/pathtofile/Sealighter/releases/tag/v1.7

Thanks for raising the issue mate! Sorry the error logging isn't awesome, it's on the cards to look at, but I don't think it's super high priority in my life atm.