Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C6in instances are available in AWS Region Asia Pacific (Osaka). These sixth-generation network optimized instances, powered by 3rd Generation Intel Xeon Scalable processors and built on the AWS Nitro System, deliver up to 200Gbps network bandwidth, for 2x more network bandwidth over comparable fifth-generation instances.
Customers can use C6in instances to scale the performance of applications such as network virtual appliances (firewalls, virtual routers, load balancers), Telco 5G User Plane Function (UPF), data analytics, high performance computing (HPC), and CPU based AI/ML workloads. C6in instances are available in 10 different sizes with up to 128 vCPUs, including bare metal size. Amazon EC2 sixth-generation x86-based network optimized EC2 instances deliver up to 100Gbps of Amazon Elastic Block Store (Amazon EBS) bandwidth, and up to 400K IOPS. C6in instances offer Elastic Fabric Adapter (EFA) networking support on 32xlarge and metal sizes.
C6in instances are available in these AWS Regions: US East (Ohio, N. Virginia), US West (N. California, Oregon), Europe (Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Zurich), Middle East (Bahrain, UAE), Israel (Tel Aviv), Asia Pacific (Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Africa (Cape Town), South America (Sao Paulo), Canada (Central), and AWS GovCloud (US-West, US-East). To learn more, see the Amazon EC2 C6in instances. To get started, see the AWS Management Console, AWS Command Line Interface (AWS CLI), and AWS SDKs.
The first models in the new Llama 4 herd of models—Llama 4 Scout 17B and Llama 4 Maverick 17B—are now available on AWS. You can access Llama 4 models in Amazon SageMaker JumpStart. These advanced multimodal models empower you to build more tailored applications that respond to multiple types of media. Llama 4 offers improved performance at lower cost compared to Llama 3, with expanded language support for global applications. Featuring mixture-of-experts (MoE) architecture, these models deliver efficient multimodal processing for text and image inputs, improved compute efficiency, and enhanced AI safety measures.
According to Meta, the smaller Llama 4 Scout 17B model, is the best multimodal model in the world in its class, and is more powerful than Meta’s Llama 3 models. Scout is a general-purpose model with 17 billion active parameters, 16 experts, and 109 billion total parameters that delivers state-of-the-art performance for its class. Scout significantly increases the context length from 128K in Llama 3, to an industry leading 10 million tokens. This opens up a world of possibilities, including multi-document summarization, parsing extensive user activity for personalized tasks, and reasoning over vast code bases. Llama 4 Maverick 17B is a general-purpose model that comes in both quantized (FP8) and non-quantized (BF16) versions, featuring 128 experts, 400 billion total parameters, and a 1 million context length. It excels in image and text understanding across 12 languages, making it suitable for versatile assistant and chat applications.
Amazon Bedrock Guardrails announces new capabilities to safely build generative AI applications at scale. These new capabilities offer grater flexibility, finer-grained control, and ease of use while using the configurable safeguards provided by Bedrock Guardrails aligning with use cases and responsible AI policies.
Bedrock Guardrails now offers a detect mode that provides a preview of the expected results from your configured policies allowing you to evaluate the effectiveness of the safeguards before deploying them. This enables faster iteration and accelerating time-to-product with different combinations and strengths of policies, allowing you to fine-tune your guardrails before deployment.
Guardrails now offers more configurability with options to enable policies on input prompts, model responses, or both prompts and responses – a significant improvement over the previous default setting where policies were automatically applied to both inputs and outputs. Providing finer-grained control enables you to selectively apply the safeguards to make them work for you.
Bedrock Guardrails offers sensitive information filters that detect personally identifiable information (PIIs) with two modes: Block where requests containing sensitive information are completely blocked, and Mask where sensitive information is redacted and replaced with identifier tags. You can now use either of these two modes for both input prompts and model responses giving you flexibility and ease of use to safely build generative AI applications at scale.
These new capabilities are available in all AWS regions where Amazon Bedrock Guardrails is supported.
AWS Serverless Application Model (AWS SAM) now supports custom domain names for private REST APIs feature of Amazon API Gateway. Developers building serverless applications using SAM can now seamlessly incorporate custom domain names for private APIs directly in their SAM templates, eliminating the need to configure custom domain names separately using other tools.
API Gateway allows you to create a custom domain name, like private.example.com, for your private REST APIs, enabling you to provide API callers with a simpler and intuitive URL. With a private custom domain name, you can reduce complexity, configure security measures with TLS encryption, and manage the lifecycle of the TLS certificate associated with your domain name. AWS SAM is a collection of open-source tools (e.g. SAM, SAM CLI) that make it easy for you to build and manage serverless applications through the authoring, building, deploying, testing, and monitoring phases of your development lifecycle. This launch enables you to easily configure custom domain names for your private REST APIs using SAM and SAM CLI.
To get started, update SAM CLI to the latest version and modify your SAM template to set the EndpointConfiguration to PRIVATE and specify a policy document in the Policy field in the Domain property of the AWS::Serverless::Api resource. SAM will then automatically generate DomainNameV2 and BasePathMappingV2 resources under AWS::Serverless::Api. To learn more, visit the AWS SAM documentation. You can learn more about custom domain name for private REST APIs in API Gateway blog post.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) M8g instances are available in AWS Asia Pacific (Mumbai) and AWS Asia Pacific (Hyderabad) regions. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 M8g instances are built for general-purpose workloads, such as application servers, microservices, gaming servers, midsize data stores, and caching fleets. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads.
AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. These instances offer larger instance sizes with up to 3x more vCPUs and memory compared to Graviton3-based Amazon M7g instances. AWS Graviton4 processors are up to 40% faster for databases, 30% faster for web applications, and 45% faster for large Java applications than AWS Graviton3 processors. M8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).
Today, Amazon introduces Amazon Nova Sonic, a new foundation model that unifies speech understanding and generation into a single model, to enable human-like voice conversations in artificial intelligence (AI) applications. Amazon Nova Sonic enables developers to build real-time conversational AI applications in Amazon Bedrock, with industry-leading price performance and low latency. It can understand speech in different speaking styles and generate speech in expressive voices, including both masculine-sounding and feminine-sounding voices, in English accents including American and British. Amazon Nova Sonic’s novel architecture can adapt the intonation, prosody, and style of the generated speech response to align with the context and content of the speech input. Additionally, Amazon Nova Sonic allows for function calling and knowledge grounding with enterprise data using Retrieval-Augmented Generation (RAG). Amazon Nova Sonic is developed with responsible AI in mind and features built-in protections including content moderation and watermarking.
To help developers build real-time application with Amazon Nova Sonic, AWS is also announcing the launch of a new bidirectional streaming API in Amazon Bedrock. This API enables two-way streaming of content, which is critical for low latency interactive communication between a human user and the AI model.
Amazon Nova Sonic can be used to voice-enable virtually any application. It has been extensively tested for a wide range of applications, including enabling customer service call automation at contact centers, outbound marketing, voice-enabled personal assistants and agents, and interactive education and language learning.
AWS announces the availability of Pixtral Large 25.02 in Amazon Bedrock, a 124B parameter model with multimodal capabilities that combines state-of-the-art image understanding with powerful text processing. AWS is the first cloud provider to deliver Pixtral Large 25.02 as a fully managed, serverless model. This model delivers frontier-class performance across document analysis, chart interpretation, and natural image understanding tasks, while maintaining the advanced text capabilities of Mistral Large 2.
With a 128K context window, Pixtral Large 25.02 achieves best-in-class performance on key benchmarks including MathVista, DocVQA, and VQAv2. The model features comprehensive multilingual support across dozens of languages and is trained on over 80 programming languages. Key capabilities include advanced mathematical reasoning, native function calling, JSON outputting, and robust context adherence for Retrieval Augmented Generation (RAG) applications.
Pixtral Large 25.02 is now available in Amazon Bedrock in seven AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Dublin), Europe (Paris), and Europe (Stockholm). For more information on supported Regions, visit the Amazon Bedrock Model Support by Regions guide.
To learn more about Pixtral Large 25.02 and its capabilities, visit the Mistral AI product page. To get started with Pixtral Large 25.02 in Amazon Bedrock, visit the Amazon Bedrock console.
Amazon S3 Tables are now available in four additional AWS Regions: Asia Pacific (Osaka), Europe (Paris), Europe (Spain), and US West (N. California). S3 Tables deliver the first cloud object store with built-in Apache Iceberg support, and the easiest way to store tabular data at scale.
At re:Invent 2024, AWS announced the preview of prompt caching, a new capability that can reduce costs by up to 90% and latency by up to 85% by caching frequently used prompts across multiple API calls. Today, AWS is launching prompt caching in generally availability on Amazon Bedrock.
Prompt caching allows you to cache repetitive inputs and avoid reprocessing context such as long system prompts and common examples that help guide the model’s response. When you use prompt caching, fewer computing resources are needed to process your inputs. As a result, not only can we process your request faster, but we can also pass along the cost savings.
Amazon Bedrock is a fully managed service that offers a choice of high-performing FMs from leading AI companies via a single API. Amazon Bedrock also provides a broad set of capabilities customers need to build generative AI applications with security, privacy, and responsible AI capabilities built in. These capabilities help you build tailored applications for multiple use cases across different industries, helping organizations unlock sustained growth from generative AI while providing tools to build customer trust and data governance.
Prompt caching is now generally available for Anthropic’s Claude 3.5 Haiku and Claude 3.7 Sonnet, Nova Micro, Nova Lite, and Nova Pro models. Customers who were given access to Claude 3.5 Sonnet v2 during the prompt caching preview will retain their access, however no additional customers will be granted access to prompt caching on the Claude 3.5 Sonnet v2 model. For regional availability or to learn more about prompt caching, please see our documentation and blog.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) M7i and R7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in Asia Pacific (Melbourne) region. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers.
M7i and R7i deliver up to 15% better price-performance compared to M6i and R6i instances respectively. They offer larger instance sizes up to 48xlarge, can attach up to 128 EBS volumes and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads.
In addition, all two instance types support the new Intel Advanced Matrix Extensions (AMX) that accelerate matrix multiplication operations for applications such as CPU-based ML.
To learn more, visit Amazon EC2 M7i, R7i instance pages.
AWS Transfer Family now enables you to delete, rename, or move files on remote SFTP servers using SFTP connectors. This enhancement allows you to easily manage files and directories stored on remote SFTP file systems and keep them up to date.
SFTP connectors provide fully managed and low-code capability to copy files between remote SFTP servers and Amazon S3. You can now organize your remote directories by deleting, renaming or moving source files to archive locations after they have been copied from the remote server. This helps you ensure that your remote directories remain current and prevent duplicate file transfers during subsequent job runs. These new features add to the existing SFTP connector functionalities, including capabilities to list remote directory contents and execute bidirectional file transfers.
SFTP connectors support for deleting, renaming and moving files on remote SFTP servers is available in all AWS Regions where AWS Transfer Family is available. To learn more about SFTP connectors, take the self paced workshop or visit the documentation. For information on pricing, see AWS Transfer Family pricing.
AWS CodeBuild now supports enhanced debugging experience through secure and isolated sandbox environments. You can connect to the sandbox environment via SSH clients or from an IDE to interactively troubleshoot your build or test runs. AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready for deployment.
With the enhanced debugging capability, you can investigate issues and validate the fixes in real-time, before committing changes to your buildspec configurations. The sandbox environment maintains a persistent file system during the debugging session, and offers the same native integration with source providers and AWS services as your build environment.
Amazon EventBridge Archive and Replay now supports AWS Key Management Service (KMS) customer managed keys for encrypting archived events. This expands your encryption options by letting you choose between default AWS owned keys for simpler, automated data protection or customer managed keys to help meet your organization’s specific security and governance requirements.
Amazon EventBridge Event Bus receives and routes events between your applications, SaaS applications, and AWS services. The Archive and Replay feature enhances this capability by allowing you to store events from an event bus and replay them later, helping you build more durable event-driven applications. You can archive events using custom filters, set flexible retention periods, and replay events to specific rules within your chosen time ranges on the original event bus. With customer managed KMS keys, you can help meet your organization’s compliance and governance requirements for encrypting archived events and use AWS CloudTrail to audit and track encryption key usage.
Customer managed key support for EventBridge Archive and Replay is available in all AWS Regions where the Archive and Replay feature is offered. Using this feature incurs no additional cost, but standard AWS KMS pricing applies.
Amazon Nova Canvas now supports fine-tuning through Amazon Bedrock, enabling customers to adapt the model to their unique datasets and brand characteristics. With custom model fine-tuning, customers can train the model on their proprietary data to generate fully customized images that align with their specific requirements and style guidelines. Fine-tuned models can be tested and deployed with provisioned throughput for consistent performance.
Text-to-image models are transforming how businesses across industries create and edit visual content. From architects visualizing floor plans to fashion designers iterating on new concepts, these models accelerate innovation by enabling rapid visualization of ideas through simple text descriptions. The technology streamlines creative workflows in manufacturing, retail, gaming, and advertising while enabling personalized customer experiences through interactive visual AI.
Fine-tuning for Amazon Nova Canvas is available in US East (N. Virginia).
Amazon FSx for NetApp ONTAP, a service that provides fully managed shared storage built on NetApp’s popular ONTAP file system, now supports ONTAP Autonomous Ransomware Protection (ARP). ARP is a NetApp ONTAP feature that proactively monitors your file system for unusual activity and automatically generates ONTAP snapshots when a potential attack is detected, helping you protect your business-critical data against a broader set of ransomware and malware attacks.
When enabled on your FSx for ONTAP storage volumes, ARP analyzes your workload access patterns to proactively detect suspicious activity – including changes in the randomness of data in files, the usage of unusual file extensions, and surges in abnormal volume activity with encrypted data – that might indicate a potential ransomware or malware attack. If activity is detected, ARP will automatically create a snapshot of the affected storage volume and generate alerts that you can monitor via EMS messages or the ONTAP CLI and REST API. By helping protect your file system against ransomware and malware attacks, ARP helps you maintain business continuity and improve data protection for your business-critical data stored on FSx for ONTAP.
AWS End User Messaging now allows customers to use Internet Protocol version 6 (IPv6) addresses for their new and existing service endpoints. Customers moving to IPv6 can simplify their network stack by running their AWS End User Messaging endpoints on a network that supports both IPv4 and IPv6.
The continued growth of the Internet, particularly in the areas of mobile applications, connected devices, and IoT, has spurred an industry-wide move to IPv6. IPv6 increases the number of available addresses by several orders of magnitude so customers will no longer need to manage overlapping address spaces in their VPCs. Customers can standardize their applications on the new version of Internet Protocol by moving their AWS End User Messaging endpoints to IPv6 with AWS CLI.
Support for IPv6 on AWS End User Messaging is available in all Regions where AWS End User Messaging is available.
We are excited to announce Amazon Nova Reel 1.1, which enables the generation of multi-shot videos up to 2-minutes in length and style consistency across shots. In addition, Amazon Nova Reel 1.1 provides quality and latency improvements in 6-second single-shot video generation over Amazon Nova Reel 1.0.
Multi-shot videos in Amazon Nova Reel 1.1 offers two modes: automated mode and manual mode. In automated mode, users can generate multiple 6-second videos by providing a single prompt and specifying the total video duration, up to 2 minutes. In manual mode, the model provides granular control, allowing users to input a text prompt and an optional image for each 6-second shot. Users can choose to receive either individual 6-second shots stored separately or a single stitched video in their S3 location.
Amazon Nova Reel 1.1 is available in US East (N. Virginia).
In October 2024, Google Threat Intelligence Group (GTIG) observed a novel phishing campaign targeting European government and military organizations that was attributed to a suspected Russia-nexus espionage actor we track as UNC5837. The campaign employed signed .rdp file attachments to establish Remote Desktop Protocol (RDP) connections from victims’ machines. Unlike typical RDP attacks focused on interactive sessions, this campaign creatively leveraged resource redirection (mapping victim file systems to the attacker servers) and RemoteApps (presenting attacker-controlled applications to victims). Evidence suggests this campaign may have involved the use of an RDP proxy tool like PyRDP to automate malicious activities like file exfiltration and clipboard capture. This technique has been previously dubbed as “Rogue RDP.”
The campaign likely enabled attackers to read victim drives, steal files, capture clipboard data (including passwords), and obtain victim environment variables. While we did not observe direct command execution on victim machines, the attackers could present deceptive applications for phishing or further compromise. The primary objective of the campaign appears to be espionage and file theft, though the full extent of the attacker’s capabilities remains uncertain. This campaign serves as a stark reminder of the security risks associated with obscure RDP functionalities, underscoring the importance of vigilance and proactive defense.
Introduction
Remote Desktop Protocol (RDP) is a legitimate Windows service that has been wellresearched by the security community. However, most of the security community’s existing research is focused on the adversarial use of RDP to control victim machines via interactive sessions.
This campaign included use of RDP that was not focused on interactive control of victim machines. Instead, adversaries leveraged two lesser-known features of the RDP protocol to present an application (the nature of which is currently unknown) and access victim resources. Given the low prevalence of this tactic, technique, and procedure (TTP) in previous reporting, we seek to explore the technical intricacies of adversary tradecraft abusing the following functionality of RDP:
RDP Property Files (.rdp configuration files)
Resource redirection (e.g. mapping victim file systems to the RDP server)
RemoteApps (i.e. displaying server-hosted applications to victim)
Additionally, we will shed light on PyRDP, an open-source RDP proxy tool that offers attractive automation capabilities to attacks of this nature.
By examining the intricacies of the tradecraft observed, we gain not only a better understanding of existing campaigns that have employed similar tradecraft, but of attacks that may employ these techniques in the future.
Campaign Operations
This campaign tracks a wave of suspected Russian espionage activity targeting European government and military organizations via widespread phishing. Google Threat Intelligence Group (GTIG) attributes this activity to a suspected Russia-nexus espionage actor group we refer to as UNC5837. The Computer Emergency Response Team of Ukraine (CERT-UA) reported this campaign on Oct. 29, 2024, noting the use of mass-distributed emails with.rdp file attachments among government agencies and other Ukrainian organizations. This campaign has also been documented by Microsoft, TrendMicro, and Amazon.
The phishing email in the campaign claimed to be part of a project in conjunction with Amazon, Microsoft, and the Ukrainian State Secure Communications and Information Security Agency. The email included a signed .rdp file attachment purporting to be an application relevant to the described project. Unlike more common phishing lures, the email explicitly stated no personal data was to be provided and if any errors occurred while running the attachment, to ignore it as an error report would be automatically generated.
Figure 1: Campaign email sample
Executing the signed attachment initiates an RDP connection from the victim’s machine. The attachment is signed with a Let’s Encrypt certificate issued to the domain the RDP connection is established with. The signed nature of the file bypasses the typical yellow warning banner, which could otherwise alert the user to a potential security risk. More information on signature-related characteristics of these files are covered in a later section.
The malicious .rdp configuration file specifies that, when executed, an RDP connection is initiated from the victim’s machine while granting the adversary read & write access to all victim drives and clipboard content. Additionally, it employs the RemoteApp feature, which presents a deceptive application titled “AWS Secure Storage Connection Stability Test” to the victim’s machine. This application, hosted on the attacker’s RDP server, masquerades as a locally installed program, concealing its true, potentially malicious nature. While the application’s exact purpose remains undetermined, it may have been used for phishing or to trick the user into taking action on their machine, thereby enabling further access to the victim’s machine.
Further analysis suggests the attacker may have used an RDP proxy tool like PyRDP (examined in later sections), which could automate malicious activities such as file exfiltration and clipboard capture, including potentially sensitive data like passwords. While we cannot confirm the use of an RDP proxy tool, the existence, ease of accessibility, and functionalities offered by such a tool make it an attractive option for this campaign. Regardless of whether such a tool was used or not, the tool is bound to the permissions granted by the RDP session. At the time of writing, we are not aware of an RDP proxy tool that exploits vulnerabilities in the RDP protocol, but rather gives enhanced control over the established connection.
The techniques seen in this campaign, combined with the complexity of how they interact with each other, make it tough for incident responders to assess the true impact to victim machines. Further, the number of artifacts left to perform post-mortem are relatively small, compared to other attack vectors. Because existing research on the topic is speculative regarding how much control an attacker has over the victim, we sought to dive deeper into the technical details of the technique components. While full modi operandi cannot be conclusively determined, UNC5837’s primary objective appears to be espionage and file stealing.
Deconstructing the Attack: A Deep Dive into RDP Techniques
Remote Desktop Protocol
The RDP is used for communication between the Terminal Server and Terminal Server Client. RDP works with the concept of “virtual channels” that are capable of carrying presentation data, keyboard/mouse activity, clipboard data, serial device information, and more. Given these capabilities, as an attack vector, RDP is commonly seen as a route for attackers in possession of valid victim credentials to gain full graphical user interface(GUI) access to a machine. However, the protocol supports other interesting capabilities that can facilitate less conventional attack techniques.
RDP Configuration Files
RDP has a number of properties that can be set to customize the behavior of a remote session (e.g., IP to connect to, display settings, certificate options). While most are familiar with configuring RDP sessions via a traditional GUI (mstsc.exe), these properties can also be defined in a configuration file with the .rdp extension which, when executed, achieves the same effect.
The following .rdp file was seen as an email attachment (SHA256): ba4d58f2c5903776fe47c92a0ec3297cc7b9c8fa16b3bf5f40b46242e7092b46
An excerpt of this .rdp file is displayed in Figure 3 with annotations describing some of the configuration settings.
When executed, this configuration file initiates an RDP connection to the malicious command-and-control (C2 or C&C) server eu-southeast-1-aws[.]govtr[.]cloud and redirects all drives, printers, COM ports, smart cards, WebAuthn requests (e.g., security key), clipboard, and point-of-sale (POS) devices to the C2 server.
The remoteapplicationmode parameter being set to 1 will switch the session from the “traditional” interactive GUI session to instead presenting the victim with only a part (application) of the RDP server. The RemoteApp, titled AWS Secure Storage Connection Stability Test v24091285697854, resides on the RDP server and is presented to the victim in a windowed popup. The icon used to represent this application (on the Windows taskbar for example) is defined by remoteapplicationicon. Windows environment variables %USERPROFILE%, %COMPUTERNAME%, and %USERDNSDOMAIN% are used as command-line arguments to the application. Due to the use of the property remoteapplicationexpandcmdline:i:0 , the Windows environment variables sent to the RDP server will be that of the client (aka victim), effectively performing initial reconnaissance upon connection.
Lastly, the signature property defines the encoded signature that signs the .rdp file. The signature used in this case was generated using Let’s Encrypt. Interestingly, the SSL certificate used to sign the file is issued for the domain the RDP connection is made to. For example, with SHA256: 1c1941b40718bf31ce190588beef9d941e217e6f64bd871f7aee921099a9d881.
Figure 4: Signature property within .rdp file
Tools like rdp_holiday can be used to decode the public certificate embedded within the file in Figure 4.
Figure 5: .rdp file parsed by rdp_holiday
The certificate is an SSL certificate issued for the domain the RDP connection is made to. This can be correlated with the RDP properties full_address / alternate_full_address.
alternate full address:s:eu-north-1-aws.ua-gov.cloud
full address:s:eu-north-1-aws.ua-gov.cloud
Figure 6: Remote Address RDP Proprties
.rdp files targeting other victims also exhibited similar certificate behavior.
In legitimate scenarios, an organization could sign RDP connections with SSL certificates tied to their organization’s certificate authority. Additionally, an organization could also disable execution of .rdp files from unsigned and unknown publishers. The corresponding GPO can be found under Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client -> Allow .rdp files from unknown publishers.
Figure 7: GPO policy for disabling unknown and unsigned .rdp file execution
The policy in Figure 7 can optionally further be coupled with the “Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers” policy (within the same location) to add certificates as Trusted Publishers.
From an attacker’s perspective, existence of a signature allows the connection prompt to look less suspicious (i.e., without the usual yellow warning banner), as seen in Figure 8.
This RDP configuration approach is especially notable because it maps resources from both the adversary and victim machines:
This RemoteApp being presented resides on the adversary-controlled RDP server, not the client/victim machine.
The Windows environment variables are that of the client/victim that are forwarded to the RDP server as command-line arguments
Victim file system drives are forwarded and accessible as remote shares on the RDP server. Only the drives accessible to the victim-user initiating the RDP connection are accessible to the RDP server. The RDP server by default has the ability to read and write to the victim’s file system drives
Victim clipboard data is accessible to the RDP server. If the victim machine is running within a virtualized environment but shares its clipboard with the host machine in addition to the guest, the host’s clipboard will also be forwarded to the RDP server.
Keeping track of what activity happens on the victim and on the server in the case of an attacker-controlled RDP server helps assess the level of control the attacker has over the victim machine. A deeper understanding of the RDP protocol’s functionalities, particularly those related to resource redirection and RemoteApp execution, is crucial for analyzing tools like PyRDP. PyRDP operates within the defined parameters of the RDP protocol, leveraging its features rather than exploiting vulnerabilities. This makes understanding the nuances of RDP essential for comprehending PyRDP’s capabilities and potential impact.
More information on RDP parameters can be found here and here.
Resource Redirection
The campaign’s .rdp configuration file set several RDP session properties for the purpose of resource redirection.
RDP resource redirection enables the utilization of peripherals and devices connected to the local system within the remote desktop session, allowing access to resources such as:
Printers
Keyboards, mouse
Drives (hard drives, CD/DVD drives, etc.)
Serial ports
Hardware keys like Yubico (via smartcard and WebAuthn redirection)
Audio devices
Clipboards (for copy-pasting between local and remote systems)
Resource redirection in RDP is facilitated through Microsoft’s “virtual channels.” The communication happens via special RDP packets, called protocol data packets (PDU), that mirror changes between the victim and attacker machine as long as the connection is active. More information on virtual channels and PDU structures can be found in MS-RDPERP.
Typically, virtual channels employ encrypted communication streams. However, PyRDP is capable of capturing the initial RDP handshake sequences and hence decrypting the RDP communication streams.
Figure 9: Victim’s mapped-drives as seen on an attacker’s RDP server
Remote Programs / RemoteApps
RDP has an optional feature called RemoteApp programs, which are applications (RemoteApps) hosted on the remote server that behave like a windowed application on the client system, which in this case is a victim machine. This can make a malicious remote app seem like a local application to the victim machine without ever having to touch the victim machine’s disk.
Figure 10 is an example of the MS Paint application presented as a RemoteApp as seen by a test victim machine. The application does not exist on the victim machine but is presented to appear like a native application. Notice how there is no banner/top dock that indicates an RDP connection one would expect to see in an interactive session. The only indicator appears to be the RDP symbol on the taskbar.
Figure 10: RDP RemoteApp (MsPaint.exe) hosted on the RDP server, as seen on a test victim machine
All resources used by RemoteApp belong to that of the RDP server. Additionally, if victim drives are mapped to the RDP server, they are accessible by the RemoteApp as well.
PyRDP
While the use of a tool like PyRDP in this campaign cannot be confirmed, the automation capabilities it offers make it an attractive option worth diving deeper into. A closer look at PyRDP will illuminate how such a tool could be useful in this context.
PyRDP is an open-source, Python-based, man-in-the-middle (MiTM) RDP proxy toolkit designed for offensive engagements.
Figure 11: PyRDP as a MiTM tool
PyRDP operates by running on a host (MiTM server) and pointing it to a server running Windows RDP. Victims connect to the MiTM server with no indication of being connected to a relay server, while PyRDP seamlessly relays the connection to the final RDP server while providing enhanced capabilities over the connection, such as:
Stealing NTLM hashes of the credentials used to authenticate to the RDP server
Running commands on the RDP server after the user connects
Capturing the user’s clipboard
Enumerating mapped drives
Stream, record (video format), and session takeover
It’s important to note that, from our visibility, PyRDP does not exploit vulnerabilities or expose a new weakness. Instead, PyRDP gives granular control to the functionalities native to the RDP protocol.
Password Theft
PyRDP is capable of stealing passwords, regardless of whether Network Level Authentication (NLA) is enabled. In the case NLA is enabled, it will capture the NTLM hash via the NLA as seen in Figure 12. It does so by interrupting the original RDP connection sequence and completing part of it on its own, thereby allowing it to capture hashed credentials. The technique works in a similar way to Responder. More information about how PyRDP does this can be found here.
Figure 12: RDP server user NTLMv2 Hashes recorded by PyRDP during user authentication
Alternatively, if NLA is not enabled, PyRDP attempts to scan the codes it receives when a user tries to authenticate and convert them into virtual key codes, thereby “guessing” the supplied password. The authors of the tool refer to this as their “heuristic method” of detecting passwords.
Figure 13: Plaintext password detection without NLA
When the user authenticates to the RDP server, PyRDP captures these credentials used to login to the RDP server. In the event the RDP server is controlled by the adversary (e.g., in this campaign), this feature does not add much impact since the credentials captured belong to the actor-controlled RDP server. This capability becomes impactful, however, when an attacker attempts an MiTM attack where the end server is not owned by them.
It is worth noting that during setup, PyRDP allows credentials to be supplied by the attacker. These credentials are then used to authenticate to the RDP server. By doing so, the user does not need to be prompted for credentials and is directly presented with the RemoteApp instead. In the campaign, given that the username RDP property was empty, the RDP server was attacker-controlled, and the RemoteApp seemed to be core to the storyline of the operation, we suspect a tool like PyRDP was used to bypass the user authentication prompt to directly present the AWS Secure Storage Connection Stability Test v24091285697854 RemoteApp to the victim.
Finally, PyRDP automatically captures the RDP challenge during connection establishment. This enables RDP packets to be decrypted if raw network captures are available, revealing more granular details about the RDP session.
Command Execution
PyRDP allows for commands to be executed on the RDP server. However, it does not allow for command execution on the victim’s machine. At the time of deployment, commands to be executed can be supplied to PyRDP in the following ways:
MS-DOS (cmd.exe)
PowerShell commands
PowerShell scripts hosted on the PyRDP server file system
PyRDP executes the command by freezing/blocking the RDP session for a given amount of time, while the command executes in the background. To the user, it seems like the session froze. At the time of deploying the PyRDP MiTM server, the attacker specifies:
What command to execute (in one of the aforementioned three ways)
How long to block/freeze the user session for
How long the command will take to complete
PyRDP is capable of detecting user connections and disconnections to RDP sessions. However, it lacks the ability to detect user authentication to the RDP server. As a user may connect to an RDP session without immediately proceeding to account login, PyRDP cannot determine authentication status, thus requiring the attacker to estimate a waiting period following user connection (and preceding authentication) before executing commands. It also requires the attacker to define the duration for which the session is to be frozen during command execution, since PyRDP has no way of knowing when the command completes.
The example in Figure 14 relays incoming connections to an RDP server on 192.168.1.2. Upon connection, it then starts the calc.exe process on the RDP server 20 seconds after the user connects and freezes the user session for five seconds while the command executes.
A clever attacker can use this capability of PyRDP to plant malicious files on a redirected drive, even though it cannot directly run it on the victim machine. This could facilitate dropping malicious files in locations that allow for further persistent access (e.g., via DLL-sideloading, malware in startup locations). Defenders can hunt for this activity by monitoring file creations originating from mstsc.exe. We’ll dive deeper into practical detection strategies later in this post.
Clipboard Capture
PyRDP automatically captures the clipboard of the victim user for as long as the RDP connection is active. This is one point where the attacker’s control extends beyond the RDP server and onto the victim machine.
Note that if a user connects from a virtual environment (e.g., VMware) and the host machine’s clipboard is mapped to the virtual machine, it would also be forwarded to the RDP session. This can allow the attacker to capture clipboard content from the host and guest machine combined.
Scraping/Browsing Client Files
With file redirection enabled, PyRDP can crawl the target system and save all or specified folders to the MiTM server if instructed at setup using the --crawl option. If the --crawl option is not specified at setup, PyRDP will still capture files, but only those accessed by the user during the RDP session, such as environment files. During an active connection, an attacker can also connect to the live stream and freely browse the target system’s file system via the PyRDP-player GUI to download files (see Figure 15).
It is worth noting that while PyRDP does not explicitly present the ability to place files on the victim’s mapped drives, the RDP protocol itself does allow it. Should an adversary misuse that capability, it would be outside the scope of PyRDP.
Stream/Capture/Intercept RDP Sessions
PyRDP is capable of recording RDP sessions for later playback. An attacker can optionally stream each intercepted connection and thereafter connect to the stream port to interact with the live RDP connection. The attacker can also take control of the RDP server and perform actions on the target system. When an attacker takes control, the RDP connection hangs for the user, similar to when commands are executed when a user connects.
Streaming, if enabled with the -i option, defaults to TCP port 3000 (configurable). Live connections are streamed on a locally bound port, accessible via the included pyrdp-player script GUI. Upon completion of a connection, an .mp4 recording of the session can be produced by PyRDP.
This section focuses on collecting forensic information, hardening systems, and developing detections for RDP techniques used in the campaign.
Security detections detailed in this section are already integrated into the Google SecOps Enterprise+ platform. In addition, Google maintains similar proactive measures to protect Gmail and Google Workspace users.
Log Artifacts
Default Windows Machine
During testing, limited evidence was recovered on default Windows systems after drive redirection and RemoteApp interaction. In practice, it would be difficult to distinguish between a traditional RDP connection and one with drive redirection and/or RemoteApp usage on a default Windows system. From a forensic perspective, the following patterns are of moderate interest:
Creation of the following registry key upon connection, which gives insight into attacker server address and username used:
HKUS-1-5-21-4272539574-4060845865-869095189-1000SOFTWARE
MicrosoftTerminal Server ClientServers<attacker_IP_Address>
HKUS-1-5-21-4272539574-4060845865-869095189-1000SOFTWARE
MicrosoftTerminal Server ClientServers<attacker_server>UsernameHint:
"<username used for connection>"
The information contained in the Windows Event Logs (Microsoft-Windows-TerminalServices-RDPClient/Operational):
Event ID 1102: Logs attacker server IP address
Event ID 1027: Logs attacker server domain name
Event ID 1029: Logs username used to authenticate in format base64(sha256(username)).
Heightened Logging Windows Machine
With enhanced logging capabilities (e.g., Sysmon, Windows advanced audit logging, EDR), artifacts indicative of file write activity on the target system may be present. This was tested and validated using Sysmon file creation events (event ID 11).
Victim system drives can be mapped to the RDP server via RDP resource redirection, enabling both read and write operations. Tools such as PyRDP allow for crawling and downloading the entire file directory of the target system.
When files are written to the target system using RDP resource redirection, the originating process is observed to be C:Windowssystem32mstsc.exe. A retrospective analysis of a large set of representative data consisting of enhanced logs indicates that file write events originating from mstsc.exe are a common occurrence but display a pattern that could be excluded from alerting.
For example, multiple arbitrarily named terminal server-themed .tmp files following the regex pattern _TS[A-Z0-9]{4}.tmp(e.g., _TS4F12.tmp) are written to the user’s %APPDATA%/Local/Temp directory throughout the duration of the connection.
Additionally, several file writes and folder creations related to the protocol occur in the %APPDATA%/LocalMicrosoftTerminal Server Client directory.
Depending upon the RDP session, excluding these protocol-specific file writes could help manage the number of events to triage and spot potentially interesting ones. It’s worth noting that the Windows system by default will delete temporary folders from the remote computer upon logoff. This does not apply to the file operations on redirected drives.
Should file read activity be enabled, mstsc.exe-originating file reads could warrant suspicion. It is worth noting that file-read events by nature are noisy due to the way the Windows subsystem operates. Caution should be taken before enabling it.
.rdp File via Email
The .rdp configuration file within the campaign was observed being sent as an email attachment. While it’s not uncommon for IT administrators to send .rdp files over email, the presence of an external address in the attachment may be an indicator of compromise. The following regex patterns, when run against an organization’s file creation events, can indicate .rdp files being run directly from Outlook email attachments:
/\AppData\Local\Microsoft\Windows\(INetCache|Temporary Internet Files)
\Content.Outlook\[A-Z0-9]{8}\[^\]{1,255}.rdp$/
/\AppData\Local\Packages\Microsoft.Outlook_[a-zA-Z0-9]{1,50}\.{0,120}
\[^\]{1,80}.rdp$/
/\AppData\Local\Microsoft\Olk\Attachments\([^\]{1,50}\){0,5}[^\]
{1,80}.rdp$/
System Hardening
The following options could assist with hardening enterprise environments against RDP attack techniques.
Network-level blocking of outgoing RDP traffic to public IP addresses
Disable resource redirection via the Registry
Key: HKEY_LOCAL_MACHINESoftwareMicrosoftTerminal Server Client
Allow .rdp files from unknown publishers: Setting this to disable will not allow users to run unsigned .rdp files as well as ones from untrusted publishers.
Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers: A way to add certificate SHA1s as trusted file publishers
Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host: Policies on enable/disabling
Resource redirection
Clipboard redirection
Forcing Network Level Authentication
Time limits for active/idle connections
Blocking .rdp file extension as email attachments
The applicability of these measures is subject to the nature of activity within a given environment and what is considered “normal” behavior.
YARA Rules
These YARA rules can be used to detect suspicious RDP configuration files that enable resource redirection and RemoteApps.
This campaign demonstrates how common tradecraft can be revitalized with alarming effectiveness through a modular approach. By combining mass emailing, resource redirection, and the creative sleight-of-hand use of RemoteApps, the actor could effectively leverage existing RDP techniques while leaving minimal forensic evidence. This combination of familiar techniques, deployed in an unconventional manner, proved remarkably effective, proving that the true danger of Rogue RDP lies not in the code, but in the con.
In this particular campaign, while control over the target system seems limited, the main capabilities revolve around file stealing, clipboard data capture, and access to environment variables. It is more likely this campaign was aimed at espionage and user manipulation during interaction. Lastly, this campaign once again underscores how readily available red teaming tools intended for education purposes are weaponized by malicious actors with harmful intentions.
Acknowledgments
Special thanks to: Van Ta, Steve Miller, Barry Vengerik, Lisa Karlsen, Andrew Thompson, Gabby Roncone, Geoff Ackerman, Nick Simonian, and Mike Stokkel.
The Amazon Route 53 authoritative DNS service for public hosted zones is now generally available in the AWS GovCloud (US-East and US-West) Regions. With today’s release, AWS customers and AWS Partners who rely on public DNS for their applications in the AWS GovCloud (US) Regions can now take advantage of most of the features they have come to expect of Route 53 in commercial AWS Regions.
Previously, customers used Route 53 authoritative DNS served from commercial AWS Regions for routing traffic to their applications in the AWS GovCloud (US) Regions. Now, you can serve DNS queries to your public hosted zones from locations within the AWS GovCloud (US) Regions and without dependency on commercial AWS Region accounts. Features include authoritative DNS query logging, DNSSEC signing on AWS GovCloud (US) public hosted zones, and support for all Route 53 routing types except for IP-based routing. It also includes alias records to the following other AWS services: Amazon API Gateway, Amazon S3, Amazon VPC endpoints, AWS Elastic Beanstalk, and Elastic Load Balancing (ELB) load balancers.
Getting started with Route 53 in the AWS GovCloud (US) Regions is easy. All customers in the AWS GovCloud (US) Regions can use Route 53 authoritative DNS via the AWS Management Console and API in the AWS GovCloud (US-West) Region. For more information, visit the Route 53 documentation or review migration recommendations in the Route 53 Developer Guide. For details on pricing, visit section Authoritative DNS on the Route pricing page.
Today, we are launching two significant updates to AWS Elemental MediaTailor pricing:
A new VOD ad insertion usage type priced at a 50% discount to live.The new pricing model aligns better with how streaming providers monetize their content. By pricing VOD ad insertion at 50% of the cost of live workflows, you can expand your ad-supported VOD libraries more cost-effectively using MediaTailor.
Elimination of the $0.75 per 1000 ads pricing tier, so live ad insertion now has a single tier at $0.50 per 1000 ads.By removing the tiered pricing model of 1 to 5M insertions and greater than 5M insertions per month, this makes it easier for you to predict your bill and get started with MediaTailor. The following summary illustrates the changes:
Previously, ad insertion pricing was tiered:
$0.75 per 1,000 ad insertions for the first 5 million insertions per month
$0.50 per 1,000 ad insertions for volumes exceeding 5 million per month
Under the new pricing model:
Live streaming ad insertions: $0.50 per 1,000 insertions
VOD streaming ad insertions: $0.25 per 1,000 insertions
Both rates now apply regardless of volume.
The new pricing is effective immediately and will be applied automatically to your bill. Customers willing to make minimum commitments of more than 60 million ad insertions per month qualify for additional discounted pricing. Contact us or your account manager to learn more.
This new pricing structure is available in all AWS Regions where MediaTailor is available. To learn more, please visit the MediaTailor product page.