Network Attack Detection Using Target Feature Extraction from Exploit Tools

Abstract

The present application discloses a method, system, and computer system for detecting malicious SQL or command injection strings, the method including obtaining an SQL or command injection string and determining whether the command injection string is malicious based at least in part on a machine learning model.

Description

[Background Technology]

[0001] Malicious 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 then send or have the malware sent to unsuspecting users. As another example, such individuals may enter command strings, such as SQL input strings, OS commands, etc., and cause a remote host to execute them. When executed, the malicious command strings compromise the victim's computer. Some types of malicious command strings will instruct the compromised computer to communicate with a remote host. For example, malware can turn a compromised computer into a “bot” in a “botnet” that receives commands from and / or reports data to a command and control (C&C) server under the control of the malicious individual. One approach to mitigating the damage caused by exploit tools (e.g., malware, malicious command strings, etc.) is for security companies (or other appropriate entities) to identify the exploit tools and attempt to prevent them from reaching / executing on end-user computers. Another approach is to try to prevent compromised computers from communicating with command and control servers. Unfortunately, malicious authors are using increasingly sophisticated techniques to obfuscate the operation of their exploit tools. As one example, some types of malware use Domain Name System (DNS) queries to exfiltrate data. Thus, there remains a need for improved techniques for detecting malware and preventing its harm. [Brief explanation of the drawings]

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. [Figure 1] FIG. 1 is a block diagram of an environment in which malicious input strings are detected or suspected, according to various embodiments. [Figure 2] FIG. 2 is a block diagram of a system for detecting malicious input strings, according to various embodiments. [Figure 3] FIG. 3 is an illustration of generating a feature vector using an input string, according to various embodiments. [Figure 4] FIG. 4 is an illustration of generating a combined feature vector using an input string, according to various embodiments. [Figure 5A] FIG. 5A is a chart illustrating a feature space for features used in connection with classifying an input string, according to various embodiments. [Figure 5B] FIG. 5B is a chart illustrating detection of malicious input strings, according to various embodiments. [Figure 6] FIG. 6 is a flow chart of a method for determining whether an input string is malicious, according to various embodiments. [Figure 7] FIG. 7 is a flowchart of a method for determining whether an input string is malicious, according to various embodiments. [Figure 8] FIG. 8 is a flowchart of a method for obtaining feature vectors to train a machine learning model, according to various embodiments. [Figure 9] FIG. 9 is a flowchart of a method for obtaining training data, according to various embodiments. [Figure 10] FIG. 10 is a flowchart of a method for obtaining a model for classifying malicious input strings, according to various embodiments. [Figure 11]FIG. 11 is a flowchart of a method for detecting malicious input strings, according to various embodiments. [Figure 12] FIG. 12 is a flowchart of a method for detecting malicious input strings, according to various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0003] The present invention may 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 configured to execute instructions stored on and / or provided by a memory coupled to the processor. These implementations, or any other form the present invention may take, may be referred to herein as techniques. In general, the order of steps in disclosed processes may be varied within the scope of the present invention. Unless otherwise specified, components such as a processor or memory described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform the task at a given time, or as specific components 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.

[0004] A detailed description of one or more embodiments of the present invention is provided below along with accompanying figures that illustrate the principles of the invention. While the present invention will be described in connection with such embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the purposes of clarity, technical material known in the art related to the present invention has not been described in detail so as not to unnecessarily obscure the present invention.

[0005] As used herein, a security entity is a network node (e.g., a device) that enforces one or more security policies with respect to information such as network traffic, files, etc. As one example, a security entity may be a firewall. As another example, a security entity may be implemented as a router, a switch, a DNS resolver, a computer, a tablet, a laptop, a smartphone, etc. As another example, security may be implemented as an application running on a device, such as an anti-malware application.

[0006] As used herein, malware refers to an application that engages in behavior, whether covert or not (and whether illegal or not), that a user would not / would not approve of if fully informed. Examples of malware include Trojan horses, viruses, rootkits, spyware, hacking tools, keyloggers, etc. One example of malware is a desktop application that collects an end user's location and reports it to a remote server (but does not provide the user with location-based services, such as mapping services). Another example of malware is a malicious Android Application Package (APK) file that appears to the end user to be a free game but stealthily sends SMS premium messages (e.g., costing $10 each), increasing the end user's phone bill. Another example of malware is the Apple iOS Flashlight application that covertly collects a user's contact information and sends them to spammers. Other forms of malware may also be detected / prevented using the techniques described herein (e.g., ransomware). Additionally, although malware signatures are described herein as being generated for malicious applications, the techniques described herein may also be used in various embodiments to generate profiles for other types of applications (e.g., adware profiles, goodware profiles, etc.).

[0007] As used herein, an input string includes an SQL statement or command, or other command injection string.

[0008] As used herein, a zero-day exploit includes an exploit that is not yet known, such that the exploit is not in the public domain.

[0009] As used herein, a regex (also called a regular expression) includes a pattern or sequence of characters, e.g., a string, that specifies a search pattern within text.

[0010] A malicious user may use a malicious input string as an exploit to compromise a target node (e.g., a computer or other remote host). The malicious input string uses a structured statement to exploit a vulnerability within a system (e.g., a vulnerability in code, an application, etc.). For example, a malicious input string is used to open a network connection used as an entry point for the malicious user. Command injection can be used to exploit a vulnerability to invoke code / command execution (e.g., execute malicious code or open a network connection, etc.). SQL injection can be used to exploit a data extraction vulnerability. An example of SQL injection is in a login screen where the user enters "OR 1=1; / *" and the password is entered as "* / --". The aforementioned SQL injection causes the system to select results from users where "user_is=" OR 1=1; / * and "password=" * / --.

[0011] An example HTTP POST request body SQL injection is as follows: "action=sendPasswordEmail&user_name=admin" or "1=1--"

[0012] An example SQL injection HTTP GET request URL is: " / inspection / web / v1.0 / admin / team_conf / page / 10 / 1?teamNm=&unionPay=&orgCd= AND (SELECT2*(IF((SELECT*FROM(SELECT CONCAT(0x71626b6a71,(SELECT(ELT(8619=8619,1))),0x717a7a6a71,0x78))s),8446744073709551610,8446744073709551610)))"

[0013] Preventing exploitation of vulnerabilities via malicious input strings and detecting such attacks poses at least two key challenges to vulnerability exploit detection and prevention: (i) exploit detection should be highly accurate to prevent false alarms (e.g., false positives), and (ii) detection techniques should be scalable to detect both seen and unseen exploits (e.g., known exploits in the public domain and zero-day exploits).

[0014] According to the related art, exploits using malicious input strings are identified based on pattern matching techniques. Because such pattern matching techniques generally match patterns in known exploits against input traffic, the matching techniques of the related art generally cannot detect zero-day exploits (e.g., the matching techniques of the related art generally are only applicable to known exploits).

[0015] Various embodiments include systems and / or methods for detecting malicious input strings or other exploit tools based on machine learning models. In some embodiments, the system (i) receives an input string, (ii) performs feature extraction, and (iii) uses a classifier to determine whether the input string is malicious based at least in part on the feature extraction results. As one example, performing feature extraction includes obtaining one or more feature vectors (e.g., feature vectors based at least in part on one or more characteristics of the input string). In some embodiments, the classifier corresponds to a model for determining whether the input string is malicious, and the model is trained using a machine learning process. Such classifiers have been found to identify known exploits and zero-day exploits, and the classifiers are highly accurate with a relatively low false positive rate.

[0016] Various embodiments include systems and / or methods for detecting exploits. The systems include one or more processors and a memory coupled to the one or more processors and configured to provide instructions to the one or more processors. The one or more processors are configured to receive an input string and determine, based at least in part on a machine learning model, whether the input string is malicious. In some embodiments, the input string is an SQL or a command injection string.

[0017] Various embodiments include a system and / or method for training a model to detect exploits. The system includes one or more processors and a memory coupled to the one or more processors and configured to provide instructions to the one or more processors. The one or more processors are configured to perform malicious feature extraction, perform exploit feature extraction based at least in part on term frequency-inverse document frequency (TF-IDF), and generate a set of feature vectors for training a machine learning model to detect SQL and / or command injection cyber attacks.

[0018] In some embodiments, the system trains a model to detect exploits. For example, the model may be a model trained using a machine learning process. Training the model includes obtaining sample exploit traffic, obtaining sample benign traffic, and obtaining a set of exploit features based at least in part on the sample exploit traffic and the sample benign traffic. In some embodiments, the set of exploit features is determined at least in part based on one or more characteristics of the exploit traffic. As one example, the set of exploit features is determined at least in part based on one or more characteristics of the exploit traffic relative to one or more characteristics of the benign traffic. The sample exploit traffic and / or malicious traffic may be generated using a traffic generation tool. As one example, the traffic generation tool is a known tool that generates malicious exploits. Exemplary traffic generation tools for generating exploit traffic are open source penetration testing tools such as Commix, developed by the Commix Project, or SQLmap, developed by the SQLmap project and available at https: / / SQLmap.org. As another example, the traffic generation tool may be an exploit emulation module, such as the Threat Emulation Module developed by Picus Security, Inc. The exploit traffic may include a malicious payload, such as a malicious SQL statement or other structured statement.

[0019] In some embodiments, the system performs malicious feature extraction in connection with generating (e.g., training) a model for detecting exploits. The malicious feature extraction can include one or more of: (i) using predefined regular expression statements to capture specific features from SQL and command injection strings; and (ii) using algorithm-based feature extraction to filter the described features from a set of raw input data.

[0020] In some embodiments, the predefined regular expression statements may be configured by a system administrator or other user. For example, the predefined regular expression statements may be manually defined and stored in the system (e.g., in a security policy or in a policy for training a model). As one example, at least a subset of the regular expression statements may be expert-defined. The regular expression statements may be statements that capture predetermined contextual patterns. For example, malicious structured statements are often part of a code language. According to various embodiments, feature extraction using regular expression statements identifies specific syntax contained in an input string (e.g., a command or SQL injection string).

[0021] In some embodiments, the algorithm-based feature extraction extracts a set of features using TF-IDF, hi some embodiments, a first subset of features obtained during malicious feature extraction are obtained using expert-generated regular expression statements, and a second subset of features obtained during malicious feature extraction are obtained using the algorithm-based feature extraction.

[0022] According to various embodiments, a traffic generation tool is used to generate exploit traffic in connection with generating a model for detecting exploits. The system performs malicious feature extraction based on the exploit traffic. The system then obtains training data used to train the model. For example, the training data includes exploit traffic and benign traffic. In some embodiments, feature extraction is performed on the exploit traffic, and training vectors are generated using the exploit traffic and benign traffic. Using exploit traffic as a basis for performing feature extraction and using both exploit traffic and benign traffic as a basis for generating training vectors can ensure a high-quality training data matrix that can be used to train different machine learning architectures. Using a traffic generation tool to generate exploit traffic for use in connection with generating a model can ensure that high-quality (e.g., correctly labeled) and diverse (e.g., covering many different exploits) traffic is used in the training data for the model.

[0023] According to various embodiments, a model for detecting exploit traffic is obtained using a machine learning process. Exemplary machine learning processes that can be implemented in connection with training the model include random forests, linear regression, support vector machines, naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient-boosted decision trees, K-means clustering, hierarchical clustering, density-based spatial clustering of noisy applications (DBSCAN) clustering, principal component analysis, etc. In some embodiments, an XGBoost machine learning classifier model is trained. The input to the classifier (e.g., an XGBoost machine learning classifier model) is a set of combined feature vectors, and based on the combined feature vectors, the classifier model determines whether corresponding traffic (e.g., an input string) is malicious or the likelihood that the traffic is malicious (e.g., whether the traffic is exploit traffic).

[0024] According to various embodiments, the models are trained using the XGBoost machine learning process. In some implementations, models trained using the XGBoost machine learning process are preferred because such models facilitate the transition from simple-version regex to pre-filter patterns supported by security entities (e.g., firewalls, etc.). XGBoost models have also been found to improve false positive rates and provide better exploit detection relative to deep learning models.

[0025] According to various embodiments, a system receives a URI path or parameters. In response to receiving the URI path or parameters, the system performs one or more decodings (e.g., multi-layer decoding) on ​​the URI path or parameters. Exemplary decodings the system may perform on the URI path or parameters include decoding based on URI percentage encoding, URI Unicode encoding, Hex encoding, HTML encoding, char() / chr() encoding, MIME encoding, etc. Various other encodings may be implemented. In response to performing the one or more decodings on the URI path or parameters, the system performs feature extraction on the results of the decoding. In some embodiments, the feature extraction includes regex-based feature extraction. The system then provides the results of the feature extraction (e.g., a feature vector) to a model to obtain a prediction of whether an input string (e.g., corresponding to a received URI or parameter) is malicious. In response to determining that the prediction indicates that the input string is malicious, the system treats the input string as exploit traffic. For example, the system implements one or more security policies regarding exploit traffic.

[0026] In some embodiments, a feature vector is obtained by applying predefined regular expression statement extraction and features obtained using algorithm-based feature extraction (e.g., features obtained using TF-IDF) to a combination of exploit traffic and benign traffic. The resulting feature vector can be highly accurate for distinguishing exploits from benign traffic because the previously extracted exploit features produce a vector with a distribution that is distinguishable from benign and exploit traffic. In some embodiments, the predefined regular expression statement can be modified to include previously unidentified exploits or to mitigate the false positive rate (e.g., by removing features that cause false positive detections). Thus, systems and methods for detecting exploits according to various embodiments are extensible and controllable to tune and better interpret detection results.

[0027] In some embodiments, features are extracted using only traffic selected as exploit traffic (e.g., exploit traffic generated from a traffic generation tool). For example, features are extracted based on exploit traffic, and benign traffic is not used in connection with feature extraction. Related techniques for extracting features generally use features extracted using all classes of input data—both malicious and benign traffic.

[0028] According to various embodiments, a system for detecting exploits (e.g., malicious input strings) is implemented by one or more servers. The one or more servers may provide services to one or more customers and / or security entities. For example, the one or more servers detect malicious input or determine / assess whether an input string is malicious and provide an indication of whether the input string is malicious to the one or more customers and / or security entities. The one or more servers provide the indication that the input string is malicious to the security entities in response to a determination that the input string is malicious and / or in conjunction with an update to a mapping of the input string to an indication of whether the input string is malicious (e.g., an update to a blacklist that includes identifiers associated with malicious input strings). As another example, the one or more servers determine whether the input string is malicious in response to a request from a customer or security entity for an assessment of whether the input string is malicious, and the one or more servers provide the results of such a determination. In some embodiments, in response to determining that the input string is malicious, the system updates the mapping of representative information / identifiers for the input string to malicious input strings to include a record or other indication that the input string is malicious. The system may provide a mapping to security entities, endpoints, etc.

[0029] In some embodiments, the system receives historical information regarding the maliciousness of input strings (e.g., a historical dataset of malicious input strings and a historical dataset of benign input strings) from a third-party service such as VirusTotal®. The third-party service may provide a set of input strings that are considered malicious and a set of input strings that are considered benign. As one example, the third-party service may analyze the input strings and provide an indication of whether the input string is malicious or benign and / or a score indicating the likelihood that the input string is malicious. The system may receive updates from the third-party service (e.g., at predetermined intervals, when updates are available, etc.), such as newly identified benign or malicious input strings, corrections to previous misclassifications, etc. In some embodiments, an indication of whether an input string in the historical dataset corresponds to a social score, such as a community-based score or rating (e.g., a reputation score), that indicates that the input string is malicious or likely to be malicious, is received. The system may use the historical information in connection with training a classifier (e.g., a classifier used to determine whether an input string is malicious).

[0030] According to various embodiments, a security entity and / or network node (e.g., a client, a device, etc.) treats traffic (e.g., an input string, a file, etc.) based at least in part on an indication that the traffic is malicious (e.g., the input string is malicious) and / or an indication that the input string matches an input string indicated to be malicious. In response to receiving an indication that traffic (e.g., an input string) is malicious, the security network and / or network node may update a mapping of input strings to indications of whether the corresponding input string is malicious and / or a blacklist of input strings. In some embodiments, the security entity and / or network node receives a signature for an input string (e.g., a sample deemed malicious), and the security entity and / or network node stores the signature of the input string for use in connection with detecting whether an input string obtained via network traffic, etc., is malicious (e.g., based at least in part on comparing a signature generated for the input string to signatures for input strings included in a blacklist of input strings). As one example, the signature may be a hash.

[0031] Firewalls typically deny or allow network transmissions 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 external traffic from reaching a protected device. 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 that may be specified in a firewall rule or firewall policy, which may be triggered based on various criteria, as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0032] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may perform various security operations (e.g., firewalls, anti-malware, intrusion prevention / detection, proxies, and / or other security functions), network functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other network functions), and / or other security and / or network-related functions. For example, routing may be performed based on source information (e.g., IP addresses and ports), destination information (e.g., IP addresses and ports), and protocol information.

[0033] Basic packet filtering firewalls filter network communication traffic by inspecting individual packets sent over the network (e.g., stateless packet filtering firewalls, or first-generation firewalls). Stateless packet filtering firewalls typically inspect the individual packets themselves and then apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).

[0034] Stateful firewalls can also perform stateful-based packet inspection, where each packet is inspected within the context of the set of packets associated with its network outgoing packet flow. This firewall technique is commonly referred to as stateful packet inspection because it keeps a record of all connections passing through the firewall and can determine whether a packet is the start of a new connection, part of an existing connection, or an invalid packet. For example, the state of a connection can itself be one of the criteria that triggers a rule in a policy.

[0035] Advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering, as described above. Next-generation firewalls can also implement additional firewall technologies. For example, existing new firewalls, often referred to as advanced or next-generation firewalls, can also identify users and content. In particular, existing next-generation firewalls have expanded 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 (e.g., the Palo Alto Networks PA Series Firewalls). For example, Palo Alto Networks next-generation firewalls use various identification technologies to enable enterprises and service providers to identify and control applications, users, and content—not just ports, IP addresses, and packets. Various identification technologies include Application ID (App-ID) for precise application identification, User ID (User-ID) for user identification (e.g., User ID), Content ID (Content-ID) for real-time content scanning (e.g., to control web surfing and restrict data and file transfers), and Device ID (e.g., for identifying IoT device types). These identification technologies allow enterprises to securely enable application usage using business-relevant concepts instead of following the traditional approach provided by traditional port-blocking firewalls.Additionally, special-purpose hardware for next-generation firewalls (e.g., implemented as dedicated devices) generally provides higher performance levels for application inspection than software running on general-purpose hardware (e.g., security appliances from Palo Alto Networks, Inc., which utilize dedicated, function-specific processing that is tightly integrated with a single-pass software engine to minimize latency while maximizing network throughput, as in the case of Palo Alto Networks' PA Series Next-Generation Firewalls).

[0036] 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 (Palo Alto Networks PA Series Next-Generation Firewalls, Palo Alto Networks VM Series Firewalls, which are deployed on VMware® ESXi, for example). TM and NSX TM , Citrix® Netscaler SDX TMThe CN Series Container Next-Generation Firewalls support a variety of commercial virtualization environments, including KVM / OpenStack (Centos / RHEL, Ubuntu®), and Amazon Web Services (AWS), and the CN Series Container Next-Generation Firewalls support a variety of commercial container environments, including Kubernetes. For example, virtualized firewalls can support similar or identical next-generation firewall and advanced threat prevention functions available in physical form factor devices, allowing enterprises to securely enable the influx of applications in private, public, and hybrid cloud computing environments. Automation capabilities such as VM monitoring, dynamic address groups, and REST-based APIs allow enterprises to dynamically monitor VM changes and update security policies with that context, thereby eliminating policy lag that can occur when VMs change.

[0037] According to various embodiments, a system for detecting exploits (e.g., malicious input strings) is implemented by a security entity. For example, the system for detecting malicious input strings is implemented by a firewall. As another example, the system for detecting malicious input strings is implemented by an application, such as an anti-malware application, running on a device (e.g., a computer, a laptop, a mobile phone, etc.). According to various embodiments, the security entity receives an input string, obtains information about the input string (e.g., a feature vector, a combined feature vector, a pattern of characters, etc.), and determines whether the input string is malicious based at least in part on the information about the input string. As one example, the system determines one or more feature vectors (e.g., a combined feature vector) corresponding to the input string and uses a classifier to determine whether the input string is malicious based at least in part on the one or more feature vectors. In response to determining that the input string is malicious, the security entity applies one or more security policies with respect to the input string. In response to determining that the input string is not malicious (e.g., the input string is benign), the security entity treats the input string as non-malicious traffic. In some embodiments, the security entity determines whether an input string is malicious based at least in part on performing a lookup on a mapping of information or identifiers representative of the input string (e.g., a calculated hash that uniquely identifies the input string, or another signature of the input string) to the malicious input string to determine whether the mapping includes matching representative information or identifiers for the input string (e.g., the mapping includes a record of an input string having a hash that matches the calculated hash of the received input string). Exemplary hash functions for determining a hash corresponding to a file include a SHA-256 hash function, an MD5 hash function, a SHA-1 hash function, etc.A variety of other hash functions may be implemented.

[0038] Various embodiments improve the detection of exploit traffic. Systems and methods for detecting exploits (e.g., neural network models) have been found to improve exploit detection by at least 20-30%, and in some implementations, increase exploit detection by 30-40%, over related art systems that rely on signature-based exploit detection or static pattern matching approaches to exploit detection. As one example, various embodiments were able to identify several recent exploits related to the Log4J library. As another example, an XGBoost model was found to have a false positive rate of approximately 0.0005% (as measured over an analysis of one month's traffic). As another example, a neural network model was found to have a false positive rate of approximately 0.34% (as measured over an analysis of one month's traffic). Use of systems and methods according to various embodiments provides detection of known and unknown exploits (e.g., zero-day exploits) with high accuracy and low false positive rates.

[0039] A comparison of detection was performed on various types of traffic using systems and methods for detecting exploits (e.g., using models trained using machine learning processes) according to various embodiments and a related art intrusion prevention system (IPS). The results of the comparison of detection using systems / methods according to various embodiments and a related art IPS are provided in Table 1 below. In Table 1, "ML" is used to represent systems / methods according to various embodiments. As shown in the ML over IPS column of Table 1, the systems / methods according to various embodiments detected a significantly higher number of exploits across various types of traffic compared to the related art IPS. Conversely, as shown in the IPS over ML column, the related art IPS was able to detect only a relatively small number of exploits that would not have been detected by the systems / methods according to various embodiments. [Table 1]

[0040] Exemplary exploits that may be detected by systems and methods for detecting exploits according to various embodiments include the following: [Table 2]

[0041] 1 is a block diagram of an environment in which malicious input strings are detected or suspected, according to various embodiments. In the illustrated example, client devices 104-108 are a laptop computer, a desktop computer, and a tablet (respectively) residing within corporate network 110 (belonging to "Acme Company"). Data appliance 102 is configured to enforce policies (e.g., security policies) regarding communications between client devices, such as client devices 104 and 106, and nodes external to corporate network 110 (e.g., reachable via external network 118). Examples of such policies include those governing traffic shaping, quality of service, and traffic routing. Other example policies include security policies requiring the scanning of incoming (and / or outgoing) email attachments, website content, input to application portals (e.g., web interfaces), files exchanged via instant messaging programs, and / or other file transfers for threats. In some embodiments, data appliance 102 is also configured to enforce policies regarding traffic that stays within (or enters) corporate network 110 .

[0042] The techniques described herein can be used with various platforms (e.g., desktops, mobile devices, gaming platforms, embedded systems, etc.) and / or various types of applications (e.g., Android .apk files, iOS applications, Windows PE files, Adobe Acrobat PDF files, Microsoft Windows PE installers, etc.). In the example environment shown in Figure 1, client devices 104-108 are a laptop computer, a desktop computer, and a tablet (respectively) that reside within enterprise network 110. Client device 120 is a laptop computer that resides outside enterprise network 110.

[0043] The data appliance 102 may be configured to operate in cooperation with a remote security platform 140. The security platform 140 may provide a variety of services, including performing static and dynamic analysis on malware samples, providing a list of signatures of known exploits (e.g., malicious input strings, malicious files, etc.) to a data appliance such as the data appliance 102 as part of a subscription, detecting exploits such as malicious input strings or malicious files (e.g., on-demand detection or periodic updates to the mapping of input strings or files to an indication of whether the input string or file is malicious or benign), providing a likelihood that an input string or file is malicious or benign, providing / updating a whitelist of input strings or files that are considered benign, providing / updating a whitelist of input strings or files that are considered malicious, identifying malicious input strings, detecting malicious input strings, detecting malicious files, predicting whether an input string or file is malicious, and providing an indication that an input string or file is malicious (or benign). In various embodiments, the results of the analysis (and additional information about the application, domain, etc.) are stored in database 160. In various embodiments, security platform 140 comprises one or more dedicated, commodity hardware servers (e.g., having multi-core processors, 32G+ RAM, Gigabit network interface adapters, and hard drives) running a typical server-class operating system (e.g., Linux). Security platform 140 may be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware.Security platform 140 may comprise several distributed components, including components provided by one or more third parties. For example, some or all of security platform 140 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Furthermore, similar to data appliance 102, whenever security platform 140 is referred to as performing a task, such as storing data or processing data, it should be understood that a subcomponent or subcomponents of security platform 140 may cooperate (individually or in cooperation with third-party components) to perform that task. As one example, security platform 140 may cooperate with one or more virtual machine (VM) servers to optionally perform static / dynamic analysis. One example of a virtual machine server is a physical machine including commercially available server-class hardware (e.g., multi-core processors, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running commercially available virtualization software, such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Additionally, the virtual machine servers may be under the control of the same entity that manages security platform 140, but may also be provided by a third party. As one example, the virtual machine servers may rely on EC2, with the remainder of security platform 140 being provided by dedicated hardware owned by and under the control of the operator of security platform 140.

[0044] In some embodiments, system 100 (e.g., malicious input string detector 170, security platform 140, etc.) trains a model to detect exploits (e.g., malicious input strings). System 100 performs malicious feature extraction and exploit feature extraction based at least in part on term frequency-inverse document frequency (TF-IDF) to generate a set of feature vectors for training a machine learning model to detect SQL and / or command injection cyber attacks. The system then uses the set of feature vectors to train the machine learning model, such as based on training data including one or more of malicious traffic and benign traffic.

[0045] According to various embodiments, security platform 140 includes DNS tunneling detector 138 and / or malicious input string detector 170. Malicious input string detector 170 is used in connection with determining whether an input string is malicious. In response to receiving a sample (e.g., an input string, such as an input string entered in connection with a login attempt), malicious input string detector 170 analyzes the input string and determines whether the input string is malicious. For example, malicious input string detector 170 determines one or more feature vectors (e.g., a combined feature vector) for the input string and uses a model to determine (e.g., predict) whether the input string is malicious. Malicious input string detector 170 determines whether the input string is malicious based at least in part on one or more attributes of the input string. In some embodiments, malicious input string detector 170 receives an input string, performs feature extraction (e.g., feature extraction on one or more attributes of the input string), and determines (e.g., predicts) whether the input string (e.g., an SQL or command injection string) is malicious based at least in part on the feature extraction results. For example, malicious input string detector 170 uses a classifier to determine (e.g., predicts) whether the input string is malicious based at least in part on the feature extraction results. In some embodiments, the classifier corresponds to a model for determining whether an input string is malicious, and the model is trained using a machine learning process.

[0046] In some embodiments, malicious input string detector 170 comprises one or more of input string parser 172 , prediction engine 174 , ML model 176 , and / or cache 178 .

[0047] Input string parser 172 is used in connection with determining (e.g., isolating) one or more attributes or sets of alphanumeric characters or values ​​associated with the input string being analyzed. In some embodiments, input string parser 172 obtains one or more attributes associated with (e.g., from) the input string. For example, input string parser 172 obtains from the input string one or more patterns (e.g., alphanumeric patterns), one or more sets of alphanumeric characters, one or more commands, one or more pointers or links, one or more IP addresses, etc.

[0048] In some embodiments, one or more feature vectors corresponding to the input string are determined by malicious input string detector 170 (e.g., input string parser 172 or prediction engine 174). For example, the one or more feature vectors are determined (e.g., populated) based at least in part on one or more attributes or sets of alphanumeric characters or values ​​associated with the input string. As one example, input string parser 172 uses one or more attributes associated with the input string in connection with determining the one or more feature vectors. In some embodiments, input string parser 172 determines a combined feature vector based at least in part on one or more feature vectors corresponding to the input string. As one example, the set of one or more feature vectors is determined (e.g., set or defined) based at least in part on a model used to detect exploits. Malicious input string detector 170 can use the set of one or more feature vectors to determine one or more attributes of the pattern to be determined (e.g., populated, etc.). The model may be trained using a set of features obtained based at least in part on samples of malicious traffic, such as a set of features corresponding to predefined regular expression statements and / or a set of feature vectors determined based on algorithm-based feature extraction. For example, the model may be determined based at least in part on performing malicious feature extraction in connection with generating (e.g., training) a model to detect exploits. The malicious feature extraction may include one or more of: (i) using predefined regular expression statements to obtain specific features from SQL and command injection strings; and (ii) using algorithm-based feature extraction to filter out the described features from a set of raw input data.

[0049] In response to malicious input string detector 170 receiving an input string for determining whether the input string is malicious (or the likelihood that the input string is malicious), malicious input string detector 170 determines one or more feature vectors (e.g., individual feature vectors corresponding to a set of predefined regular expression statements, individual feature vectors corresponding to attributes or patterns obtained using algorithm-based analysis of the exploit, and / or a combined feature vector of both, etc.). As one example, in response to determining (e.g., obtaining) the one or more feature vectors, malicious input string detector 170 (e.g., input string parser 172) provides (or makes accessible) the one or more feature vectors to prediction engine 174 (e.g., in connection with obtaining a prediction of whether the input string is malicious). As another example, malicious input string detector 170 (e.g., input string parser 172) stores the one or more feature vectors in cache 178, database 160, or the like.

[0050] In some embodiments, prediction engine 174 determines whether an input string is malicious based at least in part on one or more of: (i) a mapping of input strings to an indication of whether the corresponding input string is malicious; (ii) a mapping of an identifier of an input string (e.g., a hash or other signature associated with the input string) to an indication of whether the corresponding input string is malicious; and / or (iii) a classifier (e.g., a model trained using a machine learning process).

[0051] The prediction engine 174 is used to predict whether an input string is malicious. In some embodiments, the prediction engine 174 determines (e.g., predicts) whether a received input string is malicious. According to various embodiments, the prediction engine 174 determines whether a newly received input string is malicious based at least in part on the registration information. For example, the prediction engine 174 applies a machine learning model to determine whether a newly received input string is malicious. Applying the machine learning model to determine whether an input string is malicious may include the prediction engine 174 querying the machine learning model 176 (e.g., with information about the input string, one or more feature vectors, etc.). In some implementations, the machine learning model 176 is pre-trained, and the prediction engine 174 does not need to provide a set of training data (e.g., malicious traffic samples and / or benign traffic samples) to the machine learning model 176 at the same time as the query for an indication / determination of whether a particular input string is malicious. In some embodiments, prediction engine 174 receives information associated with whether an input string is malicious (e.g., an indication that the input string is malicious). For example, prediction engine 174 receives the results of a determination or analysis by machine learning model 176. In some embodiments, prediction engine 174 receives an indication of a likelihood that the input string is malicious from machine learning model 176. In response to receiving the indication of a likelihood that the input string is malicious, prediction engine 174 determines (e.g., predicts) whether the input string is malicious based at least in part on the likelihood that the input string is malicious. For example, prediction engine 174 compares the likelihood that the input string is malicious to a likelihood threshold. In response to a determination that the likelihood that the input string is malicious is greater than the likelihood threshold, prediction engine 174 can consider (e.g., determine) the input string to be malicious.

[0052] According to various embodiments, in response to the prediction engine 174 determining that a received input string is malicious, the system transmits an indication that the input string is malicious to a security entity. For example, the malicious input string detector 170 may transmit an indication that the input string is malicious to a security entity (e.g., a firewall) or a network node (e.g., a client). The indication that the input string is malicious may correspond to an update to a blacklist of input strings (e.g., corresponding to malicious input strings), such as when the received input string is deemed malicious, or to an update to a whitelist of input strings (e.g., corresponding to non-malicious input strings), such as when the received input string is deemed benign. In some embodiments, the malicious input string detector 170 transmits a hash or signature corresponding to the input string in association with the indication that the input string is malicious or benign. The security entity or endpoint may compute a hash or signature of the input string and perform a lookup (e.g., query a whitelist and / or blacklist) for a mapping of the hash / signature to an indication of whether the input string is malicious / benign. In some embodiments, the hash or signature uniquely identifies the input string.

[0053] The prediction engine 174 is used in connection with determining whether an input string is malicious (e.g., determining the likelihood or prediction of whether an input string is malicious). The prediction engine 174 uses information about the input string (e.g., one or more attributes, patterns, etc.) in connection with determining whether a corresponding input string is malicious.

[0054] The prediction engine 174 is used to determine whether an input string is malicious. The prediction engine 174 uses information about the input string (e.g., alphanumeric characters, character strings, patterns, or other information determined based on an analysis of the input string) in connection with determining whether the corresponding input string is malicious. In some embodiments, the prediction engine 174 determines a set of one or more feature vectors based at least in part on the information about the input string. For example, the prediction engine 174 determines (e.g., characterizes) a feature vector for one or more of: (i) a set of regular expression statements (e.g., predefined regular expression statements); and / or (ii) one or more properties or relationships determined based on algorithm-based feature extraction. In some embodiments, the prediction engine 174 uses a combined feature vector in connection with determining whether an input string is malicious. The combined feature vector is determined at least in part based on a set of one or more feature vectors. For example, the combined feature vector is determined at least in part based on a set of feature vectors for a set of predefined regular expression statements and a set of feature vectors for properties or relationships determined based on algorithm-based feature extraction. In some embodiments, the prediction engine 174 determines a combined feature vector by concatenating a set of feature vectors for a predefined set of regular expression statements and / or a set of feature vectors for properties or relationships determined based on algorithm-based feature extraction. The prediction engine 174 concatenates the sets of feature vectors according to a predefined process (e.g., a predefined order, etc.).

[0055] In response to determining the set of feature vectors or the combined feature vector, the prediction engine uses a classifier to determine whether the input string is malicious (or the likelihood that the input string is malicious). The classifier is used to determine whether the input string is malicious based at least in part on the set of feature vectors or the combined feature vector. In some embodiments, the classifier is a machine learning classifier, such as a classifier trained using a machine learning process. The prediction engine 174 uses the results of analyzing the set of feature vectors or the combined feature vector with the classifier to determine whether the input is malicious. In some embodiments, the classifier corresponds to the machine learning model 176.

[0056] According to various embodiments, the prediction engine 174 uses a set of feature vectors obtained based on a dynamic analysis of the input string to determine whether the input string is malicious. In some embodiments, the prediction engine 174 uses the combined feature vector in connection with determining whether the input string is malicious. As one example, in response to determining the corresponding feature vector, the prediction engine 174 uses a classifier to determine whether the input string is malicious (or the likelihood that the input string is malicious). In some embodiments, if the result of analyzing the feature vector (e.g., the combined feature vector) using the classifier is below a predefined threshold (e.g., a predefined maliciousness threshold), the system considers (e.g., determines) the input string to be non-malicious (e.g., the input string is benign). For example, if the result of analyzing the feature vector indicates a likelihood that the input string is malicious, the predefined threshold can correspond to a threshold likelihood. As another example, if the result from analyzing the feature vector indicates a similarity of the input string to a malicious input string, the predefined threshold can correspond to a threshold likelihood. In some embodiments, if the result of analyzing the feature vector (e.g., the combined feature vector) using the classifier is greater than (or equal to or greater than) a predefined threshold, the system considers (e.g., determines) the input string to be malicious (e.g., the input string is an exploit).

[0057] In response to receiving an input string to be analyzed, malicious input string detector 170 can determine whether the input string corresponds to a previously analyzed input string (e.g., whether the input string matches an input string associated with historical information from which a malicious determination was previously calculated). As one example, malicious input string detector 170 determines whether an identifier or representative information corresponding to the input string is included in historical information (e.g., a blacklist, a whitelist, etc.). In some embodiments, the representative information corresponding to the input string is a hash or signature of the input string. In some embodiments, malicious input string detector 170 (e.g., prediction engine 174) determines whether information regarding a particular input string is included in a dataset of historical input strings and whether the particular input string is malicious (e.g., VirusTotal TM In response to determining that information about a particular input string is not included in or available from the dataset of historical input strings and historical information, malicious input string detector 170 may consider the input string to have not yet been analyzed, and malicious input string detector 170 may invoke dynamic analysis of the input string in connection with determining (e.g., predicting) whether the input string is malicious (e.g., malicious input string detector 170 may query a classifier based on the input string in connection with determining whether the input string is malicious). One exemplary historical information associated with historical input strings that indicates whether a particular input string is malicious is VirusTotal. (R)The historical information associated with the historical input strings indicates whether the particular input string is malicious, and corresponds to a social score, such as a community-based score or rating (e.g., a reputation score), indicating whether the input string is malicious or likely to be malicious. The historical information (e.g., from a third-party service, a community-based score, etc.) indicates whether other vendors or cybersecurity organizations consider the particular input string to be malicious.

[0058] In some embodiments, malicious input string detector 170 (e.g., prediction engine 174) determines that a received input string has been newly analyzed (e.g., the input string is not found in historical information / datasets, is not on a whitelist or blacklist, etc.). Malicious input string detector 170 (e.g., input string parser 172) may detect that an input string has been newly analyzed in response to security platform 140 receiving the input string from a security entity (e.g., a firewall) or endpoint in the network. For example, malicious input string detector 170 determines that an input string has been newly analyzed upon receipt of the input string by security platform 140 or malicious input string detector 170. As another example, malicious input string detector 170 (e.g., prediction engine 174) determines that an input string has been newly analyzed according to a predefined schedule (e.g., daily, weekly, monthly, etc.), such as in connection with a batch process. In response to determining that such received input string has not yet been analyzed for maliciousness (e.g., the system does not have historical information regarding such input string), malicious input string detector 170 determines whether to use dynamic analysis of the input string in connection with determining whether the input string is malicious (e.g., querying a classifier to analyze the input string or one or more feature vectors associated with the input string), and malicious input string detector 170 uses a classifier on a set of feature vectors or combined feature vectors related to characteristics or relationships of attributes or features in the input string.

[0059] The machine learning model 176 predicts whether an input string (e.g., a newly received input string) is malicious or not based at least in part on the model. As one example, the model is pre-stored and / or pre-trained. The model may be trained using various machine learning processes. Exemplary machine learning processes that may be implemented in connection with training the model include random forests, linear regression, support vector machines, naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient-boosted decision trees, K-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. According to various embodiments, the machine learning model 176 uses attributes, feature relationships and / or patterns, and relationships between attributes or features for the input string and / or training set to infer whether the input string is malicious, such as to predict the likelihood that the input string is malicious. For example, machine learning model 176 may use a machine learning process to analyze a set of relationships between an indication of whether an input string is malicious (or benign) and one or more attributes related to the input string, and then use the set of relationships to generate a predictive model for predicting whether a particular input string is malicious. In some embodiments, in response to predicting that a particular input string is malicious, an association between the input string and the indication that the input string is malicious is stored in malicious input string detector 170 (e.g., cache 178), etc. In some embodiments, in response to predicting that a particular input string is likely to be malicious, an association between the input string and the likelihood that the input string is malicious is stored in malicious input string detector 170 (e.g., cache 178), etc. Machine learning model 176 may provide an indication of whether an input string is malicious or the likelihood that the input string is malicious to prediction engine 174.In some embodiments, the machine learning model 176 provides an indication to the prediction engine 174 that the analysis by the machine learning model 176 is complete and that the corresponding results (e.g., predicted results) are stored in the cache 178.

[0060] According to various embodiments, the machine learning model 176 uses one or more features in connection with predicting whether an input string is malicious (or the likelihood that an input string is malicious). For example, the machine learning model 176 may be trained using one or more features. Exemplary features used in connection with training / applying the machine learning model 176 include (a) a set of features each corresponding to a set of predefined regular expression statements, (b) a set of features obtained based on algorithm-based feature extraction (e.g., obtained based on generated sample malicious traffic), etc. Various other features may be implemented in connection with training and / or applying the model. In some embodiments, a set of features is used to train and / or apply the model. Weightings may be used to weight each feature in the set of features used to train and / or apply the model. The weightings may be determined at least in part based on generating (e.g., determining) the model.

[0061] Cache 178 stores information about input strings. In some embodiments, cache 178 stores a mapping of an indication of whether an input string is malicious (or likely to be malicious) to a particular input string, or a mapping of an indication of whether an input string is malicious (or likely to be malicious) to a hash or signature corresponding to the input string. Cache 178 may store additional information about the set of input strings, such as attributes of the input string, hashes or signatures corresponding to input strings in the set of input strings, other unique identifiers corresponding to input strings in the set of input strings, etc.

[0062] Returning to FIG. 1 , assume that a malicious individual (using client device 120) has created malware or malicious input string 130. The malicious individual wants a client device, such as client device 104, to execute a copy of the malware or other exploit (malware or malicious input string) 130, compromising the client device and causing the client device to become a bot in a botnet. The compromised client device can then be instructed to perform a task (e.g., cryptocurrency mining or participating in a denial-of-service attack) and / or report information to an external entity, such as command and control (C&C) server 150 (e.g., extracting sensitive corporate data associated with such task), and, if applicable, to receive instructions from C&C server 150.

[0063] 1 includes three Domain Name System (DNS) servers (122-126). As shown, DNS server 122 is under ACME's control (for use by computing assets located within network 110), while DNS server 124 is publicly accessible (and may also be used by computing assets located within enterprise network 110 as well as other devices, such as those located within other networks (e.g., networks 114 and 116)). DNS server 126 is publicly accessible but is under the control of malicious operators of C&C server 150. Enterprise DNS server 122 is configured to resolve enterprise domain names to IP addresses and is further configured to communicate with one or more external DNS servers (e.g., DNS servers 124 and 126) to resolve domain names, if applicable.

[0064] As described above, to connect to a legitimate domain (e.g., www.example.com, shown as website 128), a client device, such as client device 104, needs to resolve the domain to a corresponding Internet Protocol (IP) address. One way such resolution can occur is for client device 104 to forward a request to DNS servers 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 use the IP address to connect to website 128. Similarly, to connect to malicious C&C server 150, client device 104 needs to resolve the domain "kj32hkjqfeuo32ylhkjshdflu23.badsite.com" to a corresponding Internet Protocol (IP) address. In this example, the malicious DNS server 126 is authoritative for *.badsite.com, and requests from the client device 104 are forwarded to the DNS server 126 for resolution (for example), ultimately allowing the C&C server 150 to receive data from the client device 104.

[0065] Data appliance 102 is configured to enforce policies regarding communications between client devices, such as client devices 104 and 106, and nodes outside enterprise network 110 (e.g., those reachable via external network 118). Examples of such policies include those governing traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as those requiring threat scanning of incoming (and / or outgoing) email attachments, website content, information entry into web interfaces such as login screens, files exchanged via instant messaging programs, and / or other file transfers, and / or the quarantine or removal of files or other exploits identified as malicious (or likely malicious). In some embodiments, data appliance 102 is also configured to enforce policies regarding traffic remaining within enterprise network 110.

[0066] In various embodiments, the data appliance 102 includes a DNS module 134 configured to facilitate determining whether a client device (e.g., a client device 104-108) is attempting to engage in malicious DNS tunneling and / or prevent connections (e.g., by a client device 104-108) to malicious DNS servers. The DNS module 134 can be integrated into the data appliance 102 (as shown in FIG. 1) or, in various embodiments, can operate as a standalone appliance. And, like the other components shown in FIG. 1, the DNS module 134 can be provided by the same entity that provides the data appliance 102 (or security platform 140) or can be provided by a third party (e.g., different from the provider of the data appliance 102 or security platform 140). Furthermore, in addition to preventing connections to malicious DNS servers, the DNS module 134 can take other actions, such as individualized logging of tunneling attempts made by clients (indicating that a given client has been compromised and should be quarantined or otherwise investigated by an administrator).

[0067] 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 may be performed simultaneously with the resolution of the domain (e.g., simultaneously with the request sent to DNS servers 122, 124, and / or 126 and security platform 140). As one example, DNS module 134 may send a query (e.g., in JSON format) to front end 142 of security platform 140 via a REST API. Using a process described in more detail below, security platform 140 determines (e.g., using DNS tunneling detector 138, such as decision engine 152 of DNS tunneling detector 138) whether the queried domain indicates a malicious DNS tunneling attempt and returns a result (e.g., “malicious DNS tunneling” or “not tunneling”) to DNS module 134.

[0068] In various embodiments, when a client device (e.g., client device 104) attempts to resolve an SQL statement, SQL command, or other command injection string, the data appliance 102 uses the corresponding input string as a query to security platform 140. This query may be performed simultaneously with the resolution of the SQL statement, SQL command, or other command injection string. As one example, the data appliance 102 may send a query (e.g., in JSON format) to the front end 142 of security platform 140 via a REST API. Using a process described in more detail below, security platform 140 determines (e.g., using malicious input string detector 170) whether the queried SQL statement, SQL command, or other command injection string indicates an exploit attempt and returns a result (e.g., “malicious exploit” or “benign traffic”) to the data appliance 102.

[0069] In various embodiments, when a client device (e.g., client device 104) attempts to open or receives a file or input string received via email, an attachment to an instant message, or otherwise exchanged over a network, DNS module 134 uses the file or input string (or a computed hash or signature, or other unique identifier, etc.) as a query to security platform 140. This query may be performed immediately upon receipt of the file or input string or in response to a request from a user to scan the file. As one example, data appliance 102 may send a query (e.g., in JSON format) to front end 142 of security platform 140 via a REST API. Using processing described in more detail below, security platform 140 determines whether the queried file is malicious (or is likely malicious) (e.g., using a malicious file detector, which may be similar to malicious input string detector 170, such as by using a machine learning model to detect / predict whether a file is malicious) and returns a result (e.g., "malicious file" or "benign file") to data appliance 102.

[0070] In various embodiments, the DNS tunneling detector 138 (implemented either on the security platform 140, on the data appliance 102, or any other suitable location / combination of locations) uses a two-pronged approach in identifying malicious DNS tunneling. The first technique uses an 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 implemented using Go, for example). The two approaches are complementary. The anomaly detector functions as a general-purpose detector that can identify previously unknown tunneling traffic. However, the anomaly detector may need to observe multiple DNS queries before detection can occur. To block first DNS tunneling packets, the similarity detector 144 complements the anomaly detector 146 and extracts signatures from the detected tunneling traffic. It can be used to identify situations where attackers have registered new malicious tunneling root domains and done so using tools / malware similar to detected root domains.

[0071] When data appliance 102 receives DNS queries (e.g., from DNS module 134), data appliance 102 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.

[0072] DNS tunneling detector 138 maintains, for each device (from which data is received), a set of fully qualified domain names (FQDNs) grouped about their root domain (collectively shown in FIG. 1 as domain profile 156). (Although domains are generally described herein as grouping by root, it should also be understood that the techniques described herein may be extended to any level of domain.) In various embodiments, information about received queries for a given domain is persisted in the profile for a fixed amount of time (e.g., a 10-minute sliding time window).

[0073] As an example, DNS query information received from data appliance 102 for various foo.com sites is grouped as follows (into a domain profile for the root domain foo.com): G(foo.com)=[mail.foo.com, coolstuff.foo.com,domain1234.foo.com]. A second root domain would have a second profile with similar application information (e.g., G(baddomain.com) = [lskjdf23r.baddomain.com, kj235hdssd233.baddomain.com]). Each root domain (e.g., foo.com or baddomain.com) is modeled with a set of characteristics specific to malicious DNS tunneling, so that even diverse benign DNS patterns (e.g., k2jh3i8y35.legitimatesite.com, xxx888222000444.otherlegitimatesite.com) are highly unlikely to be misclassified as malicious tunneling. The following are example characteristics that may be extracted as features (e.g., into a feature vector) for a given group of domains (i.e., sharing a root domain):

[0074] In some embodiments, malicious input string detector 170 provides an indication of whether an input string is malicious to a security entity, such as data appliance 102. For example, in response to determining that an input string is malicious, malicious input string detector 170 sends an indication that the input string is malicious to data appliance 102, and the data appliance may then implement one or more security policies based at least in part on the indication that the input string is malicious. The one or more security policies may include isolating / quarantining the input string, deleting the input string, ensuring that the input string is not executed or resolved, warning or prompting a user about the malicious intent of the input string before the user opens / executes the input string, etc. As another example, in response to determining that an input string is malicious, malicious input string detector 170 provides the security entity with an update to the mapping of the input string (or a hash, signature, or other unique identifier corresponding to the input string) to an indication of whether the corresponding input string is malicious or not, or an update to a blacklist of malicious input strings (e.g., identifying input strings) or a whitelist of benign input strings (e.g., identifying input strings that are not considered malicious).

[0075] Figure 2 is a block diagram of a system for detecting malicious input strings, according to various embodiments. According to various embodiments, system 200 is implemented in conjunction with system 100 of Figure 1, such as with malicious input string detector 170. In various embodiments, system 200 is implemented in conjunction with process 600 of Figure 6, process 700 of Figure 7, process 800 of Figure 8, process 900 of Figure 9, process 1000 of Figure 10, process 1100 of Figure 11, and / or process 1200 of Figure 12. System 200 may be implemented in one or more servers, security entities such as firewalls, and / or endpoints.

[0076] System 200 may be implemented by one or more devices, such as a server. System 200 may be implemented at various locations on a network. In some embodiments, system 200 implements malicious input string detector 170 of system 100 of FIG. 1 . As one example, system 200 is deployed as a service, such as a web service (e.g., system 200 or the malicious input string detector is deployed on a remote server that monitors or receives input strings sent into / out of the network, such as input into a web interface, such as a login screen, authentication interface, query interface, etc., or via attachments to email, instant messages, etc., determines whether the input string is malicious, and sends / pushes notifications or updates regarding the input string, such as an indication of whether the input string is malicious). As another example, a malicious file detector is deployed on a firewall.

[0077] According to various embodiments, in response to receiving an input string to be analyzed to determine whether the input string is malicious, system 200 uses a classifier to determine whether the input string is malicious (or determine the likelihood that the input string is malicious). For example, system 200 uses a classifier to provide a prediction of whether the input string is malicious. In some embodiments, system 200 determines one or more feature vectors corresponding to the input string and uses the classifier to analyze the one or more feature vectors in connection with determining whether the input string is malicious.

[0078] In some embodiments, the system 200 (i) receives an input string, (ii) performs feature extraction, and (iii) uses a classifier to determine whether the input string is malicious based at least in part on the feature extraction results.

[0079] In the illustrated example, system 200 implements one or more modules associated with predicting whether an input string (e.g., a newly received file) is malicious, determining the likelihood that the input string is malicious, and / or providing notification or indication of whether the input string is malicious. System 200 includes a communications interface 205, one or more processors 210, storage 215, and / or memory 220. One or more processors 210 include one or more of a communications module 225, a string injection module 227, a feature vector determination module 229, a sample traffic acquisition module 231, a model training module 233, a prediction module 235, a notification module 237, and a security enforcement module 239.

[0080] In some embodiments, system 200 includes a communications module 225. System 200 uses communications module 225 to communicate with various nodes or endpoints (e.g., client terminals, firewalls, DNS resolvers, data appliances, other security entities, etc.) or user systems, such as administrator systems. For example, communications module 225 provides information to be communicated (e.g., to another node, security entity, etc.) to communications interface 205. As another example, communications interface 205 provides information received by system 200 to communications module 225. Communications module 225 is configured to receive an input string or file to be analyzed, such as from a network endpoint or node, such as a security entity (e.g., a firewall), a database system, a query system, etc. Communications module 225 is configured to query a third-party service for information about the input string (e.g., a service that publishes a third-party score or rating of the maliciousness of the input string, a community-based score, rating, or reputation for the input string, a blacklist of input strings, and / or a whitelist of files for the input string, etc.). For example, the system 200 uses the communications module 225 to query a third-party service. The communications module 225 is configured to receive one or more settings or configurations from an administrator. Examples of the one or more settings or configurations include a process for determining whether an input string is malicious, a format or process according to which the combined feature vector is to be determined, a set of feature vectors to be provided to a classifier to determine whether an input string is malicious, a set of regular expression statements from which the feature vector is to be determined (e.g., a predefined set of regular expression statements or updates to a stored set of regular expression statements, etc.), configuration related to traffic to be generated, such as related to generating training data or data from which features are to be extracted, information related to a whitelist of input strings (e.g., input strings that are not considered suspicious and for which traffic or attachments are allowed), and information related to a blacklist of input strings (e.g., input strings that are considered suspicious and for which traffic should be quarantined, deleted, or otherwise restricted from execution).

[0081] In some embodiments, system 200 includes a string injection module 227. System 200 uses string injection module 227 to obtain an input string and / or determine one or more characteristics or attributes associated with the input string. For example, string injection module 227 parses the input string. In some embodiments, string injection module 227 determines representative information or an identifier associated with the input string. For example, string injection module 227 determines a hash or another signature of the input string that uniquely identifies the input string.

[0082] In response to determining the representative information or identifier associated with the input string, system 200 (e.g., prediction module 235) may determine whether the input string corresponds to a previously analyzed input string (e.g., whether the input string matches an input string associated with historical information for which a malicious determination was previously calculated). As one example, prediction module 235 queries a database or mapping of previously analyzed input strings and / or historical information, such as a blacklist of input strings and / or a whitelist of input strings, in connection with determining whether the input string has been previously analyzed. In some embodiments, in response to determining that the input string does not correspond to a previously analyzed input string, prediction module 235 uses a classifier (e.g., a model, such as a model trained using a machine learning process) to determine (e.g., predict) whether the input string is malicious. In some embodiments, in response to determining that the input string corresponds to a previously analyzed input string, prediction module 235 obtains an indication of whether the corresponding previously analyzed input string is malicious. The prediction module 235 can use an indication of whether a corresponding previously analyzed input string is malicious as an indication of whether a received input string is malicious.

[0083] The string injection module 227 may receive the input string from an interface such as a login interface for a web application, a query interface, an SQL interface, a user interface for a database, etc. In some embodiments, the string injection module 227 receives the input string from a node such as a security entity (e.g., a firewall or other entity that enforces a security policy), which communicates the input string to the node before the node executes the input string.

[0084] In some embodiments, system 200 includes feature vector determination module 229. System 200 uses feature vector determination module 229 to determine one or more feature vectors for (e.g., corresponding to) the input string. For example, system 200 uses feature vector determination module 229 to determine a set of feature vectors or a combined feature vector for use in connection with determining whether the input string is malicious. In some embodiments, feature vector determination module 229 determines the set of one or more feature vectors based at least in part on information about the input string. For example, feature vector determination module 229 determines one or more feature vectors (e.g., characterizations) of (i) a set of regular expression statements (e.g., pre-defined regular expression statements) and / or (ii) one or more properties or relationships determined based on algorithm-based feature extraction.

[0085] In some embodiments, system 200 (e.g., prediction module 235) uses combined feature vectors in connection with determining whether an input string is malicious. Feature vector determination module 229 may determine such combined feature vectors. The combined feature vectors may be determined based at least in part on a set of one or more feature vectors. For example, the combined feature vector may be determined based at least in part on a set of feature vectors for a predefined set of regular expression statements and a set of feature vectors for characteristics or relationships determined based on algorithm-based feature extraction. In some embodiments, feature vector determination module 229 determines the combined feature vector by concatenating the set of feature vectors for the predefined set of regular expression statements and / or the set of feature vectors for characteristics or relationships determined based on algorithm-based feature extraction. Feature vector determination module 229 concatenates the set of feature vectors according to a predefined process (e.g., a predefined order, etc.).

[0086] In some embodiments, system 200 includes sample traffic acquisition module 231. System 200 uses sample traffic acquisition module 231 to acquire traffic in connection with determining one or more features and / or to train a model for determining whether an input string is malicious or a relationship (e.g., feature) between characteristics of the input string and the maliciousness of the input string. In some embodiments, sample traffic acquisition module 231 acquires sample traffic based on generating traffic, such as by using (e.g., invoking) a traffic generation tool. For example, sample traffic acquisition module 231 may comprise a traffic generation tool.

[0087] In some embodiments, system 200 trains a model for detecting exploits. For example, the model may be a model trained using a machine learning process. In connection with training the model, system 200 acquires sample exploit traffic (e.g., using sample traffic acquisition module 231), acquires sample benign traffic (e.g., using sample traffic acquisition module 231), and acquires a set of exploit features based at least in part on the sample exploit traffic and the sample benign traffic. In some embodiments, the set of exploit features is determined (e.g., by model training module 233) based at least in part on one or more characteristics of the exploit traffic. As one example, the set of exploit features is determined based at least in part on one or more characteristics of the exploit traffic relative to one or more characteristics of the benign traffic.

[0088] In some embodiments, the sample traffic acquisition module 231 uses a traffic generation tool to acquire sample exploit traffic and / or other malicious traffic. As one example, the traffic generation tool is a known tool for generating malicious exploits. An exemplary traffic generation tool for generating exploit traffic is an open-source penetration testing tool such as Commix, developed by the Commix Project, or SQLmap, developed by the SQLmap project and available at https: / / SQLmap.org. As another example, the traffic generation tool can be an exploit emulation module, such as the Threat Emulation Module, developed by Picus Security, Inc. Exploit traffic can include malicious payloads, such as malicious SQL statements or other structured statements.

[0089] In response to obtaining the sample exploit traffic, the system 200 performs feature extraction (e.g., malicious feature extraction) using the model training module 233. The malicious feature extraction may include one or more of: (i) using predefined regular expression statements to obtain specific features from SQL and command injection strings; and (ii) using algorithm-based feature extraction to filter the described features from a set of raw input data. In some embodiments, the system 200 (e.g., the model training module 233) uses the sample exploit traffic (e.g., malicious traffic) in connection with determining one or more features (e.g., performing malicious feature extraction) and does not sample benign traffic. In some embodiments, the system 200 (e.g., the model training module 233) uses both the sample exploit traffic (e.g., malicious traffic) and the sample benign traffic in connection with determining one or more features (e.g., performing malicious feature extraction).

[0090] In some embodiments, the predefined regular expression statements may be configured by a system administrator or other user. For example, the predefined regular expression statements may be manually defined and stored in the system (e.g., stored in a security policy or in a policy for training a model). As one example, at least a subset of the regular expression statements may be expert-defined. A regular expression statement may be a statement that captures a predetermined context pattern. For example, malicious structured statements are often part of a code language. According to various embodiments, feature extraction using regular expression statements identifies specific syntax contained in an input string (e.g., a command or SQL injection string).

[0091] In some embodiments, the algorithm-based feature extraction extracts a set of features using TF-IDF, hi some embodiments, a first subset of features obtained during malicious feature extraction are obtained using expert-generated regular expression statements, and a second subset of features obtained during malicious feature extraction are obtained using algorithm-based feature extraction.

[0092] In some embodiments, system 200 includes a model training module 233. System 200 uses model training module 233 to determine a model for determining whether an input string is malicious or the relationship (e.g., features) between characteristics of the input string and the maliciousness of the input string. Exemplary machine learning processes that may be implemented in connection with training the model include random forests, linear regression, support vector machines, naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient-boosted decision trees, K-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. In some embodiments, model training module 233 trains an XGBoost machine learning classifier model. The input to the classifier (e.g., an XGBoost machine learning classifier model) is a combined feature vector or set of feature vectors, and based on the combined feature vector or set of feature vectors, the classifier model determines whether the corresponding input string is malicious or the likelihood that the input string is malicious.

[0093] In some embodiments, system 200 includes a prediction module 235. System 200 uses prediction module 235 to determine (e.g., predict) whether an input string is malicious or the likelihood that the input string is malicious. Prediction module 235 uses a model, such as a machine learning model trained by model training module 233, in connection with determining whether an input string is malicious or the likelihood that the input string is malicious. For example, prediction module 235 uses an XGBoost machine learning classifier model to analyze the combined feature vector to determine whether the input string is malicious.

[0094] In some embodiments, the prediction module 235 compares information about a particular input string (e.g., a hash or other signature corresponding to the input string being analyzed) with a dataset of historical input strings and a historical dataset (e.g., VirusTotal) that indicates whether a particular input string is malicious or not. TMIn response to determining that information about a particular input string is not included in or available from the dataset of historical input strings and historical information, the prediction module 235 may consider the input string to be benign (e.g., not malicious). An example of historical information associated with a historical input string that indicates whether a particular input string is malicious corresponds to a VirusTotal® (VT) score. If the VT score for a particular input string is greater than 0, the particular input string is considered malicious by the third-party service. In some embodiments, historical information associated with a historical input string that indicates whether a particular input string is malicious corresponds to a social score, such as a community-based score or rating (e.g., a reputation score), that indicates that the input string is malicious or likely to be malicious. The historical information (e.g., from a third-party service, community-based score, etc.) indicates whether other vendors or cybersecurity organizations consider the particular input string to be malicious.

[0095] The system 200 may determine (e.g., calculate) a hash or signature corresponding to the input string and perform a lookup against historical information (e.g., a whitelist, a blacklist, etc.). In some implementations, the prediction module 235 corresponds to or is similar to the prediction engine 174. The system 200 (e.g., the prediction module 235) may query a third party (e.g., a third-party service) via the communication interface 205 for historical information about the input string (or a set of input strings or hashes / signatures for input strings previously deemed malicious or benign). The system 200 (e.g., the prediction module 235) may query the third party at predetermined intervals (e.g., customer-specified intervals, etc.). As one example, the prediction module 235 may query the third party for registration information for newly analyzed input strings daily (or daily during the business week).

[0096] In some embodiments, system 200 includes notification module 237. System 200 uses notification module 237 to provide an indication of whether an input string is malicious (e.g., provide an indication that the input string is malicious). For example, notification module 237 obtains an indication of whether an input string is malicious (or the likelihood that the input string is malicious) from prediction module 235 and provides the indication of whether the input string is malicious to one or more security entities and / or one or more endpoints. As another example, notification module 237 provides updates to an input string whitelist and / or input string blacklist to one or more security entities (e.g., firewalls), nodes, or endpoints (e.g., client terminals). According to various embodiments, notification module 237 obtains a hash, signature, or other unique identifier associated with the input string and provides an indication of whether the input string is malicious in relation to the hash, signature, or other unique identifier associated with the input string.

[0097] According to various embodiments, the hash of the input string corresponds to a hash using a predefined hash function (e.g., an MD5 hash function, etc.). A security entity or endpoint may calculate a hash of a received input string (e.g., an SQL statement or command, or other command injection string entered into an SQL interface or other database user interface, etc.). The security entity or endpoint may determine whether the calculated hash corresponding to the input string is included within a set, such as a whitelist of benign input strings and / or a blacklist of malicious input strings. If a signature for malware (e.g., the hash of the received input string) is included in a set of signatures of malicious input strings (e.g., a blacklist of malicious input strings), the security entity or endpoint may prevent the input string from being sent to an endpoint (e.g., a client device, a database system, etc.) and / or, accordingly, prevent the input string from being opened or executed.

[0098] According to various embodiments, storage 215 includes one or more of file system data 260, model data 265, and / or prediction data 270. Storage 215 includes shared storage (e.g., a network storage system), and / or database data, and / or user activity data.

[0099] In some embodiments, file system data 260 comprises a database of one or more data sets (e.g., one or more data sets of input strings, exploit traffic, and / or input string attributes, mappings of indicators of maliciousness to input strings or hashes, signatures or other unique identifiers for input strings, mappings of indicators of benign input strings to input strings or hashes, signatures or other unique identifiers for input strings, etc.) File system data 260 includes data such as historical information about input strings (e.g., the maliciousness of input strings), a whitelist of input strings that are considered safe (e.g., not suspicious), a blacklist of input strings that are considered suspicious or malicious (e.g., input strings that exceed a pre-defined / pre-set likelihood threshold to be considered malicious), information associated with suspicious or malicious input strings, etc.

[0100] In some embodiments, file system data 260 includes one or more dataset databases, such as input strings, exploit traffic, and / or input string attributes, mappings of indicators of maliciousness to input strings or hashes, signatures or other unique identifiers for input strings, mappings of indicators of benign input strings to input strings or hashes, signatures or other unique identifiers for input strings, etc. File system data 260 includes data such as historical information about input strings (e.g., the maliciousness of input strings), whitelists of input strings that are considered safe (e.g., non-suspicious, benign, etc.), blacklists of input strings that are considered suspicious or malicious (e.g., input strings that exceed a predefined / pre-set likelihood threshold to be considered malicious), information associated with suspicious or malicious input strings, etc.

[0101] Model data 265 includes information regarding one or more models used to determine whether an input string is malicious or the likelihood that an input string is malicious. As one example, model data 265 stores a classifier (e.g., an XGBoost machine learning classifier model) used in conjunction with a set of feature vectors or a combined feature vector. Model data 265 includes feature vectors that may be generated for each of one or more of: (i) a set of regular expression statements and / or (ii) algorithm-based features (e.g., features extracted using TF-IDF for sample exploit traffic, etc.). In some embodiments, model data 265 comprises a combined feature vector generated based at least in part on one or more feature vectors corresponding to each of one or more of: (i) a set of regular expression statements and / or (ii) algorithm-based features (e.g., features extracted using TF-IDF for sample exploit traffic, etc.).

[0102] Prediction data 270 includes information related to a determination of whether an input string analyzed by system 200 is malicious. For example, prediction data 270 stores an indication that the input string is malicious, an indication that the input string is benign, etc. The relevant information may be obtained by notification module 237 and provided (e.g., communicated to an applicable security entity, endpoint, or other system). In some embodiments, prediction data 270 includes hashes or signatures for input strings, such as input strings analyzed by system 200, to determine whether such input strings are malicious, or includes historical data sets in which such input strings were previously evaluated as malicious, such as by a third party. Prediction data 270 may include a mapping of hash values ​​to indications of maliciousness (e.g., an indication of whether the corresponding string is malicious or benign, etc.).

[0103] According to various embodiments, memory 220 includes executing application data 275. Executing application data 275 includes data obtained or used in connection with the execution of an application, such as an application that performs a hash function, an application that extracts information from an input string, an application that extracts information from a file, etc. In embodiments, the applications include one or more applications that perform one or more of: receiving and / or executing queries or tasks; generating reports and / or configurations of information responsive to the executed queries or tasks; and / or providing information responsive to the queries or tasks to a user. The other applications include any other suitable applications (e.g., index maintenance applications, communications applications, machine learning model applications, applications for detecting suspicious input strings, detecting suspicious files, document creation applications, report creation applications, user interface applications, data analysis applications, anomaly detection applications, user authentication applications, security policy management / update applications, etc.).

[0104] 3 is an illustration of generating a feature vector using an input string, according to various embodiments. Process 300 for generating a feature vector based on (e.g., corresponding to) an input string is one example of generating a feature vector for a given regular expression statement (e.g., "IFS"). Process 300 includes receiving an input string at 302, applying the regular expression statement at 304, obtaining a result of analyzing the input string based on the regular expression statement at 306, and setting (e.g., storing) a value based on the result of analyzing the input string using the regular expression statement at 308. The value is stored in a portion (e.g., a field) of the feature vector.

[0105] In the example shown in Figure 3, the input string corresponds to a URL with command injection. In response to receiving the URL with command injection, the system determines a feature vector based on an analysis of the URL for one or more features based on a predefined set of regular expression statements and one or more features determined based on algorithm-based feature extraction.

[0106] 4 is a diagram illustrating generating a combined feature vector using an input string, according to various embodiments. In various embodiments, a machine learning system is implemented to determine the custom features. The custom features may be determined based on a predefined set of regular expression statements and / or algorithm-based feature extraction.

[0107] In the illustrated example, feature extraction related to detecting exploits includes a plurality of features, such as a subset of features extracted based on a predetermined set of regular expression statements and a subset of features extracted based on algorithm-based feature extraction. For example, the plurality of features includes a feature for an input string first characteristic 410, a feature for an input string second characteristic 412, a feature for an input string third characteristic 414, a feature for an input string fourth characteristic 416, and a feature for an input string fifth characteristic 418. Various other features may be implemented. The plurality of features (e.g., features 410-418) may be determined based on performing malicious feature extraction. The malicious feature extraction may be performed on sample exploit traffic (e.g., exploit traffic generated by an exploit traffic generation tool).

[0108] In response to receiving an input string (e.g., an input string to be analyzed), the system analyzes the input string for various characteristics. In some embodiments, the system obtains one or more feature vectors for the input string. As one example, the system obtains one or more feature vectors to characterize the input string. In the example shown in FIG. 4, the system populates feature vector 422 corresponding to features of an input string first characteristic, feature vector 424 corresponding to features of an input string second characteristic, feature vector 426 corresponding to features of an input string third characteristic, feature vector 428 corresponding to features of an input string fourth characteristic, and feature vector 430 corresponding to features of an input string fifth characteristic.

[0109] In response to obtaining one or more feature vectors, the system can generate combined feature vector 432. In some embodiments, the system determines combined feature vector 432 by concatenating a set of feature vectors (e.g., feature vectors 422-430) for a predefined set of regular expression statements and / or for properties or relationships determined based on algorithm-based feature extraction. In some embodiments, the system concatenates the set of feature vectors according to a predefined process (e.g., a predefined order, etc.).

[0110] The feature vector can be used as input to a prediction function (e.g., a linear prediction function) to obtain a binary classification. A feature vector is an n-dimensional vector of numerical features that represent an object. Machine learning processes typically use the numerical representation of the object to process and / or perform statistical analysis.

[0111] In response to obtaining the combined feature vector 432, the system uses the combined feature vector 432 as an input to a classifier 434 (e.g., a machine learning classifier). The system uses the output of the classifier 434 as a prediction or decision of whether the corresponding input string is malicious or not.

[0112] 5A is a chart illustrating a feature space for features used in connection with classifying an input string, according to various embodiments. In the example shown, chart 500 illustrates the number of features and the percentage of exploits in which each feature is manifested.

[0113] The system performs malicious feature extraction on the sample exploit traffic to obtain a set of features. In some embodiments, the system determines the set of features based on a predetermined set of regular expression statements and / or algorithm-based feature extraction. The system may determine to use a subset of the set of features obtained based on the set of regular expression statements and algorithm-based feature extraction for the model. The subset of the set of features is used to build a classifier (e.g., to train a model using a machine learning process). For example, the system selects features between two thresholds (e.g., a maximum percentage threshold and a minimum percentage threshold) regarding the percentage of exploits in which each feature is manifested. The subset of features used to build a classifier (e.g., a model) is referred to as a considered feature space. The feature space may be bounded by a maximum percentage threshold to limit the false positive rate for the resulting model. For example, in the example shown in FIG. 5B, the “HTTP” feature may be used to train the model, but using the “HTTP” feature is likely to increase the detection positive rate of an incorrect model.

[0114] In connection with determining whether a particular input string is malicious, the system generates a feature vector that characterizes the input string with respect to features in a feature space (e.g., a subset of the set of features used to build the classifier).

[0115] 5B is a chart illustrating detection of malicious input strings according to various embodiments. In the illustrated example, chart 550 illustrates the detection of exploits using an XGBoost classifier (e.g., a classifier model) according to various embodiments, a neural network classifier according to various embodiments, or an intrusion prevention system (IPS) according to related art.

[0116] As shown, the XGBoost classifier detected at least 95% (e.g., 96.0%) of the exploits, the neural network classifier detected at least 90% (e.g., 93.4%) of the exploits, and the IPS detected approximately 72% of the exploits.

[0117] In some embodiments, a system for detecting exploits (e.g., determining whether an input string is malicious) implements one or more of an XGBoost classifier, a neural network classifier, or an IPS classifier, hi some embodiments, the system implements all of an XGBoost classifier, a neural network classifier, and an IPS classifier.

[0118] FIG. 6 is a flowchart of a method for determining whether an input string is malicious, according to various embodiments. In some embodiments, process 600 is implemented at least in part by system 100 of FIG. 1 and / or system 200 of FIG. 2. In some implementations, process 600 may be implemented by one or more servers, such as those associated with providing services to a network (e.g., a security entity and / or a network endpoint such as a client device). In some implementations, process 600 may be implemented by a security entity (e.g., a firewall), such as those associated with enforcing security policies regarding input strings or files communicated across or within / outside a network. In some embodiments, process 600 may be implemented by a client device, such as a laptop, smartphone, personal computer, etc., such as in connection with executing or opening a file, such as an email attachment, or executing a command injection string.

[0119] At 610, a sample SQL or command injection string is received. In some embodiments, the system receives the sample from a security entity, endpoint, or other system in connection with a request for the system to evaluate whether the input string is malicious. The system may receive the input string in response to a determination that the input string (e.g., a hash or other signature or identifier of the input string) is not included in a blacklist or whitelist of input strings previously evaluated for maliciousness.

[0120] The SQL or command injection string may be received in traffic corresponding to the database system, such as a user interface for accessing the database or other interface through which data contained in the database is obtained.

[0121] At 620, the sample SQL or command injection string is analyzed using a machine learning model. As one example, the machine learning model is a classifier / model that is trained using a machine learning process. In some embodiments, the model is trained based on the XGBoost framework.

[0122] In some embodiments, analyzing a sample SQL or command injection string using a machine learning model includes generating one or more feature vectors for the sample and applying the model to classify the sample based at least in part on the one or more feature vectors.

[0123] A determination of whether the sample is malicious is performed at 630. In some embodiments, the system determines whether the sample is malicious based at least in part on the results of an analysis of the sample SQL or command injection string using a machine learning model.

[0124] The model may provide an indication (e.g., a prediction) of whether the sample is malicious or not, or a likelihood of whether the sample is malicious or not. In response to receiving the likelihood of whether the sample is malicious or not, the system may determine whether the sample is malicious or not based at least in part on one or more thresholds. For example, the system considers the sample to be malicious if the likelihood of the sample being malicious exceeds a predefined first likelihood threshold. As another example, the system considers the sample to be non-malicious (e.g., benign) if the likelihood of the sample being malicious is below one or more of a predefined first likelihood threshold and a predefined second likelihood threshold. In some embodiments, the system considers the sample to be non-malicious if the likelihood of the sample being malicious is below a predefined first likelihood threshold. In some embodiments, the system considers the sample to be non-malicious if the likelihood of the sample being malicious is below a predefined second likelihood threshold, where the predefined second likelihood threshold is lower than the predefined first likelihood threshold.

[0125] In some embodiments, if the likelihood that the sample is malicious is between a first predefined likelihood threshold and a second predefined likelihood threshold, the system considers the analysis of the sample to be inconclusive. For example, the system forwards the sample (or information corresponding to the sample) to another system or another classifier. As one example, if the analysis of the sample using an XGBoost model is inconclusive, the system analyzes the sample using a neural network model and / or IPS analysis.

[0126] The predefined likelihood threshold can be configured to adjust the sensitivity of the classifier.

[0127] In response to determining that the sample is malicious at 630, process 600 proceeds to 640, where a malicious result is provided. In some embodiments, the system provides an indication that the sample corresponds to a malicious input string to an endpoint, security entity, or other system that provided the sample or requested that the system evaluate the maliciousness of the sample. For example, the system updates a blacklist or other mapping of input strings to malicious input strings to include the sample (e.g., a unique identifier associated with the sample, such as a hash, signature, etc.).

[0128] In response to determining that the sample is not malicious at 630, process 600 proceeds to 650. In some embodiments, in response to determining that the sample is not malicious at 630, the system provides an indication that the sample is not malicious (e.g., the sample corresponds to benign traffic), such as to the endpoint, security entity, or other system that provided the sample.

[0129] At 650, a determination is made as to whether process 600 is complete. In some embodiments, process 600 is determined to be complete in response to a determination that no further samples should be analyzed (e.g., no further predictions of input strings are required), an administrator indicates that process 600 should be paused or stopped, etc. In response to a determination that process 600 is complete, process 600 terminates. In response to a determination that process 600 is not complete, process 600 returns to 610.

[0130] FIG. 7 is a flowchart of a method for determining whether an input string is malicious, according to various embodiments. In some embodiments, process 700 is implemented at least in part by system 100 of FIG. 1 and / or system 200 of FIG. 2. In some implementations, process 700 may be implemented by one or more servers, such as those associated with providing services to a network (e.g., security entities and / or network endpoints, such as client devices). In some implementations, process 700 may be implemented by a security entity (e.g., a firewall), such as those associated with enforcing security policies regarding input strings or files communicated across or within / outside a network. In some embodiments, process 700 may be implemented by a client device, such as a laptop, smartphone, or personal computer, such as in connection with executing or opening an input string or file, such as an email attachment.

[0131] At 710, an input string is obtained. In some embodiments, the system receives a sample (e.g., an input string) from a security entity, endpoint, or other system in connection with a request to the system to evaluate whether the input string is malicious. The system may receive the input string in response to a determination that the input string is not included in a blacklist or whitelist of input strings previously evaluated for maliciousness.

[0132] At 720, one or more feature vectors are determined for the input string.

[0133] At 730, a model is obtained. In some embodiments, the model is a machine learning model (e.g., a model trained using a machine learning process). Obtaining the model may include querying the model, such as querying the model using a feature vector (e.g., a combined feature vector).

[0134] The input string is analyzed using the model at 740. Analyzing the input string using the machine learning model includes using a feature vector of the input string to determine whether the feature vector indicates a malicious input string.

[0135] A determination of whether the input string is malicious is performed at 750. In some embodiments, the system determines whether the sample is malicious based at least in part on the results of analyzing the sample SQL or command injection string using a machine learning model.

[0136] The model may provide an indication (e.g., a prediction) of whether the sample is malicious or not, or a likelihood of whether the sample is malicious or not. In response to receiving the likelihood of whether the sample is malicious or not, the system may determine whether the sample is malicious or not based at least in part on one or more thresholds. For example, the system considers the sample to be malicious if the likelihood of the sample being malicious exceeds a predefined first likelihood threshold. As another example, the system considers the sample to be non-malicious (e.g., benign) if the likelihood of the sample being malicious is below one or more of a predefined first likelihood threshold and a predefined second likelihood threshold. In some embodiments, the system considers the sample to be non-malicious if the likelihood of the sample being malicious is below a predefined first likelihood threshold. In some embodiments, the system considers the sample to be non-malicious if the likelihood of the sample being malicious is below a predefined second likelihood threshold, where the predefined second likelihood threshold is lower than the predefined first likelihood threshold.

[0137] In some embodiments, if the likelihood that the sample is malicious is between a first predefined likelihood threshold and a second predefined likelihood threshold, the system considers the analysis of the sample to be inconclusive. For example, the system forwards the sample (or information corresponding to the sample) to another system or another classifier. As one example, if analysis of the sample using an XGBoost model is inconclusive, the system analyzes the sample using a neural network model and / or IPS analysis.

[0138] The predefined likelihood threshold can be configured to adjust the sensitivity of the classifier.

[0139] In response to determining that the input string is malicious at 750, process 700 proceeds to 760, where a maliciousness result is provided. In some embodiments, the system provides an indication that the input string corresponds to a malicious input string, such as to an endpoint, security entity, or other system that provided the input string or requested that the system evaluate the maliciousness of the input string. For example, the system updates a blacklist or other mapping of input strings to malicious input strings to include the input string (e.g., a unique identifier associated with the sample, such as a hash, signature, etc.).

[0140] In response to determining that the input string is not malicious at 750, process 700 proceeds to 770. In some embodiments, in response to determining that the input string is not malicious at 750, the system provides an indication that the input string is not malicious (e.g., the sample corresponds to benign traffic), such as to an endpoint, security entity, or other system that provided the input string.

[0141] At 770, a determination is made as to whether process 700 is complete. In some embodiments, process 700 is determined to be complete in response to a determination that no further input strings should be analyzed (e.g., no further predictions are required for the input string), an administrator indicates that process 700 should be paused or stopped, etc. In response to a determination that process 700 is complete, process 700 terminates. In response to a determination that process 700 is not complete, process 700 returns to 710.

[0142] 8 is a flowchart of a method for obtaining feature vectors for training a machine learning model, according to various embodiments. In some embodiments, process 800 is implemented at least in part by system 100 of FIG. 1 and / or system 200 of FIG. 2. In some implementations, process 800 may be implemented by one or more servers, such as those associated with providing services to a network (e.g., security entities and / or network endpoints such as client devices). In some implementations, process 800 may be implemented by a security entity (e.g., a firewall), such as those associated with enforcing security policies regarding input strings or files communicated across or within / outside a network.

[0143] At 810, training data is obtained. In some embodiments, obtaining the training data includes invoking process 900 of FIG. 9 . In some embodiments, the training data used in connection with determining features (e.g., to perform malicious feature extraction) is different from the training data used to train the model using the determined features. For example, the training data used to train the model may comprise a subset of sample exploit traffic and a subset of sample benign traffic. And, the training data used to determine features (e.g., exploit features) may exclude (e.g., not include) sample benign traffic. In some embodiments, the features used to train the model are determined based on the sample exploit traffic (e.g., sample benign traffic is not used for malicious feature extraction, etc.).

[0144] The sample exploit traffic and / or malicious traffic may be generated using a traffic generation tool. As one example, the traffic generation tool is a known tool that generates malicious exploits. An exemplary traffic generation tool that generates exploit traffic is an open-source penetration testing tool such as Commix, developed by the Commix Project, or SQLmap, developed by the SQLmap project and available at https: / / SQLmap.org. As another example, the traffic generation tool may be an exploit emulation module, such as the Threat Emulation Module, developed by Picus Security, Inc. The exploit traffic may include a malicious payload, such as a malicious SQL statement or other structured statement.

[0145] At 820, malicious feature extraction is performed. In some embodiments, the system performs malicious feature extraction in connection with generating (e.g., training) a model for detecting exploits. Malicious feature extraction may include one or more of: (i) using predefined regular expression statements to obtain specific features from SQL and command injection strings; and (ii) using algorithm-based feature extraction to filter described features from a set of raw input data.

[0146] In some embodiments, the predefined regular expression statements may be configured by an administrator or other user of the system. For example, the predefined regular expression statements may be manually defined and stored in the system (e.g., stored in a security policy or in a policy for training a model). As one example, at least a subset of the regular expression statements may be expert-defined. The regular expression statements may be statements that capture predetermined context patterns. For example, malicious structured statements are often part of a code language. According to various embodiments, feature extraction using regular expression statements identifies specific syntax contained in an input string (e.g., a command or SQL injection string).

[0147] In some embodiments, the algorithm-based feature extraction uses TF-IDF to extract a set of features. In some embodiments, a first subset of features obtained during malicious feature extraction is obtained using expert-generated regular expression statements, and a second subset of features obtained during malicious feature extraction is obtained using the algorithm-based feature extraction.

[0148] In some embodiments, the set of exploit features is determined based at least in part on one or more characteristics of the exploit traffic. As one example, the set of exploit features is determined based at least in part on one or more characteristics of the exploit traffic relative to one or more characteristics of benign traffic.

[0149] At 830, a set of exploit features is determined. The set of exploit features may be determined based on the results of the malicious feature extraction. For example, the system determines a subset of the set of features to be used to build a classifier (e.g., train a model using a machine learning process). The system may select features between two thresholds for exploit percentage (e.g., a maximum percentage threshold and a minimum percentage threshold), each of which defines a feature.

[0150] At 840, a set of feature vectors is generated for training the machine learning model. In some embodiments, the set of feature vectors used to train the model is obtained based at least in part on training data. As one example, the training data used to determine the set of feature vectors includes sample exploit traffic (e.g., sample malicious traffic) and sample benign traffic.

[0151] At 850, a determination is made as to whether process 800 is complete. In some embodiments, process 800 is determined to be complete in response to a determination that no further models should be determined / trained (e.g., no further classification models should be created), an administrator indicates that process 800 should be paused or stopped, etc. In response to a determination that process 800 is complete, process 800 terminates. In response to a determination that process 800 is not complete, process 800 returns to 810.

[0152] 9 is a flowchart of a method for obtaining training data, according to various embodiments. In some embodiments, process 900 is implemented at least in part by system 100 of FIG. 1 and / or system 200 of FIG. 2. In some implementations, process 900 may be implemented by one or more servers, such as those associated with providing services to a network (e.g., security entities and / or network endpoints such as client devices). In some implementations, process 900 may be implemented by a security entity (e.g., a firewall), such as those associated with enforcing security policies regarding input strings or files communicated across or within / outside a network.

[0153] Benign traffic is obtained at 910. The system may use a traffic generation tool to obtain the benign traffic.

[0154] At 920, malicious traffic is received. The system may use a traffic generation tool to obtain malicious traffic (e.g., exploit traffic). As one example, the traffic generation tool is a known tool that generates malicious exploits. An exemplary traffic generation tool for generating malicious traffic is an open-source penetration testing tool such as Commix, developed by the Commix Project, or SQLmap, developed by the SQLmap project and available at https: / / SQLmap.org. As another example, the traffic generation tool may be an exploit emulation module, such as the Threat Emulation Module, developed by Picus Security, Inc. The malicious traffic may include a malicious payload, such as a malicious SQL statement or other structured statement.

[0155] At 930, training data is generated based at least in part on the benign and malicious traffic. In some embodiments, the system combines or otherwise aggregates the benign and malicious traffic.

[0156] At 940, the training data is stored. The system can store the training data for use in connection with training the model. For example, the system determines a set of feature vectors that characterize the training data, and the set of feature vectors is used to train the model.

[0157] At 950, a determination is made as to whether process 900 is complete. In some embodiments, process 900 is determined to be complete in response to a determination that no further models should be determined / trained (e.g., no further classification models should be created), an administrator indicates that process 900 should be paused or stopped, etc. In response to a determination that process 900 is complete, process 900 terminates. In response to a determination that process 900 is not complete, process 900 returns to 910.

[0158] 10 is a flowchart of a method for deriving a model for classifying malicious input strings, according to various embodiments. In some embodiments, process 1000 is implemented at least in part by system 100 of FIG. 1 and / or system 200 of FIG. 2.

[0159] At 1010, information about the historical set of malicious samples is obtained. In some embodiments, the system uses a third-party service (e.g., VirusTotal) to obtain information about the historical set of malicious samples. TM) to obtain information about a historical set of malicious samples. In some embodiments, the system obtains information about a historical set of malicious samples based at least in part on executing samples known to be malicious and performing dynamic analysis of the malicious samples (e.g., performing repeated snapshots of the sandbox state or memory structures of the sandbox, etc.).

[0160] At 1020, information about the set of historical benign samples is obtained. In some embodiments, the system uses a third-party service (e.g., VirusTotal) to obtain the historical benign sample set. TM ) to obtain information about the set of historical benign samples. In some embodiments, the system obtains information about the set of historical benign samples based at least in part on running samples that are known to be benign and performing dynamic analysis of the samples (e.g., performing repeated snapshots of the sandbox state or memory structures of the sandbox, etc.).

[0161] At 1030, one or more relationships between characteristics of the sample and the maliciousness of the sample are determined. In some embodiments, the system determines features related to whether the input string is malicious or the likelihood that the input string is malicious. The features may be determined based on a malicious feature extraction process performed on the sample exploit traffic. In some embodiments, the features may be determined with respect to a set of regular expression statements (e.g., predetermined regular expression statements) and / or with respect to the use of algorithm-based feature extraction (e.g., TF-IDF, etc.).

[0162] At 1040, a model is trained to determine whether an input string is malicious. In some embodiments, the model is a machine learning model trained using a machine learning process. Exemplary machine learning processes that may be implemented in connection with training the model include random forests, linear regression, support vector machines, naive Bayes, logistic regression, K-nearest neighbors, decision trees, gradient-boosted decision trees, K-means clustering, hierarchical clustering, density-based spatial clustering of applications with noise (DBSCAN) clustering, principal component analysis, etc. The input to the classifier (e.g., an XGBoost machine learning classifier model) is a combined feature vector or set of feature vectors, and based on the combined feature vector or set of feature vectors, the classifier model determines whether a corresponding input string is malicious or the likelihood that the input string is malicious.

[0163] At 1050, the model is deployed. In some embodiments, deploying the model includes storing the model in a model dataset for use in connection with analyzing input strings to determine whether the input strings are malicious. Deploying the model may include providing the model (or a location from which the model can be invoked) to a malicious input string detector, such as malicious input string detector 170 of system 100 of FIG. 1 or to system 200 of FIG. 2.

[0164] At 1060, a determination is made as to whether process 1000 is complete. In some embodiments, process 1000 is determined to be complete in response to a determination that no further models should be determined / trained (e.g., no further classification models should be created), an administrator indicates that process 1000 should be paused or stopped, etc. In response to a determination that process 1000 is complete, process 1000 terminates. In response to a determination that process 1000 is not complete, process 1000 returns to 1010.

[0165] FIG. 11 is a flowchart of a method for detecting malicious input strings, according to various embodiments. In some embodiments, process 1100 is implemented at least in part by system 100 of FIG. 1 and / or system 200 of FIG. 2. In some implementations, process 1100 may be implemented by one or more servers, such as those associated with providing services to a network (e.g., security entities and / or network endpoints, such as client devices). In some implementations, process 1100 may be implemented by a security entity (e.g., a firewall), such as those associated with enforcing security policies regarding input strings or files communicated across or within / outside a network. In some embodiments, process 1100 may be implemented by a client device, such as a laptop, smartphone, or personal computer, such as in connection with executing or opening an input string or file, such as an email attachment.

[0166] At 1110, one or more characteristics associated with a sample input string are obtained. The system can receive the input string (e.g., from an endpoint or security entity, or otherwise via an interface, such as an interface for a database system), and the system characterizes the input string, such as by determining whether the input string exhibits one or more characteristics associated with features corresponding to the model.

[0167] At 1120, one or more feature vectors are determined based at least in part on the one or more characteristics.

[0168] At 1130, the one or more feature vectors are provided to a classifier. In some embodiments, the classifier is a machine learning classifier trained using a machine learning process. For example, the classifier corresponds to an XGBoost machine learning classifier model. The system uses a model, such as a machine learning model trained by a machine learning process, in connection with determining whether an input string is malicious or the likelihood that the input string is malicious. For example, the system uses an XGBoost machine learning classifier model to analyze one or more feature vectors (e.g., a combined feature vector) to determine whether the input string is malicious.

[0169] At 1140, a determination is made as to whether the classification of the one or more feature vectors indicates that the input string corresponds to a malicious input string. In some embodiments, if the results of analyzing the feature vectors (e.g., the combined feature vector) using the classifier are less than a predefined threshold (e.g., a predetermined maliciousness threshold), the system deems (e.g., determines) that the input string is not malicious (e.g., the input string is benign). For example, if the results from analyzing the feature vectors indicate a likelihood that the input string is malicious or not, the predefined threshold may correspond to a likelihood threshold. As another example, if the results from analyzing the feature vectors indicate a degree of similarity of the input string to a malicious input string, the predefined threshold may correspond to a likelihood threshold. In some embodiments, if the results of analyzing the feature vectors (e.g., the combined feature vector) using the classifier are greater than (or equal to or greater than) a predefined threshold, the system deems (e.g., determines) that the input string is malicious (e.g., the input string is an exploit).

[0170] In response to determining at 1140 that the classification of one or more feature vectors indicates that the sample corresponds to a malicious input string, process 1100 proceeds to 1150, where the sample input string is determined to be malicious.

[0171] In response to determining at 1140 that the classification of the one or more feature vectors indicates that the sample input string does not correspond to a malicious string, process 1100 proceeds to 1160, where the sample input string is determined to be non-malicious. In some embodiments, the system determines that the sample input string is benign in response to determining that the classifier indicates that the sample input string is non-malicious or determining that the likelihood that the sample input string is malicious is below a predefined maliciousness threshold.

[0172] At 1170, a maliciousness result is provided. In some embodiments, the system provides an indication of whether the sample input string corresponds to a malicious input string. For example, the system provides an update to a blacklist or other mapping of input strings to malicious input strings to include the sample input string (e.g., a unique identifier associated with the sample, such as a hash, signature, etc.). The system may further provide the corresponding updated blacklist or other mapping to an endpoint, security entity, etc. For example, the system pushes the update to the blacklist or other mapping of input strings to malicious input strings to other devices that enforce one or more security policies on traffic or files or subscribe to the system's services.

[0173] At 1180, a determination is made as to whether process 1100 is complete. In some embodiments, process 1100 is determined to be complete in response to a determination that no further input strings should be analyzed (e.g., no further predictions are required for the input strings), an administrator indicates that process 1100 should be paused or stopped, etc. In response to a determination that process 1100 is complete, process 1100 terminates. In response to a determination that process 1100 is not complete, process 700 returns to 1110.

[0174] 12 is a flowchart of a method for detecting malicious input strings, according to various embodiments. In some embodiments, process 1200 is implemented by an endpoint or security entity, such as in connection with enforcing one or more security policies. In some embodiments, the process 1200 may be performed by a client device, such as a laptop, smartphone, or personal computer, such as in connection with executing or opening a file, such as an input string or an email attachment.

[0175] Traffic is received at 1210. The system may acquire traffic in connection with routing traffic in / across a network, or mediating traffic entering / exiting a network, such as a firewall, or monitoring email or instant messaging traffic, etc.

[0176] At 1220, an input string is obtained from the traffic. The system may obtain the traffic in connection with routing traffic in / across a network or mediating traffic entering / exiting a network such as a firewall, monitoring email or instant messaging traffic, or monitoring login attempts, authentication requests, or other attempts to access a system such as a database system, etc. In some embodiments, the system obtains the input string from the received traffic.

[0177] At 1230, one or more feature vectors are obtained for the input string. The system can provide the input string to a malicious input string detector, which determines whether the input string is malicious (e.g., provides a prediction of whether the input string is malicious).

[0178] At 1240, the one or more feature vectors are provided to a classifier. In some embodiments, the system performs dynamic analysis of the input string. For example, the system queries the classifier based on the one or more feature vectors. The classifier can be a model, such as a machine learning model, determined based on performing a machine learning process. For example, the classifier is an XGBoost model.

[0179] A determination of whether the input string is malicious is performed at 1250. In some embodiments, the classifier provides a prediction of whether the input string is malicious based on an analysis of one or more feature vectors.

[0180] The model may provide an indication (e.g., a prediction) of whether the sample is malicious or not, or a likelihood of whether the sample is malicious or not. In response to receiving the likelihood of whether the sample is malicious or not, the system may determine whether the sample is malicious or not based at least in part on one or more thresholds. For example, the system considers the sample to be malicious if the likelihood of the sample being malicious exceeds a predefined first likelihood threshold. As another example, the system considers the sample to be non-malicious (e.g., benign) if the likelihood of the sample being malicious is below one or more of a predefined first likelihood threshold and a predefined second likelihood threshold. In some embodiments, the system considers the sample to be non-malicious if the likelihood of the sample being malicious is below a predefined first likelihood threshold. In some embodiments, the system considers the sample to be non-malicious if the likelihood of the sample being malicious is below a predefined second likelihood threshold, where the predefined second likelihood threshold is lower than the predefined first likelihood threshold.

[0181] In some embodiments, if the likelihood that the sample is malicious is between a first predefined likelihood threshold and a second predefined likelihood threshold, the system considers the analysis of the sample to be inconclusive. For example, the system forwards the sample (or information corresponding to the sample) to another system or another classifier. As one example, if analysis of the sample using an XGBoost model is inconclusive, the system analyzes the sample using a neural network model and / or IPS analysis.

[0182] The predefined likelihood threshold can be configured to adjust the sensitivity of the classifier.

[0183] In response to determining at 1250 that the traffic contains a malicious input string, process 1200 proceeds to 1260, where the input string is treated as a malicious input string (e.g., malicious traffic / information). The system can treat the malicious traffic / information based at least in part on one or more policies, such as one or more security policies.

[0184] According to various embodiments, handling malicious input string traffic / information may include performing active measures. Active measures may be performed in accordance with (e.g., based at least in part on) one or more security policies. As one example, one or more security policies may be pre-configured by a network administrator, a customer (e.g., an organization / company) for a service that provides detection of malicious input strings or files, etc. Exemplary active measures that may be performed include quarantining the input string (e.g., quarantining the input string), deleting the input string, alerting a user that a malicious input string has been detected, providing a prompt to the user when the device attempts to open or execute the input string, blocking transmission of the input string, updating a blacklist of malicious input strings (e.g., mapping a hash of the input string to an indication that the input string is malicious), etc.

[0185] In response to determining at 1250 that the traffic does not contain a malicious input string, process 1200 proceeds to 1270, where the input string is treated as a non-malicious input string (e.g., non-malicious traffic / information).

[0186] At 1280, a determination is made as to whether process 1200 is complete. In some embodiments, process 1200 is determined to be complete in response to a determination that no further models should be determined / trained (e.g., no further classification models should be created), an administrator indicates that process 1200 should be paused or stopped, etc. In response to a determination that process 1200 is complete, process 1200 terminates. In response to a determination that process 1200 is not complete, process 1200 returns to 1210.

[0187] Various examples of the embodiments described herein are described with reference to flowcharts. Although the examples may include some steps performed in a particular order, according to various embodiments, various steps may be performed in different orders and / or various steps may be combined into a single step or in parallel.

[0188] Although the above 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 limiting.

Claims

1. 1. A system including one or more processors and a memory, The one or more processors: Takes the SQL or command injection string, determining whether the SQL or command injection string is malicious based at least in part on a machine learning model; It is structured as follows: The memory includes: coupled to the one or more processors; configured to provide instructions to the one or more processors; system.

2. the machine learning model is trained using a set of one or more feature vectors; The system of claim 1 .

3. the one or more processors are further configured to obtain the machine learning model. The system of claim 1 .

4. The one or more processors further sending an indication to a security entity that the SQL or command injection string is malicious; It is configured as follows: The system of claim 1 .

5. The one or more processors further implementing one or more security policies based on a determination of whether the SQL or command injection string is malicious; It is configured as follows: The system of claim 1 .

6. The machine learning model is a tree-based model. The system of claim 1 .

7. The tree-based model is trained using the XGBoost machine learning process. The system of claim 6.

8. The machine learning model is a neural network-based model. The system of claim 1 .

9. The machine learning model is a support vector machine-based model. The system of claim 1 .

10. The machine learning model is Obtaining sample exploit traffic; and obtaining a set of exploit features based at least in part on the sample exploit traffic; generated based at least in part on The system of claim 1 .

11. The machine learning model is further generated based at least in part on obtaining sample benign traffic; and the set of exploit features is further obtained based at least in part on the sample benign traffic. The system of claim 10.

12. obtaining the sample exploit traffic; generating said sample exploit traffic using one or more exploit tools; The system of claim 10, comprising:

13. the sample exploit traffic is based at least in part on historical exploit traffic; The system of claim 10.

14. the SQL or command injection string is obtained based at least in part on input to a user interface; The system of claim 1 .

15. The one or more processors further In response to determining that the SQL or command injection string is malicious, updating a blacklist of SQL or command injection strings that are deemed malicious. It is structured as follows: the blacklist of SQL or command injection strings is updated to include identifiers corresponding to the captured SQL or command injection strings. The system of claim 1 .

16. 1. A method comprising: obtaining, by one or more processors, an SQL or command injection string; determining whether the SQL or command injection string is malicious based at least in part on a machine learning model; A method comprising:

17. A computer program stored on a non-transitory computer-readable storage medium, the computer program comprising computer instructions, which when executed: obtaining, by one or more processors, an SQL or command injection string; determining whether the SQL or command injection string is malicious based at least in part on a machine learning model; A computer program that implements the above.

18. 1. A system including one or more processors and a memory, The one or more processors: Perform malicious feature extraction, performing exploit feature extraction based at least in part on term frequency-inverse document frequency (TF-IDF); and generating a set of feature vectors for training a machine learning model on detecting SQL and / or command injection cyber attacks; It is structured as follows: The memory includes: coupled to the one or more processors; and configured to provide instructions to the one or more processors; system.

19. The one or more processors further Get sample exploit traffic, Obtaining sample benign traffic; and obtaining a set of exploit features based at least in part on the sample exploit traffic and the sample benign traffic; 20. The system of claim 18, configured to:

20. one or more of the sample exploit traffic and the sample benign traffic are generated using a traffic generation tool; 20. The system of claim 19.

Images