***** 1


Hacking Microsoft Remote

Desktop Services for Fun and Profit

Alisa Esage

Who am I?

Reverse engineer since …

Founder, CEO, Esage Lab

– operating in Russia

– cyber incident response, software security auditing, technical training

(soon) MALWAS.com

Co-founder, sponsor, {neŠ¹ron}

Moscow’s hackerspace

Ex malware analyst, major AV vendor

Why %subj?

Trending: professional cyber robbery based on remote desktop access

Illicit money transfers via a remote banking application

An attacker wants to operate within the active user’s session, while not intercepting with the user

VNC module for Zeus

Costs $$$

Based on GPL uVNC

What about Microsoft Terminal Services?

Microsoft Terminal Services

A powerful remote access technology

Available since NT4

Two fundamental applications:

Remote Desktop

Remote Assistance

Remote Desktop

Allows users to log in remotely

Pre-installed in almost any Windows

Stable, easy, powerful, clients exists for any OS

Full-featured only on Servers

Restricted on Workstations

• only one user at a time can be logged in, either at the console or remotely

Remote Assistance

Allows to share a console user’s desktop with an authorized helper

Allows to “interact” (control)

Msra.exe (sessmgr.exe previously)

User-initiated assistance

Via tickets

Dynamic port

Offered assistance

• msra.exe /offerra

RPC request to port 135

Domain environment only


1. Allow multiple user sessions

2. Allow concurrent terminal session for the active console user

3. Bypass logon auth

4. Monitor/control the console session

Basic assumptions

We already have code execution on the target

Too many RCE exploits in the wild today to consider it a challenge

We already have local admin privilege on the target

Never been a problem for malware developers (says ex AV employee)

Plenty of buggy system-level software to develop an

EoP exploit

Speaking about architecture, I am meaning

Windows 7, if not stated otherwise

State of the %subj

Previous research

Remote Desktop functionality enhancement patches for workstation users

Cw2k, Remko Weijnen and others

Limited OS support

No auth bypass, no control over the console session

Malware based on Remote Desktop Services

Just launch the service, then login via an added user account

Key modules: Terminal Services


– service binary, RPC provider

– hosted by svchost.exe


– core device driver, network listener

– wrapped by icaapi.dll

End-user executables

msra.exe – remote assistance

mstsc.exe – RDP client

Key modules: RDP protocol stack


Tunnel remote user’s mouse and keyboard

Wrapped by rdpwsx.dll

Configured by rdpcfgex.dll


Graphics redirection to the remote user


Package RDP data into TCP/IP

Allow multiple user sessions; allow concurrent terminal session for the active console user


Remote Desktop connection details

Termdd.sys accepts a network connection on port 3389, creates a per-connection instance of RDP protocol stack

New smss.exe and csrss.exe are spawned

Per-session win32k.sys window manager

Winlogon.exe to display logon prompt

On successful logon, userinit.exe and

explorer.exe are started (or their registrydefined substitutes)


Surprise: Terminal Services module is full-featured on ALL


Feature restrictions are caused by explicit version checks:


IsProfessionalTerminalServer() { GetVersionExW() … }

Termsrv.dll XP: gbServer, g_bPersonalTS

Termsrv.dll Vista+:


Solution (contd.)

So we fool Windows into thinking that she is a server

Inline patching in real-time (no file modifications):

Hook GetVersionExW() in the context of winlogon.exe to return the proper value

Set global variables in termsrv.dll

Some more patches in termsrv.dll

Solution (contd.)

Configure the terminal server

SYSTEM\\CurrentControlSet\\Control\\Terminal Server: fDenyTSConnections = 0, TSAppCompat = 0, TSEnabled = 1

\\Licensing Core:

EnableConcurrentSessions = 0

\\WinStations\\RDP-Tcp: fEnableWinStation = 1, MaxInstanceCount = 0xFFFFFFFF

SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon:

AllowMultipleTSSessions = 1


LimitBlankPasswordUse = 0

Solution (contd.)

Add local users to “Remote Desktop Users” group



Allow Terminal Services through the firewall



Bypass logon auth



Msv1_0.dll (Microsoft Authentication Package)

LsaApLogonUserEx2(): call MsvpPasswordValidate(x,x,x,x,x,x,x) test al, al jz @@STATUS_WRONG_PASSWORD

Patch it!

Monitor/control console session


Solution #1

Remote Assistance (msra.exe) relies upon

rdpencom.dll (RdpComApi 1.0 Type Library)

API is documented!

IRDPSRAPISharingSession, IRDPSRAPIViewer m_pRdpSession = new RDPSession(); m_pRdpSession.OnAttendeeConnected += new


OnAttendeeConnected); m_pRdpSession.Open();

Available since Vista only, so we are not happy yet…


Exists in all Windows since NT4!

Only works for Server targets

Must be launched from within a terminal session

Needs target user’s permission to connect

Connection request details


WinStationShadow() @winsta.dll

RpcShadow() @termsrv.dll






cmp [ebp+var_528], IDYES jz mov jmp short @@OK_DOSHADOW esi, 0D00A002Ah


Solution #2

We’ve already tuned a workstation into a server!

So shadow.exe just works

Patch the dialog box that requests user’s permission:

Hook MessageBoxTimeoutW() @csrss.exe:

If (!wcsncmp(MsgText + i, GetComputerNameW()…))

{ // don't display the dialog box

M_FREE(Text); return IDYES; }


2 hooks + 3-4 inline patches

– vs. xxx xxx KB of custom heavy code

Seemingly complicated problems may have trivial solutions

Operating systems have plenty of code and functionality which can be re-used for offensive purpose with minimum mess

PoC limitations

Requires Local Administrator privilege

Auth bypass trick fails on Vista SP0 only

Shadow.exe trick fails on Vista

Auth bypass affects local logon