www.cyberark.com Open in urlscan Pro
104.17.196.105 Public Scan

Back to summary

URL:
https://www.cyberark.com/resources/threat-research-blog/explain-like-i-m-5-remote-desktop-protocol-rdp
Submission: On April 16 via manual (April 16th 2023, 1:36:57 pm UTC) from IL — Scanned from DE

Form analysis
1 forms found in the DOM

GET https://www.cyberark.com/

<form role="search" method="get" class="ubermenu-searchform" action="https://www.cyberark.com/">
  <input type="text" placeholder="What can we help you find?" value="" name="s" class="ubermenu-search-input">
  <button type="submit" class="ubermenu-search-submit"><i class="fas fa-search" title="Search"></i></button>
</form>

Text Content

* Blogs
* Marketplace
* Partners
* Careers

*
* Why CyberArk
* * Identity Security Leader

Security-forward identity and access management.

Why CyberArk
* * CyberArk Labs

The industry’s top talent proactively researching attacks and trends to
keep you ahead.

--------------------------------------------------------------------------------

* Blogs

Insights to help you move fearlessly forward in a digital world.

--------------------------------------------------------------------------------

* Careers

Join a passionate team that is humbled to be a trusted advisor to the
world's top companies.

--------------------------------------------------------------------------------
* * Financial

"CyberArk delivers great products that lead the industry."

Read Case Studies

* Products
* * Identity Security Platform

Put security first without putting productivity second.

Explore Platform
* * Privilege

* --------------------------------------------------------------------------------

* Privileged Access Manager
* Vendor Privileged Access Manager
* Cloud Entitlements Manager
* Endpoint Privilege Manager
* * Access

* --------------------------------------------------------------------------------

* Workforce Identity
* Customer Identity
* * DevSecOps

* --------------------------------------------------------------------------------

* Conjur Secrets Manager Enterprise
* Conjur Secrets Manager Open Source
* Credential Providers
* QUICK LINKS
* Marketplace

* Solutions
* * * By Business Initiative
* * Defend Against Attacks
* Defend Against Attacks
* Defense-in-Depth
* Ransomware Protection
* Secure DevOps Pipelines and Cloud Native Apps
* Zero Trust
* Satisfy Audit & Compliance
* Satisfy Audit & Compliance
* * Drive Operational Efficiencies
* Drive Operational Efficiencies
* Secure Cloud Workloads
* Remote Workforce Access
* Enable the Digital Business
* Enable the Digital Business
* Secure Bots and Virtual Agents
* By Industry
* Banking

Safeguard customer trust and drive stronger engagement.

--------------------------------------------------------------------------------

* Insurance

Create a competitive edge with secure digital innovation.

--------------------------------------------------------------------------------

* Healthcare

Keep ransomware and other threats at bay while you secure patient
trust.

--------------------------------------------------------------------------------

* Federal

Ensure sensitive data is accessible to those that need it - and
untouchable to everyone else.

--------------------------------------------------------------------------------

* Services & Support
* * How Can We Help?

Expert guidance from strategy to implementation.

Services & Support
* * * CUSTOMER SUCCESS

* --------------------------------------------------------------------------------

* Customer Stories
* CyberArk Blueprint
* Success Plans
* * LEARNING

* --------------------------------------------------------------------------------

* Training
* Certification
* Education Resources
* * SERVICES

* --------------------------------------------------------------------------------

* Security Services
* Red Team Services
* Remediation Services
* * RESOURCES

* --------------------------------------------------------------------------------

* Technical Community
* Technical Support
* Product Documentation

* Try & Buy
* * Try and Buy

Get started with one of our 30-day trials.

Start a Trial
* * How to Buy

Evaluate, purchase and renew CyberArk Identity Security solutions

--------------------------------------------------------------------------------

* Contact Us

How can we help you move fearlessly forward?

--------------------------------------------------------------------------------

* Identity Security Subscriptions

Learn more about our subscription offerings.

--------------------------------------------------------------------------------

* Request a Demo
* *

* Blogs
* Partners
* Marketplace
* Careers
* Menu Item

* Deutsch
* Français
* Italiano
* Español
* 日本語
* 简体中文
* 繁體中文

English – CyberArk Software Inc

UP YOUR SECURITY I.Q. BY CHECKING OUT OUR COLLECTION OF CURATED RESOURCES.

English – CyberArk Software Inc
* Products & Services

* Products & Services
* Privileged Access Manager Self-Hosted
* CyberArk Identity
* Cloud Entitlements Manager
* Vendor Privileged Access Manager
* Conjur Secrets Manager Enterprise
* Endpoint Privilege Manager
* CyberArk Privilege Cloud
* Assessment Tools
* Services & Support
* Topics

* Topics
* Automate Privileged Tasks
* Best Practices for Privileged Access Management
* Meet Audit and Compliance
* Mitigate Risk With Just-in-Time and Least Privilege
* Remove Local Admin Rights on Workstations
* Secure Application Credentials
* Secure Cloud Environments
* Secure DevOps Pipelines and Cloud Native Apps
* Secure Human Privileged Access
* Secure RPA Workloads
* Secure Third-Party Vendor and Remote Access
* Secure Workforce Access
* Threat Research
* Industry

* Industry
* Financial Services & Insurance
* Healthcare
* Public Sector & Government
* Content Type

* Content Type
* Analyst Reports & Research
* Blog Posts
* Case Studies
* eBooks
* Infographics
* On-Demand Events & Webinars
* Product Announcements
* Product Datasheets
* Solution Briefs
* Videos
* Whitepapers
* Customer Stories

Resource Menu
×

All » Threat Research Blog » Explain Like I’m 5: Remote Desktop Protocol (RDP)
× Share this Article
* Facebook
* Twitter
* Email
* LinkedIn

EXPLAIN LIKE I’M 5: REMOTE DESKTOP PROTOCOL (RDP)

Shaked Reiner4/7/20
* Share this!
* Facebook
* Twitter
* Email
* LinkedIn

TABLE OF CONTENTS

* Introduction
* RDP Connection
* Connection Sequence | Basic Input and Output
* Channels in RDP | Data Compression
* RDP Security | Recent RDP Vulnerabilities
* Conclusion
* References

INTRODUCTION

RDP is an extremely popular protocol for remote access to Windows machines. In
fact, there are more than 4.5 million RDP servers exposed to the internet alone,
and many more that are accessible from within internal networks.

The importance of knowing and understanding RDP has never been greater –
especially in light of the recent critical vulnerabilities that were found in
the protocol. It is now essential knowledge that is absolutely crucial for
everyone in the security industry. RDP is a complex protocol with many
extensions and the potential of finding new critical bugs is still high. This is
why the security industry needs to educate itself about it.

RDP is relevant now more than ever, having Microsoft’s Azure and Hyper-V
platforms using it as the default remote connection protocol and having the
interest in this protocol by attackers rise, both as an initial infection vector
and as a propagation method.

Since we weren’t able to find a digestible overview of this protocol, in this
article we’ll walk through the basics of RDP, how they work, and how some of the
critical vulnerabilities found in RDP fit into the bigger picture of an actual
RDP connection. Our hope is that you’ll walk away with a basic understanding of
the protocol so you can continue reading and researching further about the
protocol for any future needs.

RDP: THE BASICS

> “The Microsoft Remote Desktop Protocol (RDP) provides remote display and input
> capabilities over network connections for Windows-based applications running
> on a server.” (MSDN)

Essentially, RDP allows users to control their remote Windows machine as if they
were working on it locally (well, almost).

Figure 1: What is RDP?

Communication in RDP is based on multiple channels, and the protocol
theoretically supports up to 64,000 unique channels.

The basic functionality of RDP is to transmit a monitor (output device) from the
remote server to the client and the keyboard and/or mouse (input devices) from
the client to the remote server. The communication during an RDP connection will
be extremely asymmetric, while most of the data will go from the server to the
client. RDP communication is encrypted with RSA’s RC4 block cipher by default.

Figure 2: Asymmetric communication

Before we get into how an RDP connection actually works, let’s examine the
protocols/standards on which RDP relies. The RDP protocol stack looks as
follows:

Figure 3: Protocol stack

TPKT is known as the ISO Transport Service on top of TCP. TPKT enables peers to
exchange information units that are known as Transport Protocol Data Units (TPDU
or PDU).

X.224 is a Connection-Oriented Transport Protocol, it provides a connection-mode
transport service. RDP uses it in the initial connection request and response.

T.125 MCS is a Multipoint Communication Service. It allows RDP to communicate
through and manage multiple channels.

Sending and receiving data through the RDP stack is essentially the same as the
7 layer OSI model for communication. The data transmitted is sectioned, directed
to a channel, encrypted, wrapped, framed and packaged before going over the wire
to the other party, then it goes through the same process in reverse.

The implementation of MS RDP has abstracted all of the complexity of the
protocol stack, and it allows developers to write extensions to the protocol
easily.

RDP CONNECTION

In this part, we’ll explain the basics of an RDP connection. Keep in mind that
for the sake of simplicity, some details were left out. For more information
about the connection (including exact structures, constants, etc.) please see
[MS-RDPBCGR].

CONNECTION SEQUENCE

Figure 4: Connection stages

The RDP connection can be broken down into a few stages:

1. Connection Initiation
2. Basic Settings Exchange
3. Channel Connection
4. Security Commencement
5. Secure Settings Exchange
6. Licensing
7. Capabilities Exchange
8. Connection Finalization
9. Data Exchange

CONNECTION INITIATION

Figure 5: Connection initiation

The RDP connection is initiated by the client using an X.224 Connection request
PDU. This packet contains an RDP Negotiation Request that holds a few connection
flags and the security protocols supported by the client. Those security
protocols can be in one of two categories:

Standard RDP Security

* Default of RSA’s RC4 encryption

Enhanced RDP Security

* TLS
* CredSSP (TLS + NTLM/Kerberos)
* RDSTLS – RDP enhanced with TLS

More information about RDP Security is available in the next section.

The connection is confirmed by the server using an X.224 Connection Confirm PDU.
This packet contains the RDP Negotiation Response which is used to inform the
client of the selected security protocol (chosen from the client’s supported
protocols) that will be used throughout the entire connection lifetime.

From this point on, subsequent data will be wrapped in an X.224 Data PDU.

BASIC SETTINGS EXCHANGE

Figure 6: Basic settings exchange

At this stage, basic settings are exchanged between the client and the server
using an MCS Connect Initial PDU and an MCS Connect Response PDU (respectively).
These settings (both from the client and the server) include:

* Core Data – RDP Version, Desktop resolution, color depth, keyboard
information, hostname, client software information (product ID, build
number), etc.
* Security Data – Encryption methods, size of session keys, server random (used
later to create session keys) and server’s certificate (some of this is only
relevant when using Standard RDP Security).
* Network Data – Information about the requested and allocated virtual
channels. This contains the number of channels and an array of specific
virtual channels. The client requests the exact type of channels in the
request, and the server supplies the actual channel IDs in the response. For
more information about those channels see the Channels in RDP section below.

CHANNEL CONNECTION

Figure 7: Channel connection

After establishing the list of virtual channels that will be used in the RDP
session, here comes the stage at which every individual channel connection is
made. This has a few sub-stages:

1. MCS Erect Domain Request – Height in the MCS Domain. Since RDP doesn’t take
advantage of advanced MCS topologies, it will be 0.
2. MCS Attach User Request – request for a User Channel ID
3. MCS Attach User Confirm – ID of the User Channel
4. (+5) MCS Channel Join Requests and Confirmations – The client will start to
request joining the virtual channels by using their IDs. Starting with the
User Channel, I/O Channel and continuing with the virtual channels
negotiated in the basic settings exchange. The server will, in turn, confirm
every successful channel join.

From this point on, subsequent data sent by the client will be wrapped in an MCS
Send Data Request PDU, while data sent by the server will be wrapped in an MCS
Send Data Indication PDU. Data can now be redirected to virtual channels.

SECURITY COMMENCEMENT

Figure 8: Security commencement

The client sends a Security Exchange PDU containing the client random encrypted
with the server’s public key. The client and server then use the random numbers
(both from the Basic Settings Exchange’s Security Data and from the Security
Exchange PDU) in order to create session encryption keys.

From this point on, subsequent RDP traffic can be encrypted.

SECURE SETTINGS EXCHANGE

Figure 9: Secure settings exchange

At this point, the client sends an encrypted Client Info PDU containing
information about supported types of compression, user domain, username,
password, working directory, etc.

LICENSING

Figure 10: Licensing

This stage is designed to allow authorized users to connect to a terminal
server. That is to support more than 2 simultaneous connections (which is the
default for “Windows’ RDP Server”) to a server. This requires purchasing a
license from Microsoft.

In a lot of cases, no licensing server is configured for the RDP server, in that
case, the RDP server will simply send a PDU to the client that “approves” its
license (up to 2 sessions only).

You can find more information about the extended licensing phase and the
communication between the RDP server and the license server here [MS-RDPELE].

CAPABILITIES EXCHANGE

Figure 11: Capabilities exchange

The server sends its supported capabilities in a Demand Active PDU. This PDU
contains a structure that has many capabilities of different types. According to
Microsoft, we have 28 types of capability sets. Major types are general (OS
version, general compression), input (keyboard type and features, fast-path
support, etc.), fonts, virtual channels, bitmap codecs and many more. Then, the
server may or may not send a Monitor Layout PDU to describe the display monitors
on the server. The client will then respond with a Confirm Active PDU containing
its own set of capabilities.

CONNECTION FINALIZATION

Figure 12: Connection finalization

The client and the server exchange a few types of PDUs in order to finalize the
connection. All those PDUs originate from the client (PDU can be sent one after
the other without waiting for a response). The PDUs are:

* Client/Server Synchronize PDU – Used to synchronize user identifiers between
the client the server.
* Client/Server Control PDU (Cooperate) – Both the client and the server send
this PDU to indicate shared control over the session.
* Client Control PDU (Request/Grant Control) – Client sends the request for
control, server grants it.
* Persistent Key List PDU/PDUs (optional) – The client sends the server a list
of keys, each key identifies a cached bitmap. This enables the bitmap cache
to be persistent (as opposed to being limited to the lifetime of the
connection). Bitmap caching is a mechanism used to reduce network traffic
needed to transfer a graphical output from the server to the client.
* Font List/Map PDU – these PDUs were meant to hold information about fonts for
the RDP session (font name, average width, signature, etc.), however, it
seems like Microsoft is not using it. Having said that, those PDUs are still
exchanged between the client and the server at that point, but with no actual
data in it (even if there was any data, Microsoft’s documentation specifies
you should ignore it).

DATA EXCHANGE

Figure 13: Data exchange

After the connection has been finalized, the major part of the data sent between
the client and the server will be input data (client->server) and graphics data
(server->client). Additional data that can be transferred includes connection
management information and virtual channel messages.

BASIC INPUT AND OUTPUT

During the lifetime of the connection, the client and the server exchange basic
input/output data. The client is sending the input and the server sends the
output.

Input Data – This contains mouse and keyboard information, as well as periodic
synchronization (e.g. NAM_LOCK / CAPS_LOCK keys state)

Output Data – The fundamental output data contains bitmap images of the user’s
session on the server. In addition, the server can send sound information (only
in the form of very basic “beep” – frequency + duration).

This basic input/output data can be transmitted in one of two ways: slow-path or
fast-path.

Slow-Path – Normal PDU with all RDP protocol stack headers

Fast-Path – As the name suggests, it was created to reduce both the amount of
data transmitted and the amount of processing required to process it. This is
done by reducing/removing PDU headers from certain PDU types (e.g.
keyboard/mouse input).

CHANNELS IN RDP

In RDP, most of the data is being transported through different channels (MCS
Layer). There are two main types of channels: Static Virtual Channels and
Dynamic Virtual Channels.

STATIC VIRTUAL CHANNELS (SVC)

SVCs allow communication between different client and server components over the
main RDP data connection. There is a maximum of 31 Static Virtual Channels per
connection and each channel acts as an independent data stream. Those channels
are static because they are requested and created at the Basic Settings Exchange
phase during the connection initiation, and they do not change at all during the
session.

Not all SVCs are created equal, some are opened by default, and some are
negotiated during the Basic Settings Exchange Phase. The SVCs that are being
created by default are crucial to the functionality of an RDP connection, while
the others enable different extensions for the protocol.

Examples for SVCs created by default:

* I/O Channel
* Message Channel
* User Channel
* Server Channel

Extension SVCs are identified by an 8-byte name, for example:

* rdpdr – Filesystem extension. Allows the redirection of access from the
server to the client file system.
* rdpsnd – Sound output extension.
* cliprdr – Clipboard extension. Allows sharing the clipboard between the
client and the server.
* drdynvc – Dynamic Virtual Channel Extension (see DVCs below)

All the SVCs channel IDs are supplied during the Basic Settings Exchange phase
excluding 2 SVCs: the User Channel which is supplied during the Channel
Connection phase in the Attach User Confirm PDU, and the Server Channel which
has a fixed value of 0x03EA (1002).

DYNAMIC VIRTUAL CHANNELS (DVC)

Since the Static Virtual Channels number is limited to 31, RDP also supports
Dynamic Virtual Channels. Dynamic Virtual Channels are transported over one
specific Static Virtual Channel – DRDYNVC. Those channels are dynamic since you
can create and destroy them at any stage of the connection lifetime (after
initialization). Developers can create extensions that will transport data over
a Dynamic Virtual Channel quite easily. Common uses for DVCs are audio input
(client -> server), PnP redirection, graphics rendering, echo channel, video
redirection and more.

The following figure describes the relationship between the different types of
channels in RDP:

Figure 14: Channels hierarchy

DATA COMPRESSION

RDP can use compression in output data (both fast-path and slow-path) and in
virtual channels. Both the client and the server need to support compression in
general, and the specific type of compression negotiated for the connection. The
client advertises the compression types it supports in the Client Info PDU
during the Secure Settings Exchange.

Every PDU that contains compressed data, needs to have some compression flags
(containing the type of compression, etc.) set in the header of that specific
PDU.

RDP SECURITY

As mentioned briefly before, the security of the RDP protocol can be one of two
types:

STANDARD SECURITY

Traffic is encrypted using RSA’s RC4 encryption algorithm, using client and
server random values that are exchanged during the Basic Settings Exchange phase
in the connection initialization.

ENHANCED SECURITY

This type of security enables RDP to outsource all security operations
(encryption/decryption, integrity checks, etc.) to an external security
protocol. This can be one of the following:

* TLS 1.0/1.1/1.2
* CredSSP
* RDSTLS

Deciding on an enhanced security protocol can be either negotiation-based or
direct. The negotiation-based means that the connection initialization (x.224
connection request and response) is outside of the scope of the security
protocol. After the initialization, the client and server choose a security
protocol, do the external security protocol handshake and from now on all the
other stages of the RDP connection will be encapsulated within that external
security protocol.

The other option – the direct approach favors security over compatibility. In
this approach, the client will start with the external security protocol
handshake before sending any RDP related data.

Choosing enhanced security means that the Security Commencement stage will not
be executed.

The key benefit of using RDP Enhanced Security is that it enables Network Layer
Authentication (details available below).

NETWORK LEVEL AUTHENTICATION

Network Level Authentication (NLA) refers to the usage of CredSSP to
authenticate the user before the initiation of the RDP connection. This allows
the server to dedicate resources only to authenticated users.

In case of a critical vulnerability in the RDP protocol, NLA can limit the
exploitation of this vulnerability to authenticated users only.

RECENT RDP VULNERABILITIES

Now that we understand the basics on the RDP protocol, let’s review some of the
more recent critical vulnerabilities that were found, and see how they fit into
the bigger picture of the RDP protocol.

BLUEKEEP

BlueKeep (CVE-2019-0708) is an RCE vulnerability in Microsoft’s RDP server,
affecting Windows machines from Windows 2000 to Windows 7 and Windows Server
2008 R2. It was found and patched in May of 2019. This vulnerability is a
use-after-free that was present in the Windows kernel driver that handles RDP
connections – termdd.sys.

This vulnerability could be exploited in the connection initialization phase of
RDP. As mentioned before, during the Basic Settings Exchange the client and
server negotiate which static virtual channels to initialize for the connection
and there are channels that will be allocated to the connection regardless of
the client’s request, including the MS_T120 channel.

termdd.sys creates a table that contains a pointer to a channel structure for
every created channel. This table holds up to 32 (0x20) Channels. The Static
Virtual Channel MS_T120 is created by default, and it’s always at index 0x1F.
This happens even before the connection sequence begins.

In order to trigger this vulnerability, one needs to create a custom RDP client,
that will request for a static virtual channel named MS_T120 in the Basic
Settings Exchange. If such channel is requested, the RDP server will then try to
find out if this channel has already been created for this connection. If so, it
will return the pointer to the existing channel control structure instead of
creating a new one. At this point, we’ll have two pointers pointing to one data
structure and the connection channels array will look like this:

Figure 15: Structures in memory

To trigger the bug, the RDP client must send a packet that will cause the server
to close the MS_T120 channel (legitimate and documented behavior). After closing
the channel, the server will go ahead and free the channel control structure of
MS_T120, and the pointer to it in the connection channels array, but only the
one created due to the client request (not the one created automatically by the
server). Now we have a dangling pointer, and the next time the server will try
to access the MS_T120 channel (which happens often since this is a crucial
channel to the operation of RDP), the system will bug check.

Figure 16: BlueKeep illustration

Since this vulnerability has quite a few write-ups by now, I’ll leave some
references for anyone who’s interested in getting all the technical details for
triggering and exploiting it.

References:

* https://www.zerodayinitiative.com/blog/2019/5/27/cve-2019-0708-a-comprehensive-analysis-of-a-remote-desktop-services-vulnerability
* https://unit42.paloaltonetworks.com/exploitation-of-windows-cve-2019-0708-bluekeep-three-ways-to-write-data-into-the-kernel-with-rdp-pdu/
* https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html
* https://www.coresecurity.com/blog/low-level-reversing-bluekeep-vulnerability-cve-2019-0708
* https://blog.tetrane.com/2020/01/22/bluekeep.html

DEJABLUE

DejaBlue (CVE-2019-1181 & CVE-2019-1182) is another RCE vulnerability in
Microsoft’s RDP server (hence the name) discovered in 2019. This time, the
vulnerability affected all versions of Windows (7-10) up until the patch.
DejaBlue is an integer overflow vulnerability that was present in a core DLL of
the RDP server – RDPCoreTS.dll / RDPBase.dll (depending on the Windows version).

The vulnerability lies in the function that decompresses data sent over a
Dynamic Virtual Channel (DVC). Compressed data in a DVC is sent in either a
DYNVC_DATA_FIRST_COMPRESSED / DYNVC_DATA_COMPRESSED PDU. The actual data in any
of those PDUs is in the form of RDP_SEGMENTED_DATA that can contain multiple
segments. A compressed RDP_SEGMENTED_DATA will contain the data
uncompressedSize.

When the RDP server receives a compressed DVC PDU, it’ll call a function that
will decompress it – DecompressUnchopper::Decompress(). The decompress function
will allocate memory for the decompressed data with a size of uncompressedSize +
0x2000, without any checks for the result size. An attacker can make this result
integer to wrap around and cause the allocated memory to be smaller than the
size of the actual decompressed data. This will effectively lead to a heap
overflow, which can be exploited to code execution.

Figure 17: DejaBlue

From the time of writing this post, there is still no PoC/exploit available
publicly. Due to the significant risk this vulnerability may pose to the public,
we will not share any additional information at this moment. For further
reading, here a few public references for in-depth analysis of DejaBlue.

* https://www.malwaretech.com/2019/08/dejablue-analyzing-a-rdp-heap-overflow.html
* https://cyberx-labs.com/blog/analyzing-the-dejablue-heap-overflow-vulnerability/#_Toc28622447
* https://bbs.pediy.com/thread-256766.htm (Chinese)

SECURING YOUR RDP

There are general recommendations to follow that can make the task of attacking
your RDP server a lot more difficult for attackers. There are 2 simple actions
you can take that will:

* Prevent the exposure of your RDP servers to the internet, keeping them behind
your firewall.
* Enable NLA

This can minimize the attack surface by limiting potential attackers only to
those who are in your network and have already been authenticated.

CONCLUSION

Since this was an introductory article on RDP, I tried to distill hundreds of
pages worth of RDP documentation into a digestible and fairly short piece of
information, so there are many things I didn’t cover here. Our goal was to bring
the reader to the point of having a basic understanding of the protocol, as well
as the ability to continue reading and researching further about their specific
topics of interest.

In the past year, we have seen 2 critical vulnerabilities in this protocol and
with over 4.5 million RDP servers exposed to the internet (according to
shodan.io) and the risk of having an RDP driven outbreak is very high.

Even though not all RDP servers are Windows servers, we have seen similar
vulnerabilities shared between the different implementations of an RDP server,
so Windows is not the only potential target. DejaBlue for example, is very
similar to CVE-2018-8785 – a vulnerability in FreeRDP (popular open-source RDP
server) found by Eyal Itkin about a year before DejaBlue was discovered.

We started this blog by discussing how RDP is a complex protocol with many
extensions. Because of its complexity, the potential of finding new critical
bugs is still high and we need to be prepared to find and fix those before they
could be abused in the wild, or have the ability to respond quickly and minimize
the damage of potential future vulnerabilities.

REFERENCES

* https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/5073f4ed-1e93-45e1-b039-6e30c385867c
* https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpemt/4d98f550-6b0d-4d5f-89f5-2ac8616246a2
* https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/

* Share this!
* Facebook
* Twitter
* Email
* LinkedIn

Wild Temporary Tokens and Where to Find Them – AWS Edition

AWS is one of the most successful cloud solutions available today. As a pioneer
in the infrastructure-as-a-...

I Know What Azure Did Last Summer

More and more companies are deciding to move their infrastructures into cloud
environments offered by Micro...

RECOMMENDED FOR YOU

* ‹
* ›

3 days ago
The (Not so) Secret War on Discord

CYBERARK MALWARE RESEARCH TEAM ABSTRACT CYBERARK LABS DISCOVERED A NEW MALWARE
CALLED VARE THAT IS DISTRIBUTED OVER THE POPULAR CHATTING SERVICE, DISCORD. VARE
HAS BEEN USED TO TARGET NEW MALWARE...

CYBERARK MALWARE RESEARCH TEAM ABSTRACT CYBERARK LABS DISCOVERED A NEW MALWARE
CALLED VARE THAT IS DISTRIBUTED OVER THE POPULAR CHATTING SERVICE, DISCORD. VARE
HAS BEE...

Read Blog
2 months ago
Persistence Techniques That Persist

ABSTRACT ONCE THREAT ACTORS GAIN A FOOTHOLD ON A SYSTEM, THEY MUST IMPLEMENT
TECHNIQUES TO MAINTAIN THAT ACCESS, EVEN IN THE EVENT OF RESTARTS, UPDATES IN
CREDENTIALS OR ANY OTHER TYPE OF CHANGE...

ABSTRACT ONCE THREAT ACTORS GAIN A FOOTHOLD ON A SYSTEM, THEY MUST IMPLEMENT
TECHNIQUES TO MAINTAIN THAT ACCESS, EVEN IN THE EVENT OF RESTARTS, UPDATES IN
CREDENTIALS...

Read Blog
2 months ago
Phishing as a Service

INTRODUCTION EVERYONE KNOWS WHAT PHISHING IS. IT HAS BEEN AROUND FOR MORE THAN
TWO DECADES. NOW IT SEEMS THAT PHISHING IS MORE ACCESSIBLE THAN BEFORE. THIS
BLOG COVERS HOW MALICIOUS ACTORS CAN...

INTRODUCTION EVERYONE KNOWS WHAT PHISHING IS. IT HAS BEEN AROUND FOR MORE THAN
TWO DECADES. NOW IT SEEMS THAT PHISHING IS MORE ACCESSIBLE THAN BEFORE. THIS
BLOG COVERS HOW MALICIOUS ACTORS...

Read Blog
2 months ago
The Linux Kernel and the Cursed Driver

INTRODUCTION NTFS IS A FILESYSTEM DEVELOPED BY MICROSOFT THAT WAS INTRODUCED IN
1993. SINCE THEN, IT HAS BECOME THE PRIMARY FILESYSTEM FOR WINDOWS. IN RECENT
YEARS, THE NEED FOR AN NTFS...

INTRODUCTION NTFS IS A FILESYSTEM DEVELOPED BY MICROSOFT THAT WAS INTRODUCED IN
1993. SINCE THEN, IT HAS BECOME THE PRIMARY FILESYSTEM FOR WINDOWS. IN RECENT
YEARS, TH...

Read Blog
2 months ago
Breaking Docker Named Pipes SYSTEMatically: Docker Desktop Privilege Escalation
– Part 1

EVERYTHING STARTED WHEN I WAS RESEARCHING WINDOWS CONTAINERS. IT REQUIRED
INSTALLING DOCKER DESKTOP FOR WINDOWS, AND I COULDN’T HELP BUT NOTICE THAT THERE
WERE MANY DOCKER PROCESSES. SINCE SOME OF...

EVERYTHING STARTED WHEN I WAS RESEARCHING WINDOWS CONTAINERS. IT REQUIRED
INSTALLING DOCKER DESK...

Read Blog
3 months ago
Inglourious Drivers – A Journey of Finding Vulnerabilities in Drivers

TL;DR I DISCOVERED MULTIPLE BUGS IN OEM VENDORS FOR PERIPHERAL DEVICES, WHICH
AFFECTED MANY USERS OF THESE OEM VENDORS (RAZER, EVGA, MSI, AMI). MANY OF THE
VULNERABILITIES ORIGINATED IN A...

TL;DR I DISCOVERED MULTIPLE BUGS IN OEM VENDORS FOR PERIPHERAL DEVICES, WHICH
AFFECTED MANY USERS OF THESE OEM VENDORS (...

Read Blog
3 months ago
Chatting Our Way Into Creating a Polymorphic Malware

ABSTRACT CHATGPT TOOK THE WORLD BY STORM BEING RELEASED LESS THAN TWO MONTHS
AGO, IT HAS BECOME PROMINENT AND IS USED EVERYWHERE, FOR A WIDE VARIETY OF TASKS
– FROM AUTOMATION TASKS TO THE...

ABSTRACT CHATGPT TOOK THE WORLD BY STORM BEING RELEASED LESS THAN TWO MONTHS
AGO, IT HAS BECOME PROMINENT AND IS USED EVERYWHERE, FOR A WIDE VA...

Read Blog
4 months ago
What I Learned from Analyzing a Caching Vulnerability in Istio

TL;DR ISTIO IS AN OPEN-SOURCE SERVICE MASH THAT CAN LAYER OVER APPLICATIONS.
STUDYING CVE-2021-34824 IN ISTIO WILL ALLOW US TO DIVE INTO SOME CONCEPTS OF
ISTIO AND SERVICE MESHES IN GENERAL. WE...

TL;DR ISTIO IS AN OPEN-SOURCE SERVICE MASH THAT CAN LAYER OVER APPLICATIONS.
STUDYING CVE-2021-34824 IN ISTIO WILL ALLOW US TO DIVE INTO SOME C...

Read Blog
4 months ago
Decentralized Identity Attack Surface – Part 2

INTRODUCTION THIS IS THE SECOND PART OF OUR DECENTRALIZED IDENTITY (DID) BLOG
SERIES. IN CASE YOU’RE NOT FAMILIAR WITH DID CONCEPTS, WE HIGHLY ENCOURAGE YOU
TO START WITH THE FIRST PART. THIS TIME...

INTRODUCTION THIS IS THE SECOND PART OF OUR DECENTRALIZED IDENTITY (DID) BLOG
SERIES. IN CASE YOU’RE NOT FAMILIAR WITH DID CONCEPTS, WE HIGHLY ENCOURAGE YOU
TO START W...

Read Blog
5 months ago
Decentralized Identity Attack Surface – Part 1

INTRODUCTION WHO ARE YOU? THAT’S A HARD QUESTION TO ANSWER. MANY PHILOSOPHERS
HAVE BEEN FASCINATED WITH THIS QUESTION FOR YEARS. WHO ARE YOU IN CYBERSPACE?
YOUR DIGITAL IDENTITY IS COMPRISED OF...

INTRODUCTION WHO ARE YOU? THAT’S A HARD QUESTION TO ANSWER. MANY PHILOSOPHERS
HAVE BEEN FASCINATED WITH THIS QUESTION FOR YEARS. WHO ARE YOU IN CYBERSPACE?
YOUR DIGITA...

Read Blog
6 months ago
Fantastic Rootkits: And Where to Find Them (Part 1)

INTRODUCTION IN THIS BLOG SERIES, WE WILL COVER THE TOPIC OF ROOTKITS — HOW THEY
ARE BUILT AND THE BASICS OF KERNEL DRIVER ANALYSIS — SPECIFICALLY ON THE WINDOWS
PLATFORM. IN THIS FIRST PART, WE...

INTRODUCTION IN THIS BLOG SERIES, WE WILL COVER THE TOPIC OF ROOTKITS — HOW THEY
ARE BUILT AND THE BASICS OF KERNEL DRIVER ANALYSIS — SPECIFICA...

Read Blog
7 months ago
Colorful Vulnerabilities

OUR LOVE FOR GAMING ALONGSIDE FINDING BUGS LED US BACK TO THE GOOD OL’ QUESTION:
IS IT TRUE THAT THE MORE RGB COLORS YOU HAVE (EXCEPT FOR YOUR GAMING CHAIR, OF
COURSE), THE MORE SKILL...

OUR LOVE FOR GAMING ALONGSIDE FINDING BUGS LED US BACK TO THE GOOD OL’ QUESTION:
IS IT TRUE THAT THE MORE RGB COLORS YOU HAVE (EXCEPT FOR YOUR GAMING CHAIR, OF
COURSE), THE MORE SKILL......

Read Blog
7 months ago
Understanding Windows Containers Communication

SEVERAL YEARS AGO, WHEN I SPOKE WITH PEOPLE ABOUT CONTAINERS, MOST OF THEM WERE
NOT FAMILIAR WITH THE TERM. TODAY, IT IS UNQUESTIONABLY ONE OF THE MOST POPULAR
TECHNOLOGIES BEING USED IN DEVOPS...

SEVERAL YEARS AGO, WHEN I SPOKE WITH PEOPLE ABOUT CONTAINERS, MOST OF THEM WERE
NOT FAMILIAR WITH THE TERM. TODAY, IT IS UNQUESTIONABLY ONE OF...

Read Blog
8 months ago
Trust Me, I’m a Robot: Can We Trust RPA With Our Most Guarded Secrets?

IN OUR COMPLICATED AND CHALLENGING ENTERPRISE WORLD, TRUST IS NOT JUST IMPORTANT
— IT’S A VITAL LINK IN THE LONG CHAIN OF ENTERPRISE SUCCESS. IF YOU’VE EVER
MANAGED PEOPLE WHO DIDN’T TRUST ONE...

IN OUR COMPLICATED AND CHALLENGING ENTERPRISE WORLD, TRUST IS NOT JUST IMPORTANT
— IT’S A VITAL LINK IN THE LONG CHAIN O...

Read Blog
9 months ago
Inside Matanbuchus: A Quirky Loader

AN IN-DEPTH ANALYSIS OF MATANBUCHUS LOADER’S TRICKS AND LOADING TECHNIQUES
MATANBUCHUS IS A MALWARE-AS-A-SERVICE LOADER THAT HAS BEEN SOLD ON UNDERGROUND
MARKETS FOR MORE THAN ONE YEAR....

AN IN-DEPTH ANALYSIS OF MATANBUCHUS LOADER’S TRICKS AND LOADING TECHNIQUES
MATANBUCHUS IS A MALWARE-AS-A-SERVICE LOADER THAT HAS BEEN SOLD ON UNDERGROUND
MARKETS FOR M...

Read Blog
10 months ago
That Pipe is Still Leaking: Revisiting the RDP Named Pipe Vulnerability

ON JANUARY 11, 2022, WE PUBLISHED A BLOG POST DESCRIBING THE DETAILS OF
CVE-2022-21893, A REMOTE DESKTOP VULNERABILITY THAT WE FOUND AND REPORTED TO
MICROSOFT. AFTER ANALYZING THE PATCH THAT FIXED...

ON JANUARY 11, 2022, WE PUBLISHED A BLOG POST DESCRIBING THE DETAILS OF
CVE-2022-21893, A REMOTE DESKTOP VULNERABILITY T...

Read Blog
10 months ago
Go BLUE! A Protection Plan for Credentials in Chromium-based Browsers

IN MY PREVIOUS BLOG POST (HERE), I DESCRIBED A TECHNIQUE TO EXTRACT SENSITIVE
DATA (PASSWORDS, COOKIES) DIRECTLY FROM THE MEMORY OF A CHROMIUM-BASED BROWSER’S
[CBB] PROCESS. GOOGLE’S RESPONSE TO...

IN MY PREVIOUS BLOG POST (HERE), I DESCRIBED A TECHNIQUE TO EXTRACT SENSITIVE
DATA (PASSWORDS, COOKIES) DIRECTLY FROM TH...

Read Blog
10 months ago
Extracting Clear-Text Credentials Directly From Chromium’s Memory

THIS RESEARCH WAS INITIATED ACCIDENTALLY. AFTER “MINI-DUMPING” ALL ACTIVE
CHROME.EXE PROCESSES FOR ANOTHER RESEARCH PROJECT, I DECIDED TO SEE IF A
PASSWORD THAT I RECENTLY TYPED IN THE BROWSER...

THIS RESEARCH WAS INITIATED ACCIDENTALLY. AFTER “MINI-DUMPING” ALL ACTIVE
CHROME.EXE PROCESSES FOR ANOTHER RESEARCH PROJ...

Read Blog
11 months ago
Finding Bugs in Windows Drivers, Part 1 – WDM

FINDING VULNERABILITIES IN WINDOWS DRIVERS WAS ALWAYS A HIGHLY SOUGHT-AFTER
PRIZE BY SOPHISTICATED THREAT ACTORS, GAME CHEAT WRITERS AND RED TEAMERS. AS YOU
PROBABLY KNOW, EVERY BUG IN A DRIVER...

FINDING VULNERABILITIES IN WINDOWS DRIVERS WAS ALWAYS A HIGHLY SOUGHT-AFTER
PRIZE BY SOPHISTICATED THREAT ACTORS, GAME CHEAT WRITERS AND RED TE...

Read Blog
about a year ago
Conti Group Leaked!

THE CONFLICT IN UKRAINE HAS DRIVEN SIGNIFICANT ATTENTION FROM THE CYBERSECURITY
COMMUNITY, DUE IN LARGE PART TO THE CYBER ATTACKS CONDUCTED AGAINST UKRAINE
INFRASTRUCTURE — INCLUDING EVIDENCE OF...

THE CONFLICT IN UKRAINE HAS DRIVEN SIGNIFICANT ATTENTION FROM THE CYBERSECURITY
COMMUNITY, DUE IN LARGE PART TO THE CYBER ATTACKS CONDUCTED AGAINST UKRAINE
INFRASTRUCTURE — INCLUDING EVIDEN...

× Resource Center
* Products & Services
* Privileged Access Manager Self-Hosted
* CyberArk Identity
* Cloud Entitlements Manager
* Vendor Privileged Access Manager
* Conjur Secrets Manager Enterprise
* Endpoint Privilege Manager
* CyberArk Privilege Cloud
* Assessment Tools
* Services & Support

* Industry
* Financial Services & Insurance
* Healthcare
* Public Sector & Government

* Customer Stories

* Share this Hub
* Facebook
* Twitter
* Email
* LinkedIn

* STAY IN TOUCH

Keep up to date on security best practices, events and webinars.

Tell Me How

Careers

Contact Support

* Support
* Contact Support
* Training & Certification
* Customer Support
* EPM SaaS Register / Login
* Product Security

* Resources
* Resource Center
* Blogs
* CyberArk Blueprint
* Scan Your Network
* Marketplace

* Partners
* Partner Network
* Partner Community
* Partner Finder
* Become a Partner
* Alliance Partner

* Company
* Investor Relations
* Management Team
* Board of Directors
* Newsroom
* Office Locations
* Corporate Responsibility

* Terms and Conditions
* Privacy Policy
* Cookie Preferences Cookie Preferences

www.cyberark.com Open in urlscan Pro 104.17.196.105 Public Scan

Form analysis 1 forms found in the DOM

GET https://www.cyberark.com/

Text Content

www.cyberark.com Open in urlscan Pro
104.17.196.105 Public Scan

Form analysis
1 forms found in the DOM