Can someone please provide some guidance on how to go about writing a YARA-L rule for to detect this?
- Randomized powershell executables - hash is poweshell.exe but file name is different.
Randomized powershell executables - hash is poweshell.exe but file name is different.
+10To describe this at a high-level, you're attempting to find files that have a file hash that's the same as "powershell.exe" but isn't named that. You could use a "List" with all the known file hashes (you can use Virustotal to get a list) and then use a detection to compare, or here's an example where we're doing the comparison in the rule. Should help you get started!
rule anomalous_powershell_filename {
meta:
author = "Google Cloud Security Example"
events:
$e.metadata.event_type = "PROCESS_LAUNCH"
$e.principal.process.command_line = /powershell.exe/ nocase
$e.principal.process.file.sha256 = $hash
$e2.principal.process.file.sha256 = $hash
$e2.principal.process.command_line != ""
$e2.principal.process.command_line != /powershell.exe/ nocase
match:
$hash over 1h
condition:
$e and $e2
}
+22This one is a bit of a tough one, not from the actual creation of the rule but more the care and feeding of the rule itself.
I'll lay out some challenges but then also provide a few ideas around how you could handle this. First off is what are the hashes for PowerShell? There are likely a number of them floating around there since you can run PowerShell for mac, linux and windows, not to mention x64 and x86. The ISE versions plus the CLI versions and 7.3 for example is issued with pwsh and different versions all factor into this to make this a tough thing to wrangle. My initial thought on this is that if you have a software management system, a pull of some sort to gather the ones in your environment might be a place to start. The NIST NSRL also maintains a corpus of hashes (more broadly) but again that is a big data set to work through.
Rather than going for all the versions of PowerShell that exist out there, maybe narrowing down on just the PowerShell SHA256 hashes that exist in your environment is a place to start and then maintenance of that list needs to be handled as part of upgrades and the like. If you have that list established, the rule I believe you are looking for would look something like this:
rule powershell_calls_not_matching_hash {
meta:
author = "analyst123"
description = "8:00 AM local time"
severity = "Medium"
events:
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.principal.process.command_line != /powershell\\.exe/ nocase
$process.principal.process.file.sha256 = "9f914d42706fe215501044acd85a32d58aaef1419d404fddfa5d3b48f66ccd9f" //single hash option
$process.principal.process.file.sha256 in %list_of_powershell_hashes //list option
condition:
$process
}
As mentioned there is a lot of ground here that I am concerned may be missed. Here is an example of some criteria I wrote to try to encompass different varieties of powershell and I don't think I covered pwsh on this older version.
re.regex($event.target.process.file.full_path, `(system32|syswow64)\\\\WindowsPowerShell\\\\v1\\.0\\\\powershell(|\\_ise)\\.exe`) nocase
Another option you may have depending on the endpoint logging solution you have access to is to leverage a field like original field name. Here is an example where the process launch in sysmon is named an arbitrary name but the original name is mimikatz. Since it sounds like you are looking for masquerading, perhaps this route could assist as well.
+3- Bronze 3
To describe this at a high-level, you're attempting to find files that have a file hash that's the same as "powershell.exe" but isn't named that. You could use a "List" with all the known file hashes (you can use Virustotal to get a list) and then use a detection to compare, or here's an example where we're doing the comparison in the rule. Should help you get started!
rule anomalous_powershell_filename {
meta:
author = "Google Cloud Security Example"
events:
$e.metadata.event_type = "PROCESS_LAUNCH"
$e.principal.process.command_line = /powershell.exe/ nocase
$e.principal.process.file.sha256 = $hash
$e2.principal.process.file.sha256 = $hash
$e2.principal.process.command_line != ""
$e2.principal.process.command_line != /powershell.exe/ nocase
match:
$hash over 1h
condition:
$e and $e2
}
Thanks Mike, much apprecaited!
+3- Bronze 3
This one is a bit of a tough one, not from the actual creation of the rule but more the care and feeding of the rule itself.
I'll lay out some challenges but then also provide a few ideas around how you could handle this. First off is what are the hashes for PowerShell? There are likely a number of them floating around there since you can run PowerShell for mac, linux and windows, not to mention x64 and x86. The ISE versions plus the CLI versions and 7.3 for example is issued with pwsh and different versions all factor into this to make this a tough thing to wrangle. My initial thought on this is that if you have a software management system, a pull of some sort to gather the ones in your environment might be a place to start. The NIST NSRL also maintains a corpus of hashes (more broadly) but again that is a big data set to work through.
Rather than going for all the versions of PowerShell that exist out there, maybe narrowing down on just the PowerShell SHA256 hashes that exist in your environment is a place to start and then maintenance of that list needs to be handled as part of upgrades and the like. If you have that list established, the rule I believe you are looking for would look something like this:
rule powershell_calls_not_matching_hash {
meta:
author = "analyst123"
description = "8:00 AM local time"
severity = "Medium"
events:
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.principal.process.command_line != /powershell\\.exe/ nocase
$process.principal.process.file.sha256 = "9f914d42706fe215501044acd85a32d58aaef1419d404fddfa5d3b48f66ccd9f" //single hash option
$process.principal.process.file.sha256 in %list_of_powershell_hashes //list option
condition:
$process
}
As mentioned there is a lot of ground here that I am concerned may be missed. Here is an example of some criteria I wrote to try to encompass different varieties of powershell and I don't think I covered pwsh on this older version.
re.regex($event.target.process.file.full_path, `(system32|syswow64)\\\\WindowsPowerShell\\\\v1\\.0\\\\powershell(|\\_ise)\\.exe`) nocase
Another option you may have depending on the endpoint logging solution you have access to is to leverage a field like original field name. Here is an example where the process launch in sysmon is named an arbitrary name but the original name is mimikatz. Since it sounds like you are looking for masquerading, perhaps this route could assist as well.
Thanks John for the detailed explanation. Yes I am looking for masquerading solutions for PowerShell. Let me get started with some of the ideas you shared here and circle back if I have any further questions!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.