I know malware often uses a mutex to prevent reinfection, and scanning for them can be helpful.
However, I have a question after debugging my first malware sample. I'm wondering what, if anything, is stopping malware authors from generating mutexes based on data from the host it is infecting (computer name, MAC address, install date, etc.) and then using that hash as a mutex to interfere with mutex scanning.
I know malware often uses a mutex to prevent reinfection, and scanning for them can be helpful.
However, I have a question after debugging my first malware sample. I'm wondering what, if anything, is stopping malware authors from generating mutexes based on data from the host it is infecting (computer name, MAC address, install date, etc.) and then using that hash as a mutex to interfere with mutex scanning.
Nothing.
Welp, I should of searched more because I just found a site that says Conficker does exactly that. Thanks…
Thread can be deleted.
Can you provide a link to that site?
Also, a while back, I wrote a Perl script called "handle.pl". In short, it took the output of "handle -a" (handle.exe being from MS/SysInternals) and parsed through it looking for mutants/mutexes. It then listed them by order of occurrence, starting with 1…in short, performing LFO analysis.
At initialization, it checks for the presence of three mutex values on the target host to avoid reinfection. If absent, these three mutexes are created 1) the mutex name "Global\<string>-7"; 2) the mutex name "Global\<string>-99; and 3) a mutex named pseudo-randomly generated based on the process ID. The <string> in the first two mutex is unique per computer name; it is calculated based on the crc32 hash of the computer name and XOR'ed with a constant. C then installs several in-memory patches to DLLs, and embeds other mechanisms to thwart security applications that would otherwise detect its presence.
http//
hi.baidu.com/harite/blog/item/0768bb358679bd83a61e1286.html
Yup, I remember that post using handle on your blog. )