{
	"id": "742abb08-0f68-4fba-a0fb-91b73d6e5266",
	"created_at": "2026-04-06T00:14:15.00012Z",
	"updated_at": "2026-04-10T03:38:20.816734Z",
	"deleted_at": null,
	"sha1_hash": "f2144ce8647afe942d16e8886735e5ef139ce02d",
	"title": "leveraging this mysterious artifact of the PE format",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 572481,
	"plain_text": "leveraging this mysterious artifact of the PE format\r\nArchived: 2026-04-05 12:56:23 UTC\r\nVB2019 paper: Rich Headers: leveraging this mysterious artifact of the PE format\r\nMichal Poslušný \u0026 Peter Kálnai\r\nESET, Czech Republic\r\nAbstract\r\nEver since the release of Visual Studio 97 SP3, Microsoft has placed an undocumented chunk of data between the DOS\r\nand PE headers of every native Portable Executable (PE) binary produced by its linker without any possibility to opt out.\r\nThe data contains information about the build environment and the scale of the project, stored in a simple yet effective\r\nway using blocks of the following values: a product identifier, its build number, and the number of times it was used\r\nduring the build process. Several research papers on this topic have been released over the years, coming up with the\r\nname ‘Rich Header’ and shedding some light on its purpose and structure, but we feel that it has never been used to its\r\nfull potential by the security industry.\r\nWhen an analyst encounters a rare custom malware sample involved in, say, an APT, and is clutching at straws to draw\r\nconclusions about the case, this mysterious structure could provide some reasonable clues. Not only does it reveal the type\r\nof components involved in the project behind the malware and the build tools used, but, forming an abounding set of\r\nvariations, it also helps with locating similar samples. We introduce a hierarchy of similarity levels, together with real-world examples where they have successfully been applied.\r\nFor various crimeware kits, which are (re)distributed on a daily basis, the header could indicate whether their source code\r\nis available more widely or under the control of a single actor. Moreover, the headers from their encapsulating malware\r\npackers often manifest their own anomalies and could cluster a larger set of samples of the same nature. These\r\ninconsistencies could easily be identified and turned into heuristics based on the situation, such as: an unusual offset or\r\nthe size of the header, an invalid identifier or its combination with the build version, the image size not corresponding to\r\nthe magnitude of the project, etc.\r\nWe will also showcase our in-house designed database infrastructure and the tooling we’ve built around it: similarity\r\nlookup, a rule-based notification system for malware hunting and the detection of anomalies. The database currently holds\r\nthe Rich Header information for tens of millions of executables and continuously processes a live feed of new, incoming\r\nfiles. It is currently growing by ~180,000 unique records per day.\r\nIntroduction\r\nPE ‘Rich Headers’ were introduced with the release of Visual Studio 97 SP3. Microsoft didn’t announce that it had\r\nimplemented such a feature or give a reason for its introduction, and never released any kind of documentation for it, so\r\nwe cannot really be sure about its original purpose, but it seems that Microsoft simply wanted to have some sort of\r\ndevelopment environment fingerprint stored in the executables, or perhaps to help with diagnostics and debugging.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 1 of 25\n\nRegardless of the original intent, the Rich Header has proved to be a very valuable block of data for malware researchers,\r\nwhere a few hundred bytes, when interpreted correctly, can be used as a very strong factor for attribution and detection.\r\nFigure 1: PE binary with Rich Headers highlighted.\r\nThe structure\r\nThe meaning of the ‘header’ is actually quite straightforward. In Figure 2 we can see the structure of the header, as\r\ndescribed by Microsoft in the Windows 2000 source code leak [1]. The data is inserted after the IMAGE_DOS_HEADER\r\nand its stub and before the beginning of the PE header (IMAGE_NT_HEADERS structure).\r\nIts end is marked by the Rich keyword (0x68636952) followed by an XOR key DWORD, which was used to encrypt the\r\nrest of the header. The beginning of the plaintext header is marked by the DanS keyword (0x536E6144), followed by\r\npadding of three null DWORDs.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 2 of 25\n\nFigure\r\n2: Rich Headers definition in Microsoft Windows 2000 source code leak.\r\nAs we can see in Figure 2, the data is an array of simple 64-bit PRODITEM structures that consist of two 32-bit fields:\r\ndwProdid and dwCount. The dwProdid field is a combination of a product identifier (ProdID) and its corresponding Build\r\nnumber and can be considered as two separate 16-bit values.\r\nProdID represents a product from the Visual Studio development toolchain – these include objects like linkers, C/C++\r\ncompilers, MASM, resources, imports, implibs, etc. One is assigned to every object file upon creation and eventually all\r\nProdIDs from every object file used in a project are collected and written into the resulting binary, by the linker, during\r\nthe linking process.\r\nSince ProdIDs are an enumeration of numerical values, it is quite hard to identify their meaning on their own. Luckily, we\r\ncan find the values and their corresponding names in the Visual Studio installation directory in one of the msobj.lib\r\nbinaries. For example, Figure 3 shows the msobj140-msvcrt.lib file, which can be found in Visual Studio 2015 – 2019,\r\nand which contains a list of all ProdID values followed by their names.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 3 of 25\n\nFigure 3:\r\nProdID names as found in the msobj.lib binary.\r\nThe easiest way to find the Rich Header is to look for the Rich DWORD between the DOS and PE header (which marks\r\nthe end of the Rich Header), extract the following XOR key DWORD and go backwards, XORing the data until the\r\ndecrypted DanS DWORD is reached.\r\n Figure\r\n4: The unencrypted Rich Headers structure.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 4 of 25\n\nXOR key (checksum)\r\nThe XOR key used for encryption of the Rich Header is a unique four-byte value generated for every executable built by a\r\nMicrosoft compiler (linker). The value is a checksum of the DOS header, the DOS stub and plaintext Rich Header data.\r\nThe checksum calculation algorithm can be found in the IMAGE::CbBuildProdidBlock function in Visual Studio’s\r\nlink.exe binary. A code snippet is shown in Figure 5.\r\n Figure 5: XOR\r\nkey generation in Microsoft’s Visual Studio 2019 linker executable.\r\nSince the checksum algorithm consists of a simple addition and 32-bit rotate left, it can produce collisions. We have\r\nidentified a few cases where the collision happens for one of two specific reasons.\r\nThe first case is when two projects contain identical PRODITEM entries, but in a different order. This is not necessarily\r\nunwanted behaviour and might even be intended by its designer. Both samples in Table 1 have the XOR key\r\n0xAEB29219 [2].\r\nkb.dll (2010-12-6 13:36:13) phpF746.exe (2017-11-19 7:7:58)\r\nprodidMasm614   | b8444 | 1\r\nprodidLinker512 | b8078 | 9\r\nprodidLinker512  | b8078 | 9\r\nprodidMasm614    | b8444 | 1\r\n Table 1: XOR key collision example – order of PRODITEMs.\r\nAnother common case is due to the 32-bit rotation used in the algorithm (ProdID + build is rotated by its count). If two\r\nprojects have identical ProdID and build but different counts whose delta is a multiple of 32, the resulting checksum will\r\nbe identical. Table 2 is another example of two samples that also have the XOR key 0xAEB29219.\r\nmoar.exe (2017-5-9 10:24:58) phpF746.exe (2017-11-19 7:7:58)\r\nprodidLinker512 | b8078 | 41\r\nprodidMasm614   | b8444 | 1\r\nprodidLinker512 | b8078 | 9\r\nprodidMasm614   | b8444 | 1\r\n Table 2: XOR key collision example – counts delta.\r\nBehaviour\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 5 of 25\n\nRich Headers reflect the nature and scale of the project and simply by looking at the ProdID names, we can see the\r\nvarious features used in the project like imports, resources, or whether the project was written in Assembly, C, C++ or\r\n(pre .NET) Visual Basic, and approximately how large the project is, based on the product counts.\r\nRich Headers tend to change over time in an actively developed project – new ProdIDs may appear and their counts often\r\nincrease as new source files and other resources are added to the project, and with regular updates to Visual Studio the\r\nbuild numbers can change too. When changing a development environment completely (e.g. upgrading from VS2010 to\r\nVS2015) ProdIDs will also change for the equivalent in the new version.\r\nStatistics\r\nThe most important question when talking about how useful Rich Headers may be is ‘How often do they actually appear\r\nin executables?’ If Rich Headers appeared only in a small portion of files, they would not be a very useful feature.\r\nLuckily, this is not the case: when looking at our large malicious dataset consisting of roughly one million unique\r\nmalicious Win32 and Win64 native binaries (no .NET), we found that 73.20% of the PEs contain a Rich Header.\r\nOf the 26.80% of files that do not contain a Rich Header, many are produced by other compilers (Turbo C++, MinGW\r\nGCC, Clang, etc.), or are developed in a completely different environment such as Delphi or Go. When such files are\r\ndiscarded, the percentage of PEs containing Rich Headers rises to 83.30%. At this point, the absence of a Rich Header is\r\ncaused by explicit removal by malware authors or custom packers, etc. For our clean dataset of 120,000 samples, the\r\nrepresentation goes as high as 94.20% and 98.50% when taking out other compilers.\r\n Figure 6:\r\nRepresentation of Rich Headers in our malicious dataset.\r\nWe expect this number to decrease slowly over time, as malware authors become more aware of this feature and will try\r\nto obfuscate or remove the header completely. A more rapid shift would happen if Microsoft decided to drop this feature\r\ncompletely in some subsequent version of Visual Studio, but as of the recent release of Visual Studio 2019, Rich Headers\r\nare still generated by the linker.\r\nUse cases\r\nLevels of similarity\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 6 of 25\n\nIdentical Rich Headers\r\nThis is the strongest link between two files in terms of Rich Header similarity. Considering how often the Rich Headers\r\nmay change in an actively developed project, it is not the best method of long-term detection of future samples from a\r\ngiven project (a good analogy is hash-based detection of malicious files). That being said, it can still be very handy in\r\nvarious cases.\r\nThe most common case is the simple matching of the Rich Headers of an unknown file to those of some known malware\r\nto quickly identify if the file is malicious (rather like looking up a hash on VirusTotal). Rich Headers can remain\r\nunchanged for weeks or even months in the development cycle of a specific project, so a complete match with older or\r\neven newer versions of the project can still happen if the sample set is good enough.\r\nAnother useful case is possible thanks to the fact that commercial protectors like Enigma Protector, Themida and\r\nVMProtect preserve the Rich Headers of the original file. This means that when we get our hands on, say, a Themida-protected file, we could potentially look up the original, non-packed payload by searching for identical Rich Headers and\r\nvice versa. This is especially valuable considering that most of these protectors change the nature of the file completely\r\nand there are no links preserved between the code or data of the original payload. Malware authors sometimes use\r\nmultiple commercial packers to pack their payloads – we were able to identify the protected samples of a family called\r\nPredator Stealer [3] (Win32/Spy.Agent.{PQC,PQK}) and to attribute several custom Lazarus tools in [4]\r\n(Win64.NukeSped.{AA,AB}).\r\nA similar strategy can also be applied to less advanced malware packers that also tend either to preserve the original Rich\r\nHeader of the payload or to supplement the resulting packed file with their own.\r\nSometimes the Rich Header might intentionally be misplaced – there is a well-known case reported by Kaspersky [5] (and\r\nalso presented at Virus Bulletin [6]), where a component of Olympic Destroyer contained a copy of the complete Rich\r\nHeaders from a file previously attributed to the Lazarus toolset. This is widely considered to have been a false flag\r\nimplemented by the attackers to place the blame on a different actor. On the other hand, it might very well have been an\r\nEaster egg, testing the attention of malware researchers. In the past there have also been cases of malware packers that\r\ncopied the header from a legitimate explorer.exe.\r\nFor a quick matching, it is best to calculate and store a hash of the Rich Header. In our project we use an indexed CRC64\r\nfor a blazingly fast lookup.\r\nIdentical XOR keys\r\nMatching XOR keys have very similar use cases to matching Rich Headers. The advantage of using the XOR key instead\r\nof a custom hash is in it being more widely used and being supported by widespread community tools like YARA, and\r\nintegrated into VirusTotal hunting rules. The disadvantages lie in the fact that the value might artificially/explicitly be\r\nchanged and in the potential key collisions that we explained in the previous section.\r\nKnowing that the XOR keys are basically a checksum of the DOS header, DOS stub and Rich Header, we can quickly\r\nestablish that, as a malware project evolves, the key value may change fairly often (with even a single incremental change\r\nin the Rich Header count), so it is not a very useful feature when trying to track a project over a longer period of time.\r\nOn the other hand, as stated above, a malware packer is a specific project and, in many cases, shares an identical Rich\r\nHeader across many packed samples. We have found several values that covered reasonable clusters, e.g. 0x8F44CEBF,\r\n0xAEB29219, 0x8A17753B, 0xD4F1AE19, 0x887F83A7 (with the CRC64 hash varying within each key!).\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 7 of 25\n\nThere are several XOR keys associated with well-known formats, as listed in Table 3. They can be found in clean as well\r\nas malicious datasets and might be useful for a quick identification of the format.\r\nVisual Basic 6.0\r\n0x886973F3, 0x8869808D, 0x88AA42CF, 0x88AA2A9D, 0x89A99A19, 0x88CECC0B,\r\n0x8897EBCB, 0xAC72CCFA, 0x1AAAA993, 0xD05FECFB, 0x183A2CFD, 0xACCF9994,\r\n0xC757AD0B, 0xA7EEAD02, 0xD1197995, 0x83CDAD4, 0x8917A389, 0x88CEA841,\r\n0x8917DE83, 0x89AA0373, 0x8ACD8739, 0x8D156179, 0x8ACE4D53, 0x8897FE31,\r\n0x91A515F9, 0xD1983193, 0x8D16E113, 0x9AC47EF9, 0x91A80893, 0xAD0350F9,\r\n0xD180F4F9, 0xAD0EF593, 0x9ACA5793, 0x9ACA5793\r\nNSIS\r\n0xD28650E9, 0x38BF1A05, 0x6A2AD175, 0xD246D0E9, 0x371742A2, 0xAB930178,\r\n0x69EAD975, 0x69EB1175, 0xFB2414A1, 0xFB240DA1\r\nMASM 6.14\r\nbuild 8444\r\n0x88737619, 0x89A56EF9\r\nWinRar SFX\r\n0xC47CACAA, 0xFDAFBB1F, 0xD3254748, 0x557B8C97, 0x8DEFA739, 0x723F06DE,\r\n0x16614BC7\r\nAutoit\r\n0xBEAFE369, 0xC1FC1252, 0xCDA605B9, 0xA9CBC717, 0x8FEDAD28, 0x273B0B7D,\r\n0xECFA7F86\r\nMicrosoft\r\nCabinet File\r\n0x43FACBB6\r\nNTkernelPacker 0x377824C3\r\nThinstall 0x8B6DF331\r\nMoleBox Ultra\r\nv4\r\n0x8CABE24D\r\nTable 3: Various XOR keys associated with known formats.\r\nIdentical ProdIDs + builds (unsorted)\r\nDisregarding the counts and matching only the files with identical ProdIDs and build numbers also turned out to be a very\r\neffective way of looking up similar files. The bigger the project, the more effective this method is, and it should be\r\nconsidered for samples with at least five Rich Header records.\r\nIn the case of the KillDisk-ed casino in Central America [7] we found a 64-bit executable with the internal name res.dll.\r\nAnother file was later acquired, with all metadata pointing to the same threat actor. Despite being Themida-protected and\r\nstatically completely different (except for the agreement of PE timestamps), the set of ProdIDs together with builds were\r\nidentical and did not match any clean files – see Table 4 (both detected as Win64/NukeSped.Z). This inspired us to index\r\nthe sequence of pairs (ProdID, build) as they are located in the header, omitting the counts. The CRC64 checksum of\r\nunsorted sequences of these pairs reliably identified several clusters of related malicious projects: not only when the\r\nsingle count of prodidImports0 varied (Win64/CoinMiner.DN, 0x105E60A5B349F444), but also when multiple counts\r\ndid (Win32/Pterodo, 0x745E73E5045EE80E or Win32/Kryptik.GTXI, 0x613D0D87DAF1658F).\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 8 of 25\n\nrds.dll (2016-10-24 8:32:11) res.dll (2016-10-24 8:32:11)\r\nprodidUtc1600_LTCG_CPP| b40219 | 9\r\nprodidUtc1600_CPP     | b40219 | 27\r\nprodidUtc1600_C       | b40219 | 100\r\nprodidMasm1000        | b40219 | 15\r\nprodidLinker1000      | b40219 | 1\r\nprodidExport1000      | b40219 | 1\r\nprodidImplib900       | b30729 | 9\r\nprodidImport0         | b0     | 130\r\nprodidUtc1600_LTCG_CPP| b40219 | 9\r\nprodidUtc1600_CPP     | b40219 | 27\r\nprodidUtc1600_C       | b40219 | 94\r\nprodidMasm1000        | b40219 | 9\r\nprodidLinker1000      | b40219 | 1\r\nprodidExport1000      | b40219 | 1\r\nprodidImplib900       | b30729 | 9\r\nprodidImport0         | b0     | 131\r\n Table 4: Similar metadata from two Themida-protected 64-bit Lazarus backdoors.\r\nIdentical ProdIDs + builds (sorted)\r\nThe situation gets more complicated when searching for files from the same project that have different architectures. Rich\r\nHeaders tend to be almost identical between 32-bit and 64-bit equivalents of an application, but sometimes the ProdIDs\r\nare in a slightly different order. This led us to a new similarity level, namely the CRC64 checksum of the sequence of\r\nProdIDs and their builds sorted by the ProdID values to compare the Rich Header regardless of the order. Again, the\r\ncounts were omitted.\r\nThis turned out to be useful in many cases, for example when we encountered several almost identical samples of\r\nWin/GreyEnergy [8], each for a different architecture, having the same ProdIDs, but in a slightly different order.\r\nzlib_x86.dll, zlibwapi_x86.dll zlib_x64.dll, zlibwapi_x64.dll\r\nprodidAliasObj1000    | b20115 | 5\r\nprodidUtc1600_CPP     | b40219 | 25\r\nprodidMasm1000        | b40219 | 17\r\nprodidUtc1600_C       | b40219 | 110\r\nprodidImplib900       | b30729 | 3\r\nprodidImport0         | b0     |[87-88]\r\nprodidUtc1600_LTCG_CPP| b40219 | 22\r\nprodidExport1000      | b40219 |  1\r\nprodidLinker1000      | b40219 |  1\r\nprodidAliasObj1000     | b20115 | 5\r\nprodidUtc1600_CPP      | b40219 | 25\r\nprodidUtc1600_C        | b40219 | 107\r\nprodidMasm1000         | b40219 | 9\r\nProdidImplib900        | b30729 | 3\r\nprodidImport0          | b0     | [88-89]\r\nprodidUtc1600_LTCG_CPP | b40219 | [22-23]\r\nprodidExport1000       | b40219 | 1\r\nprodidLinker1000       | b40219 | 1\r\n  Table 5: Similar metadata from Win32/GreyEnergy payloads for both platforms.\r\nSpecific values query/conjunction of various ProdIDs\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 9 of 25\n\nWhile matching identical Rich Headers is nice and can be useful in many cases, for a more robust lookup we need some\r\nvariability. This can be achieved by searching for combinations of specific ProdIDs combined with builds and a range of\r\ncounts based on a value from the underlying sample. If such a query is constructed in a smart way, it can easily yield\r\nmany older and/or newer samples from the same project with slightly different Rich Headers as development progressed.\r\nFor example, given a file that contains prodidUtc1600_CPP build 40219 with a count of 48, we might search for all files\r\nwith prodidUtc1600_CPP build 40219 and a count between 42 and 54. So far we have not found a generic approach for\r\nhow best to construct these queries and instead use our ‘instincts’ that we have acquired over time while working with\r\nRich Headers.\r\nFor example, there were cases of a two-stage threat when the dropper and the payload were projects of very similar size,\r\ne.g. Win32/Exaramel [9]. Both files were 32-bit, so the order of ProdIDs was identical and counts very similar, with the\r\nexception of one additional ProdID in the payload, as seen in Table 6.\r\nxml.exe (2018-4-13 08:36:04) wsmprovav.exe (2018-4-13 08:35:52)\r\nprodidUtc1900_CPP | b24215 | 3\r\nprodidUtc1900_CPP | b24123 | 33\r\nprodidUtc1900_C   | b24215 | 7\r\nprodidUtc1900_C   | b24123 | 17\r\nprodidMasm1400    | b24123 | 18\r\nprodidLinker1400  | b24215 | 1\r\nprodidCvtres1400  | b24210 | 1\r\nprodidUtc1810_CPP | b40116 | 121\r\nprodidUtc1810_C   | b40116 | 24\r\nprodidMasm1210    | b40116 | 9\r\nprodidResource    | b0     | 1\r\nprodidImplib900   | b30729 | 9\r\nprodidImport0     | b0     | 109\r\nprodidUtc1900_CPP | b24215 |  1\r\nprodidUtc1900_CPP | b24123 | 29\r\nprodidUtc1900_C   | b24215 | 11\r\nprodidUtc1900_C   | b24123 | 17\r\nprodidMasm1400    | b24123 | 17\r\nprodidLinker1400  | b24215 |  1\r\nprodidCvtres1400  | b24210 |  1\r\nprodidUtc1810_CPP | b40116 | 120\r\nprodidUtc1810_C   | b40116 | 24\r\nprodidMasm1210    | b40116 |  9\r\nprodidResource    | b0     |  1\r\nprodidImplib900   | b30729 | 25\r\nprodidUtc1500_C   | b30729 | 4\r\nprodidImport0     | b0     |200\r\nTable 6: Similar metadata for the dropper and the payload of Win32/Exaramel.\r\nOne should always try to keep the number of items in the query to a bare minimum to distinguish different projects, but at\r\nthe same time leave some space for potential changes. Generally, ProdIDs containing ‘_CPP’ or ‘_C’ should be prioritized\r\nin the search as they tend to have the biggest count variability and the count distance could be around +/- 10%.\r\nAnomalies\r\nBasing detection on Rich Header similarity or adding it as a feature to existing detection systems is a great thing. Another\r\npotential use case is heuristic detection based on anomalies and inconsistencies that suggest the file has been tampered\r\nwith, or that there is something wrong with it, and that should generally be brought to the attention of a researcher. Such\r\nan anomaly obviously does not instantly mean a given file is malicious, but it might be useful to flag files worthy of\r\ncloser examination by an analyst. Anomalies are especially common in relation to various packers and other obfuscation\r\nstrategies commonly found in malware, as they are usually the result of tampering with the original file.\r\nIn the following subsections we look at the most common anomalies we have observed in the wild.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 10 of 25\n\nInvalid Rich Header values\r\nThis is the most obvious anomaly – since the range of valid ProdIDs is known, we can easily identify files that have non-existent values (at the moment, with the release of Visual Studio 2019, all values larger than 0x010e\r\n(prodidUtc1900_POGO_O_CPP) can be considered invalid). This could be applied to the build number as well, as each\r\nProdID has only a specific range of valid build numbers, although this would require quite a lot of work due to having to\r\ngather all possible build numbers for each ProdID. Finally, we could also check for suspicious count values, as for valid\r\nprojects they are generally in the tens or hundreds and very rarely in the thousands, so finding a valid ProdID with a count\r\ngreater than a million could be an indicator too.\r\nDuplicate Rich Header values\r\nEvery file with a Rich Header can only have a single, unique combination of ProdID and a build number. This is obvious,\r\nas the number of those records is represented by the count field instead, so duplicate records are invalid behaviour.\r\nAround 1.19% of files in our malicious dataset contain duplicate records. There is not a single one in the clean dataset.\r\nInvalid XOR key checksum\r\nSince we know how the checksum is calculated, the supplied XOR key can easily be verified. If the value is incorrect, we\r\ncan assume that there is potentially something wrong. In our malicious dataset 9.06% files have an invalid XOR key\r\nvalue, while in the clean dataset only around 0.95% do.\r\nRich Header offset\r\nThe Rich Header offset is the position in the PE at which the header begins. It is based on the size of the DOS stub, as it\r\nbegins right after that, so its value varies with the DOS stub. Since most files nowadays do not use the DOS part of the PE\r\nat all, they have the widely known default ‘This program cannot be run in DOS mode’ stub generated by the compiler, and\r\nthanks to that, in most files the Rich Header starts at file offset 0x80. While the mentioned starting position is present in\r\n~99% of cases, there are many, even valid, cases where the offset differs, so it is not a good idea to look for Rich Headers\r\nbased on this offset (like YARA does [10]). Out of 120,000 real-world clean applications with Rich Headers in our clean\r\ndataset, only 0.06% do not match the offset 0x80. The distribution for our malicious dataset can be seen in Figure 7.\r\n07_piechart2.PNG Figure 7: Distribution of Rich Header offsets in our malicious dataset.\r\nThere are a few relatively common offsets that can be found even in clean, legitimate projects like some kernel drivers\r\n(probably caused by an alignment issue, because even the default stub is aligned to 512 bytes). On the other hand, there\r\nare also several offsets that are used by a specific malware family or software project (those we have identified are listed\r\nin Table 7), which could be one of the ways to identify new samples or at least used as an indicator.\r\nOffset Example Comment\r\n0x40 Various The null DOS stub\r\n0x48 Various The minimal valid DOS stub\r\n0x60 Win32/Adware.WintionalityChecker  \r\n0x68 Win32/TrojanDownloader.Waski  \r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 11 of 25\n\n0x8C Win32/Adware.Virtumonde  \r\n0xE0 Win32/TrojanDropper.Agent.NJV  \r\n0x100 ESET modules Clean\r\n0x200 Various Some kernel drivers\r\n0x2A8 PKSFX Self Extract Utility by PKWARE Inc. Clean\r\n0x600 Win32/Adware.Trymedia  \r\nTable 7: Various types of Rich Header offsets.\r\nPE Optional Header linker information mismatch\r\nThe version of a linker used for building the file is also stored in the MajorLinkerVersion and MinorLinkerVersion fields\r\ninside the PE Optional Header. Comparing this version to the linker version found in Rich Headers (i.e. prodidLinker800\r\nshould have Optional Header linker version set to 8.0) is also a good way to find inconsistencies, packed files, tampered\r\nRich Headers and so on.\r\nThere are a few such anomalies caused by known packers – for example, the Armadillo packer changes the Optional\r\nHeader linker version to 83.82, but does not alter the Rich Header.\r\nImports\r\nThe prodidImport0 identifier is related to the number of functions in the PE import directory. The values are not always\r\nequal but correlate highly and tend to be very close together. A large difference between the number of imports and the\r\ncount of prodidImport0, or its complete absence in the Rich Header when imports are present, and vice versa, could be a\r\nsign of a packed file or a faked Rich Header.\r\nResources\r\nWhen an executable contains a resource directory populated with resources, it should always be reflected in the Rich\r\nHeader by containing prodidCvtresXXXX, where XXXX is the version of Visual Studio used. The count should always be\r\n1, regardless of the number of resources the file has. For example, when building a project that has any kind of resource\r\nincluded in Visual Studio 2015 (14.0), the resulting binary should always contain prodidCvtres1400 = 1 (in our malicious\r\ndataset, 4.12% of files have a prodidCvtresXXXX count other than 1; in our clean dataset this applies to only 0.01% of\r\nfiles).\r\nThere are multiple ideas for potential heuristics:\r\n1. Files with prodidCvtresXXXX having a count not equal to 1\r\n2. Files with resources not containing the Cvtres identifier and vice versa\r\n3. The version of prodidCvtresXXXX not corresponding with the linker version/other ProdIDs, i.e. the file having\r\nprodidCvtres1400 and prodidLinker1200.\r\nAPT malware\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 12 of 25\n\nIn this section we provide some examples where Rich Header metadata has provided interesting information and extended\r\nour overall knowledge about executables from APT toolsets. This is not the first attempt to look at Rich Headers and their\r\nusability in APT research [11].\r\nWin32/Industroyer \u0026 Win32/Exaramel\r\nThe article [9] uncovered strong code similarities between the Win32/Industroyer main backdoor (introduced to the world\r\nin [12]) and one of the backdoors (Win32/Exaramel) used by TeleBots, the group behind the massive NotPetya\r\n(Win32/Diskcoder.C) ransomware outbreak. Taking an additional look at the Rich Headers metadata, it turns out that there\r\nis additional similarity at the project development and build level – see Table 8.\r\nprodidMasm1210        b40116 =   9\r\nprodidUtc1810_CPP     b40116 = 120\r\nprodidUtc1810_C       b40116 =  24\r\nprodidMasm1400        b24123 =  17\r\nprodidUtc1900_CPP     b24123 =  29\r\nprodidUtc1900_C       b24123 =  17\r\nprodidImplib900       b30729 = [15-25]\r\nprodidImport0         b0     = [140-200]\r\nprodidCvtres1400      b24210 =   1\r\nprodidLinker1400      b24215 =   1\r\nTable 8: Rule based on the Rich Header values common to Industroyer and Exaramel.\r\nWin{32,64}/NukeSped\r\nThis is ESET’s detection name for samples from the Lazarus toolset. It is well known that the toolset is large,\r\nheterogeneous from various points of view, and all the sources are kept close. In [4] we tried to group executables based\r\non their Rich Header characteristics and the version of the Microsoft linker used. As a result, two main Lazarus tool\r\nsubgroups were identified, namely the first one using VS 98 for 32-bit compilations and VS 2010 for 64-bit, and the\r\nsecond one using VS 2010 for both. However, several anomalous combinations were discovered too, e.g. one typical\r\nmalicious project compiled as a 32-bit binary in VS 98 and as a 64-bit binary in VS 2013. In Table 9 there are two\r\nexamples of queries that successfully identified malicious clusters without causing an uncomfortable level of noise.\r\nprodidUtc1600_C    b40219 = [50-300]\r\nprodidImports    b0    = [227-228]\r\nprodidImplib900    b30729 = 23\r\nprodidAliasObj1000    b20115 = 7\r\nprodidUtc1500_C    b30729     = 8\r\nprodidExport1000    b40219     = 1\r\nprodidUtc1600_C    b40219     = [142-145]\r\nprodidUtc1600_CPP    b40219     = [61-62]\r\nTable 9: Win{32,64}/NukeSped detection rule.\r\nWin32/CrisisHT\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 13 of 25\n\nThis is ESET’s detection name for samples from the spyware kit operated and sold by the infamous Italian software\r\ncompany Hacking Team. In [13] many aspects of the threat are considered, e.g. the clustering of the toolset based on the\r\nattached code-signing certificates. In Table 10 we illustrate clustering based on the Rich Header values. The ‘SPC’ version\r\nlooks like a testing concept built by an unrelated team – a consequence of the source code leaks in July 2015.\r\nCertificate\r\nPE\r\nTimestamp\r\nprodidUtcXXXX_CPP and build values\r\nImport0 1600_CPP\r\nb40219\r\n1600_CPP\r\nb30319\r\n1700_CPP\r\nb50929\r\n1800_CPP\r\nb21005\r\n1900_CPP\r\nb24123\r\nRaffaele\r\nCarnacina\r\n16.9.2015   38       170\r\nRaffaele\r\nCarnacina\r\n19.10.2015   64       247\r\nRaffaele\r\nCarnacina\r\n19.10.2015   38       169\r\nRaffaele\r\nCarnacina\r\n5.11.2015 38         168\r\nRaffaele\r\nCarnacina\r\n17.11.2015 64         247\r\nSPC 5.1.2016       49   163\r\nRaffaele\r\nCarnacina\r\n18.1.2016 38         170\r\nRaffaele\r\nCarnacina\r\n24.3.2016   64       247\r\nRaffaele\r\nCarnacina\r\n24.3.2016   38       169\r\nADD Audit 17.6.2016     70     251\r\nADD Audit 1.9.2016     70     250\r\nADD Audit 19.12.2016     44     177\r\nADD Audit 28.4.2017 38         170\r\nADD Audit 28.4.2017 64         259\r\nZiber Ltd 28.6.2017         57 293\r\nMedia Lid 28.6.2017 40         184\r\nZiber Ltd 9.10.2017 40         190\r\nZiber Ltd 18.10.2017         57 299\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 14 of 25\n\nTable 10: CrisisHT samples clustered by C++ compiler version Rich Header data.\r\nCrimeware\r\nWin32/Kasidet\r\nKasidet (a.k.a. Neutrino bot) is a crime kit with many capabilities which is sold on underground forums and is popular for\r\nits relatively cheap price. The crime kit is distributed via a special builder containing the compiled stub of Neutrino bot. In\r\nTable 11 we showcase the evolution of four ProdIDs that represent the projects. Each colour band represents a unique stub\r\nthat was distributed by various cybercriminal groups [14].\r\n \r\nPE\r\nTimestamp\r\nprodidUtc1500_C prodidImplib900 prodidImport0 prodidUtc1600_CPP\r\nMiningRats\r\n04\r\n25.07.2017 1 25 175 44\r\nLethicGuys\r\n08\r\n21.10.2017 1 29 179 46\r\nRedirectors\r\n01\r\n25.10.2017 1 29 179 46\r\nLethicGuys\r\n09\r\n31.10.2017 1 29 179 47\r\nLethicGuys\r\n10\r\n07.11.2017 4 31 185 49\r\nRedirectors\r\n03\r\n07.11.2017 4 31 185 49\r\nLethicGuys\r\n11\r\n16.11.2017 4 31 185 49\r\nRedirectors\r\n04\r\n16.11.2017 4 31 185 49\r\nRedirectors\r\n05\r\n17.11.2017 4 31 185 49\r\nMiningRats\r\n07\r\n05.01.2018 4 31 185 49\r\nMiningRats\r\n08\r\n08.01.2018 4 31 185 49\r\nMiningRats\r\n09\r\n12.01.2018 3 31 196 50\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 15 of 25\n\nLethicGuys\r\n13\r\n13.01.2018 3 31 196 50\r\nLethicGuys\r\n14\r\n15.01.2018 3 31 196 50\r\nProxyGuys\r\n01\r\n16.01.2018 3 31 196 50\r\nMiningRats\r\n10\r\n20.01.2018 3 31 196 50\r\nLethicGuys\r\n15\r\n21.01.2018 3 31 196 50\r\nLethicGuys\r\n16\r\n21.01.2018 3 31 196 50\r\nMiningRats\r\n11\r\n30.01.2018 3 29 193 49\r\nProxyGuys\r\n02\r\n04.02.2018 3 29 193 49\r\nTinukeFareit\r\n01\r\n09.02.2018 3 29 193 49\r\nLethicGuys\r\n17\r\n16.02.2018 3 29 193 49\r\nLethicGuys\r\n18\r\n22.02.2018 3 29 193 49\r\nLethicGuys\r\n19\r\n25.02.2018 3 29 193 49\r\nLethicGuys\r\n20\r\n26.02.2018 3 29 193 49\r\nRedirectors\r\n06\r\n16.03.2018 3 29 193 49\r\nRedirectors\r\n07\r\n19.03.2018 3 29 193 49\r\nLethicGuys\r\n21\r\n22.03.2018 3 29 193 49\r\nLethicGuys\r\n22 \r\n22.03.2018  3 29 193 49\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 16 of 25\n\nLethicGuys\r\n23 \r\n02.04.2018  3 29 194 49\r\nProxyGuys\r\n03 \r\n02.04.2018  3 29 194 49\r\nLethicGuys\r\n24 \r\n05.04.2018  3 29 194 49\r\nTinukeFareit\r\n02 \r\n08.04.2018  3 29 194 49\r\nTinukeFareit\r\n03\r\n23.04.2018  3 29 194 49\r\nTinukeFareit\r\n04\r\n02.05.2018  3 29 194 49\r\nArsonists\r\n01 \r\n07.05.2018  3 29 194 49\r\nTinukeFareit\r\n05 \r\n19.05.2018  3 27 192 49\r\nArsonists\r\n021 \r\n21.05.2018  3 27 192 49\r\nTinukeFareit\r\n061 \r\n21.05.2018  3 27 192 49\r\nLethicGuys\r\n25 \r\n23.05.2018  3 27 192 49\r\nProxyGuys\r\n04 \r\n06.06.2018  3 29 223 54\r\nArsonists\r\n022 \r\n10.06.2018  3 29 223 49\r\nLethicGuys\r\n26 \r\n14.06.2018  3 29 224 54\r\nTinukeFareit\r\n062 \r\n19.06.2018  3 29 224 55\r\nTinukeFareit\r\n07 \r\n05.07.2018  3 29 224 55\r\nMiningRats\r\n12 \r\n26.08.2018  3 29 241 56\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 17 of 25\n\nLethicGuys\r\n27 \r\n03.09.2018  3 29 241 56\r\nArsonists\r\n03 \r\n18.09.2018  3 29 241 56\r\nLethicGuys\r\n28 \r\n18.09.2018  3 29 241 56\r\nProxyGuys\r\n05 \r\n18.09.2018  3 29 241 56\r\nTinukeFareit\r\n08 \r\n20.09.2018  3 29 241 56\r\nMiningRats\r\n13 \r\n11.10.2018  3 29 241 56\r\nTable 11: The evolution of the Win32/Kasidet project.\r\nTable 12 lists the Rich Header search rules we use to cover the prevalent Neutrino bot version 5.4.\r\nprodidUtc1500_C b30729 = [1-4]\r\nprodidUtc1500_CPP b30729 = 1\r\nprodidImplib900 b30729 = [25-31]\r\nprodidimport0 b0 = [175-241]\r\nprodidUtc1600_C b40219 = 5\r\nprodidUtc1600_CPP b40219 = [44-56]\r\nTable 12: Win32/Kasidet version 5.4 detection rule.\r\nWin{32,64}/Dridex\r\nIt seems that, at any given time, this infamous banking trojan is actively being developed by a single entity, as all the\r\nsamples from a given time period/campaign have the same Rich Headers. The development environment has changed at\r\nleast four times. This could mean that the authors updated their tools or that the source code has changed hands and has\r\neither been sold or passed to someone else. The detection rules for various versions can be found in Table 13.\r\nWin{32,64}/Dridex v1, v2 \u0026 v3 (2014 – 2015)\r\nThe initial versions of the Dridex banking trojan were developed in Visual Studio 2010. The rule should cover all samples\r\nfrom version 1.100 all the way until 3.102, which is over a year-long period between July 2014 and September 2015. We\r\nhave collected 75 unique builds based on this search and, based on the gaps in the versions of samples we were missing, it\r\ncould potentially cover over 270 unique versions.\r\nWin{32,64}/Dridex v3 (2016)\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 18 of 25\n\nAfter version 3.102 the development environment changed slightly for the rest of the v3 development cycle and both 32-\r\nbit and 64-bit versions between v3.145 (November 2015) and v3.258 (September 2016) can be covered by the rule.\r\nWin{32,64}/Dridex v4 (2017 – 2018)\r\nDridex version 4 introduced a few major changes including the infamous Atom bombing technique that made the\r\nheadlines back in 2017 as well as a major development environment towards Visual Studio 2015. The rule covers the\r\nversions between v4.43 and v4.87 and reliably covers both 32-bit and 64-bit samples.\r\nWin{32,64}/Dridex v5(v2) (2018 – 2019)\r\nAnother shift in the development environment of this malware. This time there has been an interesting shift in the\r\nversioning as well – instead of an expected version 5 it has been set back to version 2. This could indicate a change in the\r\nownership of the source code or a change of the developer responsible for the malware. The rule should cover the most\r\nrecent versions (v2.68 and newer).\r\nVersions 1, 2 and 3 (2014 - 2015)\r\nprodidUtc1500_CPP b30729 = 1\r\nprodidMasm1000    b40219 = [23-26]\r\nprodidUtc1600_C   b40219 = [99-143]\r\nprodidUtc1600_CPP b40219 = [32-48]\r\nprodidUnknown     b0     = 1\r\nVersion 3 (2016)\r\nprodidImplib900   b30729 = [3-5]\r\nprodidImport0     b0     = [1-2]\r\nprodidUtc1500_C   b30729 = 1\r\nprodidExport1000  b40219 = 1\r\nprodidUnknown     b0     = 1\r\nVersion 4 (2017 – 2018)\r\nprodidUtc1900_C   b24215 = [22-23]\r\nprodidUtc1900_CPP b24215 = [58-60]\r\nprodidLinker1400  b24215 = 1\r\nVersion 5 (v2) (2018 – 2019)\r\nprodidUtc1500_C   b30729 = 4\r\nprodidImplib900   b30729 = 5\r\nprodidImport0     b0     = 6\r\nprodidLinker1400  b24215 = 1\r\nprodidUnknown     b0     = 90\r\nTable 13: Win{32,64}/Dridex detection rules.\r\nWin{32,64}/Sathurbot\r\nThis name represents botnets spreading via password attacks on WordPress sites [15]. The malware is a large project\r\nwhich is compiled for both 32- and 64-bit Windows platforms. Table 14 shows the evolution of the build environment\r\n(internal DLL name, PE Timestamp and ProdIDs representing the source files).\r\n    prodidUtcXXXX_CPP\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 19 of 25\n\nPE TS\r\n1600_CPP\r\nb40219\r\n1600_CPP\r\nb30319\r\n1600_LTCG_CPP\r\nb30319\r\n1700_CPP\r\nb50929\r\n1800_CPP\r\nb20806\r\nPerformanceMonitor.dll 22.4.2015       59  \r\nPerformanceMonitor.dll\r\n27.4.2015\r\n      60  \r\nPerformanceMonitor.dll       59  \r\nPerformanceMonitor.dll\r\n14.5.2015\r\n      60  \r\nPerformanceMonitor.dll       59  \r\nPerformanceMonitor.dll\r\n21.6.2015\r\n  92      \r\nPerformanceMonitor.dll   91      \r\nPerformanceMonitor.dll 8.7.2015   92      \r\nPerformanceMonitor.dll 30.7.2015   91      \r\nPerformanceMonitor.dll 4.8.2015   91      \r\nPerformanceMonitor.dll\r\n18.8.2015\r\n  89      \r\nPerformanceMonitor.dll   88      \r\nPerformanceMonitor.dll 27.8.2015   88      \r\nPerformanceMonitor.dll 15.9.2015   89      \r\nPerformanceMonitor.dll 8.2.2016 89        \r\nPerformanceMonitor.dll 18.2.2016 89        \r\nperformanceMonitor_64.dll 31.3.2016         84\r\nperformanceMonitor_32.dll\r\n29.06.2016\r\n        83\r\nperformanceMonitor_64.dll         84\r\nperformanceMonitor_32.dll 31.8.2016         83\r\nperformanceMonitor_32.dll 24.10.2016         83\r\nperformanceMonitor_64.dll 29.12.2016   69 97    \r\nperformanceMonitor_32.dll 13.1.2017   68 97    \r\nperformanceMonitor_32.dll\r\n16.2.2017\r\n  68 97    \r\nperformanceMonitor_64.dll   69 97    \r\nperformanceMonitor_64.dll 10.3.2017   69 97    \r\nperformanceMonitor_64.dll 21.3.2017   69 97    \r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 20 of 25\n\nperformanceMonitor_64.dll 27.5.2017         79\r\nperformanceMonitor_64.dll 7.11.2017         79\r\nTable 14: The evolution of Win{32,64}/Sathurbot.\r\nIt is not possible to conclude with high confidence that there is more than a single entity operating the source code.\r\nHowever, the produced executables suggest that Visual Studio is switched regularly. The merged PE timestamp of two\r\nsamples into one cell with a single date means a consecutive compilation for both 32- and 64-bit platforms that differed\r\nby just a few seconds. The order of this compilation varied as well.\r\nMalware packers\r\nThe main purpose of malware packers is to provide a container for malware families with features like polymorphism,\r\nanti-analysis and obfuscation. Because of these features, malware packers often display abnormal static properties and\r\ntheir Rich Headers are no exception.\r\nThe first interesting case was a validly signed, highly polymorphic obfuscator detected as Win32/Kryptik.GSLI. In May\r\n2019, hundreds of unique samples were distributed in the wild, with Win32/TrojanDownloader.Zurgop.CY as the\r\nprotected payload. We discovered these campaigns because the prodidCvtres500 identifier contained anomalously high\r\ncounts. After collecting many related files, we found that the rules in Table 15 identified the cluster very well.\r\nprodidMasm613 b7299 = [12-13]\r\nprodidUtc12_C b9782 = 63\r\nprodidLinker512 b8034 = 11\r\nprodidUtc12_CPP b9782 = 2\r\nTable 15: Detection query for Win32/Kryptik.GSLI.\r\nLater, we identified another extremely polymorphic malware packer. The shared static properties include two .version PE\r\nsections of 1,024 bytes each, a file version of 1.0.0.1 and legal copyright starting with Copyright (C) 2018. The rest of the\r\nfeatures seem randomly generated. We described the cluster with the relatively simple rule conjunction seen in Table 16.\r\nprodidUtc1500_CPP b21022 = 37\r\nprodidMasm900 b21022 = 17\r\nprodidUtc1500_C b21022 = [112-120]\r\nprodidUtc1500_LTCG_CPP b21022 = 1\r\nprodidCvtres900 b21022 = 1\r\nTable 16: Detection query for the malware packer shared across many malware families.\r\nThere were many malware families protected with this packer, including the following (for further examples see [01]):\r\nWin32/PSW.Delf.OSF (aka Azorult)\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 21 of 25\n\nWin/Spy.Kronosbot\r\nWin32/TrojanDownloader.Zurgop.DA\r\nWin32/Filecoder.Spora\r\nWin32/Agent.TFY (a backdoor written in GoLang)\r\nMSIL/Spy.Baldr\r\nWin32/Ramnit.BV (a virus)\r\nWin32/Spy.Ursnif.CY\r\nRich Headers \u0026 YARA\r\nYARA is a great tool for malware researchers, incident responders and security engineers that has become an industry\r\nstandard for hunting malware and the classification of unknown samples. Hence, being able to write YARA rules based on\r\nRich Headers would be a great way to share our findings with the rest of the world.\r\nAlthough YARA does support parsing of Rich Headers and the PE module has a few Rich Header-related fields, at the\r\ntime of writing (June 2019) there are a few critical drawbacks that greatly limit its usability [16].\r\nFirst, as seen in its source code in Figure 8, YARA incorrectly assumes that the Rich Header always starts at the common\r\noffset 0x80 [10] and will not work for any Rich Header at a different offset. This can easily be fixed and is not that big an\r\nissue, since as stated above, over 99% of files with Rich Headers tend to have them at that offset.\r\n Figure 8:\r\nYARA’s implementation of Rich Headers lookup.\r\nThe bigger problem is the YARA Rich Header-related API, which is very simple and insufficient for any effective Rich\r\nHeader-related rules. The version and toolid functions can only look whether a specific ProdID and build is present in the\r\nRich Header, but are unable to query its count values, which are the most crucial attribute in most useful searches. The\r\nannouncement of YARA’s toolid function can be seen in Figure 9.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 22 of 25\n\nFigure 9: YARA PE module Rich Headers API documentation.\r\nThe APIs would be much more useful if instead of the existence of a given ProdID, the toolid and version interfaces\r\nreturned the count (or null), which then could be compared against a ranged interval. This would greatly enhance YARA’s\r\nRich Header-related capabilities and would enable more complete leverage of the Rich Header format. We hope to\r\ncontribute to the YARA project and to help to improve the Rich Header-related functionality in the near future.\r\nConclusion\r\nWe started our project with low expectations, thinking that there must be a reason the Rich Headers feature is overlooked\r\nand not widely utilized. Over time, we became more and more impressed with how much could be achieved by searching\r\nfor feature clusters based on such a small part of an executable, and how powerful it can be when leveraged correctly.\r\nThe space of Rich Header features has an extremely fast lookup and is ‘rich’ indeed, in the sense that the detection queries\r\nfor chosen parts of APT toolsets or crimeware kits identified the clusters well and with a low level of noise. Because of\r\nthe nature of the information, false positives may occur, however the erroneous verdicts seem to be intuitive: clean\r\nprojects of small magnitude, shared executable containers and, surprisingly, different malicious families as well. We\r\nbelieve this kind of static feature may also be utilized in machine-learning algorithms, to assist in deciding maliciousness,\r\nand this is the subject of future work.\r\nSharing publicly the various techniques malware researchers use to track cybercriminal actors usually causes an obvious\r\nreaction: avoidance. In the case of the Rich Header that may be a Pyrrhic victory – any interference with this delicate\r\nstructure, such as wiping it or substituting it, will produce obvious, easily detectable anomalies just asking for closer\r\nattention from our malware analysts.\r\nRich Headers are definitely not a silver bullet that will change the security industry, but they could be a nice and very\r\nhelpful addition to current detection and hunting methods and systems. We feel that this undocumented structure deserves\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 23 of 25\n\nmore attention than it currently receives across the field and imagine that, in the not too distant future, we may see Rich\r\nHeader YARA rules appearing in malware analysis IoC listings and the like.\r\nReferences\r\n[1] https://github.com/AyalaRs/win/blob/master/private/sdktools/vctools/langapi/include/prodids.h.\r\n[2] ESET GitHub. SHA256 hashes of mentioned files. https://github.com/eset/malware-ioc/tree/master/rich_headers.\r\n[3] GReAT. A predatory tale: Who’s afraid of the thief? Securelist.com. March 2019. https://securelist.com/a-predatory-tale/89779/.\r\n[4] Kálnai, P.; Poslušný, M. Lazarus Group: a mahjong game played with different sets of tiles, Virus Bulletin\r\nInternational Conference 2018, Montreal. https://www.virusbulletin.com/uploads/pdf/magazine/2018/VB2018-Kalnai-Poslusny.pdf.\r\n[5] Kaspersky GReAT. The devil’s in the Rich header. March 2018. https://securelist.com/the-devils-in-the-rich-header/84348/.\r\n[6] Rascagnères, P.; Mercer, W. Who wasn’t responsible for Olympic Destroyer. Virus Bulletin International Conference\r\n2018, Montreal. https://www.virusbulletin.com/uploads/pdf/magazine/2018/VB2018-Rascagneres-Mercer.pdf.\r\n[7] Kálnai, P.; Cherepanov, A. Lazarus KillDisks Central American casino. April 2018.\r\nhttps://www.welivesecurity.com/2018/04/03/lazarus-killdisk-central-american-casino/.\r\n[8] Cherepanov, A. GREYENERGY: A successor to BlackEnergy. October 2018. https://www.welivesecurity.com/wp-content/uploads/2018/10/ESET_GreyEnergy.pdf.\r\n[9] Cherepanov, A.; Lipovský, R. New Telebots backdoor linking Industroyer and notPetya. WeLiveSecurity.com.\r\nOctober 2018. https://www.welivesecurity.com/2018/10/11/new-telebots-backdoor-linking-industroyer-notpetya/.\r\n[10] https://github.com/VirusTotal/yara/blob/master/libyara/modules/pe.c#L190.\r\n[11] Webster, G.D.; Kolosnjaji, B.; von Pentz, Ch.; Kirsch, J.; Hanif, Z.D.; Zarras, A.; Eckert, C. Finding the Needle: A\r\nStudy of the PE32 Rich Header and Respective Malware Triage. In: Proceedings of the International Conference on\r\nDetection of Intrusions and Malware, and Vulnerability Assessment. Springer, pp. 119--138, 2017.\r\nhttps://www.sec.in.tum.de/i20/publications/finding-the-needle-a-study-of-the-pe32-rich-header-and-respective-malware-triage.\r\n[12] Cherepanov, A. Win32/Industroyer a new threat to industrial control systems. WeLiveSecurity.com. June 2017.\r\nhttps://www.welivesecurity.com/wp-content/uploads/2017/06/Win32_Industroyer.pdf.\r\n[13] Kafka, F. From Hacking Team to Hacked Team to…? Virus Bulletin International Conference 2018, Montreal.\r\nhttps://www.virusbulletin.com/uploads/pdf/magazine/2018/VB2018-Kafka.pdf.\r\n[14] Soucek, J.; Tomanek, J.; Kálnai, P. Collecting Malicious Particles from Neutrino botnets. The Journal on Cybercrime\r\n\u0026 Digital Investigations, Botconf 2018 Conference proceedings,\r\nhttps://journal.cecyf.fr/ojs/index.php/cybin/article/view/22/24.\r\n[15] ESET Research: Sathurbot: Distributed WordPress password attack. WeLiveSecurity.com. April 2017.\r\nhttps://www.welivesecurity.com/2017/04/06/sathurbot-distributed-wordpress-password-attack/.\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 24 of 25\n\n[16] YARA PE module documentation. https://yara.readthedocs.io/en/v3.7.0/modules/pe.html.\r\nSource: https://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nhttps://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/\r\nPage 25 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2020/01/vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format/"
	],
	"report_names": [
		"vb2019-paper-rich-headers-leveraging-mysterious-artifact-pe-format"
	],
	"threat_actors": [
		{
			"id": "34eea331-d052-4096-ae03-a22f1d090bd4",
			"created_at": "2025-08-07T02:03:25.073494Z",
			"updated_at": "2026-04-10T02:00:03.709243Z",
			"deleted_at": null,
			"main_name": "NICKEL ACADEMY",
			"aliases": [
				"ATK3 ",
				"Black Artemis ",
				"COVELLITE ",
				"CTG-2460 ",
				"Citrine Sleet ",
				"Diamond Sleet ",
				"Guardians of Peace",
				"HIDDEN COBRA ",
				"High Anonymous",
				"Labyrinth Chollima ",
				"Lazarus Group ",
				"NNPT Group",
				"New Romanic Cyber Army Team",
				"Temp.Hermit ",
				"UNC577 ",
				"Who Am I?",
				"Whois Team",
				"ZINC "
			],
			"source_name": "Secureworks:NICKEL ACADEMY",
			"tools": [
				"Destover",
				"KorHigh",
				"Volgmer"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a3687241-9876-477b-aa13-a7c368ffda58",
			"created_at": "2022-10-25T16:07:24.496902Z",
			"updated_at": "2026-04-10T02:00:05.010744Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "ETDA:Hacking Team",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e90c06e4-e3e0-4f46-a3b5-17b84b31da62",
			"created_at": "2023-01-06T13:46:39.018236Z",
			"updated_at": "2026-04-10T02:00:03.183123Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "MISPGALAXY:Hacking Team",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "4d9cdc7f-72d6-4e17-89d8-f6323bfcaebb",
			"created_at": "2023-01-06T13:46:38.82716Z",
			"updated_at": "2026-04-10T02:00:03.113893Z",
			"deleted_at": null,
			"main_name": "GreyEnergy",
			"aliases": [],
			"source_name": "MISPGALAXY:GreyEnergy",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "39842197-944a-49fd-9bec-eafa1807e0ea",
			"created_at": "2022-10-25T16:07:24.310589Z",
			"updated_at": "2026-04-10T02:00:04.931264Z",
			"deleted_at": null,
			"main_name": "TeleBots",
			"aliases": [],
			"source_name": "ETDA:TeleBots",
			"tools": [
				"BadRabbit",
				"Black Energy",
				"BlackEnergy",
				"CredRaptor",
				"Diskcoder.C",
				"EternalPetya",
				"ExPetr",
				"Exaramel",
				"FakeTC",
				"Felixroot",
				"GreyEnergy",
				"GreyEnergy mini",
				"KillDisk",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"NonPetya",
				"NotPetya",
				"Nyetya",
				"Petna",
				"Petrwrap",
				"Pnyetya",
				"TeleBot",
				"TeleDoor",
				"Win32/KillDisk.NBB",
				"Win32/KillDisk.NBC",
				"Win32/KillDisk.NBD",
				"Win32/KillDisk.NBH",
				"Win32/KillDisk.NBI",
				"nPetya"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df",
			"created_at": "2023-01-06T13:46:38.402513Z",
			"updated_at": "2026-04-10T02:00:02.959797Z",
			"deleted_at": null,
			"main_name": "Sandworm",
			"aliases": [
				"IRIDIUM",
				"Blue Echidna",
				"VOODOO BEAR",
				"FROZENBARENTS",
				"UAC-0113",
				"Seashell Blizzard",
				"UAC-0082",
				"APT44",
				"Quedagh",
				"TEMP.Noble",
				"IRON VIKING",
				"G0034",
				"ELECTRUM",
				"TeleBots"
			],
			"source_name": "MISPGALAXY:Sandworm",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "732597b1-40a8-474c-88cc-eb8a421c29f1",
			"created_at": "2025-08-07T02:03:25.087732Z",
			"updated_at": "2026-04-10T02:00:03.776007Z",
			"deleted_at": null,
			"main_name": "NICKEL GLADSTONE",
			"aliases": [
				"APT38 ",
				"ATK 117 ",
				"Alluring Pisces ",
				"Black Alicanto ",
				"Bluenoroff ",
				"CTG-6459 ",
				"Citrine Sleet ",
				"HIDDEN COBRA ",
				"Lazarus Group",
				"Sapphire Sleet ",
				"Selective Pisces ",
				"Stardust Chollima ",
				"T-APT-15 ",
				"TA444 ",
				"TAG-71 "
			],
			"source_name": "Secureworks:NICKEL GLADSTONE",
			"tools": [
				"AlphaNC",
				"Bankshot",
				"CCGC_Proxy",
				"Ratankba",
				"RustBucket",
				"SUGARLOADER",
				"SwiftLoader",
				"Wcry"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa",
			"created_at": "2022-10-25T16:47:55.919702Z",
			"updated_at": "2026-04-10T02:00:03.618194Z",
			"deleted_at": null,
			"main_name": "IRON VIKING",
			"aliases": [
				"APT44 ",
				"ATK14 ",
				"BlackEnergy Group",
				"Blue Echidna ",
				"CTG-7263 ",
				"ELECTRUM ",
				"FROZENBARENTS ",
				"Hades/OlympicDestroyer ",
				"IRIDIUM ",
				"Qudedagh ",
				"Sandworm Team ",
				"Seashell Blizzard ",
				"TEMP.Noble ",
				"Telebots ",
				"Voodoo Bear "
			],
			"source_name": "Secureworks:IRON VIKING",
			"tools": [
				"BadRabbit",
				"BlackEnergy",
				"GCat",
				"NotPetya",
				"PSCrypt",
				"TeleBot",
				"TeleDoor",
				"xData"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a2b92056-9378-4749-926b-7e10c4500dac",
			"created_at": "2023-01-06T13:46:38.430595Z",
			"updated_at": "2026-04-10T02:00:02.971571Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Operation DarkSeoul",
				"Bureau 121",
				"Group 77",
				"APT38",
				"NICKEL GLADSTONE",
				"G0082",
				"COPERNICIUM",
				"Moonstone Sleet",
				"Operation GhostSecret",
				"APT 38",
				"Appleworm",
				"Unit 121",
				"ATK3",
				"G0032",
				"ATK117",
				"NewRomanic Cyber Army Team",
				"Nickel Academy",
				"Sapphire Sleet",
				"Lazarus group",
				"Hastati Group",
				"Subgroup: Bluenoroff",
				"Operation Troy",
				"Black Artemis",
				"Dark Seoul",
				"Andariel",
				"Labyrinth Chollima",
				"Operation AppleJeus",
				"COVELLITE",
				"Citrine Sleet",
				"DEV-0139",
				"DEV-1222",
				"Hidden Cobra",
				"Bluenoroff",
				"Stardust Chollima",
				"Whois Hacking Team",
				"Diamond Sleet",
				"TA404",
				"BeagleBoyz",
				"APT-C-26"
			],
			"source_name": "MISPGALAXY:Lazarus Group",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "32a223a8-3c79-4146-87c5-8557d38662ae",
			"created_at": "2022-10-25T15:50:23.703698Z",
			"updated_at": "2026-04-10T02:00:05.261989Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Lazarus Group",
				"Labyrinth Chollima",
				"HIDDEN COBRA",
				"Guardians of Peace",
				"NICKEL ACADEMY",
				"Diamond Sleet"
			],
			"source_name": "MITRE:Lazarus Group",
			"tools": [
				"RawDisk",
				"Proxysvc",
				"BADCALL",
				"FALLCHILL",
				"WannaCry",
				"MagicRAT",
				"HOPLIGHT",
				"TYPEFRAME",
				"Dtrack",
				"HotCroissant",
				"HARDRAIN",
				"Dacls",
				"KEYMARBLE",
				"TAINTEDSCRIBE",
				"AuditCred",
				"netsh",
				"ECCENTRICBANDWAGON",
				"AppleJeus",
				"BLINDINGCAN",
				"ThreatNeedle",
				"Volgmer",
				"Cryptoistic",
				"RATANKBA",
				"Bankshot"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6",
			"created_at": "2022-10-25T15:50:23.339976Z",
			"updated_at": "2026-04-10T02:00:05.27483Z",
			"deleted_at": null,
			"main_name": "Sandworm Team",
			"aliases": [
				"Sandworm Team",
				"ELECTRUM",
				"Telebots",
				"IRON VIKING",
				"BlackEnergy (Group)",
				"Quedagh",
				"Voodoo Bear",
				"IRIDIUM",
				"Seashell Blizzard",
				"FROZENBARENTS",
				"APT44"
			],
			"source_name": "MITRE:Sandworm Team",
			"tools": [
				"Bad Rabbit",
				"Mimikatz",
				"Exaramel for Linux",
				"Exaramel for Windows",
				"GreyEnergy",
				"PsExec",
				"Prestige",
				"P.A.S. Webshell",
				"AcidPour",
				"VPNFilter",
				"Neo-reGeorg",
				"Cyclops Blink",
				"SDelete",
				"Kapeka",
				"AcidRain",
				"Industroyer",
				"Industroyer2",
				"BlackEnergy",
				"Cobalt Strike",
				"NotPetya",
				"KillDisk",
				"PoshC2",
				"Impacket",
				"Invoke-PSImage",
				"Olympic Destroyer"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f32df445-9fb4-4234-99e0-3561f6498e4e",
			"created_at": "2022-10-25T16:07:23.756373Z",
			"updated_at": "2026-04-10T02:00:04.739611Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"APT-C-26",
				"ATK 3",
				"Appleworm",
				"Citrine Sleet",
				"DEV-0139",
				"Diamond Sleet",
				"G0032",
				"Gleaming Pisces",
				"Gods Apostles",
				"Gods Disciples",
				"Group 77",
				"Guardians of Peace",
				"Hastati Group",
				"Hidden Cobra",
				"ITG03",
				"Jade Sleet",
				"Labyrinth Chollima",
				"Lazarus Group",
				"NewRomanic Cyber Army Team",
				"Operation 99",
				"Operation AppleJeus",
				"Operation AppleJeus sequel",
				"Operation Blockbuster: Breach of Sony Pictures Entertainment",
				"Operation CryptoCore",
				"Operation Dream Job",
				"Operation Dream Magic",
				"Operation Flame",
				"Operation GhostSecret",
				"Operation In(ter)caption",
				"Operation LolZarus",
				"Operation Marstech Mayhem",
				"Operation No Pineapple!",
				"Operation North Star",
				"Operation Phantom Circuit",
				"Operation Sharpshooter",
				"Operation SyncHole",
				"Operation Ten Days of Rain / DarkSeoul",
				"Operation Troy",
				"SectorA01",
				"Slow Pisces",
				"TA404",
				"TraderTraitor",
				"UNC2970",
				"UNC4034",
				"UNC4736",
				"UNC4899",
				"UNC577",
				"Whois Hacking Team"
			],
			"source_name": "ETDA:Lazarus Group",
			"tools": [
				"3CX Backdoor",
				"3Rat Client",
				"3proxy",
				"AIRDRY",
				"ARTFULPIE",
				"ATMDtrack",
				"AlphaNC",
				"Alreay",
				"Andaratm",
				"AngryRebel",
				"AppleJeus",
				"Aryan",
				"AuditCred",
				"BADCALL",
				"BISTROMATH",
				"BLINDINGCAN",
				"BTC Changer",
				"BUFFETLINE",
				"BanSwift",
				"Bankshot",
				"Bitrep",
				"Bitsran",
				"BlindToad",
				"Bookcode",
				"BootWreck",
				"BottomLoader",
				"Brambul",
				"BravoNC",
				"Breut",
				"COLDCAT",
				"COPPERHEDGE",
				"CROWDEDFLOUNDER",
				"Castov",
				"CheeseTray",
				"CleanToad",
				"ClientTraficForwarder",
				"CollectionRAT",
				"Concealment Troy",
				"Contopee",
				"CookieTime",
				"Cyruslish",
				"DAVESHELL",
				"DBLL Dropper",
				"DLRAT",
				"DRATzarus",
				"DRATzarus RAT",
				"Dacls",
				"Dacls RAT",
				"DarkComet",
				"DarkKomet",
				"DeltaCharlie",
				"DeltaNC",
				"Dembr",
				"Destover",
				"DoublePulsar",
				"Dozer",
				"Dtrack",
				"Duuzer",
				"DyePack",
				"ECCENTRICBANDWAGON",
				"ELECTRICFISH",
				"Escad",
				"EternalBlue",
				"FALLCHILL",
				"FYNLOS",
				"FallChill RAT",
				"Farfli",
				"Fimlis",
				"FoggyBrass",
				"FudModule",
				"Fynloski",
				"Gh0st RAT",
				"Ghost RAT",
				"Gopuram",
				"HARDRAIN",
				"HIDDEN COBRA RAT/Worm",
				"HLOADER",
				"HOOKSHOT",
				"HOPLIGHT",
				"HOTCROISSANT",
				"HOTWAX",
				"HTTP Troy",
				"Hawup",
				"Hawup RAT",
				"Hermes",
				"HotCroissant",
				"HotelAlfa",
				"Hotwax",
				"HtDnDownLoader",
				"Http Dr0pper",
				"ICONICSTEALER",
				"Joanap",
				"Jokra",
				"KANDYKORN",
				"KEYMARBLE",
				"Kaos",
				"KillDisk",
				"KillMBR",
				"Koredos",
				"Krademok",
				"LIGHTSHIFT",
				"LIGHTSHOW",
				"LOLBAS",
				"LOLBins",
				"Lazarus",
				"LightlessCan",
				"Living off the Land",
				"MATA",
				"MBRkiller",
				"MagicRAT",
				"Manuscrypt",
				"Mimail",
				"Mimikatz",
				"Moudour",
				"Mydoom",
				"Mydoor",
				"Mytob",
				"NACHOCHEESE",
				"NachoCheese",
				"NestEgg",
				"NickelLoader",
				"NineRAT",
				"Novarg",
				"NukeSped",
				"OpBlockBuster",
				"PCRat",
				"PEBBLEDASH",
				"PLANKWALK",
				"POOLRAT",
				"PSLogger",
				"PhanDoor",
				"Plink",
				"PondRAT",
				"PowerBrace",
				"PowerRatankba",
				"PowerShell RAT",
				"PowerSpritz",
				"PowerTask",
				"Preft",
				"ProcDump",
				"Proxysvc",
				"PuTTY Link",
				"QUICKRIDE",
				"QUICKRIDE.POWER",
				"Quickcafe",
				"QuiteRAT",
				"R-C1",
				"ROptimizer",
				"Ratabanka",
				"RatabankaPOS",
				"Ratankba",
				"RatankbaPOS",
				"RawDisk",
				"RedShawl",
				"Rifdoor",
				"Rising Sun",
				"Romeo-CoreOne",
				"RomeoAlfa",
				"RomeoBravo",
				"RomeoCharlie",
				"RomeoCore",
				"RomeoDelta",
				"RomeoEcho",
				"RomeoFoxtrot",
				"RomeoGolf",
				"RomeoHotel",
				"RomeoMike",
				"RomeoNovember",
				"RomeoWhiskey",
				"Romeos",
				"RustBucket",
				"SHADYCAT",
				"SHARPKNOT",
				"SIGFLIP",
				"SIMPLESEA",
				"SLICKSHOES",
				"SORRYBRUTE",
				"SUDDENICON",
				"SUGARLOADER",
				"SheepRAT",
				"SierraAlfa",
				"SierraBravo",
				"SierraCharlie",
				"SierraJuliett-MikeOne",
				"SierraJuliett-MikeTwo",
				"SimpleTea",
				"SimplexTea",
				"SmallTiger",
				"Stunnel",
				"TAINTEDSCRIBE",
				"TAXHAUL",
				"TFlower",
				"TOUCHKEY",
				"TOUCHMOVE",
				"TOUCHSHIFT",
				"TOUCHSHOT",
				"TWOPENCE",
				"TYPEFRAME",
				"Tdrop",
				"Tdrop2",
				"ThreatNeedle",
				"Tiger RAT",
				"TigerRAT",
				"Trojan Manuscript",
				"Troy",
				"TroyRAT",
				"VEILEDSIGNAL",
				"VHD",
				"VHD Ransomware",
				"VIVACIOUSGIFT",
				"VSingle",
				"ValeforBeta",
				"Volgmer",
				"Vyveva",
				"W1_RAT",
				"Wana Decrypt0r",
				"WanaCry",
				"WanaCrypt",
				"WanaCrypt0r",
				"WannaCry",
				"WannaCrypt",
				"WannaCryptor",
				"WbBot",
				"Wcry",
				"Win32/KillDisk.NBB",
				"Win32/KillDisk.NBC",
				"Win32/KillDisk.NBD",
				"Win32/KillDisk.NBH",
				"Win32/KillDisk.NBI",
				"WinorDLL64",
				"Winsec",
				"WolfRAT",
				"Wormhole",
				"YamaBot",
				"Yort",
				"ZetaNile",
				"concealment_troy",
				"http_troy",
				"httpdr0pper",
				"httpdropper",
				"klovbot",
				"sRDI"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434455,
	"ts_updated_at": 1775792300,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f2144ce8647afe942d16e8886735e5ef139ce02d.pdf",
		"text": "https://archive.orkl.eu/f2144ce8647afe942d16e8886735e5ef139ce02d.txt",
		"img": "https://archive.orkl.eu/f2144ce8647afe942d16e8886735e5ef139ce02d.jpg"
	}
}