Skip to content

CoRe rules

Jump to bottom
Karneades edited this page Apr 5, 2019 · 7 revisions

CoRe rules

CoRe rules (from Containment and Remediation) should be the Yara or Sigma equivalent but for targeted cleanup of OS artifacts. Yara or Sigma are used for pattern matching and detection when hunting for malware. But there is no definition language for containment and remediation of malware or OS artifacts in general.

CoRe should help incident responders to quickly create a cleanup rule which then would be processed by PowerSponse for cleanup of all the given indicators and artifacts defined within a rule against one or multiple hosts.

The rules are used with the commands Invoke-PowerSponse -Rule ... or New-CleanupPackage -RuleFile ... to execute every action defined within the rule either against remote hosts or through a cleanup script which includes every command to use on disconnected hosts.

Usage

Use Invoke-PowerSponse or New-CleanupPackage to use a CoRe rule for cleanup.

Invoke-PowerSponse -Rule infection.json -ComputerName host ...
New-CleanupPackage -RuleFile infection.json -ComputerName host ...

Commands used with CoRe rules

Example

Dridex creates some files, injects itself into explorer and adds a scheduled task. Taken from Detecting and removing Dridex, the steps for cleanup could be the following:

  1. Kill explorer.exe process from memory, taskkill /f /im explorer.exe
  2. Remove all tmp files from C:\users\username\data\locallow, del %userprofile%\appdata\locallow*.tmp. There could be more than one user on a PC and you’d better traverse through all users’ profile folders to check for Dridex files.
  3. Remove Dridex task, schtasks /delete /tn “User_Feed_Synchronization-{Dridex-Random-Hex-GUID}” /f
  4. Reboot the PC.

The corresponding CoRe rule looks like this - if you omit the action, then the default action is used (e.g. kill for processes, disable for tasks, ...). See section Repository below or see Repository for details about available rule actions.

{
	"PowerSponse": [
		{
			"id" : "12341234-1234-1234-1234-123412341234",
			"name" : "Dridex June 2016",
			"date" : "2016-06-01",
			"author" : "Mr. Evil",
			"description" : "Dridex cleanup rule.",
			"action" : [
				{
					"type" : "ProcessItem",
					"name" : "explorer.exe"
				},
				{
					"type" : "FileItem",
					"path" : "C:\\users\\*\\appdata\\locallow\\*.tmp"
				},
				{
					"type" : "TaskItem",
					"searchstring" : "User_F.*_S.*-\\{.{8}-(.{4}-){3}.{12}\\}"
				},
				{
					"type" : "ProcessItem",
					"name" : "iexplore.exe"
				},
				{
					"type" : "ProcessItem",
					"name" : "firefox.exe"
				},
				{ 
					"type" : "ProcessItem",
					"name" : "chrome.exe"
				},
				{
					"type" : "ComputerItem",
					"action" : "reboot"
				}
			]
		}
	]
}

Now run Invoke-PowerSponse with the defined rule.

PS> Invoke-PowerSponse -ComputerName comp1, comp2 -Rule dridex-201606.json

Or make a cleanup package (basically a PowerShell script which includes everything to run the cleanup on disconnected hosts and servers.

PS> New-CleanupPackage -ComputerName comp1, comp2 -Rule dridex-201606.json

Repository

The Repository contains the available commands for using with Invoke-PowerSponse and for New-CleanupPackage and with the available parameter for each command. The repository defines the action names for a CoRe rule.

The repository defines the available actions for each type, the available methods, the parameters which can be used inside a rule and default configuration for each.

$Script:Repository = @{

	ServiceItem = @{
		DefaultAction = "Disable"
		DefaultMethod = "WMI"
		Actions = @("Disable", "Stop", "Start", "Enable")
		ActionStart = "Start-Service"
		ActionStop = "Stop-Service"
		ActionEnable = "Enable-Service"
		ActionDisable = "Disable-Service"
		Methods = @("WMI", "External")
		Parameter = @{
			Name = "-Name"
		}
	}
...
	FileItem  = @{
		DefaultAction = "Remove"
		DefaultMethod = "WinRM"
		Actions = @("Find", "Remove")
		ActionFind = "Find-File"
		ActionRemove = "Remove-File"
		Methods = @("WinRM")
		Parameter = @{
			Path = "-Path"
		}
		ParameterOpt = @{
			Regex = "-Regex"
			Recurse = "-Recurse"
		}
	}

Rule definition

The CoRe rules are defined as XML or JSON files.

The basic structure is as follows:

  1. Root element "PowerSponse"
  2. meta information as child elements to the PowerSponse root element (id, name, author, ...)
  3. Followed by a list of actions defined with the type field used to search for the corresponding function in PowerSponse and the parameters which are passed to that function.

You can define multiple actions per rule and also multiple rules per file.

Example JSON

{
	"PowerSponse": [
		{
			"id" : "12341234-1234-1234-1234-123412341234",
			"name" : "my json rule",
			"author" : "Anton Putty",
			"description" : "Some description about this rule.",
			"action" : [
				{
					"type" : "ServiceItem",
					"name" : "my service name"
				},
				{
					"type" : "TaskItem",
					"searchstring" : "my task name"
				},
				{
					"type" : "TaskItem",
					"searchstring" : "my second task name"
				}
			]
		}
	]
}

Example XML

<PowerSponse>
	<Rule>
		<name>Test-Rule</name>
		<author>Olivia Vim</author>
		<date>2017-01-14</date>
		<description>Again, your description here.</description>
		<links>https://you-super-references.here</links>
		<Action>
			<type>ServiceItem</type>
			<name>Bad Service Name</name>
		</Action>
		<action>
			<type>TaskItem</type>
			<searchstring>Evil task</searchstring>
		</action>
		<action>
			<type>ProcessItem</type>
			<Name>malicious task</Name>
		</action>
	</Rule>

	<Rule>
		<name>Second Rule</name>
		<author>Ms. PowerShell</author>
		<date>2017-01-14</date>
		<description>Again, your description here.</description>
		<Action>
			<type>ServiceItem</type>
			<name>Evil service</name>
		</Action>
		<action>
			<type>ProcessItem</type>
			<Name>malicious task</Name>
		</action>
	</Rule>
</PowerSponse>
Clone this wiki locally