Category Archives: Microsoft security intelligence

Secured-core PCs help customers stay ahead of advanced data theft

Researchers at the Eindhoven University of Technology recently revealed information around “Thunderspy,” an attack that relies on leveraging direct memory access (DMA) functionality to compromise devices. An attacker with physical access to a system can use Thunderspy to read and copy data even from systems that have encryption with password protection enabled.

Secured-core PCs provide customers with Windows 10 systems that come configured from OEMs with a set of hardware, firmware, and OS features enabled by default, mitigating Thunderspy and any similar attacks that rely on malicious DMA.

How Thunderspy works

Like any other modern attack, Thunderspy relies on not one but multiple building blocks being chained together. Below is a summary of how Thunderspy can be used to access a system where the attacker does not have the password needed to sign in. A video from the Thunderspy research team showing the attack is available here.

Step 1: A serial peripheral interface (SPI) flash programmer called Bus Pirate is plugged into the SPI flash of the device being attacked. This gives access to the Thunderbolt controller firmware and allows an attacker to copy it over to the attacker’s device

Step 2: The Thunderbolt Controller Firmware Patcher (tcfp), which is developed as part of Thunderspy, is used to disable the security mode enforced in the Thunderbolt firmware copied over using the Bus Pirate device in Step 1

Step 3: The modified insecure Thunderbolt firmware is written back to the SPI flash of the device being attacked

Step 4: A Thunderbolt-based attack device is connected to the device being attacked, leveraging the PCILeech tool to load a kernel module that bypasses the Windows sign-in screen

Diagram showing how the Thunderspy attack works

The result is that an attacker can access a device without knowing the sign-in password for the device. This means that even if a device was powered off or locked by the user, someone that could get physical access to the device in the time it takes to run the Thunderspy process could sign in and exfiltrate data from the system or install malicious software.

Secured-core PC protections

In order to counteract these targeted, modern attacks, Secured-core PCs use a defense-in-depth strategy that leverage features like Windows Defender System Guard and virtualization-based security (VBS) to mitigate risk across multiple areas, delivering comprehensive protection against attacks like Thunderspy.

Mitigating Steps 1 to 4 of the Thunderspy attack with Kernel DMA protection

Secured-core PCs ship with hardware and firmware that support Kernel DMA protection, which is enabled by default in the Windows OS. Kernel DMA protection relies on the Input/Output Memory Management Unit (IOMMU) to block external peripherals from starting and performing DMA unless an authorized user is signed in and the screen is unlocked. Watch this video from the 2019 Microsoft Ignite to see how Windows mitigates DMA attacks.

This means that even if an attacker was able to copy a malicious Thunderbolt firmware to a device, the Kernel DMA protection on a Secured-core PC would prevent any accesses over the Thunderbolt port unless the attacker gains the user’s password in addition to being in physical possession of the device, significantly raising the degree of difficulty for the attacker.

Hardening protection for Step 4 with Hypervisor-protected code integrity (HVCI)

Secured-core PCs ship with hypervisor protected code integrity (HVCI) enabled by default. HVCI utilizes the hypervisor to enable VBS and isolate the code integrity subsystem that verifies that all kernel code in Windows is signed from the normal kernel. In addition to isolating the checks, HVCI also ensures that kernel code cannot be both writable and executable, ensuring that unverified code does not execute.

HVCI helps to ensure that malicious kernel modules like the one used in Step 4 of the Thunderspy attack cannot execute easily as the kernel module would need to be validly signed, not revoked, and not rely on overwriting executable kernel code.

Modern hardware to combat modern threats

A growing portfolio of Secured-core PC devices from the Windows OEM ecosystem are available for customers. They provide a consistent guarantee against modern threats like Thunderspy with the variety of choices that customers expect to choose from when acquiring Windows hardware. You can learn more here: https://www.microsoft.com/en-us/windowsforbusiness/windows10-secured-core-computers

 

Nazmus Sakib

Enterprise and OS Security 

The post Secured-core PCs help customers stay ahead of advanced data theft appeared first on Microsoft Security.

Microsoft researchers work with Intel Labs to explore new deep learning approaches for malware classification

The opportunities for innovative approaches to threat detection through deep learning, a category of algorithms within the larger framework of machine learning, are vast. Microsoft Threat Protection today uses multiple deep learning-based classifiers that detect advanced threats, for example, evasive malicious PowerShell.

In continued exploration of novel detection techniques, researchers from Microsoft Threat Protection Intelligence Team and Intel Labs are collaborating to study new applications of deep learning for malware classification, specifically:

  • Leveraging deep transfer learning technique from computer vision to static malware classification
  • Optimizing deep learning techniques in terms of model size and leveraging platform hardware capabilities to improve execution of deep-learning malware detection approaches

For the first part of the collaboration, the researchers built on Intel’s prior work on deep transfer learning for static malware classification and used a real-world dataset from Microsoft to ascertain the practical value of approaching the malware classification problem as a computer vision task. The basis for this study is the observation that if malware binaries are plotted as grayscale images, the textural and structural patterns can be used to effectively classify binaries as either benign or malicious, as well as cluster malicious binaries into respective threat families.

The researchers used an approach that they called static malware-as-image network analysis (STAMINA). Using the dataset from Microsoft, the study showed that the STAMINA approach achieves high accuracy in detecting malware with low false positives.

The results and further technical details of the research are listed in the paper STAMINA: Scalable deep learning approach for malware classification and set the stage for further collaborative exploration.

The role of static analysis in deep learning-based malware classification

While static analysis is typically associated with traditional detection methods, it remains to be an important building block for AI-driven detection of malware. It is especially useful for pre-execution detection engines: static analysis disassembles code without having to run applications or monitor runtime behavior.

Static analysis produces metadata about a file. Machine learning classifiers on the client and in the cloud then analyze the metadata and determine whether a file is malicious. Through static analysis, most threats are caught before they can even run.

For more complex threats, dynamic analysis and behavior analysis build on static analysis to provide more features and build more comprehensive detection. Finding ways to perform static analysis at scale and with high effectiveness benefits overall malware detection methodologies.

To this end, the research borrowed knowledge from  computer vision domain to build an enhanced static malware detection framework that leverages deep transfer learning to train directly on portable executable (PE) binaries represented as images.

Analyzing malware represented as image

To establish the practicality of the STAMINA approach, which posits that malware can be classified at scale by performing static analysis on malware codes represented as images, the study covered three main steps: image conversion, transfer learning, and evaluation.

Diagram showing the steps for the STAMINA approach: pre-processing, transfer learning, and evaluation

First, the researchers prepared the binaries by converting them into two-dimensional images. This step involved pixel conversion, reshaping, and resizing. The binaries were converted into a one-dimensional pixel stream by assigning each byte a value between 0 and 255, corresponding to pixel intensity. Each pixel stream was then transformed into a two-dimensional image by using the file size to determine the width and height of the image.

The second step was to use transfer learning, a technique for overcoming the isolated learning paradigm and utilizing knowledge acquired for one task to solve related ones. Transfer learning has enjoyed tremendous success within several different computer vision applications. It accelerates training time by bypassing the need to search for optimized hyperparameters and different architectures—all this while maintaining high classification performance. For this study, the researchers used Inception-v1 as the base model.

The study was performed on a dataset of 2.2 million PE file hashes provided by Microsoft. This dataset was temporally split into 60:20:20 segments for training, validation, and test sets, respectively.

Diagram showing a DNN with pre-trained weights on natural images, and the last portion fine-tuned with new data

Finally, the performance of the system was measured and reported on the holdout test set. The metrics captured include recall at specific false positive range, along with accuracy, F1 score, and area under the receiver operating curve (ROC).

Findings

The joint research showed that applying STAMINA to real-world hold-out test data set achieved a recall of 87.05% at 0.1% false positive rate, and 99.66% recall and 99.07% accuracy at 2.58% false positive rate overall. The results certainly encourage the use of deep transfer learning for the purpose of malware classification. It helps accelerate training by bypassing the search for optimal hyperparameters and architecture searches, saving time and compute resources in the process.

The study also highlights the pros and cons of sample-based methods like STAMINA and metadata-based classification methods. For example, STAMINA can go in-depth into samples and extract additional signals that might not be captured in the metadata.  However, for bigger size applications, STAMINA becomes less effective due to limitations in converting billions of pixels into JPEG images and then resizing them. In such cases, metadata-based methods show advantages over our research.

Conclusion and future work

The use of deep learning methods for detecting threats drives a lot of innovation across Microsoft. The collaboration with Intel Labs researchers is just one of the ways in which Microsoft researchers and data scientists continue to explore novel ways to improve security overall.

This joint research is a good starting ground for more collaborative work. For example, the researchers plan to collaborate further on platform acceleration optimizations that can allow deep learning models to be deployed on client machines with minimal performance impact. Stay tuned.

 

Jugal Parikh, Marc Marino

Microsoft Threat Protection Intelligence Team

 

The post Microsoft researchers work with Intel Labs to explore new deep learning approaches for malware classification appeared first on Microsoft Security.

Lessons learned from the Microsoft SOC—Part 3c: A day in the life part 2

This is the sixth blog in the Lessons learned from the Microsoft SOC series designed to share our approach and experience from the front lines of our security operations center (SOC) protecting Microsoft and our Detection and Response Team (DART) helping our customers with their incidents. For a visual depiction of our SOC philosophy, download our Minutes Matter poster.

COVID-19 and the SOC

Before we conclude the day in the life, we thought we would share an analyst’s eye view of the impact of COVID-19. Our analysts are mostly working from home now and our cloud based tooling approach enabled this transition to go pretty smoothly. The differences in attacks we have seen are mostly in the early stages of an attack with phishing lures designed to exploit emotions related to the current pandemic and increased focus on home firewalls and routers (using techniques like RDP brute-forcing attempts and DNS poisoning—more here). The attack techniques they attempt to employ after that are fairly consistent with what they were doing before.

A day in the life—remediation

When we last left our heroes in the previous entry, our analyst had built a timeline of the potential adversary attack operation. Of course, knowing what happened doesn’t actually stop the adversary or reduce organizational risk, so let’s remediate this attack!

  1. Decide and act—As the analyst develops a high enough level of confidence that they understand the story and scope of the attack, they quickly shift to planning and executing cleanup actions. While this appears as a separate step in this particular description, our analysts often execute on cleanup operations as they find them.

Big Bang or clean as you go?

Depending on the nature and scope of the attack, analysts may clean up attacker artifacts as they go (emails, hosts, identities) or they may build a list of compromised resources to clean up all at once (Big Bang)

  • Clean as you go—For most typical incidents that are detected early in the attack operation, analysts quickly clean up the artifacts as we find them. This rapidly puts the adversary at a disadvantage and prevents them from moving forward with the next stage of their attack.
  • Prepare for a Big Bang—This approach is appropriate for a scenario where an adversary has already “settled in” and established redundant access mechanisms to the environment (frequently seen in incidents investigated by our Detection and Response Team (DART) at customers). In this case, analysts should avoid tipping off the adversary until full discovery of all attacker presence is discovered as surprise can help with fully disrupting their operation. We have learned that partial remediation often tips off an adversary, which gives them a chance to react and rapidly make the incident worse (spread further, change access methods to evade detection, inflict damage/destruction for revenge, cover their tracks, etc.).Note that cleaning up phishing and malicious emails can often be done without tipping off the adversary, but cleaning up host malware and reclaiming control of accounts has a high chance of tipping off the adversary.

These are not easy decisions to make and we have found no substitute for experience in making these judgement calls. The collaborative work environment and culture we have built in our SOC helps immensely as our analysts can tap into each other’s experience to help making these tough calls.

The specific response steps are very dependent on the nature of the attack, but the most common procedures used by our analysts include:

  • Client endpoints—SOC analysts can isolate a computer and contact the user directly (or IT operations/helpdesk) to have them initiate a reinstallation procedure.
  • Server or applications—SOC analysts typically work with IT operations and/or application owners to arrange rapid remediation of these resources.
  • User accounts—We typically reclaim control of these by disabling the account and resetting password for compromised accounts (though these procedures are evolving as a large amount of our users are mostly passwordless using Windows Hello or another form of MFA). Our analysts also explicitly expire all authentication tokens for the user with Microsoft Cloud App Security.
    Analysts also review the multi-factor phone number and device enrollment to ensure it hasn’t been hijacked (often contacting the user), and reset this information as needed.
  • Service Accounts—Because of the high risk of service/business impact, SOC analysts work with the service account owner of record (falling back on IT operations as needed) to arrange rapid remediation of these resources.
  • Emails—The attack/phishing emails are deleted (and sometimes cleared to prevent recovering of deleted emails), but we always save a copy of original email in the case notes for later search and analysis (headers, content, scripts/attachments, etc.).
  • Other—Custom actions can also be executed based on the nature of the attack such as revoking application tokens, reconfiguring servers and services, and more.

Automation and integration for the win

It’s hard to overstate the value of integrated tools and process automation as these bring so many benefits—improving the analysts daily experience and improving the SOC’s ability to reduce organizational risk.

  • Analysts spend less time on each incident, reducing the attacker’s time to operation—measured by mean time to remediate (MTTR).
  • Analysts aren’t bogged down in manual administrative tasks so they can react quickly to new detections (reducing mean time to acknowledge—MTTA).
  • Analysts have more time to engage in proactive activities that both reduce organization risk and increase morale by keeping them focused on the mission.

Our SOC has a long history of developing our own automation and scripts to make analysts lives easier by a dedicated automation team in our SOC. Because custom automation requires ongoing maintenance and support, we are constantly looking for ways to shift automation and integration to capabilities provided by Microsoft engineering teams (which also benefits our customers). While still early in this journey, this approach typically improves the analyst experience and reduces maintenance effort and challenges.

This is a complex topic that could fill many blogs, but this takes two main forms:

  • Integrated toolsets save analysts manual effort during incidents by allowing them to easily navigate multiple tools and datasets. Our SOC relies heavily on the integration of Microsoft Threat Protection (MTP) tools for this experience, which also saves the automation team from writing and supporting custom integration for this.
  • Automation and orchestration capabilities reduce manual analyst work by automating repetitive tasks and orchestrating actions between different tools. Our SOC currently relies on an advanced custom SOAR platform and is actively working with our engineering teams (MTP’s AutoIR capability and Azure Sentinel SOAR) on how to shift our learnings and workload onto those capabilities.

After the attacker operation has been fully disrupted, the analyst marks the case as remediated, which is the timestamp signaling the end of MTTR measurement (which started when the analyst began the active investigation in step 2 of the previous blog).

While having a security incident is bad, having the same incident repeated multiple times is much worse.

  1. Post-incident cleanup—Because lessons aren’t actually “learned” unless they change future actions, our analysts always integrate any useful information learned from the investigation back into our systems. Analysts capture these learnings so that we avoid repeating manual work in the future and can rapidly see connections between past and future incidents by the same threat actors. This can take a number of forms, but common procedures include:
    • Indicators of Compromise (IoCs)—Our analysts record any applicable IoCs such as file hashes, malicious IP addresses, and email attributes into our threat intelligence systems so that our SOC (and all customers) can benefit from these learnings.
    • Unknown or unpatched vulnerabilities—Our analysts can initiate processes to ensure that missing security patches are applied, misconfigurations are corrected, and vendors (including Microsoft) are informed of “zero day” vulnerabilities so that they can create security patches for them.
    • Internal actions such as enabling logging on assets and adding or changing security controls. 

Continuous improvement

So the adversary has now been kicked out of the environment and their current operation poses no further risk. Is this the end? Will they retire and open a cupcake bakery or auto repair shop? Not likely after just one failure, but we can consistently disrupt their successes by increasing the cost of attack and reducing the return, which will deter more and more attacks over time. For now, we must assume that adversaries will try to learn from what happened on this attack and try again with fresh ideas and tools.

Because of this, our analysts also focus on learning from each incident to improve their skills, processes, and tooling. This continuous improvement occurs through many informal and formal processes ranging from formal case reviews to casual conversations where they tell the stories of incidents and interesting observations.

As caseload allows, the investigation team also hunts proactively for adversaries when they are not on shift, which helps them stay sharp and grow their skills.

This closes our virtual shift visit for the investigation team. Join us next time as we shift to our Threat hunting team (a.k.a. Tier 3) and get some hard won advice and lessons learned.

…until then, share and enjoy!

P.S. If you are looking for more information on the SOC and other cybersecurity topics, check out previous entries in the series (Part 1 | Part 2a | Part 2b | Part 3a | Part 3b), Mark’s List (https://aka.ms/markslist), and our new security documentation site—https://aka.ms/securitydocs. Be sure to bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Or reach out to Mark on LinkedIn or Twitter.

The post Lessons learned from the Microsoft SOC—Part 3c: A day in the life part 2 appeared first on Microsoft Security.

Mitigating vulnerabilities in endpoint network stacks

The skyrocketing demand for tools that enable real-time collaboration, remote desktops for accessing company information, and other services that enable remote work underlines the tremendous importance of building and shipping secure products and services. While this is magnified as organizations are forced to adapt to the new environment created by the global crisis, it’s not a new imperative. Microsoft has been investing heavily in security, and over the years our commitment to building proactive security into products and services has only intensified.

To help deliver on this commitment, we continuously find ways to improve and secure Microsoft products. One aspect of our proactive security work is finding vulnerabilities and fixing them before they can be exploited. Our strategy is to take a holistic approach and drive security throughout the engineering lifecycle. We do this by:

  • Building security early into the design of features.
  • Developing tools and processes that proactively find vulnerabilities in code.
  • Introducing mitigations into Windows that make bugs significantly harder to exploit.
  • Having our world-class penetration testing team test the security boundaries of the product so we can fix issues before they can impact customers.

This proactive work ensures we are continuously making Windows safer and finding as many issues as possible before attackers can take advantage of them. In this blog post we will discuss a recent vulnerability that we proactively found and fixed and provide details on tools and techniques we used, including a new set of tools that we built internally at Microsoft. Our penetration testing team is constantly testing the security boundaries of the product to make it more secure, and we are always developing tools that help them scale and be more effective based on the evolving threat landscape. Our investment in fuzzing is the cornerstone of our work, and we are constantly innovating this tech to keep on breaking new ground.

Proactive security to prevent the next WannaCry

In the past few years, much of our team’s efforts have been focused on uncovering remote network vulnerabilities and preventing events like the WannaCry and NotPetya outbreaks. Some bugs we have recently found and fixed include critical vulnerabilities that could be leveraged to exploit common secure remote communication tools like RDP or create ransomware issues like WannaCry: CVE-2019-1181 and CVE-2019-1182 dubbed “DejaBlue“, CVE-2019-1226 (RCE in RDP Server), CVE-2020-0611 (RCE in RDP Client), and CVE-2019-0787 (RCE in RDP client), among others.

One of the biggest challenges we regularly face in these efforts is the sheer volume of code we analyze. Windows is enormous and continuously evolving 5.7 million source code files, with more than 3,500 developers doing 1,100 pull requests per day in 440 official branches. This rapid cadence and evolution allows us to add new features as well proactively drive security into Windows.

Like many security teams, we frequently turn to fuzzing to help us quickly explore and assess large codebases. Innovations we’ve made in our fuzzing technology have made it possible to get deeper coverage than ever before, resulting in the discovery of new bugs, faster. One such vulnerability is the remote code vulnerability (RCE) in Microsoft Server Message Block version 3 (SMBv3) tracked as CVE-2020-0796 and fixed on March 12, 2020.

In the following sections, we will share the tools and techniques we used to fuzz SMB, the root cause of the RCE vulnerability, and relevant mitigations to exploitation.

Fully deterministic person-in-the-middle fuzzing

We use a custom deterministic full system emulator tool we call “TKO” to fuzz and introspect Windows components.  TKO provides the capability to perform full system emulation and memory snapshottting, as well as other innovations.  As a result of its unique design, TKO provides several unique benefits to SMB network fuzzing:

  • The ability to snapshot and fuzz forward from any program state.
  • Efficiently restoring to the initial state for fast iteration.
  • Collecting complete code coverage across all processes.
  • Leveraging greater introspection into the system without too much perturbation.

While all of these actions are possible using other tools, our ability to seamlessly leverage them across both user and kernel mode drastically reduces the spin-up time for targets. To learn more, check out David Weston’s recent BlueHat IL presentation “Keeping Windows secure”, which touches on fuzzing, as well as the TKO tool and infrastructure.

Fuzzing SMB

Given the ubiquity of SMB and the impact demonstrated by SMB bugs in the past, assessing this network transfer protocol has been a priority for our team. While there have been past audits and fuzzers thrown against the SMB codebase, some of which postdate the current SMB version, TKO’s new capabilities and functionalities made it worthwhile to revisit the codebase. Additionally, even though the SMB version number has remained static, the code has not! These factors played into our decision to assess the SMB client/server stack.

After performing an initial audit pass of the code to understand its structure and dataflow, as well as to get a grasp of the size of the protocol’s state space, we had the information we needed to start fuzzing.

We used TKO to set up a fully deterministic feedback-based fuzzer with a combination of generated and mutated SMB protocol traffic. Our goal for generating or mutating across multiple packets was to dig deeper into the protocol’s state machine. Normally this would introduce difficulties in reproducing any issues found; however, our use of emulators made this a non-issue. New generated or mutated inputs that triggered new coverage were saved to the input corpus. Our team had a number of basic mutator libraries for different scenarios, but we needed to implement a generator. Additionally, we enabled some of the traditional Windows heap instrumentation using verifier, turning on page heap for SMB-related drivers.

We began work on the SMBv2 protocol generator and took a network capture of an SMB negotiation with the aim of replaying these packets with mutations against a Windows 10, version 1903 client. We added a mutator with basic mutations (e.g., bit flips, insertions, deletions, etc.) to our fuzzer and kicked off an initial run while we continued to improve and develop further.

Figure 1. TKO fuzzing workflow

A short time later, we came back to some compelling results. Replaying the first crashing input with TKO’s kdnet plugin revealed the following stack trace:

> tkofuzz.exe repro inputs\crash_6a492.txt -- kdnet:conn 127.0.0.1:50002

Figure 2. Windbg stack trace of crash

We found an access violation in srv2!Smb2CompressionDecompress.

Finding the root cause of the crash

While the stack trace suggested that a vulnerability exists in the decompression routine, it’s the parsing of length counters and offsets from the network that causes the crash. The last packet in the transaction needed to trigger the crash has ‘\xfcSMB’ set as the first bytes in its header, making it a COMPRESSION_TRANSFORM packet.

Figure 3. COMPRESSION_TRANSFORM packet details

The SMBv2 COMPRESSION_TRANSFORM packet starts with a COMPRESSION_TRANSFORM_HEADER, which defines where in the packet the compressed bytes begin and the length of the compressed buffer.

typedef struct _COMPRESSION_TRANSFORM_HEADER

{

UCHAR   Protocol[4]; // Contains 0xFC, 'S', 'M', 'B'

ULONG    OriginalMessageSize;

USHORT AlgorithmId;

USHORT Flags;

ULONG Length;

}

In the srv2!Srv2DecompressData in the graph below, we can find this COMPRESSION_TRANSFORM_HEADER struct being parsed out of the network packet and used to determine pointers being passed to srv2!SMBCompressionDecompress.

Figure 4. Srv2DecompressData graph

We can see that at 0x7e94, rax points to our network buffer, and the buffer is copied to the stack before the OriginalCompressedSegmentSize and Length are parsed out and added together at 0x7ED7 to determine the size of the resulting decompressed bytes buffer. Overflowing this value causes the decompression to write its results out of the bounds of the destination SrvNet buffer, in an out-of-bounds write (OOBW).

Figure 5. Overflow condition

Looking further, we can see that the Length field is parsed into esi at 0x7F04, added to the network buffer pointer, and passed to CompressionDecompress as the source pointer. As Length is never checked against the actual number of received bytes, it can cause decompression to read off the end of the received network buffer. Setting this Length to be greater than the packet length also causes the computed source buffer length passed to SmbCompressionDecompress to underflow at 0x7F18, creating an out-of-bounds read (OOBR) vulnerability. Combining this OOBR vulnerability with the previous OOBW vulnerability creates the necessary conditions to leak addresses and create a complete remote code execution exploit.

Figure 6. Underflow condition

Windows 10 mitigations against remote network vulnerabilities

Our discovery of the SMBv3 vulnerability highlights the importance of revisiting protocol stacks regularly as our tools and techniques continue to improve over time. In addition to the proactive hunting for these types of issues, the investments we made in the last several years to harden Windows 10 through mitigations like address space layout randomization (ASLR), Control Flow Guard (CFG), InitAll, and hypervisor-enforced code integrity (HVCI) hinder trivial exploitation and buy defenders time to patch and protect their networks.

For example, turning vulnerabilities like the ones discovered in SMBv3 into working exploits requires finding writeable kernel pages at reliable addresses, a task that requires heap grooming and corruption, or a separate vulnerability in Windows kernel address space layout randomization (ASLR). Typical heap-based exploits taking advantage of a vulnerability like the one described here would also need to make use of other allocations, but Windows 10 pool hardening helps mitigate this technique. These mitigations work together and have a cumulative effect when combined, increasing the development time and cost of reliable exploitation.

Assuming attackers gain knowledge of our address space, indirect jumps are mitigated by kernel-mode CFG. This forces attackers to either use data-only corruption or bypass Control Flow Guard via stack corruption or yet another bug. If virtualization-based security (VBS) and HVCI are enabled, attackers are further constrained in their ability to map and modify memory permissions.

On Secured-core PCs these mitigations are enabled by default.  Secured-core PCs combine virtualization, operating system, and hardware and firmware protection. Along with Microsoft Defender Advanced Threat Protection, Secured-core PCs provide end-to-end protection against advanced threats.

While these mitigations collectively lower the chances of successful exploitation, we continue to deepen our investment in identifying and fixing vulnerabilities before they can get into the hands of adversaries.

 

The post Mitigating vulnerabilities in endpoint network stacks appeared first on Microsoft Security.

Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation

The latest round of MITRE ATT&CK evaluations proved yet again that Microsoft customers can trust they are fully protected even in the face of such an advanced attack as APT29. When looking at protection results out of the box, without configuration changes, Microsoft Threat Protection (MTP):

  • Provided nearly 100 percent coverage across the attack chain stages.
  • Delivered leading out-of-box visibility into attacker activities, dramatically reducing manual work for SOCs vs. vendor solutions that relied on specific configuration changes.
  • Had the fewest gaps in visibility, diminishing attacker ability to operate undetected.

Beyond just detection and visibility, automation, prioritization, and prevention are key to stopping this level of advanced attack. During testing, Microsoft:

  • Delivered automated real-time alerts without the need for configuration changes or custom detections; Microsoft is one of only three vendors who did not make configuration changes or rely on delayed detections.
  • Flagged more than 80 distinct alerts, and used built-in automation to correlate these alerts into only two incidents that mirrored the two MITRE ATT&CK simulations, improving SOC analyst efficiency and reducing attacker dwell time and ability to persist.
  • Identified seven distinct steps during the attack in which our protection features, which were disabled during testing, would have automatically intervened to stop the attack.

Microsoft Threat Experts provided further in-depth context and recommendations for further investigation through our comprehensive in-portal forensics. The evaluation also proved how Microsoft Threat Protection goes beyond just simple visibility into attacks, but also records all stages of the attack in which MTP would have stepped in to block the attack and automatically remediate any affected assets.

While the test focused on endpoint detection and response, MITRE’s simulated APT29 attack spans multiple attack domains, creating opportunities to empower defenders beyond just endpoint protection. Microsoft expanded defenders’ visibility beyond the endpoint with Microsoft Threat Protection (MTP). MTP has been recognized by both Gartner and Forrester as having extended detection and response capabilities. MTP takes protection to the next level by combining endpoint protection from Microsoft Defender ATP (EDR) with protection for email and productivity tools (Office 365 ATP), identity (Azure ATP), and cloud applications (Microsoft Cloud App Security [MCAS]). Below, we will share a deep-dive analysis and explanation of how MTP successfully demonstrated novel optic and detection advantages throughout the MITRE evaluation that only our solution can provide.

Incident-based approach enables real-time threat prioritization and remediation

Analyzing the MITRE evaluation results from the lens of breadth and coverage, as the diagrams below show, MTP provided exceptional coverage for all but one of the 19 tested attack stages. This means that in real life, the SOC would have received alerts and given full visibility into each of the stages of the two simulated attack scenarios across initial access, deployment of tools, discovery, persistence, credential access, lateral movement, and exfiltration. In Microsoft Threat Protection, alerts carry with them rich context—including a detailed process tree showing the recorded activities (telemetry) that led to the detection, the assets involved, all supporting evidence, as well as a description of what the alert means and recommendations for SOC action. Note that true alerts are attributed in the MITRE evaluation with the “Alert” modifier, and not all items marked as “Tactic” or “Technique” are actual alerts.

MTP detection coverage across the attack kill-chain stages, with block opportunities.

Figure 1: MTP detection coverage across the attack kill-chain stages, with block opportunities.

Figure 1: MTP detection coverage across the attack kill-chain stages, with block opportunities.

Note: Step 10, persistence execution, is registered as a miss due to a software bug, discovered during the test, that restricted visibility on Step 10—“Persistence Execution.” These evaluations are a valuable opportunity to continually improve our product, and this bug was fixed shortly after testing completed.

The MITRE APT29 evaluation focused solely on detection of an advanced attack; it did not measure whether or not participants were able to also prevent an attack. However, we believe that real-world protection is more than just knowing that an attack occurred—prevention of the attack is a critical element. While protections were intentionally turned off to allow the complete simulation to run, using the audit-only prevention configuration, MTP also captured and documented where the attack would have been completely prevented, including—as shown in the diagram above – the very start of the breach, if protections had been left on.

Microsoft Threat Protection also demonstrated how it promotes SOC efficiency and reduces attacker dwell time and sprawl. SOC alert fatigue is a serious problem; raising a large volume of alerts to investigate does not help SOC analysts understand where to devote their limited time and resources. Detection and response products must prioritize the most important attacker actions with the right context in near real time.

In contrast to alert-only approaches, MTP’s incident-based approach automatically identifies complex links between attacker activities in different domains including endpoint, identity, and cloud applications at an altitude that only Microsoft can provide because we have optics into each of these areas. In this scenario, MTP connected seemingly unrelated alerts using supporting telemetry across domains into just two end-to-end incidents, dramatically simplifying prioritization, triage, and investigation. In real life, this also simplifies automated response and enables SOC teams to scale capacity and capabilities. MITRE addresses a similar problem with the “correlated” modifier on telemetry and alerts but does not reference incidents (just yet).

Figure 2: MTP portal showing 2nd day attack incident including correlated alerts and affected assets.

Figure 2: MTP portal showing 2nd day attack incident including correlated alerts and affected assets.

Figure 3: 2nd day incident with all correlated alerts for SOC efficiency, and the attack incident graph.

Figure 3: 2nd day incident with all correlated alerts for SOC efficiency, and the attack incident graph.

Microsoft is the leader in out-of-the-box performance

Simply looking at the number of simulation steps covered—or, alternatively, at the number of steps with no coverage, where less is more—the MITRE evaluation showed MTP provided the best protection with zero delays or configuration changes.

Microsoft believes protection must be durable without requiring a lot of SOC configuration changes (especially during an ongoing attack), and it should not create friction by delivering false positives.

The chart below shows Microsoft as the vendor with the least number of steps categorized as “None” (also referred to as “misses”) out of the box. The chart also shows the number of detections marked with “Configuration Change” modifier, which was done quite considerably, as well as delayed detections (“Delayed” modifier), which indicate in-flight modifications and latency in detections.

Microsoft is one of only three vendors that made no modifications or had any delays during the test.

Microsoft is one of only three vendors that made no modifications or had any delays during the test.

Similarly, when looking at visibility and coverage for the 57 MITRE ATT&CK techniques replicated during this APT29 simulation, Microsoft’s coverage shows top performance at 95 percent of the techniques covered, as shown in the chart below.

A product’s coverage of techniques is an important consideration for customers when evaluating security solutions, often with specific attacker(s) in mind, which in turn determines the attacker techniques they are most concerned with and, consequently, the coverage they most care about.
Figure 5: Coverage across all attack techniques in the evaluation.

Figure 5: Coverage across all attack techniques in the evaluation.

MTP provided unique detection and visibility across identity, cloud, and endpoints

The powerful capabilities of Microsoft Threat Protection originate from unique signals not just from endpoints but also from identity and cloud apps. This combination of capabilities provides coverage where other solutions may lack visibility. Below are three examples of sophisticated attacks simulated during the evaluation that span across domains (i.e., identity, cloud, endpoint) and showcase the unique visibility and unmatched detections provided by MTP:

  • Detecting the most dangerous lateral movement attack: Golden Ticket—Unlike other vendors, MTP’s unique approach for detecting Golden Ticket attacks does not solely rely on endpoint-based command-line sequences, PowerShell strings like “Invoke-Mimikatz”, or DLL-loading heuristics that can all be evaded by advanced attackers. MTP leverages direct optics into the Domain Controller via Azure ATP, the identity component of MTP. Azure ATP detects Golden Ticket attacks using a combination of machine learning and protocol heuristics by looking at anomalies such as encryption downgrade, forged authorization data, nonexistent account, ticket anomaly, and time anomaly. MTP is the only product that provided the SOC context of the encryption downgrade, together with the source and target machines, resources accessed, and the identities involved.
  • Exfiltration over alternative protocol: Catching and stopping attackers as they move from endpoint to cloud—MTP leverages exclusive signal from Microsoft Cloud App Security (MCAS), the cloud access security broker (CASB) component of MTP, which provides visibility and alerts for a large variety of cloud services, including OneDrive. Using the MCAS Conditional Access App Control mechanism, MTP was able to monitor cloud traffic for data exfiltration and raise an automatic alert when a ZIP archive with stolen files was exfiltrated to a remote OneDrive account controlled by the attacker. It is important to note the OneDrive account used by MITRE Redteam was unknown to the Microsoft team prior to being automatically detected during the evaluation.
  • Uncovering Remote System Discovery attacks that abuse LDAP—Preceding lateral movement, attackers commonly abuse the Lightweight Directory Access Protocol (LDAP) protocol to query user groups and user information. Microsoft introduced a powerful new sensor for unique visibility of LDAP queries, aiding security analyst investigation and allowing detection of suspicious patterns of LDAP activity. Through this sensor, Microsoft Defender ATP, the endpoint component of MTP, avoids reliance on PowerShell strings and snippets. Rather, Microsoft Defender ATP uses the structure and fields of each LDAP query originating from the endpoint to the Domain Controller (DC) to spot broad requests or suspicious queries for accounts and groups. Where possible, MTP also combines and correlates LDAP attacks detected on the endpoint by Microsoft Defender ATP with LDAP events seen on the DC by Azure ATP.

Figure 6: Golden Ticket alert based on optics on Domain Controller activity.

Figure 6: Golden Ticket alert based on optics on Domain Controller activity.

Figure 7: Suspicious LDAP activity detected using deep native OS sensor.

Figure 7: Suspicious LDAP activity detected using deep native OS sensor.

Microsoft Threat Experts: Threat context and hunting skills when and where needed

In this edition of MITRE ATT&CK evaluation, for the first time, Microsoft products were configured to take advantage of the managed threat hunting service Microsoft Threat Experts. Microsoft Threat Experts provides proactive hunting for the most important threats in the network, including human adversary intrusions, hands-on-keyboard attacks, or advanced attacks like cyberespionage. During the evaluation, the service operated with the same strategy normally used in real customer incidents: the goal is to send targeted attack notifications that provide real value to analysts with contextual analysis of the activities. Microsoft Threat Experts enriches security signals and raises the risk level appropriately so that the SOC can focus on what’s important, and breaches don’t go unnoticed.

Microsoft Threat Experts notifications stand out among other participating vendors as these notifications are fully integrated into the experience, incorporated into relevant incidents and connected to relevant events, alerts, and other evidence. Microsoft Threat Experts is enabling SOC teams to effortlessly and seamlessly receive and merge additional data and recommendations in the context of the incident investigation.

Figure 8: Microsoft Threat Experts alert integrates into the portal and provides hyperlinked rich context.

Figure 8: Microsoft Threat Experts alert integrates into the portal and provides hyperlinked rich context.

Transparency in testing is key to threat detection, prevention

Microsoft Threat Protection delivers real-world detection, response, and, ultimately, protection from advanced attacks, as demonstrated in the latest MITRE evaluation. Core to MITRE’s testing approach is emulating real-world attacks to understand whether solutions are able to adequately detect and respond to them. We saw that Microsoft Threat Protection provided clear detection across all categories and delivered additional context that shows the full scope of impact across an entire environment. MTP empowers customers not only to detect attacks, offering human experts as needed, and easily return to a secured state with automated remediation. As is true in the real world, our human Threat Experts were available on demand to provide even more context and help with.

We thank MITRE for the opportunity to contribute to the test with unique threat intelligence that only three participants stepped forward to share. Our unique intelligence and breadth of signal and visibility across the entire environment is what enables us to continuously score top marks. We look forward to participating in the next evaluation, and we welcome your feedback and partnership throughout our journey.

Thanks,

Moti and the entire Microsoft Threat Protection team

Related Links:

 

The post Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation appeared first on Microsoft Security.