Real time detecting of mutex objects

wouldn’t that be enough to scan object manager directories with ZwOpenDirectoryObject and friends and check for existence of the name you interested in ?

that is a good approach, the key question is when during the execution to do it? since i have a bunch of callback notifications, and a minifilter at what point should the query occur? if we knew a mutex was being created we could query the dirobj at that point, since that does not exists in a documented fashion, its leaves the question open of when to do it. any insights on that is appreciated.

as an additional thought, deciding which directory to query is critical since its inefficient to have multiple queries of all directories.

also I’m not searching for specific mutex names, so a name search is not usable here, but searching for teh existence of any mutex object is.

Actually, I like the way how the malware generates mutex names based on product ID >:) It is creative.

also I’m not searching for specific mutex names, so a name search is not usable here, but searching for teh existence of any mutex object is.
OK but you should take into account creating named mutexes is something not specific to malware and any software can do it for honest reasons. I probably never used mutexes this way but I used named events. They can be used by malware the same way.

You can search object space periodically and detect changes against previous state. For example once per minute, 10 minutes or or. Still I’m not sure what do you want to do with it. Alert! Somebody created named mutex! What is user expected to do then?

thanks michal, I save all these execution events to a log file resulting in a large data set for win exe malware on virushsare.com teh data set is meant for researchers, adding mutex is, in my opinion, important for malware defense research. Periodic checks of obj space is good and the thread would benefit hearing other approaches as well, hope others provide.

For logging and research it looks OK. But there should be no need for real time approach, maybe not even for periodic checks, just scan and create log.

The whole notion that malware trolls are conscientious enough to do ANYTHING to avoid multiple infections is totally laughable. “Well, sure, he mugged me, but at least he was polite.”

Im thinking in my minifilter i can check for directory access adn query that object, i can relate pids to those im interested in.

it would be nice if ObCallbacks notified for mutex objects, as far as i know, they don’t.

would be nice if ObCallbacks notified for mutex objects

Nope. As we’ve said, I think, several times by now, they do not.

I apologize, but I find this whole notion laughable. Singling out Mutex objects is, from my limited point of view as a mere kernel dev and not any sort of security or malware researcher, simply ridiculous. These are not the only objects that can be named. So, why choose Mutex for special treatment? Asking for and/or expecting a callback for the instantiation of a simple kernel synchronization primitive is foolish. The callback can create more overhead overhead than the instantiation… for something that might be done frequently.

OK… I realize my editorializing on this has no real point behind satisfying myself.

Peter

1 Like

Very challenging indeed!

You want to know as and when a mutex gets created, then perhaps search
agains known hash for the name ??

It’s more like coming up with a debugger module that will insert exceptions
to interesting places, handle the exception!!!

Pro

I think that we can safely decide that this is the most ridiculous objective of the year - with half of the year ahead.

Because this is both totally useless in the objectives and so impractical in the proposed means it is outlandish enough to qualify as one of the most ridiculous things I have ever heard proposed.

To the OP, it is certainly possible that you have a legitimate objective, and I am sure that if you do, and can articulate it, me and the rest of the community will certainly try to help you. But the problem is that as stated you can’t achieve anything with this approach i think

The whole notion that malware trolls are conscientious enough to do ANYTHING to avoid multiple infections is totally laughable.

What about the scenario when two separate instances of the same malware “title” are potentially getting at odds with one another, effectively rendering one another unfunctional (in a sense that they are both unable to exercise their intended malicious functionalities)?
In this particular case malware writers may,indeed, want to avoid multiple reinfections, and the purpose of the whole exercise is protecting the malware itself, rather than the target machine/OS installation that it attempts to subvert. It never occurred to you to think this way, by any chance?

Anton Bassov

Again, I am amused to no end that anyone thinks these bastards expend any energy at all worrying about how their software fits into a malware “ecosystem”.

Wow, trying to complete a project, makes someone ?astered. and it is already won the prize for the most ridiculous post of the year…

This is the slippery slop or fools paradise… Go to any credible security company and find out what kinda hack the do to support as much as they can for APT. And ask them what and how they handle those things…

From OS, protocol, device nothing is as safe as we wish to think. So people trying to do whatever they can … Otherwise we will all have to soak our systems in salt water for a day, then give to recycling …

pro

Any credible hacker worth a salt never going to ask a question as straight as this one !
Pro

Again, I am amused to no end that anyone thinks these bastards expend any energy at all worrying about how their software
fits into a malware “ecosystem”.

I am speaking not about an “ecosystem” (i.e. different malware “titles” peacefully coexisting on the same machine") but about the scenario when two separate instances of the same “title” are installed on it.

I know you may get surprised to no end, but If you don’t mind “expending your energy” on writing a program you may, probably, want to “expend some energy” on making it work, at least from time to time,as well. Taking into account the malicious nature of the program in question, in this particular case it may mean taking some steps to avoid the detection and/or removal.

Another point to consider is that two separate instances of the same malware “title” that are installed on the target machine are going to compete for exactly the same resources. Taking,again, into account the malicious nature of the program in question and its lack of concern for anybody else, this may result in some “funny” situations (like, for example, the instance A removing a hook installed by the instance B, and vice versa, effectively resulting in a ridiculous scenario of a malware rendering itself harmless by its own actions).

In order to avoid this unfortunate (from the malware writer’s perspective,of course), scenario, they may want to avoid installing multiple instances of it on the same machine

Anton Bassov

If I scanned and remember the linked report correctly, I think the malware is using the named mutex to store some information… so not necessarily as a serialization primitive?

Regardless…

Peter

I think the malware is using the named mutex to store some information… so not necessarily as a serialization primitive?

At this point, the original question that Marion branded as “the most ridiculous post of the year - with half of the year ahead” starts,once it a sudden, making a perfect sense . If mutexes are used this way quite a few of them may potentially be required to store all the info, right. Therefore, if you notice the surge of named mutex creation once it a sudden, it may, indeed, raise some suspicions.Certainly, it is not up to a driver to decide upon anything, but logging mutex creation events for the subsequent analysis may be, reasonable indeed…

Anton Bassov