{
	"id": "413e9fe7-93ee-4764-8b10-12d40330e796",
	"created_at": "2026-04-06T00:08:14.729004Z",
	"updated_at": "2026-04-10T13:12:59.482667Z",
	"deleted_at": null,
	"sha1_hash": "dc3aadade89c7a68825de31d88bb28bf02e4c22f",
	"title": "Host-based Threat Modeling \u0026 Indicator Design",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1795813,
	"plain_text": "Host-based Threat Modeling \u0026 Indicator Design\r\nBy Jared Atkinson\r\nPublished: 2017-07-18 · Archived: 2026-04-05 21:31:45 UTC\r\nIntroduction and Background\r\nLast week, my colleague Brian Reitz (@brian_psu) wrote a brilliant post about leveraging PSReflect to model\r\nmalware techniques. This post builds upon his thought process and explicitly lays out SpecterOps’ methodology\r\nsurrounding threat modeling and design of defensive indicators.\r\nUltimately, this process is designed to facilitate researching a technique from the underlying technology all the\r\nway to specific implementations. We start by identifying the offensive technique we want to focus on. Once we\r\nhave a technique, we identify the actual technology that the technique targets. This step forces us to look at the\r\ntechnique from the macro level, while still maintaining a technical perspective. For the next portion of the process\r\nwe will build on the knowledge we gained to identify relevant data sets, understand how to collect it, and write a\r\nproof-of-concept (POC) for implementing the specific attack technique. With these tools we can then begin to\r\nunderstand the technology’s normal behavior and identify how the attack technique deviates from normal as well\r\nas validate any assumptions made along the way. Lastly, we will check how the scale of an enterprise environment\r\nchallenges our assumption and adapt our detection based on this reality.\r\nIn this post I will leverage the MITRE ATT\u0026CK Framework to identify post-exploitation techniques that we may\r\nwant to focus on.\r\nMethodology\r\nDescribing the methodology seems to make the most sense if I work through it using an actual example technique.\r\nFor the remainder of the post, I will explain my thought process on detecting malicious use of NTFS Extended\r\nAttributes (ATT\u0026CK: T1096 — Defense Evasion/NTFS Extended Attributes), a technique used by the Zeroaccess\r\nTrojan since at least 2012.\r\nResearch Underlying Technology\r\nDeveloping a lasting behavioral detection requires a solid understanding not only of the possible attacker\r\nimplementations of the technique, but of the underlying technology as well. In this case, how can we truly detect\r\nthe malicious use of NTFS Extended Attributes (EA) if we don’t actually understand them?! A good place to start\r\ndelving into this technology is the ATT\u0026CK Framework’s wiki entry for our chosen technique. If we refer to the\r\ntechnique’s wiki we can see the description of the attack and how adversaries leverage this technique to evade in-place defenses:\r\n“Data or executables may be stored in New Technology File System (NTFS) partition metadata instead of directly\r\nin files. This may be done to evade some defenses, such as static indicator scanning tools and anti-virus.\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 1 of 10\n\nThe NTFS format has a feature called Extended Attributes (EA), which allows data to be stored as an attribute of\r\na file or folder.”\r\nAfter reading this, I walk away with some level of understanding, but I also have some questions. Let’s take a look\r\nat what we know after reading these sentences:\r\nAttackers are hiding data in NTFS metadata structures (namely Extended Attributes).\r\nData is being hidden so the attacker can bypass AV and other automated scanning solutions.\r\nLet’s take a peek at the questions I’ve come up with:\r\nWhat are Extended Attributes?\r\nWhere are Extended Attributes stored?\r\nWhy are attackers using Extended Attributes?\r\nIs there any particular advantage to this technique?\r\nHow are the attackers interacting with the Extended Attributes (storing and retrieving data)?\r\nOk! Lets see what we can do to answer these questions!\r\nFirst things first, we know that EAs are part of NTFS, so we should start by checking out some NTFS\r\ndocumentation. Technically speaking, NTFS is a proprietary file system, so we cannot simply find information\r\nabout Extended Attributes on MSDN. Luckily, Richard Russon provides excellent documentation derived from the\r\nLinux NTFS driver project. While working on PowerForensics development, this is my first stop when I have an\r\nNTFS related question. The page is a gold mine of information about NTFS, including the most niche details\r\nabout the Master File Table (MFT) and its attributes.\r\nUpon arriving on the page, I searched for “Extended Attribute” and was directed to the $EA page. The\r\n“Overview” section describes the $EA attribute as:\r\n“Used to implement the HPFS extended attribute under NTFS. This file attribute may be non-resident because its\r\nstream is likely to grow.\r\nAs defined in $AttrDef, this attribute has a no minimum size but a maximum of 65536 bytes.”\r\nThe documentation also provides a the $EA attribute data structure as shown below:\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 2 of 10\n\n$EA attribute structure retrieved from https://flatcap.org/linux-ntfs/ntfs/attributes/ea.html\r\nTurns out Extended Attributes are Master File Table attributes, meaning it serves to provide some sort of metadata\r\nabout a file. For some context, a few of the more well known attributes are\r\nthe $STANDARD_INFORMATION attribute (stores the timestamps we see in File Explorer),\r\nthe $FILE_NAME attribute (keeps track of the file’s name), and the $DATA attribute (which contains or points to\r\nthe file’s contents). It also looks like the $EA is used for compatibility with the High Performance File System\r\n(HPFS), which is a legacy file system that is unlikely to be used in conjunction with modern operating systems. I\r\nalso see that a $EA is basically a name/value pair where the Value field can store arbitrary data (possibly code)\r\nwith a maximum size of ~65536 bytes.\r\nWith a generic concept of EA, we can look at the overarching concept of the Master File Table. The MFT is a\r\nmetadata structure present on every NTFS formatted partition. The MFT maintains a record for every “file” (data\r\nfiles and directories) on the partition and each record contains file data and metadata. For a bit more understanding\r\nof how the MFT works, I’ve included a poster I made to break down the structure of a Master File Table record\r\nbelow:\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 3 of 10\n\nNotice that an MFT Record is composed of a header that describes the record’s place in the MFT itself and an\r\narray of “Attributes.” As mentioned earlier, there are numerous attribute types and some are more common than\r\nothers. For instance, every MFT Record has a $STANDARD_INFORMATION attribute and at least one\r\n$FILE_NAME attribute, while a data file will also have at least one $DATA attribute (any additional $DATA\r\nattributes are what we all know as “Alternate Data Streams”). Other attributes are used in certain situations,\r\nincluding $EA attributes (Extended Attributes), which seem to be used rather infrequently.\r\nWith this understanding of Extended Attributes and how they fit into the MFT picture, we can begin looking at\r\nhow attackers leverage this technique to achieve their objectives.\r\nUnderstand and Model Technique\r\nIn the last section, we learned about NTFS, specifically the Master File Table and its $EA attribute. During our\r\nresearch, one thing stood out to me. You may have noticed that I mentioned Alternate Data Streams (ADS). ADS\r\nis a popular place for attackers to hide files, but the proliferation of this technique has led to the popularization of\r\nADS detections. When we looked at the structure of the $EA attribute, it appears to be a good place to store\r\narbitrary data that matches up with the description on the technique’s wiki page. It appears we are dealing with a\r\ncreative alternative to hiding data in ADS and banking on the idea that less tools/people are looking for Extended\r\nAttributes being used to store attacker-supplied data.\r\nOur background of the Master File Table, and more specifically Extended Attributes, allows us to address\r\ndetecting this technique behaviorally. This portion of the process focuses on modeling the technique. This includes\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 4 of 10\n\nidentifying data relating to this technique, collecting said data, and writing a simple POC to confirm your\r\nunderstanding and to test your data collection.\r\nIdentify Related Data Set\r\nFirst things first, we need to identify what data we need to collect. Some situations call for multiple data sets that\r\nmust be compared to identify the malicious behavior, but in this case it appears that we only need to look for\r\nExtended Attributes throughout the file system.\r\nImplement Collection\r\nBefore we begin analyzing behavior for detections, we need to understand how to collect relevant data (in this\r\ncase NTFS Extended Attributes).\r\nAs the developer of PowerForensics, my initial thought was to add support for $EA attributes (something I need to\r\ndo anyway) and then use my MFT parser to identify all $EA attributes on the file system. After considering this\r\nmethod for a bit, I decided I wanted to also provide a more lightweight option that leverages the Windows API to\r\ncheck a file for an Extended Attribute.\r\nInitially, I had no idea how to enumerate Extended Attributes through the Windows API, but the ATT\u0026CK wiki\r\npointed me to a blog post by Symantec researcher Mircea Ciubotariu. Mircea finds that Zeroaccess Trojan used\r\nthe ZwSetEaFile and ZwQueryEaFile functions to interact with the Extended Attributes. Awesome! We now know\r\nthe API calls we need to implement to create and enumerate Extended Attributes.\r\nNOTE: Since this is a post about methodology, I am not going to get into details about the code itself as I believe\r\nthat will distract from the point of this post. I plan on writing a follow up post that will cover the specific\r\nimplementation of the “Zw*EaFile” family of functions. For now, there will be a bit of hand waving just to get the\r\npoint across.\r\nSince this section is focusing on collection, let’s start with ZwQueryEaFile. I wrote an abstraction function for\r\nZwQueryEaFile in PowerShell using PSReflect. Below you will find the MSDN C++ function definition for\r\nZwQueryEaFile:\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 5 of 10\n\nA couple of high level observations: the function appears to require multiple calls to enumerate ALL Extended\r\nAttributes (a file can have multiple $EA attributes). Also, ZwQueryEaFile requires a handle to the file you are\r\nquerying, so we need to find a way to get that file handle. After a bit of Googling, I found that NtOpenFile did the\r\ntrick; you can see the C++ function definition for NtOpenFile below:\r\nNow that we presumably have all the code we need to enumerate a single file for Extended Attributes, we can\r\nwrap that functionality and recursively check every file on the file system. Our collection mechanism is now\r\ncomplete.\r\nImplement Technique POC or Malware Sample\r\nAfter implementing ZwQueryEaFile, ZwSetEaFile should be pretty straightforward. Again we write an abstracted\r\nfunction using PSReflect, so we can add custom Extended Attributes to any file of our choosing. This function is\r\nalso simpler because you are choosing the file to write to instead of looking for every instance of a file that has\r\nExtended Attributes. Below is the C++ function definition for ZwSetEaFile:\r\nIn some cases, writing a POC could be a too big of an investment. In these situations, I like to find a malware\r\nsample that implements this technique and use that sample for testing purposes. Each technique’s wiki entry\r\nincludes references to blog posts or white papers from which the technique’s knowledge was derived. These posts\r\nare often a great starting point for understanding the technique itself, as well as the way malware used it in the\r\nwild.\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 6 of 10\n\nEach technique wiki page includes examples of malware that leverage it. An example from the NTFS Extended\r\nAttribute entry is below:\r\nWhat if we just get a copy of Regin or Zeroaccess Trojan and test it in a lab environment? If we refer back to the\r\narticles analyzing Zeroaccess and its use of Extended Attributes, we can look for a way to identify the specific\r\nversion of Zeroaccess that implements this technique. When we review Corey Harrell’s post, we find the hash for\r\nthis version of the malware (ee14dcd20b2ee118618e3a28db72cce92ccd9e85dd8410e02479d9d624934b13). We\r\ncan now use whatever means are available to us to download a copy of this file to use for testing (I found the\r\nsample on VirusShare).\r\nAlways consider reimplementing the basic functionality involved in the attack technique, as a first priority. This\r\nallows threats to be modeled on a generic level without focusing on a specific tool’s implementation. For example,\r\nin his post Corey Harrell provides the following description of Zeroaccess Trojan’s implementation of this\r\ntechnique:\r\n“A large amount of binary data is also written to the NTFS Extended Attributes of services.exe. … ZeroAccess\r\nuses this feature to hide a whole PE file as well as shellcode that loads the PE file. The overwritten subroutine in\r\nservices.exe reads in all the data from the Extended Attributes and executes it.”\r\nIf we only analyze ZeroAccess Trojan, we may mistakenly conclude that we only need to check services.exe for\r\nExtended Attributes which would obviously not solve the problem in the way we’d like.\r\nDetection\r\nWith the ability to collect Extended Attributes and implement a POC “malicious EA,” we can work on identifying\r\nways to detect malicious use specifically.\r\nThe first step in building a detection is identifying normal. How normal are Extended Attributes on your average\r\nenterprise computer? Is there a different “normal” depending on the Operating System version? Do these normal\r\ninstances follow an identifiable pattern? If we can answer these questions, then we can begin to wrap our heads\r\naround identifying the malicious use or more generically, deviations from normal.\r\nOne thing that is important to remember in this case is that attackers aren’t using Extended Attributes for their\r\noriginal purpose. Attackers are using them as data storage (often PE files) which is not consistent with the\r\n“key/value pair” concept we saw in documentation. This information can help us look for patterns when\r\nconsidering normal use versus malicious use.\r\nI put together a couple PowerShell functions to recursively enumerate all files for Extended Attributes (details will\r\nbe discussed in a future post). You can find my code at the end of the post.\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 7 of 10\n\nFirst, I ran the function on a stock Windows 7 VM which came back with exactly 0 EAs. This lines up with our\r\noriginal assumption that Extended Attributes are a legacy compatibility feature that is no longer used in modern\r\noperating systems. As I mentioned earlier, just because a stock Windows 7 image has no EAs does not mean that\r\nthis is the default behavior on all OS’s. For this reason I decided to test a Windows 10 VM as well.\r\nBefore running my Windows 10 test, I wrote an Extended Attribute named TEST to a file located at\r\nC:\\demo\\ea.exe. I want to make sure the function detects my custom EA, as well as, any built in EAs.\r\nNext, I ran the function on my Windows 10 VM and found 35751 EAs! Either EAs made a come back, or I’m\r\npwned! To get an idea of what is going on, I used PowerShell’s Group-Object cmdlet to group all EAs based on\r\nname to see if there is an identifiable pattern.\r\n35749 out of 35751 EAs are named either $CI.CATALOGHINT or $KERNEL.PURGE.ESBCACHE. The\r\nremaining two EAs are my “TEST” EA and one named $KERNEL.PURGE.CATALOGHINT which appears\r\nrelated to the other built in EAs.\r\nNow we want to see if we can understand the purpose of these EAs. I’ll start with the most prevalent\r\nEA $CI.CATALOGHINT. Let’s take a look at one:\r\nUpon further review, it appears that all $CI.CATALOGHINT EAs have a value that is related to a .cat file or a\r\n“digitally-signed catalog file”. These are files that are used to verify the digital signature of other files as a\r\ncollection and alternative to Authenticode signing each individual file.\r\nWe can assume that the catalog referenced in the EA is the catalog file that would be used to validate our file’s\r\nsignature (C:\\Windows\\bfsvc.exe), but it is best not to assume. We use PowerShell’s Get-AuthenticodeSignature\r\ncmdlet to check the digital signature of C:\\Windows\\bfsvc.exe and it tells us that the file is indeed “Catalog”\r\nsigned.\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 8 of 10\n\nNext we check the catalog file’s digital signature and it turns out that the catalog file is Authenticode signed (the\r\nfile itself contains an embedded signature).\r\nOne thing to notice is that both files have an identical Thumbprint. This proves that the catalog file referenced in\r\nthe $CI.CATALOGHINT EA is the catalog used to validate the base file’s digital signature. Another way to\r\nresolve what catalog to use for validating a file is to use sigcheck sysinternals with the -i parameter.\r\nWhen I thought about why this EA is unique to Windows 10, it struck me that $CI likely stands for Code Integrity\r\nwhich is related to Device Guard. This is a security feature included in Windows 10, but unfortunately there is\r\nliterally no documentation how Device Guard interacts with Extended Attributes. We can now make an educated\r\nguess as to the purpose of the $CI.CATALOGHINT.\r\nI will leave the other two EAs as an exercise for the reader, but I’d recommend investigating the relationship\r\nbetween $KERNEL.PURGE.ESBCACHE and the Enterprise Service Bus. I also stumbled upon this page which\r\ndescribes the $KERNEL.PURGE prefix with the statement below:\r\nI’m interested to hear what EAs you come across and how you think they are being used!\r\nHopefully, this example demonstrated the process I like to follow to understand “normal” behavior on a system.\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 9 of 10\n\nTest Detection at Scale\r\nIt’s one thing to get a working detection on one machine in your test lab, but things can surprise you when you\r\nattempt to apply that detection at scale. Once we have identified a detection with fairly low false positive rates in\r\nthe lab, we need to see how that detection works at scale.\r\nIn my testing, Extended Attributes seem to remain consistent in large environments. In order to not skip this\r\nsection, I want to describe how to approach this portion of the methodology from the perspective of the Golden\r\nTicket technique. When I think of detections that work in labs, but needed a little more thought after testing at\r\nscale, I think of some of the problems I faced with detections I use for Golden Tickets.\r\nThe original assumption was Kerberos tickets (both Ticket Granting Tickets and Service Tickets), in modern\r\nenvironments, should not use RC4 encryption. In our lab environment, this was true and a 100% detection. While\r\nan adversary could upgrade to AES encryption, any ticket with RC4 was in fact malicious. We decided to test this\r\nat scale and collect tickets across a fairly large environment, and were surprised when we saw TONS of RC4 and\r\ntherefore, appeared to be TONS of Golden Tickets in the environment (fortunately this was not the case!). After\r\nsome research and consulting with Sean Metcalf (@PyroTek3) over at Trimarc Security, it turns out that cross-domain and cross-forest tickets use RC4 by default. I assume this is to maintain backward compatibility in cases\r\nwhere the domain being requested is not functional level 2008. Testing this detection at scale can prevent a large\r\namount of effort on trying to address false positives in the future.\r\nThis step of the process should also be catered to your environment. For example, many organizations have very\r\nfew WMI Permanent Event Subscriptions, but maybe someone in your organization has found a useful way to\r\nleverage this technology. In most companies, you are unlikely to learn about that just by asking around. Many\r\norganizations are too complex for any individual to know everything. The only true way to know how each\r\ntechnology/technique is used in your environment is to look yourself. Every network has its own unique quirks\r\nthat are sure to surprise you.\r\nConclusion\r\nSo why go through this lengthy process to build detections? A mature threat hunting program continuously maps\r\ndocumented attack techniques (those found in the MITRE ATT\u0026CK Framework) to durable, behavior based\r\ndetections. Target techniques should be identified based on your resources and you should cover as much of the\r\nattack chain as possible. An attacker must evade all detections throughout the chain to be successful. There is an\r\nimplicit need to fully understand a technology in order to identify detections that are neither too tactical in nature\r\n(something an adversary can easily change) nor too broad (with a high false positive rate). Hopefully this\r\nmethodology can help your organization work toward a more mature threat hunting program.\r\nSource: https://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nhttps://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://posts.specterops.io/host-based-threat-modeling-indicator-design-a9dbbb53d5ea"
	],
	"report_names": [
		"host-based-threat-modeling-indicator-design-a9dbbb53d5ea"
	],
	"threat_actors": [],
	"ts_created_at": 1775434094,
	"ts_updated_at": 1775826779,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dc3aadade89c7a68825de31d88bb28bf02e4c22f.pdf",
		"text": "https://archive.orkl.eu/dc3aadade89c7a68825de31d88bb28bf02e4c22f.txt",
		"img": "https://archive.orkl.eu/dc3aadade89c7a68825de31d88bb28bf02e4c22f.jpg"
	}
}