Motivation
ICA winstation driver(wdica!KeyboardScanCodes()) always passes the following keyboard input data structure down to termdd!IcaChannelInput() in Shadow_Stack a.k.a passthru stack when user finished Shadow by entering Hotkey “Ctrl + ” and remained that key in the previous shadower session. This means to cause SAS dialog by only “Alt” key down.

Debugging and some comments


PROCESS 820d5bc8 SessionId: 0 Cid: 09cc Peb: 7ffdf000 ParentCid: 01f4
DirBase: 0fdee3e0 ObjectTable: e1487130 HandleCount: 413.
Image: svchost.exe

scancode member for keyboard make in KeyboardInputData structure
~ snips ~
MakeCode : 0x1d
Flags : 0
~ snips


This scancode deliver causes to remain win32k!gfsSASModifieresDown(2) in previous shadower session.This is perfomed at win32k!xxxKeyEvent() to remains Ctrl / Shift / Alt key are really phisically down. At this moment, win32k!gfsSASModifieresDown(2) and win32k!gfsSASModifiers(3) by default.

In a mean time, user enteted “Alt” key in previous shadower session then add modifier ALT(1) to win32k!gfsSASModifieresDown(2) win32k!gfsSASModifieresDown became 3 which is SAS modifier Hotkey. then SAS dialog popped up in the previous shadower session as a result of entering “Del” key in win32k!IsSAS().

On the other hand, RDP winstation driver passes keyboard input data structure down to termdd!IcaChannelInput() in Shadow Stack as the same as ICA passthru stack. However, modify Flags member in keyboard data structure to 0x10. This implementation prevented from the same issue so that remains win32k!gfsSASModifieresDown(2) in previous shadower session.

useful conditional break point
The following conditional break patching was effective in this ica shadowing scenario.
0 e f768a096 0001 (0001) termdd!IcaChannelInput “j poi(@esp+8) = 0 & poi(poi(esp+14)+2) = 0x1d’!process -1 0;kv;ew poi(esp+14)+4 0x10;gc’;’gc'”

Global Escalation Manager Tokyo
-fb