Didier Stevens

I’ve seen reports that WannaCry uses a mutex with name Global\MsWinZonesCacheCounterMutexA.

The samples I analyzed all use another mutex: Global\MsWinZonesCacheCounterMutexA0. That’s a digit zero at the end.

I have not found a sample that uses mutex Global\MsWinZonesCacheCounterMutexA (e.g. without digit zero at the end).

Update 1: I got confirmation from Costin Raiu from Kaspersky that the mutex is Global\MsWinZonesCacheCounterMutexA0.

Update 2: dynamic analysis with sample 84c82835a5d21bbcf75a61706d8ab549 shows that there are 2 mutexes that can prevent the ransoming of files: MsWinZonesCacheCounterMutexA and Global\MsWinZonesCacheCounterMutexA0. Remark that the Global namespace must be used with mutex MsWinZonesCacheCounterMutexA0, while it may not be used with mutex MsWinZonesCacheCounterMutexA.

Remark that the code above contains string “Global\\MsWinZonesCacheCounterMutexA”, but that is not the actual string used for OpenMutexA.

The actual string used for OpenMutexA is created by a sprintf “%s%d” call, and results in “Global\\MsWinZonesCacheCounterMutexA0“, that is “Global\\MsWinZonesCacheCounterMutexA” with a digit 0 (zero) appended.

Mutexes have long been used by malware authors to prevent more than one instance of the malware running on the same machine. An old anti-malware trick consists in the creation of a specific mutex, to prevent the execution of a specific malware.

I’ve seen tools and scripts published to create mutex Global\MsWinZonesCacheCounterMutexA to prevent WannaCry from infecting machines. This will not work for the samples I analyzed.

Samples I disassembled:

7c465ea7bcccf4f94147add808f24629644be11c0ba4823f16e8c19e0090f0ff (contained as a resource in 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec).

86721e64ffbd69aa6944b9672bcabb6d (contained as a resource in 5bef35496fcbdbe841c82f4d1ab8b7c2).

Samples I searched for containing the mutex and sprintf code:

509c41ec97bb81b0567b059aa2f50fe8
5bef35496fcbdbe841c82f4d1ab8b7c2
638f9235d038a0a001d5ea7f5c5dc4ae
7f7ccaa16fb15eb1c7399d422f8363e8
84c82835a5d21bbcf75a61706d8ab549
86721e64ffbd69aa6944b9672bcabb6d
d6114ba5f10ad67a4131ab72531f02da
db349b97c37d22f5ea1d1841e3c89eb4
f107a717f76f4f910ae9cb4dc5290594

If you have a sample that actually uses mutex Global\\MsWinZonesCacheCounterMutexA and not mutex Global\\MsWinZonesCacheCounterMutexA0 (e.g. with digit zero appended), please post a comment with the hash of your sample.

Quickpost info

It looks like #WannaCry’s killswitch check (www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com) is not proxy aware:

Organizations that use proxies will not benefit from the killswitch.

Sample: 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec

I have not tested this in a VM. If someone has, please post a comment with your findings.

Update: I did test the sample, it is not proxy aware. In an environment with an HTTP proxy and no direct connections to the Internet, the sample can not connect to www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com, and it will infect the host.

If I patch the sample to make it proxy aware, it can connect to the site through the proxy, and it does not infect the host.

Quickpost info