You are browsing the archive for Compromise Detection.

Two old-school download/exfil methods

May 25, 2018 in Anti-Forensics, Archaeology, Code Injection, Compromise Detection

Sending and receiving network data is always tricky.

With AV, EDR, and dozen of other agents that are installed on the system nowadays it is getting harder and harder to transfer data, because security applications may be actively monitoring specific system/API calls, or just following strict network rules with regards to non-approved apps. Often, if the app is not on the whitelist no connection out can be made.

There are numerous known ways to bypass it, of course; here, I re-discover two very, very and I mean it… very, very old-school techniques that rely on IE browser and its support of Dynamic Data Exchange (DDE) and Microsoft Active Accessibility (MSAA) functionalities. They have most likely only a historical meaning today: new versions of Windows are shipped with Microsoft Edge and the tabbed interface adds additional complexity…

As I mentioned, these two methods are almost completely forgotten. One of them was actively used by old malware (10+ years ago), the other was successfully leveraged by various IE Spies that helped to look at the source code of blocked/inaccessible IE windows + any application that was relying on the HTML-based user interface (it was very prevalent back in early 2000s e.g. think of Norton products from that era).

The first method is DDE/WWW_OpenURL command. As long as IE is open you can send it a DDE command WWW_OpenURL with the URL of your choice. Sending data out this way is trivial (although limited in length), receiving requires either accessing the IE instance, or just enumerating the TIF directory. The method is not clean per se as it was designed long time ago and was not prepared for the tabbed interface. It may affect the user’s browsing experience.

The second one is more esoteric. You can enumerate all windows classes and find windows with a class ‘Internet Explorer_Server’ (Old IE web browser container, prior to Edge; also note: you cnn always launch new instance of IE as well, and make it a hidden window). Once such window is identified, you can send it a very specific message called WM_HTML_GETOBJECT, and process the result using a ObjectFromLresult function. The result will give you an access to a IHTMLDocument2 pointer for that IE instance. With that pointer, you can walk through a couple of COM queries and retrieve the IWebBrowser2 interface of the Web control container. And with that, you can access an active instance of IE browser from your program and manipulate it freely to download and send out whatever you want. Unless security solution monitors these requests specifically you may not be able to spot the bad guy…

I did say that these methods have most likely only a historical meaning today as new versions of Windows are shipped with Microsoft Edge and the tabbed interface adds additional complexity, but… as this thread suggests, perhaps the support for MSAA implemented by modern browsers still offers some interesting possibilities? And probably here it is a good time to remind you of my old post talking about using the accessibility APIs to develop keylogging functionality w/o using any typical well-known keylogging APIs.

And last, but not least. At some stage I was looking at the possibility of using the DDE and WM_HTML_GETOBJECT tricks to develop a new code injection technique. Since we can access the browser’s process via other means than a regular WriteProcessMemory it definitely may come handy. And the simplicity of the idea relies on the fact that we can actually forget the shellcodes for a moment, and the code injection can rely on… JavaScript code.

The little known (I think) secret of hosts.ics

March 31, 2018 in Anti-Forensics, Compromise Detection

Today I discovered that while everyone knows one can use the c:\WINDOWS\system32\drivers\etc\hosts file to introduce static entries to the DNS resolver there is one more file that can be utilized for this purpose.

It is a hosts.ics (c:\WINDOWS\system32\drivers\etc\hosts.ics) file that was originally designed to support the Internet Connection Sharing service. It looks like it is being ingested by the DNS resolver same way as the hosts file.

So… yet another place to look at.

After introducing the file on my system to a test Win 10 box I got the following results: