Beyond good ol’ Run key, Part 113

This is another one where I just document things that are not commonly known, but _are_ very well documented for years, and defo still worth describing in this series.

While looking at the well-known dbghelp.dll library I noticed that it looks for entries under:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\KnownManagedDebuggingDlls

These entries are enumerated and then loaded via LoadLibrary

Quick google session followed and I found this awesome post from 2007.

—–Original Message—–
From:
Subject: RE: managed minidump
Auxiliary DLLs are loaded inside of MiniDumpWriteDump when it finds a registered auxiliary DLL for a module in the target process. The lookup is to take the full path of the module and see if there’s a registered auxiliary DLL. You can’t have multiple aux DLLs for a single module path.
—–Original Message—–
From: Junfeng Zhang
Subject: RE: managed minidump
When are auxiliary dlls loaded?
What is the behavior when there are multiple entries under each key?
—–Original Message—–
From:
Subject: RE: managed minidump
Both are filled with string values of the form = . MiniDumpAuxiliaryDlls lists helper DLLs that the minidump code can use to get additional data during dump generation. For example, mscorwks.dll has a registered auxiliary of mscordacwks.dll, which provides extra CLR memory data for a minidump.
KnownManagedDebuggingDlls is a security measure so that a debugger, when attempting to load extra support DLLs for managed debugging, can know what DLLs are approved for use on the system. The CLR registers mscordacwks.dll here, for example.
Both are kept in HKLM so that they can only be written by an admin.
—–Original Message—–
From: Junfeng Zhang
Subject: managed minidump
How does OS use the following two registry keys?
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MiniDumpAuxiliaryDlls
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\KnownManagedDebuggingDlls

As you see, not only KnownManagedDebuggingDlls, but also MiniDumpAuxiliaryDlls branch is of value for threat hunters.

That’s a very fine Chardonnay you’re not drinking

Update

This post is vague on names, vendors, products. Simple reason: I don’t want to get sued.

However, I give you all the tools to go and find the vendors that abuse the trust ‘your’ users put in them.

Old Post

This post is an attempt to look at a threat that is often overlooked in our typical threat hunting scenarios: unintended data leakage.

Unintended means that users do not have any plan to steal a data and ruin a company. They simply lack the technical knowledge that would allow them to assess the risk of installing certain applications. Who am I kidding. It’s not only non-techies falling for it, but also more technical people as well. I saw evidence of the latter on a number of occasions. Yup, and the evidence includes yours truly.

How do we leak data in an unintended way?

The simplest example is the auto-complete/auto-suggest functionality. As you type stuff in various search boxes (OS, browser address bar, search bar, etc.), the data is often sent key by key to some remote server instantly. In return, a suggested word can be provided and the editor can help us to type faster by ‘guessing’ what the next word will be. This is a great and handy functionality, but the risk is that you may accidentally paste something sensitive and hit Enter. It did happen to me on more than one occasion over the years. I tend to flip between many windows pretty quickly, and sometimes such automation mode fails me. Additionally, if I work between two different OSes e.g. Windows and MAC, and with many host/guest combos my strong habits on one OS don’t translate well to the others. As such, wrong combinations of keys lead to a booboo. I developed a habit now that I always look at the search box before I hit enter, but I wouldn’t say this is a foolproof solution…

We can argue that these are just accidents and can be handled quickly. I agree. I wanted to describe a trivial case before I go to a more interesting area: the software.

There is a group of software that relies on a heavy interaction with servers for a very simple reason: it works using the same principles like auto-complete/auto-suggest functionality, but applies it not to typed keys only, but pretty much everything that has a textual form.

By now, I guess you know what I am talking about — translation, and with a lower impact – spelling, and grammar correction software, text to speech, voice to text software, as well as many online document converters (e.g. DOC to PDF).

I will focus on describing a translation software only, but many of aspects covered below apply to other software too & similar threat hunting techniques can be used to find them.

From a purely technical perspective, many of translation applications/plug-ins use techniques that are very similar to ones you expect from a proper keylogger. They monitor keys entered from a keyboard, they monitor a clipboard, they monitor active / foreground windows as well as mouse cursor position to know where to grab a text from. Some of them go as far as using ScreenOCR/ScreenICR to grab a text from pictures, or custom controls that don’t support text retrieval via any API. They also install add-ins, plug-ins to improve their ability to harvest text from word processors, email clients, etc. in a native way. They have… lots of potential.

Anytime they grab that text – it is being translated almost instantly.

Applications of this sort exist for many years. Back in a day though, they would heavily rely on offline dictionaries and translation algorithms that would reside in libraries stored on user’s system. The need to connect to the remote server was minimal (only for updates). Today, most of them are cloud-based – – it is obviously better this way, from a quality perspective: dictionaries are always up to date, no need to transfer large files, users can exchange translations, etc.

The only problem is that in an effort to be as user-friendly as possible, they grab all the possible stuff without much control from the user and send it out.

If you are a ‘lucky’ threat hunter, you will look at your logs and see very rich GET requests. If you are less lucky, only POST and for these you need to collect some PCAPs.

The ‘richest’ translation applications I have seen are these that are sending whole paragraphs, memos, content of emails, email threads, pretty much… everything. Some of them will even include process names for windows the text snapshot was taken from, or additional attributes telling the vendor how the text was grabbed. They actually include lots of metadata in these logs.

Now that I have your attention, my suggestion for your hunting exercise is as follows:

  • Network Logs
    • Look for popular process names in your logs e.g. Outlook, Winword, etc; they may be related to the translation software, or… any other threat (PUA, malware, etc.), so they are good one way or another
    • Look for domains that are related to translation; the following list of initial keywords should help:
      • transl
      • traduct
      • lingv
      • dict
      • thesau
      • spellc
  • Endpoint
    • Look for a presence of translation software
    • Download and install it in VM, test how it works
    • If you see it sending stuff out, assess what sort of data is being included
    • Look for cool functionality: ScreenOCR, ‘follow the window’, etc.

Note: not all of these applications are bad. Many of them ‘behave’, so you don’t need to kill’em all. But monitoring at least — yes, definitely.