How Radware CNP Uses Amazon Route 53 Query Logging for Threat Detection

By Yuval Shapira, Security Research Team Leader at Radware
By Amnon Lotem, Head of Data Science at Radware

Amazon Web Services (AWS) recently launched a new feature as part of its Amazon Route 53 service, called Route 53 Resolver Query Logging.

This new service enables organizations to retrieve logs of their Domain Name System (DNS) queries originating from resources within their virtual private clouds (VPCs). Analysis of these logs can be a great help for detecting malicious activity within an organization’s accounts.

This post describes how these logs can be analyzed as part of the Radware Cloud Native Protector Service (CNP), which is available on AWS Marketplace. Radware is an AWS Partner and provider of cybersecurity and application delivery solutions for public cloud environments.

Radware’s Cloud Security Services, including CNP, provides a range of fully managed, enterprise-grade cloud security solutions to protect applications running in public clouds against threats, web vulnerabilities, bot attacks, and network traffic attacks.

Radware Cloud Native Protector (CNP)

Radware provides an agentless, cloud-native solution for the comprehensive protection of workloads running on AWS against cloud-native threats and complex attacks.

Radware CNP fortifies an organization’s security posture with compliance reporting, and provides alerts of misconfigurations and excessive permissions. It also detects malicious activity that’s indicative of data theft, provides centralized visibility and management, and responds to attacks as soon as they’re detected.

Here are some details about Radware CNP’s multi-layered approach to infrastructure protection:

• As a foundation, CNP provides cloud security posture management (CSPM) to secure the overall cloud account and reduce risk by identifying misconfigured and publicly exposed assets and compliance breaches.
• In the next level, Radware provides risk-based actionable visibility to allow security managers to address concerns in a prioritized manner and focus on what matters most.
• Next, Radware provides continuous hardening of permissions based on the principal of least privilege in order to reduce the threat surface as much as possible, without impacting business operations.
• Finally, Radware provides sophisticated attack detection and remediation capabilities, which detect and correlate individual events across long timespans into interconnected, streamlined storylines. This shows the step-by-step progression of attacks, so they can be cut off before they result in a breach.

Radware CNP analyzes AWS CloudTrail and VPC Flow Logs using advanced machine learning and deep learning techniques.

The analysis enables the detection of suspicious activities within the cloud, correlating events (using the Radware patent-pending sequence building technique) and alerting on the cases of malicious or highly-suspicious behavior.

Figure 1 – Alert for detected anomalous activity across various attack steps.

Radware also detects excessive permissions by analyzing the gap between granted and used permissions, and provides smart hardening recommendations to fortify the security posture and reduce attack surfaces.

Figure 2 – Hardening pane, listing excessive privileges, exposed assets and more.

Onboarding AWS Accounts to Radware CNP

In order to onboard an AWS account to CNP, there’s no need to install agents or deploy any additional software to your cloud for CNP to protect your account. Instead, setup involves adding policies and roles to your account to allow Radware to collect logs and metadata, and start digesting the collected logs.

To connect your AWS account to Radware CNP service, you need to log in to the service portal with the credentials you received from Radware, and follow three simple configuration steps.

• In the Allow Permissions screen, create the required permission policies in your AWS account. Copy from the tutorial the required permissions Radware CNP uses, and then log in to the AWS console and create a new policy with the copied content.

Figure 3 – Create new policy for Radware’s CNP.

• In the Configure Access screen, allow Radware to access logs and metadata in your cloud by creating a new role with trusted entity to the account in the tutorial.

Figure 4 – Configure who has access to the data.

• Lastly, assign a name to the new account, the Amazon Resource Name (ARN) of the role you just created, and the external ID you defined in the created role.

Figure 5 – Finalize the setup to start using Radware CNP.

DNS and Configuring Query Logging

The DNS, also known as “The Internet’s Phone Book,” translates human-readable domain names (like example.com) into IP addresses. Because of how ubiquitous DNS is, it’s usually open on all system firewalls, unlike the well-known and well-protected TCP.

DNS logs are now accessible using Route 53 Resolver Query Logging, and this new feature lets you log the DNS queries that originate in your Amazon VPCs.

DNS queries forwarded by on-premises DNS servers to VPCs via inbound endpoints are also logged. Even the DNS queries made by your AWS Lambda functions, Amazon Elastic Kubernetes Service (Amazon EKS) clusters, and Amazon WorkSpaces instances can be logged.

In order to configure logging within your AWS account, using the new query logging feature, you need to create a query logging configuration, set the logging destination, and get DNS logs for the VPC’s you want.

To do so, you need to create the resolver query log configuration in the AWS Command Line Interface (CLI):

aws route53resolver create-resolver-query-log-config --name <nameOfResolver> --creator-request-id <IdOfRequset> --destination-arn arn:aws:s3:::<bucketname>/<key>/

This command will output a JSON containing the ResolverQueryLogConfigId, which looks like this:

rqlc-abcdef0123456789

This object is used to attach the newly-created configuration to a VPC of your choosing, with the following CLI command:

aws route53resolver associate-resolver-query-log-config --resolver-query-log-config-id rqlc- abcdef0123456789 --resource-id vpc-01234567890abcdef

From this point forward, you have a working query logging configuration, recording every DNS request and response your VPC initiates.

CNP Detection with Query Logging Feature

The new Route 53 Query Logging service enables Radware CNP to provide even stronger capabilities to monitor and identify suspicious attacker activities.

Why is that capability so important? An attacker or malware that achieves a footprint within an AWS account typically tries to communicate to machines in the internet for different purposes, such as command and control (C&C) communication, data exfiltration, or even crypto mining.

Significant cases of these communications start with a DNS query. Close monitoring of resolver query logs, and the combination of query logs and existing VPC Flow Logs enable Radware CNP to identify malicious communication, correlate it with other potentially suspicious activities, and identify the attacker.

This is far from trivial, however, as attackers use different techniques to make their fraudulent outbound communication look legitimate, or go unnoticed within the vast amount of network traffic flowing from an AWS account to the internet.

For that reason, Radware CNP applies advanced and complementary techniques for analyzing query logs and distinguishing DNS traffic between legit and malicious traffic.

These techniques involve:

• Strong threat intelligence, which makes use of a propriety sandbox.
• Machine learning analysis designed to detect abnormal requests, such as unusual volume or type of requests or unusual server requests.

Radware CNP Sandbox – Blocklist Matching

Radware’s developed and managed sandbox analyzes over 100,000 potentially malicious files per day. Radware CNP Sandbox monitors system calls, disk changes, IO activities, and outgoing network transactions generated by the files analyzed.

Radware CNP Sandbox also learns, analyzes, dissects, and captures all of the relevant data that each type of Linux and Windows malware generates as part of its activity at the endpoint.

The contiguous analysis generates significant indication of compromise (IOC) information later in the process used by Radware CNP, while analyzing network and other activities of the customer’s ongoing activities.

Looking at the sandbox results, where records are generated every second, Radware’s system analyzes many DNS requests to malicious hosts. These hosts shows a clear global trend indicating a rise in Linux malwares diversity over the last few years.

Collecting this information makes a DNS “blocklist” to correlate with Radware CNP customer’s provided logs. It attempts to identify malicious activity, originating from within the customer’s cloud workload and sending sensitive data to a malicious host.

These communications can be one of several types of matches Radware CNP looks for:

• Crypto mining activity: As the hype and interests in crypto-currency mining is rising, matching a communication from inside the network to a miner pool site is a valuable match. This indication lets the company know of a miner installed on one of the servers inside the organization that’s being used to create revenues for the attacker.
  .
• C&C activity: Command and control communication is another valuable match Radware looks for. DNS logs allows Radware to match the communication to malicious hosts generated by infected machines.
  .
• DNS data exfiltration: DNS protocol can also be used to exfiltrate data. For example, the attacker can initiate DNS requests to  “sensitivePasswordFromInsideTheMachine.malsite.com”. These DNS requests query the Nameservers of malsite.com. The Nameservers are controlled by the attacker, which results in exfiltrating the entire string “sensitivePasswordFromInsideTheMachine.malsite.com” from inside the machine to the attacker, over DNS.
  .
• Domain Generated Algorithms (DGA): This is used when an attacker wants to avoid detection of noticeable malicious domain names. DGAs are based on a changing seed that recreates a new domain every time period (hour, day, week, etc.), which causes the attacker to be stealthier and more complicated to catch.
  .
  DGAs can be as simple as time-based, or more advanced, and based on currency exchange for example, as seen by Bedep malware a few years back, or the recently discovered Linux malware dubbed Doki, with DGA based on Dogecoin cryptocurrency blockchain.
  .
  Without cracking the DGA algorithm and recreating the seed, it’s impossible to detect the following created domains.
  .
  When Radware CNP matches a record from the logs with such known malicious activity, a new suspicious indication is produced. It includes contextual forensic information that is helpful for security teams, while analyzing the malicious communication.

Figure 6 – Crypto mining activity as seen in Radware’s CNP.

Machine Learning Detection Techniques

Machine learning (ML) is applied to DNS logs to address new and unknown threats that could not be detected by known malicious hosts.

The ML models are trained using the historic DNS activity of cloud entities (such as machine, VPC, or account) to capture their normal behavior. The models are then applied to the recent DNS activity of the cloud workload entities.

If that activity is not predicted by the models—meaning it does not match the normal behavior—an anomaly indication is produced.

Various dimensions of the DNS request should be considered when capturing the normal behavior and identifying anomalies:

• Volume of DNS traffic by the source entity: Unusual high volume of DNS traffic may point on activity to find a C&C or to perform DNS exfiltration (using the DNS protocol to exfiltrate data).
• Type of DNS requests: Non-typical types of DNS requests may point on trial to perform DNS data exfiltration.
• Errors (DNS server response): Recurring or high rate NXDOMAIN for the return code of the DNS request might point on activity to find a C&C.
• Domain and subdomain names: Domain names and subdomain names with anomalous length or patterns may point to auto-generated domain names, used for C&C, or subdomains used for encoding information to be exfiltrated.

In addition, a combined analysis of DNS logs from Amazon Route 53 and VPC Flow Logs has high potential to better understand malicious communication related to data exfiltration.

Conclusion

In this post, we went through setting up Radware Cloud Native Protector Service (CNP) to start monitoring your organization. We also discussed how to configure Route 53 Resolver Query Logs and how these logs are used in the Radware CNP product.

This release from AWS empowers CNP detection capabilities with additional information that can be indicative of malicious activity that was hidden from any detectors up until this new logging addition.

Radware CNP is powered by more than 70 advanced threat detection algorithms, spanning across the entire attack kill chain.

The correlation of insights generated from DNS query logs with additional malicious behavior indicators produced by Radware CNP, such as network activity and API activity, will improve and refine the accuracy of Radware CNP’s Threat Detection capabilities.

In today’s era, where security teams are overloaded with enormous amounts of alerts and indications of suspicious activities, the addition of this new telemetry improves the accuracy of threat detection, enabling faster detection and response in addition to improved efficiency of an organization’s incident response team.

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.

.

Radware – AWS Partner Spotlight

Radware is an AWS Partner and provider of cybersecurity and application delivery solutions for public cloud environments.

Contact Radware | Partner Overview | AWS Marketplace

*Already worked with Radware? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.