How to label a reverse shell that employs Command Prompt

There is no Behavior to describe the following simple reverse shell malware. The malware invokes cmd.exe and creates three pipes (stdin, stdout, stderr) to forward data between cmd.exe and an attacker across a network. The Objective of this malware can be interpreted as Command and Control, though it can also be Execution. Thus, I have two questions:

Execution is described as a secondary objective, but in this case, it's unclear what's the primary objective is. Is labeling this sample with both Command and Control and Execution right or wrong?
There is no Behavior under Command and Control to describe how the reverse shell is implemented (i.e. the fact that Command Prompt and pipes are used). However, Command-Line Interface behavior under Execution completely fits here. Perhaps, Command-Line Interface should also be listed under Command and Control.

The description of the Execution objective was confusing - it should not have used the word "objective". It should be more clear now.
As you say, reverse shell behavior is described under the ATT&CK Command-Line Interface technique, but the CLI technique covers more than C2-related behaviors, so it seems too broad to associate with C2. How about adding "reverse shell" to the description for Impact: Remote Access, with a method that describes the use of cmd and pipes?

Sorry I haven't commented in a while. I didn't forget about this, I was just pondering what the right solution is. I think one guidance should be: the labels should allow a sample to be described clearly and succinctly. Another guidance can be: if we can list a sample under an Objective, then there should be a Behavior under that Objective to describe the sample.

My problem is that labeling a reverse shell is currently confusing because it matches too many labels. This reverse shell can be described in words simply as: one, it provides a capability to accept and execute commands from an attacker; two, the commands are shell commands that are interpreted and execute by Command Prompt; an optional third is that this malware is a Windows malware. Intuitively translating these words to labels, I would only use, "Command and Control, Command Line Interface, and Windows," to express that it is a Windows malware that provides C2 infrastructure via victim hosts' built-in shell, which we know is either Command Prompt or PowerShell. Because there are many ways to provide C2, Command and Control should stay as Objective, and Command Line Interface should be a Behavior under it.

While a lot of malware use Command Line Interface to do many things, I don't think that it's bad to have CLI Behavior appear under many Objectives because it's a fact that shell can be used for many things. I also think that CLI's description should be read simply as, "The malware uses a built-in shell that comes with an OS. The shell can be PowerShell, Command Prompt, Terminal, bash, tsh, tcsh, csh, etc...."

Next, the description of Command and Control should be, "The malware provides a mechanism to accept a command from a source, parse/interpret the command and execute it either within its code or by employing another tool." Saying there is or there isn't a capability is a lot simpler than trying to infer whether the mechanism is intended to perform a diverse set of commands or just a convenient method of doing something else non-C2.

I would do away with the "Impact" Objective and move its Behaviors to different Objectives. Any malware is aimed to have an impact, or what would be the point?

I would also do away with Remote Access Behavior because that just means there exists a mechanism for C2.

"if we can list a sample under an Objective, then there should be a Behavior under that Objective to describe the sample."

Mapping to an explicit behavior will require some level of detail of the sample to be known – without detailed behavior indicators, it may only be possible to map to the higher-level objective. See the MBC FAQ, “Can MBC behaviors be used without MBC objectives? Can objectives be used without behaviors? Or must objectives and behaviors be specified in pairs?” But if detailed behavior indicators are known, appropriate MBC behaviors should be available; in some cases, MBC will need to grow to cover behaviors adequately.

"My problem is that labeling a reverse shell is currently confusing because it matches too many labels..."

I think it’s okay for a broad behavior indicator (e.g., “reverse shell”) to map to multiple MBC behaviors. See the FAQ, “Can malware behaviors identified via manual analysis map to multiple MBC behaviors, or should correspondence be one-to-one?” Also, I don’t think “this is a Windows malware” qualifies as a behavior.

"While a lot of malware use Command Line Interface to do many things, I don't think that it's bad to have CLI Behavior appear under many Objectives because it's a fact that shell can be used for many things."

It seems then that CLI would be under every objective – but keeping it under “Execution” – ways to execute, for whatever objective, is cleaner. ATT&CK groups techniques that are oriented toward a common tactic/objective. For example, “Exfiltration over Command and Control Channel” clearly applies to C2, but it’s not associated with the C2 tactic – it’s listed only under Exfiltration. Analogously, CLI is listed under Execution. This question is related to ATT&CK’s philosophy - maybe it should be a FAQ.

"Next, the description of Command and Control should be, "The malware provides a mechanism to..."

MBC’s description is based on ATT&CK’s.

"I would do away with the "Impact" Objective and move its Behaviors to different Objectives."

The Impact objective captures impacts/behaviors that don’t fit under other objectives. Where would behaviors like, Hijack System Resources or Disk Content Wipe be placed otherwise? Also, ATT&CK defines the Impact tactic, and MBC aims to mirror ATT&CK when it makes sense for malware use cases.

"I would also do away with Remote Access Behavior because that just means there exists a mechanism for C2."

ATT&CK defines the C2 tactic as “techniques adversaries use to communicate with systems under their control” and under C2 defines techniques such as Commonly Used Ports, Connection Proxy, Domain Generation Algorithms, etc. ATT&CK defines “Remote Access Tools” as a C2 technique, but the definition is, “legitimate desktop support and remote access software” – which is different than RAT malware. That’s why MBC defines “Remote Access” (as in RAT) under Impact. I updated the text of MBC’s Impact: Remote Access and C2: Remote Access Tools to make the differences clearer.

Before I address all the comments in this discussion, I think I should state how I see MBC-labeled samples can be used. The purpose for my labeling is to help studies of various malware behaviors. For example, should anyone want to examine all the ways an attacker can establish C2 with a victim host, a labeled dataset should have a label to help a researcher finds that subset of samples. It's like saying, "Here are all the malware that we know contain a C2 feature." This thinking inspires the definition of "Command and Control" as having C2 capability. Then, the Behaviors under C2 would give more details of how that C2 is implemented. That is my use case. I probably don't have everyone's use cases, but perhaps we should start listing use cases so that we can build requirements for the labels.

"Mapping to an explicit behavior will require some level of detail of the sample to be known – without detailed behavior indicators, it may only be possible to map to the higher-level objective."

I completely agree with you there. I didn't think about labeling samples based on their reports, which may not give you enough details, but is what you're doing with your examples. What I really meant was that if we found some feature of the malware that indicates a particular Objective, then MBC should have a Behavior in that objective to describe the feature in more details.

I don't think "this is a Windows malware" should be an MBC Behavior either; it seems out-of-scope for your work. However, it would be a very useful label, but I'm not suggesting you add it to MBC.

"I think it’s okay for a broad behavior indicator (e.g., “reverse shell”) to map to multiple MBC behaviors."

I should have said more explicitly that my trouble with reverse shell is that it matches too many labels but none of them add details to the others (with the exception of Command Line Interface). Right now, one can say it has "Command and Control", "Command Line Interface", "Remote Access" and "Execution" plus "Impact" because they encompass Behaviors that seems to match. I know that you have said some of those labels don't apply because of the way they are defined. To me, it absolutely is a problem that a person can pick out all these terms while going through the list without looking at their descriptions. There are many Behaviors, so it needs to be more intuitive to pick out the correct ones.

"It seems then that CLI would be under every objective – but keeping it under 'Execution' – ways to execute, for whatever objective, is cleaner."

I agree that having CLI under every objective is ugly, and it may not be necessary. If we are to work off of specific examples, then right now I'm only advocating for adding something to Command and Control to describe reverse shell. I admit that I have wanted to add CLI to C2, but now I think that CLI doesn't provide enough clarity. I think that what I want is "Reverse Shell" added to C2 with the description that "Malware accepts shell commands from attackers and use built-in shell programs to execute those commands."

I don't want to add "reverse shell" to Impact:Remote Access. I'm still against having "Remote Access" Behavior even if we can't remove "Impact" because when a malware has C2 feature, it provides remote access however limited. I understand that Remote Access is meant to describe the more powerful access: "potentially full" is the word. However, I think we ought to stay away with trying to quantify the amount of impact, it will give rise to much debate: what is full, and what count as potential? Systems may change and give new capabilities, so what is full today may not be considered full tomorrow. The amount of impact can be inferred by Behaviors that describe a C2 mechanism, so we just need to label the mechanism.

"MBC’s description [of Command and Control] is based on ATT&CK’s."

I thought we want to change wherever ATT&CK doesn't make sense?

"The Impact objective captures impacts/behaviors that don’t fit under other objectives."

We shouldn't have an Objective just to capture things that don't fit elsewhere. If you have to have Objectives for those Behaviors, I would suggest create a separate Objectives, perhaps "Compromise Availability" for Data Destruction, Denial of Service, Destroy Hardware, Disk Content Wipe, Disk Structure Wipe, Encrypt Files For Impact, Endpoint Denial of Service, Firmware Corruption, Hijack System Resources, Inhibit System Recovery, and Service Stop, and "Compromise Integrity" for Compromise Data. Remaining Behaviors can be moved. "Availability" and "integrity" are terms frequently used in business risk management, using them as labels allow the labels to be meaningful to those people.

Due to a lack of examples, I can't say this forcefully, but I think these Behaviors are more inferences than description of the samples. Take Data Destruction for example: I had a sample that would delete files with document-type extensions on network and removable media but not on the victim's host own disk, and it only deletes under a very specific and strange circumstance that makes one wonder whether the malware means to destroy data or trigger an exception. By labeling it with Data Destruction, we would remove details that may lead to other conclusions.

If the argument is that we want to align MBC Objectives with ATT&CK tactics, then Impact's description is way too general versus ATT&CK's Impact is very specific. Impact in MBC is "Behaviors that enable malware to achieve its mission." Impact in ATT&CK is "Impact consists of techniques that adversaries use to disrupt availability or compromise integrity by manipulating business and operational processes." ATT&CK language scopes Impact specifically about attacks on availability and integrity.

Thanks. I made the MBC objective more explicit, borrowing from the first line of ATT&CK's Impact description: "Behaviors that enable malware to achieve its mission of manipulating, interrupting, or destroying systems and data." "Manipulate" is broad and would seem to cover any malware mission (and all the behaviors included under the Impact objective).

MBCProject / mbc-markdown

How to label a reverse shell that employs Command Prompt #2