Patent Description:
Attackers target servers having relatively weak passwords and no multi-factor authentication, virtual private networks (VPNs), and other security protections. Through brute force attacks, threat actor groups have gained access to target machines and have conducted many follow-on activities like ransomware and coin mining operations.

<CIT> describes systems and methods for detecting potential attacks on a domain, where one or more servers, in response to a failure event, obtain a lambda value from a baseline model of historical data associated with a current time interval corresponding to the failure event, determine a probability of whether a total count of failure events for the current time interval is within an expected range using a cumulative density function based on the lambda value, and identify a possible malicious attack if the probability is less than or equal to a selected alpha value.

<NPL> describes how cyber intrusions are one of the main causes of fear across the internet and now, due to the substantial increase in network traffic, detection of each unauthorized access has become extremely difficult. Brute-force attacks are the most common form of malicious traffic. To prevent such attacks and detect them in real time many new techniques have been developed. The majority of these techniques monitor the sequential transfers between users/IPs and the network. However, though many networks are now monitoring their logs and can identify when brute-force attacks occur, they cannot provide more detailed information about the attack (such as where and how) without some form of direct visual inspection of the logs. The authors explore a Latent Dirichlet Allocation as a form of topic modeling of IP addresses through SSH authentication logs with the final goal of automating classifications of users. Using textual topics or the "top words" associated with logs, the authors differentiate legitimate users and brute-attackers users according to their IP addresses and discuss the potential of topic modelling for identifying and further classification of cyber threats.

<NPL> describes methods to detect SSH brute-force attacks by analyzing a server's unsuccessful access logs and a firewall's drop events in a multi-user environment. Then, the authors analyze the durations of the SSH brute-force attacks that are detected by applying these methods. The results of an analysis of about <NUM> thousand attack source IP addresses show that the behaviors of abnormal users using SSH brute-force attacks are based on human dynamic characteristics of a typical heavy-tailed distribution.

Brute force attacks represent a technical problem in that they can be difficult to detect while generating a manageable number of false positives. In a brute force attack, adversaries can attempt to sign into an account by effectively using one or more trial-and-error methods. In some instances of brute force attacks, failed logins are associated with these attacks. These failed logins can occur over a very short time frequency, typically minutes or even seconds. A brute force attack might also involve an attempt to access one or multiple accounts using valid usernames. The valid usernames may be obtained by the attacker via traditional credential theft techniques or via use of common usernames such as "administrator. " The same holds for password combinations. In detecting brute force attacks, some of the disclosed embodiments focus on a source Internet Protocol (IP) address and username, as in at least some cases, password data is not available.

In some operating environments, login failures are logged to a log file or other logging facility. These log entries may include an event code indicating the login failure, along with associated information, such as a username used in the login attempt. For example, in the Microsoft Windows operating system, whenever an attempted login fails for a local machine, Event Tracing for Windows (ETW) registers Event ID <NUM> with the associated username.

Moreover, source IP addresses associated with the failed login attempt are also recorded in at least some environments. This information can be useful in assessing if a machine is under brute force attack. This information, in combination with indications of login failures (e.g. Event ID <NUM>) for non-server machines, is useful to understand which login sessions were successfully created. Based on this understanding, indications of a compromised machine are generated.

Disclosed are embodiments that utilize these and/or other signals which have proven valuable in detecting and, in some embodiments, mitigating brute force attacks. In some embodiments, this capability may be deployed via Microsoft Threat Experts, a managed threat hunting service in Microsoft Defender Advanced Threat Protection. Other embodiments are deployed in non-Microsoft environments or environments including solutions delivered by a mix of different vendors.

In some embodiments, the disclosed embodiments generate one or more alerts. The alerts are directed to, in various embodiments, one or more of system administrators, security vendors, end users, or other contacts. In some embodiments, the detection of anomalous activity indicating a brute force attack causes programmatic reconfiguration of network security devices such as firewalls, proxies, routers, switches, or other network devices to mitigate the brute force attack. For example, in some embodiments, an access control policy of one or more network security devices is updated based on a likelihood of a brute force attack. The programmatic reconfiguration is performed, in some embodiments, without human intervention. For example, a firewall is reconfigured in some embodiments to prevent access to a network by a device identified as initiating at least a portion of an identified brute force attack. In some embodiments, more restrictive access policies are progressively deployed to network security devices until the brute force attack is successfully mitigated (e.g. a level of anomalous activity drops below a predetermined threshold). These access policies are progressively deployed, in some embodiments, by programmatically configuring one or more firewalls deployed to control access to the network.

Some of the disclosed embodiments recognize that observation of a sudden, relatively large count of particular types of events (e.g. Event ID <NUM>) associated with network connections (e.g. RDP), while infrequent in some environments, does not necessarily imply that a machine is under attack. For example, a script that performs the following actions would appear to be suspicious when evaluating a time series of counts of failed logins. However, such an example is most likely not malicious:.

In contrast, behavior that includes the following events can be indicative of an attack:.

The above example demonstrates that understanding the context of failed logins and inbound connections can be useful in discriminating between true positive (TP) and false positive (FP) brute force attacks. Such understanding provides for improved precision in detecting brute force attacks.

In developing the disclosed embodiments, historical data from several previous months was obtained. This historical data was later analyzed to provide insights into the types of brute force attacks occurring across the measured environments during those previous months. Out of approximately <NUM>,<NUM> machines that had both public IP connections (e.g., RDP) and at least one (<NUM>) network failed login, on average, several hundred machines per day had a high probability of undergoing one or more brute force attack attempts. Of the subpopulation of machines with detected brute force attacks, the attacks lasted <NUM>-<NUM> days on average, with about <NUM>% of cases lasting for <NUM> week or less, and less than <NUM>% for <NUM> or more weeks. Based at least partly on insights gained via the analysis of the historical data, the presently disclosed embodiments were then developed.

To detect brute force attacks, some of the disclosed embodiments implement a technical solution to the technical problem of brute force attacks that models a distribution of operational parameter values as a finite mixture of distributions. The use of a mixture model in detection of a brute force attack recognizes the multi-modal nature of operational parameter values experienced by a computer network. By comparing operational parameter values to a distribution appropriate for a network environment during a given time period, the disclosed embodiments adapt their detection of brute force attacks as needed to reduce a number of false positives while still providing accurate detection of real brute force attacks.

Each distribution in the mixture model is defined by one or more parameters. The parameters and thus the distributions themselves are dynamically updated based on additional operational parameter values as those operational parameter values are observed. The disclosed embodiments compare observed operational parameter values to particular distributions in the mixture model based on dynamically determined thresholds that determine which distribution is used for the comparison. In some embodiments, multiple time series are each modeled as separate mixtures of distributions, with each mixture model defined by its own distribution parameters and comparison thresholds. By recognizing that one or more time series of operational parameter values may be multi-modal, and thus are best compared using a mixture model of distributions, the disclosed embodiments are able to more accurately detect anomalous events, while reducing the probability of false positives.

<FIG> is an overview diagram <NUM> of a network that implements one or more of the disclosed embodiments. <FIG> shows a network <NUM>. The network <NUM> includes a plurality of network components 102A-F. <FIG> also shows devices external 104A-C to the network <NUM>. Network components 102A-F within the network <NUM> and external devices 104A-C outside the network <NUM> communicate with each other. Examples of this communication is illustrated in <FIG> as arrows 106A-G (not all arrows are labeled to preserve figure clarity).

Access to the network <NUM> is controlled by a firewall <NUM>. <FIG> also shows a network security system <NUM>. In some embodiments, the network security system <NUM> collects information on the communication between network components 102A-F and/or external devices 104A-C represented by the arrows 106A-G. The network security system <NUM> also collects, in some embodiments, operational parameter values of one or more of the network components 102A-F. As discussed in more detail below, based on information indicating the communications, the disclosed embodiments provided for improved methods of detecting a brute force attack on the network <NUM>. In some embodiments, the network security system <NUM> sends one or more control signals <NUM> to the firewall <NUM>. The control signals <NUM> configure one or more network access policies for one or more of the devices 102A-F.

The network security system <NUM> receives operational parameter values from one or more of the network components 102A-F. The operational parameter values are received by the network security system <NUM> via messages transmitted from the network components (directly or indirectly) to the network security system <NUM>. These messages are shown as messages 122A-C. The operational parameter values provided by the one or more network components 102A-C are provided, in at least some embodiments, as a time series of values. In other words, the operational parameter values are periodically, or at multiple times, at regular or irregular intervals, measured, and then communicated to the network security system <NUM>.

The network security system <NUM> processes the operational parameter values according to the methods discussed herein in order to determine a probability that the network <NUM> is experiencing a brute force attack. For example, the analysis performed by the network security system <NUM> determines, in some cases, that one or more of the external devices 104A-C is initiating a brute force attack on the network <NUM>.

<FIG> shows an example empirical distribution of a number of days devices of a network experienced a brute force attack. Large counts of failed logins are often associated with brute force attacks. In the example of <FIG>, <NUM>% of brute force attacks exhibit greater than ten attempts, with a median larger than <NUM>. In addition, unusual daily counts have a high positive correlation with large counts in shorter time windows (see <FIG>). The number of extreme failed logins per day occurred under two hours typically, with about <NUM>% failing in under thirty minutes.

<FIG> shows example counts of daily and maximum hourly network failed logins for a local machine under brute force attack. While detection logic based on thresholding a count of failed logins during a daily or finer grain time window can detect many brute force attacks, this can produce too many false positives. Relying on such a strategy will also result in false negatives, resulting in missed compromises of a network. We identified several instances of brute force attacks that generated fewer than five to ten failed attempts daily, but often persisted for many days. This attack pattern avoids extreme counts at any point in time. For such a brute force attack, thresholding the cumulative number of logins over time that are unsuccessful across time demonstrated efficacy, as discussed below with respect to <FIG>.

<FIG> shows daily and cumulative failed network logins. Looking at counts of network failed logins provides a useful but incomplete picture of RDP brute force attacks. This can be further augmented with additional information about the failed login, such as the failure reason, time of day and day of week, as well as the username itself. An especially strong signal is the source IP of the inbound RDP connection. Knowing if the external IP has a high reputation of abuse, as can be looked up on sites like https://www. com/, can directly confirm if an IP is a part of an active brute force.

Unfortunately, not all IP addresses have a history of abuse, and it can be expensive to retrieve information about many external IP addresses on demand. Maintaining a list of suspicious IPs is an option, but relying on this can result in false negatives as inevitably, new IPs continually occur, particularly with the adoption of cloud computing and ease of spinning up virtual machines. A generic signal that can augment failed login and user information is counting distinct RDP connections from external IP addresses. Again, extreme values occurring at a given time or cumulated over time can be an indicator of attack.

<FIG> show example histograms (i.e., counts put into discrete bins) of daily counts of RDP public connections per machine that occurred for an example enterprise with known brute force attacks. It's evident that normal machines have a lower probability of larger counts compared to machines attacked.

Given that some enterprises have machines under brute force attack daily, the priority may be to focus on machines that have been compromised, defined by a first successful login following unsuccessful attempts from suspicious source IP addresses or unusual usernames. In embodiments directed to Microsoft Windows operating systems, Windows logs, Event ID <NUM> can be leveraged to measure successful login events for local machine in combination with unsuccessful logins (e.g. Event ID <NUM>).

Out of the hundreds of machines with RDP brute force attacks detected in our analysis, we found that about. <NUM>% were compromised. Furthermore, across all enterprises analyzed over several months, on average about one machine was detected with high probability of being compromised resulting from an RDP brute force attack every <NUM>-<NUM> days.

<FIG> shows a bubble chart of example average abuse scores of external IPs associated with RDP brute force attacks that successfully compromised machines. The size of the bubbles is determined by the count of distinct machines across the enterprises analyzed having a network connection from each IP. While there is diversity IPs originate, Netherlands, Russia and United Kingdom have a larger concentration of inbound RDP connections from high-abuse IP.

A takeaway from our analysis is that successful brute force attempts are not uncommon; therefore, it's critical to monitor at least the suspicious connections and unusual unsuccessful logins that result in authenticated login events. In the following sections we describe a methodology to do this.

Reliance on thresholding of operational parameter values such as a number of unsuccessful attempts per machine for detecting brute force attacks can be noisy and may result in many false positives. For example, such an approach can generate false positives in a situation when a script has been preconfigured with an outdated password and continuously attempts to login using the invalid password.

To avoid problems associated with basic thresholding, at least some of the disclosed embodiments utilize a plurality of contextually relevant signals, such as:.

These examples can be extended to include indicators associated with a brute force attack, such as counts of detected port scanning.

At least some of the disclosed embodiments analyze one or more of the following per machine (or device) signals when determining whether an RDP inbound brute force attack is in progress or has previously occurred:.

In some embodiments, each time series or signal is scored for its indication of a brute force attack. In some embodiments, hourly time windows are the lowest time granularity. In other embodiments, other periods of time (a minute, five minutes, etc.) are used as the shortest time window for a time series. One or more additional time series can be generated by accumulating the lowest time granularity time series. For example, in some embodiments, some time series aggregate multiple hour time series within a day. In some embodiments, some time series aggregate granular time series across multiple days accounting for specific daily and weekly periodicity effects. Additionally, some time series are aggregated across multiple devices, and across multiple networks in some embodiments.

Let t be a time window, and T represent an interval of multiple time windows at a higher temporal frequency than t. The discussion below defines yt to be a lowest level univariate time series per each signal type and per single or multiple devices, and yT be an aggregation of yt for the time frequency T.

A first signal is a categorical time series of logon type (e.g. Event Id <NUM>) per device per t. For each device in a network, yt = [("<NUM>", countt), ("<NUM>", countt). , ("<NUM>", countt)], where "<NUM>", "<NUM>" and "<NUM>" are examples of login types. For example, "<NUM>" is a sign-on at a keyboard, "<NUM>" is a connection to a shared folder on the device from elsewhere in the network, etc. Of particular interest for monitoring inbound brute force were logon types "<NUM>" and "<NUM>". The countt represents a total number of failed logins at time t of the specified login type. In some embodiments, the count is determined across usernames and IP addresses group.

A second signal is a categorical time series of failure reason (e.g. Event ID <NUM>) per device per t per logon type. For each device in a network, yt = [("<NUM>: %%<NUM>", countt), ("<NUM>:%%<NUM>", countt). , ("<NUM>:%%<NUM>", countt)], where each entry of the time series yt includes the logon type (e.g. "<NUM>:", "<NUM>:", "<NUM>:"), a failure reason code (e.g. "%%<NUM>"), and a count. For example, the failure reason %%<NUM> describes that the users attempting to login have not been granted access on the device. The countt term represents a total number of failed logins at time t for the specified logon type and failure reason. In some embodiments, the total number of failed logins are counted across usernames. Some embodiments generate a time series of countt per IP address. In some embodiments, a time series is generated that aggregates countt values for a group of IP addresses having an associated reputation or anomaly score that meets a predetermined criterion (e.g., reputation or score is less than a predetermined threshold).

A third signal in some embodiments is a time series aggregated failed login counts across multiple login types and/or multiple login failure reasons. Thus, these embodiments contemplate a third signal comprised of one or more combinations of possible login types and one or more combinations of possible login failure reasons. In some embodiments, this signal is generated on a per device basis. For each device in a network and set of logon type and failure reason time series, yt = count of total number of failed logins at time t across username and IP addresses. For example, yt can be counts summed across possible login types <NUM> and <NUM>, and login failure reasons in (%%<NUM>, %%<NUM>, %%<NUM>, %%<NUM>).

A fourth signal in some embodiments is a cumulative count of failed logins per device per T. The cumulative count is filtered by one or more logon types and login failure reasons. For each device in a network and the filtered logon type(s) and failure reason(s), the time series, yT = Σt∈T yt, where yt is a count of a failed login signal.

A fifth signal in some embodiments is a cumulative count of failed logins per device per T across a subset of one or more logon types and failure reasons. For each device in a network and set of logon type and failure reason time series, yT = Σt∈T yt, where yt is the count of a failed login signal. Thus, a difference between the fourth and fifth signal is that the fifth signal includes a subset of logon types relative to the fourth signal. For example, in some embodiments, the fifth signal indicates login failures having reasons associated with new (or unknown) usernames, and a logon type indicating a network connection (e.g. the login attempt was initiated from outside the monitored network or at least not via a console of the machine).

A sixth signal in some embodiments is a total count of remote desktop protocol (RDP) inbound public source addresses per device per time t. In other words, the sixth signal represents, in some embodiments, how many different source addresses are attempting RDP connections on a device during the time period t. Thus, the sixth signal provides, for each device in a network, RDP source addresses that are public. Thus, the sixth signal can be defined, in some embodiments, as yt = a count of total distinct IP source RDP addresses per t.

A seventh signal in some embodiments is a cumulative count of RDP inbound public source address per device. For each device in a network and RDP network connection, yT=Σt∈T yt, where yt is the count of RDP inbound connections. The seventh signal accumulates the count for a longer period of time than the sixth signal. For example, whereas the sixth signal accumulates a count for a period of one hour in some embodiments, the seventh signal accumulates the count for a period of one, two, or three days, or even longer.

An eighth signal in some embodiments is a cumulative failed and successful sign in rate per username per time period t. In some embodiments, this eighth signal is generated per device and per each username used in an attempted login. Thus, in some embodiments let yT = (yT,fail,yT,success) be the bivariate cumulative number of failed and successful login cumulated across each time window up to T, across all devices in network. Let UT be the count of distinct username on a device where yT,success = <NUM>, that is, the user has never successfully authenticated to any device in the network. Thus, in some embodiments, the eighth signal represents a time series of a cumulative count of usernames attempting to login to a device but never successfully doing so. This eighth signal is generated, in at least some embodiments,.

A ninth signal in some embodiments is a username last time successful sign in per device per T. Per each device and per each username, let yT = (T<NUM>,. , Tk) be the k most recent distinct times with at least one successful login. If this does not exist this time series is set to empty.

A tenth signal in some embodiments characterizes IP address abuse per T. Per each IP address, if available, let yT-d be the reputation score of the IP address associated with suspicious activity (brute force, scanning, etc.) over the time period T and last d-days. Otherwise, yT-d is a multivariate time series consisting of the following:.

For many cybersecurity problems, including detecting brute force attacks, previously labeled data is not usually available. Thus, training a supervised learning model is not feasible. This is where unsupervised learning is helpful, enabling one to discover and quantify unknown behaviors when examples are too sparse. Given that several of the signals we consider for modeling RDP brute force attacks are inherently dependent on values observed over time (for example, daily counts of failed logins and counts of inbound connections), time series models are particularly beneficial. Specifically, time series anomaly detection naturally provides a logical framework to quantify uncertainty in modeling temporal changes in data and produce probabilities that then can be ranked and compared to a predetermined threshold to control a desirable false positive rate.

Time series anomaly detection captures the temporal dynamics of signals and accurately quantifies the probability of observing values at any point in time under normal operating conditions. More formally, if we introduce the notation Y(t) to denote the signals taking on values at time t, then we build a model to compute reliable estimates of the probability of Y(t) exceeding observed values given all known and relevant information, represented by P[y(t)], sometimes called an anomaly score. Given a false positive tolerance rate r (e.g.,. <NUM>% or <NUM> out of <NUM> per time), for each time t, values y*(t) satisfying P[y*(t)] < r would be detected as anomalous. Assuming the right signals reflecting the relevant behaviors of the type of attacks are chosen, then the idea is simple in that the lowest anomaly scores occurring per time will be likely associated with the highest likelihood of real threats.

For example, with respect to <FIG> discussed above, the time series of daily count of failed login occurring on the brute force attack day <NUM>/<NUM>/<NUM> had extreme values that would be associated with an empirical probability of about. <NUM>% out of all machine and days with at least <NUM> failed network login for the enterprise.

As discussed earlier, applying anomaly detection to a single or a few signals to detect real attacks can yield too many false positives. To mitigate this, we combined anomaly scores across the eight signals we selected to model RDP brute force attack patterns. The details of our solution are included in the appendix, but in summary, our methodology involves:.

<FIG> shows a daily count of network failed login for a machine with no brute force attack. Parametric discrete location/scale distributions do not generate well-calibrated p-values for rare time series as seen in <FIG>, and thus if used to detect anomalies can result in too many false positives when looking across many machines at high time frequencies. To overcome this challenge of sparse time series of counts of failed login attempts and RDP inbound public connections, some embodiments utilize a mixture model. In some of these embodiments, a zero-inflated two-component negative binomial distribution was utilized.

This formulation is based on thresholding values which are used to select a distribution to compare to the time series. An example of selecting a distribution is provided via Equation <NUM> below. The comparison of multiple distributions to a single time series based on threshold captures the multi-modal and heavy-tailed behavior of operational parameter values in a computationally efficient way. This represents an improvement over other approaches such as those that utilize expectation maximization.

In some embodiments, hierarchical priors are given from empirical estimates of the sample moments across machines using about one month of data.

Let yt be a univariate time series corresponding to one of the signals of brute force.

PDF: <MAT> where <MAT> is the Gamma function<NUM>.

This formulation does not yield a conjugate prior, and thus directly computing probabilities from the posterior predicted density is not done. Instead, anomaly scores are generated based on drawing samples from distributions and then computing the empirical right-tail p-value.

Updating parameters is done based on applying exponential smoothing, a sequential and computationally efficient method capable of weighting more recent data. To avoid skewing of estimates based on outlier data, such as machines under brute force or other attacks, trimming is applied to sample from the distribution at a specified false positive rate, (e.g.. Algorithm <NUM> below demonstrates this.

The smoothing parameters were learned based on maximum likelihood estimation and then fixed during each new sequential update. To induce further uncertainty, bootstrapping across machines is done to produce a histogram of smoothing weights, and samples are drawn in accordance to their frequency. We found that weights concentrated away from <NUM> vary between. <NUM>% to <NUM>% for over <NUM>% of machines, thus leading to slow changes in the parameters. An extension using adaptive forgetting factors will be considered in future work to automatically learn how to correct smoothing real time.

To update model parameters, some embodiments utilize algorithm <NUM>, discussed below. In algorithm <NUM>, for each model parameter θt, distribution of smoothing parameters αθ, and new value yt+ε, the following steps are performed:.

<FIG> shows example ranking of detected RDP inbound brute force attacks. For each machine detected with a probable brute force attack, each instance is assigned TP, FP, or unknown, and each TP is assigned priority based on the severity of the attack. For high-priority TP, a targeted attack notification is sent, in some embodiments, to the associated enterprise with details and recommendations regarding the active brute force attack; otherwise the machine is closely monitored until more information is available.

Some of the disclosed anomaly detection embodiments provide extra capability of sending targeted attack notifications to organizations when attacks are detected. In many cases, these notifications are provided before the brute force attack succeeds or the actor was able to conduct further malicious behavior. Experimental results indicate that the average precision per day, that is, true positive rate, was approximately <NUM>% at a conservative false positive rate of <NUM>%.

Via selection of signals found to be highly associated with RDP brute force attacks, time series anomaly detection is very accurate in identifying real threats. Monitoring suspicious activity in failed login and network connections should be taken seriously, and real time anomaly detection capable of self-updating with the changing dynamics in a network can indeed provide a sustainable solution.

Some embodiments employ hierarchical zero adjusted negative binomial dynamic threshold models to capture the characteristics of the highly discrete count time series. Specifically, as shown in <FIG>, many examples of brute force attacks do not demonstrate failed logins for valid credentials on a local machine, and hence, there are excess zeros that would not be explained by standard probability distributions such as the negative binomial. Also, the variance of non-zero counts can be much larger than the mean, where for example, valid scripts connecting via RDP can generate counts in the twenties or more over several minutes because of an outdated password. Moreover, given a combination of multiple users or scripts connecting to shared machines at the same time, this can generate more extreme counts at higher quantiles resulting in heavier tails as seen in <FIG>.

<FIG> is a diagram showing data flow occurring in one or more of the disclosed embodiments. Data flow <NUM> of <FIG> shows operation of two separate mixture models operating on two separate time series 802A and 802B. Each model includes a plurality to distributions (e.g. 804A-C in mixture model <NUM>, and 804D-F in mixture model <NUM>). Each mixture model also threshold values defining which of the plurality of distributions is applied to time series values (shown as value ranges 805A-C and ranges 805D-F). Each mixture model also includes a threshold mixture component which compares current time series values to the selected distribution. Each of the mixture models generates an indication of anomaly, shown in <FIG> as 812A and 812B. These indications of anomaly are then combined, by a combiner <NUM> to generate a single indication of anomaly or anomaly score <NUM>.

In particular, data flow <NUM> includes a plurality of time series 802A and 802B. Each of the time series 802A and 802B indicates operational parameter values. Each of the time series 802A and 802B is provided to a selection component 803A and 803B respectively. The selection components 803A-B select between a plurality of distributions based on operational parameter values of the respective time series and a range associated with each distribution in the plurality of distributions. For example, <FIG> shows value ranges 805A-C associated with distributions 804A-C respectively. <FIG> also shows ranges 805d-f associated with distributions 804d-f respectively. The selection component 803A selects one of distributions 804A-C for time series 802A based on value ranges 805A-C. Selection component 803B selects one of distributions 804D-F for time series 802B based on ranges 805D-F. The value ranges 805A-C and 805D-F are dynamically updated by some embodiments of this disclosure. For example, some embodiments update the value ranges 805A-C and 805D-F based on values of the time series 802A and 802B respectively. This dynamic update process is discussed further below.

The selected distribution (809A for time series 802A, and distribution 809B for time series 802B) is provided to a respective threshold mixture model 808A-B. Each distribution P[Y | Θ] is modeled, in some embodiments, as a finite mixture of distributions. The distributions of the mixture are obtained from a list of distributions P<NUM>[Y | Θ<NUM>],. Pm[Y | Θm], where each parameter Op is a stochastic process.

Each threshold mixture model 808A-B compares the respective time series to its selected distribution (809A for time series 802A and selected distribution 809B for time series 802B), and outputs an indication of anomaly, shown as 812A-B respectively. The indications of anomaly 812A-B are combined by a combiner <NUM> into a single indication of anomaly or anomaly score <NUM>. In some embodiments, the combiner <NUM> employs Fisher's method, as discussed further below, to combine the indications of anomaly 812A-B. In some embodiments, the single indication of anomaly or anomaly score <NUM> indicates whether a network is experiencing a brute force attack.

While <FIG> shows two time series, two sets of distributions (e.g. 804A-C and 804D-F), two selectors (803A-B), and two threshold mixture models (e.g. 808a-b), some of the disclosed embodiments rely on more than two of each of these components. For example, as discussed above, any number of time series (e.g. input signals), such as three (<NUM>), four(<NUM>), five (<NUM>), ten (<NUM>), fifteen (<NUM>), twenty (<NUM>) or any number may be processed, compared, and combined (e.g. via the combiner <NUM>) in the contemplated embodiments.

<FIG> shows two groups of distributions as 804A-C and 804D-F. <FIG> demonstrates a selection of one of distributions 804A-C to compare to time series 802A, and a second selection of one of distributions 804D-F to compare to time series 802B. In some embodiments, the two groups of distributions 804A-C and 804D-F are equivalent. In some embodiments, the two groups of distributions 804A-C and 804D-F overlap. In some embodiments, the two groups of distributions 804A-C and 804D-F overlap, but are not equivalent. This can also be the case for larger than two groups of distributions, such as three (<NUM>), four (<NUM>), five (<NUM>), ten (<NUM>), twenty (<NUM>), or any number of distribution groups.

<FIG> also shows an updater <NUM>. The updater <NUM> monitors operational parameter values in one or more of the time series 802A or the time series 802B (this is not shown in <FIG>). As illustrated, the updater <NUM> is shown dynamically updating the mixture model for the time series 802A based on the monitored operational parameter values. In particular, the updater <NUM> is shown generating new parameter values Θ for each of the distributions 804A-C included in a particular mixture model. These parameter values are represented in <FIG> as data <NUM> via the symbol Θ. The updater <NUM> also updates threshold values that define boundaries between distributions of the mixture model. For example, the threshold values define boundaries between distributions 804A-C. These boundaries are represented in <FIG> by the different value ranges 805A-C. <FIG> shows updated values for τ via data flow <NUM> defining the value ranges 805A-C. The updater <NUM> also updates two-state homogenous hidden Markov models represented by the symbol "C" in <FIG>, via data flow <NUM>. While <FIG> shows the updater <NUM> being applied only to the top mixture model that is processing time series 802A, in at least some embodiments, the updater is similarly applied to two or more mixture models utilized to detect a brute force attack. For example, the updater <NUM> could also be applied to update the second mixture model that processes the time series 802B, however, this has been omitted from <FIG> to preserve figure clarity. Specific methods utilized by the updater <NUM> are discussed in more detail below.

<FIG> shows an example data flow implemented in one or more of the disclosed embodiments. The data flow <NUM> of <FIG> illustrates how the updater <NUM> processes data in one or more of the disclosed embodiments. <FIG> shows a time series of operational parameter values <NUM> flowing into a historical database <NUM>. Historical time series data <NUM> is then provided to the updater <NUM>. Based on the historical time series data, the updater generates data values <NUM> (τ ), <NUM> (C), and <NUM> (Θ). Data value <NUM> is a parameter at least partially defining a distribution of the historical time series data <NUM>. In some embodiments, multiple parameter values are generated. Data value <NUM> is two state homogenous hidden Markov model, defined by a probability that the time series data (e.g. <NUM>) is greater than the value τ of data value <NUM>. Referring back to <FIG>, data values <NUM>, <NUM>, and <NUM> generated by the updater <NUM> are shown flowing to control the value ranges 805A-C, the distribution 804A-C, and the threshold mixture models 808A-C.

<FIG> shows the τ values in data value <NUM>, two state markov model values in data value <NUM>, and parameter values in data value <NUM> being stored in a mixture model parameters data store <NUM>. The mixture model parameters data store <NUM> is referenced, in some embodiments, by a scoring process <NUM>. The scoring process <NUM> implements at least portions of data flow <NUM>, discussed above with respect to <FIG>.

The updater <NUM> operates, in at least some embodiments, on multiple time series obtained by the disclosed embodiments and multiple corresponding mixture models. One implementation of the updater <NUM> is discussed below with respect to <FIG>.

<FIG> is a flowchart of a process for determining whether a network is experiencing a brute force attack. In some embodiments, one or more of the functions discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). In some embodiments, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>, <NUM>) configure the hardware processing circuitry to perform one or more of the functions discussed below. In some embodiments, process <NUM> discussed below is performed by a network management system or a network security system (e.g. <NUM>).

After start operation <NUM>, process <NUM> moves to operation <NUM>, where a first time series of operational parameter values are received. The first time series of operational parameter values relate to operation of a device attached to a network. For example, as discussed above with respect to <FIG>, operations parameter values of one or more of the network components 102A-F are provided to the network security system <NUM>. In some embodiments, operation <NUM> includes receiving one or more messages indicating the operational parameter values (e.g. any one or more of messages 122A-C). In various embodiments, multiple different time series of different operational parameter values are received. The multiple different time series are received from a single device and/or multiple devices in some embodiments. For example, as discussed above, one or more network component devices provide or transmit time series indicating operational parameter values to a network management system or network security system (e.g. <NUM>). The received time series of operational parameter values indicate one or more of failed login and RDP connections per hour of day and day of week, time delays between one or more failed login and a successful logon, logon type (e.g. Event ID <NUM>), failure reason (e.g. Event ID <NUM>), cumulative count of each distinct username that failed to login without success, a count (and cumulative count) of failed logins, a count (and cumulative count) of RDP external IP addresses (e.g. for inbound RDP connections). These time series of operational parameter values are discussed in more detail above.

In operation <NUM>, the operational parameter values in the first time series are compared to a first parameter value range and a second parameter value range. For example, as discussed above, some of the disclosed embodiments employ a multi-modal distribution (mixture model) approach to analyzing operational parameter values.

For example, a plurality of time series of operational parameter values received in operation <NUM> can be represented via y<NUM>. Each time series is a subset of time series from the same given data generating process P[yi | Oi], where each P[. |i] can be a different probability distribution family. Each distribution P[Y | Θ] is modeled as a finite mixture of distributions specified from a list of distributions P<NUM>[Y|Θl],. Pm[Y|Θm], where each parameter Θp is a stochastic process.

Some of the disclosed embodiments utilize a switching mechanism that is based on learned threshold values of y exceeding specified quantiles. The quantiles are defined, in at least some embodiments, via Equation <NUM> below:.

The dynamic threshold mixture density is defined in some embodiments as follows: <MAT>.

Thus, in operation <NUM>, from a plurality of possible distributions to apply to the time series, one distribution is selected based on a parameter value range of the time series. The parameter value ranges for each of the possible distributions is dynamically adjusted in some embodiments as discussed further below (e.g. with respect to <FIG>). Thus, in operation <NUM>, a first distribution from the plurality of possible distributions is selected based on the comparisons. For example, if the time series values are generally within the first parameter value range, a first distribution is selected, whereas if the time series values are generally within the second parameter value range, a second distribution is selected, at least in some embodiments. If the first distribution is selected, the selected first distribution is the used to determine whether the time series represents anomalous activity, or a degree of anomalous activity present in the time series.

In some embodiments, time series values are generally within the first parameter value range if the values fall within the first parameter value range after outliers or exceptional values are eliminated or not considered. For example, some embodiments may determine a percentage of time series values that fall within each of the possible parameter value ranges, with a range including the highest percentage of values used in selecting an appropriate distribution.

In operation <NUM>, the first time series is compared to the selected distribution. For example, in some embodiments, a percentage of operational parameter values that conform with the selected distribution is determined. In embodiments that process a plurality of time series, values of each time series are compared to a corresponding distribution selected based on the respective time series (e.g. selected distribution 809A is compared to time series 802A and selected distribution 809B is compared to time series 802B in <FIG>).

As discussed above, process <NUM> compares values of one or more time series (e.g. time series 802A and time series 802B) to a corresponding set of parameter value ranges (e.g. value ranges 805A-C and value ranges 805D-F respectively), or a first parameter value range and second parameter value range for that particular time series. Distributions specific for each time series are then selected based on which range the values of the respective time series fall (e.g., as illustrated in <FIG>, a plurality of distributions 804A-C are considered for selection based on corresponding value ranges 805A-C and values of the time series 802A).

In operation <NUM>, an indication of anomaly is determined based on the comparison of the first time series with the selected distribution (e.g., as performed when the threshold mixture model 808A compares time series 802A to selected distribution 809A). Some embodiments determine a percentage of operational parameter values of the first time series that fall outside the selected distribution. The percentage is the indication of anomaly. In other embodiments, a probability of occurrence of each value in the time series is determined based on the selected distribution. These probabilities are then aggregated to determine the indication of anomaly. In some embodiments, the aggregation is performed by multiplying the probability of occurrence of each of the values. The resulting aggregated probability is then normalized in some embodiments.

Note that some embodiments of process <NUM> operate on multiple different time series of operational parameter values, and multiple mixture models. For example, as described above with respect to <FIG>, some embodiments combine a plurality of anomaly indications (e.g. 812A and 812B) generated by a corresponding plurality of mixture models via a combination process (e.g. combiner <NUM>) to generate a combined indicator of anomaly, or in other words, a single indication of anomaly or anomaly score (e.g. <NUM>). Some embodiments utilize Fisher's method to combine the plurality of indications of anomaly into a single anomaly indication. For example, some embodiments operate as follows: Let αT,<NUM>,. ,αT,N be the collection of available scores. These embodiments then compute <MAT>, where χT is the combined indicator of anomaly for purposes of the discussion of process <NUM>. Fisher showed that if each αT,i is independent with a uniform distribution between <NUM> and <NUM>, then χT would have a chi-square distribution with 2N degrees of freedom. The use of Fisher's test applied to anomaly scores produces a scalable solution that yields interpretable probabilities that thus can be controlled to achieve a desired false positive rate.

In operation <NUM>, based on the indication of anomaly, a likelihood of a brute force attack on the network is determined. For example, in some embodiments, if the indication of anomaly is above a predetermined threshold, process <NUM> determines that the network is experiencing a brute force attack. Some embodiments maintain a moving average of indications of anomaly, and determine the network is experiencing a brute force attack if the moving average of anomaly indications transgresses a predetermined threshold.

Upon determination that a brute force attack is likely occurring, additional forensics processing is performed in some embodiments to identify one or more offending computers that are performing the brute force attack. These identified computers are located outside the network (e.g. external devices 104A-C), or in some embodiments, may be internal to the network (e.g. in some cases, malware installed on a computer within the network may provide a "proxy" for a malicious actor to perform a brute force attack on the network).

In operation <NUM>, the brute force attack is mitigated based on the likelihood. Some embodiments mitigate a brute force attack by determining a mitigation action based on the likelihood. A mitigating action can include controlling network access in some embodiments. For example, in some embodiments, if the likelihood is higher than a predetermined threshold, one or more access control policies of a firewall (e.g. firewall <NUM>) or multiple firewalls controlling access to a network (e.g. <NUM>) may be adjusted. For example, more restrictive firewall polices may be applied during a brute force attack (e.g. initiated by the network security system <NUM>). In some embodiments, packets received from devices identified as participating in the brute force attack (e.g. any one or more of external devices 104A-C) are dropped at an access point to the network (e.g. one or more firewalls, such as firewall <NUM>). This is accomplished in some embodiments, by modifying access policies of the firewalls to restrict access to the network by the identified devices. In some embodiments, one or more alerts are generated based on the likelihood. The alerts may be generated, in various embodiments, via text, email, or other messaging technology.

In operation <NUM>, the first parameter value range and the second parameter value range (e.g. value range 805A and value range 805B) are updated based on the operational parameter values of the first time series (e.g. 802A). Updating the first parameter value range and the second parameter value range adjusts at least a boundary between the first parameter value range and second parameter value range. To the extent that a mixture model includes more than two distributions, multiple boundaries are adjusted in operation <NUM>.

For example, given samples y from P[Y| ϕ] (e.g. the first time series), estimation of the parameters ϕ proceeds in two stages, at least in some embodiments. In a first stage, parameters are initialized. In some embodiments, Gibbs sampling is used to initialize the parameters. This computes the conditional likelihood for each parameter under a specified choice of hierarchical priors. The first stage is performed before operation <NUM> is performed in some embodiments. In a second stage, each parameter is updated using generalized exponential smoothing with a selected grid of smoothing weights αϕ for each parameter ϕ with a link function gϕ. Thus, for each parameter ϕ, the link function gϕ is applied to yield an additive term ηt := gϕ[ϕt]. A smoothing weight is then sampled α̃Φ∼αΦ. The additive parameter is updated according to: <MAT> where Mϕ is the central moment corresponding to the parameter Φ.

In some embodiments, the updated parameter is set to, ϕt+ε = gϕ-<NUM>[ηt+ε]. After the parameters of the distribution are updated, an updated posterior distribution ϕt+<NUM>, and for each new sample yt+<NUM>, a right tail pvalue is computed. In some embodiments, the right tail pvalue is computed according to: <MAT> where:.

One embodiment of operation <NUM> is described below with respect to <FIG>. After process <NUM> completes, process <NUM> moves to end operation <NUM>.

<FIG> is a flowchart of a process for estimating parameters of an unknown distribution. In some embodiments of the present disclosure, the unknown distribution is a distribution of events occurring on a monitored network. This unknown distribution is dynamically estimated by estimating parameters of the distribution. Based on this estimation process, the disclosed embodiments are able to determine a probability of individual events occurring within the distribution. A brute force attack is then determined, in at least some embodiments, based on the determined probability.

The unknown distribution is described by a plurality of parameters. Each parameter describes a characteristic of the unknown distribution. For example, the plurality of parameters describe, in various embodiments, two or more of a standard deviation, mean, median of the distribution. In at least some embodiments, the distribution is modeled as a finite mixture of distributions specified from among a list of distributions P<NUM>[Y|Θ<NUM>],. ,Pm[Y|Θm], where each parameter Op is a stochastic process.

Process <NUM> discussed below with respect to <FIG> determines updated distribution parameters, including ranges for selecting a distribution as discussed above. In some embodiments, process <NUM> discussed below is performed by the updater <NUM> discussed above with respect to <FIG>.

In some embodiments, process <NUM> is performed for multiple time series obtained by the disclosed embodiments. For example, with respect to <FIG> discussed above, process <NUM> is performed, in some embodiments, to estimate parameters of distributions for time series 802A, and separately performed to estimate parameters of distributions for time series 802B. A collection of time series is denoted as Y<NUM>,. Thus, each Yi = { yij | j = <NUM>. ni} is a subset of time series from a given data generating process P[Yi |Θi], where each P[. |Θi] can be a different probability distribution family.

In some embodiments, one or more of the functions discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). In some embodiments, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>, <NUM>) configure the hardware processing circuitry to perform one or more of the functions discussed below. In some embodiments, process <NUM> discussed below is performed by a network management system or a network security system (e.g. <NUM>). In some embodiments, one or more of the functions discussed below with respect to <FIG> are performed as part of operation <NUM>, discussed above with respect to <FIG>.

After start operation <NUM>, process <NUM> moves to operation <NUM>, which initializes parameters of the distribution. In some embodiments, the parameters are estimated using Gibbs sampling. For example, some embodiments compute a conditional likelihood for each parameter under a selected set of hierarchical priors for the parameter. The parameter is then initialized based on the conditional likelihood.

In operation <NUM>, a parameter of the plurality of parameters is selected. In operation <NUM>, an additive parameter corresponding to the selected parameter is obtained via a link function. For example, in some embodiments, the additive parameter ηt is obtained via: <MAT> where:
gϕ is a link function of parameter ϕ.

In operation <NUM>, a smoothing weight is sampled. In operation <NUM>, the additive parameter is updated based on the smoothing weight and a central moment corresponding to the parameter. For example, in some embodiments, the additive parameter ηt is updated via : <MAT> where:.

In operation <NUM>, the selected parameter is updated based on an inverse link function of the updated additive parameter. In some embodiments, the selected parameter is updated according to: <MAT> where:.

Operation <NUM> determines if there are additional parameters of the distribution. If so, processing returns to operation <NUM>. Otherwise, processing moves to end block <NUM>.

Note that at least some embodiments of <FIG> function to define or otherwise update values ranges used to select a distribution in a multi-modal model. For example, as discussed above, boundaries delineating a first parameter value range and a second parameter value range are adjusted in some embodiments of process <NUM><NUM> based on values of a time series. A likelihood of a brute force attack is then determined based on the adjusted boundary. As illustrated above with respect to <FIG>, adjusting the boundary between value ranges controls which distribution is compared to the time series at any particular time. The comparison of the time series with the distribution determines how likely the values included in the time series occur within the selected distribution. This likelihood may be combined, in some embodiments, with other likelihoods of values from other time series (e.g. combined via Fisher's method).

<FIG> illustrates a block diagram of an example machine <NUM> upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform. The machine <NUM> may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, a server computer, a database, conference room equipment, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. In various embodiments, machine <NUM> may perform one or more of the processes described above with respect to <FIG> above.

Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms (all referred to hereinafter as "modules").

The machine <NUM> may additionally include a storage device (e.g., drive unit) <NUM>, a signal generation device <NUM> (e.g., a speaker), a network interface device <NUM>, and one or more sensors <NUM>, such as a global positioning system (GPS) sensor, compass, accelerometer, or another sensor.

The term "machine readable medium" may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine <NUM> and that cause the machine <NUM> to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); Solid State Drives (SSD); and CD-ROM and DVD-ROM disks. In some examples, machine readable media may include non-transitory machine readable media. In some examples, machine readable media may include machine readable media that is not a transitory propagating signal.

The instructions <NUM> may further be transmitted or received over a communications network <NUM> using a transmission medium via the network interface device <NUM>. The machine <NUM> may communicate with one or more other machines utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) <NUM> family of standards known as Wi-Fi®, IEEE <NUM> family of standards known as WiMax®), IEEE <NUM>. <NUM> family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device <NUM> may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network <NUM>. In an example, the network interface device <NUM> may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. In some examples, the network interface device <NUM> may wirelessly communicate using Multiple User MIMO techniques.

Claim 1:
A method performed by hardware processing circuitry, comprising:
obtaining a first time series of operational parameter values (802A, 802B) of a device (102A, 102B, 102C, 102D, 102E, 102F) attached to a network (<NUM>);
comparing the operational parameter values of the first time series to a first parameter value range (805A, 805B, 805C) and a second parameter value range (805A, 805B, 805C), wherein the first parameter value range corresponds to a first distribution in a mixture model and the second parameter value range corresponds to a second distribution in the mixture model, and the first and second parameter value ranges are delineated by a boundary;
determining, based on the comparing, that the operational parameter values of the first time series are within the first parameter value range (805A, 805B, 805C);
based on the determining, selecting, from a plurality of distributions in the mixture model, the first distribution (804A, 804B, 804C);
determining, a first probability at which values in the first time series occur in the selected distribution;
determining, based on the first probability, a likelihood of a brute force attack on the network;
based on the first time series, adjusting the boundary between the first parameter value range and the second parameter value range;
determining, based on the adjusted boundary, a second likelihood of a brute force attack; and
performing, based on the likelihood, a mitigating action.