[debug]

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
OldSpoiler (Click to View)




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

Change Log
v1.0.0.1

• 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.
  

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

[Business Crypt]

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.

[debug]

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.

Correct. And If there are 5 or greater mismatches, it's flagged.
I will probably later turn this into more general Anti-Malware program, but for now, wiping out runpe's takes care of alot. ;)

[ucsandaasu]

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

mate , this is insane! thank you alot and keep it up

[Cecilia]

Eh yours is less advanced than mine, but you have done a good job in making it available to everyone ;)

[log dot zip]

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.

[Only3]

u can use async event https://msdn.microsoft.com/en-us/library....100).ASPx
properties https://msdn.microsoft.com/en-us/library...s.85).aspx
or simply loop the process anyway theres better and simple ways to do it

[debug]

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.

thanks!

u can use async event https://msdn.microsoft.com/en-us/library....100).ASPx
properties https://msdn.microsoft.com/en-us/library...s.85).aspx
or simply loop the process anyway theres better and simple ways to do it

Yes, I plan to move away from WMI. See: todo.

---

---

Updated with significant improvements. See changelog.

[Wardow]

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

[debug]

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

I'm sure you can bypass it Wardow, but for 99% of the malware skiddies, this will work just fine.

[The-One]

I'm sure you can bypass it Wardow, but for 99% of the malware skiddies, this will work just fine.

In C# one can easily install EasyHook and write a simple hook for ReadProcessMemory to redirect your calls to ReadProcessMemory and return invalid information.

[Wardow]

In C# one can easily install EasyHook and write a simple hook for ReadProcessMemory to redirect your calls to ReadProcessMemory and return invalid information.

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

[The-One]

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

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?

[Wardow]

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?

"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.

[The-One]

"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.

Okay, I get that hooking is universal and that is doesn't affect the integrity but still; why would I write loads of code when I could apply a simple rpm hook, just out of curiosity?