Patent Application
20240205240
Nefarious individuals attempt to compromise computer systems in a variety of ways. As one example, such individuals may embed or otherwise include malicious software (“malware”) in email attachments and transmit or cause the malware to be transmitted to unsuspecting users. When executed, the malware compromises the victim's computer. Some types of malware will instruct a compromised computer to communicate with a remote host. For example, malware can turn a compromised computer into a “bot” in a “botnet,” receiving instructions from and/or reporting data to a command and control (C&C) server under the control of the nefarious individual. One approach to mitigating the damage caused by malware is for a security company (or other appropriate entity) to attempt to identify malware and prevent it from reaching/executing on end user computers. Another approach is to try to prevent compromised computers from communicating with the C&C server. Unfortunately, malware authors are using increasingly sophisticated techniques to obfuscate the workings of their software. As one example, some types of malware use Domain Name System (DNS) query responses to infiltrate data. Accordingly, there exists an ongoing need for improved techniques to detect malware and prevent its harm.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
A firewall generally protects networks from unauthorized access while permitting authorized communications to pass through the firewall. A firewall is typically a device, a set of devices, or software executed on a device that provides a firewall function for network access. For example, a firewall can be integrated into operating systems of devices (e.g., computers, smart phones, or other types of network communication capable devices). A firewall can also be integrated into or executed as one or more software applications on various types of devices, such as computer servers, gateways, network/routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of special purpose devices), and in various implementations, certain operations can be implemented in special purpose hardware, such as an ASIC or FPGA.
Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify or log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as are described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.
Security devices (e.g., security appliances, security gateways, security services, and/or other security devices) can include various security functions (e.g., firewall, anti-malware, intrusion prevention/detection, Data Loss Prevention (DLP), and/or other security functions), networking functions (e.g., routing, Quality of Service (QOS), workload balancing of network related resources, and/or other networking functions), and/or other functions. For example, routing functions can be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.
A basic packet filtering firewall filters network communication traffic by inspecting individual packets transmitted over a network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect the individual packets themselves and apply rules based on the inspected packets (e.g., using a combination of a packet's source and destination address information, protocol information, and a port number).
Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls, which work on the application level of the TCP/IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (e.g., web browsing using HyperText Transfer Protocol (HTTP), a Domain Name System (DNS) request, a file transfer using File Transfer Protocol (FTP), and various other types of applications and other protocols, such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, application firewalls can block unauthorized protocols that attempt to communicate over a standard port (e.g., an unauthorized/out of policy protocol attempting to sneak through by using a non-standard port for that protocol can generally be identified using application firewalls).
Stateful firewalls can also perform state-based packet inspection in which each packet is examined within the context of a series of packets associated with that network transmission's flow of packets. This firewall technique is generally referred to as a stateful packet inspection as it maintains records of all connections passing through the firewall and is able to determine whether a packet is the start of a new connection, a part of an existing connection, or is an invalid packet. For example, the state of a connection can itself be one of the criteria that triggers a rule within a policy.
Advanced or next generation firewalls can perform stateless and stateful packet filtering and application layer filtering as discussed above. Next generation firewalls can also perform additional firewall techniques. For example, certain newer firewalls sometimes referred to as advanced or next generation firewalls can also identify users and content. In particular, certain next generation firewalls are expanding the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' PA Series firewalls). For example, Palo Alto Networks' next generation firewalls enable enterprises to identify and control applications, users, and content—not just ports, IP addresses, and packets—using various identification technologies, such as the following: APP-ID for accurate application identification, User-ID for user identification (e.g., by user or user group), and Content-ID for real-time content scanning (e.g., controlling web surfing and limiting data and file transfers). These identification technologies allow enterprises to securely enable application usage using business-relevant concepts, instead of following the traditional approach offered by traditional port-blocking firewalls. Also, special purpose hardware for next generation firewalls (implemented, for example, as dedicated appliances) generally provide higher performance levels for application inspection than software executed on general purpose hardware (e.g., such as security appliances provided by Palo Alto Networks, Inc., which use dedicated, function specific processing that is tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).
Advanced or next generation firewalls can also be implemented using virtualized firewalls. Examples of such next generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' VM Series firewalls, which support various commercial virtualized environments, including, for example, VMware® ESXi™ and NSX™, Citrix® Netscaler SDX™, KVM/OpenStack (Centos/RHEL, Ubuntu®), and Amazon Web Services (AWS)). For example, virtualized firewalls can support similar or the exact same next-generation firewall and advanced threat prevention features available in physical form factor appliances, allowing enterprises to safely enable applications flowing into, and across their private, public, and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and a REST-based API, allow enterprises to proactively monitor VM changes dynamically feeding that context into security policies, thereby eliminating the policy lag that may occur when VMs change.
Data appliance 102 can be configured to work in cooperation with a remote security platform 140. Security platform 140 can provide a variety of services, including performing static and dynamic analysis on malware samples, and providing a list of signatures of known-malicious files to data appliances, such as data appliance 102 as part of a subscription. In various embodiments, results of analysis (and additional information pertaining to applications, domains, etc.) are stored in database 160. In various embodiments, security platform 140 comprises one or more dedicated commercially available hardware servers (e.g., having multi-core processor(s), 32G+ of RAM, gigabit network interface adaptor(s), and hard drive(s)) running typical server-class operating systems (e.g., Linux). Security platform 140 can be implemented across a scalable infrastructure comprising multiple such servers, solid state drives, and/or other applicable high-performance hardware. Security platform 140 can comprise several distributed components, including components provided by one or more third parties. For example, portions or all of security platform 140 can be implemented using the Amazon Elastic Compute Cloud (EC2) and/or Amazon Simple Storage Service (S3). Further, as with data appliance 102, whenever security platform 140 is referred to as performing a task, such as storing data or processing data, it is to be understood that a sub-component or multiple sub-components of security platform 140 (whether individually or in cooperation with third party components) may cooperate to perform that task. As one example, security platform 140 can optionally perform static/dynamic analysis in cooperation with one or more virtual machine (VM) servers. An example of a virtual machine server is a physical machine comprising commercially available server-class hardware (e.g., a multi-core processor, 32+ Gigabytes of RAM, and one or more Gigabit network interface adapters) that runs commercially available virtualization software, such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Further, a virtual machine server may be under the control of the same entity that administers security platform 140, but may also be provided by a third party. As one example, the virtual machine server can rely on EC2, with the remainder portions of security platform 140 provided by dedicated hardware owned by and under the control of the operator of security platform 140.
An embodiment of a data appliance is shown in
Functionality described herein as being performed by data appliance 102 can be provided/implemented in a variety of ways. For example, data appliance 102 can be a dedicated device or set of devices. The functionality provided by data appliance 102 can also be integrated into or executed as software on a general purpose computer, a computer server, a gateway, and/or a network/routing device. In some embodiments, at least some services described as being provided by data appliance 102 are instead (or in addition) provided to a client device (e.g., client device 104 or client device 106) by software executing on the client device.
Whenever data appliance 102 is described as performing a task, a single component, a subset of components, or all components of data appliance 102 may cooperate to perform the task. Similarly, whenever a component of data appliance 102 is described as performing a task, a subcomponent may perform the task and/or the component may perform the task in conjunction with other components. In various embodiments, portions of data appliance 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to data appliance 102, various logical components and/or features of data appliance 102 may be omitted and the techniques described herein adapted accordingly. Similarly, additional logical components/features can be included in embodiments of data appliance 102 as applicable. One example of a component included in data appliance 102 in various embodiments is an application identification engine which is configured to identify an application (e.g., using various application signatures for identifying applications based on packet flow analysis). For example, the application identification engine can determine what type of traffic a session involves, such as Web Browsing—Social Networking; Web Browsing—News; SSH; and so on.
As shown, data appliance 102 comprises a firewall, and includes a management plane 232 and a data plane 234. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.
Network processor 236 is configured to receive packets from client devices, such as client device 108, and provide them to data plane 234 for processing. Whenever flow module 238 identifies packets as being part of a new session, it creates a new session flow. Subsequent packets will be identified as belonging to the session based on a flow lookup. If applicable, SSL decryption is applied by SSL decryption engine 240. Otherwise, processing by SSL decryption engine 240 is omitted. Decryption engine 240 can help data appliance 102 inspect and control SSL/TLS and SSH encrypted traffic, and thus help to stop threats that might otherwise remain hidden in encrypted traffic. Decryption engine 240 can also help prevent sensitive content from leaving enterprise network 110. Decryption can be controlled (e.g., enabled or disabled) selectively based on parameters such as: URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., that specify which sessions to decrypt), decryption profiles can be assigned to control various options for sessions controlled by the policy. For example, the use of specific cipher suites and encryption protocol versions can be required.
Application identification (APP-ID) engine 242 is configured to determine what type of traffic a session involves. As one example, application identification engine 242 can recognize a GET request in received data and conclude that the session requires an HTTP decoder. In some cases, e.g., a web browsing session, the identified application can change, and such changes will be noted by data appliance 102. For example a user may initially browse to a corporate Wiki (classified based on the URL visited as “Web Browsing—Productivity”) and then subsequently browse to a social networking site (classified based on the URL visited as “Web Browsing—Social Networking”). Different types of protocols have corresponding decoders.
Based on the determination made by application identification engine 242, the packets are sent, by threat engine 244, to an appropriate decoder configured to assemble packets (which may be received out of order) into the correct order, perform tokenization, and extract out information. Threat engine 244 also performs signature matching to determine what should happen to the packet. As needed, SSL encryption engine 246 can re-encrypt decrypted data. Packets are forwarded using a forward module 248 for transmission (e.g., to a destination).
As also shown in
Returning to
While malware 130 might attempt to cause the compromised client device to directly communicate with C&C server 150 (e.g., by causing the client to send an email to C&C server 150), such overt communication attempts could be flagged (e.g., by data appliance 102) as suspicious/harmful and blocked. Increasingly, instead of causing such direct communications to occur, malware authors use a technique referred to herein as DNS tunneling. DNS is a protocol that translates human-friendly URLs, such as paloaltonetworks.com, into machine-friendly IP addresses, such as 199.167.52.137. DNS tunneling exploits the DNS protocol to tunnel malware and other data through a client-server model. In an example attack, the attacker registers a domain, such as badsite.com. The domain's name server points to the attacker's server, where a tunneling malware program is installed. The attacker infects a computer. Because DNS requests are traditionally allowed to move in and out of security appliances, the infected computer is allowed to send a query to the DNS resolver (e.g., to kj32hkjqfeuo32ylhkjshdflu23.badsite.com, where the subdomain portion of the query encodes information for consumption by the C&C server). The DNS resolver is a server that relays requests for IP addresses to root and top-level domain servers. The DNS resolver routes the query to the attacker's C&C server, where the tunneling program is installed. A connection is now established between the victim and the attacker through the DNS resolver. This tunnel can be used to exfiltrate data or for other malicious purposes.
Detecting and preventing DNS tunneling attacks is difficult for a variety of reasons. A first reason is illustrated in
The environment shown in
As mentioned above, in order to connect to a legitimate domain (e.g., www.example.com depicted as site 128), a client device, such as client device 104 will need to resolve the domain to a corresponding Internet Protocol (IP) address. One way such resolution can occur is for client device 104 to forward the request to DNS server 122 and/or 124 to resolve the domain. In response to receiving a valid IP address for the requested domain name, client device 104 can connect to website 128 using the IP address. Similarly, in order to connect to malicious C&C server 150, client device 104 will need to resolve the domain, “kj32hkjqfeuo32ylhkjshdflu23.badsite.com,” to a corresponding Internet Protocol (IP) address. In this example, malicious DNS server 126 is authoritative for *.badsite.com and client device 104's request will be forwarded (for example) to DNS server 126 to resolve, ultimately allowing C&C server 150 to receive data from client device 104.
In various embodiments, data appliance 102 includes a DNS module 134, which is configured to facilitate determining whether client devices (e.g., client devices 104-108) are attempting to engage in malicious DNS tunneling, and/or prevent connections (e.g., by client devices 104-108) to malicious DNS servers. DNS module 134 can be integrated into appliance 102 (as shown in
In various embodiments, when a client device (e.g., client device 104) attempts to resolve a domain, DNS module 134 uses the domain as a query to security platform 140. This query can be performed concurrently with resolution of the domain (e.g., with the request sent to DNS servers 122, 124, and/or 126 as well as security platform 140). As one example, DNS module 134 can send a query (e.g., in the JSON format) to a frontend 142 of security platform 140 via a REST API. Using processing described in more detail below, security platform 140 will determine (e.g., using DNS tunneling detector 138) whether the queried domain indicates a malicious DNS tunneling attempt and provide a result back to DNS module 134 (e.g., “malicious DNS tunneling” or “non-tunneling”).
In various embodiments, DNS tunneling detector 138 (whether implemented on security platform 140, on data appliance 102, or other appropriate location/combinations of locations) uses a two-pronged approach in identifying malicious DNS tunneling. The first approach uses anomaly detector 146 (e.g., implemented using python) to build a set of real-time profiles (156) of DNS traffic for root domains. The second approach uses signature generation and matching (also referred to herein as similarity detection, and, e.g., implemented using Go). The two approaches are complementary. The anomaly detector serves as a generic detector that can identify previously unknown tunneling traffic. However, the anomaly detector may need to observe multiple DNS queries before detection can take place. In order to block the first DNS tunneling packet, similarity detector 144 complements anomaly detector 146 and extracts signatures from detected tunneling traffic which can be used to identify situations where an attacker has registered new malicious tunneling root domains but has done so using tools/malware that are similar to the detected root domains.
As data appliance 102 receives DNS queries (e.g., from DNS module 134), it provides them to security platform 140 which performs both anomaly detection and similarity detection, respectively. In various embodiments, a domain (e.g., as provided in a query received by security platform 140) is classified as a malicious DNS tunneling root domain if either detector flags the domain.
DNS tunneling detector 138 maintains a set of fully qualified domain names (FQDNs), per appliance (from which the data is received), grouped in terms of their root domains (illustrated collectively in
As one example, DNS query information received from data appliance 102 for various foo.com sites is grouped (into a domain profile for the root domain foo.com) as: G(foo.com)-[mail.foo.com, coolstuff.foo.com, domain1234.foo.com]. A second root domain would have a second profile with similar applicable information (e.g., G(baddomain.com)=[lskjdf23r.baddomain.com, kj235hdssd233.baddomain.com]). Each root domain (e.g., foo.com or baddomain.com) is modeled using a set of characteristics unique to malicious DNS tunneling, so that even though benign DNS patterns are diverse (e.g., k2jh3i8y35.legitimatesite.com, xxx888222000444.otherlegitimatesite.com), they are highly unlikely to be misclassified as malicious tunneling. The following are example characteristics that can be extracted as features (e.g., into a feature vector) for a given group of domains (i.e., sharing a root domain).
1. The number of distinct FQDNs in the group: Typically, legitimate domains will tend to have a small number of FQDNs (e.g., mail.example.com and ftp.example.com). In contrast, as malicious DNS tunneling encodes a message, significantly more FQDNs will be used. An example value for this feature for a benign domain is “5” and an example value for this feature for a malicious domain is “568.”
2. The average DNS query count for each FQDN: Typically, legitimate domains will tend to have many queries (for a small number of FQDNs). In contrast, as malicious DNS tunneling encodes a message, each FQDN will typically have only one query count.
3. The Jeffrey distribution of DNS query counts for all FQDNs: Typically, legitimate domains will tend to have a nonzero number. In contrast, malicious DNS tunneling domains will tend to have a zero number.
4. The average length of FQDNs in the group: Typically, legitimate domains will tend to have shorter average domain name lengths than malicious DNS tunneling domains.
5. The ratio of queries for A/AAAA/CNAME/NS/MX records: Typically, the kinds of queries performed involving legitimate domains will involve A, MX, and CNAME records. The ratio of different kinds of queries can be used as a feature.
6. The ratio of meaningful words in all FQDN names in the group: Typically, legitimate domains (e.g., content delivery network domains) will include meaningful words in subdomain names (e.g., as determinable using a dictionary or other list of predetermined words). In contrast, as malicious DNS tunneling encodes a message, such subdomains generally comprise meaningless characters.
7. The n-gram frequency of all FQDN names in the group: The type of “n” gram used can be set variously in different embodiments. In an example embodiment, 4-grams are evaluated. Typically, legitimate domains will tend to have lower 4-gram frequency than malicious DNS tunneling domains.
8. The entropy of the FQDNs in the group: Typically, legitimate domains will tend to have less entropy in their FQDNs than malicious DNS tunneling domains.
9. Whether or not the domains use trusted authoritative DNS servers: Typically, legitimate domains will use well-established third party managed DNS servers. For example, 44 million root domains use domaincontrol.com (provided by GoDaddy). While a few legitimate root domains (e.g., google.com) manage their own DNS servers (e.g., ns.google.com), such DNS servers can also be considered as trusted. In contrast, in order for malicious DNS tunneling to work, the DNS server (e.g., proxychecker.pro, ziyouforever.com, 63z.de) needs to be controlled by the tunneling domain. For this feature, a root domain is assigned a value of “1” if it uses a trusted authoritative DNS server (e.g., as determined by comparing its DNS server(s) against a whitelist of known trusted DNS servers) and a “0” otherwise.
10. The compression rate of the FQDNs in the group: Typically, malicious DNS tunneling domain names contain compressed data. The compression rate of domain names can be used as a feature (e.g., as length of GZIPed string/length of original string).
In various embodiments, the feature vector associated with a given root domain (e.g., foo.com) is updated each time a DNS query associated with that root domain is received by security platform 140. Each time the feature vector for a root domain (e.g., foo.com) is updated, it is checked against a pre-built benign traffic model. The model can be built using any appropriate anomaly detection approach, and stays stable, even across different networks. One example of such an approach is an isolation forest approach (e.g., implemented using the scikit-learn python tool) where an ensemble of iTrees is built, with each iTree representing a domain profile of benign DNS queries. The isolation forest approach is fast, computation and memory efficient, scales to a very large dataset, and can be particularly useful where (e.g., with malicious DNS tunneling traffic) the training data set is heavily lopsided (i.e., with many more available benign examples than malicious ones). In various embodiments, isolation forest 158 is trained using benign traffic only (e.g., using feature vectors previously collected for benign DNS query information). Any anomalies detected by the model are anomalous to benign DNS traffic and thus can be classified as malicious DNS tunneling traffic. If the traffic is determined to be malicious DNS tunneling, a remedial action can be taken (e.g., with security platform 140 instructing data appliance 102 to block any traffic that includes the root domain (thus also blocking any subdomains)).
While an attacker may use multiple different domains for DNS tunneling (e.g., xyz.baddomain.com and abc.terriblespamsite.io), those domains may share at least a portion of infrastructure. For example, both sites may make use of similar message encoding schemes for receiving DNS tunneled messages (e.g., 1861IDa23d57f90-0-2D-2D.baddomain.com and 9773IDa23d57f91-0-2D-2D.terriblespamsite.io, where “-0-2D-2D” is common to both). Such patterns can be extracted (e.g., using python) from known malicious DNS tunneling messages (e.g., by DNS tunneling detector 138) and stored as regular expressions for use by similarity detector 144. Similarly, both baddomain.com and terriblespamsite.io may make use of a DNS server having a single IP address (e.g., 123.45.67.89) to receive their respective DNS queries. IP addresses of known DNS tunneling servers can also be used by similarity detector 144.
In addition to providing DNS query information received from data appliance 102 to anomaly detector 146, in various embodiments, security platform 140 also provides the information to similarity detector 144. Similarity detector 144 is configured to use a set of previously determined regular expressions and previously determined IP addresses (corresponding to known malicious tunneling traffic/servers) to detect new malicious DNS tunneling servers.
At 504, a determination is made that a root domain portion of the received DNS query is associated with a malicious DNS tunneling root domain. As described above, two example tools for making such a determination are anomaly detector 146 or similarity detector 144. If either (or both) such tool makes such a determination, decision engine 152 (or any other appropriate component, including anomaly detector 146 and similarity detector 144 themselves) can conclude that a remedial action should be taken in response. Finally, at 506, one or more appropriate remedial actions are taken. Examples of such actions include platform 140 instructing data appliance 102 to block further communication with the implicated root level domain, informing data appliance 102 that the domain is a malicious tunneling domain (but allowing data appliance 102 to make its own determination of what to do as a result, such as alerting an administrator that a given client has attempted to contact a malicious DNS tunneling server and quarantining the client device from other nodes on the network), extracting IP address and/or regular expression pattern information from the implicated DNS query, etc.
DNS tunneling refers, generally, to techniques for exploiting the DNS protocol to tunnel malware and other data through a client-server model. As mentioned above, DNS-related attacks can pose particular security challenges because DNS requests (and responses) are often allowed to move in and out of enterprise (and other) networks freely (including through security appliances). Further, the amount of benign DNS traffic far outnumbers the amount of malicious DNS traffic and distinguishing one from the other can be difficult.
As shown in
Among other features, the DNS system was designed to be highly available, fault tolerant, and provide quick responses. Unfortunately, these features can also be leveraged by a malicious individual for nefarious purposes. Suppose client device 702 has been compromised (e.g., malware 130 has compromised client device 702) and an attacker would like to use client device 702 to help perpetrate an attack. The attacker has registered the domain, “attacker.com.” The attacker can use client device 702 to exfiltrate data (e.g., secret information to be stolen from within network 110) by causing client device 702 to make a DNS query that encodes (e.g., at the subdomain level, denoted in
Embodiments of security platform 140 (and/or, as applicable embodiments of data appliance 102) can be used to detect and prevent DNS tunneling attacks, including both DNS exfiltration attacks and DNS infiltration attacks.
In contrast to a DNS query (e.g., a fully qualified domain name), a DNS response contains more information. Of note, a response will include multiple fields, examples of which are as follows:
There are various resource record types that can be used for encoding infiltration payloads. Examples are as follows:
Here, the IPv4 address (121.32.66.30) is used to encode four bytes of information to the victim.
Here, the IPV6 address is similarly used to encode sixteen bytes of information to the victim.
Here, the TXT field can be used to encode virtually anything, similarly with the following responses.
And, while the following are less frequently used for infiltration, their values can also be examined for statistical features.
For CNAME, commonly, a legitimate domain will have a single alias (or a limited number of often related aliases, e.g., with example.org being an alias for example.com). For DNS tunneling, to encode information, many such mappings may exist, often with high entropy (including suspicious or invalid domains (e.g., non existent domains)).
For NS/MX/etc., for legitimate domains, the corresponding nameservers, mail servers, etc. exist and include semantic information. For example, an NS domain should be a domain server and an MX domain should be a mail server, both of which can be validated. For DNS tunneling, to encode information, the corresponding servers will be suspicious/invalid (e.g., not provide expected services such as mail handling, and/or have high entropy names).
Finally, for TXT, for legitimate domains, the information tends to conform to certain predetermined patterns (e.g., containing strings related to DMARC, SPF, etc.). Regular expressions can be used to determine whether TXT response information is likely to be benign (corresponds to a known pattern) or evidence of DNS tunneling (does not match expected patterns). Example regular expressions for performing such matching follow (using the format: Category,Label,Comment,Regex):
Other patterns can also be used, as applicable.
For IPV4 responses, the following are examples of features that can be extracted:
For IPV6 responses, the following are examples of features that can be extracted (for similar reasons to those mentioned above in connection with IPv4 responses):
Fully qualified domain name (FQDN) responses (e.g., CNAME/NS/MX/etc.) are in the format of FQDNs and can be used to derive the features discussed above in connection with IPv4 and IPV6 responses. Additional features that are unique to FQDN responses can also be extracted, example of which follow:
For TXT, responses, the following are examples of features that can be extracted:
For other types of responses (e.g., SOA, KEY, DNSKEY, RRSIG), the following are examples of statistical features that can be extracted:
The above response types and values refer to rrtype and rdata. In addition to rrtype and rdata, qname and rrname are in the format of FQDNs and can be used to derive the same set of features as discussed above in connection with IPv4 response features.
Once the various features are collected (e.g., using feature extractors 808 implemented, for example, using python code and modules), they're provided to a detection engine 812 that makes use of a set of machine learning and/or heuristic detectors. These detectors work similarly to those discussed in conjunction with
At 1204, a determination is made that the DNS response is associated with a malicious DNS tunneling domain. As described above, an example tool for making such a determination is shown in
Finally, at 1206, one or more appropriate remedial actions are taken. Examples of such actions include platform 140 instructing data appliance 102 to block further communication with the implicated domain, informing data appliance 102 that the domain is a malicious tunneling domain (but allowing data appliance 102 to make its own determination of what to do as a result, such as alerting an administrator that a given client has attempted to contact a malicious DNS tunneling server and quarantining the client device from other nodes on the network), extracting IP address and/or regular expression pattern information from the implicated DNS query, etc., and/or providing that information to other data appliances (e.g., as part of a subscription).
Of note, in some cases, only a single observation of a DNS response need be made to identify a malicious infiltration domain. As an example, an IPV6 response for a non-public domain can be treated as a trigger that should result in immediate blocking (or other remedial actions) being taken against the domain. For other heuristics, weights (or other approaches) can be used to determine whether a response (or set of responses) is suspicious. Both scenarios readily support real-time detection of infiltration domains.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
This application claims priority to U.S. Provisional Patent Application No. 63/432,963 entitled REAL-TIME DETECTION OF DNS INFILTRATION TRAFFIC filed Dec. 15, 2022 which is incorporated herein by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 63432963 | Dec 2022 | US |
