Spoiler (Click to View)

• Move away from WMI; it's slow.
  


• Monitor all processes, existing and new. Do so by scanning existing processes first and log their PID's. Run a constant thread to search for new processes by PID by referencing the PID list.
  


• Clear closed processes from PID list every so often.
  


• Handle processes protected by security access control.
  


• Handle persistence.
  

• Removed WMI method. Looping all processes now.
  


• Scans all currently running 32-bit processes at the start, and continues to scan.
  


• Improved speed of detection.
  


• Remove old processes from active list
  


• Added documentation.
  


• Color coded log.
  

(Dec 1, 2015 06:29 PM)Business Crypt Wrote:  Hi DeBuG :^)

Glad to see you've moved onto something worthwhile.

So if I gather correctly - you're scanning for mismatching fields from the PE on disk and the PE in memory? I believe DarkCoderSC's tool does the same thing.

Nice work, it's a clever idea. I can think of at least a couple problems this could run into off the top of my head. Nonetheless, cool.

(Dec 1, 2015 05:53 PM)debug Wrote:  Summary
I created this project to detect malware executed by RunPE's.
This is a work in progress, no where near its final stage. That being said, it's probably very buggy, so use with caution.

In Action


Notes
In the gif you can see that the first crypted.exe process is declared as clean, as it is not a process created by a runPE. But if it uses a runPE to create a new process, it will kill both processes.

TODO

• Move away from WMI; it's slow.
  


• Monitor all processes, existing and new. Do so by scanning existing processes first and log their PID's. Run a constant thread to search for new processes by PID by referencing the PID list.
  


• Clear closed processes from PID list every so often.
  


• Handle processes protected by security access control.
  


• Handle persistence.
  

Source
Github: https://github.com/debug-hf/RunPE-Shield

Credits
Almost all credits go to BahNahNah for his PEToolKit.
I modified his code to work in this fashion, so shout out to him for most of the hard work.

If you find any bugs or have any suggestions let me know. I think this will be a fun project to work on.

Hope you like it!
-debug

beat you to it Lapan, suck it

(Dec 2, 2015 09:03 AM)codeconfusion Wrote:  Finally someone who isn't showing off generic shit malware. Cool idea - reminds me of this demonstration, by Malwarebytes:





I'm guessing they're using the same basic flagging principle.

+rep for not being a shitter.

(Dec 2, 2015 09:46 AM)Only3 Wrote:  u can use async event https://msdn.microsoft.com/en-us/library/system.management.managementeventwatcher.stop(v=vs.100).ASPx
properties https://msdn.microsoft.com/en-us/library/windows/desktop/aa394372(v=vs.85).aspx
or simply loop the process anyway theres better and simple ways to do it

(Jun 10, 2016 09:41 AM)Wardow Wrote:  Many ways to bypass this, I can leave the original PE loaded or, remap it to another place and make so the first module base address points to it, then create another row to the module list with the same info as the first one and use my new base address and patch the program base address in the PEB with that one too, this way your program checks the original application against the disk copy and does not detect anything

(Jun 10, 2016 10:27 AM)debug Wrote:  I'm sure you can bypass it Wardow, but for 99% of the malware skiddies, this will work just fine.

(Jun 10, 2016 11:42 AM)The-One Wrote:  In C# one can easily install EasyHook and write a simple hook for ReadProcessMemory to redirect your calls to ReadProcessMemory and return invalid information.

(Jun 11, 2016 04:39 AM)Wardow Wrote:  Not the subject, nor the point, anyone can get over anything using hooking, it's all about integrity level, if you have a driver you can even do that on Anti-Viruses, again, not the point

(Jun 13, 2016 02:24 AM)The-One Wrote:  But that is the point I wanted to make; I tried to explain that this tool could easily be fooled and one shouldn't rely on it. Also, whats wrong with hooking? Why should I want to write something that remaps my assembly or messes with the PEB while I can easily hook rpm?

(Jun 13, 2016 06:27 AM)Wardow Wrote:  "Hooking" is universal,
When hooking is only way to bypass you can consider it secure; as is, integrity is what will stop your program from operating, so get it higher when you run it.