FalconFriday: MITRE linked KQL hunting queries for Defender for Endpoint and Sentinel

One Markdown file per offensive technique, numbered with a 0xFF prefix

FalconFriday is a repository of hunting queries rather than a program. There is no package to install, no service to run and no build step, because the deliverable is a set of KQL queries written in Markdown files that sit at the root of the repository. The naming scheme does the cataloguing work. Every file carries an identifier in the form 0xFF-NNNN, followed by a description of the technique and a suffix marking the platform, so a name like 0xFF-0081-Process_Injection_From_Untrusted_Process-Win.md tells you the technique and the target environment before you open the file. The full range covers Windows, Azure, and AWS, with entries such as 0xFF-0270-NTLM_Relay_Attack-Win.md, 0xFF-0294-ADCS_Certificate_Requested_via_Web_Interface.md and 0xFF-0240-Instance_Profile_Credentials_Used_from_Unexpected_IP-AWS.md. A hunts folder exists alongside the flat files, and the numbering runs across technique IDs rather than dates, which makes it easy to reference a single hunt by number when you discuss it with a colleague.

The hunt list covers injection, credential theft and cloud enumeration

The technique spread is wide enough that the repository reads as a catalogue of offensive tradecraft rather than a single speciality. The README lists the intended targets: DLL injection, process injection, COM hijacking, .NET to JScript, aborted MFA requests, abuse of LOLBins, misbehaving Office applications, process hollowing, unmanaged binaries running managed code, anomalies in LDAP traffic, command execution using WMI and SMB NULL session attempts. The file names show how that list was later widened. Password spraying has a dedicated hunt, 0xFF-0044, and so does runas abuse with 0xFF-0049 and LSASS dumping with 0xFF-0241. The cloud entries are a different family: 0xFF-0161 flags an overly permissive security group, 0xFF-0235 covers a user accessing excessive secrets, 0xFF-0238 an assume role added from an unknown external account, and 0xFF-0219 excessive share permissions. For a reader deciding whether this is relevant, the honest summary is that it is a hunting library with a strong Windows centre of gravity and a growing cloud section.

Each hunt ships with its reasoning, not just a query

The stated publishing format is the reason this repository is worth reading even if you never paste a query. Each hunt is released with a short accompanying blog post on Medium that covers the background, how the query works, the accuracy expected, possible variations, improvements, catches, and anything else the team considers relevant. The queries themselves are linked to MITRE ATT&CK, and some techniques are covered by more than one variant that detects the same behaviour in different ways. The team is explicit about trade-offs within a single query as well, documenting them so a reader can steer towards fewer false positives or fewer false negatives depending on what their environment can tolerate. The README also notes that the work started from the library of ired.team, with the MDE-specific versions written for Microsoft Defender for Endpoint, and that Sysmon hunts may follow since olafhartong is involved. For a detection engineer, that combination, a technique, a query, an expected accuracy and a written trade-off, is closer to a design note than to a rule dump.

Adopting one hunt: copy the KQL, then rewrite it for your tenant

There is no installer here, so the practical sequence for using FalconFriday is short. Take the numbered Markdown file for the technique you care about from the repository, open the KQL it contains, and run it against the telemetry you already collect. The second step is the whole job. The project is explicit that a foundation query still has to be fine-tuned or extended to the specifics of your organisation before it works in your environment and integrates into your monitoring solution, so a copy and paste into the Defender hunting pane is where you start, not where you finish. Two further details come straight from the repository's own approach. Each query is linked to a MITRE ATT&CK technique, so the identifier is what you use to trace a hunt back to the behaviour it is meant to expose, and where several variants exist for one technique, you pick the variant whose trade-off matches what your environment can absorb. The project also invites requests for specific attack techniques you want covered, so a gap in the numbering can be reported back to the team rather than filled with a homegrown rule that never gets tuned.

The project tells you not to expect a copy and paste win

This is the part of the README that matters most for anyone planning to adopt the queries. The instruction is blunt: do not expect to copy-paste the queries into your environment and be done with it. What is provided is a foundation query that can detect a certain technique, and you still need to fine-tune or extend it to your organisation's specifics before it works and before it integrates into your monitoring solution. That is a correct warning on their part, because a generic injection query will match legitimate software in most environments, and a hunt that fires on everything is worse than no hunt because it trains analysts to ignore the signal. The trade-off documentation exists for the same reason. If your goal is a scheduled, closed detection with a test case, this repository will disappoint you, because what it produces is analyst-facing detection engineering input, and the last mile of tuning is explicitly yours.

Licence and reuse terms are permissive, and attribution is only requested

The licence field for the repository is BSD-3-Clause, with a LICENSE file at the repository root, which is one of the more permissive open source licences and does not carry the copyleft obligations of the GPL family. The README adds its own practical position, that the queries are free to use in any way you like, with an appreciation for a reference back to the FalconForceTeam Twitter account or the FalconForce GitHub organisation rather than a requirement. There is no separate contributor licence agreement, no paid tier and no support contract mentioned anywhere in the documentation. The practical consequence is that an organisation can take a query, adapt it to its own environment, fold it into an internal detection library, and ship it internally without negotiating anything, provided it honours the BSD notice text in the LICENSE file. The flip side is that there is nobody accountable for the accuracy of a query after you have modified it, which is why the fine-tuning step the README insists on is not optional paperwork.

No releases, no tags, and a last push on 2026-05-07

The repository has no GitHub releases at all, which matters when you are thinking about how you would consume this content. There is no versioned artefact to pin, no changelog entry to diff and no upgrade path for the collection as a whole. What you consume is the current state of the main branch, and the state of the working tree is the only version identifier available. The last push to the repository was on 2026-10-22, and the project is not archived, so it is being worked on, but the documentation itself is written largely in the future tense, describing what the team plans to release on a regular basis rather than a published schedule you can plan against. For a team that wants hunts, that means reading the tree periodically and tracking the numbered files yourself, rather than subscribing to a release feed. For a team that wants a maintained detection content pipeline, this repository is one input among several, and the responsibility for versioning it is yours.

Where to look for a comparison, and where FalconFriday sits differently

The natural comparison for a hunting query library is a vendor detection rule set, and the difference in approach is straightforward. Commercial detection content ships with a versioned lifecycle, support commitments and often a mapping you can consume through an API. FalconFriday instead publishes the reasoning next to the query: a numbered file per technique, an ATT&CK link, a written expectation about accuracy, and a documented choice between false positives and false negatives. That is closer in spirit to a public detection engineering blog than to a managed ruleset, and it means you get the trade-off discussion rather than a support contract. The other comparison point is ired.team, the library the README says the work started from. FalconFriday differentiates by writing the queries for Microsoft Defender for Endpoint specifically, and by packaging each one with a technique number and a narrative. Neither source gives you a finished detection for your environment, so the choice between them comes down to whether you want the query or the commentary around it.

Editorial conclusion

FalconFriday suits a detection engineer who wants a written technique per file, a stated trade-off between false positives and false negatives, and a starting query that can be adapted rather than a finished rule. It suits a team less if you want packaged detection logic, test cases, or an update feed, because the repository ships no releases and its documentation is written in the future tense. Before adopting anything from it, read one query file end to end against your own telemetry, check the technique identifier against the ATT&CK mapping the file claims, and confirm that the source tables you rely on are actually ingested in your tenant.

Frequently asked questions

Official sources

1. FalconForceTeam/FalconFriday on GitHub
2. Issues
3. License: BSD-3-Clause
4. README