Detecting anomalous accounts using event logs

BACKGROUND

0001Event logs provide a nearly complete history of activities within an information technology (IT) environment. Event logs can include logon times, names of created processes, directory paths of processes, and accounts used to connect to a plurality of host machines.

SUMMARY

0002The following presents a simplified summary of the innovation in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview of the claimed subject matter. It is intended to neither identify key elements of the claimed subject matter nor delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts of the claimed subject matter in a simplified form as a prelude to the more detailed description that is presented later.

0003An implementation provides a system for anomalous process detection. The system includes an event log module configured to receive a plurality of event logs. The system also includes a filter module configured to filter the plurality of event logs based on detected process creations. The system can also further include a receiving module configured to receive a directory path and process name for each detected process creation. The system can also include a conversion module configured to convert each directory path to a sequence of integers based on a character count for each sub-directory of the directory path. The system can further include a detection module configured to detect an anomalous process based on a threshold number of matching character counts and matching process names. The system can also further include a display module can also further be configured to display the detected anomalous process.

0004Another implementation provides for a system for detecting anomalous accounts. The system includes a receiving module to receive a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The system can also include a module to generate a baseline based on the event logs for the predetermined window of time. The system can also include a collector module configured to collect daily logon events after the predetermined time and compare the daily logon events to the baseline. The system can also include a detection module configured to detect an anomalous account based on a difference of logon events of the anomalous account from the baseline. The system can also include an update module configured to generate a new baseline by removing older event logs from the baseline based on a predetermined adjustment time and adding new event logs from non-anomalous accounts based on the predetermined adjustment time and comparing daily logon events to the new baseline. The system can also include a display module configured to display the detected anomalous account.

0005Another implementation provides for a system for generating bubble plot graphs. The system includes a receiving module configured to receive processed event logs including logons of a logon account at a plurality of machines for a predetermined time. The system can also include an aggregator module configured to aggregate the processed event logs for the logon account to generate a total number of logons, and a first and a last logon time for the logon account. The system can also include a graphing module configured to generate a bubble plot graph including a bubble based on the total number of logons and a difference between the first and the last logon time for the logon account and a size of the bubble indicating an inverse difference between the first logon and the last logon for the logon account. The system can also include a display module configured to display the bubble plot graph.

0006Another implementation provides method for anomalous process detection. The method can include receiving, via a processor, a plurality of event logs. The method can also include filtering, via the processor, the plurality of event logs to detect process creations. The method can further include receiving, via the processor, a directory path and process name for each detected process creation. The method can also further include converting, via the processor, each directory path to a sequence of integers based on character count. The method can also include detecting, via the processor, an anomalous process based on a threshold number of matching character counts. The method can also further include displaying, via the processor, the detected anomalous process.

0007Another implementation provides for a method for detecting anomalous accounts. The method can include receiving, via a processor, a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The method can also include generating, via the processor, a baseline based on the event logs for the predetermined window of time. The method can further include collecting, via the processor, daily logon events after the predetermined time and comparing the daily logon events to the baseline. The method can also further include detecting, via the processor, an anomalous account based on a difference of logon events of the anomalous account from the baseline. The method can also include displaying, via the processor, the detected anomalous account.

0008Another implementation provides for a method for generating a bubble plot graph. The method includes receiving, via a processor, processed event logs including logons of a logon account at a plurality of machines for a predetermined time. The method can also include aggregating, via the processor, the processed event logs for the logon account to generate a total number of logons, and a first and a last logon time for the logon account. The method can also further include generating, via the processor, a bubble plot graph based on the total number of logons and a difference between a first logon time and a last logon time for the logon account. The method can also include displaying, via the processor, the bubble plot graph.

0009The following description and the annexed drawings set forth in detail certain illustrative aspects of the claimed subject matter. These aspects are indicative, however, of a few of the various ways in which the principles of the innovation may be employed and the claimed subject matter is intended to include all such aspects and their equivalents. Other advantages and novel features of the claimed subject matter will become apparent from the following detailed description of the innovation when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an example system for detecting anomalous processes;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an example system for detecting anomalous accounts;

<figref idref="DRAWINGS">FIG. 3</figref> is an example bubble plot graph according to techniques described herein;

<figref idref="DRAWINGS">FIG. 4</figref> shows a process flow diagram of an example method for detecting anomalous processes;

<figref idref="DRAWINGS">FIG. 5</figref> shows a process flow diagram of an example method for detecting anomalous accounts;

<figref idref="DRAWINGS">FIG. 6</figref> shows a process flow diagram of an example method for generating a bubble plot graph of anomalous logons;

<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram of an example operating environment configured for implementing various aspects of the techniques described herein; and

<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram of an example computer-readable storage medium that can be used to generate a bubble plot graph of anomalous logons.

DETAILED DESCRIPTION

0018Attacks and exposures of vulnerabilities in information technology networks are substantial risks to a corporation's intellectual property and can affect the ability of a corporate enterprise to operate effectively. Event logs that are typically collected daily can be used to view a near complete history of activities within an information technology network, where evidence of attacks and malicious behavior is generally found. However, the volume, variety, and velocity of the event log data limits detection of such activities using conventional analysis and data storage.

0019This disclosure describes techniques to detect anomalous processes and accounts via processing of a plurality of event logs. In some examples, event logs can include information about process creations, logons, and accounts performing process creations or logons, or the like. A process creation, as used herein, refers to a type of event including information about an instance of a computer program that is being executed. For example, a process creation event can include a security ID of the account, an account logon name, an account domain/computer name, and a logon ID, and can sometimes be referred to as a 4688 Event. A logon, as used herein, refers to a type of event recording the attempted authentication of an account onto a machine. For example, a logon may include a security ID, an account logon name, an account domain/computer name, and a logon ID, and can sometimes be referred to as a 4624 Event. In some examples, anomalous processes can be detected by collecting event logs and comparing character counts of directory paths and process names.

0020In some examples, a baseline can be generated from a window of time of logon events for a plurality of accounts. For example, the window of time can be weekly, daily, hourly, etc. Anomalous accounts can be detected by comparing logon events for each account accessing a list of machines within the window of time against the baseline. In some techniques, the baseline can be updated at predetermined adjustment times based on recent event logs from non-anomalous accounts detected from the daily logon events. The daily logon events can then be compared against the new baseline.

0021In some examples, logon events from event logs can be aggregated for a predetermined window of time and a bubble plot graph created to visualize account behavior and emphasize anomalous accounts. Accounts can be represented by bubbles on a graph depicting a total number of logons to any host versus a most recent time of a logon to any machine for the account. In addition, the size of the bubbles can indicate a difference between a first logon time and a last logon time inversely.

0022The techniques thus enable real-time detection of anomalous account and activities in a large volume of logon data that is otherwise not able to be comprehensively analyzed by users. For example, the event logs can be terabytes in size. Moreover, the techniques include analyzing existing data that is routinely collected. Thus, the techniques do not collect additional data. The techniques also reduce the amount of processing required to detect anomalous behavior and associated accounts. For example, compression can be used to minimize file size. Moreover, the increased efficiency of the detection can further save computer resources by enabling a user to find anomalous behavior or accounts using fewer resources. In addition, the techniques also enable earlier detection of suspicious activities. For example, analysis and visualization of event logs provided herein can improve system security by enabling users to efficiently analyze potential threats in a large amount of data. These techniques are described in more detail herein.

0023As a preliminary matter, some of the figures describe concepts in the context of one or more structural components, variously referred to as functionality, modules, features, elements, or the like. The various components shown in the figures can be implemented in any manner, such as software, hardware, firmware, or combinations thereof. In some cases, various components shown in the figures may reflect the use of corresponding components in an actual implementation. In other cases, any single component illustrated in the figures may be implemented by a number of actual components. The depiction of any two or more separate components in the figures may reflect different functions performed by a single actual component. <figref idref="DRAWINGS">FIG. 7</figref>, discussed below, provides details regarding one system that may be used to implement the functions shown in the figures.

0024Other figures describe the concepts in flowchart form. In this form, certain operations are described as constituting distinct blocks performed in a certain order. Such implementations are exemplary and non-limiting. Certain blocks described herein can be grouped together and performed in a single operation, certain blocks can be broken apart into multiple component blocks, and certain blocks can be performed in an order that differs from that which is illustrated herein, including a parallel manner of performing the blocks. The blocks shown in the flowcharts can be implemented by software, hardware, firmware, manual processing, or the like. As used herein, hardware may include computer systems, discrete logic components, such as application specific integrated circuits (ASICs), or the like.

0025As to terminology, the phrase “configured to” encompasses any way that any kind of functionality can be constructed to perform an identified operation. The functionality can be configured to perform an operation using, for instance, software, hardware, firmware, or the like. The term, “logic” encompasses any functionality for performing a task. For instance, each operation illustrated in the flowcharts corresponds to logic for performing that operation. An operation can be performed using, software, hardware, firmware, or the like. The terms, “component,” “system,” and the like may refer to computer-related entities, hardware, and software in execution, firmware, or combination thereof. A component may be a process running on a processor, an object, an executable, a program, a function, a subroutine, a computer, or a combination of software and hardware. The term, “processor,” may refer to a hardware component, such as a processing unit of a computer system.

0026Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computing device to implement the disclosed subject matter. The term, “article of manufacture,” as used herein is intended to encompass a computer program accessible from any computer-readable storage device or media. Computer-readable storage media include magnetic storage devices, e.g., hard disk, floppy disk, magnetic strips, optical disk, compact disk (CD), digital versatile disk (DVD), smart cards, flash memory devices, among others. Moreover, computer-readable storage media does not include communication media such as transmission media for wireless signals. In contrast, computer-readable media, i.e., not storage media, may include communication media such as transmission media for wireless signals.

0027<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an example system for detecting anomalous processes. The example system of <figref idref="DRAWINGS">FIG. 1</figref> is referred to generally by the reference number <b>100</b>.

0028In the example system <b>100</b>, an anomaly detection analytics module <b>102</b> is connected to a store <b>104</b> in which anomalous process creations can be stored as indicated by an arrow <b>106</b>. The store <b>104</b> with anomalous process creations is connected to a filtering and auto-classification module <b>108</b> as indicated by an arrow <b>110</b>. The filtering and auto-classification module <b>108</b> can filter out known benign processes and automatically classify anomalies based on patterns of processes. For example, the patterns of processes may be associated with grayware. Grayware, as used, herein, refers to processes that behave in a manner that is annoying or undesirable, and yet less serious or troublesome than malware. The filtering and classification module <b>108</b> is connected to a store <b>112</b> containing anomalies remaining after filtering as shown by arrow <b>114</b>. The store <b>112</b> containing remaining anomalies can also be accessible by a client <b>116</b> that can receive and send feedback <b>118</b> to the filtering and auto-classification module <b>108</b>. As shown on the left side of <figref idref="DRAWINGS">FIG. 1</figref>, the anomaly detection analytics module <b>102</b> can include a stored daily pull of events <b>119</b>. The anomaly detection analytics module <b>102</b> can also include a full directory path <b>120</b> for each instance of an event <b>122</b> as indicated by an arrow. The full directory path <b>120</b> can be processed to obtain a directory path <b>124</b> and process name <b>126</b> as indicated by arrows <b>128</b> and <b>130</b>. Any known usernames in the path can be ignored. For example, a full directory path and name <b>120</b> of C:\Users\[alias]\AppData\Local\c41af15c8fa9\c41af15c8fa9.exe can be processed to obtain a directly path <b>124</b> of C:\Users\AppData\Local\c41af15c8fa9\ and a process name <b>126</b> of c41af15c8fa9.exe. The directory path <b>124</b> can be processed to obtain a character count <b>132</b> of each sub-directory name of the directory path <b>124</b> as indicated by an arrow <b>134</b>. For example, the path C:\Users\AppData\Local\c41af15c8fa9\ can have all characters between slashes replaced with a character count of (2, 5, 7, 5, 12). The character count <b>132</b> and process name <b>126</b> are included in a comparison <b>136</b> to be made against the daily pull of events <b>119</b> as indicated by an arrow <b>138</b>.

0029In the example system <b>100</b>, the anomaly detection analytics module <b>102</b> can receive a daily pull of events <b>119</b> in a storage. For example, the daily pull of events <b>119</b> in the storage <b>119</b> can include thousands to billions of events collected each day. The events <b>119</b> can include process creation events, sometimes referred to as instances of Event 4688. For example, process creation events can document each program that is executed, the account and machine that ran the program and the process that started this process. In some examples, the data size of the collected daily pull of events <b>119</b> can be more than ten terabytes of raw data per day. The event logs can be pushed to a plurality of event collector systems and transferred to folders that are shared with a plurality of example processing systems <b>100</b>. An example system <b>100</b> can convert the event logs from a native format such as the Extensible Markup Language (XML) format to a common structured table format. The event logs can then be stored in a storage of a daily pull of events <b>119</b>. In some examples, the processed event logs can be compressed and inserted into the storage. For example, the event logs can be compressed using the Optimized Row Columnar (ORC) format. In some examples, the storage can use an HDFS format. In addition, the example system <b>100</b> can use error-handling and re-run procedures to prevent loss or corruption of data. In some examples, a system monitor application, linked to the example system <b>100</b>, can oversee the health and maintenance of infrastructure and provide status updates on heartbeats of operating system services, file tracking information, and system statuses.

0030As shown in <figref idref="DRAWINGS">FIG. 1</figref>, anomaly detection analytics module <b>102</b> can process the event logs recording new instances of events <b>122</b>, for each day for the detection of harmful activities such as malware installations. For example, the event instances may include evidence of such harmful activities. In some examples, the filtering and auto-classification module <b>108</b> can filter the process creations based on specific sub-directory paths where malware are likely to be found. For example, the directories can include common sub-directories for a particular operating system. In some examples, the anomaly detection analytics module <b>102</b> and the filtering and auto-classification module <b>108</b> can label processes with rare-occurring names or directory paths, defined as occurring fewer than a threshold number of times across all hosts in an IT environment, as potentially associated to malware installations. In some examples, the filtering and auto-classification module <b>108</b> can ignore user-identified sub-directories. The anomaly detection analytics module <b>102</b> can also apply to other events that record directory information, including a new service installation event, sometimes referred to as Event 7045. For example, the new service installation event can record service names and directory information, and may include evidence of malware installations. In some examples, the anomaly detection analytics module <b>102</b> can determine the rarity of directory paths by comparing sequences of character counts <b>132</b> of the folder names <b>124</b>, instead of the character strings of the folder names <b>124</b>. For example, the directory path <b>120</b> from a process creation event can be converted to a sequence of integers <b>132</b>, each sequence of integers <b>132</b> denoting the number of characters for the corresponding sub-directory name. For example, the directory path <b>124</b> “C:\Windows\System32\Microsoft\” can be represented by the sequence of integers <b>132</b> of (2, 7, 8, 9,). The “C:” can be represented by the integer 2, “Windows” can be represented by the integer 7, “System32” can be represented by the integer 8, and “Microsoft” can be represented by the integer 9. In some examples, user names can be removed from the directory paths. In some examples, the anomaly detection analytics module <b>102</b> can label events with sequences of integers <b>132</b> occurring fewer than a threshold number of times as potentially malicious. For example, similar character counts can be compared against a threshold number to determine whether the processes associated with the directory paths may be anomalous. For example, a process with a directory path that is unique and therefore has a character count that appears less than a threshold number of times can be detected as anomalous. In some examples, process names can be compared <b>138</b> and less common names can be detected as anomalous. In some examples, known benign processes can be filtered out before the comparison <b>138</b>. Feedback <b>118</b> can be received based on initially detected anomalous processes to filter out additional processes that may be benign from future detection. Thus, the present techniques can also address a problem of detecting an excess number of false positives having unique sub-directory paths with GUIDs since sub-directory GUIDs have the same character lengths. As a result, they need not be rare with respect to character counts and need not be falsely detected as anomalous.

0031Still referring to <figref idref="DRAWINGS">FIG. 1</figref>, once anomaly detection analytics module <b>102</b> labels events as potentially linked to malware, additional querying logic of the filtering and auto-classification module <b>108</b> can be applied to filter known rare yet benign process creations and auto-classify patterns of processes linked with grayware or adware. In some examples, after processing the events, the filtering and auto-classification logic <b>108</b> can send the remaining anomalies <b>112</b> to be displayed to security experts for investigation. For example, the remaining anomalies <b>112</b> can be displayed at a client <b>116</b>. In return, the filtering and auto-classification logic <b>108</b> can receive false positive instances and use the false positive instances to update.

0032The diagram of <figref idref="DRAWINGS">FIG. 1</figref> is not intended to indicate that the example system <b>100</b> is to include all of the components shown in <figref idref="DRAWINGS">FIG. 1</figref>. Rather, the example system <b>100</b> can include fewer or additional components not illustrated in <figref idref="DRAWINGS">FIG. 1</figref> (e.g., additional modules, clients <b>116</b>, etc.).

0033<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an example system for detecting anomalous accounts. The example system <b>200</b> can be implemented using the computer <b>702</b> as described below.

0034The example system <b>200</b> can include an event store <b>202</b> that is communicatively connected to a visualization and detection logic <b>204</b> for visualizing and detecting anomalous accounts. The event store <b>202</b> can also be communicatively connected to a daily detection logic <b>206</b> for daily detection of anomalous events against a baseline. At block <b>208</b>, the visualization and detection logic <b>204</b> for visualizing and detecting anomalous accounts aggregates an event history for a predetermined amount of time. At block <b>210</b>, the visualization and detection logic <b>204</b> creates a bubble plot graph from the aggregated logon history as indicated by an arrow <b>212</b>. At block <b>216</b>, the daily detection logic <b>206</b> builds an initial baseline. At block <b>218</b>, the daily detection logic <b>206</b> performs daily detection by comparing logon accounts to the initial baseline as indicated by arrow <b>220</b>. The daily detection logic <b>206</b> can also detect one or more daily anomalies <b>222</b> as indicated by an arrow <b>224</b>. At block <b>226</b>, the daily detection logic <b>206</b> creates a new baseline that includes a new month <b>228</b> of data. <figref idref="DRAWINGS">FIG. 2</figref> also shows a baseline start marker <b>230</b> for the initial baseline <b>216</b> and a baseline end marker <b>232</b> for the initial baseline <b>216</b>. An updated baseline start marker <b>234</b> and updated baseline end marker <b>236</b> is also shown for the updated baseline block <b>226</b>.

0035In the example system <b>200</b> of <figref idref="DRAWINGS">FIG. 2</figref>, the event store <b>202</b> can include a plurality of events. For example, the events can include logon events to a list of machines. The list of machines can include information technology machines such as Domain Controller and Certificate Authority servers. The event store <b>202</b> can be accessed by a visualization and detection logic <b>204</b> for visualizing and detecting anomalous accounts. At block <b>208</b>, the visualization and detection logic <b>204</b> aggregates a logon history for a period of time. For example, the predetermined amount of time can be two months or six months. In some examples, for a given list of machines, logons from any accounts to these host machines are collected for a period of time and stored in the event store <b>202</b>. For example, a given list may contain those host machines with names containing “-dc-”, which indicates that the host machines are Domain Controller servers. The block <b>208</b> can then aggregate the events to provide, for each account, the total number of logons and a most recent and earliest time of logon across all machines from the list. At block <b>210</b>, the visualization and detection logic <b>204</b> creates a bubble plot graph from the aggregated logon history as indicated by an arrow <b>212</b>. For example, the bubble plot graph may resemble the example bubble plot graph of <figref idref="DRAWINGS">FIG. 3</figref> below.

0036In some examples, the event store <b>202</b> can be accessed by a daily detection logic <b>206</b> that can store events recorded over a period of time as a baseline <b>216</b>. For example, the baseline <b>216</b> can include all logons to machines from any accounts recorded over a six month period. In <figref idref="DRAWINGS">FIG. 2</figref>, the period for baseline <b>216</b> begins at a baseline start time <b>230</b> and ends at a baseline end time <b>232</b>. At block <b>218</b>, the daily detection logic <b>206</b> collects logon events each day and compares the daily logon events to the baseline <b>216</b>. The daily detection logic <b>206</b> can label any account that has not been detected logging onto a machine in the baseline as anomalous. At block <b>224</b>, the daily detection logic <b>206</b> adds anomalous accounts to a store of daily anomalies <b>222</b>. After a predetermined amount of time, the daily detection logic <b>206</b> can update the baseline <b>216</b> by removing the older events and including all logon events not labeled as anomalous of the most current time period. For example, given a predetermined amount of time of six months, events from a first month in six months can be removed and logon events from a recent month of collection can be added. Thus, a new baseline <b>226</b> can include all captured events from the updated baseline start time <b>234</b> to the updated baseline end time <b>236</b>. Similar to the anomaly detection analytics module <b>102</b> in example system <b>100</b> above, which is general enough for any rare directory and process name detection, the baseline <b>216</b> can also be based on other types of events. For example, the events can include events that are triggered when members are added to global and/or local groups of a machine.

0037Thus, the present techniques save resources such as processor power and bandwidth that may have otherwise been spent on testing false positives. Furthermore, the techniques reduce the risk of undetected malicious behavior by providing a manageable number of daily anomalies for review. In addition, the techniques provide the ability to easily visualize anomalous accounts and suspicious logon activity for wide audiences.

0038The diagram of <figref idref="DRAWINGS">FIG. 2</figref> is not intended to indicate that the example system <b>200</b> is to include all of the components shown in <figref idref="DRAWINGS">FIG. 2</figref>. Rather, the example system <b>200</b> can include fewer or additional components not illustrated in <figref idref="DRAWINGS">FIG. 2</figref> (e.g., additional events <b>202</b>, logic, blocks, etc.).

0039<figref idref="DRAWINGS">FIG. 3</figref> is an example bubble plot graph according to techniques described herein. The example bubble plot graph is referred to generally by the reference number <b>300</b>.

0040In the example bubble plot graph <b>300</b>, the vertical axis <b>302</b> represents a total number of logons for an account to any host from a list of host machines. The horizontal axis <b>304</b> represents the most recent time of an account logon to any machine from the list of host machines. Two accounts <b>306</b> and <b>308</b> are indicated by bubbles. The account <b>306</b> has a size <b>310</b> inversely indicating the difference between the time of the most recent logon and the time of the earliest logon for the account. The size <b>310</b> of the representative bubble for the account <b>306</b> is larger than the size of bubble for the account <b>308</b>, which indicates that account <b>306</b> has less time difference between a most recent logon and earliest logon for the account. Therefore, account <b>306</b> is more likely to be anomalous than account <b>308</b> because the logon history of account <b>306</b> resides in a smaller time frame.

0041In the example bubble plot graph <b>300</b>, the total logons <b>302</b> for each account is plotted against the most recent logon <b>304</b>. In addition, the size <b>310</b> of each bubble reflects a third dimension representing the inverse difference between the time of most recent logon for a particular account and the time of the earliest logon for the account. For example, an account that has a larger difference between the most recent logon and earliest logon can have a smaller bubble. Bubble size <b>310</b> can reflect that accounts with longer histories of use are less anomalous than accounts with less history. In addition, an account with a lower total number of logons to any host from the list is more likely to be anomalous. As indicated by horizontal axis <b>304</b>, accounts with more recent logon times are also considered less anomalous. Thus, account <b>306</b> is more anomalous by all three measures: account <b>306</b> has a lower total number of logons, a less recent logon time, and a smaller difference between the most recent logon time and the earliest logon time. Account <b>308</b>, on the other hand, displays less anomaly by all three measures. Account <b>308</b> has a higher total number of logons <b>302</b> and a more recent time of log. Moreover, account <b>308</b> is represented by a smaller bubble indicating a larger time difference between a last logon time associated with account <b>308</b> and an earliest logon time associated with account <b>308</b>. Since benign accounts for IT servers generally exhibit consistent logon behavior, accounts showing high levels of abnormality may have a low number of logons, a most recent time of logon in the far past indicating a long period of account inactivity, and small time differences between most recent and earliest logon. Thus, anomalous accounts can be concentrated in the bottom-left corner of the plot and have larger bubble sizes as compared to benign accounts. In some examples, threshold selections can be made to label accounts as anomalous and thus to be investigated further by security analysts. For example, the thresholds can be based on number of logons and most recent time of logon. Thus, accounts that are anomalous will be larger and/or grouped in the bottom left side of the bubble plot graph, improving the ability of user to detect anomalous accounts and provide feedback as to whether the accounts and/or activities are benign or malicious. Accounts demonstrating abnormalities can be thus easier to detect using the present techniques.

0042The graph of <figref idref="DRAWINGS">FIG. 3</figref> is not intended to indicate that the example bubble plot graph <b>300</b> is to include all of the components shown in <figref idref="DRAWINGS">FIG. 3</figref>. Rather, the example bubble plot graph <b>300</b> can include fewer or additional components not illustrated in <figref idref="DRAWINGS">FIG. 3</figref> (e.g., additional accounts, dimensions, etc.).

0043<figref idref="DRAWINGS">FIG. 4</figref> shows a process flow diagram of an example method for detecting anomalous processes. The method is generally referred to by the reference number <b>400</b> and can be implemented using the computer <b>702</b> as described below. The example method <b>400</b> can be performed by the anomaly detection analytics module <b>102</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0044At block <b>402</b>, a plurality of event logs is received. For example, event logs can be pulled for daily for processing. The event logs can include a plurality of process creations with the corresponding directory path and process name for each process creation. The event logs can be saved to storage. In some examples, the event logs are processed and stored as a common structured table format. In some examples, the event logs can be compressed using an ORC format.

0045At block <b>404</b>, the plurality of event logs are filtered based on detected process creations. For example, the process creations can be instances of Event 4688. In some examples, the process creations can be filtered based on specific sub-directory paths where malware are likely to be found. For example, the directories can include common sub-directories for a particular operating system. In some examples, processes with rare-occurring names or directory paths can be labeled as potentially associated with malware installations. In some examples, user-identified sub-directories can be ignored during the filtering. For example, the user-identified sub-directories can be received from the feedback in block <b>414</b> below. In some examples, patterns of processes linked with malware or grayware can automatically classified as anomalous. For example, grayware processes can include spyware or adware processes. In some examples, the event logs can be filtered to include events such as service installations and additions or removals of members from groups. For example, the event logs can include Event Log 4697 indicating a service was installed on a system.

0046At block <b>406</b>, a directory path and process name is received for each detected process creation. For example, the directory path can be strings of sub-directories separated by slash symbols. In some examples, strings including user names can be removed from the directory paths. For example, the path “C:/root/Alice/directory” may be shortened to “C:/root/directory.” In some examples, a directory path and process name can be received for each detected service installation. In some examples, a directory path and process names are detected for each detected service installation.

0047At block <b>408</b>, each directory path is converted to a sequence of integers based on character count for each sub-directory of the directory path. The directory path <b>120</b> from each process creation event can be converted to a sequence of integers <b>132</b>, each sequence of integers <b>132</b> denoting the number of characters for the corresponding sub-directory name. For example, the directory path “C:/root/example/directory/” can be represented as “(2, 4, 7, 9)”.

0048At block <b>410</b>, an anomalous process is detected based on threshold number of matching character counts or matching process names. In some examples, anomalous directory paths can be determined by comparing sequences of character counts of the folder names, instead of the character strings of the folder names. For example, if the sequence (2, 4, 7, 9) only occurs less than a threshold amount of times, then the corresponding process with that directory path can be detected as anomalous. In some examples, events with directory paths having sequences of integers, or with process names, occurring n or fewer times overall can be labeled as anomalous, wherein n is a threshold number of similar instances. In some examples, the names of the processes are compared against a list of process names. For example, the list can include process names that are system processes. The detected process names can be compared against the list of process names and also be used to detect anomalous processes. For example, if a process creation has an anomalous directory path sequence and a process name that is similar or identical to a list of system processes, then such process creation can be detected as anomalous. In some examples, process names that are similar to the list of system processes and in the same directory paths as the similar system processes can be detected as anomalous. Service installations into similar directory paths can also be detected as anomalous. Thus, processes and service installations additions that could be easily overlooked by human users due to the similarity of process name can be detected as anomalous and therefore subject to further review.

0049At block <b>412</b>, the detected anomalous process is displayed. For example, the anomalous process can be displayed in a list of directories for a security expert to further investigate. The security expert may determine whether the anomalous process is malicious or not. In some examples, anomalous service installations can also be displayed.

0050At block <b>414</b>, feedback is received as input to use in filtering the plurality of activity logs. For example, false positives can be identified by security experts and received by the filtering and auto-classification module <b>108</b>. The filtering and auto-classification module <b>108</b> can then update its list of benign processes and filter such processes out at an early stage in later analysis. For example, process creations with a particular combination of character count sequence and process name can be excluded from future anomaly analysis by the filtering and auto-classification module <b>108</b>. In some examples, service installations that were detected as anomalous can also be added to the filter to be excluded from future anomaly analysis and detection.

0051This process flow diagram is not intended to indicate that the blocks of the method <b>400</b> are to be executed in any particular order, or that all of the blocks are to be included in every case. Further, any number of additional blocks not shown may be included within the method <b>400</b>, depending on the details of the specific implementation.

0052<figref idref="DRAWINGS">FIG. 5</figref> shows a process flow diagram of an example method for detecting anomalous accounts. The example method is generally referred to by the reference number <b>500</b> and can be implemented using computer <b>702</b> as described below. The example method <b>500</b> can be performed by the example system <b>200</b>.

0053At block <b>502</b>, a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time is received. For example, the predetermined window of time can be six months. In some examples, the event logs can include additions of new members to groups. For example, the event logs can include instances of Event Log 4728, wherein a member is added to a security-enabled global group.

0054At block <b>504</b>, a baseline is generated based on the event logs for the predetermined window of time. For example, the baseline can include all accounts in the predetermined window of time that were not detected as anomalous or determined to be false positives. In some examples, the baseline can include membership additions that were not detected as anomalous or determined to be safe. The baseline can represent normal account behavior for the predetermined window of time. For example, the behavior of an individual account can be used to generate a baseline for that account. An account may, for example, only logon to one server. In some examples, the behavior of a plurality of accounts can be used to generate the baseline. For example, a server that is rarely logged onto may be left out of the baseline. In some examples, security-sensitive servers can also be left out of the baseline. Thus, any logons to security-sensitive servers can be detected as anomalous.

0055At block <b>506</b>, daily logon events after the predetermined time are collected and compared to the baseline. For example, the account ID and server for each logon event can be extracted and compared to the account IDs and servers in the generated baseline. In some examples, membership additions after the predetermined time can also be collected and compared to the baseline.

0056At block <b>508</b>, anomalous accounts can be detected based on differences of the logon events of the anomalous accounts from the baseline. For example, if an account detected in a daily pull of events is not present in the baseline, then the account can be labeled anomalous. If an account from a daily pull of events is found in the baseline, then the account can be labeled benign. In some examples, if an account logs on to a server that is outside its baseline of normal logons, then the logon can be detected as anomalous. In some examples, logons to servers that are rarely logged on to can be detected as anomalous. In some examples, new membership additions that differ from baseline membership additions can be detected as anomalous.

0057At block <b>510</b>, a new baseline is generated by removing older event logs from baseline at a predetermined adjustment time and adding new event logs from non-anomalous accounts at the predetermined adjustment time. For example, the predetermined adjustment time can be a month. Given a predetermined window of time of six months, in some examples, the first month of event logs can be removed and the newest month of recorded event logs added to the baseline. Thus, the new baseline is based on the latest six months of event logs. In some examples, the predetermined window of time can be a moving window that can be readjusted every hour, day, or month. In this manner, the activities that are considered normal behavior for an account may change over time and thus adapt to any changes in the environment.

0058At block <b>512</b>, the detected anomalous accounts are displayed. For example, the anomalous accounts can be displayed at one or more client machines for further analysis. In some examples, the anomalous accounts can be displayed in a bubble graph according to the techniques described in <figref idref="DRAWINGS">FIG. 6</figref> below. In some examples, anomalous membership additions can also be displayed.

0059This process flow diagram is not intended to indicate that the blocks of the method <b>500</b> are to be executed in any particular order, or that all of the blocks are to be included in every case. Further, any number of additional blocks not shown may be included within the method <b>500</b>, depending on the details of the specific implementation.

0060<figref idref="DRAWINGS">FIG. 6</figref> shows a process flow diagram of an example method for generating a bubble plot graph of anomalous logons. The method is generally referred to by the reference number <b>600</b> and can be implemented using computer <b>702</b> as described below. The example method <b>600</b> can be performed by the example system <b>200</b> to generate a bubble plot graph, an example of which is shown in <figref idref="DRAWINGS">FIG. 3</figref>.

0061At block <b>602</b>, processed event logs including logons of a logon account at a plurality of machines for a predetermined period of time are received. For example, the period of time can be six months.

0062At block <b>604</b>, the processed event logs for each logon account is aggregated to generate a total number of logons, and first and last logon time for each logon account. For example, for a given account, the total number of logons can be aggregated for the predetermined period of time. The first and last logon time for the account within the predetermined period of time can also be determined for the predetermined period of time. In some examples, a difference between the last logon time and the first logon time can also be calculated.

0063At block <b>606</b>, a bubble plot graph is generated based on the total number of logons and the difference between the first and last logon time for each logon account. For example, the total number of logons can be represented on a vertical axis as shown in <figref idref="DRAWINGS">FIG. 3</figref> above. As regular accounts exhibit habitual patterns, accounts with less logons can be treated with more suspicion. In some examples, the most recent time of a logon to any machine can be represented on the horizontal axis. Accounts that have not logged into any machine in a long time can be treated with more suspicion. In some examples, the difference in time between the first and last logon time for each account can be represented inversely by the bubble size of the represented account. More precisely, the bubble size can be defined as the mathematical inverse of last logon time minus first logon time, expressed in some quantitative measurement of time, for example, the difference in terms of number of days, hours, weeks, etc. Other formulas of computing this inverse difference can include 1−(x_a/max(x_a)), where x_a is the difference in time between the last and first logon times for an account a. Thus, accounts falling in the bottom left corner are more likely to be malicious. For example, such account activity may indicate a stolen account or a malicious intent. In some examples, activities that are unauthorized may also be discovered. For example, the use of a root account with privileges greater than authorized can also be discovered.

0064At block <b>608</b>, the bubble plot graph <b>300</b> is displayed. For example, the bubble plot graph <b>300</b> can be displayed at a client.

0065This process flow diagram is not intended to indicate that the blocks of the method <b>600</b> are to be executed in any particular order, or that all of the blocks are to be included in every case. Further, any number of additional blocks not shown may be included within the method <b>600</b>, depending on the details of the specific implementation.

0066<figref idref="DRAWINGS">FIG. 7</figref> is intended to provide a brief, general description of a computing environment in which the various techniques described herein may be implemented. For example, a method and system for detecting anomalous logons described in <figref idref="DRAWINGS">FIGS. 1-6</figref> can be implemented in such a computing environment. While the claimed subject matter is described below in the general context of computer-executable instructions of a computer program that runs on a local computer or remote computer, the claimed subject matter also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, or the like that perform particular tasks or implement particular abstract data types.

0067<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram of an example operating environment configured for implementing various aspects of the techniques described herein. The example operating environment <b>700</b> includes a computer <b>702</b>. The computer <b>702</b> includes a processing unit <b>704</b>, a system memory <b>706</b>, and a system bus <b>708</b>.

0068The system bus <b>708</b> couples system components including, but not limited to, the system memory <b>706</b> to the processing unit <b>704</b>. The processing unit <b>704</b> can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit <b>704</b>.

0069The system bus <b>708</b> can be any of several types of bus structure, including the memory bus or memory controller, a peripheral bus or external bus, and a local bus using any variety of available bus architectures known to those of ordinary skill in the art. The system memory <b>706</b> includes computer-readable storage media that includes volatile memory <b>710</b> and nonvolatile memory <b>712</b>.

0070The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer <b>702</b>, such as during start-up, is stored in nonvolatile memory <b>712</b>. By way of illustration, and not limitation, nonvolatile memory <b>712</b> can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory.

0071Volatile memory <b>710</b> includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), SynchLink™ DRAM (SLDRAM), Rambus® direct RAM (RDRAM), direct Rambus® dynamic RAM (DRDRAM), and Rambus® dynamic RAM (RDRAM).

0072The computer <b>702</b> also includes other computer-readable media, such as removable/non-removable, volatile/non-volatile computer storage media. <figref idref="DRAWINGS">FIG. 7</figref> shows, for example a disk storage <b>714</b>. Disk storage <b>714</b> includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-210 drive, flash memory card, or memory stick. In some examples, the disk storage <b>714</b> can be formatted using the Hadoop Distributed File System (HDFS). For example, an HDFS cluster can include a NameNode that manages the file system metadata and DataNodes that store the actual data.

0073In addition, disk storage <b>714</b> can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage devices <b>714</b> to the system bus <b>708</b>, a removable or non-removable interface is typically used such as interface <b>716</b>.

0074It is to be appreciated that <figref idref="DRAWINGS">FIG. 7</figref> describes software that acts as an intermediary between users and the basic computer resources described in the suitable operating environment <b>700</b>. Such software includes an operating system <b>718</b>. Operating system <b>718</b>, which can be stored on disk storage <b>714</b>, acts to control and allocate resources of the computer <b>702</b>.

0075System applications <b>720</b> take advantage of the management of resources by operating system <b>718</b> through program modules <b>722</b> and program data <b>724</b> stored either in system memory <b>706</b> or on disk storage <b>714</b>. It is to be appreciated that the claimed subject matter can be implemented with various operating systems or combinations of operating systems.

0076A user enters commands or information into the computer <b>702</b> through input devices <b>726</b>. Input devices <b>726</b> include, but are not limited to, a pointing device, such as, a mouse, trackball, stylus, and the like, a keyboard, a microphone, a joystick, a satellite dish, a scanner, a TV tuner card, a digital camera, a digital video camera, a web camera, and the like. The input devices <b>726</b> connect to the processing unit <b>704</b> through the system bus <b>708</b> via interface ports <b>728</b>. Interface ports <b>728</b> include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB).

0077Output devices <b>730</b> use some of the same type of ports as input devices <b>726</b>. Thus, for example, a USB port may be used to provide input to the computer <b>702</b>, and to output information from computer <b>702</b> to an output device <b>730</b>.

0078Output adapter <b>732</b> is provided to illustrate that there are some output devices <b>730</b> like monitors, speakers, and printers, among other output devices <b>730</b>, which are accessible via adapters. The output adapters <b>732</b> include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device <b>730</b> and the system bus <b>708</b>. It can be noted that other devices and systems of devices provide both input and output capabilities such as remote computers <b>734</b>.

0079The computer <b>702</b> can be a server hosting various software applications in a networked environment using logical connections to one or more remote computers, such as remote computers <b>734</b>. The remote computers <b>734</b> may be client systems configured with web browsers, PC applications, mobile phone applications, and the like. The remote computers <b>734</b> can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a mobile phone, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to the computer <b>702</b>.

0080Remote computers <b>734</b> can be logically connected to the computer <b>702</b> through a network interface <b>736</b> and then connected via a communication connection <b>738</b>, which may be wireless. Network interface <b>736</b> encompasses wireless communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

0081Communication connection <b>738</b> refers to the hardware/software employed to connect the network interface <b>736</b> to the bus <b>708</b>. While communication connection <b>738</b> is shown for illustrative clarity inside computer <b>702</b>, it can also be external to the computer <b>702</b>. The hardware/software for connection to the network interface <b>736</b> may include, for exemplary purposes, internal and external technologies such as, mobile phone switches, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

0082An example processing unit <b>704</b> for the server may be a computing cluster. Additionally, the disk storage <b>714</b> can store various types of data <b>724</b> used to detect anomalous events and accounts. For example, the disk storage <b>714</b> may comprise an enterprise data storage system, for example, storing data <b>724</b> such as event logs. An event log, as used herein, refers to a file containing a plurality of recorded events. For example, the logs can be received in a native XML format and processed into a common structured table format and inserted in a disk storage <b>714</b> for querying and analytics purposes. For example, the disk storage can be a Hadoop Distributed File System (HDFS). In some examples, the number of events processed each day can number in the billions. For example, tens of thousands of events can be receive and processed per second. Thus, in some examples, the event logs can be compressed into Optimized Row Columnar (ORC) format before being inserted into the disk storage. In some examples, error-handling and re-run procedures can also be used to prevent loss or corruption of data <b>724</b>.

0083The computer <b>702</b> includes one or more modules <b>722</b> configured to perform detection of anomalous processes and accounts, including an event log module <b>740</b>, a filter module <b>742</b>, a receiving module <b>744</b>, a conversion module <b>746</b>, a baseline module <b>748</b>, a detection module <b>750</b>, a baseline module <b>752</b>, a collector module <b>754</b>, an aggregator module <b>756</b>, a graphing module <b>758</b>, an update module <b>760</b>, and a display module <b>762</b>. The event log module <b>740</b> can receive a plurality of event logs. The filter module <b>742</b> can filter the plurality of event logs based at least in part on detected process creations. The receiving module <b>744</b> can receive a directory path and process name for each detected process creation. The directory path is the location on a network server where the executable file resides. In some examples, the directory path may be a path on a logical file system implemented one or more nodes of a cloud service. For example, event logs from thousands of machines can be pushed to event collector systems and transferred to folders shared with processing systems. In some examples, the event logs can be processed from a native XML format into a common structure table format. The event logs can then be inserted into a Hadoop Distributed File System (HDFS) storage for querying and analytics purposes. Once a directory path and process name is received by the receiving module <b>744</b>, the conversion module <b>746</b> can convert each directory path to a sequence of integers based on character count. Each integer in the sequence of integers describes the number of characters in the corresponding sub-directory name. In some examples, the detection module <b>752</b> can detect the anomalous process by determining whether a number of matching sequences falls below a threshold number of matches for a given sequence. In some examples, the detection module <b>752</b> can match a process within an error of two characters to a process name on a list of process names. In some examples, anomalous processes may be potentially malicious activities. The detection module <b>752</b> can further detect an anomalous process based on a threshold number of matching character counts or matching process names. For example, if a process name matches within an error of two characters a process name on a list of process names, then an anomalous process can be detected. The display module <b>762</b> can cause the anomalous process to be displayed, for example, by sending the anomalous process for display to a client device.

0084In some examples, the receiving module <b>744</b> can be configured to receive user feedback as input to use in filtering and auto-classification of the plurality of event logs. The event logs can include one or more anomalous processes. For example, the anomalous processes may be malicious processes or suspicious activities. In some examples, the plurality of event logs can also be filtered based on known benign processes. For example, a list of known benign processes may be received from a client by the detection module <b>750</b> and processes with the same name can be filtered from the plurality of event logs. In some examples, the detection module <b>750</b> can automatically classify patterns of processes linked with grayware and filter the plurality of event logs based on the patterns. For example, grayware can include spyware, adware, dialers, joke programs, remote access tools, and any other unwelcome files and programs apart from viruses that are designed to harm the performance of computers on a network.

0085In some examples, the receiving module <b>744</b> can receive a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The baseline module <b>748</b> can generate a baseline based on the event logs for a predetermined window of time. For example, the predetermined window of time can be six months. The collector module <b>754</b> can also collect daily logon events after the predetermined time and compare the daily logon events to the baseline. The detection module <b>750</b> can detect anomalous accounts based on a difference of the logon events of the anomalous account from the baseline. The display module <b>762</b> can then display the detected anomalous accounts. The operation of the baseline module <b>748</b> is discussed in greater detail with respect to <figref idref="DRAWINGS">FIG. 2</figref> above.

0086In some examples, the receiving module <b>744</b> can receive processed event logs including logons of a logon account at a plurality of machines for a predetermined time. In some examples, the aggregator module <b>756</b> can aggregate the processed event logs for each logon account to generate a total number of logons, and a first and a last logon time for each logon account. The graphing module <b>758</b> can then generate a bubble plot graph based on the total number of logons and a difference between the first and the last logon time for each logon account and a size of the bubble indicating an inverse difference between the first logon and the last logon for the logon account. The display module <b>762</b> can then display the bubble plot graph on a client for further analysis. In some examples, the logon account can be one of a plurality of logon accounts to be represented by bubbles in the bubble plot graph. In some examples, the graphing <b>758</b> module can receive an input from a user and remove a bubble from the graph. In some examples, the bubble graph can include an axis representing the last logon time for the logon account. In some examples, the bubble plot graph can include an axis representing the total number of logons for the account. The operation of the graphing module <b>758</b> is discussed in greater detail with respect to <figref idref="DRAWINGS">FIG. 3</figref> above.

0087It is to be understood that the block diagram of <figref idref="DRAWINGS">FIG. 7</figref> is not intended to indicate that the computing system <b>700</b> is to include all of the components shown in <figref idref="DRAWINGS">FIG. 7</figref>. Rather, the computing system <b>700</b> can include fewer or additional components not illustrated in <figref idref="DRAWINGS">FIG. 7</figref> (e.g., additional applications, additional modules, additional memory devices, additional network interfaces, etc.). Furthermore, any of the functionalities of the event log module <b>740</b>, the filter module <b>742</b>, the receiving module <b>744</b>, the conversion module <b>746</b>, the baseline module <b>748</b>, the detection module <b>750</b>, the baseline module <b>752</b>, the collector module <b>754</b>, the aggregator module <b>756</b>, the graphing module <b>758</b>, the update module <b>760</b>, and the display module <b>762</b>, can be partially, or entirely, implemented in hardware and/or in a processor. For example, the functionality can be implemented with an application specific integrated circuit, in logic implemented in the processor, or in any other device. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), and Complex Programmable Logic Devices (CPLDs), etc.

0088<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram showing an example tangible, computer-readable storage medium that can be used to generate a bubble plot graph of anomalous logons. The tangible, computer-readable storage media <b>800</b> can be accessed by a processor <b>802</b> over a computer bus <b>804</b>. Furthermore, the tangible, computer-readable storage media <b>800</b> can include code to direct the processor <b>802</b> to perform the current methods. For example, any combination of methods <b>400</b>-<b>600</b> can be performed by the processor <b>802</b>.

0089The various software components discussed herein can be stored on the tangible, computer-readable storage media <b>800</b>, as indicated in <figref idref="DRAWINGS">FIG. 8</figref>. For example, the tangible computer-readable storage media <b>800</b> can include an anomalous process detector module <b>806</b>, a baseline module <b>808</b>, and a graph generator module <b>810</b>. In some implementations, the anomalous process detector module <b>806</b> includes code to receive a plurality of event logs. For example, the event logs can include logons of a plurality of machines for a predetermined time. The anomalous process detector module <b>806</b> can also include code to filter the plurality of event logs based on detected process creations. The anomalous process detector module <b>806</b> can also include code to receive a directory path and process name for each detected process creation. The anomalous process detector module <b>806</b> can also include code to convert each directory path to a sequence of integers based on a character count for each sub-directory of the directory path. The anomalous process detector module <b>806</b> can also include code to detect an anomalous process based on a threshold number of matching character counts. The anomalous process detector module <b>806</b> can also include code to display the anomalous process.

0090The baseline module <b>808</b> includes code to receive a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The baseline module <b>808</b> also includes code to generate a baseline based on the event logs for the predetermined window of time. The baseline module <b>808</b> can also include code to collect daily logon events after the predetermined time and compare the daily logon events to the baseline. The baseline module <b>808</b> can also include code to detect an anomalous account based a difference of logon events of the anomalous account from the baseline. The baseline module <b>808</b> can also include code to display the detected anomalous account.

0091The graph generator module <b>810</b> includes code to generate a bubble plot graph based on the total number of logons and a difference between the first and last logon time for each logon account. The graph generator module <b>810</b> can also include code to display the bubble plot graph. In some examples, the bubble plot graph can include a plurality of bubbles with sizes indicating an inverse difference between a first logon and last logon for each logon account.

0092It is to be understood that any number of additional software components not shown in <figref idref="DRAWINGS">FIG. 8</figref> can be included within the tangible, computer-readable storage media <b>800</b>, depending on the specific application. Although the subject matter has been described in language specific to structural features and/or methods, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific structural features or methods described above. Rather, the specific structural features and methods described above are disclosed as example forms of implementing the claims.

EXAMPLE 1

0093This example provides for an example system for anomalous process detection. The example system includes an event log module configured to receive a plurality of event logs. The example system also includes a filter module to filter the plurality of event logs based on detected process creations. The example system also includes a receiving module to receive a directory path and process name for each detected process creation. The example system also includes a conversion module to a sequence of integers based on a character count for each sub-directory of the directory path. The example system also includes a detection module to detect an anomalous process based on a threshold number of matching character counts and matching process names. The example system also includes a display module to display the detected anomalous process. Alternatively, or in addition, the receiving module can be further configured to receive user feedback as input to use in filtering and auto-classification of the plurality of event logs. Alternatively, or in addition, the detection module can be further configured to match a process within an error of two characters to a process name on a list of process names. Alternatively, or in addition, the detection module can be further configured to determine whether a number of matching sequences falls below a threshold number of matches for a given sequence. Alternatively, or in addition, the detection module can be configured to automatically classify patterns of processes linked with malware or grayware.

EXAMPLE 2

0094This example provides for an example system for detecting anomalous accounts. The example system includes a receiving module configured to receive a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The example system includes a baseline module configured to generate a baseline based on the event logs for the predetermined window of time. The example system also includes a collector module configured to collect daily logon events after the predetermined time and compare the daily logon events to the baseline. The example system further includes a detection module configured to detect an anomalous account based on a difference of logon events of the anomalous account from the baseline. The example system also further includes an update module configured to generate a new baseline by removing older event logs from the baseline based on a predetermined adjustment time and adding new event logs from non-anomalous accounts based on the predetermined adjustment time and comparing daily logon events to the new baseline. The example system also includes a display module configured to display the detected anomalous account. Alternatively, or in addition, the update module can be further configured to generate a new baseline by removing older event logs from the baseline based on a predetermined adjustment time and adding new event logs from non-anomalous accounts based on the predetermined adjustment time and comparing daily logon events to the new baseline. Alternatively, or in addition, the example system can also include a graphing module to generate a bubble plot graph to visualize account behavior and the detected anomalous accounts. Alternatively, or in addition, the baseline module can be further configured to format the event logs into a table format. Alternatively, or in addition, the table format can be an Optimized Row Columnar (ORC) format.

EXAMPLE 3

0095This example provides for an example system for generating bubble plot graphs. The example system includes a receiving module configured to receive processed event logs including logons of a logon account at a plurality of machines for a predetermined time. The example system also includes an aggregator module configured to aggregate the processed event logs for the logon account to generate a total number of logons, and a first and a last logon time for the logon account. The example system also includes a graphing module configured to generate a bubble plot graph including a bubble based on the total number of logons and a difference between the first and the last logon time for the logon account and a size of the bubble indicating an inverse difference between the first logon and the last logon for the logon account. The example system also includes a display module configured to display the bubble plot graph. Alternatively, or in addition the logon account can be one of a plurality of logon accounts to be represented by bubbles in the bubble plot graph. Alternatively, or in addition, the graphing module can be further configured to receive an input and remove a bubble from the graph. Alternatively, or in addition, the bubble plot graph can also include an axis representing the last logon time for the logon account. Alternatively, or in addition, the bubble plot graph can also include an axis representing the total number of logons for the account.

EXAMPLE 4

0096This example provides for an example method for anomalous process detection. The example method can include receiving, via a processor, a plurality of event logs. The example method can also include filtering, via the processor, the plurality of event logs to detect process creations. The example method can further include receiving, via the processor, a directory path and process name for each detected process creation. The example method can also further include converting, via the processor, each directory path to a sequence of integers based on character count. The example method can also include detecting, via the processor, an anomalous process based on a threshold number of matching character counts. The example method can also further include displaying, via the processor, the detected anomalous process. Alternatively, or in addition, the example method may include receiving user feedback as input to use in filtering and auto-classification of the plurality of event logs. Alternatively, or in addition, the example method may include detecting an anomalous process based on matching process names. Alternatively, or in addition, the example method may include. Alternatively, or in addition, the example method may include calculating a confidence score that indicates a level of certainty of the comparison results and displaying the confidence score with an associated comparison result. Alternatively, or in addition, the example method may include filtering the plurality of event logs to detect service installations and detecting an anomalous service installation based on the threshold number of matching character counts. Alternatively, or in addition, the example method may include automatically classifying patterns of processes linked with malware or grayware.

EXAMPLE 5

0097This example provides for an example method for detecting anomalous accounts. The example method can include receiving, via a processor, a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The example method can also include generating, via the processor, a baseline based on the event logs for the predetermined window of time. The example method can further include collecting, via the processor, daily logon events after the predetermined time and comparing the daily logon events to the baseline. The example method can also further include detecting, via the processor, an anomalous account based on a difference of logon events of the anomalous account from the baseline. The example method can also include displaying, via the processor, the detected anomalous account. Alternatively, or in addition, the example method may include generating, via the processor, a new baseline by removing older event logs from the baseline based on a predetermined adjustment time and adding new event logs from non-anomalous accounts based on the predetermined adjustment time and comparing daily logon events to the new baseline. Alternatively, or in addition, the example method may include generating, via the processor, a bubble plot graph to visualize account behavior and the detected anomalous accounts. Alternatively, or in addition, the event logs can include additions of members to groups. Alternatively, or in addition, the example method can further include detecting an anomalous group membership addition based on a detected difference of the group membership addition from the baseline. Alternatively, or in addition, the example method may include compressing, via the processor, the event logs into an Optimized Row Columnar (ORC) format.

EXAMPLE 6

0098This example provides for an example method for generating a bubble plot graph. The example method can include receiving, via a processor, processed event logs including logons of a logon account at a plurality of machines for a predetermined time. The example method can also include aggregating, via the processor, the processed event logs for the logon account to generate a total number of logons, and a first and a last logon time for the logon account. The example method can further include generating, via the processor, a bubble plot graph based on the total number of logons and a difference between a first logon time and a last logon time for the logon account. The example method can also further include displaying, via the processor, the bubble plot graph. Alternatively, or in addition, the example method may include representing the difference between the first and last logon time for the account in the bubble plot graph via a bubble size. Alternatively, or in addition, the bubble size can indicate an inverse difference between a first logon and last logon for the account. Alternatively, or in addition, the example method may include representing the last logon time for the logon account along one axis of the bubble plot graph. Alternatively, or in addition, the example method may include representing the total number of logons for the account along one axis of the bubble plot graph.

EXAMPLE 7

0099This example provides for one or more computer-readable storage medium for storing computer readable instructions that, when executed by one or more processing devices, instruct the detection of anomalous processes. The computer-readable medium includes instructions to receive a plurality of event logs. The computer-readable medium also includes instructions to filter the plurality of event logs based on detected process creations. The computer-readable medium includes instructions to. Further, the computer-readable medium includes instructions to receive a directory path and process name for each detected process creation. The computer-readable medium also further includes instructions to convert each directory path to a sequence of integers based on a character count for each sub-directory of the directory path. The computer-readable medium also further includes instructions to detect an anomalous process based on a threshold number of matching character counts and matching process names. The computer-readable medium also further includes instructions to display the detected anomalous process. Alternatively, or in addition, the computer-readable medium may include instructions to receive user feedback as input to use in filtering and auto-classification of the plurality of event logs. Alternatively, or in addition, the computer-readable medium may include instructions to match a process within an error of two characters to a process name on a list of process names. Alternatively, or in addition, the computer-readable medium may include instructions to determine whether a number of matching sequences falls below a threshold number of matches for a given sequence. Alternatively, or in addition, the computer-readable medium may include instructions to automatically classify patterns of processes linked with malware or grayware.

EXAMPLE 8

0100This example provides for one or more computer-readable storage medium for storing computer readable instructions that, when executed by one or more processing devices, instruct the detection of anomalous accounts. The computer-readable medium includes instructions to receive a list of monitored machines and event logs including logons for the list of monitored machines for a predetermined window of time. The computer-readable medium also includes instructions to generate a baseline based on the event logs for the predetermined window of time. The computer-readable medium includes instructions to. Further, the computer-readable medium includes instructions to collect daily logon events after the predetermined time and compare the daily logon events to the baseline. The computer-readable medium also further includes instructions to detect an anomalous account based on a difference of logon events of the anomalous account from the baseline. The computer-readable medium also further includes instructions to generate a new baseline by removing older event logs from the baseline based on a predetermined adjustment time and adding new event logs from non-anomalous accounts based on the predetermined adjustment time and comparing daily logon events to the new baseline. The computer-readable medium also further includes instructions to display the detected anomalous account. Alternatively, or in addition, the computer-readable medium may include instructions to generate a new baseline by removing older event logs from the baseline based on a predetermined adjustment time and adding new event logs from non-anomalous accounts based on the predetermined adjustment time and comparing daily logon events to the new baseline. Alternatively, or in addition, the computer-readable medium may include instructions to generate a bubble plot graph to visualize account behavior and the detected anomalous accounts. Alternatively, or in addition, the computer-readable medium may include instructions to format the event logs into a table format. Alternatively, or in addition, the table format can be an Optimized Row Columnar (ORC) format.

EXAMPLE 9

0101This example provides for one or more computer-readable storage medium for storing computer readable instructions that, when executed by one or more processing devices, instruct the generation of bubble plot graphs. The computer-readable medium includes instructions to receive processed event logs including logons of a logon account at a plurality of machines for a predetermined time. The computer-readable medium also includes instructions to aggregate the processed event logs for the logon account to generate a total number of logons, and a first and a last logon time for the logon account. The computer-readable medium includes instructions to generate a bubble plot graph including a bubble based on the total number of logons and a difference between the first and the last logon time for the logon account and a size of the bubble indicating an inverse difference between the first logon and the last logon for the logon account. Further, the computer-readable medium includes instructions to display the bubble plot graph. Alternatively, or in addition, the logon account can be one of a plurality of logon accounts to be represented by bubbles in the bubble plot graph. Alternatively, or in addition, the computer-readable medium may include instructions to receive an input and remove a bubble from the graph. Alternatively, or in addition, the computer-readable medium may include instructions to generate an axis representing the last logon time for the logon account. Alternatively, or in addition, the computer-readable medium may include instructions to generate an axis representing the total number of logons for the account.

0102What has been described above includes examples of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the claimed subject matter are possible. Accordingly, the claimed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

0103In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component, e.g., a functional equivalent, even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the claimed subject matter. In this regard, it will also be recognized that the innovation includes a system as well as a computer-readable storage media having computer-executable instructions for performing the acts and events of the various methods of the claimed subject matter.

0104There are multiple ways of implementing the claimed subject matter, e.g., an appropriate API, tool kit, driver code, operating system, control, standalone or downloadable software object, etc., which enables applications and services to use the techniques described herein. The claimed subject matter contemplates the use from the standpoint of an API (or other software object), as well as from a software or hardware object that operates according to the techniques set forth herein. Thus, various implementations of the claimed subject matter described herein may have aspects that are wholly in hardware, partly in hardware and partly in software, as well as in software.

0105The aforementioned systems have been described with respect to interaction between several components. It can be appreciated that such systems and components can include those components or specified sub-components, some of the specified components or sub-components, and additional components, and according to various permutations and combinations of the foregoing. Sub-components can also be implemented as components communicatively coupled to other components rather than included within parent components (hierarchical).

0106Additionally, it can be noted that one or more components may be combined into a single component providing aggregate functionality or divided into several separate sub-components, and any one or more middle layers, such as a management layer, may be provided to communicatively couple to such sub-components in order to provide integrated functionality. Any components described herein may also interact with one or more other components not specifically described herein but generally known by those of skill in the art.

0107In addition, while a particular feature of the claimed subject matter may have been disclosed with respect to one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes,” “including,” “has,” “contains,” variants thereof, and other similar words are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.