Beyond good ol’ Run key, Part 5

Time for the 5th part. Today it’s about the Phantom DLLs Hijacking (do not confuse it with ‘DLL Search Order Hijacking’ where order in which paths are searched for is abused).

Windows is a huge operating system and not all components are cleaned up every new release. Thanks to that, there is a lot of legacy code that due to its age and changes in the structure of the operating system no longer work, or are simply left alone – probably just an implementation of the good ol’ rule at work – if it doesn’t break, don’t touch it.

Many Windows applications residing in the system32 directory are not used on daily basis – some of them indeed look like legacy apps (you can still run syncapp.exe on your Windows XP copy to enjoy the Briefcase experience :)), and some of them may be used only in specific configurations (e.g. NT Backup). The mechanisms that some of these legitimate applications use often cater for different scenarios and environments and… thanks to that, they can be often exploited.

Toying around with system32 executables I came across a few legitimate applications that may work as a hidden persistence mechanism . The ‘features’ I am describing are not new, and are identical with the fxsst.dll trick mentioned in the 3rd part of the series and described by Mandiant in detail. The idea is simple – some programs attempt to load specifically named libraries that are some sort of extension, or plugins and in some cases debugging tools – and they can continue to run, even if these DLLs implementing this extra functionality are not present.

Here’s a list of pairs I came across (and I bet there is more; note, some of these may work on other OS versions as well – usually the same code is used across many consecutive OS versions):

ntbackup.exe and edbbcli.dll (Windows XP)

Ntbackup is a Backup Utility for Windows (available on XP, but not 7). When launched it starts a Backup or Restore Wizard.

The interesting thing is that when loaded, this .exe is also attempting to load a library called:

  •  %windir%\system32\edbbcli.dll

Thus, dropping such named DLL and making ntbackup run every time Windows starts either by using Scheduled job or using any of the well-known Autorun mechanisms one can achieve quite a stealthy code execution.

ntbackup.exe and esebcli2.dll (Windows XP)

The situation is exactly the same here; anytime ntbackup launches, it attempts to load the esebcli2.dll DLL from the following location:

  • %windir%\system32\esebcli2.dll

The legitimate mechanism of loading these two NT Backup DLLs is explained here.

mrt.exe and bcrypt.dll (Windows XP)

MRT is a Malicious Software Removal Tool. When launched, it attempts to load bcrypt.dll; thus, dropping it in the system32 directory on XP will lead to (somehow ironic) execution of the code:

  • %windir%\system32\bcrypt.dll

The bcrypt.dll doesn’t exist on XP, but it does on Windows 7, so this trick will only work on older Windows.

sessmgr.exe and SalemHook.dll (Windows XP)

Yet another binary that can load a targeted DLL is a Remote Desktop Help Session Manager executable on Windows XP. Once launched, it tries to load the following DLL:

  • %windir%\system32\SalemHook.dll

certreq.exe and msfte.dll (Windows 7)

Certreq is a tool that allows to work with certificates. When launched it attempts to load the following DLL:

  • %windir%\system32\msfte.dll

certreq.exe and msTracer.dll (Windows 7)

Certreq seems to like non-existing DLLs as it also attempts to load the following DLL:

  • %windir%\system32\msTracer.dll

FXSCOVER.exe and TPPrnUIENU.dll (Windows 7)

This tool is a Fax Cover Page Editor. When loaded, it attempts to load the following DLL

  • %windir%\system32\spool\DRIVERS\W32X86\3\TPPrnUIENU.dll

The name of the DLL (TPPrnUIENU.dll) suggests that:

  • It is a companion to %windir%\system32\spool\drivers\w32x86\3\TPPrnUI.DLL (there are plenty of %windir%\system32\spool\drivers\w32x86\3\TPPrnUI*.dll files, but not the TPPrnUIENU.dll)
  • The ENU in the file name indicates it is a Satellite DLL used in localization and it’s providing data for the English language (the other TPPrnUI*.dll present on the system use other language identifiers e.g. TPPrnUIfra.dll, TPPrnUIita.dll)

In theory, these Satellite DLLs are resource-only DLLs, but the TPPrnUI.DLL is using a LoadLibraryW to load them –  a big mistake, since the LoadLibraryW calls DllMain of the loaded DLL (LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE is a better choice here). Hence, a code execution.

dxdiag.exe and DXGIDebug.dll (Windows 7)

dxdiag.exe is a DirectX Diagnostic tool. When executed, it attempts to load the following DLL (for debugging purposes as a part of DXGI framework):

  • %windir%\system32\DXGIDebug.dll

msinfo32.exe and fveapi.dll (Windows 8.1)

The msinfo32.exe is a system information tool. When executed, it will try to load the following DLL:

  • %windir%\system32\fveapi.dll

Interestingly, this DLL is present on Windows 7 and Windows 8, but not present on Windows 8.1 (in default installation). The DLLs description is Microsoft Vista BitLocker Drive Encryption API and it offers access to BitLocker API.

narrator.exe and MSTTSLocEnUS.DLL (Windows 8)

Last one on the list is Narrator.exe that attempts to load the following DLL:

  • %windir%\system32\speech\engines\tts\MSTTSLocEnUS.DLL

Again, then file naming suggests localization gone wrong.

32-bit processes, Wow64.dll and Wow64Log.dll (Windows 7 64-bit)

This is not a process-specific autorun mechanism, but a system-wide way of introducing a DLL into all 32-bit processes running under control of WOW64 by dropping the following 64-bit DLL on the 64-bit Windows 7.

  • %windir%\system32\Wow64Log.dll

This trick has been discovered and described in detail by Wallied Assar on his blog earlier this year.

While Wow64Log.dll appears to be made available with a purpose of being a legitimate logging feature, it can be abused as a persistent mechanism as well.

The art of disrespecting AV (and other old-school controls)

Update

Thanks to Kurt Wismer for pointing out a mistake re: false vs. true negatives; I have corrected it below

Old post

Every once in a while I hear people whining commenting about antivirus solutions:

  • “It’s outdated”.
  • “It’s a resource hog”.
  • “Let’s get rid of it”.
  • “It didn’t detect the malware XYZ.”

I sometimes do it too, but… I would never ever remove AV from the company environment. It’s easy to say AV is no longer necessary, or ‘doesn’t work’ . It’s also very tempting to apply one’s localized context of their (often smaller) environment to pretty much every possible situation, but… it just doesn’t work this way.

Let the preaching begin.

What is an antivirus and its role in your environment?

Putting sales BS away, one can say that:

The antivirus’ role in your environment is to:

  • detect known malware using specific patterns/signatures, algorithms, etc.
  • detect unknown malware using heuristics (wildcard/regular expressions, behavioral analysis, file reputation, etc.)

and block/remove it

The ‘known malware’ is an easy bit. You know it, you block it (or kill it).

The ‘unknown malware’ bit is often the major reason for whining, but we should all know that AV is not a ‘cure it all’ solution and there is no algorithm in the world that will allow to detect every single malware. Nearly 30 years ago Fred Cohen prove that detection of viruses is undecidable. The proof will probably make you scratch your head a little, but the beauty here is in its simplicity.

To catch up with the reality, we can expand our definition and say:

The antivirus’ role in your environment is to:

  • detect known malware using specific patterns/signatures, algorithms, etc.
  • detect unknown malware using heuristics (wildcard/regular expressions, behavioral analysis, file reputation, etc.) with the highest possible rate, but with NO expectation of detecting every single malware out there

and block/remove it

Statement like this is far more realistic – people who support this are at least aware of AV weaknesses.

Still, such statement omits one yet very important bit.

The antivirus role in your environment is also NOT to detect non-malicious files.

Ever heard of False Positives?

The availability heuristic makes a lot of people talking critically about AV to focus on the following:

  • False Negatives (malware is missed)
  • False Positives (good file is incorrectly detected as malware).

followed by the obvious:

  • True Positives (malware is detected)

What about True Negatives?

The number of these is tremendous. The thing is, they are NOT reported.

You probably chuckle now. How can we even take it into consideration? After all, we are not paying AV for NOT detecting stuff!

You see, with a decent AV on your system every single operation you do one way or another triggers a background AV check. And it is a far more complex task NOT to trigger on stuff, than to trigger on a very specific pattern. This is especially true for heuristic detections. And this is not to justify AV missing stuff by saying ‘but it’s not detecting the good stuff’. It is just a picture is not full without this bit. If it doesn’t make sense – think of all the posters in Las Vegas showing the casino winners. And then try imagining what would happen if they put the posters of all the losers as well. This is an error of availability at work.

So far we have got:

The antivirus role in your environment is to:

  • detect known malware using specific patterns/signatures, algorithms, etc.
  • detect unknown malware using heuristics (wildcard/regular expressions, behavioral analysis, file reputation, etc.) with the highest possible rate, but with NO expectation of detecting every single malware out there

and block/remove it. The antivirus role in your environment is also NOT to detect non-malicious files.

I guess that’s it.

On a high-level, AV is just one of available security controls that is imperfect by its nature. Interestingly, individual malware detection kinda lost its ‘whoaw’ impact over the years. Malware detections are quoted in groups of hundreds, thousands, and more – and reported in ‘spikes’ on monthly basis. So, right there, in front of our very own eyes we have a proof of AV actually working, and working very well, yet a few missed detections occupy our mind enough to dismiss the benefits of using it. It is true that even a single malware NOT detected can be a game over, but the alternative cost of NOT having AV installed means the chances for game over increase dramatically as its multiplied by hundreds, thousands detection for your average mid-size to large company.

Let’s say it one more time: any single piece of malware that AV detects makes your company more secure.

And about all these neglected hundreds, thousands and more detection reported on monthly basis?

Don’t just stare at the charts. Use it.

In my recent post I mentioned SCCM. AV logs from across the whole company are very useful in finding patterns of malicious campaigns, characteristic patterns, and so on and so forth. The infamous ‘invoice’, ‘fedex’, ‘ups’, campaigns often end up with malware being deployed in a very similar fashion. With such internal intel that can be very quickly pulled from any enterprise-level AV product, it’s very easy to combine it with SCCM and other controls to form a solid detection ‘umbrella’.

The list below shows a few things you can do with AV logs alone:

  • run statistics – pick up systems that are infected over and over again, investigate
  • find systems with detections coming from removable devices – block access to removable devices for repeating ‘offenders’
  • find systems with recurring detections – request rebuild/forensics if you see malware being picked up on the same system many times; AV may be struggling to remove it
  • find systems infected with a highly sophisticated malware (ZeroAccess, rootkits, etc.) – request rebuild/forensics
  • find file names / patterns of detected malware – use it in SCCM queries
  • eyeball the ‘detected & removed’ alerts – most of people ignore the ‘detected & removed’ – once in a while you will find hacking tools, password/information stealers, etc. – these systems are the ones you should be looking at; there may be something juicy stolen from these systems; request credentials changes; these systems may be also compromised by other malware
  • correlate alerts looking at the host names and cross-reference them with a list of important systems – domain controllers, web servers, systems that belong to C-level guys, admins, etc. – anything that processes sensitive data / is a part of a highly critical infrastructure is of an interest
  • cherry-pick systems, fetch samples from Quarantine, run them via sandboxes

The list can go and on.

I would argue that lots of conversations about threat intel, security analytics, clustering, etc. often miss the basic fact that the ‘old-school’ enterprise products provide both data and tools to run lots of correlations and they do it ‘natively’ without any need for BIG DATA solutions or external input.

You heard it right. You can do IR work w/o buying new security controls!

In fact, if you have an AV, proxy/firewall and DNS logs as well as SCCM access you have at your hands most of the data needed to discover a compromise, or a malicious infection. SCCM and AV helps with host analysis, proxy/firewall and DNS with network analysis.The early daily stats can be done with Excel, grep and a bit of scripting. This can be always automated later.

Preaching ends here 🙂