Inline detection of hardcoded credential attacks

Abstract

The hardcoded credential attack detection and prevention system disclosed herein distinguishes between legitimate and malicious use to prevent attacks using hardcoded credentials without interfering with legitimate use that still relies on hardcoded credentials. The system collects publicly available hardcoded credentials and creates network traffic-based signatures to detect login attempts corresponding to the publicly available hardcoded credentials. The system then uses the created “login signatures” to detect login attempts corresponding to the hardcoded credentials. Detection using login signatures occurs inline at individual network devices with network traffic visibility, while the system also acquires relevant network traffic from other network devices to analyze login behavior at a wider scale. This more informative analysis may involve profiling, reputation scoring, and / or behavioral analysis using aggregated network traffic to detect malicious use of hardcoded credentials that would go undetected or result in false positives.

Description

Technical Field

[0001] The present disclosure generally relates to the transmission of digital information (e.g., CPC (Cooperative Patent Classification) class H04L), and security configurations (e.g., CPC subclass G06F 21 / 00) for protecting computers, their components, programs or data from unauthorized activities.

Background Art

[0002] Hardcoded / embedded credentials (also called default credentials) are pairs of user IDs / passwords that are incorporated into a product or pre-installed, such as an operating system or a database. Default credentials pose cybersecurity risks, but they have multiple uses. Default credentials can be used for customer support, initial software installation, initial device setup, and upgrades. A user may use the default credentials to reset a device and access the reset device.

Brief Description of the Drawings

[0003] Embodiments of the present disclosure can be better understood by referring to the accompanying drawings. [Figure 1] FIG. 1 is an exemplary diagram of a cyberattack detection and prevention system that distinguishes between legitimate and malicious uses of hardcoded credentials. [Figure 2] FIG. 2 is an exemplary diagram of a cyberattack detection and prevention system that distinguishes between legitimate and malicious uses of hardcoded credentials. [Figure 3]Figure 3 is a flowchart illustrating an exemplary operation for collecting network traffic samples to create a login signature. [Figure 4] Figure 4 is a flowchart illustrating an example operation for inline detection of login signatures. [Figure 5] Figure 5 is a flowchart illustrating an example of an operation to determine whether a login request is legitimate or an exploit of a hardcoded credential logon vulnerability. [Figure 6] Figure 6 is a flowchart illustrating an exemplary operation for comparing the profile of a login traffic sample with that of a login attack profile. [Figure 7] Figure 7 is a flowchart illustrating an exemplary operation for analyzing login behavior across network devices. [Figure 8] Figure 8 shows an exemplary computer system with login attack detection and prevention components. [Modes for carrying out the invention]

[0004] The following description includes exemplary systems, methods, techniques, and program flows to aid in understanding this disclosure and does not limit the scope of the claims. Well-known instruction instances, protocols, structures, and techniques are not shown in detail for brevity. This description uses “login traffic” to refer to network traffic samples or data traffic samples, including login requests or login attempts.

[0005] overview

[0006] Hardcoded credentials are often widely exposed (e.g., on message boards or online communities), increasing the existing risk of exploits related to these credentials. This has already occurred with Internet of Things (IoT) devices (e.g., the Mirai botnet) and operating systems (e.g., residential modems and automotive GPS tracking devices). Nevertheless, hardcoded credentials continue to be used for legitimate purposes.

[0007] As disclosed herein, a system for detecting and preventing hardcoded credential attacks distinguishes between legitimate and malicious use to prevent attacks using hardcoded credentials without interfering with legitimate use that still relies on hardcoded credentials. The system collects publicly available hardcoded credentials and creates network traffic-based signatures to detect login attempts corresponding to the publicly available hardcoded credentials. The system then uses the created “login signatures” to detect login attempts corresponding to the hardcoded credentials. Detection using login signatures occurs inline at individual network devices with network traffic visibility, while the system also obtains relevant network traffic from other network devices to analyze login behavior at a wider scale. This more informative analysis may include profiling, reputation scoring, and / or behavioral analysis using aggregated network traffic to detect malicious use of hardcoded credentials that would otherwise go undetected or result in false positives.

[0008] Example explanation

[0009] Figures 1 and 2 are exemplary diagrams relating to a cyberattack detection and prevention system that distinguishes between legitimate and malicious use of hardcoded credentials. Figure 1 is an exemplary diagram relating to a system that collects login traffic samples using hardcoded credentials for signature creation. Figure 2 is an exemplary diagram relating to a system that deploys the created signatures, scans traffic to detect login attempts of interest, and performs analysis based on a multi-device and / or multi-network view of the relevant login traffic. In both Figures 1 and 2, network devices 106A-106C are located on networks 111A-111C, respectively. The login attack detector 103 and login signature generator 101 are accessible via network 107. As one example, the login attack detector 103 and login signature generator 101 may be provided as cloud-based services. Network 107 also provides access to a repository 105 where the login traffic samples are stored. Network devices 106A-106C can communicate with the login attack detector 103 and the login signature generator 101, for example, as permitted by license or subscription. Software on network devices 106A-106C communicates with the login attack detector 103 and the login signature generator 101 according to a preferred paradigm, such as an application programming interface (API) (e.g., Remote Procedure Call (RPC) API, Simple Object Access Protocol (SOAP) API, Representative State Transfer (REST) ​​API), or a proprietary application layer protocol.

[0010] Each of Figures 1 and 2 is annotated with a series of letters for each stage, each representing one or more operations. Figure 1 shows stage AD, and Figure 2 shows stage AE. Although these stages are ordered in this example, these stages are provided as an example to help understand this disclosure and should not be used to limit the claims. The subject matter that falls within the claims may differ from that exemplified.

[0011] In stage A, the login signature generator 101 obtains publicly available hardcoded credentials 108. In Figure 1, an example of hardcoded credentials 108 is shown as username:password sets, and their corresponding resources / services, nproc:nproc, admin:admin, and admin:password, as well as their respective resource / service indicators, OS_xyz, VendorXRouter, and app2.example. The login signature generator 101 may receive hardcoded credentials according to the publish-subscribe paradigm, notifications, web crawling, etc. The login signature generator 101 obtains hardcoded credentials that lack a login signature for the detection and prevention of login attacks. The login signature generator 101 maintains a list of hardcoded credentials from which login signatures have been created, and filters the retrieved hardcoded credentials as needed to produce those for which no login signatures have been created.

[0012] In stage B, the login signature generator 101 generates and distributes data collection login signatures using hardcoded credentials. To generate data collection login signatures, the login signature generator 101 creates a file or data structure that network devices can use to find matching network traffic when scanning traffic. As one example, the login signature generator 101 creates an Extended Markup Language (XML) file with tags to describe each data collection login signature and constituent component. A data collection login signature is an association between a set of hardcoded credentials (i.e., username and password) and one or more indications of a resource or service accessed using hardcoded credentials (e.g., network or device address, Uniform Resource Identifier (URI) or Uniform Resource Locator (URL), etc.). The creation of data collection login signatures may be manual and / or automated based on a template that organizes and formats the acquired hardcoded credentials and resource / service indicators into data collection login signatures. The login signature generator 101 distributes the generated data collection login signatures 110 to network devices 106A-106C.

[0013] In stage C, network devices 106A-106C scan inbound network traffic for data collection login signature 110. Since the components of the data collection login signature are likely to be in the application layer, the traffic scanning will involve deep packet inspection.

[0014] In stage D, a network device that detects data collection login signatures in network traffic samples captures matching traffic and provides the matching traffic sample to the login signature generator 101. If a login is attempted using hardcoded credentials corresponding to one of the data collection login signatures 110, the matching network traffic sample is communicated to the login signature generator 101. In Figure 1, each of the network devices 106A-106C communicates with one of the matching traffic samples 113A-113C. The matching traffic sample will be a protocol data unit (e.g., a packet, application layer message) corresponding to the detected login request. For example, an encoded login in a Hypertext Transfer Protocol (HTTP) message.

[0015] In stage A of Figure 2, the login signature generator 101 creates login signatures with different matching scopes based on matching network traffic samples from network devices 106A-106C. The first scope of the login signature includes hardcoded credentials, a login marker (e.g., login keyword) that depends on the protocol for accessing the corresponding assertion or resource, and a service / resource indication. However, at least the password among the set of credentials may be obfuscated. Therefore, the login signature generator 101 creates another version or set of login signatures with a broader matching scope, so that each set of hardcoded credentials has at least two login signatures. The second login signature with a broader matching scope includes the login request (e.g., a keyword indicating the submitted username and password) and login signature components for discovering the resource / service to be accessed. A first scoped login signature is a login request with hardcoded credentials and matches with high confidence the login traffic, which is the corresponding service / resource. A second scoped login signature does not contain at least one of the hardcoded credentials and therefore matches with lower confidence the login traffic. Unlike data collection signatures, these login signatures are used to identify login requests for login attack analysis. After creating the login signature 120, the login signature generator 101 distributes the login signature 120 to network devices 106A-106C.

[0016] In stage B, network devices 106A-106C scan network traffic for login signature 120. Similar to the scan for login signature 110, login requests with components of the login signature are most likely to be found in application layer data. Therefore, network devices 106A-106C scan application layer data for login signature 120. Figure 2 shows two login signatures for the hardcoded credentials nproc:nproc related to login signature 120. The first scoped login signature includes the credentials, login markers "os_username" and "os_password", and the Internet Protocol version 4 (IPv4) address of the resource being accessed. The second scoped login signature includes the login markers from the first scoped login signature, additional login markers "POST" and "login.action", and the IPv4 address.

[0017] In stage C, network device 106A detects one of the login signatures 120 while inline scanning network traffic and supplies the matching traffic sample 122A in which the login signature was detected to the login attack detector 103. Since network devices 106A-106C have already scanned for attack prevention and / or for security policy enforcement, scanning for long signatures can be implemented by updating the repository of scan targets that occur per flow / session.

[0018] In stage D, the login attack detector 103 determines whether the detected login is a login attack or a legitimate login. The login attack detector 103 makes this determination using one or more different types of analysis, at least some of which include analysis of login traffic detected on other network devices and / or historical login traffic detected on network device 106A. The different types of analysis include login behavior analysis, reputation scoring, and profiling. Repository 105 hosts network traffic or data about network traffic and can be queried for one or more attributes of matching traffic samples 122A to retrieve network traffic or network traffic data that have common attributes, such as source network address. Using this “global” view of login traffic, the login attack detector 103 analyzes the behavior of the login traffic with respect to login attack heuristics. The login traffic that facilitates the global view is provided by network devices 106A-106C. When a login is detected using the login signature 120, network devices 106B-106C each provide matching traffic samples 122B-122C.

[0019] In stage E, the login attack detector 103 returns a determination of the login attack analysis to the network device 106A. Based on the analysis, the login attack detector 103 indicates either a benign determination (i.e., the detected login is legitimate) or a malicious determination (i.e., the detected login is an exploit related to a hardcoded credential login vulnerability).

[0020] Although shown in separate figures, data collection and login attack analysis can occur simultaneously rather than in separate phases. After an initial set of login signatures is installed, scanning and attack analysis do not depend on data collection and login signature creation. Scanning of traffic for attack analysis can be paused when login signatures are updated in network devices.

[0021] Figure 3 is a flowchart relating to an exemplary operation for collecting network traffic samples to create login signatures. The description of Figure 3 refers to the login signature generator as the execution of the operation for the sake of consistency with Figures 1-2.

[0022] In block 301, the login signature generator obtains the published hard-coded credentials and identifiers of the corresponding service / resource. Obtaining the hard-coded credentials can be started periodically, event-based, and / or manually. The hard-coded credentials can be limited to those corresponding to resources or services of interest to the customer.

[0023] In block 303, the login signature generator begins to iteratively process each set of hard-coded credentials or hard-coded credential pairs to create a data collection login signature for the set of hard-coded credentials. The login signature generator traverses a list of hard-coded credentials that have been obtained and lack a corresponding data collection login signature. In this flowchart, the iterative operations are represented by blocks 305 and 307.

[0024] In block 305, the login signature generator determines the resource or service to be accessed using a set of hardcoded credentials. The service / resource identifier is likely to be extracted from the data accompanying the retrieved hardcoded credentials. The service / resource identifier does not necessarily identify a specific device. For example, hardcoded credentials for a gateway or router from vendor X may be used to access a specific model from vendor X. Thus, the resource identifier may be the vendor name and / or model identifier. Furthermore, the resource / service identifier may not be explicitly indicated using hardcoded credentials. For example, a customer may indicate that they will be using a network device of model 123 from vendor X. This may be indicated in a configuration file or through a user interface associated with the login signature generator. The login signature may search for or subscribe to notices regarding the public disclosure of vendor X's hardcoded credentials. Thus, the resource / service identifier may be indicated in parameters used to build or search for registrations for the relevant hardcoded credentials.

[0025] In block 307, the login signature generator creates data collection login signatures using hardcoded credentials and instructions for the resource or service being accessed. For example, the login signature generator creates an XML file and inserts objects or entries for the data collection login signature. The object / entry includes components for the username, password, and service / resource indicator. The login signature generator can also create entries using components for login markers. The login signature generator can create a file for each data collection login signature, or it can automatically populate (populate) multiple login signature entries / objects into a file.

[0026] In block 309, the login signature generator determines whether there is another hardcoded set of credentials to process. If not, the operation flow proceeds to block 311. If there is another hardcoded set of credentials to process, the operation flow returns to block 303.

[0027] In block 311, the login signature generator distributes data collection login signatures to network devices for inline detection. The login signature generator has established a trust relationship with the receiving network device (e.g., through a licensing or subscription model). Alternatively, the network device can retrieve or request updates to the data collection login signature from the login signature generator.

[0028] The operation flow continues asynchronously to block 313, as shown by the dashed line in Figure 3. In block 313, the login signature generator receives one or more network traffic samples of hardcoded credentials. When a data collection login signature is detected in the login traffic at a network device, the network device may communicate a sample of the login traffic to the login signature generator at each detection, or after a configured number of detections. The network traffic sample, which is the login traffic or login traffic data for a login attempt / request, may be application layer data (e.g., a File Transfer Protocol (FTP) message).

[0029] In block 315, the login signature generator generates a first-scope login signature using a hardcoded set of credentials, resource / service indicators, and login markers from an received network traffic sample. For example, the first-scope login signature specifies a hardcoded set of credentials, a protocol identifier, and a login keyword.

[0030] In block 317, the login signature generator generates a second-scope login signature using the resource / service indicators and login markers from the received network traffic sample. For example, the second-scope login signature specifies the login keyword, URI, and protocol message keyword / tag.

[0031] Figure 4 is a flowchart illustrating an exemplary operation for inline detection of login signatures. For consistency with Figures 1-2, the description of Figure 4 refers to a network device as the execution of the operation. The network device hosts scanning logic and software to adapt or configure the scanning logic to scan for login signatures.

[0032] In block 401, the network device scans application layer data traffic for login requests. A reference to network traffic refers to a collection of data traffic flowing through the network device, which may be in different traffic flows. Scanning performed on the network device can inspect network traffic at different communication layers, such as the application layer and the transport layer. Detection of login requests in network traffic is based on inspection of application layer data, such as FTP or HTTP messages. Scanning occurs per flow (e.g., per connection between endpoints defined by source and destination in the application layer). Different application layer protocols may have common login markers within messages, but the traffic scanner may be configured / programmed to scan the traffic flow for login markers of the protocol determined for the flow. Network traffic scanning continues as long as traffic flows through the network device. If a login request is detected in the login traffic sample, the operation flow proceeds to block 403 (e.g., a thread is created for the called function, resulting in a different process from the scanning process / thread). Otherwise, the network device continues scanning application layer data traffic for login requests.

[0033] In block 403, the network device extracts the first-scope signature component from the login traffic sample and then searches for the first-scope login signature for a match. Configuration information or the first-scope login signature definition specifies the fields or message components of the login traffic sample for the relevant login signature scope. These can be values ​​in fields specified by keywords / tags, multiple keywords / tags, or both. For the first-scope login signature, the extracted components are at least the username and password values. The network device then searches the current list of first-scope login signatures for a match based on the extracted components.

[0034] In block 405, the network device determines whether a match was found in the first scope login signature. For example, the network device determines whether a query to the login signature repository returns an empty value or a hardcoded set of credentials and / or the corresponding resource / service identifier. If a match is found with the first scope login signature, the operation flow proceeds to block 409. If no match is found, the operation flow proceeds to block 406.

[0035] In block 406, the network device extracts the second-scope signature component from the login traffic sample and searches for a second-scope login signature for a match. Since the second-scope login signature may contain encrypted username and password, it allows for the detection of login requests corresponding to a hardcoded set of credentials of interest without having to detect the hardcoded set of credentials. To maintain reliability in detection, implementations can define second-scope login signatures with more components. As mentioned earlier, these may include keywords and values ​​for protocols, resource / service indicators, and script keywords.

[0036] In block 407, the network device determines whether a match was found in the second-scope login signature. If a match is found in the second-scope login signature, the operation flow proceeds to block 409. If no match is found, the operation flow terminates. This assumes that only two scopes of the login signature are being used. Embodiments may add other scopes depending on the strength of the match reliability or tolerance acceptable to the customer / user, for a greater number of false positives in login detection that will be submitted to the analytics service or platform.

[0037] In block 409, the network device submits login traffic samples for login attack analysis. Based on the detection of first or second scope login signatures in the login traffic samples, the network device submits login traffic samples by message or function call (e.g., by a platform or SaaS defined API) for analysis to determine whether the login request is an exploit of a hardcoded credential vulnerability or a legitimate login.

[0038] The operation flow continues asynchronously to block 411, as indicated by the dashed line. In block 411, the network device determines whether the determination from the login attack analysis is malicious or benign. After submitting a login traffic sample for analysis, the network device delays sending login requests until the determination is received. If the determination is benign, the network device no longer delays login requests, and the operation flow ends, while scanning continues (401). If the determination indicates malicious, the operation flow proceeds to block 413.

[0039] In block 413, the network device takes security action based on a malicious determination. A malicious determination indicates that the login request is likely to be an attack. The network device takes security action against detected hardcoded login attacks as defined in the security policy. This may include generating an alarm or notification, updating the network's attack visualization, capturing login traffic samples for further analysis, blocking all traffic from the same source, etc.

[0040] Figure 5 is a flowchart illustrating an exemplary operation for determining whether a login request is legitimate or an exploit of a hardcoded credential login vulnerability. For consistency with Figures 1-2, the explanation in Figure 5 refers to the login attack detector as an operation. The names chosen for the program code are not limiting to the claims. The structure and organization of a program may vary due to platform, programmer / architect preferences, programming language, etc. Furthermore, the names of code units (programs, modules, methods, functions, etc.) may vary for the same reasons and may be arbitrary.

[0041] In block 501, the login attack detector determines the source network address of the login traffic sample submitted for login attack analysis. The network device detects the login signature in the login traffic sample and submits the login traffic sample for analysis. The login traffic sample may be a message formed from lower-layer protocol data units (e.g., packets) or stored in a location accessible by the login attack detector and the network device. For example, the network device may store login requests from network traffic samples as files in an online repository and notify the login attack detector of their location (e.g., address and file name).

[0042] In block 503, the login attack detector searches the block / allow list for the source network address. The login attack detector platform / service may maintain a global (e.g., customer-wide) blocklist based on the identification of malicious actors. Using the blocklist, a login attack can be quickly determined to be malicious if the source network address of a login traffic sample is in the blocklist. Customers may share their allowlists with the platform / service to enable quick determination of benign, which is likely to be more effectively used at the customer's network perimeter. If the source address is found in the blocklist, the operation flow proceeds to block 511. If the source address is found in the allowlist, the operation flow proceeds to block 510. If the source address is not found, the operation flow proceeds to block 505.

[0043] In block 505, the login attack detector determines whether the reputation score of the source address meets the malicious actor threshold. For implementations that quantify suspicion / risk with a higher reputation score, the reputation score meets the malicious actor threshold when it is equal to or exceeds the malicious actor threshold (comprehensively depending on the threshold implementation). This effectively represents that the accumulation of observed activity or behavior associated with the source address has resulted in a suspicion or risk that it is considered malicious. The reputation score is updated in block 509 based on the observed login behavior. Thus, the malicious login behavior previously determined by the source address is reflected in the reputation score. If the reputation score meets the malicious actor threshold, previous login behavior analysis indicating a login attack, and other analyses of login behavior, may be bypassed. If the reputation score meets the malicious actor threshold, the operation flow proceeds to block 511. If the reputation score does not meet the malicious actor threshold, the operation flow proceeds to block 507.

[0044] In block 507, the login attack detector compares the profile or fingerprint of a login traffic sample to a login attack profile. A more detailed illustrative operation is shown in Figure 6. If the profile comparison yields a match to the login attack profile, the operation flow proceeds to block 511. Otherwise, the operation flow proceeds to block 509.

[0045] In block 509, the login attack detector analyzes login behavior across network devices. Analyzing login behavior across network devices provides a view of login traffic samples and associated behavior across a network or multiple networks. Depending on user preferences and permissions, the analysis may span different customer networks. A more detailed illustrative operation is shown in Figure 7. If the login behavior analysis determines that the behavior is malicious, the operation flow proceeds to block 511. If the login behavior analysis determines that the behavior is not malicious, the operation flow proceeds to block 510.

[0046] The results of the analysis are shown in blocks 510 and 511. In block 511, the login attack detector indicates a malicious use determination. In block 510, the login attack detector indicates a benign use determination. The login attack detector can make a determination about communications to the network device that submitted the login traffic sample for analysis and can generate a message or notification that identifies the attributes of the login traffic sample.

[0047] Figure 6 is a flowchart illustrating an exemplary operation for comparing a login traffic sample profile with a login attack profile. The description of an exemplary operation refers to the operation performed by the login attack detector. In block 601, the login attack detector generates a profile from the login traffic sample. Different login attack profiles may have various components. Therefore, the login attack generator may create multiple profiles for each login attack profile using different configuration fields / components. For example, a login attack profile may vary depending on the protocol (e.g., HTTP, FTP). The login attack detector extracts the values ​​of the defined components for the profile. Exemplary components that form a profile or fingerprint include user agent, platform, and product. Furthermore, a login attack profile may also include components of the login signature. In block 603, the login attack detector compares the generated profile with the login attack profile to determine if a match exists. If a match exists with the login attack profile, the operation flow proceeds to block 511. If no match exists, the operation flow proceeds to block 509 or 510, depending on the implementation.

[0048] Figure 7 is a flowchart of exemplary operations for analyzing login behavior across network devices. To distinguish between legitimate use of hardcoded credential sets and login attacks involving hardcoded credential sets, analysis of login traffic at different entrance points to one network or multiple networks and / or different entrance points to multiple networks is examined against login attack heuristics. Descriptions of exemplary operations refer to operations performed by the login attack detector. Exemplary operations represented by blocks 705, 707, and 709 correspond to operations related to maintaining reputation scores for source network addresses of login traffic samples based on login behavior analysis. Exemplary operations correspond to implementations where a higher reputation score reflects a greater risk or suspicion. However, these operations are optional and are therefore indicated by dashed lines.

[0049] In block 701, the login attack detector retrieves login traffic samples across network devices that have a set of one or more attributes common to the login traffic sample. When login traffic is detected using the login signature, the login traffic repository is updated to provide visibility into activity across a network entry point or multiple network entry points. The login attack detector queries the repository for login traffic samples that have one or more attributes of the login traffic sample submitted for analysis. For example, the login attack detector queries for login traffic samples that have the same source network address as the login traffic sample. Since different login attack heuristics may be aligned with different common attributes, the login attack detector may submit different queries to retrieve different sets of login traffic samples for analysis. In addition to network addresses and account identifiers, other exemplary features that may be common across an attack or intrusion include domain names, HTTP message elements (e.g., user agent, query string in message header, etc.), and service identifiers.

[0050] In block 703, the login attack detector analyzes a set of login traffic samples against login attack heuristics. Login attack heuristics are encodings of observed login attack characteristics. Characteristic encodings can be a set of conditional statements used collectively to determine the presence of a characteristic in the login traffic samples being analyzed. The following is an example of a login attack heuristic. Login attack heuristic 1: Multiple login attempts from the same source address Login attack heuristic 2: Multiple login attempts to the same account Login attack heuristic 3: Multiple login attempts from the same source address to different accounts Login attack heuristic 4: Multiple login attempts from different source addresses These examples relate to login attempts and attack heuristics, while embodiments are not limited to them. An attack heuristic may be a threshold number of service requests within a time window, regardless of the requesting or source address. Another heuristic may be multiple request messages from different addresses and / or accounts corresponding to the same domain. If a login traffic sample does not possess the characteristics shown in any of the login attack heuristics, the login attempt is determined to be non-malicious, and the operation flow proceeds to block 707. Otherwise, the login attempt is determined to be malicious.

[0051] In block 705, the login attack detector increases the reputation score of the source network address of the login traffic sample being analyzed, based on the determination of malicious login behavior. The reputation score is increased by a constant amount based on the determination of malicious login behavior. Embodiments may use heuristics relating to different degrees of risk or suspicion and, therefore, proportionally increase the reputation score. The operation flow proceeds from 705 to 511.

[0052] In block 707, the login attack detector determines whether the decline criterion is met. Decreasing the reputation score to reflect an increase in trustworthiness may be done to recover a typically trusted node used in an attack, such as a command and control attack. This criterion could be a period or number of non-malicious outcomes for a source address. A state is maintained for the reputation score to determine whether the criterion is met. For example, if the criterion is time-based, the state indicates the time when the reputation score was most recently adjusted to reflect a malicious decision. As another example, if the criterion is based on the number of logins analyzed for a network address, the state is a counter. If the decline criterion is not met, the reputation score should not be changed, so the operation flow terminates, and the operation flow returns to the calling or containing program code (e.g., continuing to block 510 in Figure 5). If the criterion is met, the operation flow proceeds to block 709 (e.g., continuing to block 510 in Figure 5).

[0053] In block 709, the login attack detector deducts the reputation score based on the reputation score status. Deducting reputation, as well as increasing it, is implementation-dependent (e.g., deducting a fixed amount for detected behavior or deducting proportionally). The operation flow ends after block 709 (e.g., continuing to block 510 in Figure 5).

[0054] Variation

[0055] Embodiments may anonymize at least some data in login request network traffic samples communicated or supplied from a scanning network device. This may be done to comply with privacy laws and / or to satisfy customer concerns about privacy or data leakage. An agent or process in a network device scanning login signatures obfuscates the sample, or specified fields of the sample (e.g., username and password fields), according to an obfuscation paradigm established between the scanning network device and a cybersecurity platform or cybersecurity provider that generates login signatures and analyzes the sample. The obfuscation paradigm may be defined by the jurisdiction of the customer and / or the sample source. For example, the platform / provider may use public-key cryptography with a different private key for each customer to obfuscate the data. As another example, anonymization may be limited to the identification of the source or customer, and not necessarily limited to data traffic. As one example, information identifying a scanning network device, or the organization that owns the network device, can be replaced with a generic identifier that allows for the differentiation of traffic flows without identifying the customer or address of the scanning network device.

[0056] The illustrative description refers to the exploitation of hardcoded credentials against the pervasiveness of a vulnerability. However, embodiments are not limited to this vulnerability and are not limited to evaluating login traffic and login attempts. Network traffic across different security devices / components (e.g., different firewalls, gateways, etc.) may be analyzed to detect attempted attacks, not limited to login attempts. For example, a login attempt may initiate aggregated view analysis (e.g., analysis of traffic across different security devices / components or traffic across different private network boundaries), but other network traffic that does not have login markers and / or does not contain login traffic may be collected and analyzed based on common traffic attributes independent of logins. Furthermore, a login attempt is not necessarily required to trigger aggregated traffic analysis. In addition to, or instead of, scanning for login signatures, security equipment (hardware or software) may be programmed to scan for other signatures or markers. For example, a scanner may be programmed to scan for service identifiers or domain identifiers and then initiate aggregated traffic analysis. The embodiments are not limited to aggregated traffic analysis that relies on scanning for markers or signatures. For example, the detection of threat signatures or discovered attacks can initiate aggregated traffic analysis. The analysis extracts different attributes of the traffic in which attack or threat signatures are detected, and then collects the traffic for aggregated analysis by obtaining traffic that has at least some of those attributes in common.

[0057] The flowchart is provided to aid in understanding the examples and should not be used to limit the scope of the claims. The flowchart represents exemplary operations that may vary within the scope of the claims. Additional operations may be performed, fewer operations may be performed, operations may be performed in parallel, and operations may be performed in different orders. For example, one implementation may simultaneously look up different ranges of login signatures corresponding to blocks 403 and 406. As another example, not all operations shown in blocks 505, 507, and 509 may be performed. If multiple operations represented by blocks 505, 507, and 509 are performed, they may be performed simultaneously. In addition, the operation represented by block 503 is not required and depends on whether an allow / blocklist is defined in the platform or service providing cybersecurity analysis. It will be understood that each block in the flowchart examples and / or block diagrams, as well as combinations of blocks in the flowchart examples and / or block diagrams, may be implemented by program code. The program code may be provided for the processor of a general-purpose computer, a dedicated computer, or other programmable machine or device.

[0058] To be understood, aspects of this disclosure may be embodied as systems, methods, or program code / instructions stored in one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, all of which may be commonly referred to herein as “circuit”, “module”, or “system”. Functionality represented as individual modules / units in the illustrative description may be configured differently according to the platform (operating system and / or hardware), application ecosystem, interface, programmer preferences, programming language, administrator preferences, etc.

[0059] Any combination of one or more machine-readable media may be used. A machine-readable media may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium may be, but is not limited to, a system, apparatus, or device that employs one or a combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technologies for storing program code. More specific examples (non-exclusive list) of machine-readable storage media may include: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this specification, a machine-readable storage medium may be any tangible medium that contains or can store programs for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable storage medium is not a machine-readable signal medium.

[0060] A machine-readable signaling medium may include, for example, a propagating data signal accompanied by machine-readable program code embodied therein, either in the baseband or as part of a carrier wave. Such propagating signals may take any of various forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A machine-readable signaling medium may be any machine-readable medium that is not a machine-readable storage medium and that can communicate, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device.

[0061] Program code, embodied on a machine-readable medium, may be transmitted using any suitable medium. These mediums include, but are not limited to, wireless, wired, fiber optic cables, RF, and the like.

[0062] Program code / instructions may also be stored in machine-readable media that can instruct a machine to function in a specific way. As a result, instructions stored in machine-readable media generate a product that includes instructions to perform a function / operation specified in one or more blocks of a flowchart and / or block diagram.

[0063] Figure 8 shows an exemplary computer system having login attack detection and prevention components. The computer system includes a processor 801 (possibly including multiple processors, multiple cores, multiple nodes, and / or implementing multithreading, etc.). The computer system includes memory 807. Memory 807 may be system memory or one or more of the possible implementations of machine-readable media already described above. The computer system also includes a bus 803 and a network interface 805. The system also includes a login attack detector 811, a login signature generator 815, and a login signature scanner 813. The system may have all the components / functionalities corresponding to these components, but a expected implementation will have at least one other login signature scanner deployed to collect data across one or more networks, scan traffic, and communicate with the login attack detector 811. Also, the login signature generator 815 and the login attack detector 811 do not need to be hosted on the same device, but both may be part of the same system. The login signature scanner 813 may be implemented as a separate network traffic scanner, or an implementation may adapt an existing traffic scanner to scan for login signatures and communicate login traffic samples to the login attack detector 811 and the login signature generator 815. The login attack detector 811 distinguishes between legitimate attempted logins and malicious attempted logins corresponding to hardcoded credentials for which signatures have been detected. The login signature generator 815 generates login signatures for data collection and attack analysis. The login signature generator 815 may also provide a user interface for the user to select components of a login traffic sample to form login signatures relating to different match scopes.Any one of the aforementioned functionalities may be implemented in hardware and / or partially (or completely) on the processor 801. For example, the functionality may be implemented using application-specific integrated circuits within the logic implemented in the processor 801, within a coprocessor on a peripheral device or card, or in welding. Furthermore, the implementation may include fewer or additional components not shown in Figure 8 (e.g., a video card, an audio card, additional network interfaces, peripheral devices, etc.). The processor 801 and the network interface 805 are coupled to the bus 803. Although shown as coupled to the bus 803, the memory 807 may be coupled to the processor 801.

[0064] term

[0065] The use of the phrase "at least one of" preceding a list accompanied by the conjunction "and" should not be treated as an exclusive list unless otherwise specified, nor should it be interpreted as a list of categories having one item from each category. A clause containing "at least one of A, B, and C" may be violated by one of the listed items alone, multiple of the listed items, or one or more of the listed items and other items not listed.

Claims

1. It is a method, A step of detecting a login request in a subset of first network traffic, which includes one of a plurality of login signatures, based at least in part on scanning network traffic transmitted through a first network device, The step of determining whether the login request is legitimate or suspicious is, A step of determining whether the profile generated from the first network traffic subset matches the attack profile, A step of determining whether the behavior determined from the second network traffic and the first network traffic subset is suspicious, wherein the second network traffic has at least one attribute common to the first network traffic subset, and A step of determining whether the reputation score of the first network address, which is shown as the source address of the first network traffic subset, meets the threshold for a malicious actor. A step including at least one of the following, A step of indicating a determination based on the determination of whether the login request is legitimate or suspicious, Methods that include...

2. Network traffic scanning includes scanning network traffic for one of the first subsets of the plurality of login signatures or one of the second subsets of the plurality of login signatures. Each of the first subset of the plurality of login signatures includes at least hardcoded credentials and a resource identifier or service identifier. Each of the second subset of the plurality of login signatures includes at least a login marker and a resource identifier or service identifier. The method according to claim 1.

3. The aforementioned method further The steps include scanning the first network traffic for multiple credentials identified as being susceptible to the exploit, The steps include: detecting a first credential among the plurality of credentials, and capturing a second network traffic subset including the first credential; The steps include generating a first login signature based at least partially on the second network traffic subset, The method according to claim 1, including the method described in claim 1.

4. The step of generating the first login signature is as follows: The steps include determining the resource or service identifier corresponding to the first credential from the second network traffic subset, and The step of indicating the resource or service identifier associated with the first credentials as the first login signature, The method according to claim 3, including the method described in claim 3.

5. The above method further, The process includes the step of generating a second login signature based at least partially on the second network traffic subset, The step of generating the second login signature is: The steps include determining a set of one or more login markers in a login request or login response of the second network traffic subset from the second network traffic subset, and The step of representing the set of login markers associated with the resource or service identifier as the second login signature, The method according to claim 4, including the method described in claim 4.

6. The step of determining whether the login request is legitimate or suspicious is further: A step of determining whether the source network address of the first network traffic subset is permitted, trusted, or blocked. Optionally, the steps include capturing the first network traffic subset, and In order to determine whether the login request is legitimate or suspicious, the captured subset of first network traffic is submitted from the first network device to a cloud-based cybersecurity service. The method according to claim 1, including the method described in claim 1.

7. The above method further, The step of obtaining the second network traffic is at least partially based on querying the login network traffic of a plurality of network devices having at least one common attribute with the first network traffic subset, wherein the at least one common attribute is the first network address. The step of determining whether the aforementioned behavior is suspicious is: Whether the second network traffic indicates login attempts from the first network address to multiple different accounts using login credentials corresponding to the login requests in the first network traffic subset, Whether the second network traffic indicates multiple login attempts to the same entity from the first network address, and, Whether the second network traffic and the third network traffic represent multiple login attempts to the same entity from the first network address and the second network address shown as the source address in the third network traffic, The step of determining at least one of the following, The method according to claim 1.

8. The above method further, The step includes maintaining the reputation score of the first network address based on an analysis of the behavior of network traffic, with the first network address being the source address. The behavioral analysis includes evaluating the network traffic that indicates the first network address as the source address for a heuristic of malicious or suspicious login attempts. The method according to claim 1.

9. The aforementioned plurality of login signatures correspond to at least one of the following: default credentials, hardcoded credentials, a device having default credentials or hardcoded credentials, software having default credentials or hardcoded credentials, and a cloud-based service having default credentials or hardcoded credentials. The method according to claim 1.

10. A non-temporary machine-readable storage medium in which program code is stored, wherein the program code includes a plurality of instructions, and when the instructions are executed, The instruction for determining whether a login request detected in the first network traffic is legitimate or an exploit of a login vulnerability is: Instructions for determining a second network traffic that spans multiple network devices having at least one attribute common to the first network traffic, and for determining whether the login behavior of either the first network traffic or the second network traffic has specified characteristics of a login attack. An instruction for determining whether the reputation score of the source network address of the first network traffic meets the threshold for a malicious actor, wherein the reputation score is based on the login behavior of the network traffic of the source network address, and Instructions for determining whether the profile generated from the first network traffic matches the login attack profile, It includes at least one of the following: Based at least in part on the determination of whether the login request is legitimate or an exploit of a login vulnerability, a security decision corresponding to the login request is generated. A non-temporary, machine-readable memory medium that allows for such operation.

11. The instruction for determining whether the login behavior has the specified characteristics of a login attack is: Whether the login behavior indicates login attempts from the source network address to multiple different entities using login credentials corresponding to the detected login signature, Whether the login behavior indicates multiple login attempts from the source network address to the same entity, and, Whether the login behavior of the first network traffic and the second network traffic, and the login behavior of the third network traffic, indicate multiple login attempts to the same entity from the source network addresses of the second network traffic and the third network traffic, and from the second source network address indicated as the source address of the third network traffic, Includes an instruction to determine at least one of the following: The non-temporary machine-readable storage medium according to claim 10.

12. The aforementioned program code further, Includes instructions to maintain the reputation score of the source network address of network traffic in which one of multiple login signatures was detected. The non-temporary machine-readable storage medium according to claim 10.

13. The instruction to maintain the aforementioned reputation score is: The instructions include updating the reputation score of a network address in order to improve or worsen its reputation, as represented by the reputation score, based on the login behavior of network traffic observed for the source network address. The non-temporary machine-readable storage medium according to claim 12.

14. The aforementioned program code further, The instructions include scanning network traffic for one of several login signatures generated based on hardcoded credentials of a service or resource. The detection of login requests is based on scanning for the detection of one of the aforementioned multiple login signatures. The non-temporary machine-readable storage medium according to claim 10.

15. The aforementioned plurality of login signatures correspond to at least one of the following: default credentials, hardcoded credentials, a device having default credentials or hardcoded credentials, software having default credentials or hardcoded credentials, and a cloud-based service having default credentials or hardcoded credentials. The non-temporary machine-readable storage medium according to claim 14.

16. Processor, and, Non-temporary machine-readable storage medium according to any one of claims 10 to 15, A system that includes this.

Images