DefenderYara: Windows Defender signatures rewritten as YARA rules

Signatures pulled out of a closed binary

DefenderYara describes itself simply: extracted Yara rules from Defender mpavbase.vdm and mpasbase. The whole project is the consequence of that one line.

Microsoft's antimalware platform ships its detection logic inside binary modules rather than as inspectable rules. mpavbase and mpasbase are two of those modules, and the naming convention of the surrounding Microsoft documentation for antimalware naming, which the readme links, is what makes it possible to interpret what the extracted rules are looking for. The rules are not written by the project author in the usual sense. They are a mechanical translation of vendor logic, which is what makes them valuable and also what makes them fragile.

The readme is explicit about the fragility. A note under the sample rule says that some strings or conditions may be wrong. That is not a hedge, it is a description of a translation process that involves pulling string tables out of a data module and reconstructing match conditions by hand, with no access to the original source that generated them.

The project is a security artefact rather than a security tool. There is nothing to install and nothing to run. What you get is a large body of detection logic in a text format that a versioning system handles well, that a reviewer can read, and that fits into an existing YARA pipeline without a second scanner.

The reference section points at related work by commial and HackingLZ, both of which are attempts at the same problem, and at a defender-recon24 repository, plus the Microsoft documentation on antimalware naming. Those links tell you the project is one node in a community effort to make vendor signature logic legible.

Hex string sets with a weighted threshold condition

The sample rule in the readme shows the shape of almost everything in the collection, and the shape is distinctive.

rule HackTool_Win64_ATPMiniDump_lsa{
	meta:
		description = "HackTool:Win64/ATPMiniDump!lsa,SIGNATURE_TYPE_PEHSTR_EXT,05 00 05 00 06 00 00 "
		
	strings :
		$a_01_0 = {41 54 50 4d 69 6e 69 44 75 6d 70 } //2 ATPMiniDump
		$a_01_1 = {42 00 79 00 20 00 62 00 34 00 72 00 74 00 69 00 6b 00 20 00 26 00 20 00 75 00 66 00 30 00 } //2 By b4rtik & uf0
		$a_01_2 = {54 00 65 00 6d 00 70 00 5c 00 64 00 75 00 6d 00 70 00 65 00 72 00 74 00 2e 00 64 00 6d 00 70 00 } //2 Temp\dumpert.dmp
		$a_01_3 = {5b 00 21 00 5d 00 20 00 59 00 6f 00 75 00 20 00 6e 00 65 00 65 00 64 00 20 00 65 00 6c 00 65 00 76 00 61 00 74 00 65 00 64 00 } //1 [!] You need elevated
		$a_01_4 = {5b 00 21 00 5d 00 20 00 46 00 61 00 69 00 6c 00 65 00 64 00 20 00 74 00 6f 00 20 00 63 00 72 00 65 00 61 00 74 00 65 00 20 00 6d 00 69 00 6e 00 69 00 64 00 75 00 6d 00 70 00 2c 00 } //1 [!] Failed to create minidump,
		$a_01_5 = {5b 00 31 00 5d 00 20 00 43 00 68 00 65 00 63 00 6b 00 69 00 6e 00 67 00 20 00 4f 00 53 00 } //1 [1] Checking OS
	condition:
		((#a_01_0  & 1)*2+(#a_01_1  & 1)*2+(#a_01_2  & 1)*2+(#a_01_3  & 1)*1+(#a_01_4  & 1)*1+(#a_01_5  & 1)*1) >=5
}

Three things stand out. First, the strings are hex byte sequences, not text, and the byte patterns are wide character encodings: 41 54 50 4d is ATPM in ASCII, but the second string spells out By b4rtik with a 00 between every character, which is UTF-16. A defender reading only the rule sees noise until they decode it.

Second, the trailing comments carry the readable form, prefixed with a number that looks like a weight marker. The comments are the readable form of the hex, and they are what makes the rule reviewable at all.

Third, the condition is not a simple threshold. Each string is counted, the count is masked with a bitwise AND against 1, and each count is multiplied by a weight of 2 or 1, and the weighted total has to reach 5. The first three strings carry double weight. This weighted sum is a mechanical rendering of a vendor scoring model, and it is the part of the translation most likely to be subtly wrong, which is exactly what the warning about conditions refers to.

HSTR signature types and the work still outstanding

The readme tracks progress by signature type, and the naming follows the Microsoft antimalware naming scheme that the reference section points to.

The types listed as parsed are SIGNATURE_TYPE_PEHSTR_EXT, SIGNATURE_TYPE_ELFHSTR_EXT, SIGNATURE_TYPE_MACHOHSTR_EXT, SIGNATURE_TYPE_MACROHSTR_EXT, SIGNATURE_TYPE_DEXHSTR_EXT, SIGNATURE_TYPE_JAVAHSTR_EXT, SIGNATURE_TYPE_CMDHSTR_EXT, SIGNATURE_TYPE_ARHSTR_EXT and SIGNATURE_TYPE_PEHSTR. The trailing _EXT variants and the plain PEHSTR cover the executable and library formats across Windows, ELF, Mach-O, Java class files, DEX, AR archives, macro documents and command scripts.

The TODO list names the formats that are not yet handled: SIGNATURE_TYPE_SWFHSTR_EXT, SIGNATURE_TYPE_AUTOITHSTR_EXT, SIGNATURE_TYPE_INNOHSTR_EXT, SIGNATURE_TYPE_MDBHSTR_EXT and SIGNATURE_TYPE_DMGHSTR_EXT. Those correspond to Flash, AutoIt scripts, Inno Setup installers, Access databases and DMG disk images, and the fact that they are listed individually tells you the extraction is format by format rather than generic.

The distinction matters for a defender deciding whether a detection gap is a real gap. If a repository claims coverage of Defender signatures, you need to know which container formats were actually mined. Here that is knowable, and it is knowable because the project tracks it in the readme rather than leaving it to be discovered.

The extracted strings are also grouped by what the extracted rule is looking for, and the labels in the sample rule's meta description give the family away. The description field carries the Microsoft detection name, the signature type, and a trailing byte sequence that appears to be an internal version or parameters marker.

The directory tree mirrors the Defender classification

The top level of the repository is the clearest evidence of scale, and it is organised by the same taxonomy the vendor uses.

The directories with hashes in their names are working or rescanning directories rather than finished categories. You can see #ALF/, #ASRWin32ApiMacroExclusion/, #Adware/, #Exploit/, #FOPEX/, #HSTR/, #LoD/, #Lowfi/ and #PUA/, plus a set of directories that name their operation directly: #attrmatch_rescan_psif/, #do_deep_rescan/, #do_exhaustivehstr_64bit_rescan/, #do_exhaustivehstr_rescan/, #do_vmmgrow_rescan/. Those read like the internal stages of the extraction process, which is a hint that the author iterated on the rescan logic rather than doing a single pass.

The named category directories are the finished output. They are Adware/, Backdoor/, Behavior/, BrowserModifier/, Constructor/, DDoS/, DoS/, Exploit/, HackTool/, InfrastructureShared/, Joke/, Misleading/, MonitoringTool/, PUA/, PUAMiner/, PWS/, Program/ and a long tail of PseudoThreat directories with encoded names such as PseudoThreat_40000020/ and PseudoThreat_c00007d7/. The PseudoThreat family with numeric suffixes is the most interesting naming here, since the numbers look like identifiers carried over from the vendor's own naming rather than a category a human would invent. InfrastructureShared/ suggests rules that are deliberately shared across multiple detections rather than tied to one.

Two observations follow. The categories are a mixture of behavioural and taxonomic labels, so HackTool/ and Behavior/ describe what a sample does while Backdoor/ and Adware/ describe what it is, and a single rule could plausibly belong to more than one. And the presence of directories such as Joke/ and Misleading/ tells you the extraction was not filtered for seriousness, which is correct for a rule corpus and worth knowing before you point a scanner at it.

How to use the rules and what to check first

There are no installation instructions, and that is correct. The output is a set of .yar files arranged in directories, and the way to use them is with the YARA tooling you already have.

The practical workflow has three steps, and only the first two are obvious. Clone the repository, point your YARA command at the rule directories rather than at a single file, since the tree is organised as a hierarchy of categories, and then, and this is the part that matters, validate the rules before you trust them. The readme's own warning is the specification for that step: some strings or conditions may be wrong, so a rule can compile, load and scan without ever firing on the sample it was written for, or can fire on things it should not.

A sensible validation approach, given what the readme says, is to take a handful of known samples for a given detection name, run the corresponding rule against them, and confirm it matches. The meta description field gives you the Microsoft detection name for each rule, which is the join key to any sample you already have, since that name is what a Defender alert or a public sandbox report would give you. Where the rule does not fire on a sample the vendor flags, you have found a broken extraction and can decide whether to fix the condition or drop the rule.

You also want to check for false positives before deployment, because the conditions are threshold based and a misweighted sum is a false positive generator. Weighting two of the six strings double and requiring a total of 5 means a file with three double weighted strings and nothing else can satisfy the rule, and that is a property of the translation rather than of the malware.

The repository has no GitHub releases, so the tip of the default branch is what you get. The last push was on 2026-05-14, and the readme documents the state of the extraction work as of that point, including the outstanding HSTR types, which is the thing to watch for as the project progresses.

Why this corpus and not the vendor's own definitions

There is a real alternative here, and it is not another YARA collection. Microsoft's own antimalware definitions are what Defender actually uses, and the readme links the Microsoft documentation on malware naming, which is the part of that definition stack a defender can legitimately consult.

The difference in approach is what the corpus is for. The vendor definitions are a binary artefact that you either trust wholesale or not at all, and they change without a changelog you can read, and they are not mergeable into a pull request. The extracted rules are the opposite on all three counts. They are text, they live in git so you can see when a detection changed, and they can be proposed as a pull request to a detection repository that your team already reviews.

The cost of the approach is accuracy, and the readme is upfront about it. A rule translated by hand from a data module is a reconstruction, not a copy, and the project says so. A corpus of a hundred thousand near-correct rules is also not the same thing as a hundred thousand correct rules, and a detection pipeline that fires on the whole corpus inherits every reconstruction error in it.

There is a second alternative worth naming for comparison, which is a different tool rather than a different source. YARA itself, or a commercial scanner, works on the same principle of pattern based matching but with maintained rule sets written by their authors, and those rule sets come with the expectation that they are correct and tested. The difference in approach is authorship and accountability: a maintained rule has a named author who tests it, while an extracted rule has a transcription.

The pragmatic position is that the two are complementary rather than competing. DefenderYara is most useful as a source of insight into what the vendor is looking for, particularly the string sets that a defender might not have thought to search for, and as a comparison set for a rule you have written yourself. It is least useful as the sole basis of a detection pipeline.

Editorial conclusion

DefenderYara suits a detection engineer who wants Defender's own signature logic in a form they can diff, review and merge into an existing YARA pipeline, and it does not suit anyone treating the repository as a source of ground truth, because the readme states that some strings or conditions may be wrong. Before you deploy any rule from this collection, run it against a corpus you control and compare it with the vendor signature, and note that the repository carries no licence that GitHub can classify, so read the LICENSE file yourself before you redistribute the rules.

Frequently asked questions

Official sources

1. Issues
2. README
3. roadwy/DefenderYara on GitHub