An .iso file downloaded from the Internet (thus with a Zone.Identifier ADS) opened in Windows 10 will not propagate this “mark-of-the-web” to the contained files.
Here is an example with file demo.iso, marked as downloaded from the Internet:
When this file is opened (double-clicked), it is mounted as a drive (E: in this example), and we see the content (a Word document: demo.docx):
This file is not marked as downloaded from the Internet:
Word does not open it in Protected View:
Searching through VirusTotal Intelligence, I found a couple of .iso files (CD & DVD images) containing a malicious EXE spammed via email like this one. Here is the attached .iso file (from May 25th 2017) on VirusTotal, with name “REQUEST FOR QUOTATION,DOC.iso”.
Recent versions of Windows will open ISO files like a folder, and give you access to the contained files.
I found Python library isoparser to help me analyze .iso files.
Here is how I use it interactively to look into the ISO file. I create an iso object from an .iso file, and then I list the children of the root object:
The root folder contains one file: DIALOG42.EXE.
Looking into the content of file DIALOG42.EXE, I see the header is MZ (very likely a PE file):
And I can also retrieve all the content to calculate the MD5 hash:
This is a quick & dirty Python script to dump the first file in an ISO image to stdout:
import isoparser
import sys
import os
oIsoparser = isoparser.parse(sys.argv[1])
if sys.platform == 'win32':
import msvcrt
msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
sys.stdout.write(oIsoparser.root.children[0].content)
This allows me to pipe the content into other programs, like pecheck.py:
Here is a great tip from @PintAndClick: you can pipe the output of sigtool –find-sigs into sigtool –decode-sigs to get a nice breakdown of the signatures:
My previous blog post “Analyzing ClamAV Signatures” is incorrect. Here is a better explanation.
I wrongly assumed that the signature printed in the debug statement would be the actual signature in the ClamAV database. That is not always the case.
So here is a better method.
First I update the signatures (yup, that’s ClamAV on Windows):
This is a standard scan:
The signature is Win.Trojan.Mimikatz-6331391-0.
Then I do a search with sigtool in the database, providing a regular expression (Mimikatz-6331391) to match signature names (this matching process is case sensitive):
And this signature is more interesting. This is an extended signature. It is composed of several fields (: is the separator). Here I have each field on a separate line:
Field 1 is the name of the signature.
Field 2 is the type of file to scan: 1 is for PE files
Field 3 is the part of the file to scan: SE1 is the second section of the PE file.
Field 4 is the hex signature: the sequence of bytes to search for in the section, expressed as hexadecimal data. {-10} is a wildcard for 0 to 10 arbitrary bytes.
Field 5 is the minimum version of the ClamAV engine that supports this type of signature.
The bytes represent strings (UNICODE and ASCII):
This signature does not trigger on the genuine mimikatz binaries:
While updating my Petya/Notpetya notes, I saw that ClamAV now detects resources 1 and 2 (zlib compressed PE files) as Mimikatz. Curious about how they detect Mimikatz, I wanted to take a look at the signature. I’ve done this before, but I forgot exactly how. So here is a blog post to remind me next time.
First I update the signatures (yup, that’s ClamAV on Windows):
This is a standard scan:
The signature is Win.Trojan.Mimikatz-6331391-0.
Then I do a scan with option –debug, this will print out the signature:
The signature is: 2813d34f6197eb4df42c886ec7f234a1:47616:Win.Trojan.Mimikatz-6331391-0
I hoped for something more interesting: this is an MD5 hash-based signature. 2813d34f6197eb4df42c886ec7f234a1 is the MD5 hash of the file, 47616 is its file size, and Win.Trojan.Mimikatz-6331391-0 is the signature name.
Years ago I wrote a C program to create a new process with a chosen parent process: selectmyparent. And recently I showed what process monitor and system monitor report when you use this tool.
Starting a new process with a chosen parent process can be done from VBA too, as shown in this video (I’m not sharing the VBA code):
I can’t help feeling some kind of satisfaction when a friend uses my tools to analyze malware, and hacks his way to a solution when my tool falls short 🙂
In this nice blogpost, @bluejay00 analyzes RTF malware with my rtfdump.py tool. But because of obfuscation, rtfdump.py is not able to extract the object. @bluejay00 understands this, deobfuscates the RTF sample with an editor, and is then able to get my tool to work correctly.
I’ll just show how I would have used my translate.py tool to remove the obfuscation:
In this video, I show how to get started with my tools and a WannaCry sample.
Tools: pecheck.py, zipdump.py, strings.py
Sample: 84c82835a5d21bbcf75a61706d8ab549
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.
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.
