thae 14 Posted July 9 Posted July 9 Hey everyone, I thought it would be a good idea to create a thread for sharing your own created rules. Here's one rule which looks for IOCs of StrelaStealer <?xml version="1.0" encoding="utf-8"?> <rule> <description> <name>IOCs of StrelaStealer Usage - [Your ID]</name> <category>Office</category> <os>Windows</os> <severity>90</severity> <explanation> A JavaScript based stealer to steal Outlook and Thunderbird credentials. https://blog.sonicwall.com/en-us/2024/06/strelastealer-resurgence-tracking-a-javascript-driven-credential-stealer-targeting-europe/ </explanation> <maliciousCauses>Files associated with the StrelaStealer have been downloaded and executed.</maliciousCauses> <benignCauses>There should be no known beningn causes, since hash collision is very unlikely with SHA256.</benignCauses> <recommendedActions> 1. Review the affected endpoint to see if StrelaStealer associated files were downloaded. 2. If IOCs were found, clear the endpoint of malicious files. 3. Change the credentials of the affected user. </recommendedActions> </description> <definition> <process> <operator type="OR"> <condition component="Module" property="Sha256" condition="is" value="0f069016bc5c9347099589c103c8617e716ad301c3b83b69b5ebd11ef623cf78" /> <condition component="Module" property="Sha256" condition="is" value="a4cd72aea29e992fcdf808370f3a7c9333458535b86c9a11a1fff20299f837e6" /> <condition component="Module" property="Sha256" condition="is" value="f2afca709e2973f2733887e401c903580e1ffe4d4ae6d7ea28cc5a6149ba4b96" /> <condition component="Module" property="Sha256" condition="is" value="2385a4dcf8076eb51ad6893624d36ba49beac92f1e681297afbb89cd5be46c57" /> <condition component="Module" property="Sha256" condition="is" value="b36fee8895bd828a42a166488b4a2574a232726d89153e3e37fe4382020f7800" /> <condition component="Module" property="Sha256" condition="is" value="00e7bdaa8ff895b3b82a0b9cc8ba1971d6401e9cf575ec44a5bc3adc6bfd0771" /> </operator> </process> <operations> <operation type="TcpIpConnect"> <condition component="Network" property="DestinationIpAddressV4" condition="is" value="45.9.74.176" /> </operation> </operations> </definition> <maliciousTarget name="current" /> <actions> <action name="TriggerDetection" /> <action name="StoreEvent" /> <action name="KillProcess" /> <action name="BlockProcessExecutable" /> <action name="BlockProcessSuspiciousModules" /> <action name="ReportIncident" aggregateOn="Computers" /> <action name="SubmitToLiveGuard" /> </actions> </rule>
thae 14 Posted July 9 Author Posted July 9 (edited) Another rule for an IOC of GrimResource: <?xml version="1.0" encoding="utf-8"?> <rule> <description> <name>IOCs of GrimResource Usage - [Your ID]</name> <category>Suspicious Process Creation and Process Manipulation</category> <os>Windows</os> <severity>90</severity> <explanation> Execution of arbitrary code in Microsoft Management Console https://www.elastic.co/security-labs/grimresource </explanation> <maliciousCauses>Malicious .msc file tries to exploit an XSS flaw in the apds.dll library to achieve arbitrary code execution.</maliciousCauses> <benignCauses>There should be no known beningn causes.</benignCauses> <recommendedActions> 1. Review the affected endpoint to see if an unknown .msc file was downloaded and executed. 2. If IOCs were found, clear the endpoint of malicious files. </recommendedActions> </description> <definition> <process> <condition component="FileItem" property="FileName" condition="is" value="mmc.exe" /> </process> <operations> <operation type="CreateProcess"> <condition component="FileItem" property="FileName" condition="is" value="apds.dll" /> </operation> </operations> </definition> <maliciousTarget name="current" /> <actions> <action name="TriggerDetection" /> <action name="StoreEvent" /> <action name="KillProcess" /> <action name="BlockProcessExecutable" /> <action name="BlockProcessSuspiciousModules" /> <action name="ReportIncident" aggregateOn="Computers" /> <action name="SubmitToLiveGuard" /> </actions> </rule> Edited July 9 by thae
ESET Staff j91321 8 Posted July 21 ESET Staff Posted July 21 Hi, thanks for the rule ideas, really appreciate the effort! The rules like the one for StrelaStealer have a very limited lifetime as AV component usually gets these updates much faster and even if not, I'd recommend using "Blocked Hashes" functionality for this use case. For the second rule, did you actually test it on the samples mentioned in the blog post? It's been in my backlog for a while. I wanted to reproduce it to make sure we register the apds.dll correctly as is mentioned in the blog post.
thae 14 Posted July 22 Author Posted July 22 21 hours ago, j91321 said: Hi, thanks for the rule ideas, really appreciate the effort! The rules like the one for StrelaStealer have a very limited lifetime as AV component usually gets these updates much faster and even if not, I'd recommend using "Blocked Hashes" functionality for this use case. For the second rule, did you actually test it on the samples mentioned in the blog post? It's been in my backlog for a while. I wanted to reproduce it to make sure we register the apds.dll correctly as is mentioned in the blog post. Hey! I'll look into the Blocked Hashes function, thanks! These two rules are NOT tested. I don't have the setup and the time for it. I just like to do some of my own rules when I have some time. I'll include it so everyone can see that it's not tested. I know it'd be bad to trust this rule when it's not tested, but better than nothing. If someone has the setup and time he can go for it and use this as a starting point.
Recommended Posts