WDAC audit logs

[JamesBowtell]

@

Hey, hope you're well.

I'm working on a Power BI dashboard that gives me a clear, single-screen view of all WDAC blocks and filter by single user, device or a whole department. The goal is to speed up the process of whitelisting apps and help with rolling out WDAC across our estate.

However, I'm running into an issue — the AppControl Manager (via MDE Advanced Hunting) is only showing me 10 logs, whereas when I run the query directly in MDE Advanced Hunting, I see 719 logs for the same machines over the past 7 days.

Has anyone come across this discrepancy before? Any ideas on how I can tweak my Power BI query or rule to match what AppControl Manager is seeing?

And also, i'm seeing a lot of blocks for DLLs listed as blocked in MDE logs but not in AppControl Manager, any advice for tackling DLLs as its becoming unmanageable to the point where it makes WDAC too much of an admin overhead.

Thanks in advance!

let
// Step 1: Use the filter string from the other query
DeviceFilter = DeviceFilterText,

// Step 2: Build the full KQL query with dynamic device filtering
KQLTemplate = "

DeviceEvents
| where (ActionType startswith 'AppControlCIScriptAudited'
or ActionType startswith 'AppControlCIScriptBlocked'
or ActionType startswith 'AppControlCodeIntegrityOriginBlocked'
or ActionType startswith 'AppControlCodeIntegrityOriginAudited')
| where {DeviceFilter}
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, ReportId,
InitiatingProcessAccountName, InitiatingProcessFileName,
InitiatingProcessCommandLine,
InitiatingProcessVersionInfoFileDescription,
InitiatingProcessParentFileName, InitiatingProcessFolderPath,
InitiatingProcessVersionInfoProductVersion
| sort by Timestamp desc",

FinalQuery = Text.Replace(KQLTemplate, "{DeviceFilter}", DeviceFilter),

// Step 3: Run the Defender API query
HuntingUrl = "https://api.securitycenter.microsoft.com/api/advancedqueries",
Response = Json.Document(Web.Contents(HuntingUrl, [Query = [key = FinalQuery]])),
Schema = Table.FromRecords(Response[Schema]),
Results = Response[Results],

TypeMap = #table(
    { "Type", "PowerBiType" },
    {
        { "Double",   Double.Type },
        { "Int64",    Int64.Type },
        { "Int32",    Int32.Type },
        { "Int16",    Int16.Type },
        { "UInt64",   Number.Type },
        { "UInt32",   Number.Type },
        { "UInt16",   Number.Type },
        { "Byte",     Byte.Type },
        { "Single",   Single.Type },
        { "Decimal",  Decimal.Type },
        { "TimeSpan", Duration.Type },
        { "DateTime", DateTimeZone.Type },
        { "String",   Text.Type },
        { "Boolean",  Logical.Type },
        { "SByte",    Logical.Type },
        { "Guid",     Text.Type }
    }),
TypedSchema = Table.Join(
    Table.SelectColumns(Schema, {"Name", "Type"}), {"Type"},
    TypeMap, {"Type"}
),
Rows = Table.FromRecords(Results, Schema[Name]),
WDACRaw = Table.TransformColumnTypes(Rows, Table.ToList(TypedSchema, (c) => {c{0}, c{2}})),

// Step 4: Add Action column
AddAction = Table.AddColumn(WDACRaw, "Action", each 
    if Text.Contains([ActionType], "Audited") then "Would Block" 
    else if Text.Contains([ActionType], "Blocked") then "Blocked" 
    else if Text.Contains([ActionType], "Revoked") then "Blocked" 
    else if Text.Contains([ActionType], "AppControlCodeIntegrity") then "Would Block" 
    else "Policy"),

Cleaned = Table.TransformColumns(AddAction, {
    {"InitiatingProcessVersionInfoFileDescription", Text.Clean, type text}, 
    {"InitiatingProcessParentFileName", Text.Clean, type text}
})

in
Cleaned

[HotCakeX]

Hi,
Thanks for letting me know, I'll definitely look into it and let you know about my findings. I'm planning to expand the UI to include a much better dashboard for filtering too btw.

[HotCakeX]

The events that have origin in their name, at least for the time being, are related to the ISG, such as ISG itself, or Smart App Control, or ManagedInstaller. More info here

Also, those event don't have the EtwActivityId part in the AdditionalFields section, so they can't be correlated with other data and they don't produce AppControlCodeIntegritySigningInformation events, that is why the app does not include them in the results because they simply don't have the necessary information to be used in policy creation, which is the main job of the MDE AH page in AppControl Manager.

I could however change the behavior so that they will still be visible in the app if you want to generate reports or perform advanced filtering.