Author Archives: adam

Trivial AppID Impersonation

Posted on by

I was wondering what would happen if one tried to impersonate the AppID of the common applications i.e. run my own application and change its AppID to that of a well-known application during run-time. Kinda lame, I know.

To test it, I wrote a quick PoC that uses SetCurrentProcessExplicitAppUserModelID API to pretend it is Internet Explorer, Remote Desktop and Sticky Notes using their respective AppIDs. I also added the AppID for Notepad – while it doesn’t have a standard AppID like the 3 other applications I just wanted to show that we can still enforce the AppID association using Notepad’s normalized path {D65231B0-B2F1-4857-A4CE-A8E7C6EA7D27}\notepad.exe (for details see my older post about AppIDs).

Here’s a list of AppIDs used:

  • Internet Explorer – Microsoft.InternetExplorer.Default
  • Remote Desktop – Microsoft.Windows.RemoteDesktop
  • Sticky Notes – Microsoft.Windows.StickyNotes
  • Notepad – {D65231B0-B2F1-4857-A4CE-A8E7C6EA7D27}\notepad.exe

I pinned all these 4 applications to the Taskbar on Windows 8.1. and then ran my test application, pausing it each time I changed the AppID to take a screenshot I got the result combined on the below picture. Not surprisingly anytime I changed the AppID a different pinned taskbar icon got highlighted (the test application needs to do some GUI operation for it to work; it can simply show a message box).

appid_rotation

This is quite a tiny level of impersonation – hard to really come up with some really useful scenarios here – perhaps one could use it to enforce social engineering attempts (e.g. escalation of privileges triggered by malware while pretending to be from some legitimate Windows application, or perhaps AV) ? But aren’t existing GUI manipulation tricks better than that? Oh well, trivial is trivial.

Beyond good ol’ Run key, Part 7

Posted on by

In my last post of this series I discussed the VBA Monitor mechanism that can be used to execute code anytime Visual Basic application is started. Today’s topic is similar and talks about yet another internal Microsoft component that could be abused to load arbitrary code – this time it happens anytime the application crashes. As far as I can tell, it only works on XP, so it’s a bit old and not that practically useful, but given the fact XP is still out there in large quantities it is worth documenting it.

The component that we will abuse is called OAClient. It is an agent that is a part of a distributed test management system called Oasys (Office Automation System) and which is used internally by Microsoft to test their Office suites.

How do I know?

I have read about it in this pdf (‘Exploring Cross-Platform Testing Strategies at Microsoft”) that I found online while looking for the meaning of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OASys\OAClient key – and I looked for it, because I spotted this key being queried by DWWIN.EXE anytime the application crashes under Windows XP.

Once I found out, all I had to do is to add the key, force the application to crash

notepad_crash

– so that DWWIN.EXE is launched and then confirm that the presence of the OAClient key leads the DWWIN.EXE to attempt loading of the BTLOG.DLL file from c:\windows\system32.

dwwin_load_btlog_dllThere you have it.

To reproduce:

  • Create %windir%\system32\BTLOG.DLL
  • Add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OASys\OAClient
  • Now launch the application that crashes and loads DWWIN.EXE as a result of the crash (e.g. copy notepad.exe to notepad2.exe and patch its entry point with 0xCC = int 3); the DWWIN.EXE will load the btlog.dll.

.