Sep 8 2022 | Jared Atkinson

On Detection: Tactical to Function

Part 6: What is a Procedure?

Physical reality has structures at all levels of metric size from atoms to galaxies. Within the intermediate band of terrestrial sizes, the environment of animals and men is itself structured at various levels of size. At the level of kilometers, the earth is shaped by mountains and hills. At the level of meters, it is formed by boulders and cliffs and canyons, and also by trees. It is still more finely structured at the level of millimeters by pebbles and crystals and particles of soil, and also by leaves and grass blades and plant cells. All these things are structural units of the terrestrial environment, what we loosely call the forms or shapes of our familiar world.

Now, with respect to these units, an essential point of theory must be emphasized. The smaller units are embedded in the larger units by what I call nesting. For example, canyons are nested within mountains; trees are nested within canyons; leaves are nested within trees; and cells are nested within leaves. These are forms within forms both up and down the scale of size. Units are nested within larger units. Things are components of other things. They would constitute a hierarchy except that this hierarchy is not categorical but full of transitions and overlaps. Hence, for the terrestrial environment, there is no special proper unit in terms of which it can be analyzed all at once and for all. There are no atomic units of the world considered as an environment. Instead, there are subordinate and superordinate units. The unit you choose for describing the environment depends on the level of the environment you choose to describe.

– James A. Gibson¹

Introduction

Welcome back to the On Detection: Tactical to Functional blog series. I want to take a slightly different approach to things in this post. Most of the previous articles in the series have been purely technical in focus. I hope that this post maintains this technical feel, but I feel it is time to do semantical house cleaning. The goal is to leverage the technical foundation we’ve established throughout the series to help answer this question. Over the past few months, I’ve observed an increased focus on “procedures,” as in the “P” of the acronym TTP, as being the optimal level of analysis in Detection Engineering. As a result, I’ve felt the need to consider whether I agree with the proposition that we should focus our detection efforts on procedures. However, I ran into an issue each time I tried to provide my perspective. I didn’t know what a procedure was! When I look at the MITRE ATT&CK matrix, it is easy to understand that tactics are the column headers, things like Persistence, Credential Access, Lateral Movement, and techniques are each individual cell, things like Kerberoasting, OS Credential Dumping, etc., but then we kind of hand wave away procedures as being “everything below the technique.” I’ve seen procedures defined as tools, specific command lines, steps in an attack, and different things. It appears that there are actually two questions hidden in this proposition. First the ontological question, “what do you think a procedure is?” Second, the practical question, “do you think that procedures are the optimal target of detection engineering efforts?” Initially, I intended for this post to answer both questions, but the initial draft was 5000 words, and frankly, I’m not sure anyone would stick with me for that long in one sitting. Instead, I decided to answer each question individually in subsequent articles. In this article, I plan to use the technical work we’ve put in during the previous 6 posts to explain precisely how I define the term “procedure.” Then we will build on that topic in the next post to understand whether “procedures” are, in fact, the optimal target for detection engineers.

Why is the term “procedure” so ill-defined?

In 1931, the Polish-American scientist Alfred Korzybski published a paper that included the statement, “the map is not the territory.”² This phrase is a metaphor that examines the relationship between the model we use to see the world (the map) and the world itself (the territory). This is a fascinating relationship because the world is far too complex for us to perceive completely, so our map must necessarily be lower resolution than the world. However, we would hope that our map roughly approximates reality such that it has utility for problem-solving. If it tells us that Fresno is between Los Angeles and Sacramento, we should expect that Fresno is actually between the other two cities. If it is not, then our decision-making is compromised. This means that our map should be low resolution enough to comprehend it while simultaneously high resolution enough (detailed) to enable us to make accurate predictions when faced with uncertainty. I believe that one of the significant issues in the sub-discipline of Detection and Response is that our map is too low resolution to use to make sound and accurate predictions. Our perception of the world is shaped by the frame of reference through which we interact with it.

Imagine that we have been trained our entire career to view the cyber world through a three-layered lens (Tactics, Techniques, and Procedures). As a result, we apprehend the cyber world as something composed of three layers and tend to be limited to thinking and talking (but I repeat myself) about it within this three-layer construct. Through this blog series, I have attempted to shed this preconceived structure to explore the ontological structure of this world, or at least estimate it as well as I can. The result has been interesting for me, and I hope for you as well because we have discovered the existence of at least six layers (functions, operations, procedures, sub-techniques, techniques, and tactics). Consider what must occur when one attempts to view six layers through a three-layered map? The resolution with which one views the world must necessarily be reduced. The nuance and complexity of those six layers are lost or compressed into the three-layer frame of reference.

In some cases, this loss of detail might be spread throughout all three layers of the model (TTP), but in this case, it seems that the first two layers, tactics and techniques, are well aligned to the first two layers in the six-layer model. This means that all of the loss is realized at the procedure level specifically. This is because the three-layer model’s version of procedures is responsible for representing the six-layer model’s concept of sequences of operations, operations, and functions. While we all have our own unique maps or perspective with which we view the problem, I hope that this journey to increase the resolution and detail of my map has the side effect of informing your map, so we are better off as an industry. It is time to unshackle “procedure” from the burden of representing multiple layers and allow it to take its rightful place within the emergent hierarchical structure we’ve uncovered.

What is a Procedure?

What does the Military Say?

To answer the question “what is a procedure?” I think it is essential to understand where the term originated. Where did the information security field pick up the Tactics, Techniques, and Procedures (TTP) concept? As is common in our specialty, it stems from the Military, so it may be worth consulting them (at least the US DoD) to better understand the intended purpose. My colleague, Robby Winchester (@robwinchester3 on Twitter), explored the idea of procedures in his What is a TTPblog post,³ referring to Department of Defense Joint Publication 1–02, Department of Defense Dictionary of Military and Associated Terms, for the official definitions of each term. JP 1–02 defines Procedures as the “specific detailed instructions and/or directions for accomplishing a task.”⁴ This definition is helpful but doesn’t clarify precisely where procedures fit into the overall structure of things we’ve begun to uncover.

Robby goes further in his post to provide a metaphor about car ownership that we can use to better understand the idea. He labels high-level considerations like “providing fuel,” “cleaning the interior,” and “preventative maintenance” as examples at the Tactic level. He then changes focus to the preventative maintenance Tactic and explores the Techniques that achieve this Tactical objective. Examples provided include “changing the oil,” “rotating tire,” and “replacing the breaks.” The last level of analysis is Procedures, where one would expect “detailed instructions and/or directions” to implement a Technique like changing the oil.⁵ To correctly interpret this definition, we must first understand what is meant by “detailed instructions and/or directions.”

My Thought Process

One option for interpretation is that it could mean something as specific as “run this tool with this command line,” However, I believe there is a technical issue that prevents this interpretation. So far, all the different concepts we’ve discussed are categories. You can think of them as classes in object-oriented programming, or you can think of them as Platonic forms (I prefer this interpretation). These forms are not concrete or tangible. Instead, they are patterns that must be instantiated in order to exist in the world. Tools are the instantiation of the class or the form. For an attacker to execute a technique, they MUST instantiate the form through a tool. Tools are simply idiosyncratic instantiations of the technique, not the technique itself.

To me, procedures belong to the forms, not the instances. The procedures are the pattern of steps to execute, not the execution of the steps. Therefore, it seems that the “detailed instructions” aspect of the procedure definition might look something like the list below:

Enumerate processes to obtain the process identifier for lsass.exe.
Open a handle to lsass.exe with the PROCESS_VM_READ access right.
Read the memory of lsass.exe to obtain the credentials stored within.

The vital point here is not the steps; it is what the steps represent. Notice that each step corresponds with an operation that we’ve discussed previously. Step 1 corresponds with the Process Enumerate operation, step 2 corresponds with the Process Access operation, and step 3 corresponds with the Process Read operation. The steps define a sequence of operations that implements a sub-technique, specifically, the sequence of operations that is instantiated by Mimikatz’s sekurlsa::logonPasswords command.⁶

As I mentioned in the introduction, I’ve, until now, found it difficult to pin down exactly what a procedure is or at least should be. I feel that the structure that we’ve uncovered throughout this series finally provides the foundation to allow me to state precisely what I believe a procedure is. My answer is that a procedure is not a tool or a command line argument.

A procedure is “a sequence of operations that, when combined, implement a technique or sub-technique.”

Comparing the Definition to the Operation Graph

We can now apply this definition to our analysis of the operation graph for LSASS Memory dumping that we discussed in the previous post,⁷ and that is shown below as Figure 1:

**Figure 1**. LSASS Memory Operation Graph

This graph shows four unique sequences of operations that can be used to accomplish the sub-technique. Based on our new definition for procedures, these four sequences of operations ARE procedures.

The Ontological Hierarchy

This series has explored the ontological hierarchy of things in the cyber world. We talked about the function call stack,⁸ identified the functions called by Mimikatz,⁹ abstracted functions into operations,¹⁰ combined them to make function call graphs,¹¹ observed how operations can be connected as procedures, and how numerous procedures exist that can fulfill the requirements of a given sub-technique.¹² While each of these concepts can hopefully stand alone, I have found it helpful to generate a graphic that visualizes the hierarchical relationship between these concepts and demonstrates that they fit together to form a coherent structure. The image is shared as Figure 2.

**Figure 2.** Conceptual Taxonomic Structure from the Tactical to the Functional

Note: For brevity’s sake, and because I have yet to do the work, this hierarchical image only expands one node at each level. Imagine that each node at each level has a relatively similar number of options that it abstracts. Hopefully, this allows you to imagine the sheer extent of the possibilities available to attackers.

The image shows the different levels of abstraction that are simultaneously occurring. So when someone chooses to run Mimikatz sekurlsa::logonPasswords to dump credentials, it is simultaneously true that they are executing kernel32!ReadProcessMemory¹³ (function), Process Read (operation), Direct Memory Access (procedure), LSASS Memory¹⁴ (sub-technique), OS Credential Dumping¹⁵ (technique), and Credential Access¹⁶ (tactic).

The nested structure of things

The quote that opened this post was written by James J. Gibson in his book The Ecological Approach to Visual Perception. What I love about it, especially in this context, is that it helps us to see that this nested structure is not unique to this particular use case. The nested structure is present in everything we interact with daily. Just as Gibson observed, the cell is nested within the leaf, the leaf within the branch, the branch within the tree, the tree within the canyon, and the canyon within the mountain.¹⁷ We can observe that the function implements the operation, operations can be combined to implement the procedure, the procedure implements the sub-technique, the sub-technique implements the technique, the technique implements the tactic, and tactics are integrated to implement the attack chain.

Put another, more explicit way, functions represent the base level of the structure, at least thus far. Functions are interesting because they are about as tangible as things get within the context of software. They represent the doors through which an application can interact with the operating system and the associated hardware. We then discovered that “functions” implement “operations.” Operations are the first level of abstraction in our structure. They are beneficial because numerous functions can be used to achieve the same operational result. For instance, both kernel32!ReadProcessMemory and ntdll!NtReadVirtualMemory implements the Process Read operation. Operations are interesting because, in some sense, they form the basic building blocks of applications. Programs basically combine individual operations to accomplish tasks. Based on the conclusion of this article, when operations are combined to achieve a technical objective, they become procedures. For instance, we saw that Mimikatz combines the Process Enumerate, Process Access, and Process Read operations to dump credentials from LSASS. This leads us to understand that procedures implement a “technique” or a “sub-technique.” The aforementioned procedure implements the LSASS Memory sub-technique, but it is essential to remember that there is often more than one procedure for any given technique or sub-technique. Sub-techniques, when applicable, are specific manifestations of techniques, like OS Credential Dumping. Techniques ultimately are implementations of tactics. For instance, OS Credential Dumping is one technique that implements the Credential Access tactic. Lastly, attackers can combine and order tactics to achieve their overall objectives. Our prior work now provides a coherent structure allowing us to connect the abstract tactical layer to the concrete functional layer. Specifically, we have language that enables precise speech when discussing these ideas.

Conclusion

I hope my explorations of the hierarchy, as I see it, allow for expanding the language used to discuss these details and increasing the definitional resolution of specific terms currently in our lexicon (like procedures). Whether you agree with my new/refined use of “procedures” or not, I hope you can at least appreciate my attempt to define a term that, based on my observations, we universally agree is overly broad by giving it specific technical meaning. Either way, I will use “procedures” to mean “a sequence of operations that, when combined, implement a technique or sub-technique” in my future posts, presentations, and Twitter debates.

I’d like to leave you with a parting thought. I’m going to ask you a question about Figure 3 below, and for this experiment to work, you mustn’t read the next paragraph until AFTER you have answered the question (this should not be a hard requirement to meet). When you look at this image, what object do you see?

There is a concept in social psychology called “experiential hierarchies.” This idea focuses on the categorical nesting of things. Different subjects can apprehend an individual object at different levels within the hierarchy. It is possible to interpret the object in the image at different levels of abstraction. For instance, it is simultaneously an object, a vehicle, a car, a race car, a Formula 1 race car, a Red Bull Racing Formula 1 race car, and Max Verstappen’s Red Bull Racing Formula 1 race car. Each level increases the resolution with which one considers the object.

Two questions that I want you to consider between now and my next post are:

Why did you choose the level you did?
Is there an optimal hierarchical level at which you should view things?

References

[1]: James A. Gibson. (1986). The Ecological Approach to Visual Perception. Psychology Press.

[2]: Korzybski, Alfred (1933). Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics. International Non-Aristotelian Library Publishing Company.

[3]: Robby Winchester. (2017, September 27). What’s in a name? TTPs in Info Sec. Medium.

[4]: Joint Chiefs of Staff. (2010). Department of Defense dictionary of military and associated terms (JP 1–02).

[5]: Winchester, R. (2017, September 27). What’s in a name? TTPs in Info Sec. Medium.

[6]: Delpy, B. (2014). Mimikatz. GitHub repository.

[7]: Atkinson, Jared C. (2022, August 18). Part 5: Expanding the operation graph. Medium.

[8]: Atkinson, Jared C. (2022, June 27). Understanding the function call stack. Medium.

[9]: Atkinson, Jared C. (2022, July 19). Part 1: Discovering API function usage through source code review. Medium.

[10]: Atkinson, Jared C. (2022, August 4). Part 2: Operations. Medium.

[11]: Atkinson, Jared C. (2022, August 9). Part 3: Expanding the function call graph. Medium.

[12]: Atkinson, Jared C. (2022, August 18). Part 5: Expanding the operation graph. Medium.

[13]: Microsoft. (2022, May 13). ReadProcessMemory function. Microsoft Docs.

[14] Williams E., Millington E. (2020 February 11). LSASS Memory. MITRE ATT&CK.

[15] Williams E., Le Toux V. (2017 May 31). OS Credential Dumping. MITRE ATT&CK.

[16] MITRE ATT&CK. (2018 October 17). Credential Access. MITRE ATT&CK.

[17]: James A. Gibson. (1986). The Ecological Approach to Visual Perception. Psychology Press.