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%”;
show variables like ‘%version_compile_machine%’;
SHOW VARIABLES LIKE ‘%basedir%’;
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
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
Description: A pretty generic downloader (a quick look shows it’s grabbing a file from hxxp://www.game918.me:2545/host.exe and saving it as C:\Windows\shes.exe, launching it, and then grabbing hxxp://huya1219.top/svchost.exe 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:
These UPX-packed files blow out to a 12,288 byte file dropper:
Filesize: 7680 bytes
Type: Windows PE DLL file, UPX packed
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:
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://www.game918.me:2545/host.exe (see above!) as well as something new: hxxp://www.82022333.cn:8065/im.exe
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:
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
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:
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…
P.S.: In the above, I’ve “defanged” all URIs, mostly because Octopress kept turning them into links if I didn’t… and God knows one of you idiots would click on them and then blame me for whatever bad stuff happened.