<p>As antivirus and machine learning-based malware detection have increased their effectiveness in detecting file-based attacks, adversaries have migrated to “living off the land” techniques to bypass modern security software. This involves executing system tools preinstalled with the operating system or commonly brought in by administrators to perform tasks like automating IT administrative tasks, running scripts on a regular basis, executing code on remote systems, and much more. Attackers using trusted OS tools like powershell.exe, wmic.exe, or schtasks.exe can be difficult to identify. These binaries are inherently benign and commonly used in most environments, so attackers can trivially bypass most first-line defenses simply by blending in with the noise of what’s executing on a recurring basis. Detecting patterns like this post-compromise requires sifting through millions of events with no clear starting point.</p><p>In response, security researchers have begun authoring detectors to target suspicious parent-child process chains. Using MITRE ATT&amp;CK™ as a playbook, researchers can write detection logic to alert on a specific parent launching a child process with certain command line arguments. A good example is alerting on an MS Office process spawn powershell.exe with base64 encoded arguments. However, this is a time-consuming process requiring domain expertise and an explicit feedback loop to tune noisy detectors.</p><p>Security workers have open-sourced several Red vs. Blue Frameworks to simulate attacks and evaluate detector performance — but no matter how effective the detector, its logic can only solve one specific attack. A failure of detectors to generalize and detect emergent attacks presents a unique opportunity for machine learning.</p><h2><strong>Thinking in graphs</strong></h2><p>When we first started thinking about detecting anomalous parent-child processes, I immediately jumped at the idea of turning this into a graph problem. After all, process execution can be expressed as a graph for a given host. The nodes in our graph will be individual processes broken out by process ID (PID), while each of the edges, which connect the nodes, will be a process_creation event. A given edge will be packed with important metadata derived from the event like timestamps, command-line arguments, and the user.</p><p style="text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltef61d88cac306543/5e507da426150d0da990265b/discovering-anomalous-behavior-blog-process-chain.png" data-sys-asset-uid="bltef61d88cac306543" alt="discovering-anomalous-behavior-blog-process-chain.png" width="373" height="321" style="width: 373;height: 321;"/></p><figcaption style="text-align: center;">Fig 1 - Example graph representation of a process chain</figcaption><p><br /></p><p>Now we have a graph representation of a host machine’s process events. However, living off the land attacks can spawn from the same system-level processes that are always executing. We need a way to separate good and bad process chains within a given graph. Community detection is a technique that segments a large graph into smaller “communities” based on the density of the edges between our nodes. To use this, we need a way to generate a weight between nodes to ensure community detection works properly and identifies the anomalous portion(s) of our graph. For this, we will turn to machine learning.</p><h2><strong>Machine learning</strong></h2><p>To generate our edge weight model, we will use supervised learning, a machine learning approach that requires labeled data to feed to the model. Luckily, we can use the open source Red and Blue frameworks mentioned above to help generate some training data. Below are a few of the Open Source Red and Blue Frameworks used in our training corpus:</p><h4><strong>Red team frameworks</strong></h4><ul><li><a href="https://github.com/redcanaryco/atomic-red-team">Atomic Red Team</a> (Red Canary)</li><li><a href="https://github.com/endgameinc/RTA">Red Team Automation</a> (Endgame/Elastic)</li><li><a href="https://github.com/mitre/caldera">Caldera Adversary Emulation</a> (MITRE)</li><li><a href="https://github.com/uber-common/metta">Metta</a> (Uber)</li></ul><h4><strong>Blue team frameworks</strong></h4><ul><li><a href="https://eqllib.readthedocs.io/en/latest/atomicblue.html">Atomic Blue</a> (Endgame/Elastic)</li><li><a href="https://github.com/mitre-attack/car">Cyber Analytics Repository </a>(MITRE)</li><li><a href="https://github.com/microsoft/WindowsDefenderATP-Hunting-Queries">MSFT ATP Queries</a> (Microsoft)</li></ul><h3><strong>Data ingest &amp; normalization</strong></h3><h3><strong></strong></h3><p style="text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt00f32018fe982214/5e507df806f84d0d618d9bf4/discovering-anomalous-behavior-blog-sample-process-creation.png" data-sys-asset-uid="blt00f32018fe982214" alt="discovering-anomalous-behavior-blog-sample-process-creation.png"/></p><figcaption style="text-align: center;">Fig 2 - Sample process creation event pre- and post-feature engineering</figcaption><p><br /></p><p>Once we’ve ingested some event data, we will need to transform it into a numeric representation (Fig 2). This representation will allow the model to learn broader details of a parent-child relationship in the scope of an attack, which helps it avoid merely learning signatures.&nbsp;</p><p>First, we perform feature engineering (Fig 3) on process names and command-line arguments. TF-IDF vectorization will capture the statistical importance of a given word to an event across our dataset. Converting timestamps to integers will allow us to determine the delta between the parent process start time and when a child process was launched. Other features are binary in nature (e.g., 1 or 0, yes or no). Good examples of this feature type are:&nbsp;</p><ul><li>Is the process signed?&nbsp;</li><li>Do we trust the signer?&nbsp;</li><li>Is the process elevated?</li></ul><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt25637fac37f11262/5e50802eaa10350d40de7cfd/discovering-anomalous-behavior-blog-feature-engineering.png" data-sys-asset-uid="blt25637fac37f11262" alt="discovering-anomalous-behavior-blog-feature-engineering.png"/></p><figcaption style="text-align: center;">Fig 3 - Examples of feature engineering on process event metadata</figcaption><p><br /></p><p>After our dataset has been transformed, we will use it to train a supervised learning model (Fig 4). The model serves to provide an “anomalous score” for a given process creation event between 0 (benign) and 1 (anomalous). We can use the anomalous score as an edge weight in our graph!</p><figcaption style="text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt035ac4d8f6488c90/5e5080cf9911e20db4ddf7ec/discovering-anomalous-behavior-blog-supervised-machine-learning.png" data-sys-asset-uid="blt035ac4d8f6488c90" alt="discovering-anomalous-behavior-blog-supervised-machine-learning.png"/><br />Fig 4 - Example of a supervised machine learning workflow</figcaption><p><strong></strong></p><h3><strong>Prevalence service</strong></h3><figcaption style="text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5d6f3f5d4a9a94a8/5e50811caa10350d40de7d03/discovering-anomalous-behavior-blog-conditional-probabilities-1.png" data-sys-asset-uid="blt5d6f3f5d4a9a94a8" alt="discovering-anomalous-behavior-blog-conditional-probabilities-1.png" width="216" height="149" style="background-color: initial;width: 216;height: 149;"/><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8c47b8c822d879b1/5e50811363fdbd0db5743cea/discovering-anomalous-behavior-blog-conditional-probabilities.png" data-sys-asset-uid="blt8c47b8c822d879b1" alt="discovering-anomalous-behavior-blog-conditional-probabilities.png" width="279" height="143" style="width: 279;height: 143;"/><br />Fig 5 - Conditional probabilities used by the Prevalence Engine</figcaption><p style="text-align: center;"><br /></p><p>Now we have a weight graph — courtesy of our machine learning model. Mission accomplished, right? The model we’ve trained does a great job of making a good/bad decision for a given parent-child chain based on our global understanding of good and bad. But every customer environment is going to be different. There will be processes we’ve never observed before and system administrators who use PowerShell for … well, everything.</p><p>Basically, if we just used this model alone, we would likely see a deluge of false positives and we would increase the amount of data an analyst needs to sift through. To offset this potential problem, we’ve developed a prevalence service to tell us how common a given parent-child process chain is within that environment. Accounting for the local nuances of the environment will allow us to more confidently elevate or suppress suspicious events and draw out truly anomalous process chains.&nbsp;</p><p>The prevalence service (Fig 5) relies on two statistics derived from conditional probability that allow us to state: “From this parent, I’ve seen this child more than X% of other child processes” AND “From this process, I’ve seen this command-line more than X% of other command-lines associated w/ the process.” Once we have the Prevalence Service in place, we can put the finishing touches on our core detection logic, find_bad_communities.</p><h3><strong>Finding “bad” communities</strong></h3><figcaption style="text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb6c59558aee70528/5e50815b1ec0810daab50176/discovering-anomalous-behavior-blog-python-code.png" data-sys-asset-uid="bltb6c59558aee70528" alt="discovering-anomalous-behavior-blog-python-code.png"/><br />Fig 6 - Python code for discovering anomalous communities</figcaption><p style="text-align: center;"><br /></p><p>Above (Fig 6) we see the Python code used to generate the bad communities. The logic for find_bad_communities is very straightforward:</p><ol><li>Classify each process_create event for a host machine to generate a node pair (e.g., parent node and child node) and an associated weight (e.g. the output from our model)&nbsp;</li><li>Construct a directed graph&nbsp;</li><li>Perform community detection to generate a list of communities in the graph.</li><li>Within each community, we determine how prevalent a parent-child is (e.g. each connection). We account for the commonness of a parent-child event in the final anomalous_score.&nbsp;</li><li>If the anomalous_score meets or exceeds a threshold, we set aside that entire community for analyst review&nbsp;</li><li>After each community has been analyzed, we return a list of “bad” communities sorted by the max anomalous_score</li></ol><h2><strong>Results</strong></h2><p>We trained the final model on a combination of real-world and simulated benign and malicious data. Benign data consisted of 3 days of Windows process event data gathered on our internal network. The sources of this data were a mix of user workstations and servers to replicate a small organization. We generated malicious data by detonating all the ATT&amp;CK techniques available via the Endgame RTA framework, as well as launching macro and binary-based malware from advanced adversaries like FIN7 and Emotet.</p><p>For our main experiment, we decided to use event data from the <a href="https://attackevals.mitre.org/">MITRE ATT&amp;CK Evaluation</a> provided by Roberto Rodriguez’s <a href="https://github.com/hunters-forge/mordor">Mordor project</a>. The ATT&amp;CK Evaluation sought to emulate APT3 activity using FOSS/COTS tools like PSEmpire and CobaltStrike. These tools allow living off the land techniques to be chained to perform Execution, Persistence, or Defense Evasion tasks.&nbsp;</p><p>The framework was able to identify several multi-technique attack chains&nbsp;using exclusively process creation events. Discovery (Fig 7) and Lateral Movement (Fig 8) we discovered and highlighted for analyst review.&nbsp;</p><figcaption style="text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6dcc408f4752159c/5e5081827569ef0d9eca55a5/discovering-anomalous-behavior-blog-discovery-techniques.png" data-sys-asset-uid="blt6dcc408f4752159c" alt="discovering-anomalous-behavior-blog-discovery-techniques.png"/><br />Fig 7 - Process chain performing “Discovery” techniques</figcaption><figcaption style="text-align: center;"><br /><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt19416010ffee0562/5e5081c826150d0da9902667/discovering-anomalous-behavior-blog-lateral-movement.png" data-sys-asset-uid="blt19416010ffee0562" alt="discovering-anomalous-behavior-blog-lateral-movement.png"/><br />Fig 8 - Process chain performing lateral movement</figcaption><p style="text-align: center;"><strong></strong></p><h4><strong>Data reduction</strong></h4><p>A byproduct of our approach is not only the ability to discover anomalous process chains, but also the ability to demonstrate the value of the prevalence engine in suppressing false positives. In combination, we were able to drastically reduce the amount of event data that needed to be reviewed by an analyst. By the numbers:&nbsp;</p><ul><li>We tallied ~10K process creation events per endpoint in the APT3 scenario (5 endpoints total).&nbsp;</li><li>We identified ~6 anomalous communities per endpoint.</li><li>Each community consisted of ~6-8 events apiece.</li></ul><h2><strong>Looking ahead</strong></h2><p>We’re in the process of taking this research from proof-of-concept to integrated solution as an <a href="https://www.elastic.co/security">Elastic Security</a> feature. The most promising feature is the \prevalence engine. Prevalence engines highlighting frequency of occurrence of files are common, but describing prevalence of relationships between events will help security professionals detect threats in new ways, both by looking at what is rare/common in their enterprise and eventually augmented by measurements of what is rare globally.&nbsp;</p><h2><strong>Conclusion</strong></h2><p>We presented this graph-based framework (called <a href="https://docs.google.com/presentation/u/1/d/1bcdBzxedIDwgAgXJr3LGfIaauk_YnCw3z562N1jYEzE/edit">ProblemChild</a>) at <a href="https://www.virusbulletin.com/conference/vb2019/abstracts/problem-child-common-patterns-malicious-parent-child-relationships">VirusBulletin</a> and <a href="https://www.camlis.org/2019/talks/filar">CAMLIS</a> last year with the goal of reducing the need for domain expertise in the detector writing process. By applying supervised machine learning to derive a weighted graph, we demonstrated an ability to identify communities of seemingly disparate events into larger attack sequences. Our framework applies conditional probability to automatically rank anomalous communities, as well as suppress commonly occurring parent-child chains. When applied towards both goals, this framework can be used by analysts to aid in the crafting or tuning of detectors and reduce false positives over time.&nbsp;</p>

blog-banner-bw-dot-grid.jpg

blog-thumb-bw-dot-grid.jpg

Discovering anomalous patterns based on parent-child process relationships

<p>We recently launched Elastic Security, combining the threat hunting and analytics tools from <a href="/products/siem" target="_self">Elastic SIEM</a> with the prevention and response features of <a href="/products/endpoint-security" target="_self">Elastic Endpoint Security</a>. This combined solution focuses on detecting and flexibly responding to security threats, with machine learning providing core capabilities for real-time protections, detections, and interactive hunting. But why are machine learning tools so important in information security? How is machine learning being applied? In this first of a two-part blog series, we’ll motivate the "why" and explore the "how," highlighting malware prevention via supervised machine learning in Elastic Endpoint Security. In a follow-up, we’ll highlight where machine learning plays a role in detecting anomalous behavior from the global view of Elastic SIEM.</p><h2><strong>Malicious activity: a case study</strong></h2><p>Even as the United States prepares for the 2020 election cycle, a three-year anniversary of an <a href="https://www.cnet.com/news/how-the-russian-hackers-infiltrated-the-dnc-a-timeline/" target="_self">infamous cyber attack</a> is still top of mind.</p><p>On Tuesday, March 15, 2016, threat actors allegedly from the advanced persistent threat (APT) Group 28 (aka “Fancy Bear”) began port scanning servers at the Democratic National Committee. This was part of a broader reconnaissance effort that adversaries commonly perform against a target. By Saturday, the adversary had delivered a spear-phishing email to the campaign chairman to gain access to his email account. Although recipients noted it as suspicious, the attack worked: by Monday, the threat group had compromised the chairman’s email account and stolen more than 50 thousand emails. Then, from a new email account created by attackers within the DNC domain (with a name similar to the account of a recognized DNC staffer), a spreadsheet named “candidate favorability ratings” was delivered to 30 DNC staffers. At least one recipient opened the spreadsheet and enabled a macro, which resulted in a local user account being hacked.</p><p>In the weeks that followed, a common playbook of tactics unfolded in what is now eponymously known as the DNC hack. Like other APT groups, while the specific techniques deployed are circumstantially tailored, the broader tactics are repeated in attack after attack (and thus codified by MITRE). The attack process typically follows some variation of the following steps:</p><ul><li>Human exploitation leads to account theft.</li><li>Attackers establish persistence, use existing tools or install command-and-control malware (in the case of the DNC hack, X-Agent) that allow them to log keystrokes, take screenshots, and otherwise “land and expand” into other servers on the network.</li><li>Attackers collect, compress, and consume a surfeit of data.</li><li>Logs are scrubbed and digital footprints are delicately swept away.</li><li>The threat group goes dormant, becoming difficult to fully root out, even if their presence is detected on a single device (in the case of the DNC hack, although X-Agent was disabled on June 20 — <strong>97 days after the initial reconnaissance</strong> — a Linux version of the malware remained through October).</li></ul><p>It’s not difficult to understand why unified protections and comprehensive event management are important in a case like this. Unfortunately, being compromised has become a fact of life, and security organizations aim to stop an attacker early in the execution of their plan. Thus, most of the energy traditionally spent in security has been toward detection mechanisms that reduce the dwell time of an attacker post-compromise. Since attacker tools and techniques vary, rules crafted for specific adversary techniques and machine learning trained to catch more general behaviors have been used to detect almost every point along the attacker’s natural progression from reconnaissance to delivery; exploitation to exfiltration.</p><p>The <a href="https://attack.mitre.org/" target="_self">MITRE Corporation</a> began developing a globally accessible knowledge base of adversary tactics and techniques (ATT&amp;CK) based on real-world observations in 2014, which has now grown to codify 266 specific techniques, including many created or enhanced by community <a href="https://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/the-philosophy-of-attck" target="_self">contributions of information</a>. The MITRE ATT&amp;CK matrix is now the most comprehensive adversary model and framework for describing the actions an adversary may take to compromise and operate within an enterprise network.</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltfbac7da809939393/5ddc4ca316efc60c370c15af/ml-cybersecurity-mitre-framework-blog.jpg" data-sys-asset-uid="bltfbac7da809939393" alt="Mitre Attack matrix" style="display: block;margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;"/></p><p><a href="https://attack.mitre.org/" target="_self"><br/></a></p><p><strong></strong></p><h2><strong>Why machine learning?</strong></h2><p>Machine learning offers an attractive paradigm for scaling the detection of adversarial behaviors and their tools, largely owing to the following:</p><ul><li><strong>Automation</strong><strong> — Coarsely, security has historically been tackled by throwing experts at data to produce rules, heuristics, and analytics in a repetitive process of cat-and-mouse. One natural outcome of machine learning is the repurposing of security experts to engineer automation processes — including machine learning training infrastructures — rather than spending cycles on the most repetitive tasks of detection creation. In this way, it’s the algorithms, not valued experts, that are tackling the mundane tasks, occasionally overseen, curated, and refined by security experts where appropriate.</strong></li><li><strong>Discovery of sophisticated relationships</strong><strong> — Human experts are still best positioned to pinpoint causal indicators of threat behavior. For example, a reverse engineer may disassemble and isolate a particular code block encapsulating nefarious behavior. However, machine learning is exceedingly good at finding useful correlations from data that can’t easily be discovered manually. For example, some combination of file size, imported functions, resource table usage, and properties of the </strong><strong>.text</strong><strong> section might isolate a 99.99% pure set of malicious files in the training data. While this isn’t a smoking gun for malicious behavior, it may offer enough evidence to convict a file, process, or user of malintent.</strong></li><li><strong>Generalization with less brittleness — The discovered patterns tend to generalize toward new malware strains, similar tactics, or sketchy user behavior in a way that is less brittle than hand-crafted rules. </strong><a href="https://www.elastic.co/blog/may-2023-launch-machine-learning-models" target="_self"><strong>Machine learning models</strong></a><strong> are often shaped in a way that a file, process, or behavior is not convicted as a binary “good” or “bad,” but instead produces a score that smoothly transitions between areas convicted as “good” and areas convicted as “bad.” Importantly, a model is generated from the data. All real-world machine learning models are in some sense “</strong><a href="https://en.wikipedia.org/wiki/All_models_are_wrong" target="_self"><strong>wrong</strong></a><strong>,” in that they do not perfectly summarize their training data. However, they are “useful” in their very specific task of rendering judgements on samples that are similar to those in their training set. They have “learned” to </strong><em><strong>generalize.</strong></em></li></ul><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta0f4392313f43879/5ddc4cead800b20c30e1ab85/ml-cybersecurity-space-code-blog.jpg" data-sys-asset-uid="blta0f4392313f43879" alt="Malware mapping 1" style="display: block;margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;"/></p><p><br/></p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4fdf6710c32a32da/5ddc4d07d800b20c30e1ab8b/ml-cybersecurity-space-size-blog.jpg" data-sys-asset-uid="blt4fdf6710c32a32da" alt="Malware mapping 2" style="display: block;margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;"/></p><h3>No free security lunch</h3><p>Marketing campaigns notwithstanding, machine learning has generally been a benefit to security. But, the truth is that machine learning for security brings a number of substantive challenges:</p><ul><li><strong>False positives</strong><strong> — When compared to hand-crafted rules and heuristics, machine learning generally trades an increased “true positive rate” (detect new behavior) for a modest increase in false positives (FPs). While the FP rate is still less than, say, 1 in 2000, this is discouraging when the model chooses </strong><em><strong>your </strong></em><strong>favorite application to flag as malicious. “Fixing” a FP is not straightforward. To borrow a </strong><a href="https://pbs.twimg.com/media/EHHdPcCXUAABs3d.jpg" target="_self"><strong>concept</strong></a><strong> from Microsoft, the challenge of deploying machine learning is that “one doesn’t so much fix errors in ML as much as encourage toward the correct answer.” In fatalistic irony, FPs actually </strong><em><strong>increase</strong></em><strong> analyst workload, reducing the overall effectiveness of a solution, especially when defenders respond to FPs by the </strong><a href="https://www.reuters.com/article/us-target-breach/target-says-it-declined-to-act-on-early-alert-of-cyber-breach-idUSBREA2C14F20140313" target="_self"><strong>age-old approach</strong></a><strong> of ignoring or turning off alerting.</strong></li><li><strong>Explainability</strong><strong> — In many cases, from a human’s perspective, the results of a machine learning model may seem incoherent or inconsistent. Trust is paramount in security, and the explainability of a model may be at odds with its sophistication and accuracy. Indeed, when offered, some explanations of model decision come across as trend diagnosis, e.g., “this file is malicious because of imports and high entropy in </strong><strong>.text,</strong><strong>” which does not provide a true explanation, but instead reinforces a notion that machine learning amounts to “bias automation.”</strong></li><li><strong>Adversarial drift</strong><strong> — Dataset drift in machine learning is present in many applications due to the natural evolution of observations. In security, where an adversary — a </strong><em><strong>who</strong></em><strong> not a </strong><em><strong>what</strong></em><strong> — is the focus of observed data, the drift is driven in an adversarial way: an adversary is incentivized to adjust behaviors to evade defensive detections. In this scenario, the fundamental assumption of machine learning — that the training conditions of a model are identical to deployment conditions — is broken. Instead, this assumption must be relaxed to “deployment conditions are almost identical to training conditions for some period of time [until they aren’t].” To keep up, defenders must recollect, retrain, and redeploy machine learning models, typically at a much slower pace than brittle signature and rule-based approaches.</strong></li></ul><p>Tackling these and other considerations motivate the need for security data science and engineering at Elastic. So, where have we applied machine learning? Here, we’ll describe where machine learning plays a role in Elastic Endpoint Security protections. In a follow-up, we’ll highlight where it plays a role in detecting and searching from bulk event data in Elastic SIEM.</p><h2><strong>Endpoint security protections: MalwareScore™</strong></h2><p>Both custom and common software tools are employed by threat actors across all tactics in the MITRE ATT&amp;CK framework. In particular, custom software, macros, or scripts may be used to gain initial access, access credentials, establish command-and-control communications, or render the adversary’s desired impact, such as data encryption for ransomware. MalwareScore is a prevention in Elastic Endpoint Security that detects these malicious files via a trained machine learning model.</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3cb8a6fb972d45e9/5ddc4df66afb810c2d465f63/ml-cybersecurity-ml-model-blog.png" data-sys-asset-uid="blt3cb8a6fb972d45e9" alt="MalwareScore machine learning model" style="display: block;margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;"/></p><figcaption>Parsing files effectively to generate features and train MalwareScore models</figcaption><p>Writing rules or heuristics for every type of known malicious software tool is not sustainable, especially as malware variants evolve. Instead, MalwareScore leverages the scale and automation benefits of machine learning. MalwareScore models are trained to generalize from patterns discovered in large corpora of malicious and benign files: exceeding 150M files for Windows executable files for recent model versions.</p><p>MalwareScore consists of three malicious software models: Windows PE files, macro-based Office documents, and macOS binaries (Mach-O). We apply domain expertise from our threat intelligence team to identify features of these files important in determining whether the file is likely good or bad. For instance, Windows PE files are summarized by features that are derived from aspects of the file that include:</p><ul><li>Header and rich signature</li><li>File section characteristics</li><li>Version data</li><li>Debug info included by the compiler</li><li>Imported and exported functions</li><li>The overlay (appended to the file)</li><li>Resources section</li><li>The entry point</li><li>Thread local storage callbacks</li><li>The distribution of byte patterns in the file</li></ul><p>Mach-O binaries are summarized from similar information. Macros embedded within Office documents are characterized by both macro content and document properties.</p><p>Features like those listed above are readily converted into a format (vector of numbers) that can be ingested and analyzed by machine learning algorithms. MalwareScore leverages <a href="https://en.wikipedia.org/wiki/Gradient_boosting" target="_self">gradient boosting decision trees</a> because these model types offer a nice combination of excellent efficacy (high detection rate with a low false positive rate) and computational simplicity (essentially, a series of if/then statements). Indeed, the models are designed to be lightweight (roughly 5MB) with low CPU utilization.</p><p>MalwareScore is a supervised machine learning model, meaning that each file is paired with a malicious or benign label. The model is trained to minimize prediction errors of these target labels on the training set, with model regularization employed so that the model <em>generalizes</em> to samples not in the training set, rather than just <em>memorizing</em>. While the features and the model type are important, the richness and distribution of the training data and the quality of the labels are fundamental to providing a good model.</p><p><strong></strong></p><h2><strong>What’s next?</strong></h2><p>MalwareScore-supervised machine learning models bring an important element of protection to the Elastic Stack. Users who install Elastic Endpoint Security are protected against malware as part of a layered protection strategy that includes behavioral rules. You can try a recent version of MalwareScore in <a href="https://www.virustotal.com/gui/home/search" target="_self">VirusTotal</a>. Upload or search for a PE, macro, or Mach-O file, and view the results yourself!</p>An even broader security and operational perspective can be attained in Elastic SIEM. In addition to endpoint events collected by Elastic Endpoint Security or other technologies, the SIEM app may include audit events, authentication logs, and firewall logs in holistic detail. In the next blog, we’ll discuss how machine learning in Elastic SIEM can be used to expose unknown threats via anomaly detection in an <em>unsupervised learning</em> paradigm. This allows you to protect against behaviors at the endpoint, and discover unexpected behavior in Elastic SIEM.

Machine learning for cybersecurity: only as effective as your implementation

<p>In our last post, we highlighted the design challenges we faced creating a chatbot for the security space. While the design considerations pose a significant challenge, equally daunting is building something that actually “understands” the end user. For instance, the banner graphic above demonstrates the wide gap between query language syntax when searching on endpoints and how a human would actually pose the question in reality.
</p><p>Unfortunately, the computational transition to natural language is not necessarily a ahem... “natural” one. Building something that understands an English form SQL-like language is much simpler than the messy reality required to build a conversational interface. We’ll describe this process of transitioning from strict query syntax toward building a user-friendly interface flexible enough to answer questions. Guided by the user experience research, building a natural language processing pipeline is the essential second component to ensure our chatbot, Artemis, meets the operational needs of users across a range of expertise.
</p><h2>Chatbot</h2><p>The concept of a chat interface is straightforward. The user is presented a text input window where they can perform a query. Upon entering some text in the window and hitting <enter>, the following actions occur behind the scenes:</enter>
</p><ol>
	<li>Text is sent to the bot
	</li>
	<li>Bot preprocesses/cleans incoming text
	</li>
	<li>Bot determines what the user wants to do
	</li>
	<li>Bot extracts important information
	</li>
	<li>Bot carries out user action</li>
</ol><p>Easy enough, right? Well, not really. In fact, steps 2-4 are some of the toughest problems in a subfield field of Natural Language Processing (NLP), called Natural Language Understanding (NLU). This field has seen increased attention due to the rise of other mainstream intelligent assistants from companies like Amazon, Microsoft, and Google, as well as chatbots on Facebook Messenger and Slack. In short, NLU attempts to derive a user’s intention by performing semantic and syntactic analysis. Before we dive into our NLU pipeline, let’s first explore the core chatbot components required to successfully build a chatbot.
</p><h5>Utterance</h5><p>Utterance refers to the words the user sends to the chatbot.  Utterance is a catch-all term that covers whatever the bot might receive, anything from the word “hey” to a multi-sentence paragraph.
</p><h5>Dialog script</h5><p>The flowchart in Figure 1  is one example of a dialog script. Dialog scripts provide a template of ideal interaction between bot and user. They are similar to a decision or process tree, and cover the potential range of outcomes and flows within a conversation.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd8ecf10168a7d0bb/5dfaab36b24eb127e25aae4f/blog-figure-1-example-of-a-dialog-tree-endpoint.png" data-sys-asset-uid="bltd8ecf10168a7d0bb" alt="blog-figure-1-example-of-a-dialog-tree-endpoint.png"><br>
</p><figcaption>Figure 1 -- Example of a dialog tree</figcaption><h5>Context</h5><p>Context represents the current state of a conversation. Each context within an intent has constraints that must be met (e.g. context = search_process_no_query means a user must supply a hash or filename) to proceed. It might include the extracted entities, the intent itself, the history of past user actions, etc. Programmers could consider context the “state” of the dialog.
</p><h5>Action</h5><p>The action of a chat varies depending on the application.  At its most basic form, action is an API call that is only made when the bot receives the necessary parameters to satisfy a constraint. The Action is a database query using the search term(s) discovered from entity extraction.  In the case of our tool, Artemis, we are trying to get results to the users in an intuitive way which promotes intelligent hunting and effortless hypothesis checking.  The actions driven by Artemis are generally search and discovery, with the final result being an answer in the form of data.  Within the Endgame platform, Artemis allows the user to run efficient distributed search functions with parameters they specify through chat.
</p><h5>Intent</h5><p>The concept of an intent is intimately tied to actions, but it is the human-facing side of a set of actions.  For example, searching for processes connecting to an IP and searching for IPs that received the most traffic are both ‘network’ intents, but the actions are different enough that the API calls internally are distinct.  The intent could be considered the part that gathers the parameters for the action function, but it also may decide which exact action to call.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd0b6368b2e766a47/5dfaab460f82e627e3022459/blog-figure-2-foundation-of-artemis-architecture-endpoint.png" data-sys-asset-uid="bltd0b6368b2e766a47" alt="blog-figure-2-foundation-of-artemis-architecture-endpoint.png">
</p><figcaption>Figure 2 -- Foundation of Artemis architecture</figcaption><h5>Entities</h5><p>Entities are the final core component of our chatbot, Artemis. Entities can be thought of as the parameters needed to satisfy constraints stated within Intents that ultimately lead to the execution of Actions. For example, in the sentence: “Search processes for the filenames calc.exe;explorer.exe” we would like to perform Named Entity Recognition on the filenames. Unlike a finite list of known pizza toppings or airport codes, the list of possible process names is nearly infinite (well something more like 1.9820064666e+493 on Windows with a Latin-1) so we can’t possibly hardcode all of them. One option is to write (or copy from stack overflow) a regular expression akin to the 86 ascii characters for string lengths 1 to 255 to match filenames. Unfortunately, this would match all of the words in this paragraph as well, so we need the ‘file|filename|process’ tag specifier as well or use a Named Entity Recognizer model which we detail later.
</p><h2>Natural language understanding</h2><p>Although we built the architecture to handle a wide range of use cases, in every data scientist’s life, the inevitable handling of missing data must occur. To handle missing information, we had to improve Artemis’ ability to understand user supplied language. After all, we can only discover missing information after we identify what has already been supplied. We integrated a pipeline similar to what is depicted in Figure 3 to perform the following process:
</p><ol>
	<li>Take a user’s utterance and break apart the sentences into words (Tokenization)
	</li>
	<li>Create features from tokenized words (Bag-of-Words -- BoW)
	</li>
	<li>Perform Named Entity Recognition (NER) to extract the query parameters
	</li>
	<li>Redact the user utterance with entity labels (reduces the vocabulary Artemis needs to model)
	</li>
	<li>Extract Bag of Words to use as features against a supervised learning model
	</li>
	<li>Make a prediction on user input to determine intent (Intent Classification)
	</li>
	<li>Acquire all necessary data to carry out an action in Artemis (Perform Action).</li>
</ol><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt58bfd13443e4ca66/5dfaab53b24eb127e25aae55/blog-figure-3-artemis-natural-language-understanding-pipeline-endpoint.png" data-sys-asset-uid="blt58bfd13443e4ca66" alt="blog-figure-3-artemis-natural-language-understanding-pipeline-endpoint.png">
</p><figcaption>Figure 3 -- Artemis natural language understanding pipeline</figcaption><p>Within this pipeline, there are several key components that warrant additional clarification, and are described below.
</p><h5>Tokenizing</h5><p>Tokenizing refers to the breaking apart of sentences into separate words, often on whitespace. This facilitates the tagging and extraction in the subsequent steps.
</p><h5>POS tagging</h5><p>Parts-of-speech tagging is different from named entity recognition in that instead of a proper name like “Windows Filename” we are looking for more universal parts of speech like “noun” or “verb”, etc.  These parts of speech are defined through the grammar of the language, not by the problem domain (in our case: cybersecurity, aka computers).  Many linguists often use tags to facilitate building relevant models.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt92bd140be07a6ead/5dfaab6345b45a5a20263409/blog-figure-4-part-of-speech-tagging-on-tokenized-string.png" data-sys-asset-uid="blt92bd140be07a6ead" alt="blog-figure-4-part-of-speech-tagging-on-tokenized-string.png">
</p><figcaption>Figure 4 -- Part-of-speech tagging on a tokenized string<br><br></figcaption><h5>Entity extraction</h5><p>Entities are the items which are not parts of speech but are interesting to your domain of research.  For example, in the domain of information security you might want to extract operating systems, IP addresses or CVEs.  They are all generally “nouns” but you can assign more meaning to them by declaring them special entities in your NLP pipeline and either matching them explicitly or training named entity recognizers (NER) to identify what kind of entity they are.  For example, if you have a corpus of text where “the vulnerability CVE-2017-0069” shows up if someone else writes “the vulnerability CVE-2017-0107”, an NER model can predict or infer “CVE-2017-0107” refers to a CVE.  However, a regex may work better in production.
</p><h5>Intent classification</h5><p>Intent classification can be thought of as taking a user input and assigning the appropriate category. This process is achieved by training a supervised learning model, which we have explained in previous posts. Unlike other intent classifiers, we leverage the entity extractor prior to classifying the user intent so the intent model can see a “redacted” sentence. This redacted sentence removes unique entities (i.e. filename or domain names) and replaces them with a label (i.e. ENT-FILE or ENT-DOMAIN). By performing this step first we can significantly reduce the size of our vocabulary, a core feature in our model. This reduces the overall size of the model and increases the overall speed of a response!
</p><h5>Dependency parsing</h5><p>Dependency parsing involves analyzing a sentence based on the sequence of the words and which word comes next.  When shown in graphical form (Figure 5), you can see how each word depends on another and how those links and the words represent parts of speech. For instance, the phrase: “Show me network traffic from 10.0.100 to 10.0.5.10” should be trivial for the intent classifier to correctly predict. After all the bigram “network traffic” is a strong indicator of the intent search_network. Likewise, entity extraction is simple enough since the structure of IP addresses are unique (i.e. all numbers with 3 periods). But for Artemis to return the correct data we must understand the source and the destination IPs. Otherwise, we could return suboptimal results.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt75af4ab5be4228d9/5dfaab72bda0aa5d1ad54468/blog-figure-5-visualization-of-spacys-dependency-parser.png" data-sys-asset-uid="blt75af4ab5be4228d9" alt="blog-figure-5-visualization-of-spacys-dependency-parser.png">
</p><figcaption>Figure 5 -- Visualization of SpaCy’s dependency parser</figcaption><h2>Conclusion</h2><p>Behind every successful chatbot, there is a logical, scientifically-driven NLU model. Having walked through the core components that together comprise the data science behind Endgame’s chatbot, Artemis, we hope that some of the mystery behind chatbots is replaced with a better understanding of the depth of research on which it was built. However, as we continue to emphasize, neither a well-designed user experience nor a properly specified NLU approach alone are sufficient to meet the needs of security analysts and operators. NLU and user experience together are required to ensure a chatbot moves beyond hype and provides an operationally essential capability for our customers.
</p><h2>Resources
</h2><p>If you want to learn more about building your own bots and the tools required to pull it off we recommend the following resources:
</p><p><a href="http://www.wildml.com/2016/04/deep-learning-for-chatbots-part-1-introduction/">http://www.wildml.com/2016/04/deep-learning-for-ch...</a>
</p><p><a href="http://www.wildml.com/2016/07/deep-learning-for-chatbots-2-retrieval-based-model-tensorflow/">http://www.wildml.com/2016/07/deep-learning-for-ch...</a>
</p><p><a href="https://stanfy.com/blog/advanced-natural-language-processing-tools-for-bot-makers/">https://stanfy.com/blog/advanced-natural-language-...</a>
</p><p><a href="https://medium.com/lastmile-conversations/do-it-yourself-nlp-for-bot-developers-2e2da2817f3d#.q6xoefkp2">https://medium.com/lastmile-conversations/do-it-yo...</a>
</p><p><a href="https://medium.com/the-mission/how-i-turned-my-resume-into-a-bot-and-how-you-can-too-f03847352baa#.d74niojp5">https://medium.com/the-mission/how-i-turned-my-res...</a>
</p><p><a href="https://blog.acolyer.org/2016/06/27/on-chatbots/">https://blog.acolyer.org/2016/06/27/on-chatbots/</a>
</p><p><a href="https://medium.com/@surmenok/chatbot-architecture-496f5bf820ed#.k0aj6weqk">https://medium.com/@surmenok/chatbot-architecture-...</a>
</p><p><a href="https://api.ai/blog/2015/11/09/SlotFilling/">https://api.ai/blog/2015/11/09/SlotFilling/</a>
</p><p><a href="https://wit.ai/">https://wit.ai/</a>
</p><p><a href="https://x.ai/how-to-teach-a-machine-to-understand-us/">https://x.ai/how-to-teach-a-machine-to-understand-...</a>
</p><p><a href="http://www.nltk.org/">http://www.nltk.org/</a>
</p><p><a href="https://spacy.io/">https://spacy.io/</a>
</p><p><a href="https://textblob.readthedocs.io/en/dev/">https://textblob.readthedocs.io/en/dev/</a>
</p><p><a href="http://scikit-learn.org/stable/">http://scikit-learn.org/stable/</a>
</p><p><a href="https://keras.io/">https://keras.io/</a>
</p>

blog-banner-generic-blue.png

blog-thumb-generic-blue.png

Ask me anything: From query to natural language

<p>You’ve used them for directions, to order pizza, to ask about the weather. You’ve called them by their names Siri, Alexa, Cortana... You speak to them like you know them, like they can understand you. Why? Because they usually can. Intelligent assistants are on the rise and increasingly supporting our lives. In large part, this is driven by the user’s desire for ever more efficient querying and frictionless action. Instead of muddling through bloated interfaces, simply speaking or typing your queries or commands through a bot is often easier, faster, and seamless.</p><p>Bots aren’t just useful for helping us plan our day and listen to music. They are increasingly implemented across a wide range of industries, and have been introduced by companies to market and provide customer/sales support and recommendations. They can automate large portions of many data-driven tasks, correlating data, and providing context. They can go even further and suggest what you may want to do next.</p><p>In short, bots can take care of the data gathering, munging, and routine analysis that previously consumed significant resources. This is especially pertinent for the information security mission. Security operators and analysts encounter simple tasks and actions daily while executing their complex higher order work. Unfortunately, the elementary tasks currently consume an inordinate amount of time. With that in mind, we created Artemis, an intelligent assistant for cyber defense.</p><h2>Background</h2><p>In contrast to other fields where bots are ubiquitous, bots have yet to make a major impact in the information security industry. Due to the talent shortage and the vast and diverse array of data in information security, there is a unique opportunity for intelligent assistants to help improve the workflow of operators and analysts. Resource-constrained security teams may rely on alerts generated by security platforms, but these alerts often lack context and require additional collection and correlation to make a solid analytic judgement. Intelligent assistants can help automate repetitive tasks and provide a natural language interface to streamline workflows for interacting with endpoint data.</p><p>By removing friction inherent in accessing information during an investigation, we can free up the responder to focus on the core investigatory analysis which is difficult to automate. Questions like "Is this artifact present on other systems?”, "What does this file do?”, "Is this artifact malicious?”, and “What strings are present in this process’s memory?” require additional querying and collection as well as enrichment from other available sources. Today, this process often demands an intimate understanding of multiple data schemas to effectively derive meaning from the mountains of data available during an investigation.</p><h2>Artemis, an intelligent assistant</h2><p>Endgame introduces Artemis, a first-of-its-kind intelligent assistant for cyber defense operations with these challenges in mind. Artemis is the ideal enabler for an organization’s information security mission, allowing analysts, hunters, and forensic personnel to use natural language to perform precision-guided analytics on endpoint data. The following are some of the intelligent assistant’s key features.</p><h3>A conversational interface to your endpoints</h3><p>The user interface is simply a chat window we’ve been familiar with in tools from IRC to Slack. The user merely asks a question and the intelligent assistant surmises what needs to happen next. This leads to a natural and fluid two-way conversation towards the analyst’s objectives without needing to learn a complex query language to formulate the perfect query in one go.</p><h3>Expert recommendations and rapid contextualization</h3><p>Less experienced analysts may have difficulty knowing how to pivot through data in response to an event or alert. They may make the common mistake of pulling in so much data that it becomes overwhelming and the malicious activity is lost in the noise. Artemis solves this by helping answer questions about what to search for, during what timeframe, and from which endpoints to extract data. The experience of our subject matter experts who’ve worked as hunters and DFIR experts in government, military and financial sectors is baked directly into the technology and guides the workflow. For a given alert or issue, Artemis immediately suggests logical and effective next steps or actions.</p><h3>Focused collection and efficient operation</h3><p>The conversational interface of Artemis creates the query logic that runs on each targeted endpoint, culling data there instead of returning mass amounts of data to be centrally processed. In this way, the results of an Artemis conversation turn a big data problem into a good data solution. This lessens the physical resource strain in storage and network bandwidth, as well as the mental strain on analysts who have a helpful assistant guiding them, as needed, through the process.</p><h3>User directed workflows</h3><p>The conversational interface of Artemis streamlines workflows and enhances junior level analysts as well as power users. Importantly, analysts do not relinquish control. They remain in the driver’s seat. Furthermore, the power of Artemis’ advanced query and aggregation capabilities can be accessed via Endgame’s open API, allowing power users to derive many of the benefits of Artemis as they directly access their endpoint data programmatically.</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb5b038edf032f1bc/5dfaa02143a01a5be6375ab6/artemis.png" data-sys-asset-uid="bltb5b038edf032f1bc" alt="Artemis-the-intelligent-assistant-for-cyber-defense"/></p><figcaption>Artemis, the intelligent assistant for cyber defense</figcaption><h2>Conclusion</h2><p>Intelligent assistants offer great promise to expedite security analysis and operations, save time and resources, and help strengthen defense. Artemis is capable of doing all these things, ultimately reducing the frequency and impact of significant cyber intrusion. In an accompanying post, we will dig deeper into the bot architecture, including the natural language processing, algorithms, and user experience features. If you’ll be attending RSA, you can also <a href="https://www.endgame.com/resource/event/rsa-conference-2017">swing by our booth #1739</a> and hear our talk about bots for security.</p>

Artemis: An intelligent assistant for cyber defense

Artemis: an intelligent assistant for cyber defense

<p>Natural Language Processing (<a href="https://en.wikipedia.org/wiki/Natural_language_processing">NLP</a>) is a diverse field in computer science dedicated to automatically parsing and processing human language. NLP has been used to perform authorship attribution and sentiment analysis, as well as being a core function of IBM’s Watson and Apple’s Siri. NLP research is thriving due to the massive amounts of diverse text sources (e.g., Twitter and Wikipedia) and multiple disciplines using text analytics to derive insights. However, NLP can be used for more than human language processing and can be applied to any written text. Data scientists at Endgame apply NLP to security by building upon advanced NLP techniques to better identify and understand malicious code, moving toward an NLP methodology specifically designed for malware analysis—a Malicious Language Processing framework. The goal of this Malicious Language Processing framework is to operationalize NLP to address one of the security domain’s most challenging big data problems by automating and expediting the identification of malicious code hidden within benign code.</p><h3>How is NLP used in InfoSec?</h3><p>Before we delve into how Endgame leverages NLP, let’s explore a few different ways others have used it to tackle information security problems:</p><ul><li><a href="http://conferences.sigcomm.org/imc/2010/papers/p48.pdf">Domain Generation Algorithm classification</a> – Using NLP to identify malicious domains (e.g., blbwpvcyztrepfue.ru) from benign domains (e.g., cnn.com)</li><li><a href="https://www.usenix.org/legacy/events/woot11/tech/slides/yamaguchi.pdf">Source Code Vulnerability Analysis</a> – Determining function patterns associated with known vulnerabilities, then using NLP to identify other potentially vulnerable code segments.</li><li><a href="http://nlp.uned.es/~lurdes/araujo/eswa13_malicious_tweets.pdf">Phishing Identification</a> – A bag-of-words model determines the probability an email message contains a phishing attempt or not.</li><li>Malware Family Analysis –Topic modeling techniques assign samples of malware to families, as discussed in my colleague Phil Roth’s previous <a href="https://www.endgame.com/blog/examining-malware-python">blog</a>.</li></ul><p>Over the rest of this post, I’ll discuss how Endgame data scientists are using Malicious Language Processing to discover malicious language hidden within benign code.</p><h3>Data Acquisition/Corpus Building</h3><p>In order to perform NLP you must have a corpus, or collection of documents. While this is relatively straightforward in traditional NLP (e.g., APIs and web scraping) it is not necessarily the same in malware analysis. There are two primary techniques used to get data from malicious binaries: static and dynamic analysis.</p><figcaption><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt63811a93bc14888b/5dfd4fbb15c5fe6533ad76e7/endgame-nlp-disassembled-source-code.png" data-sys-asset-uid="blt63811a93bc14888b" alt="endgame-nlp-disassembled-source-code.png" style="display: block;margin: auto;"/><br />Fig 1. Disassembled source code</figcaption><p>Static analysis, also called source code analysis, is performed using a<a href="https://en.wikipedia.org/wiki/Disassembler">disassembler</a> providing output similar to the above (Fig 1). The disassembler presents a flat view of a binary, however structurally we lose important contextual information by not clearly delineating the logical order of instructions. In disassembly, jmp or call instructions should lead to different blocks of code that a standard flat file misrepresents. Luckily, static analysis tools exist that can provide call graphs that provide logical flow of instructions via a directed graph, like <a href="https://github.com/vivisect/vivisect">this</a> and <a href="https://radare.org/r/">this</a>.<br /></p><p>Dynamic analysis, often called behavioral analysis, is the collection of metadata from an executed binary in a sandbox environment. Dynamic analysis can provide data such as network access, registry/file activity, and API function monitoring. While dynamic analysis is often more informative, it is also more resource intensive, requiring a suite of collection tools and a sandboxed virtual environment. Alternatively, static analysis can be automated to generate disassembly over a large set of binaries generating a corpus ready for the NLP pipeline. At Endgame we have engineered a hybrid approach that automates the analysis of malicious binaries providing data scientists with metadata from both static and dynamic analysis.</p><h3>Lexical Parsing</h3><p>Lexical parsing is paramount to the NLP process as it provides the ability to turn large bodies of text into individual tokens. The goal of Malicious Language Processing is to parse a binary the same way an NLP researcher would parse a document:</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3fd50bed57da2cb1/5dfd4fdd631b8140b1f0417d/endgame-nlp-chart.png" data-sys-asset-uid="blt3fd50bed57da2cb1" alt="endgame-nlp-chart.png" style="display: block;margin: auto;"/></p><p>To generate the “words” in this process we must perform a few traditional NLP techniques. First is tokenization, the process of breaking down a string of text into meaningful segments called tokens.Segmenting on whitespace, new line characters, punctuation or regular expressions can generate tokens. (Fig 2)</p><figcaption><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc81d810e282f29ab/5dfd4fec4dfaba3e76b434cb/endgame-tokenized-disassembly.png" data-sys-asset-uid="bltc81d810e282f29ab" alt="endgame-tokenized-disassembly.png" style="display: block;margin: auto;"/><br />Fig 2. Tokenized disassembly</figcaption><p><br /></p><p>The next step in the lexical parsing process is to merge families of derivationally related words with similar meaning or text normalization. The two forms of this process are called stemming and lemmatization.</p><p>Stemming seeks to reduce a word to its functional stem. For example, in malware analysis this could reduce SetWindowTextA or SetWindowTextW to SetWindowText (Windows API), or JE, JLE, JNZ to JMP (x86 instructions) accounting for multiple variations of the essentially the same function.</p><p>Lemmatization is more difficult in general because it requires context or the part-of-speech tag of a word (e.g., noun, verb, etc.). In English, the word “better” has “good” as its lemma. In malware we do not yet have the luxury of parts-of-speech tagging, so lemmatization is not yet applicable. However, a rules-based dictionary that associates Windows API equivalents of C runtime functions may provide a step towards lemmatization, such as mapping _fread to ReadFile or _popen to CreateProcess.</p><h3>Semantic Networks</h3><p>Semantic or associative networks represent the co-occurrence of words within a body of text to gain an understanding of the semantic relationship between words. For each unique word in a corpus, a node is created on a directed graph. Links between words are generated with an associated weight based on the frequency that the two words co-occurred. The resulting graph can then be clustered to derive cliques or communities of functions that have similar behavior.</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2fc31c2a126bbc4d/5dfd500194b1d7403bbd3779/endgame-nlp.png" data-sys-asset-uid="blt2fc31c2a126bbc4d" alt="endgame-nlp.png" style="display: block;margin: auto;"/></p><p>A malicious language semantic network could aid in the generation of a lexical database capability for malware similar to WordNet. WordNet is a lexical database of English nouns, verbs, and adjectives grouped into sets of cognitive synonyms. Endgame data scientists are in the incipient stages of exploring ways to search and identify synonyms or synsets of malicious functions. Additionally, we hope to leverage our version of WordNet in the development of lemmatization and the Parts-of-Speech tagging within the Malicious Language Processing framework.</p><h3>Parts-of-Speech Tagging</h3><p>Parts-of-Speech (POS) tagging is a piece of software capable of tagging a list of tokens in a string of text with the correct language annotation, such as noun, verb, etc. POS Tagging is crucial for gaining a better understanding of text and establishing semantic relationship within a corpus. Above I mentioned that there is currently no representation of POS tagging for malware. Source code may be too abstract to break down into nouns, prepositions or adjectives. However, it is possible to treat subroutines as “sentences” and gain an understanding of functions used as subjects, verb and predicates. Using pseudo code for a process injection in Windows, for example, would yield the following from a Malicious Language Processing POS-Tagger:</p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd505b71f2097d85a/5dfd5014028cba3ef4ec65fe/endgame-process-injection.png" data-sys-asset-uid="bltd505b71f2097d85a" alt="endgame-process-injection.png" style="display: block;margin: auto;"/><h3>Closing Thoughts</h3><p>While the majority of the concepts mentioned in this post are being leveraged by Endgame today to better understand malware behavior, there is still plenty of work to be done. The concept of Malicious Language Processing is still in its infancy. We are currently working hard to expand the Malicious Language Processing framework by developing a malicious stop word list (a list of the most common words/functions in a corpus of binaries) and creating an anomaly detector capable of determining which function(s) do not belong in a benign block of code. With more research and larger, more diverse corpuses, we will be able to understand the behavior and basic capabilities of a suspicious binary without executing or having a human reverse engineer it. We view NLP as an additional tool in a data scientist’s toolkit, and a powerful means by which we can apply data science to security problems, quickly parsing the malicious from the benign.</p>

NLP For Security: Malicious Language Processing

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Bobby Filar

<p>Надсилаючи цю форму ви погоджуєтеся з <a href="/legal/terms-of-use">Умовами надання послуг Elastic</a>. Ваші особисті дані будуть опрацьовані відповідно з <a href="/legal/privacy-statement">Положеннями про конфіденційність Elastic</a>.</p>

Newsletter GDPR Text - Ukrainian

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

Intentionally Blank

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>提交即表示您確認已詳閱並同意我們的<a href="/legal/elastic-cloud-account-terms" target="_blank">服務條款</a>，且同意 Elastic 使用您在上方提供的個人資料<a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">與您聯絡</a>，為您提供相關產品和服務的資訊。如需詳細說明或隨時想停止收到產品和服務資訊，請參閱 <a href="/legal/privacy-statement/" target="_blank">Elastic 的隱私聲明</a>。</p>

Newsletter GDPR Text - TW

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p><p>By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.</p>

GDPR Text + Google Cloud

<p>Inviando la registrazione (1) esprimi il consenso ai <a href="/legal/terms-of-use">termini e condizioni di Elastic</a> e <a href="/legal/privacy-statement">all’informativa sulla privacy</a>, nonché (2) a ricevere saltuarie e-mail.</p>

Newsletter GDPR Text - Italian

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

Load more

Overview

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content.

You'll also receive an email with related content.

You'll also receive an email with related content

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

Author

Articles by Bobby Filar

Discovering anomalous patterns based on parent-child process relationships

Machine learning for cybersecurity: only as effective as your implementation

Ask me anything: From query to natural language

Artemis: an intelligent assistant for cyber defense

NLP For Security: Malicious Language Processing