MalwareBytes internals (incomplete)
This write up won't be nearly as technical or in-depth as I'd like. Initially when I decided to begin poking MalwareBytes with a stick my reasoning was pure curiosity. I don't have any reason really to try to reverse engineer MalwareBytes.
I initially played with the idea of developing a proof-of-concept malware payload which would be custom tailored to MalwareBytes evasion. As you'll see as you read this I've found some potential attack vectors. However, as time progressed I kind of just got bored with reversing MalwareBytes. I found some really cool stuff, I have an appreciation for MalwareBytes (and anti-malware products in general, actually), but I no longer possess the motivation to continue reviewing it.
I hope by sharing this you'll decide to review it yourself, or maybe you'll appreciate what I've written, or maybe you'll feel more compelled than I am to try to develop a custom malware payload for it.... or maybe you won't do any of this and you'll look at cat pictures on the internet. That is cool too.
I'd also like to note I have not reviewed MalwareBytes in totality. It is a big application with lots of moving parts. I don't want to spend the next three weeks poking this thing with a stick.
MalwareBytes has a bunch of programs. It has a bunch of DLLs. Some of the DLLs are from MalwareBytes (they're signed), some DLLs are external libraries it's dependent on (such as 7z DLLs, or Microsoft.NET DLLs). These DLLs are there to ensure they're not missing from the machine. Their presence isn't really indicative anything. It does however illustrate MalwareBytes needs 7z for stuff.
The main MalwareBytes executable (the one you see when you actually run the program) is written using the .NET framework. I am going to faithfully assume it is C#.NET, I'm skeptical they would use VB.NET. Regardless, when using ILspy it all turns into the same thing, so whatever.
The main MalwareBytes executable is a .NET loader which then loads the actual MalwareBytes UI, and all the fancy bells and whistles. It is MalwareBytes.dll.
tl;dr MalwareBytes.exe is just a loader for MalwareBytes.dll.
MalwareBytes.exe
└── CLR startup
└── Load Assembly("MalwareBytes.dll")
└── Invoke Main()This isn't uncommon. Microsoft has a whole thing on it here: https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting
As you can see, it's a big ol' son-of-a-gun. It has a lot of moving parts. Most of it revolves around the UI, the remaining is interoperability with the low-level components which actually do the anti-malware stuff.
Funnily enough however, inside of these binaries (Mbam.UI.Data) contains the .NET code responsible for communicating with a database on the machine which contains user-mode settings and some other stuff. When you peek inside of that file you find the hardcoded password to the user-mode database located in %LOCALAPPDATA%
It is very silly. "VGhhbmtZb3VGb3JDaG9vc2luZ01hbHdhcmVieXRlcw" is Base64 encoded. When decoded is transforms into "ThankYouForChoosingMalwarebytes". That is a very cute Easter egg.
data.db, located in %LOCALAPPDATA% can viewed regularly using DB Browser (SQLCipher). This is required because this is password protected and requires authentication.
This is another standard user-mode database. This database stores user-mode configurations, alerts, blah blah blah. It should be noted however that, because the password is hardcoded, there is a potential abuse vector present. Security researcher miltinhoc noted it is possible to change the password to data.db. When the password to the database is modified the entire application implodes into itself. Neat.
The actual detection logic for MalwareBytes comes from it's kernel-mode components. It has a few. The main one is mbam.sys. mbam.sys (MalwareBytes Anti-Malware?) is their minifilter which does some heavy lifting for detecting malware. They have a bunch of other kernel-mode minifilters (as you can see from the attached link). I have not really dug into those yet. I didn't even have most of those present on my virtual machine. Some of those kernel-mode components are probably from other products, maybe, I don't know.
mbam.sys communicates, in some capacity I still haven't identified, with a proprietary data format MalwareBytes uses. All of their malware detection logic (YARA rules, or whatever) is stored inside of %PROGRAMDATA%\Malwarebytes\MBAMService\rules.mbdb
I am going to take an educated guess that "mbdb" stands for MalwareBytes Database.
I began attempting to reverse engineer their mbdb file format, but I began screaming and throwing things out my window. I dislike reverse engineering custom file formats. It is the work of the devil (I'm being hyperbolic for comedic effect, relax).
Their mbdb is "delimited" (using that word extremely liberally) with special characters (in actuality hex). It is "o|". It acts as the root identifier for their database. I unironically began using AI slop to try to figure out what the hell is going on. I wasn't going to spend hour Googling to try to identify patterns in the file.
Using AI slop and janky Python code, I was able to begin making a dent in their custom file format, but it was still too much effort for me.
I was able to carve out 4 different tables (maybe?) but it's got all sorts of stuff going on.
MalwareBytes has invested a lot of time and energy into preserving their intellectual property of malware detection logic (YARA rules, probably). I eventually said, "fuck it, I don't give a shit" and gave up. My goal wasn't to steal their data, so I don't really care too much, but it is incredibly interesting seeing this custom file format.
---WARNING INCOMPLETE NOTES---
Here is my notes I'm saving for later. I briefly wrote about it on X here: https://x.com/vxunderground/status/2012409833614406120.
I still have to poke some stuff with a stick.
Last updated