Атаки на rdp и способы защиты от них / хабр

Executive Summary

In May 2019, Microsoft released an out-of-band patch update for remote code execution (RCE) vulnerability CVE-2019-0708, which is also known as “BlueKeep” and resides in code for Remote Desktop Services (RDS). Over the last year, researchers had proved the exploitability of BlueKeep and proposed countermeasures to detect and prevent it. However, RDP is still one of the most popular attack vectors used by attackers today. To make it harder for RDP attacks to succeed and to better protect Windows users and our customers, we will disclose detailed information in this blog about how attackers might exploit BlueKeep on Windows RDP endpoints.

In August 2019, Unit 42 researchers published a blog on CVE-2019-0708, covering how Bitmap Cache protocol data unit (PDU), Refresh Rect PDU and RDPDR Client Name Request PDU can be used to write data into the Windows kernel memory. Additionally, in October 2019, Unit 42 researchers presented three new Windows kernel pool Feng Shui techniques with RDP PDUs and two different exploit techniques of BlueKeep at Microsoft’s BlueHat Seattle 2019 Security Conference. This blog discusses how to combine Refresh Rect PDU and RDPDR Client Name Request PDU to get remote code execution RCE with system privilege.

Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription are protected from this vulnerability, and Cortex XDR customers can prevent exploitation of this vulnerability on Windows XP, Windows 7 and Windows Server 2003 and 2008.

Vulnerability Overview

To make the exploitation clear, we will briefly introduce the root cause of CVE-2019-0708. CVE-2019-0708 is a Use After Free (UAF) vulnerability related to a dangling object, the MS_T120 virtual channel. The MS_T120 virtual channel is one of two default channels (MS_T120 and CTXTW) used by the RDP server internally that are initialized when the RDP connection is established. However, the RDP client can also create a customized virtual channel named “MS_T120” by adding the “MS_T120” item to channelDefArray in Client MCS Connect Initial PDU, as shown in Figure 1.

Figure 1. Customized MS_T120 channel in channelDefArray.

The RDP server receives that request and creates a reference for the MS_T120 object in the ChannelPointerTable object. Figure 2 shows that there are two “MS_T120” channel object references in the ChannelPointerTable object. The first one is created for the Client MCS Connect Initial PDU request, and the second one is created for internal use by the RDP server.

Figure 2. Customized MS_T120 channel object created.

After joining the customized MS_T120 channel using MCS Channel Join Request, the MS_T120 channel can be opened successfully by the RDP client. If the RDP client sends crafted data into the MS_T120 channel as shown in Figure 3, the MCSPortData function in rdpwx.dll module will be invoked.

Figure 3. PDU used to free MS_T120 channel object.

In the function MCSPortData, the data starting from 0x74 offset of the first argument lpAddend are controlled by the RDP client, and MCSChannelClose will be called to free the MS_T120 channel object when the variable “v2” is equal to the value “2”, as shown in Figure 4.

Figure 4. Close channel in MCSPortData.

After the MS_T120 channel object is freed, there is still one dangling pointer left pointing to the freed MS_T120 channel object in the slot 0x1f of the ChannelPointerTable object, as shown in Figure 5.

Figure 5. Customized MS_T120 channel object freed.

When the RDP client disconnects from the connection, the function RDPWD!SignalBrokenConnection is invoked, and then the function termdd!IcaChannelInput will be called to access the freed MS_T120 object in the slot 0x1f, as shown in Figure 6.

Figure 6. Reuse freed MS_T120 object call stack.

Patch Kernel to Avoid Crash

The following work is now a routine for kernel exploitation. The final shellcode first fixes the return value and patches the kernel to avoid crash after the shellcode finishes, and then it executes the kernel shellcode to insert the APC to lsass.exe or spoolsv.exe and execute user mode shellcode. Figure 16 shows how the final shellcode fixes the ChannelPointerTable object, modifies the return address and emulates the execution of the ExReleaseResourceAndLeaveCriticalRegion function to inc a WORD value in KTHREAD.

Figure 16. Final shellcode patch the kernel.

After patching the kernel, the functional part of the kernel shellcode is executed. To illustrate the exploitation, we used a kernel shellcode template released by Sleepya for the eternalblue exploit. A userland shellcode of WinExec(‘calc’) for the demo is shown in Figure 17.

Figure 17. Final shellcode usermode shellcode.

Shellcode

Since there are only 4 bytes that can be used for the stage 0 shellcode, we used a trick of 4 bytes shellcode slipper “add bl,al; jmp ebx” instead of “call/jmp ebx+30h” to jump to stage one of shellcode. When termdd!IcaChannelInputInternal executes “call dword ptr ” assembly instruction, the al is 0x30 and ebx points to the fake MS_T120 channel object in which the RDP client can fill the controlled data. Stage one shellcode is put into the kernel pool from the address faked_MS_T120_channel_object+0x30 (0x867b3590). The whole process is shown in Figure 13.

Figure 13. Stage 0 shellcode.

Something worth mentioning: 2 bytes assembly code “add bl, al” is used because only 4 bytes shellcode can be used to implement “jmp ebx+0x30”. This is not perfect, since when “bl” is greater than 0xd0, there is an overflow in “add bl, al”, enabling “jmp ebx” to jump to a wrong address, causing the exploitation to fail. However, this will be good enough, since the success rate will theoretically be 81.25% (0xd/0x10).

Before talking about stage one shellcode, we’d like to discuss stage two, or the final shellcode. We noticed that the RDPDR Client Name Request PDU can also be used to send arbitrary-sized final kernel shellcodes to the kernel pool in the RDP server. As an example, we constructed an RDPDR Client Name Request PDU with the data length of 0x5c8 and the payload embedded, as shown in Figure 14.

Figure 14. Final shellcode sent by RDPDR Client Name Request PDU.

When the RDPDR Client Name Request PDU embedded with the shellcode is sent to the RDP server, PDMCS — Hydra MCS Protocol Driver will store the data in the kernel pool. Interestingly, that kernel pool has a reference maintained on the stack, which can be used by stage one shellcode to locate the final shellcode. Specifically, the ECX register here points to the stack, and the address ECX+0x28 stores the kernel pool address. The final shellcode is located at the 0x434 offset of the kernel pool, as shown in Figure 15.

Figure 15. Stage one shellcode.

The offset 0x434 may vary in different Windows versions. However, it is easy to craft the stage one shellcode as an egg hunter to make it universal by searching the final shellcode in the kernel pool.

Module Overview

Name: CVE-2019-0708 BlueKeep Microsoft Remote Desktop RCE Check
Module: auxiliary/scanner/rdp/cve_2019_0708_bluekeep
Source code: modules/auxiliary/scanner/rdp/cve_2019_0708_bluekeep.rb
Disclosure date: 2019-05-14
Last modification time: 2022-01-23 15:28:32 +0000
Supported architecture(s): —
Supported platform(s): —
Target service / protocol: —
Target network port(s): 3389
List of CVEs: CVE-2019-0708

This module is also known as BlueKeep.

This module checks a range of hosts for the CVE-2019-0708
vulnerability by binding the MS_T120 channel outside of its
normal slot and sending non-DoS packets which respond
differently on patched and vulnerable hosts. It can
optionally trigger the DoS vulnerability.

Module Ranking and Traits

Module Ranking:

normal: The exploit is otherwise reliable, but depends on a specific version and can’t (or doesn’t) reliably autodetect. More information about ranking can be found here.

Stability:

crash-safe: Module should not crash the service.

Basic Usage

This module is a scanner module, and is capable of testing against multiple hosts.

Other examples of setting the RHOSTS option:

Example 1:

Example 2:

Example 3:

Связь с кибервымогателями

Sophos, Mandiant и SentinelOne зафиксировали применение нового инструментария целым рядом известных группировок хакеров-вымогателей. В их числе Cuba и Hive. Кроме того, похожий тулкит еще в августе 2022 г. использовали участники UNC3944, которая для получения первоначального доступа в сеть организаций использует технику подмены SIM-карт.

В настоящий момент достоверно неизвестно, каким образом упомянутые группировки сумели обзавестись подобными наборами инструментов, содержащими подписанные Microsoft компоненты. Однако Mandiant и SentinelOne считают, что инструментарием или услугой подписи вредоносных драйверов торгуют в Сети. Эксперты предполагают, что за разработкой разновидностей нового тулкита стоит один человек или организация. На это, по их мнению, указывает тот факт, что применяемые «разношерстными» киберпреступниками инструменты сходны по функциональности и по структуре, входящих в их состав, вредоносных драйверов.

Foresight Day’2023: импортозамещение продолжается
Импортонезависимость

Специалисты Mandiant выяснили, что для подписи вредоносных драйверов использовались сертификаты, выданные китайским компаниям: Qi Lijun; Luck Bigger Technology Co., Ltd; XinSing Network Service Co., Ltd; Hangzhou Shunwang Technology Co., Ltd; Fuzhou Superman; Beijing Hongdao Changxing International Trade Co., Ltd; Fujian Altron Interactive Entertainment Technology Co., Ltd; Xiamen Hengxin Excellence Network Technology Co., Ltd; Dalian Zongmeng Network Technology Co., Ltd.

Обновления Windows для защиты от RDP уязвимости BlueKeep

Microsoft выпустила обновления для всех ОС Windows, подверженных уязвимости CVE-2019-0708 (BlueKeep). Патчи доступны для загрузки в каталоге обновлений Microsoft.

Несмотря на то, что Microsoft прекратила поддержку Windows XP и Windows Server 2003, для защиты от BlueKeep были выпушены обновления и для этих устаревших систем. Что лишний раз подчеркивает серьезность найденной уязвимости и высокий риск ее массовой эксплуатации.

Ниже приведены прямые ссылки на ручную загрузку обновлений для популярных версий Windows:

KB4500331:

Windows XP SP3 x86, x64 Windows XP Embedded, Windows Server 2003 SP2 x86, x64 — https://www.catalog.update.microsoft.com/Search.aspx?q=KB4500331

KB4499175:

Windows Server 2008 R2 SP1 и Windows 7 SP1 x64 — windows6.1-kb4499175-x64_3704acfff45ddf163d8049683d5a3b75e49b58cb.msu
Windows 7 x86 SP1 — windows6.1-kb4499175-x86_6f1319c32d5bc4caf2058ae8ff40789ab10bf41b.msu

В Windows XP и 2003 обновления kb4500331 придется устанавливать вручную.

Для Windows 7 и Windows Server 2008 R2 обновление KB4499175 уже доступно для установки через WSUS (в зависимости от настроек одобрения обновлений) и Microsoft Update. Но вы можете установить его и вручную из msu файла с помощью wusa.exe:

wusa.exe «C:Installwindows6.1-kb4499175-x64_3704acfff45ddf163d8049683d5a3b75e49b58cb.msu» /quiet /warnrestart

Quick Review of Refresh Rect PDU and RDPDR Client Name Request PDU

Our last blog about BlueKeep introduced Refresh Rect PDU and RDPDR Client Name Request PDU in Windows RDP protocols in detail. Here is a quick review of those two PDUs.

Refresh Rect PDU can be used to spray many 0x828-sized kernel pools by sending PDUs multiple times. Those 0x828-sized kernel pools will be aligned by 0x1000 offset, and there are eight bytes of data controlled by RDP Client at offset 0x2c in each 0x828-sized kernel pool. The start address of eight bytes-controlled data looks like 0x8xxxx02c. During our testing, the 0x828-sized kernel pools are groomed consecutively from the address 0x86000000 to 0x8a000000 with the 0x1000-sized kernel pool aligned on our VMware virtual machine. In the exploitation proof of concept (PoC), we used 0x86c1002c as the fixed address to store a function pointer and got a very high success rate when re-exploiting multiple times and when restarting systems. The address 0x88xxx02c and 0x89xxx02c are also good candidates that perform very well in high memory consumption targets, such as RDP servers running a lot of applications at the same time.

RDPDR Client Name Request PDU can be used to reclaim the freed channel object with controlled data by sending PDUs multiple times. The size and data of the kernel pool allocated when the RDP server parses Client Name Request PDU are both controllable. We can make the RDP server allocate the 0xd0-sized kernel pool to claim the freed MS_T120 channel object. By spraying the kernel pool with the specifically crafted data, we can control the reuse route to execute a function call with a controllable function pointer and thus control extended instruction pointer (EIP). We can also use Client Name Request PDU to write the shellcode into the kernel pool since the size and data of Client Name Request PDU are both controllable by the RDP client. All the details about how those two PDUs are used in the exploit will be discussed in the following sections.

Виды уязвимостей удаленного доступа

По опыту ИБ-специалистов ITGLOBAL.COM, немалая часть векторов атаки на корпоративную сеть компании извне связана с уязвимостями веб-приложений. Здесь возможны и недостатки в конфигурации ПО — например, примитивные настройки политик доступа, упрощенный алгоритм регистрации новых пользователей и т. п., — и то, что сотрудникам разрешается использовать простые пароли для входа. Всё это облегчает задачу злоумышленникам, которые стремятся проникнуть во внутреннюю сеть компании — например, в Intra- портал, где хранится коммерческая информация.

Также популярна эксплуатация уязвимостей в протоколах и ПО, которые используются для удаленного доступа. Примеры: ошибка безопасности в ОС Windows — в версиях 7, Server 2008 и Server 2008 R2, — известная как BlueKeep (код CVE-2019-0708), ошибка CVE-2019-19781 в ПО Citrix, уязвимость фреймворка Laravel (CVE-2018-15133), а также ряд уязвимостей сетевого оборудования для VPN-соединений.

Разумеется, компании, у которых есть собственный отдел ИБ скорее всего закрывают известные «дыры» и ошибки. Однако даже квалифицированные безопасники вряд ли могут защитить от уязвимостей нулевого дня. Стоит ли говорить о рисках для компаний, у которых нет в штате специалиста по ИБ, и не налажено даже элементарное обновление приложений и ОС.

Reuse After Free

We have discussed how the MS_T120 channel object is freed, leaving a dangling pointer to the MS_T120 channel object in the ChannelPointerTable object. Now we will cover how to reuse the freed object. In the function termdd!IcaChannelInput, the function IcaFindChannel will be called to find the channel object. When the RDP client terminates the connection, the second argument slot_base will be 0x05 and the third argument slot_index will be 0x1f, and so the function IcaFindChannel will set the freed MS_T120 channel object as the return value. If the freed MS_T120 channel object is reclaimed with a fake MS_T120 channel object, the following function execution route can be controlled with a function call (call ) in which the function pointer (register eax) is obtained from inside the fake MS_T120 channel object, as shown in Figure 7.

Figure 7. Reuse route in IcaChannelInputInternal.

Как проходит аттестация драйверов Windows

В операционных системах Windows актуальных версий драйверы режима ядра (kernel-mode hardware drivers) при загрузке получают наивысший уровень привилегий в ОС. Оказавшись под контролем злоумышленника, такой драйвер способен на выполнение множества операций, недоступных программам, запущенным в пространстве пользователя. В числе таких операций – вывод из строя антивирусного ПО, удаление защищенных системой файлов, а также маскировать другие процессы в системе, ведя себя как руткит.

В 2015 г. Microsoft предупредила производителей «железа» о том, что с выходом Windows 10 все новые драйверы режима ядра должны будут в обязательном порядке получать цифровую подпись компании через Windows Hardware Developer Center (WHDC; центр разработки оборудования Windows).

Однако на деле соответствующие меры по обеспечению безопасности вступили в силу лишь в июле 2016 г., и с тех пор неподписанные драйверы Windows устанавливать отказывается.

Процедура аттестации драйвера Microsoft является многоступенчатой и довольно сложной. Так, разработчику для ее прохождения совершенно необходимо приобрести сертификат EV (Extended Validation; дополнительная проверка). Процедура его получения предусматривает подтверждение доверенным центром сертификации факта существования компании, на имя которой тот оформляется, и принадлежности этой компании сертифицированных доменных имен.

Затем разработчик должен привязать полученный EV-сертификат к учетной записи участника Windows Hardware Developer Program (WHDP; программа разработки оборудования Windows). После этого драйвер, нуждающийся в подписи, отправляется в Microsoft через партнерский портал для дальнейшей проверки на совместимость и наличие вредоносного содержимого. В случае ее успешного прохождения драйвер получает электронную подпись Microsoft (Microsoft Hardware Compatibility Publisher), поясняют в SentinelOne.

Разработчики многих ИБ-решений считают эту процедуру достаточно надежной и поэтому их продукты полностью доверяют ПО, подписанному Microsoft. Таким образом, для злоумышленника наличие возможности подписывать собственные драйверы уровня ядра с помощью сертификата Microsoft представляет огромную ценность.

Защита от уязвимости BlueKeep CVE-2019-0708

Для защиты от CVE-2019-0708 (BlueKeep) Microsoft рекомендует незамедлительно устанавливать обновления безопасности (перечисленные в следующем разделе). Чтобы снизить риски уязвимости в системах перед установкой обновления во внешний периметр, рекомендуются следующие действия:

Временно отключите RDP-доступ к компьютерам и отключите службы удаленных рабочих столов или заблокируйте внешний RDP-доступ на межсетевых экранах периметра сети и отключите перенаправление портов RDP в локальную сеть;
Включить поддержку аутентификации на сетевом уровне (NLA – Network Level Authentication) в настройках RDP на компьютере) – можно настроить как в Windows 7/2008 R2, так и в Windows XP SP3. При включенном NLA для реализации уязвимости злоумышленник должен сначала пройти аутентификацию в службах удаленных рабочих столов, используя действительную учетную запись (атака может быть реализована только с легитимным пользователем).

Conclusion

This blog outlines how to get system privilege RCE with Refresh Rect PDU and RDPDR Client Name Request PDU for the Windows RDP vulnerability CVE-2019-0708 (BlueKeep). The 4 bytes shellcode slider in shellcode stage 0 and the shellcode egg hunter in shellcode stage one are general exploit techniques and could be used in all Windows RDP vulnerability exploitations. The deep research on the kernel pool Feng Shui techniques with RDP PDUs and Windows RDP exploit techniques will help defenders to better protect all Windows users from Windows RDP attacks.

Palo Alto Networks customers are protected from BlueKeep:

Cortex XDR prevents exploitation of this vulnerability on Windows XP, Windows 7 and Windows Server 2003 and 2008.
Next-Generation Firewall with a Threat Prevention security subscription detects the vulnerability.

Get updates from Palo Alto Networks!

By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.

Критическая уязвимость в службе удаленного рабочего стола Windows и защита от нее с помощью КриптоПро NGate

Публикация: 17 Май 2019 — 09:39, редакция: 17.05.2019 10:23

Суть уязвимости

14 мая 2019 года (ровно через 2 года и 2 дня с момента массового распространения WannaCry) Microsoft сообщила о наличии критической уязвимости CVE-2019-0708 в реализации Remote Desktop Services (RDS – службы удаленного рабочего стола) в Windows, которая позволяет атакующему через протокол RDP удаленно выполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows – от Windows XP (Windows Server 2003) до Windows 7 (Windows Server 2008 R2).

Для эксплуатации уязвимости необходим только сетевой доступ к хосту и наличие на нем включенной службы RDS (не заблокированной межсетевым экраном). Т.е. если ваш Windows хост доступен из интернета через RDP, то уязвимость может быть эксплуатирована кем угодно. Уязвимость реализуется за счет отправки специального запроса к RDS через RDP, без аутентификации. После реализации уязвимости атакующий может удаленно выполнить произвольный код на целевой системе с правами SYSTEM.

Microsoft отмечает, что есть весьма высокая вероятность появления автоматических червей, которые будут использовать уязвимость в RDS для распространения в локальных сетях. Вполне возможно, что распространение будет иметь масштабы, близкие к WannaCry.

Как от нее защититься?

Для защиты от уязвимости Microsoft рекомендует временно или на постоянной основе (если RDP не требуется) отключить RDP-доступ к хостам и отключить службу RDS. Кроме этого рекомендуется как можно быстрее установить необходимые обновления безопасности, даже если вы планируете оставить на своих хостах службу RDS отключенной.

Если же отключить на хостах RDP доступ и службу RDS по каким-то причинам нельзя, то до момента установки необходимых обновлений, Microsoft рекомендует:

Включить поддержку Network Level Authentication (NLA — проверку подлинности на уровне сети – в настройках RDP на хостах). При включенной NLA для реализации уязвимости атакующему сначала нужно аутентифицироваться в службе.

либо

Заблокировать внешний доступ по RDP на периметровом FW и отключить проброс RDP порта (TCP 3389) в локальную сеть. Это позволит защитить хосты от эксплуатации уязвимости атакующими из-за пределов внутренней сети, однако хосты по-прежнему останутся уязвимыми из пределов внутренней сети.

Если использование RDP для удаленных подключений нужно и важно для вас и вы не готовы отказаться от него, то для исключения риска реализации уязвимости из-за пределов внутренней сети, RDP-подключения достаточно защитить с помощью средств VPN – и тут отлично подойдет TLS-шлюз удаленного доступа и VPN: КриптоПро NGate. Почитать о нем можно тут и тут

В этом случае:

Отпадает необходимость отключения RDP-доступа и RDS-службы на хостах. При этом пользователи продолжают пользоваться RDP как и раньше;
Не требуется включение поддержки NLA;
Не требуется блокирование внешнего доступа по RDP на периметровом FW и отключение проброса RDP порта в локальную сеть, т.к. использование VPN-шлюза не подразумевает публикацию RDP наружу.

При этом установка обновлений безопасности на хосты потребуется для исключения риска реализации уязвимости из пределов внутренней сети.

Почему это так важно?

О том, что стоит уделить особое внимание вопросам нейтрализации рассматриваемой уязвимости, свидетельствует, в частности, то, что Microsoft выпустила обновления для всех ОС Windows, подверженных рассматриваемой уязвимости, включая устаревшие и уже не поддерживаемые ОС Windows XP и Windows Server 2003 – это говорит о серьезности найденной уязвимости и высоком риске ее массовой эксплуатации

Reclaim the Freed MS_T120 Channel Object With RDPDR Client Name Request PDU and Control EIP

In this section, details about how to reclaim the freed MS_T120 channel object to control EIP will be discussed. The size of the freed MS_T120 Channel is 0xc8 (0xd0 including 8 bytes pool header), as shown in Figure 5. The termdd!IcaChannelInputInternal function will allocate channel_data_size+0x20-sized kernel pool, as shown in Figure 19 of our previous blog. The size of the Client Name Request PDU needs to be set to 0xa8 (0xc8-0x20), and the ComputerNameLen field needs to be set to 0x98 accordingly if we want the function termdd!IcaChannelInputInternal to allocate the 0xc8-sized kernel pool. Considering that there is a memory copy operation after successful pool allocation, by sending those Client Name Request PDUs multiple times, we ensure the freed MS_T120 pool slot has been occupied by the Client Name Request PDU data. Moreover, the first 0x20 bytes of the 0xc8-sized kernel pool is for the internal use of the termdd module, which means the first 0x20 bytes are not controllable, and the following 0x10 bytes that are for the Client Name Request PDU header are also not controllable, so the controllable data size is 0x98 (0xc8-0x20-0x10) in total. Figure 8 shows how the RDP client constructs the RDPDR Client Name Request PDU.

Figure 8. RDPDR Client Name Request to reclaim the freed MS_T120 channel object.

Figure 9 shows the memory dump of the fake MS_T120 channel object created by sending RDPDR Client Name Request PDU. Several important fields in the fake MS_T120 channel object are labeled in different colors. The 4 bytes (DWORD) value of 0x00000000 in green is set to prevent service from crashing in hal!KeAcquireInStackQueuedSpinLockRaiseToSynch, which is called by ExEnterCriticalRegionAndAcquireResourceExclusive. The DWORD value of 0x00000000 in light blue is set to ensure condition check and make the function route arrive at the function call (call ) with the controlled function pointer eax, as shown in Figure 7.

Figure 9. Fake MS_T120 channel object.

The DWORD value 0x86c10030 in purple is set at the offset 0x8c of the fake MS_T120 channel object, as shown in Figure 9. The debug log in Figure 10 shows how to get the fake object address at the offset 0x8c and make a function call (call ) to control EIP.

Figure 10. Function call with controlled function pointer in IcaChannelInputInternal.Now that we’ve shown how the EIP is controlled, we will discuss why the eax is set to the address 0x86c10030 and the EIP is set to the address 0x86c1002c. With the technique described in the previous section, we are able to get a stable spray from the address 0x86xxxxxx to 0x8axxxxxx. There are 8 bytes data controllable at the offset 0x002c in each aligned 0x1000 address, as shown in Figure 11.

Figure 11. Stable spray with Refresh Rect PDU.

The code snippet in Figure 12 shows how the RDP client constructs the Refresh Rect PDUs and how many times it needs to send them to the RDP server.

Figure 12. How to construct Refresh Rect PDU to spray in the RDP client.

In the 8 bytes of controllable data in each aligned 0x1000 sized kernel pool, 4 bytes at offset 0x0030 (0x86c10030) are set to 0x86c1002c, which is the hard-coded address of stage 0 shellcode. The other 4 bytes at offset 0x002c (0x86c1002c) are used to store the stage 0 shellcode. The next section will introduce more details about the several stages of shellcodes.