Add Rule: Potential File Override/Append Via SET Command

[Mahir-Ali-khan]

Summary of the Pull Request

C:\Windows\System32\cmd.exe \c >> C:\Users\dummy-user\AppData\Local\test.dll.tmp set /p="4D5A90000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000504500004C0106000000000000000000"

The Attacker can use the SET variable to append or create a new file

The set /p command is used to set the value of an environment variable based on user input. However, in this case, the = sign after /p directly assigns the provided string to the file without waiting for user input. The string "4D5A90..." is hexadecimal data.

Changelog

new: Potential File Override/Append Via SET Command

Example Log Event

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385f-c22a-43e0-bf4c-06f5698ffbd9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-08-22T21:27:22.8813544Z" /> 
  <EventRecordID>1946803766</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="7100" ThreadID="9504" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>XXXX</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-08-22 21:27:22.873</Data> 
  <Data Name="ProcessGuid">{351a8fc0-ad3a-66c7-5064-010000004c00}</Data> 
  <Data Name="ProcessId">12264</Data> 
  <Data Name="Image">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="FileVersion">10.0.22621.3672 (WinBuild.160101.0800)</Data> 
  <Data Name="Description">Windows Command Processor</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">Cmd.Exe</Data> 
  <Data Name="CommandLine">cmd /c set /p="test"</Data> 
  <Data Name="CurrentDirectory">C:\Users\user\examples\</Data> 
  <Data Name="User">XXX</Data> 
  <Data Name="LogonGuid">{351a8fc0-b821-66bf-2968-be0000000000}</Data> 
  <Data Name="LogonId">0xbe6829</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">Medium</Data> 
  <Data Name="Hashes">SHA1=7140CAF2A73676D1F7CD5E8529DB861F4704C939,MD5=428CEC6B0034E0F183EB5BAE887BE480,SHA256=3F6AA206177BEBB29FC534C587A246E0F395941640F3F266C80743AF95A02150,IMPHASH=D73E39DAB3C8B57AA408073D01254964</Data> 
  <Data Name="ParentProcessGuid">{351a8fc0-aa7c-66c5-0ad6-000000004c00}</Data> 
  <Data Name="ParentProcessId">41712</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentUser">XXX</Data> 
  </EventData>
  </Event>

Fixed Issues

N/A

SigmaHQ Rule Creation Conventions

• If your PR adds new rules, please consider following and applying these conventions

[nasbench]

Hey @Mahir-Ali-khan thanks for the contribution.

The PR contains an already submitted rule in #4968 so please remove that.

Also can you fill out the template of the PR by providing a description and an example log of what you're trying to detect.

Finally give the sigma conventions a read to ease the review process.

[Mahir-Ali-khan]

#4969 and #4968 are 2 different rules

[nasbench]

#4969 and #4968 are 2 different rules

I implore you to check the content of the PRs before making a comment. And please modify the rules to comply with the conventions

[nasbench]

@Mahir-Ali-khan did you try the command?

As it is written and provided from the blog both Sysmon and 4688 will not catch the redirect but instead will only have something like this C:\Windows\System32\cmd.exe" \c set /p=4D5A90000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000504500004C0106000000000000000000

So i wonder how did your test went? did your rule work?

[Mahir-Ali-khan]

Hello @nasbench ,

I didn't test this out , this technique was found to be successfully executed in this sophos https://news.sophos.com/en-us/2024/08/07/sophos-mdr-hunt-tracks-mimic-ransomware-campaign-against-organizations-in-india/ .

[nasbench]

Hello @nasbench ,

I didn't test this out , this technique was found to be successfully executed in this sophos https://news.sophos.com/en-us/2024/08/07/sophos-mdr-hunt-tracks-mimic-ransomware-campaign-against-organizations-in-india/ .

I'm not talking about the technique, i'm talking about your rule. If you didn't test this out how would you know that you are detecting the technique itself? As I mentioned the rule you submitted wouldn't work as the >> would not be captured in the event. So it needs to be updated.

[Mahir-Ali-khan]

Hello @nasbench

Thanks for the feedback, I have tested this query over EDR. well you was right ">>" this is not getting captured.

But this can be monitor by "SET" and "/p" command.

Below query is working just right on SentinelOne

(src.process.name='cmd.exe' OR 'powershell.exe' OR 'powershell_ise.exe') AND (tgt.process.cmdline contains 'set' and tgt.process.cmdline contains '/p')

kindly suggest if any improvements needed.

[nasbench]

I made the necessary updates to the rule.

Without the usage of ">>" this can only be a "low" as the "/p=" flag is heavily used in prompting for user info or simply showcasing messages. As the ">>" cannot be caught by Sysmon/Security logs we have to make do with that.

I added the ">>" case to the selection, just in case the attacker wrapped everything in a "/c".

Thanks for the contribution @Mahir-Ali-khan

[Mahir-Ali-khan]

Thanks @nasbench for the update