Backdoor Could Be Used On Microsoft SQL Without Detection Comments Off on Backdoor Could Be Used On Microsoft SQL Without Detection
If you haven't heard of Skip-2.0 yet, prepare to be dismayed.
Security researchers have recently discovered an undocumented (until now) backdoor designed for Microsoft SQL servers.
It will allow a hacker working remotely to stealthily take control of a previously compromised system.
Worse, this is not theory or conjecture. Researchers have found malware strains in the wild that take advantage of the backdoor, allowing attackers to remotely connect to any account on the server running MSSQL version 11 or 12 by using a "magic password."
As bad as that sounds, it gets worse. The Skip-2.0 malware contains code that disables the compromised machine's logging functions, audit mechanisms and event publishing every time the "magic password" is used so that it leaves no trace, which is why it's so difficult to detect.
This gives the malware the freedom and flexibility to move seamlessly through the target system, where it can copy, change, or delete any content stored on it. That is, all while keeping the system's owner or user blind and in the dark as to what's happening. In their most recently published cybersecurity report, the security firm ESET attributed the Skip-2.0 backdoor to an organization known as the Winnti Group, which is a state-sponsored threat actor with Chinese backing.
As evidence in support of this conclusion, the researchers involved with drafting the report point to numerous similarities between Skip-2.0 and other tools developed and used by the Winnti Group, including PortReuse and ShadowPad.
In addition to that, Skip-2.0 utilizes an encrypted 'VMProtected' launcher, an 'inner-0loader' injector and hooking framework and a custom packer to install its payload, which again, is identical to the structure of other Winnti Group tools.
In basic terms, this is just another malware threat to emerge in the tech world. If there's a silver lining in all of this, it is the fact that MSSQL 11 and 12 are not the most recent versions, so the fix is fairly simple. Just upgrade to a version beyond 12 and you can avoid the risks associated with this new threat.