OSX Kitmos : other binary, other C&C

On May the 20th, Norman has published a report about an Indian cyberattack infrastructure that they call "Hangover" due to information found to the path to a PDB file.
Their blog post also refers to Oslo Freedom Forum attack that I wrote about in my previous article :
"Based on the sample and Command&Control domain mentioned in the F-Secure post, we can say quite conclusively that the Oslo Freedom Forum attack was performed through the same attack infrastructure. We also found another MachO executable apparently written by the same person (same Apple Developer ID), and using another domain in the Hangover infrastructure – torqspot.org."

As this domain was present in another Mach-O binary that I have, I have chose to take a quick look at it.

File informations

SHA1 hash : b6a47d52de64af50a5a1415213e60dc1b076b4e7
File type : Mach-O executable i386
VirusTotal report : https://www.virustotal.com/en/file/a74196018b2854765333a8f798b0ae3f3b71c89ec9632188f07c71d055125cb2/analysis/

C&C information

This sample uses "torqspot.org" as C&C domain name. Whois reveals still fake information :

Domain ID:D168171472-LROR
Domain Name:TORQSPOT.ORG
Created On:16-Mar-2013 05:28:07 UTC
Last Updated On:16-May-2013 03:45:16 UTC
Expiration Date:16-Mar-2014 05:28:07 UTC
Sponsoring Registrar:PDR Ltd. d/b/a PublicDomainRegistry.com (R27-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:DI_25590875
Registrant Name:Melissa Leo
Registrant Street1:E-5 cecill street
Registrant Street2:Manchester
Registrant City:Manchester
Registrant State/Province:Manchester(Cityof)
Registrant Postal Code:M14LF
Registrant Country:GB
Registrant Phone:+044.7251868
Registrant Email:leo.melissa@mail.ru

C&C is not responding anymore.

IOC

All logged messages can be used to identify a compromised macintosh. For example, the following messages can be used as IOC :

- "http://torqspot.org/App/MacADV/up.php?cname=%@&file=%@"
- "CONTACTS mreslt %@"
- "CONTACTS urlResponse  %d"
- "responseData: %@"
- "http://torqspot.org/App/MacADV/$hostname/$serverResponse"
- "/Applications"
- "End"
- "app path =%@"
- " exec path =%@"
- "file: %@"
- "connected to upload server %@"
- "Fail connected to upload server %@, begin in %d sec"
- "Try zip and upload for failed file, before."
- "ComputerName_UserName : %@"
- "Failed retry %@"
- "Retry %@"
- "New seesion"
- "search path from state.dat"
- "search path from root"
- "available paths: %@"
- "No found folder"
- "No found file"
- "Start searching"
- "%ld files found"

DNS resolution to "torqspot.org" and all kind of HTTP requests to this domain can also be used to identify a compromised computer on a network.

Features

Lots of features and functions (coml, cop, runSystemCommand, ...) are similar to previous binary analyzed. Below, only new and interesting will be detailed.

macurl

- send synchronous HTTP request to "http://torqspot.org/App/MacADV/up.php?cname=%@&file=%@" w/ hostname as 1st arg and "no" as 2nd arg
- get data at URL "http://torqspot.org/App/MacADV/$hostname/$serverResponse" w/ dataWithContentsOfURL function, where $serverResponse is the response sent by the server to the previous request
- write downloaded data to file "/Applications/$ServerResponse"
- execute following command :
"/usr/bin/ditto -x -k /Applications/$ServerResponse /Applications/" to extract PKZip archive "/Applications/$ServerResponse" to "/Applications/"
- replace/add ".app" extension to "/Applications/$ServerResponse"
- if path exists, run the executable (NSTask, setLaunchPath, launch)
- create string "http://torqspot.org/App/MacDV/up.php?cname=%@&file=%@&res=%@" w/ arguments : $hostname, $serverResponse and "sucess" (w/ one 'c' :)
- send a request using that string (w/ sendSynchronousRequest:returningResponse:error: method)
- log "file: %@" w/ data answered by the server as argument

initFileBackup

- get bundlePath and add "FileBackup.ini" to it
- use "stringWithContentsOfFile:encoding:error:" function to get content data of config file ("<bundlePath>/FileBackup.ini")
- if file content iss less than 10 characters, go to the end of the function
- extract data between <URL> and </URL> to pass as parameter to setUrl function
- extract data between <EXTENSION> and <EXTENSION> and use it to create an array of strings based on ';' separator
- call setExtArray to initialize an array with extensions stored in "FileBackup.ini" file

before_start_

- get bundlePath and add "state.dat" to it
- if that file exists, read its content and create an array of strings by spliting on "#####" separator. Then use strings in that array as paths
- if the file doesn't exist, path will be set to "/"
- call connectServer/upload of ZipUpload class and run a command similar to this : "/usr/bin/curl -F upload=@ -F pc="

find_

Looking for files based on extension

batch_

Do some stuff and call macurl

deleteState_

Delete file "<bundlePath>/state.dat" if it exists

saveState_

Save a string array to "<bundlePath>/state.dat" by separating strings by "#####". This function is called by find function and the malware terminates.

Refs

https://github.com/gdbinit/fixobjc/blob/master/fixobjc.idc
http://www.f-secure.com/weblog/archives/00002554.html
http://threatpost.com/new-mac-malware-discovered-on-attendee-computer-at-anti-surveillance-workshop/
http://blogs.norman.com/2013/security-research/the-hangover-report
https://www.botnets.fr/index.php/HangOver

OSX Kitmos analysis

On 16th of May, Sean Sullivan has published an article on F-Secure blog about a new Mac OSX malware discovered on the Mac of an African activist by Jacob Appelbaum during an Oslo Freedom Forum workshop.

File information

SHA1 hash : 4395a2da164e09721700815ea3f816cddb9d676e

According to file Unix command, this binary is a Mach-o executable containing x86 and x64 code. VirusTotal repport of this binary can be found here. With a really quick look at the sample, we can see that it is not packed, obfuscated or encrypted.

C&C information

This sample contains two C&C url which in fact are at the moment pointing to the same server at IP 50.116.28.24 (This differs from F-Secure blog post, where IP addresses of both domains where different). This IP address points to Linode hosting company.

A whois on "securitytable.org" reveals these (fake) information :

Domain ID:D168053198-LROR
Domain Name:SECURITYTABLE.ORG
Created On:04-Mar-2013 06:58:36 UTC
Last Updated On:16-May-2013 16:02:07 UTC
Expiration Date:04-Mar-2014 06:58:36 UTC
Sponsoring Registrar:PDR Ltd. d/b/a PublicDomainRegistry.com (R27-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:DI_26714386
Registrant Name:Christopher
Registrant Organization:N/A
Registrant Street1:DE-10387
Registrant Street2:Nairobi
Registrant Street3:
Registrant City:Nairobi
Registrant State/Province:Central
Registrant Postal Code:50563
Registrant Country:KE
Registrant Phone:+254.204973957
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:n.christopher@mail.ru

Whois information of "docsforum.info" domain are similar.

IOC

All logged messages can be used to identify a compromised macintosh. For example, the following messages can be used as IOC :
- " before ==%@"
- "path == %@"
- "path2===%@"
- "Hellooo"
- "Copy successful"
- "Upload response %@"
- "the path =%@"
- "path1 =%@"
- " Error - Statistics file upload failed: "%@""
- " the array value =%@"
- path to $HOME/MacApp
- date in this format : "yy-MM-dd-HH:mm:ss"
- ComputerName_UserName : $hostname-$username"
- "Start file zip : %@"
- "Start file zip : %@"
- "Start file upload : %@"
- "finished zipping file"
- "finished uploading file"
- "file path==%@"

Network traffic can be useful too to identify a compromised Mac on your network. A compromised macintosh, will generate DNS requests to "securitytable.org" and "docsforum.info" domains which, at the time I'm writing these blog post resolves to 50.116.28.24. HTTP requests to "http://securitytable.org/lang.php" and "http://docsforum.info/lang.php" will also reveal the compromission.

Features

sub_1E72

Function "sub_1E72" is responsible of the persistence of this malware. In fact, this function add the malware to the list of items to start at session login.

- get malware bundle path thanks to NSBundle.bundlePath
- call LSSharedFileListCreate with kLSSharedFileListSessionLoginItems as ListType in order to access to the list of applications starting when user logged on
- call LSSharedFileListInsertItemURL to add the path to the malware bundle to the list

PS : The malware is added to startup items of the current user only, if the malware author would like to start is program for all users on the system, he must use kLSSharedFileListGlobalLoginItems list type as LSSharedFileListCreate argument.

More information about this technique can be found here : http://cocoatutorial.grapewave.com/2010/02/creating-andor-removing-a-login-item/

cop

The first time the binary is executed, it copy itself to $HOME/<bundle_name>.app. Then, the sample calls "coml" function with the path to the new place (or its actual place, if it's not his first execution) as parameter. 

The call to "coml" will result of the execution of the following command : "/bin/sh -c open -a $HOME/<bundle_name>.app" (see coml & runSystemCommand below)

coml

Prepare "open -a $arg" NSString for "runSystemCommand" function.

runSystemCommand

Execute "/bin/sh -c $arg".

- create a NSArray via arrayWithObjects method used as command line options for "sh" and containing : "-c" and runSystemCommand argument
- create NSTask and call launchedTaskWithLaunchPath:arguments: method with "/bin/sh" and previous NSArray as argument

uploadRequestFinished

This function log some information like the response string received from the server or the path of the uploaded file. Then, the uploaded file is removed from the file system with a call to removeItemAtPath.

uploadRequestFailed

Log " Error - Statistics file upload failed: "%@"" where %@ is replaced by localizedDescription returned string.

sendRequestToServer

This function is sending hostname of the compromised macintosh to C&C server thanks to an HTTP request to http://docsforum.info/lang.php URL.

- create "http://docsforum.info/lang.php" URL for ASIFormDataRequest
- get hostname via NSProcessInfo.processInfo.hostName
- call stringByReplacingOccurrencesOfString on hostname value to replace '.' by 'p'
- log that new "hostname" string
- add hostname value to the HTTP request as a POST data named "cname" (addPostValue function)
- do the request w/ startAsynchronous

NB : I don't know if this function is called somewhere as I haven't found any xref to this function

getscreenshot

This function is used to take screenshots w/ screencapture Mac OSX binary and save them in $HOME/MacApp directory. Name of the screenshot follow this format : "yy-MM-dd-HH:mm:ss.png". This function is first called inside applicationDidFinishLaunching function. Screenshots are saved every 20 seconds.

- create $HOME/MacApp path (with NSHomeDirectory, stringWithFormat functions)
- this path will be log in Apple System Log via NSLog
- use the shared file manager to play with FS (via NSFileManager.defautlManager)
- check if the path exists (via fileExistsAtPath)
  - If it doesn't exist, create directory with createDirectoryAtPath
- get date string with this format "yy-MM-dd-HH:mm:ss" (via NSDate, NSDateFormatter, setDateFormat, stringFromDate)    // the date format is different from F-secure screenshot. here, use of ':' instead of '/' on F-Secure screenshot
- date is logged (NSLog)
- create string $HOME/MacApp/yy-MM-dd-HH:mm:ss.png
- create a NSTask object to run a program as a subprocess
  - defines the executable path to "/usr/sbin/screencapture" via setLaunchPath
  - arguments are passed to screenshot via setArguments
    /usr/sbin/screencapture -x -T 20 $HOME/MacApp/yy-MM-dd-HH:mm:ss.png : take a screenshot without any sound after a 20 seconds delay and save it to the aforementioned path
  - task is launched via launch method
- to finish, uploadImage function is called

uploadImage

This function is used to upload screenshots to "http://securitytable.org/lang.php"

- create NSUrl object with string "http://securitytable.org/lang.php" and use it to create an ASIFormDataRequest
- create MacApp directory path string and log it (like in getscreenshot function)
- get the hostname of the computer, thanks to "hostname" method of NSProcessInfo object (process information agent of the process)
- check that the path to MacApp folder exists. Go to end of the function if not
- count the number of files/screenshots w/ contentsOfDirectoryAtPath and use count function on the returned string array
- log the number of files/screenshots
- get first file of the list
- log " the array value =%@" where %@ is replaced by the name of the first file
- If ".DS_Store" exists, remove it from the file array
- Loop to take and upload screenshot
  - create NSData with content of each file/screenshot (via initWithContentsOfFile)
  - call ASIFormDataRequest.addPostValue function and set $hostname data to key "cname"
  - second call to addPostValue with key "name" and value : path to the screenshot
  - then call to setData ("setData:withFileName:andContentType:forKey:")
    key : userfile
    content type : image/png
    filename : path to the screenshot
    data : file content (screenshot)
  - upload the file/screenshot
  - call getscreenshot function

Summary

This Mac OSX malware is really simple. It has only few features :
- start at user login
- take screenshot
- upload screenshot

In addition, it is absolutely not stealth as screenshots are saved in $HOME/MacApp directory of the infected user. No advanced malware techniques/features (packing, encryption, obfuscation) have been seen in this sample.

Refs

https://github.com/gdbinit/fixobjc/blob/master/fixobjc.idc
http://www.f-secure.com/weblog/archives/00002554.html
http://threatpost.com/new-mac-malware-discovered-on-attendee-computer-at-anti-surveillance-workshop/

https://www.botnets.fr/index.php/HangOver

Analysis of an APT1 binary

In middle of February, Mandiant has released a huge report about cyber threat from Chinese government. Some of the technical details has been disclosed in Appendix C ("The Malware Arsenal") of their report.

Because of this APT buzz, I decided to take a look on one of the binary mentioned in APT1 report in order to know the level of this cyber threat.

After running a script on around 200 samples from APT1, I decided to analyse the binary which look the most strange. Report on VT can be found here.

According to PeID, this binary is not packed but it has 4 ".upx" sections and the OEP is pointing to the

last ".upx" section which is not a normal behavior. The few functions in the import table, the few strings in the binary and a high entropy in all sections confirm that point, the binary is packed! I thought interesting to take a look on this binary in order to understand and maybe discover the packer used as PeID failed to identify it.

Unpacking

Beginning of the packed code (in last .upx section : 0x8000) contains a lot of junk code. After these useless instructions, a loop is used to modify the code which follow the loop. The code after this loop is used to get addresses of LoadLibrary and GetProcAddress thanks to the ImportTableAddress field of the loaded PE file.

LoadLibrary is then used to load "kernel32.dll" and GetProcAddress to get addresses of the following functions :

GetModuleHandleA, VirtualProtect, GetModuleFileNameA, CreateFileA, GlobalAlloc, GlobalFree, ReadFile, GetFileSize, CloseHandle, CreateSemaphoreA, ReleaseSemaphore, Sleep, WaitForSingleObject, CreateThread

After the resolution of these functions, SizeOfImage in PEB->PEB_LDR_DATA->InLoadOrderModuleList is set to 1000 (previous value was 9000). Then, VirtualProtect is called in order to change access to ImageBase of the binary to PAGE_READWRITE.

Then some strings will be decoded from memory before being used for example to load library "kernel32.dll" again and then resolve addresses of VirtualProtect, VirtualAlloc,VirtualFree. As soon as the string has been used by LoadLibraryA or GetProcAddress, the string is replaced by several 0 in memory. With this kind of protection, the process contains few information in memory, so a dump of the actual process memory will be not really interesting for an analyst.

Then, code jumps to the third section (.upx 0x7000) which do similar stuff. Idem for the second .upx section.

The first .upx at RVA 0x5000 (but the last called, as order is reversed) will do similar stuff than previous sections but as this is the last packed section, these actions should be more interested for the unpacked binary.

In fact, this last .upx section will load all DLL used by the final (unpacked) binary and will resolve addresses of all functions :

kernel32.dll : CreateProcess, GetLongPathNameA, GetTempPathA, Sleep, CloseHandle, GetModuleHandleA, GetCommandLineA, GetModuleFileNameA, GetProcAddress, LoadLibraryA, ExitProcess

LZ32.dll : LZCopy, LZOpenFileA, LZClose

MSVCRT.dll : strstr, strncmp, atoi ...

ADVAPI32.dll : RegSetValueExA, RegCreateKeyExA, RegCloseKey

Then code jump in .text section, and OEP is then correct.

This packer uses several tricks to annoy the disassembler/analyst like some jumps in middle of an instruction, "push eax; retn", always true comparison ... but nothing to detect the presence of a debugger or a VM.

Malware features

After unpacking, this binary is in fact a simple downloader. The binary try to confuse IDA with lots of "JZ/JNZ" jumps. In fact, nearly all jumps are using this trick.

IDA confused

Disassembly fixed

The first function called by the unpacked code is used to resolve addresses of network functions. "wininet.dll" library is loaded at runtime with LoadLibrary and then InternetOpenUrlA, InternetOpenA, InternetCloseHandle and InternetReadFile functions addresses are resolved thanks to GetProcAddress. Address of UrlDownloadToFileA from "urlmon.dll" is also resolved with the same method.

The second function used is to assure reboot persistence to the malware. In order to run after a reboot, this malware add an entry to the registry :

[HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]

"McUpdate"="path_to_this_binary"

Key and subkey values are not stored in clear text in the file but are encoded with a xor algorithm. The following python script decodes all encoded strings used in this binary :

Then malware contacts its C&C to get an order. URL is encoded with the aforementioned algorithm. After decoding, URL is : http://216.15.210.68/197.1.16.3_7.html. After decoding, User-Agent used to connect to the C&C is "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)". If it can't contact the C&C, it will wait 10 minutes before retry. After 3 fails to get a command from the C&C, the binary ends its execution.

Commands on the C&C server are between "<!-- DOCHTML" and "-->" HTML tags. These two tags like the following commands are also encoded in the binary. Command can be one of the following :

- Ausov : Exit the program

- Author X : Wait X * 10 minutes

- http://url : url used to download and execute an other binary.

When the last command is obtained from C&C, the file pointed by the url is downloaded to the temporary folder thanks to UrlDownloadToFile function. As the downloaded file can be compressed by Lempel-Ziv algorithm, the malware opens the downloaded file with LZOpenFile. An other file is created with nearly the same path than the first file opened : ".exe" extension is added at the end. Then, content from the first file (the downloaded one) is copied (and decompressed if necessary) to the second thanks to LZCopy function.

After that, the copied (and uncompressed) file is executed with CreateProcessA.

After analysis, the aim of this malware is simple : download and execute (more advanced?) binaries on the victim computer. This malware seems to be one of the WEBC2-AUSOV family defined by Mandiant as "Ausov" is a command of this sample.

I have not being able to identify the packer used. So if you recognized it, feedback will be welcome ;-)