Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Front matter

This is the DynaMAL patterns catalog.

Contributors

Viktor Engström

Preliminaries

Terminology

The patterns catalog introduces specialized terms to discuss patterns. These are:

  • Asset: The DynaMAL term for the representation of a physical or logical entity.
  • Association: The DynaMAL term for the representation of a physical or logical relationship between assets.
  • Authentication object: A type of configuration object that represents material used during identification and authentication procedures, such as accounts, access keys, and passwords.
  • Configuration object: An object that represents some form of setting or other passive control logic that directs the execution logic of other objects. Configuration objects contain little to no executable logic.
    • Colloquially: Objects that control other things.
  • Container object: An object that is a tangible and manipulable representation of data or information. Container objects contain little to no executable logic.
    • Colloquially: Objects that are used and moved by other objects.
  • Execution object: An object that represents active entities in the represented domain, i.e., entities that act and interact with other objects. Execution objects contain the bulk of the total executable logic.
    • Colloquially: Objects that do things.
  • Simple object: An object without elaborate relationships or attributes. For instance, a single asset with a single association.
  • Object: A physical or logical entity in the domain, typically represented via assets.

The pattern format

The pattern format used in this catalog was inspired by the format in Design Patterns [1] and consists of seven standard components:

  • Diagram: a visual representation of the pattern.
  • Intent: a brief statement about what the pattern represents.
  • Motivation: a longer description of the pattern and the context in which it arose.
  • Possible use cases: examples where applying the pattern may be motivated.
  • Code example: an illustrative DynaMAL implementation of the pattern.
  • Possible synonyms: alternative terms that may correspond to the pattern.
  • Occurrences: the sources and evidence for the pattern.

Pattern entries may not omit any of the standard entries. Candidate patterns may omit one or more of the standard entries.

Visual syntax

Diagram elements

The pattern entries in the catalog must begin with a visual representation. These representations should diagrams that depict the graph operations prescribed by the pattern. To ensure a consistent visual syntax, the graph visualizations must be constructed from the standard elements depicted above.

The standard elements are as follows:

  • Object: A vertex that represents some entity.
  • Collected object: A vertex that has been retrieved with a collect operation.
  • Potential object: An ephemeral vertex, used to signal the intended result of an addition.
  • Relationship: An edge that represents some relationship between two entities.
  • Collection: An edge with a gradient that represents a collect operation and its direction. Collect directions are light to dark, e.g., left to right in the standard elements illustrated above.
  • Potential relationship: An ephemeral edge, used to signal the intended result of an addition.

The color palette is as follows:

  • White is defined as 0xFFFFFF.
  • Black is defined as 0x000000.
  • The pattern background is white.
  • Vertex centers are white. Vertex lines are black.
  • Relationships are black.
  • Potential objects and relationships are dashed black lines.
  • Collections are depicted with white–black linear gradients.

The rules for patterns sequences are as follows:

  • A pattern sequence is one or more rows of panels that depicts a series of graph operations.
  • A row is a sequence of panels that reads left–right.
  • A row typically consists of three to five panels.
  • A panel is a single diagram that depicts some graph operations, e.g., a step
  • The first and last panels of a sequence should depict the initial and end states, respectively.
  • Intermediate steps should depict one graph operation, but more may be shown.
  • Pattern diagrams may depict multiple alternative pattern sequences, where the beginning and the end of a sequence should be indicated by a single black horizontal line.
  • Extraneous visual elements, such as text labels and extra arrows, are to be avoided.

An annotated example

Annotated example

The diagram above shows an annotated pattern sequence for the Transfer pattern. The sequence is to be read as:

  1. The initial state shows the first objects and relationships.
  2. The first operation (1.) collects the top right object from the top left object.
  3. Retain the previous collection (1.), collect the bottom object from the top left object (2.). The potential relationship (3.) between the top right object and the bottom object is depicted.
  4. Link the top right and the bottom objects (3.). Collect the bottom elements from the top left object (4.).
  5. Unlink the top left object and the bottom object (4.). The end state has been reached.

References

[1] E. Gamma, R. Helm, R, Johnson, J. Vlissides, Design patterns : elements of reusable object-oriented software. Reading, Mass: Addison-Wesley, 1995.

Atomic patterns

Add

The add pattern

Intent

This is the fundamental graph operation for creating objects (vertices) dynamically within some context.

Motivation

Many adversarial actions include the notion of object addition, such as creating, uploading/downloading, and infecting objects. These actions reduce to the ability to add new objects to an existing model as a direct consequence. This pattern especially refers to simple objects.

Possible use cases

Use Add when creating:

  • Container objects, such as data or information objects.
  • An object that represents a new device.
  • Simple execution objects, such as applications, services, or scripts.
  • Simple configuration objects.
  • Simple principals, such as accounts and identities.
  • Simple authentication objects, such as keys and credentials.
  • Data transfers by adding an object to the receiver directly.
  • Simple malicious execution objects, such as an initial infection or malicious payload upload.
  • Malicious execution objects to be activated later.
  • Malicious executable logic that compromises the target, such as a backdoor.
  • Simple cxecution objects that represent artifact creation, such as the development of a custom application, exploit, or other script.
  • Manipulative container objects, such as forged or otherwise deceptive documents.
  • Certain simplified cryptographic objects, such as detachable signatures.

Code example

asset Host {
  | startApplication >
    A> self / applications

  | addFile >
    A> self / files

  | infectHost >
    A> self / malware
}

asset Application {[...]}
asset File {}
asset Malware {[...]}

associations {
  Host [host] 1 <-- Execution --> * [applications] Application
  Host [host] * <-- Storage --> * [files] File
  Host [host] 1 <-- Infection --> * [malware] Malware
}

Possible synonyms

•build •construct •craft •create •connect •deliver •develop •distribute •download •drop •sign [crypto] •forge •generate •hijack •implant •implement •include •infect •insert •install •place •plant •propagate •provide •provision •push •reply •request •schedule •send •spawn •start •store •update •upgrade •upload •write

Occurrences

ATT&CK

•Abuse elevation control mechanism •Account manipulation •Acquire access •Adversary-in-the-middle •Boot or logon autostart execution •Boot or logon ini- tialization scripts •Browser extensions •Browser session hijacking •Compromise client software binary •Compromise infrastructure •Content injection •Create account •Create or modify system process •Content injection •Data from information repository •Data destruction •Data encrypted for impact •Data manipulation •Direct volume access •Disk wipe •Develop Capabilities •Domain policy modification •Escape to host •Endpoint denial of service •Event triggered execution •Execution guardrails •Exploitation for credential access •Forced authentication •Forge web credentials •Hardware additions •Hide artifacts •Hijack execution flow •Impair defenses •Inter-process communications •Implant internal image •Modify authentication process •Native API •Modify system image •Multi-factor authentication request generation •Network boundary bridging •Obfuscate files or information •Office application startup •Phishing •Pre-OS boot •Process injection •Proxy •Replication through removable media •Scheduled task/job •Scheduled transfer •Serverless execution •Server software component •Steal application access token •Steal or forge authentication certificates •Steal or forge Kerberos tickets •Subvert trust controls •Supply chain compromise •System binary proxy execution •Taint shared content •System services •Use alternate authentication material •User execution •Valid account •Virtualization/sandbox evasion

Remove

Remove pattern

Intent

This is the fundamental graph operation for removing objects (vertices) and their associations within some context.

Motivation

Some adversarial actions include the notion of deletion or destruciton, such as when clearing, deleting, destroying, killing, and stopping certain objects and entities. These actions are particularly common for obstructing defenders or causing destructive effects. This pattern is especially relevant for manipulating simple objects.

Possible use cases

Use Remove when deleting:

  • Container objects for destructive effects, such as data or information.
  • Container objects to hide or otherwise prevent it from reaching another entity.
  • Simple execution objects to impair a system, such as an application, service, or a script.
  • Simple configuration objects to impair or circumvent mechanisms.
  • Simple authentication objects to obstruct or for destructive effects, such as accounts and access keys.
  • Adversary-made simple objects to remove indicators of compromise.
  • Simple objects to deceive or otherwise trigger a response from another entity or agent.
  • Malicious objects in a self-destructive manner as a form of disengagement or to remove indicators of compromise.
  • Processes, applications, services, and possibly entire systems.

Code example

asset Malware {
  | stopApplications >
    R> host / applications

  | deleteFiles >
    R> host / files

  | disengage >
    A> self / self
}

asset Host {[...]}
asset Application {[...]}
asset File {}

associations {
  Host [host] 1 <-- Execution --> * [applications] Application
  Host [host] * <-- Storage --> * [files] File
  Host [host] 1 <-- Infection --> * [malware] Malware
}

Possible synonyms

•clean •clear •delete •disengage •kill •remove •shutdown •stop

Occurrences

ATT&CK

•Account access removal •BITS jobs •Data destruction •Data manipulation •Disk wipe •Debugger evasion •Hide artifacts •Impair defenses •Indicator removal •Inhibit system recovery •Input capture •Modify cloud compute infrastructure •Obfuscated files or information •Phishing for information •Power settings •Resource hijacking •Scheduled task/job •Service stop •System binary proxy execution •Virtualization/sandbox evasion

Link

Link pattern

Intent

This is the fundamental graph operation for creating a link (association) between two objects (vertices).

Motivation

Many adversarial actions include the notion of establishing new relationships between existing objects, such as when adding, attaching, assigning. binding, copying, giving, sending, and transferring objects.

This pattern is a special case among the atomic patterns since it is an operation on node pairs, which resembles closing a triangle.

Possible use cases

  • Setting up a communication channel between two objects, such as a computer network connection.
  • Connect a device to an existing object.
  • Setting up a malicious covert channel between two objects, such as a backdoor.
  • Placing benign or executable objects in some location.
  • Placing inert objects, such as when storing data objects.
  • Designating an executable object for another entity.
  • Designating a target object for a configuration object, indirectly changing some execution flow or logic.
  • Declaring or granting ownership or rights for certain objects, such as authentication or data objects.
  • Assigning authentication objects to a principal, such as assigning a policy to an identity.
  • Attach an object to another as a foothold, especially when expressing infections.
  • Attach malicious executable object to another object, a form of viral infection.
  • Copying some object from one location to another by expressing its presence in multiple locations.
  • Stealing or exfiltrating objects without removing the original object.
  • Creating an additional relationship to the same object, such as data having primary storage and backup storage relationships.
  • Attaching otherwise meaningful objects, such as signatures.

Code example

iasset Host {
  | connectToHost
    A> self / ~network.hosts.receiveFrom

  | copyFiles
    A> files / ~network.hosts.host
}

asset Malware {
  | activate
    -> infectHosts, host.connectToHost, copyFiles
  | infectHosts
    A> self / ~ host.network.hosts.malware
}
asset Network {}
asset File {}

associations {
  Host [hosts] * <-- Placement --> 1 [network] Network
  Host [receiveFrom] * <-- Party --> [sendTo] * Host
  Host [host] * <-- Storage --> * [files] File
  Host [host] 1 <-- Infection --> * [malware] Malware
}

Possible synonyms

•acquire •add •apply •assign •associate •attach •backdoor •backup •bind •clone •collect •copy •create •delegate •deliver •distribute •download •duplicate •drop •enroll •establish •exfiltrate •export •forward •give •grant •hijack •hook •implant •import •include •inherit •infect •inject •insert •install •intercept •introduce •load •mirror •mount •obtain •pass •place •plant •point •poison •propagate •push •register •replicate •request •retrieve •set •share •sign •spawn •specify •spread •steal •store •subscribe •transfer •transmit •update •upload •write

Occurrences

ATT&CK

•Abuse elevation control mechanism •Account manipulation •Access token manipulation •Acquire access •Acquire infrastructure •Adversary-in-the-middle •Archive collected data •Automated collection •Automated exfiltration •BITS jobs •Browser extensions •Browser session hijacking •Boot or logon autostart execution •Boot or logon initialization script •Build image on host •Create account •Create or modify system process •Command and scripting interpreter •Compromise accounts •Compromise client software binary •Content injection •Data destruction •Data encrypted for impact •Data from information repository •Data from removable media •Data staged •Data transfer limits •Deploy container •Direct volume access •Disk wipe •Drive-by compromise •Domain policy modification •Dynamic resolution •Email collection •Escape to host •Event triggered execution •Execution guardrails •Exfiltration over alternative protocol •Exfiltration over C2 channel •Transfer data to cloud account •Exfiltration over other network medium •Exfiltration over physical medium •Exfiltration over web service •Exploitation for credential access •Exploitationfor client execution •Exploitation for privilege escalation •Forced authentication •Forge web credentials •Hardware additions •Hide artifacts •Hijack execution flow •Impair defenses •Implant internal image •Ingress tool transfer •Input capture •Inter-process communication •Internal spearphishing •Lateral tool transfer •Log enumeration •Masquerading •Modify authentication process •Modify cloud computer infrastructure •Modify system image •Multi-stage channel •Network sniffing •Obfuscated files or information •OS credential dumping •Phishing •Plist file modification •Pre-OS boot •Process injection •Reflective code loading •Remote access software •Replication through removable media •Rogue domain controller •Scheduled task/job •Scheduled transfer •Serverless exeuction •Server software component •Stage capabilities •Steal application access token •Steal or forge authentication certificates •Steal or forge Kerberos tickets •Steal web session cookie •Subvert trust controls •Supply chain compromise •System binary proxy execution •Taint shared content •Template injection •Traffic signaling •Transfer data to cloud account •Process injection •Unsecured credentials •Use alternative authentication material •User execution •Video capture •Virtualization/sandbox evasion

Unlink

Unlink pattern

Intent

This is the fundamental graph operation for removing a link (association) between two objects (assets).

Motivation

Some adversarial actions include the notion of severing relationships between existing objects, such as when clearing, deleting, destroying, excluding, redirecting, and removing objects. These actions reduce to removing links between two objects, while leaving the objects themselves intact.

Possible use cases

Use Unlink when:

  • Making objects unavailable for destructive effects while preserving the object in the model.
  • Detaching executable objects to shut them down or otherwise impair a system.
  • Detaching configuration objects to change behaviors or the flow of execution.
  • Detaching simple authentication objects to prevent or block access.
  • Detaching objects created during an attack to avoid leaving indicators of compromise.

Code example

asset Host {
  | disconnectHost >
    R> self / ~sendTo,
       self / ~receiveFrom,
       self / ~network

  | deleteFiles >
    A> self / ~files
}

asset Network {}
asset File {}

associations {
  Host [hosts] * <-- Placement --> 1 [network] Network
  Host [receiveFrom] * <-- Party --> [sendTo] * Host
  Host [host] * <-- Storage --> * [files] File
}

Possible synonyms

•clean •clear •delete •destroy •erase •exclude •hijack •kill •redirect •reformat •remove •shutdown •unhook •unregister •wipe

Occurrences

ATT&CK

•Account access removal •BITS jobs •Data destruction •Data manipulation •Disk wipe •File and directory permissions modification •Hijack execution flow •Impair defenses •Indicator removal •Inhibit system recovery •Modify authentication process •Modify cloud compute infrastructure •Native API •Obfuscated files or information •Resource hijacking •Service stop •System binary proxy execution

Patterns

Transfer

Transfer pattern

Intent

This pattern re-links an object to update a relationship or to re-position it.

Motivation

There are numerous instances of adversaries changing the relationship between objects, such as by transferring objects from one location to another. Transferring objects is particularly prevalent since it mimics many movement forms and re-configurations in the physical and logical dimensions.

Possible use cases

Use Transfer when:

  • Moving objects from one location to another, physical or logical.
  • Moving container objects to mimic data transfers.
  • Sending or relaying objects to another party without keeping a local copy.
  • Delivering (malicious) objects to a remote party.
  • Fetching an object from another location without leaving a remote copy.
  • Performing true theft, where the objects will not remain in their original location.
  • Swapping an execution object that is invoked by another entity.
  • Changing target of configuration objects, thereby affecting the flow of execution and system behaviors.
  • Changing connections and communication channels of physical devices or networks.
  • Diverting connections, communication channels, and execution flows.
  • Transferring ownership of objects.
  • Re-assigning authentication objects.

Code example

asset Host {
  | transferFile >
    A> dirs.files / ~sendTo.dirs.dir
    R> dirs / ~files

  | moveFile >
    A> dirs / ~dirs.files.dir
    R> dirs / ~files
}

asset Network {}
asset File {}
asset Directory {}

associations {
  Host [hosts] * <-- Placement --> 1 [network] Network
  Host [receiveFrom] * <-- Party --> [sendTo] * Host
  Host [host] * <-- Storage --> * [dirs] Directory
  Directory [dir] 1 <-- Contains --> * [files] File
}

Possible synonyms

•acquire •AITM •backup •bring •create •copy •deliver •distribute •divert •download •drop •exfiltrate •export •forward •hijack •hook •implant •import •inject •insert •install •intercept •load •move •overwrite •place •point •poison •propagate •provide •push •redirect •reflect •relay •remove •replace •replay •request •retarget •retrieve •send •set •specify •spread •setup •steal •store •transfer •transmit •update •upgrade •upload •write

Occurrences

ATT&CK

•Account manipulation •Acquire access •Adversary-in-the-middle •Archive collected data •Automated exfiltration •BITS jobs •Browser session hijacking •Boot or logon autostart execution •Content injection •Create or modify system process •Command and scripting interpreter •Communication through removable media •Compromise infrastructure •Content injection •Data destruction •Data encrypted for impact •Data from removable drive •Data staged •Data transfer limits •Deploy container •Direct volume access •Disk wipe •Domain policy modification •Email collection •Endpoint denial of service •Escape to host •Event triggered execution •Execution guardrails •Exfiltration over alternative protocol •Exfiltration over C2 channel •Exfiltration over other network medium •Exfiltration over physical medium •Exfiltration over web service •Exploitation for client execution •Exploitation for credential access •Exploitation for privilege escalation •Financial theft •Forced authentication •Hide artifacts •Hijack execution flow •Impair defenses •Implant internal image •Ingress tool transfer •Input capture •Internal spearphishing •Inter-process communication •Lateral tool transfer •Log enumeration •Masquerading •Modify authentication process •Modify cloud computer infrastructure •Modify system image •Multi-factor authentication request generation •Multi-stage channel •Network denial of service •Network sniffing •Obfuscated files or information •Office application startup •Phishing •Phishing for information •Pre-OS boot •Process injection •Remote service session hijacking •Replication through removable media •Rootkit •Scheduled transfer •Server software component •Serverless execution •Stage capabilities •Steal application access token •Subvert trust controls •Supply chain compromise •Taint shared content •Transfer data to cloud account •Unsecured credentials •Use alternate authentication material •User execution •Video capture •Virtualization/sandbox evasion

Replace

Replace pattern

Intent

This pattern replaces an object with another without preserving the original.

Motivation

There are occasional instances of adversaries replacing or overwriting existing objects, both container and executable objects. This reduces to removing the original object, then adding a new one in its stead.

Possible use cases

Use Replace when:

  • Overwriting simple objects.
  • Replacing a benign execution object with a malicious counterpart.
  • Overwriting a simple object with a stronger/weaker version, such as when overwriting a weak policy with a privileged one.
  • Updating configuration objects when values are expressed as simple discrete objects.
  • One-way encrypting or similarly destroying simple objects.

Code example

asset Host {
 | replaceFiles >
    R> self / files
    A> self / files

 | plantMalware >
    R> self / applications
    A> self / applications[Malware]
 }

asset Application {[...]}
asset Malware extends Application {[...]}
asset File {}

associations {
  Host [host] 1 <-- Execution --> * [applications] Application
  Host [host] * <-- Storage --> * [files] File
}

Possible synonyms

•copy •encrypt •distribute •inject •install •overwrite

Occurrences

ATT&CK

•Boot or logon autostart execution •Compromise client software binary •Data destruction •Data encrypted for impact •Disk wipe •Event triggered execution •File and directory permissions modification •Firmware corruption •Hide artifacts •Hijack execution flow •Modify system image •Pre-OS boot •Process injection •Server software component •Supply chain compromise

Assemble

Assemble pattern

Intent

This pattern creates one or more origin objects, then creates at least one or more layer of related objects starting from the origin objects.

Motivation

There are multiple occurrences of adversaries creating more elaborate structures in stages that can not be conveniently expressed through singular graph operations. Moreover, many elaborate structures start from a single new object, then adds more from there. Such actions reduce to multiple application of Add.

Realistically, elaborate structures may require multiple applications of Assemble in combination with other patterns, such as Install.

Possible use cases

Use Assemble when:

  • Creating more elaborate object structures in multiple stages.
  • Creating an object and at least one immediately related sub-object.
  • Creating a hierarchy of objects.
  • Creating and filling a container objects.
  • Creating a configuration object and its related sub-objects, such as a setting and a nominal value.
  • Creating an authentication object and its related sub-objects, such as an account and a key.
  • Creating an execution object packed with additional objects, such as further execution objects.
  • Deploying executors and executees, such as a container (executor) and its applications (executees).

Code example

asset Host {
 | createDirectories >
    A> self / dirs
    A> dirs / files

 | startContainer >
    A> self / applications[Container]
    A> applications[Container] / applications
}

asset File {}
asset Directory {}
asset Application {[...]}
asset Container extends Application {[...]}

associations {
  Host [host] * <-- Storage --> * [dirs] Directory
  Directory [dir] 1 <-- Contains --> * [files] File
  Host [host] 1 <-- Execution --> * [applications] Application
  Container [executor] 1 <-- Container --> * [executee] Application
}

Possible synonyms

•add •build •craft •create •deploy •run •update •upgrade

Occurrences

ATT&CK

•Abuse elevation control mechanisms •Account manipulation •Build image on host •Compromise infrastructure •Create account •Deploy container •Develop capabilities •Hide artifacts •Modify cloud compute infrastructure •Rogue domain controller •Scheduled task/job •Steal application access token

Disassemble

Disassemble pattern

Intent

This pattern removes objects at the fringes of a more elaborate structure, then works downward until it removes the origin object(s).

Motivation

There are occurrences of deleting or dismantling more elaborate structures in multiple steps that can not be conveniently expressed through singular grap operations. Such dismantlings typically start from the farthest objects, then works downwards in iterations to the final origin objects. Such staged removals reduce to multiple applications of Remove.

Possible use cases

Use Disassemble when:

  • Dismantling more elaborate object structures with multiple layers of objects.
  • Dismantling a hierarchy of objects.
  • Deleting a container object and its sub-objects.
  • Deleting a configuration object and its sub-objects, such as a setting and a nominal value.
  • Deleting an authentication object and its sub-objects, such as an account and a credential.
  • Deleting an executable object packed with additional objects, such as further execution objects.
  • Terminating executors and executees, such as a container (executor) and its running applications (executees).
  • Deleting object structures specifically to impair or shut down a system.

Code example

asset Host {
 | removeDirectories >
    R> dirs / files
    R> self / dirs

 | shutDownContainer >
    R> applications[Container] / applications
    R> self / applications[Container]
}

asset File {}
asset Directory {}
asset Application {[...]}
asset Container extends Application {[...]}

associations {
  Host [host] * <-- Storage --> * [dirs] Directory
  Directory [dir] 1 <-- Contains --> * [files] File
  Host [host] 1 <-- Execution --> * [applications] Application
  Container [executor] 1 <-- Container --> * [executee] Application
}

Possible synonyms

•delete •destroy •erase •kill •shutdown •stop •terminate •uninstall •wipe

Occurrences

ATT&CK

•Disk wipe •Impair defenses •Inhibit system recovery •Modify cloud compute infrastructure •Modify system image •Resource hijacking •Service stop •System shutdown/reboot

Install

Install pattern

Intent

This pattern creates one or more origin objects, then links them to other existing items.

Motivation

There are multiple occurrences of creating objects then linking them to the surrounding context, which creates an elaborate structure. Such operations reduce to an application of Add followed by one or more applications of Link.

Possible use cases

Use Install when:

  • Adding a simple object followed by at least one new link.
  • Creating a configuration object and linking it to one or more objects.
  • Creating and immediately assigning authentication objects, such as a key.
  • Setting up execution objects on a system, i.e., installing it.
  • Creating and attaching execution objects to another object.
  • Creating an executor and linking it to its executees.
  • Creating an executee, then linking it to an executor.
  • Copying an object with more elaborate relationships.
  • Inserting container objects into more elaborate structures.
  • Attaching an object in a more elaborate manner, such as when creating and attaching cryptographic signature objects.

Code example

asset Host {
 | generateKey >
    A> self / keys
    A> identities / ~keys.owners

 | scheduleMalware >
    A> self / applications[Malware]
    A> applications[Malware] / applications[Scheduler].parent
}

asset Key {}
asset Account {}
asset Application {[...]}
asset Malware extends Application {[...]}
asset Scheduler extends Application {[...]}

associations {
  Host [host] * <-- Storage --> * [keys] Directory
  Host [host] 1 <-- Accounts --> * [identities] Identity
  Identity [owners] * <-- Identify --> * [keys] Key
  Host [host] 1 <-- Execution --> * [applications] Application
  Application [parent] 1 <-- Process --> * [child] Application
}

Possible synonyms

•add •backdoor •bring •clone •copy •create •deploy •download •duplicate •forge •generate •implant •implement •infect •inject •insert •intercept •introduce •load •make •obtain •place •plant •poison •propagate •provision •push •run •schedule •setup •sign [crypto] •spawn •start •update •upgrade

Occurrences

ATT&CK

•Access token manipulation •Account manipulation •Acquire access •Acquire infrastructure •Adversary-in-the-middle •Automated collection •Browser extensions •Browser session hijacking •Boot or logon autostart execution •Build image on host •Create account •Create or modify system process •Compromise client software binary •Data destruction •Data manipulation •Data staged •Deploy container •Develop capabilities •Direct volume access •Domain policy modification •Email collection •Escape to host •Event triggered execution •Execution guardrails •Exploitation for credential access •Exploitation for privilege escalation •Forge web credentials •Hide artifacts •Hijack execution flow •Impair defense •Implant internal image •Input capture •Install root certificate •Inter-process communications •Modify authentication process •Modify cloud compute infrastructure •Modify system image •Network boundary bridging •Native API •Office application startup •OS credential dumping •Pre-OS boot •Proxy •Remote access software •Replication through removable media •Rogue domain controller •Scheduled task/job •Scheduled transfer •Server software component •Serverless execution •Steal or forge authentication certificates •Steal or forge Kerberos tickets •Subvert trust controls •Supply chain compromise •System binary proxy execution •System services •Unused/unsupported cloud regions •Use alternate authentication material •Valid account

Uninstall

Uninstall pattern

Intent

This pattern removes more elaborate relationships originating from one or more objects, then removes the origin object(s).

Motivation

There are occurrences of removing and dismantling objects with more elaborate relationships to their surrounding. These relationships may be direct or indirect.

Uninstall is not explicitly featured as frequently as Install, but it is a necessary inverse pattern.

Possible use cases

  • Removing at least one link followed by an origin object.
  • Deleting a configuration object and its relationships.
  • Removing executable logic from an system, possibly impairing or downgrading it.
  • Unlinking an authentication item, then removing it.
  • Deleting a copy of some object with more elaborate relationships.
  • Removing inert objects from more elaborate structures.

Code example

asset Host {
 | revokeKey >
    A> self / keys
    A> identities / ~keys.owners

 | disengageMalware >
    R> applications[Malware] / ~parent[Scheduler]
    R> applications[Malware] / self
}

asset Key {}
asset Account {}
asset Application {[...]}
asset Malware extends Application {[...]}
asset Scheduler extends Application {[...]}

associations {
  Host [host] * <-- Storage --> * [keys] Directory
  Host [host] 1 <-- Accounts --> * [identities] Identity
  Identity [owners] * <-- Identify --> * [keys] Key
  Host [host] 1 <-- Execution --> * [applications] Application
  Application [parent] 1 <-- Process --> * [child] Application
}

Possible synonyms

•delete •destroy •erase •reformat •remove •wipe

Occurrences

ATT&CK

•Account access removal •Disk wipe •Inhibit system recovery •Modify cloud compute infrastructure •Modify system image

Pack

Pack pattern

Intent

This patterns transfers an object to another super-object to express a grouping or aggregate.

Motivation

There are many occurrences of actions that group or collect objects inside other objects, such as when compressing, compiling, embedding, obfuscating, encoding, and encrypting objects. These actions reduce to transferring multiple sub-objects under a super-object.

Possible use cases

Use Pack when:

  • Collecting and handling an aggregate of objects.
  • When translating objects into another intermediate format.
  • When hiding objects inside other objects.
  • When collecting multiple objects as an archive.
  • When compressing multiple objects into a single object.
  • When encoding objects in a different form.
  • When encrypting objects.
  • When embedding some objects inside another object.
  • When hiding execution objects inside some other executable parent.
  • When encapsulating some objects inside another object.

Code example

asset Host {
 | compress >
    A> self / files[Compressed]
    A> files[Compressed] / ~files.super

 | encrypt >
    A> keys / cipertext
    A> keys.ciphertext / ~files.super
    R> keys.ciphertext / ~sub.host
}

asset File {}
asset Compressed extends File {}
asset EncryptionKey {}

associations {
  Host [host] 1 <-- Contains --> * [files] File
  File [super] 1 <-- Nesting --> * [sub] File
  Host [host] * <-- Carry --> * [keys] Key
  Key [key] 1 <-- Crypto --> * [ciphertext] File
}

Possible synonyms

•add •attach •archive •create •collect •compile •compress •conceal •embed •encapsulate •encode •encrypt •hide •inject •mine •obfuscate •overwrite •package •poison •smuggle

Occurrences

ATT&CK

•Archive collected data •Automated collection •Clipboard data •Command and scripting interpreter •Data destruction •Data encoding •Data encrypted for impact •Data from cloud storage •Data from configuration repository •Data from information repository •Data from local system •Data from network shared drive •Data from removable drive •Data staged •Data obfuscation •Disk wipe •Email collection •Encrypted channel •Execution guardrails •Exfiltration over alternative protocol •Exfiltration over web service •Firmware corruption •Hide artifacts •Hijack execution flow •Inter-process communications •Modify authentication process •Multi-stage channel •Obfuscated files or information •Phishing •Phishing for information •Protocol tunneling •Steal or forge authentication certificates •Subvert trust controls •System binary proxy execution •Template injection •XSL script processing

Unpack

Unpack pattern

Intent

This pattern extracts sub-objects from a grouping or aggregate under a super-object.

Motivation

There were many occurrences of grouping objects but few explicit mentions of the inverse. However, many grouping actions are reversible processes, meaning that an inverse operation is implied, such as by decompressing, de-obfuscating, decoding, and decrypting objects. These actions reduce to transferring objects out of a super-object.

Possible use cases

Use Unpack when:

  • Extracting the constituents of an aggregate of objects.
  • Recovering objects expressed in another intermediate format.
  • Extracting container objects or executable objects hidden inside other objects.
  • Extracting multiple objects collected in an archive.
  • Decompressing a singular object to retrieve its constituents.
  • Decoding objects expressed in a different format.
  • Decrypting enciphered objects.
  • Extracting embedded objects.
  • Unwrapping encapsulated objects.

Code example

asset Host {
 | decompress >
    A> self / ~files[Compressed].sub.host

 | decrypt >
    A> self / keys.ciphertext.sub.host
    R> keys / ciphertext
}

asset File {}
asset Compressed extends File {}
asset EncryptionKey {}

associations {
  Host [host] 1 <-- Contains --> * [files] File
  File [super] 1 <-- Nesting --> * [sub] File
  Host [host] * <-- Carry --> * [keys] Key
  Key [key] 1 <-- Crypto --> * [ciphertext] File
}

Possible synonyms

•decode •decrypt •deobfuscate

Occurrences

ATT&CK

•Deobfuscate/decode files or information

Deliver

Deliver pattern

Intent

Create an object, then transfer it elsewhere.

Motivation

There were some occurrences where the adversary prepared objects in one location, then sent them later. This maps to actions centered on sending, delivering, distributing, and placing objects. Such actions reduce to creating an object, then applying Transfer, either immediatly or at a later point in time.

Deliver can be approximated with other patterns that mimic transfers. However, the key is both creating and then transferring objects, the latter after a possible delay. Certain systems and tacticts specifically rely on setting up objects before transferring at a later point in time, too.

Possible use cases

Use Deliver when:

  • Preparing objects to be transferred in another time step.
  • Approximating message delivery, such as e-mail services.
  • Mimicking delivery setups, where an object is created in one location and fetched from another.
  • Mimicking trap setups, where one agent places a malicious object and another transfers it to their system.
  • Mimicking delegation, where a privileged system is responsible for generating and granting authentication objcets, such as tokens and tickets.

Code example

asset Host {
  | sendFile >
    A> self / files
    A> files / ~sendTo.files
    R self / ~files

  // On a malicious host
  | prepareMalware >
    A> self / application[Malware]

  // On a target host
  | downloadApplication >
    A> self / ~network.hosts.applications.hosts
}

asset Network {}
asset File {}
asset Application {[...]}
asset Malware extends Application {[...]}

associations {
  Host [hosts] * <-- Placement --> 1 [network] Network
  Host [receiveFrom] * <-- Party --> [sendTo] * Host
  Host [host] * <-- Storage --> * [files] File
  Host [host] 1 <-- Execution --> * [applications] Application
}

Possible synonyms

•create •send •distribute •download •generate •infect •obtain •place •poison •propagate •provide •push •request •send •spread •steal •transfer •upload

Occurrences

ATT&CK

•Account manipulation •Acquire infrastructure •Adversary-in-the-middle •Browser extensions •Domain policy modification •Endpoint denial of service •Event trig- gered execution •Forge web credentials •Ingress tool transfer •Internal spearphish- ing •Multi-factor authentication request generation •Network denial of service •Obfuscated files or information •Phishing •Phishing for information •Stage capabilities •Steal application access token •Steal or forge Kerberos tickets •Subvert trust controls •Taint shared content •Transfer data to cloud account •Use alternate authentication material

Candidate patterns

Candidate patterns are incomplete patterns that may be developed into full patterns in time.

Insert

Intent

This pattern insert an object into a sequence of objects.

Motivation

There were some occurrences of actions based on inserting objects into some ordered sequence to achieve some effect. This was mostly the case when describing actions against lower-level systems. These types of insertions reduce to a special case of Transfer, effectively a linked list insertion.

Albeit a variant of Transfer, this particular use case may warrant a special mention.

Possible use cases

Use Insert when:

  • Appending or prepending objects to a sequence.
  • Inserting container objects into a sequence.
  • Inserting execution objects into a sequence of execution objects.
  • Poisoning a sequence by inserting malicious objects.

Code example

asset Host {
 | scheduleMalware >
    A> applications[Malware] /
    ~applications[Scheduler].tasks.next*previous
    ^ ~applications[Scheduler].tasks.next*next
    R> ~applications[Scheduler].tasks.next*next

asset Application {[...]}
asset Malware extends Application {[...]}
asset Scheduler extends Application {[...]}

associations {
  Host [host] 1 <-- Execution --> * [applications] Application
  Scheduler [scheduler] 1 <-- Schedule --> * [tasks] Application
  Application [previous] 1 <-- Order --> * [next] Application
}

Possible synonyms

•add •attach •hijack •include •infect •insert •place

Occurrences

ATT&CK

•Boot or logon initialization scripts •Data obfuscation •Event triggered execution •Hijack execution flow •Process injection •Taint shared content

Fragment

Intent

Split a singular object into multiple components.

Motivation

There was one mention of breaking a single object into multiple smaller parts. This is a plausible pattern but there's not enough evidence for it being a useful pattern at this time.

Fragment implies that there is an inverse Defragment, which would convert multiple objects into one.

The fragmentation operations are effectively antonyms of Pack and Unpack. Fragmentation breaks one into many, whereas packaging groups many into one.

Possible use cases

Use Fragment when:

  • Representing one object as multiple smaller sub-objects or fragments.
  • Transferring one object as many smaller sub-objects.

Code example

NA

Possible synonyms

NA

Occurences

•Data transfer size limits