App Control & Advanced Hunting

Find out what App Control would block in your environment — then build a policy from what you find.

Requires Microsoft Defender for Endpoint with Advanced Hunting   ·   Advanced Hunting retains 30 days of data

The short version

Application control is the single most effective thing you can do to stop untrusted code running — and the one most organisations never finish deploying. The reason is almost always the same: nobody can answer “what will break if I turn this on?”

This page of Highwind answers that question using data your tenant is already collecting. Deploy an audit-mode policy, let it run, and every Code Integrity event lands in Advanced Hunting. Highwind pulls those events, compares them against real policy files, and tells you exactly which applications are not yet covered.

This is not only for building an allow policy. Use it to author a policy that permits software, one that blocks it, or simply to survey your estate and find out what enforcement would break — before you commit to anything.

The workflow, in order

Each step depends on the one before it. Do them in this order.

  1. Sign in. Pick your cloud — Commercial, GCC, GCC‑High or DoD — then click Sign In. You need the Advanced Hunting read permission in the tenant.
  2. Load your policies first. Open the Policies drawer and choose Local active for the policies already on this machine, or Browse folder for a draft you are testing. Doing this before you query is what makes results come back already compared, instead of every row reading “Not Evaluated”.
  3. Set your scope. Last N days sets the lookback, Max caps the rows returned. Switch the view to Fleet Impact for a whole-tenant picture rather than individual events.
  4. Pick a Group by level (Fleet Impact only). Match it to the rule type you intend to write — see the table below. On a large tenant this is the single biggest lever on how much data comes back.
  5. Run the query. Results are compared against your loaded policies automatically. Read the Disposition column: Would Still Block is your work queue, Allowed is already covered.
  6. Work the list in Decisions. Record Allow / Block / Defer / Need info per application, with an owner, ticket reference and rationale. Decisions save to disk and are reapplied on future queries.
  7. Export. The Export drawer produces rule fragments or a complete policy from a template. The rollout enablement exports give you the application inventory, the publisher shortlist and a scored readiness report.
  8. Deploy in audit mode first. Let it run for at least one full patch cycle, then repeat this workflow. Only enforce once the readiness assessment shows the estate is genuinely covered.

Choosing a Group by level

One row should equal one thing you would write a rule for. Match this setting to the rule type you plan to author.

Publisher (signer)

Smallest result. One row per signer. Use when you intend to trust vendors wholesale with Publisher rules.

Publisher + product

The usual starting point. One row per product per vendor — small enough to read end to end, specific enough to decide on.

File identity

One row per distinct file, ignoring version and location. Matches FilePublisher / FileName rules and collapses per-user install paths automatically.

File + location

One row per file per folder, with user-profile paths normalised to \Users\*\. Use when authoring FilePath rules.

Hash

Largest result. Every version of every binary. Only for Hash rule authoring — expect this to be very large.

Why this matters on a large estate. The finest level keys on hash and folder path. Per-user installs such as Teams, Chrome, Zoom and VS Code live under C:\Users\<name>\AppData, so one application can produce one row per user — hundreds of thousands of rows describing a single app. Grouping at the level you will actually write rules at removes that at source, before any result-size limit is reached.
Switching Group by does not re-run the query. Results are regrouped from the data already collected, so you can look at the same pull several ways for free. One limit: grouping only runs one way. You can always go coarser, but you cannot recover detail that was discarded — asking for Hash after collecting at Publisher will prompt you to re-run rather than show something wrong. If you expect to explore, collect at a fine level once. Regrouped results are badged Regrouped locally, and comparison results are cleared because the rows changed shape.

Rule precedence — a different setting

Group by decides how rows are grouped. Rule precedence, on the right of the same toolbar, decides which rule each row is recommended. They list similar-sounding names, so they are easy to confuse — but they are independent, and precedence is the one that shapes your finished policy.

It behaves exactly like PowerShell New-CIPolicy -Level <first> -Fallback <rest>: the first level an event actually satisfies wins. Drag to re-rank, or select and use the arrows. The order is saved between sessions, and a custom badge appears whenever it differs from the recommended default.

LevelMatches onSurvives an update?
FilePublisherSigner + original file name + minimum versionYes — the usual right answer
PublisherSigner + issuing CAYes — broadest; trusts a vendor's whole catalogue
SignedVersionSigner + minimum versionYes
FileAttributePE header fields (InternalName, ProductName)Usually — good for signed files that get renamed
FileNameFile name onlyYes, but defeated by renaming a file
HashExact SHA256No — breaks on every patch
FilePathAny file in a locationYes, but only safe where standard users cannot write
The hash trap. Hash rules look like the safe choice because they are the most precise. In practice a hash-led policy is the one that gets abandoned: every Patch Tuesday invalidates it and someone has to re-author the lot. Keep signer-based levels first and let hashes catch only what is genuinely unsigned. Equally, a FilePath rule under C:\Users\ is user-writable — it effectively means "allow anything".

Recommended order, and what Reset to defaults restores: FilePublisher → Publisher → SignedVersion → FileAttribute → FileName → Hash → FilePath. After changing the order, existing results are stale until you re-evaluate — use Apply & re-compare in the same panel.

Reading the Disposition column

Disposition is the result of comparing each event against the policies you loaded.

The Recommend column suggests the rule type that would authorise the file, based on the metadata the event actually carries — a signer if one exists, otherwise file attributes, a path, or a hash as a last resort.

The Decisions workbench

A rollout is not a single sitting. You pull a month of data, work through the top publishers, email four application owners, and come back on Thursday. The Decisions workbench is what lets that work accumulate instead of starting over each time.

  1. Run a query first — the workbench lists every distinct application in the results.
  2. Select a row and record a verdict: Allow, Block, Defer (waiting on a vendor or an upgrade) or Need info (waiting on an application owner).
  3. Fill in Owner, Ticket and Why before pressing the verdict button. These are typed by you — Advanced Hunting does not supply them — and they are what make the ledger an audit trail rather than a list of verdicts.
  4. Use Save notes to update the annotation on an already-decided row without changing the verdict.
  5. Decisions persist keyed by publisher + product + original file name, so they survive re-running the query, restarting Highwind, and the vendor shipping a new version.
  6. Ledger → Sync with shared ledger points at a file on a share: it reads it, merges your decisions in, writes it back and adopts the result, so several admins can work one master list. Newest decision wins per application, and genuine disagreements are reported rather than applied silently.
  7. Ledger → Export audit trail (CSV) produces the who-approved-what-and-why record for your change board.
Two columns worth understanding. Review grades how hard to look before allowing — an unsigned kernel driver is flagged HIGH, a third-party signed driver CHECK (signed drivers are the Bring-Your-Own-Vulnerable-Driver vector), a Microsoft-signed driver only FYI. Rule durability tells you whether the rule will survive the next vendor update: Durable means a signer rule covers it, Brittle means only a hash or a user-writable path will, and a policy made mostly of Brittle rules needs re-issuing every patch cycle.

Very large environments

Advanced Hunting has a 30-day retention, a per-query complexity limit, a response-size cap and a request rate limit. On an estate of a few hundred thousand devices, all four bite.

Watch the status bar. TRUNCATED means more distinct binaries were found than your row limit kept — raise the limit, because the rows dropped are the low-reach long tail, which is exactly what is still missing from your policy. An incomplete window warning means a 30-minute slice still exceeded the service limits; narrow the scope with a vendor or product filter and re-run.

What you can export

Where to go next

The same guidance is available inside the app: Knowledge Base → Application Control → Advanced Hunting.