Changes with Raccine 1.0 BETA

[Neo23x0]

To inform you on the changes made with the merge of the yara-matching branch and John's GUI into master.

• The Raccine GUI is now a subfolder of the main project
• The installer uses %ProgramFiles% for the executables and %ProgramData% for logs and yara rules (and temp files of the YARA scanning process)
• The installer extends the PATH variable
• The installer adds RaccineSettings.exe to the Run key
• The installer starts RaccineSettings.exe
• The installer has a new option 4 to deactivate the GUI (kills process, removes startup entry, sets Registry key ShowGui to 0 so that Raccine.exe don't trigger an alert window anymore)
• yara64.exe is a new executable in the %ProgramFiles%\Raccine folder (in PATH)

FYI @JohnLaTwC @Eran-YT @Omodaka9375

Commit https://github.com/Neo23x0/Raccine/commit/cf3790cd9e25c80db7a61fed362948de8471bcf0

[Omodaka9375]

Another option that I personally would like Raccine to have is the ability to take a memory dump of the process that has been detected.

This implementation would blow out the scope of the Raccine at this point and add a lot more code to it. Instead, I made a separate script that can be easily converted to binary and just copied with the raccine.exe during installation.

https://github.com/Omodaka9375/Dumper/

Dumper downloads procdump sysinternals files(on the first start only), suspends the PID passed to it as an argument, and makes a memory dump file for the given PID. Then depending if the --kill parameter is passed it resumes or terminates the process.

There are some benefits to offloading the dumping (and/or killing) process from Raccine, but it depends if it matches with the vision and scope of this project.

Raccine can just pass the PID to dumper.exe and he will take care of it. It can be easily extended to cover other handles like crash dumps etc.

Any thoughts on the approach? @Neo23x0

[Eran-YT]

Another option that I personally would like Raccine to have is the ability to take a memory dump of the process that has been detected.

This implementation would blow out the scope of the Raccine at this point and add a lot more code to it. Instead, I made a separate script that can be easily converted to binary and just copied with the raccine.exe during installation.

https://github.com/Omodaka9375/Dumper/

Dumper downloads procdump sysinternals files(on the first start only), suspends the PID passed to it as an argument, and makes a memory dump file for the given PID. Then depending if the --kill parameter is passed it resumes or terminates the process.

There are some benefits to offloading the dumping (and/or killing) process from Raccine, but it depends if it matches with the vision and scope of this project.

Raccine can just pass the PID to dumper.exe and he will take care of it. It can be easily extended to cover other handles like crash dumps etc.

Any thoughts on the approach? @Neo23x0

The code to create a minidump of a process isn't large, see here

[Omodaka9375]

As I said it depends on what you want to do with it. I prefer full dumps and capturing crashed ones too and other noonce info we get from it for forensics. Handling threads and heavy lifting should not be coupled with the Raccine in my opinion.

[JohnLaTwC]

Can you say how you'd like to use this in detection? Currently Raccine intercepts windows processes like wmic/vssadmin/powershell. Its interception technique as a debugger means these processes have not started yet, so there's nothing malicious in their address space yet except what will be passed in via the command line, which raccine already allows yara rules on.

If you are suggesting to collect dumps when it decides to terminate parent processes (i.e. to find and kill the malicious program abusing these programs), then yes one of those could be valuable to collect a memory dump on.

[Omodaka9375]

Yes, collecting dumps when it decides to terminate a process was my intent here. But only if the user selects it as an option in the menu.

[Omodaka9375]

Just for some reference.... since I understand we are all coming from different angles here.

I'm familiar how Raccine works. I implemented the PowerShell IEFO debugger and had a heuristic approach in mind, especially regarding obfuscation.

@Neo23x0 and I agreed to leave some complicated ones for Yara implementation. Check out: https://github.com/Neo23x0/Raccine/issues/38

There was a 'detected' status in the logs when I first wrote it, with the idea to dump any process that triggers powershell or bcdedit for example. This is because Raccine will still leak and let in a lot of special cases. At that time, I would like to be able to capture a memory dump of not only definitely malicious, but also suspicious processes. Big potential for providing valuable data to be learned from.

I want to use Raccine in an environment where I can safely expose it to many different strains and families and collect the data. Basically, Ransomware honeypot with Raccine running in the back.

So for me first step would be just implementing procdumping when it decides to terminate parent processes, but later on it can collect data for further study.

[JohnLaTwC]

It would be pretty straightforward to have an (off by default) approach where when Raccine decides to terminate processes it:

1. does a first pass on bad processes to suspend all their threads (stopping them in their tracks)
2. does a second pass writing dump files using the MiniDumpWriteDump (which could take many seconds to complete). Even though the name says 'mini dump' in this API, it takes a param which can be a combination of these values. The exact param could have a default but be configurable by registry key. https://docs.microsoft.com/en-us/windows/win32/api/minidumpapiset/ne-minidumpapiset-minidump_type
3. Runs yara rules against the dump files and logs those events.

   BOOL MiniDumpWriteDump(
   HANDLE                            hProcess,
   DWORD                             ProcessId,
   HANDLE                            hFile,
   MINIDUMP_TYPE                     DumpType,
   PMINIDUMP_EXCEPTION_INFORMATION   ExceptionParam,
   PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
   PMINIDUMP_CALLBACK_INFORMATION    CallbackParam
   );

[Neo23x0]

Hi, the idea itself isn't a bad idea. However, I'd like to focus the use of Raccine on a target group of users that hasn't the budget and team to manage EDRs and this very target group usually also doesn't have someone that is able to analyze process memory dumps.

And process memory dumping can be problematic. We've just recently tested a new feature in THOR that dumps process memory of processes with YARA rule matches or PE-Sieve detections on them. Since we run THOR on more than 100.000 systems with close contact to customers, we could experience some issues that could be problematic in the field. Some of the dumper processes had huge sizes and some of the disks drives had only little of free disk space left. We didn't experience both situations together, but they made us more cautious.

You can argue that we'd make that feature optional and set it to disabled by default. In this case, we would still have to provide test coverage, support it in case of problems and add some code complexity.

What I'd possibly agree to, would be a generic "action" that could be a custom action run at each detection and executed with cmd.exe /c.

We would make some variables available to that command, like %ImageFile% or %PID%, so that users could add e.g. procdump.exe to a folder and then configure an action that is

• procdump -ma %PID% or
• copy %ParentImageFile% \\server\share1 or
• netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound to block all incoming and outgoing traffic.

We could set that command in a Registry key.

[Neo23x0]

Runs yara rules against the dump files and logs those events.

I wouldn't run YARA against the dumped process memories on disk but directly against their process memory using the PIDs, as described in https://github.com/Neo23x0/Raccine/issues/58

[Omodaka9375]

Agreed.