Seeing an increase in MySQL attacks hitting your network and interested in knowing more about them? This post follows on from the previous post which discussed how to run a Cuckoo Sandbox analysis of a MySQL attack.
This post starts analysing the results and notices an issue with a particular malware trait and Cuckoo (v0.4.2). Awfully gripping stuff — I was on the edge of my seat, but then that could be because my table was too far away from my chair.
The story so far…
I’ve seen some MySQL attacks coming in that I’m calling (for lack of anything better at the moment) the autocommit attacks, mainly because they start with a set autocommit = 0 command and I don’t have much imagination. The MySQL commands contain a hex encoded DLL file which gets saved to the MySQL plugin directory as cna12.dll.
Static analysis of this DLL suggested that it implements a MySQL UDF (User Defined Function) which downloads a given URL to c:\windows\temp\isetup.exe and runs it.
The previous post showed you how to use my misql.py Cuckoo analysis package to dynamically analyse MySQL attacks. It also confirmed one thing before leaving you in suspense, and that is that the xpdl3() MySQL function in cna12.dll returns the string ok…(c:\isetup.exe) portnumber (3389) osversion (WinXP) if the download succeeds, or more precisely, if URLDownloadToFileA() returns a non-zero value (that is, not S_OK).
Let’s continue the excitement by getting in to some analysis.
Dropped files
We can see which files the malware created/modified by going back to Cuckoo’s analysis.log file. Note that if we search for the string Dropped file instead of for the string Added new file, then we won’t see dropped files which couldn’t be copied by Cuckoo:
.../cuckoo/storage/analyses/190$ grep "Added new file to list" analysis.log 2012-12-24 11:07:25,992 [root] INFO: Added new file to list with path: C:\Program Files\MySQL\MySQL Server 5.5\lib\plugin\cna12.dll 2012-12-24 11:07:26,042 [root] INFO: Added new file to list with path: C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.5\data\mysql\proc.MYI 2012-12-24 11:07:26,203 [root] INFO: Added new file to list with path: C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.5\data\mysql\func.MYI 2012-12-24 11:07:26,632 [root] INFO: Added new file to list with path: C:\Documents and Settings\...\Local Settings\Temporary Internet Files\Content.IE5\index.dat 2012-12-24 11:07:26,663 [root] INFO: Added new file to list with path: C:\Documents and Settings\...\Cookies\index.dat 2012-12-24 11:07:26,683 [root] INFO: Added new file to list with path: C:\Documents and Settings\...\Local Settings\History\History.IE5\ index.dat 2012-12-24 11:07:32,492 [root] INFO: Added new file to list with path: C:\Documents and Settings\...\Local Settings\Temporary Internet Files\Content.IE5\H8T9VMND\888[1].exe 2012-12-24 11:07:32,691 [root] INFO: Added new file to list with path: c:\Windows\temp\isetup.exe 2012-12-24 11:07:36,127 [root] INFO: Added new file to list with path: C:\Windows\SoftWareProtector\111.pr 2012-12-24 11:07:36,898 [root] INFO: Added new file to list with path: c:\windows\csrtsdtmkd 2012-12-24 11:07:41,615 [root] INFO: Added new file to list with path: c:\docume~1\...\locals~1\temp\iwlfgjbllx.dat 2012-12-24 11:07:41,934 [root] INFO: Added new file to list with path: C:\Program Files\%SESSIONNAME%\jidfh.cc3 2012-12-24 11:07:43,457 [root] INFO: Added new file to list with path: C:\WINDOWS\system32\f5859b27.rdb 2012-12-24 11:07:59,230 [root] INFO: Added new file to list with path: c:\Windows\v3.log
This confirms that the attack does indeed drop a file called cna12.dll to the MySQL plugin directory. proc.MYI and func.MYI are MySQL database files and were presumably modified as a result of MySQL implementing the CREATE FUNCTION and/or other MySQL commands, and not as a direct result of the attack.
The Content.IE5\index.dat, Cookies\index.dat, and History.IE5\index.dat files are the Internet Explorer cache index file, cookie file, and URL history file, respectively, and they were presumably modified as a side-effect of using the URLDownloadToFile() Win32 API call to download from a URL.
The Content.IE5\H8T9VMND\888[1].exe file will be the Internet Explorer cache copy of the downloaded URL, which was /888.exe in this case (see the URL in the select xpdl3() query above), and an MD5 hash comparison will also suggest this. The fact that this file exists, also suggests that the xpdl3() function downloads the URL that it is given.
We then see c:\Windows\temp\isetup.exe, which Cuckoo actually copied despite mentioning in its analysis.log file, that it couldn’t copy that file because it didn’t exist:
2012-12-24 11:09:37,000 [root] ERROR: Unable to dump dropped file at path "c:\Windows\temp\isetup.exe": [Errno 2] No such file or directory: 'c:\\Windows\\temp\\isetup.exe'
There are then some files which we don’t recognise, followed by c:\Windows\v3.log. We should recognise this from the static analysis, as being the log file created by the xpdl3() function if the URLDownloadToFileA() call succeeds (or returns zero at least).
Let’s have a look at the dropped files in a bit more detail:
.../cuckoo/storage/analyses/190$ find files -type f -exec file {} \;
files/5745345984/func.MYI.bin: MySQL MISAM compressed data file Version 1
files/2147759824/proc.MYI.bin: MySQL MISAM compressed data file Version 1
files/124681346/index.dat.bin: Internet Explorer cache file version Ver 5.2
files/3624467864/index.dat.bin: Internet Explorer cache file version Ver
5.2
files/2156270017/isetup.exe.bin: PE32 executable (GUI) Intel 80386, for MS
Windows
files/5271876673/111.pr.bin: data
files/9432877995/cna12.dll.bin: PE32 executable (DLL) (GUI) Intel 80386,
for MS Windows, UPX compressed
files/2146349854/yongger2.frm.bin: MySQL table definition file Version 9
files/2381280534/f5859b27.rdb.bin: MS Windows registry file, NT/2000 or
above
files/9452760445/888[1].exe.bin: PE32 executable (GUI) Intel 80386, for MS
Windows
files/9958236814/index.dat.bin: Internet Explorer cache file version Ver
5.2
files/3851122010/v3.log.bin: ASCII text, with no line terminators
files/1719595416/wjxsexryy.bin: MS Windows registry file, NT/2000 or above
Let’s do a quick sanity check to get some confidence that the cna12.dll file that Cuckoo noticed being dropped, is the same as the cna12.dll file that we extracted from the MySQL commands:
$ find files -iname cna12.dll\* -exec sha224sum -b {} \;
a922d55a873d4ad0bbbbbc8147a3a65a *files/9432877995/cna12.dll.bin
That is the same MD5 hash so we’re reasonably sure that they are the same. Let’s get down to business.
The Analysis
“Houston, we’ve had a problem”
Although I dare say Houston doesn’t care about this problem. It turns out that I discovered something interesting when I started wading through the output from Cuckoo’s DLL and the output from Process Monitor. Cuckoo doesn’t show any registry access to the key SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\ which is quite obviously mentioned in a RegCreateKeyA() call toward the start of the xpdl3() function in cna12.dll. However, the Process Monitor log file, events.csv, does mention it:
"11:07:26.2141624","mysqld.exe","1340","RegCreateKey","HKLM\SYSTEM\ CurrentControlSet\Control\Terminal Server\WinStations\ RDP-Tcp","SUCCESS","Desired Access: Maximum Allowed" "11:07:26.2143180","mysqld.exe","1340","WriteFile","C:\cuckoo\ logs\1340.csv","SUCCESS","Offset: 34,057, Length: 264" "11:07:26.2143375","mysqld.exe","1340","RegQueryValue","HKLM\System\ CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\ PortNumber","SUCCESS","Type: REG_DWORD, Length: 4, Data: 3389" "11:07:26.2144521","mysqld.exe","1340","WriteFile","C:\cuckoo\ logs\1340.csv","SUCCESS","Offset: 34,321, Length: 188" "11:07:26.2146074","mysqld.exe","1340","RegCloseKey","HKLM\System\ CurrentControlSet\Control\Terminal Server\WinStations\ RDP-Tcp","SUCCESS","" "11:07:26.2147194","mysqld.exe","1340","WriteFile","C:\cuckoo\ logs\1340.csv","SUCCESS","Offset: 34,509, Length: 128"
Process Monitor even shows mysqld.exe writing to Cuckoo’s process log file, 1430.csv, so why doesn’t the registry access appear in the 1340.csv log file? Another oddity is that the registry access and the WriteFile() call entries are time stamped 11:07:26. If we look at the start of Cuckoo’s log file, 1340.csv
"2012-12-24 00:07:31,440","1340","mysqld.exe","192","428","system", "NtDelayExecution","SUCCESS","0x00000000","Milliseconds->1566804069" "2012-12-24 00:07:31,450","1340","mysqld.exe","480","428","threading", "CreateRemoteThread","SUCCESS","0x000232a0","ProcessHandle->0xffffffff", "StartRoutine->0x7c910230","Parameter->0x00000000","CreationFlags->4", "ThreadId->0" "2012-12-24 00:07:31,490","1340","mysqld.exe","480","428","threading", "NtResumeThread","SUCCESS","0x00000000","ThreadHandle->0x000232a0", "SuspendCount->1" "2012-12-24 00:07:31,490","1340","mysqld.exe","480","428","system", "NtClose","SUCCESS","0x00000000","Handle->0x000232a0"
we can see that the first entry is time stamped 00:07:31. Something is obviously amiss, and the answer lies further down in the Process Monitor log file:
"11:07:28.9374848","mysqld.exe","1340","Thread Create","","SUCCESS", "Thread ID: 392" "11:07:28.9408936","mysqld.exe","1340","Thread Create","","SUCCESS", "Thread ID: 192" "11:07:28.9413269","mysqld.exe","1340","WriteFile", "C:\cuckoo\logs\1340.csv","SUCCESS","Offset: 177,680, Length: 227" "11:07:28.9422717","mysqld.exe","1340","QueryOpen", "C:\analyzer\dll\VROOqM.dll","SUCCESS", "CreationTime: 24/12/2012 11:07:26, LastAccessTime: 24/12/2012 11:07:26, LastWriteTime: 24/12/2012 11:07:26, ChangeTime: 24/12/2012 11:07:26, AllocationSize: 159,744, EndOfFile: 158,720, FileAttributes: A" "11:07:28.9424077","mysqld.exe","1340","CreateFile", "C:\analyzer\dll\VROOqM.dll","SUCCESS", "Desired Access: Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened" "11:07:28.9425080","mysqld.exe","1340","CreateFileMapping", "C:\analyzer\dll\VROOqM.dll","SUCCESS", "SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE" ... "11:07:31.4433904","mysqld.exe","1340","CreateFile", "C:\cuckoo\logs\1340.csv","SUCCESS", "Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Overwritten"
The Cuckoo log file, 1340.csv, is recreated with an OverwriteIf (the file exists) disposition, and the result of the open is stating that a file with the same name was Overwritten. It turns out that URLDownloadToFile() actually creates new threads, which may be what caused Cuckoo to reinject its DLL, and hence recreate the log file. I did some quick testing, but only discovered that Cuckoo’s analyzer.py is reinjecting because it receives a PID: message over its named pipe from the DLL. I have been unable to find the source code for v0.4.2 of cuckoomon.dll, possibly due to my lack of git skills, and hence haven’t gone any further with this.
However, since finishing most of the content for this mini-series, I noticed that Cuckoo v0.5 had been released so I won’t concentrate too much on issues with Cuckoo v0.4.2 (especially when Cuckoo v0.5 now copies dropped files when it sees a call to delete them), but rather work on getting misql.py working nicely with v0.5 — I’m having some issues which I’m trying to troubleshoot.
So join me for the next post in the mini-series where I am able to conveniently ignore these problems and continue on by using both Process Monitor’s log file and Cuckoo’s log files.