Advanced Host CLI Usage

TomAtGoogle

Shells, shells and more shells!

Do’s and don’t for creating Host CLI Actions

The Mandiant Security Validation(MSV) platform is distinctly different from attack simulation technologies. Security validation includes vast integrations with defensive technologies and attack execution across the entire enterprise security environment. It is not limited to endpoint security controls. It uses real, active attack binaries to test the effectiveness of security controls.

The platform is open and allows users to create custom actions needed in their environment.

A little review

MSV offers four shells for writing command line scripts. This article will speak to three of those

simply because the last one is very different from the rest and is honestly seldom used. The three shells that we will discuss here are bash, windows command and powershell. Python shell will not be discussed.

Each command in the script is standalone and is evaluated for a single result. If any command results in a blocked condition, an error condition or an incompatible condition, the script stops and the cleanup steps are executed. The checks are below:

Command output string. Remember, the regex starts immediately after the colon so be aware of whitespace.

blocked_match:<regex to match>
Example: "blocked_match:permission denied" will report the Action as blocked if the command's output contains the string "permission denied"

success_match:<regex to match>
Example: "success_match:new user created" will report the attack successful if the command's output contains the string "new user created"

error_match:<regex to match>
Example: "error_match:invalid syntax" will report an error if the command's output contains the string "invalid syntax"

incompatible_match:<regex to match>
Example: "incompatible_match:no outlook keys were found" will report an incompatible if the command's output contains the string "No Outlook keys were found"

Command exit codes

Blocked_nonzero
The Action should be considered blocked if its exit code is nonzero

Success_zero
The Action should be considered a successful attack if its exit code is zero

Error_nonzero
The Action will report an error if its exit code is nonzero

Incompatible_nonzero
The Action should be considered incompatible if its exit code is nonzero

Some do’s and don’ts

Do	Don’t
Keep commands as atomic as possible. Concatting commands may be prettier code, but MSV will only interpret the last return code for each line of the script.	Create shells inside of shells. It will cause return values from the inner shell to get lost and not be available for evaluation.
Pay attention to how long commands should	Require user interaction. Even when MSV uses

take. Each command has a time limit (default 60 seconds). If running a long command, modify the timeout.	an interactive session, there is no way to interact with the user interface.
Know what the output should look like. It’s difficult to create matching regex for a black box.	Run the cleanup steps in the same shell. Newer releases of MSV support running cleanup steps in their own shell.
If multiple commands need to be combined to get an expected result, create a script and run it inside MSV. (More details below)	Assume a certain application is installed on the actor. Add an incompatible check to see if it is available.
Delete any files created in the cleanup steps.	Change the command prompt. MSV checks the command prompt when a command completes.
Restore any settings changed in the cleanup steps.	Rely on outside network resources. Include any needed files inside the action itself.
Create multiple actions where appropriate. Actions should be as atomic as possible.	Do anything irreversible unless this action is exclusively for Protected Theater. The snapshot restore in Protected Theater can cure many ills.

Let’s get to work

Scenario: Whether from the Red Team, an intelligence feed, a user submission, or some personal research, a questionable powershell script shows up on your desk. The request is to create test(s) to verify new detections and/or preventative measures will stop this script.

Sample Script

While this script is not extremely complicated, it gives us lots of options on how it could be handled. In relation to MSV, the first thought is, “Do we have protected theater?” If so, there is a safe sandbox where one can run this powershell script to see what it does. If not, more research will need to be done.

For this example, let’s assume that we do not have protected theater. We need to learn as much as possible about the script in a safe manner. Looking at the script, the Invoke-Expression is the “dangerous” portion of the code. To see what the decoded code looks like, let’s replace the Invoke-Expression with an echo or a print statement.

Here’s the action in MSV:

And the output after running the action:

It appears that this encoded Powershell code gathers some system information and stores it in a local text file. One could assume that this file would be exfiltrated at a later time by another application. Now that we understand the malware, we can move forward with completing the entire action.

The complete action will have a couple of extra steps. At the beginning, the action should switch to a folder that exists on all Windows hosts where the data file can be written. In the cleanup, remove the file created during the action.

The complete action:

And the results:

Now that the action is available, it can be placed in an AEDA monitor or run on a scheduled basis to ensure the remediations prevent this type of malware in the future.

The unknown malware is always the hardest challenge. If this file had been something from the Red Team or Github, the process is simpler because the output and risks would already have been provided.

Good luck and remember, the offense may make the front page, but defense wins championships.