search

SecurityRiskAdvisors / VECTR

VECTR is a tool that facilitates tracking of your red and blue team testing activities to measure detection and prevention capabilities across different attack scenarios
1.37k stars 162 forks source link

CMD Execution Problems with Environment Variables #225

Closed zaicurity closed 1 year ago

zaicurity commented 1 year ago

Describe the bug The way VECTR runtimes execute CMD atomics can cause issues with some ART tests.

I ran into this issue with https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1560.001/T1560.001.md#atomic-test-2---compress-data-and-lock-with-password-for-exfiltration-with-winrar. It appears that environment variables like "%programfiles%" are resolved slightly differently during VECTR execution when compared to Invoke-Atomic.

This is what the error looks like in the runtime output: image

I believe the root cause for this is that VECTR executes the commands in CMD atomics one after the other, each with its own cmd /c statement. In contrast, Invoke-Atomic creates a oneliner to execute each command one after the other separated by & characters. This can also be seen in the Test Preview: image Execution log for Invoke-Atomic: image

To Reproduce Steps to reproduce the behavior:

  1. Import current version of ART index.yaml into VECTR
  2. Go into Test Case "Compress Data and lock with password for Exfiltration with winrar" and click "Build & Download"
  3. Install pre-reqs for ART T1560.001/8dd61a55-44c6-43cc-af0c-8bdda276860c (Easiest way is through Invoke-Atomic: Invoke-AtomicTest T1560.001 -TestGuids 8dd61a55-44c6-43cc-af0c-8bdda276860c -GetPrereqs)
  4. Unzip and execute runtime binary
  5. Look in the runtime output for About to run "%programfiles%/WinRAR/Rar.exe" a -hp"blue" hello.rar using command_prompt and subsequent errors related to the

Expected behavior The specified test should run without errors.

Workaround I've tried adding additional single or double quotes around the Variable before building the runtime but that did not fix the issue. The only workaround I found was changing the test configuration in VECTR into a oneliner similar to what Invoke-Atomic does: image With that change I was able to build and run the test without errors.

Desktop:

Additional context Searching in the ART repository I did not find any other tests that use the %programfiles% variable so I did not verify if other tests are also affected by this.

dominyko commented 1 year ago

We are having the same issue, however there is a workaround that you can use. Open a text editor with all ART rules (e.g. index.yaml) and then find all variables like "PathToAtomics\", "PathToAtomics/" and etc. And then just replace all of that with the correct ones. In most cases, it worked for us.

zaicurity commented 1 year ago

Thank you @domizi. That answer will help us with some of our issues.

Unfortunately I ran into another issue with the CMD executor which I suspect is related to the above.

Description:

I tried to run T1053.005 Test #7 from AtomicRedTeam https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1053.005/T1053.005.md#atomic-test-7---scheduled-task-executing-base64-encoded-commands-from-registry

There I noticed that the second command (schtasks.exe /Create ...) was not executed properly, resulting in the scheduled task not being created. Please note that I removed >nul 2>&1 from the Cleanup command to get more useful error output.

We can see that the Cleanup cannot find the scheduled task: image

In the screenshot above we see the runtime logging the following: About to run schtasks.exe /Create /F /TN "ATOMIC-T1053.005" /TR "cmd /c start /min \"\" powershell.exe -Command IEX([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String((Get-ItemProperty -Path HKCU:\\SOFTWARE\\ATOMIC-T1053.005).test)))" /sc daily /st 07:45 using command_prompt

However, there is no indication in the Sysmon logs that this was actually executed. I could not even see the cmd /c schtasks.exe /Create... parent process that I would expect to be logged.

I confirmed that T1053.005 Test #7 works via Invoke-AtomicTest. There the task is created and I can also see the schtasks.exe process in Sysmon logs.

Changing the failed schtasks command to something more simple I was able to get it to work: schtasks.exe /Create /F /TN "ATOMIC-T1053.005" /TR "cmd /c start /min ipconfig.exe" /sc daily /st 07:45 using command_prompt

This suggests to me that there might be an issue in the way (quoted) arguments are handled in the CMD execution method. I tried multiple variations of single and double-quotes to test if that would change the behavior but ultimately could not get it to run through the CMD executor.

Workaround:

For this specific case the only solution I found was the following:

In VECTR workaround looks like this: image

thebleucheese commented 1 year ago

@zaicurity Thanks, this detail is helpful. There's definitely some unintended behavior coming from our quote processing. We've resolved some of the automation argument issues in the upcoming release, if we have time we'll try to get this as well.

dominyko commented 1 year ago

Great to hear! Do you have an ETA for your new release?

thebleucheese commented 1 year ago

Great to hear! Do you have an ETA for your new release?

@domizi Within the next 2-3 weeks. The target is the 30th, 9 days from now, but we're starting internal UAT on the primary changes, and any unintended behavior will delay that a bit.

thebleucheese commented 1 year ago

Release target pushed to the 6th. I haven't had a chance to look into this particular issue yet, but I'll try to reproduce it and document the behavior if I'm unable to get it fixed prior to the release.

thebleucheese commented 1 year ago

@zaicurity @domizi We have fixes for these in our internal release candidate due out later this week, but I want to put out a forewarning that the way we execute commands will continue to be different than the way Invoke-Atomicredteam does. There will probably continue to be some discrepancies due to how we're creating processes and working with the windows API to try to capture as much output as we can. Dealing with the weird behavior of various STDOUT and STDERR streams is one of the trickier parts of this.

We had an issue with the max length of a command and additionally, quoting the entire command like in the case of cmd.exe /c "%programfiles%/WinRAR/Rar.exe" a -hp"blue" hello.rar turning it into cmd.exe /c ""%programfiles%/WinRAR/Rar.exe" a -hp"blue" hello.rar" resolved the issue. We've tested a limited set of additional atomics, and it seems to behave but there could be side effects.

We have some ideas for making this part of the application & testing process much more robust, but our primary focus for the next few months is on some larger UI & foundational backend work.

thebleucheese commented 1 year ago

Fixed in 8.8.0