Microsoft and partners design new device security requirements to protect against targeted firmware attacks

Microsoft Malware Protection Center - Mon, 10/21/2019 - 11:00am

Recent developments in security research and real-world attacks demonstrate that as more protections are proactively built into the OS and in connected services, attackers are looking for other avenues of exploitation with firmware emerging as a top target. In the last three years alone, NIST’s National Vulnerability Database has shown nearly a five-fold increase in the number of firmware vulnerabilities discovered.

To combat threats specifically targeted at the firmware and operating system levels, we’re announcing a new initiative we’ve been working on with partners to design what we call Secured-core PCs. These devices, created in partnership with our PC manufacturing and silicon partners, meet a specific set of device requirements that apply the security best practices of isolation and minimal trust to the firmware layer, or the device core, that underpins the Windows operating system. These devices are designed specifically for industries like financial services, government and healthcare, and for workers that handle highly-sensitive IP, customer or personal data, including PII as these are higher value targets for nation-state attackers.


In late 2018, security researchers discovered that hacking group, Strontium has been using firmware vulnerabilities to target systems in the wild with malware delivered through a firmware attack. As a result, the malicious code was hard to detect and difficult to remove – it could persist even across common cleanup procedures like an OS re-install or a hard drive replacement.

Why attackers and researchers are devoting more effort toward firmware

Firmware is used to initialize the hardware and other software on the device and has a higher level of access and privilege than the hypervisor and operating system kernel thereby making it an attractive target for attackers. Attacks targeting firmware can undermine mechanisms like secure boot and other security functionality implemented by the hypervisor or operating system making it more difficult to identify when a system or user has been compromised. Compounding the problem is the fact that endpoint protection and detection solutions have limited visibility at the firmware layer given that they run underneath of the operating system, making evasion easier for attackers going after firmware.

What makes a Secured-core PC?

Secured-core PCs combine identity, virtualization, operating system, hardware and firmware protection to add another layer of security underneath the operating system. Unlike software-only security solutions, Secured-core PCs are designed to prevent these kinds of attacks rather than simply detecting them. Our investments in Windows Defender System Guard and Secured-core PC devices are designed to provide the rich ecosystem of Windows 10 devices with uniform assurances around the integrity of the launched operating system and verifiable measurements of the operating system launch to help mitigate against threats taking aim at the firmware layer. These requirements enable customers to boot securely, protect the device from firmware vulnerabilities, shield the operating system from attacks, prevent unauthorized access to devices and data, and ensure that identity and domain credentials are protected.

The built-in measurements can be used by SecOps and IT admins to remotely monitor the health of their systems using System Guard runtime attestation and implement a zero-trust network rooted in hardware. This advanced firmware security works in concert with other Windows features to ensure that Secured-core PCs provide comprehensive protections against modern threats.


Removing trust from the firmware

Starting with Windows 8, we introduced Secure Boot to mitigate the risk posed by malicious bootloaders and rootkits that relied on Unified Extensible Firmware Interface (UEFI) firmware to only allow properly signed bootloaders like the Windows boot manager to execute. This was a significant step forward to protect against these specific types of attacks. However, since firmware is already trusted to verify the bootloaders, Secure Boot on its own does not protect from threats that exploit vulnerabilities in the trusted firmware. That’s why we worked with our partners to ensure these new Secured-core capabilities are shipped in devices right out of the box.

Using new hardware capabilities from AMD, Intel, and Qualcomm, Windows 10 now implements System Guard Secure Launch as a key Secured-core PC device requirement to protect the boot process from firmware attacks. System Guard uses the Dynamic Root of Trust for Measurement (DRTM) capabilities that are built into the latest silicon from AMD, Intel, and Qualcomm to enable the system to leverage firmware to start the hardware and then shortly after re-initialize the system into a trusted state by using the OS boot loader and processor capabilities to send the system down a well-known and verifiable code path. This mechanism helps limit the trust assigned to firmware and provides powerful mitigation against cutting-edge, targeted threats against firmware. This capability also helps to protect the integrity of the virtualization-based security (VBS) functionality implemented by the hypervisor from firmware compromise. VBS then relies on the hypervisor to isolate sensitive functionality from the rest of the OS which helps to protect the VBS functionality from malware that may have infected the normal OS even with elevated privileges. Protecting VBS is critical since it is used as a building block for important OS security capabilities like Windows Defender Credential Guard which protects against malware maliciously using OS credentials and Hypervisor-protected Code Integrity (HVCI) which ensures that a strict code integrity policy is enforced and that all kernel code is signed and verified.


Being able to measure that the device booted securely is another critical piece of this additional layer of protection from firmware compromise that gives admins added confidence that their endpoints are safe. That’s why we implemented Trusted Platform Module 2.0 (TPM) as one of the device requirements for Secured-core PCs. By using the Trusted Platform Module 2.0 (TPM) to measure the components that are used during the secure launch process, we help customers enable zero trust networks using System Guard runtime attestation. Conditional access policies can be implemented based on the reports provided by the System Guard attestation client running in the isolated VBS environment.

In addition to the Secure Launch functionality, Windows implements additional safeguards that operate when the OS is running to monitor and restrict the functionality of potentially dangerous firmware functionality accessible through System Management Mode (SMM).

Beyond the hardware protection of firmware featured in Secured-core PCs, Microsoft recommends a defense-in-depth approach including security review of code, automatic updates, and attack surface reduction. Microsoft has provided an open-source firmware project called Project-Mu that PC manufactures can use as a starting point for secure firmware.

How to get a Secured-core PC

Our ecosystem partnerships have enabled us to add this additional layer of security in devices that are designed for highly-targeted industries and end-users who handle mission-critical data in some of the most data-sensitive industries like government, financial services, and healthcare, right-out-of-the-box. These innovations build on the value of Windows 10 Pro that comes with built-in protections like firewall, secure boot, and file-level information-loss protection which are standard on every device.

More information on devices that are verified Secured-core PC including those from Dell, Dynabook, HP, Lenovo, Panasonic and Surface can be found on our web page.


David Weston (@dwizzzleMSFT)
Partner Director, OS Security

The post Microsoft and partners design new device security requirements to protect against targeted firmware attacks appeared first on Microsoft Security.

Best practices for adding layered security to Azure security with Check Point’s CloudGuard IaaS

Microsoft Malware Protection Center - Thu, 10/17/2019 - 9:00pm

The cloud is changing the way we build and deploy applications. Most enterprises will benefit from the cloud’s many advantages through hybrid, multi, or standalone cloud architectures. A recent report showed that 42 percent of companies have a multi-cloud deployment strategy.

The advantages of the cloud include flexibility, converting large upfront infrastructure investments to smaller monthly bills (for example, the CAPEX to OPEX shift), agility, scalability, the capability to run applications and workloads at high speed, as well as high levels of reliability and availability.

However, cloud security is often an afterthought in this process. Some worry that it may slow the momentum of organizations that are migrating workloads into the cloud. Traditional IT security teams may be hesitant to implement new cloud security processes, because to them the cloud may be daunting or confusing, or just new and unknown.

Although the concepts may seem similar, cloud security is different than traditional enterprise security. Additionally, there may also be industry-specific compliance and security standards to be met.

Public cloud vendors have defined the Shared Responsibility Model where the vendor is responsible for the security “of” their cloud, while their customers are responsible for the security “in” the cloud.

The Shared Responsibility Model (Source: Microsoft Azure).

Cloud deployments include multi-layered components, and the security requirements are often different per layer and per component. Often, the ownership of security is blurred when it comes to the application, infrastructure, and sometimes even the cloud platform—especially in multi-cloud deployments.

Cloud vendors, including Microsoft, offer fundamental network-layer, data-layer, and other security tools for use by their customers. Security analysts, managed security service providers, and advanced cloud customers recommend layering on advanced threat prevention and network-layer security solutions to protect against modern-day attacks. These specialized tools evolve at the pace of industry threats to secure the organization’s cloud perimeters and connection points.

Check Point is a leader in cloud security and the trusted security advisor to customers migrating workloads into the cloud.

Check Point’s CloudGuard IaaS helps protect assets in the cloud with dynamic scalability, intelligent provisioning, and consistent control across public, private, and hybrid cloud deployments. CloudGuard IaaS supports Azure and Azure Stack. Customers using CloudGuard IaaS can securely migrate sensitive workloads, applications, and data into Azure and thereby improve their security.

But how well does CloudGuard IaaS conform to Microsoft’s best practices?

Principal Program Manager of Azure Networking, Dr. Reshmi Yandapalli (DAOM), published a blog post titled Best practices to consider before deploying a network virtual appliance earlier this year, which outlined considerations when building or choosing Azure security and networking services. Dr. Yandapalli defined four best practices for networking and security ISVs—like Check Point—to improve the cloud experience for Azure customers.

I discussed Dr. Yandapalli’s four best practices with Amir Kaushansky, Check Point’s Head of Cloud Network Security Product Management. Amir’s responsibilities include the CloudGuard IaaS roadmap and coordination with the R&D/development team.

1. Azure accelerated networking support

Dr. Yandapalli’s first best practice in her blog is that the ISV’s Azure security solution is available on one or more Azure virtual machine (VM) type with Azure’s accelerated networking capability to improve networking performance. Dr. Yandapalli recommends that you “consider a virtual appliance that is available on one of the supported VM types with Azure’s accelerated networking capability.”

The diagram below shows communication between VMs, with and without Azure’s accelerated networking:

Accelerated networking to improve performance of Azure security (Source: Microsoft Azure).

Kaushansky says, “Check Point was the first certified compliant vendor with Azure accelerated networking. Accelerated networking can improve performance and reduce jitter, latency, and CPU utilization.”

According to Kaushansky—and depending on workload and VM size—Check Point and customers have observed at least a 2-3 times increase in throughput due to Azure accelerated networking.

2. Multi-Network Interface Controller (NIC) support

Dr. Yandapalli’s blog’s next best practice is to use VMs with multiple NICs to improve network traffic management via traffic isolation. For example, you can use one NIC for data plane traffic and one NIC for management plane traffic. Dr. Yandapalli states, “With multiple NICs you can better manage your network traffic by isolating various types of traffic across the different NICs.”

The diagram below shows the Azure Dv2-series with maximum NICs per VM size:

Azure Dv2-series VMs with # NICs per size.

CloudGuard IaaS supports multi-NIC VMs, without any maximum of the number of NICs. Check Point recommends the use of VMs with at least two NICs—VMs with one NIC are supported but not recommended.

Depending on the customer’s deployment architecture, the customer may use one NIC for internal East-West traffic and the second for outbound/inbound North-South traffic.

3. High Availability (HA) port with Azure load balancer

The Dr. Yandapalli’s third best practice is that Azure security and networking services should be reliable and highly available.

Dr. Yandapalli suggests the use of a High Availability (HA) port load balancing rule. “You would want your NVA to be reliable and highly available, to achieve these goals simply by adding network virtual appliance instances to the backend pool of your internal load balancer and configuring a HA ports load-balancer rule,” says Dr. Yandapalli.

The diagram below shows an example usage of a HA port:

Flowchart example of a HA port with Azure load balancer.

Kaushansky says, “CloudGuard IaaS supports this functionality with a standard load balancer via Azure Resource Manager deployment templates, which customers can use to deploy CloudGuard IaaS easily in HA mode.”

4. Support for Virtual Machine Scale Sets (VMSS)

The Dr. Yandapalli’s last best practice is to use Azure VMSS to provide HA. These also provide the management and automation layers for Azure security, networking, and other applications. This cloud-native functionality provides the right amount of IaaS resources at any given time, depending on application needs. Dr. Yandapalli points out that “scale sets provide high availability to your applications, and allow you to centrally manage, configure, and update a large number of VMs.”

In a similar way to the previous best practice, customers can use an Azure Resource Manager deployment template to deploy CloudGuard in VMSS mode. Check Point recommends the use of VMSS for traffic inspection of North-South (inbound/outbound) and East-West (lateral movement) traffic.

Learn more and get a free trial

As you can see from the above, CloudGuard IaaS is compliant with all four of Microsoft’s common best practices for how to build and deploy Azure network security solutions.

Visit Check Point to understand how CloudGuard IaaS can help protect your data and infrastructure in Microsoft Azure and hybrid clouds and improve Azure network security. If you’re evaluating Azure security solutions, you can get a free 30-day evaluation license of CloudGuard IaaS on Azure Marketplace!

(Based on a blog published on June 4, 2019 in the Check Point Cloud Security blog.)

The post Best practices for adding layered security to Azure security with Check Point’s CloudGuard IaaS appeared first on Microsoft Security.

Top 6 email security best practices to protect against phishing attacks and business email compromise

Microsoft Malware Protection Center - Wed, 10/16/2019 - 1:00pm

Most cyberattacks start over email—a user is tricked into opening a malicious attachment, or into clicking a malicious link and divulging credentials, or into responding with confidential data. Attackers dupe victims by using carefully crafted emails to build a false sense of trust and/or urgency. And they use a variety of techniques to do this—spoofing trusted domains or brands, impersonating known users, using previously compromised contacts to launch campaigns and/or using compelling but malicious content in the email. In the context of an organization or business, every user is a target and, if compromised, a conduit for a potential breach that could prove very costly.

Whether it’s sophisticated nation-state attacks, targeted phishing schemes, business email compromise or a ransomware attacks, such attacks are on the rise at an alarming rate and are also increasing in their sophistication. It is therefore imperative that every organization’s security strategy include a robust email security solution.

So, what should IT and security teams be looking for in a solution to protect all their users, from frontline workers to the C-suite? Here are 6 tips to ensure your organization has a strong email security posture:

You need a rich, adaptive protection solution.

As security solutions evolve, bad actors quickly adapt their methodologies to go undetected. Polymorphic attacks designed to evade common protection solutions are becoming increasingly common. Organizations therefore need solutions that focus on zero-day and targeted attacks in addition to known vectors. Purely standards based or known signature and reputation-based checks will not cut it.

Solutions that include rich detonation capabilities for files and URLs are necessary to catch payload-based attacks. Advanced machine learning models that look at the content and headers of emails as well as sending patterns and communication graphs are important to thwart a wide range of attack vectors including payload-less vectors such as business email compromise. Machine learning capabilities are greatly enhanced when the signal source feeding it is broad and rich; so, solutions that boast of a massive security signal base should be preferred. This also allows the solution to learn and adapt to changing attack strategies quickly which is especially important for a rapidly changing threat landscape.

Complexity breeds challenges. An easy-to-configure-and-maintain system reduces the chances of a breach.

Complicated email flows can introduce moving parts that are difficult to sustain. As an example, complex mail-routing flows to enable protections for internal email configurations can cause compliance and security challenges. Products that require unnecessary configuration bypasses to work can also cause security gaps. As an example, configurations that are put in place to guarantee delivery of certain type of emails (eg: simulation emails), are often poorly crafted and exploited by attackers.

Solutions that protect emails (external and internal emails) and offer value without needing complicated configurations or emails flows are a great benefit to organizations. In addition, look for solutions that offer easy ways to bridge the gap between the security teams and the messaging teams. Messaging teams, motivated by the desire to guarantee mail delivery, might create overly permissive bypass rules that impact security. The sooner these issues are caught the better for overall security. Solutions that offer insights to the security teams when this happens can greatly reduce the time taken to rectify such flaws thereby reducing the chances of a costly breach

A breach isn’t an “If”, it’s a “When.” Make sure you have post-delivery detection and remediation.

No solution is 100% effective on the prevention vector because attackers are always changing their techniques. Be skeptical of any claims that suggest otherwise. Taking an ‘assume breach’ mentality will ensure that the focus is not only on prevention, but on efficient detection and response as well. When an attack does go through the defenses it is important for security teams to quickly detect the breach, comprehensively identify any potential impact and effectively remediate the threat.

Solutions that offer playbooks to automatically investigate alerts, analyze the threat, assess the impact, and take (or recommend) actions for remediations are critical for effective and efficient response. In addition, security teams need a rich investigation and hunting experience to easily search the email corpus for specific indicators of compromise or other entities. Ensure that the solution allows security teams to hunt for threats and remove them easily.
Another critical component of effective response is ensuring that security teams have a good strong signal source into what end users are seeing coming through to their inbox. Having an effortless way for end users to report issues that automatically trigger security playbooks is key.

Your users are the target. You need a continuous model for improving user awareness and readiness.

An informed and aware workforce can dramatically reduce the number of occurrences of compromise from email-based attacks. Any protection strategy is incomplete without a focus on improving the level of awareness of end users.

A core component of this strategy is raising user awareness through Phish simulations, training them on things to look out for in suspicious emails to ensure they don’t fall prey to actual attacks. Another, often overlooked, but equally critical, component of this strategy, is ensuring that the everyday applications that end-users use are helping raise their awareness. Capabilities that offer users relevant cues, effortless ways to verify the validity of URLs and making it easy to report suspicious emails within the application — all without compromising productivity — are very important.

Solutions that offer Phish simulation capabilities are key. Look for deep email-client-application integrations that allow users to view the original URL behind any link regardless of any protection being applied. This helps users make informed decisions. In addition, having the ability to offer hints or tips to raise specific user awareness on a given email or site is also important. And, effortless ways to report suspicious emails that in turn trigger automated response workflows are critical as well.

Attackers meet users where they are. So must your security.

While email is the dominant attack vector, attackers and phishing attacks will go where users collaborate and communicate and keep their sensitive information. As forms of sharing, collaboration and communication other than email, have become popular, attacks that target these vectors are increasing as well. For this reason, it is important to ensure that an organization’s anti-Phish strategy not just focus on email.

Ensure that the solution offers targeted protection capabilities for collaboration services that your organization uses. Capabilities like detonation that scan suspicious documents and links when shared are critical to protect users from targeted attacks. The ability in client applications to verify links at time-of-click offers additional protection regardless of how the content is shared with them. Look for solutions that support this capability.

Attackers don’t think in silos. Neither can the defenses.

Attackers target the weakest link in an organization’s defenses. They look for an initial compromise to get in, and once inside will look for a variety of ways increase the scope and impact of the breach. They typically achieve this by trying to compromise other users, moving laterally within the organization, elevating privileges when possible, and the finally reaching a system or data repository of critical value. As they proliferate through the organization, they will touch different endpoints, identities, mailboxes and services.

Reducing the impact of such attacks requires quick detection and response. And that can only be achieved when the defenses across these systems do not act in silos. This is why it is critical to have an integrated view into security solutions. Look for an email security solution that integrates well across other security solutions such as endpoint protection, CASB, identity protection, etc. Look for richness in integration that goes beyond signal integration, but also in terms of detection and response flows.



The post Top 6 email security best practices to protect against phishing attacks and business email compromise appeared first on Microsoft Security.

Guarding against supply chain attacks—Part 1: The big picture

Microsoft Malware Protection Center - Wed, 10/16/2019 - 12:00pm

Every day, somewhere in the world, governments, businesses, educational organizations, and individuals are hacked. Precious data is stolen or held for ransom, and the wheels of “business-as-usual” grind to a halt. These criminal acts are expected to cost more than $2 trillion in 2019, a four-fold increase in just four years. The seeds that bloom into these business disasters are often planted in both hardware and software systems created in various steps of your supply chain, propagated by bad actors and out-of-date business practices.

These compromises in the safety and integrity of your supply chain can threaten the success of your business, no matter the size of your operation. But typically, the longer your supply chain, the higher the risk for attack, because of all the supply sources in play.

In this blog series, “Guarding against supply chain attacks,” we examine various components of the supply chain, the vulnerabilities they present, and how to protect yourself from them.

Defining the problem

Supply chain attacks are not new. The National Institute of Standards and Technology (NIST) has been focused on driving awareness in this space since 2008. And this problem is not going away. In 2017 and 2018, according to Symantec, supply chain attacks rose 78 percent. Mitigating this type of third-party risk has become a major board issue as executives now understand that partner and supplier relationships pose fundamental challenges to businesses of all sizes and verticals.

Moreover, for compliance reasons, third-party risk also continues to be a focus. In New York State, Nebraska, and elsewhere in the U.S., third-party risk has emerged as a significant compliance issue.

Throughout the supply chain, hackers look for weaknesses that they can exploit. Hardware, software, people, processes, vendors—all of it is fair game. At its core, attackers are looking to break trust mechanisms, including the trust that businesses naturally have for their suppliers. Hackers hide their bad intentions behind the shield of trust a supplier has built with their customers over time and look for the weakest, most vulnerable place to gain entry, so they can do their worst.

According to NIST, cyber supply chain risks include:

  • Insertion of counterfeits.
  • Unauthorized production of components.
  • Tampering with production parts and processes.
  • Theft of components.
  • Insertion of malicious hardware and software.
  • Poor manufacturing and development practices that compromise quality.

Cyber Supply Chain Risk Management (C-SCRM) identifies what the risks are and where they come from, assesses past damage and ongoing and future risk, and mitigates these risks across the entire lifetime of every system.

This process examines:

  • Product design and development.
  • How parts of the supply chain are distributed and deployed.
  • Where and how they are acquired.
  • How they are maintained.
  • How, at end-of-life, they are destroyed.

The NIST approach to C-SCRM considers how foundational practices and risk are managed across the whole organization.

Examples of past supply chain attacks

The following are examples of sources of recent supply chain attacks:

Hardware component attacks—When you think about it, OEMs are among the most logical places in a supply chain which an adversary will likely try to insert vulnerabilities. For example, in 2018, an unidentified major telecommunications company in the U.S. uncovered hardware manufactured by a subcontractor in China for Super Micro Computer Inc., a California-based company. These parts which were manufactured in China and assumed to have been tampered with by the Chinese intelligence service.

Software component attacks—Again in 2016, Chinese hackers purportedly attacked TeamViewer software, which was a potential virtual invitation to view and access information on the computers of millions of people all over the world who use this program.

People perpetrated attacks—People are a common connector between the various steps and entities in any supply chain and are subject to the influence of corrupting forces. Nation-states or other “cause-related” organizations prey on people susceptible to bribery and blackmail. In 2016, the Indian tech giant, Wipro, had three employees arrested in a suspected security breach of customer records for the U.K. company TalkTalk.

Business processes—Business practices (including services), both upstream and downstream, are also examples of vulnerable sources of infiltration. For example, experienced an exposed database when one of its customers did not adequately protect a web server storing resumes, which contain emails and physical addresses, along with other personal information, including immigration records. This and other issues can be avoided if typical business practices such as risk profiling and assessment services are in place and are regularly reviewed to make sure they comply with changing security and privacy requirements. This includes policies for “bring your own” IoT devices, which are another fast-growing vulnerability.

Big picture practical advice

Here’s some practical advice to take into consideration:

Watch out for copycat attacks—If a data heist worked with one corporate victim, it’s likely to work with another. This means once a new weapon is introduced into the supply chain, it is likely to be re-used—in some cases, for years.

To prove the point, here are some of the many examples of cybercrimes that reuse code stolen from legal hackers and deployed by criminals.

  • The Conficker botnet MS10-067 is over a decade old and is still found on millions of PCs every month.
  • The criminal group known as the Shadow Brokers used the Eternal Blue code designed by the U.S. National Security Agency as part of their cybersecurity toolkit. When the code was leaked illegally and sold to North Korea, they used it to execute WannaCry in 2017, which spread to 150 countries and infected over 200,000 computers.
  • Turla, a purportedly Russian group, has been active since 2008, infecting computers in the U.S. and Europe with spyware that establishes a hidden foothold in infected networks that searches for and steals data.

Crafting a successful cyberattack from scratch is not a simple undertaking. It requires technical know-how, resources to create or acquire new working exploits, and the technique to then deliver the exploit, to ensure that it operates as intended, and then to successfully remove information or data from a target.

It’s much easier to take a successful exploit and simply recycle it—saving development and testing costs, as well as the costs that come from targeting known soft targets (e.g., avoiding known defenses that may detect it). We advise you to stay in the know about past attacks, as any one of them may come your way. Just ask yourself: Would your company survive a similar attack? If the answer is no—or even maybe—then fix your vulnerabilities or at the very least make sure you have mitigation in place.

Know your supply chain—Like many information and operational technology businesses, you probably depend on a global system of suppliers. But do you know where the various technology components of your business come from? Who makes the hardware you use—and where do the parts to make that hardware come from? Your software? Have you examined how your business practices and those of your suppliers keep you safe from bad actors with a financial interest in undermining the most basic components of your business? Take some time to look at these questions and see how you’d score yourself and your suppliers.

Looking ahead

Hopefully, the above information will encourage (if not convince) you to take a big picture look at who and what your supply chain consists of and make sure that you have defenses in place that will protect you from all the known attacks that play out in cyberspace each day.

In the remainder of the “Guarding against supply chain attacks” series, we’ll drill down into supply chain components to help make you aware of potential vulnerabilities and supply advice to help you protect your company from attack.

Stay tuned for these upcoming posts:

  • Part 2—Explores the risks of hardware attacks.
  • Part 3—Examines ways in which software can become compromised.
  • Part 4—Looks at how people and processes can expose companies to risk.
  • Part 5—Summarizes our advice with a look to the future.

In the meantime, 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.

The post Guarding against supply chain attacks—Part 1: The big picture appeared first on Microsoft Security.

Microsoft’s 4 principals for an effective security operations center

Microsoft Malware Protection Center - Tue, 10/15/2019 - 12:00pm

The Microsoft Cyber Defense Operations Center (CDOC) fields trillions of security signals every day. How do we identify and respond to the right threats? One thing that won’t surprise you: we leverage artificial intelligence (AI), machine learning, and automation to narrow the focus. But technology is not enough. Our people, culture, and process are just as critical.

You may not have trillions of signals to manage, but I bet you will still get a lot of value from a behind-the-scenes look at the CDOC. Even the small companies that I’ve worked with have improved the effectiveness of their security operations centers (SOCs) based on learnings from Microsoft.

Watch the operations episode of the CISO Spotlight Series—The people behind the cloud to get my take and a sneak peek at our team in action. In the video, I walk you through four principals:

  1. It starts with assessment.
  2. Invest in the right technology.
  3. Hire a diverse group of people.
  4. Foster an innovative culture.
It starts with assessment

Before you make any changes, it helps to identify the gaps in your current security system. Take a look at your most recent attacks to see if you have the right detections in place. Offense should drive your defenses. For example:

  • Has your organization been victim to password spray attacks?
  • Have there been brute force attacks against endpoints exposed to the internet?
  • Have you uncovered advanced persistent threats?

Understanding where your organization is vulnerable will help you determine what technology you need. If you need further help, I would suggest using the MITRE ATT&CK Framework.

Invest in the right technology

As you evaluate technology solutions, think of your security operations as a funnel. At the very top are countless threat signals. There is no way your team can address all of them. This leads to employee burnout and puts the organization at risk. Aim for automation to handle 20-25 percent of incoming events. AI and machine learning can correlate signals, enrich them with other data, and resolve known incidents.

Invest in good endpoint detection, network telemetry, a flexible security incident and event management system (SIEM) like Azure Sentinel, and cloud workload protection solutions. The right technology will reduce the volume of signals that filter down to your people, empowering them to focus on the problems that machines can’t solve.

Hire a diverse group of people

The people you hire matter. I attribute much of our success to the fact that we hire people who love to solve problems. You can model this approach in your SOC. Look for computer scientists, security professionals, and data scientists—but also try to find people with nontraditional backgrounds like military intelligence, law enforcement, and liberal arts. People with a different perspective can introduce creative ways of looking at a problem. For example, Microsoft has had a lot of success with veterans from the military.

I also recommend organizing your SOC into specialized, tiered teams. It gives employees a growth path and allows them to focus on areas of expertise. Microsoft uses a three-tiered approach:

  • Tier 1 analysts—These analysts are the front line. They manage the alerts generated by our SIEM and focus on high-speed remediation over a large number of events.
  • Tier 2 analysts—This team tackles alerts that require a deeper level of analysis. Many of these events have been escalated up from Tier 1, but Tier 2 analysts also monitor alerts to identify and triage the complex cases.
  • Tier 3 analysts—These are the threat hunters. They use sophisticated tools to proactively uncover advanced threats and hidden adversaries.

For a more detailed look at how Microsoft has structured our team, read Lessons learned from the Microsoft SOC—Part 2a: Organizing people

Foster an innovative culture

Culture influences SOC performance by guiding how people treat each other and approach their work. Well-defined career paths and roles are one way to influence your culture. People want to know how their work matters and contributes to the organization. As you build your processes and team, consider how you can encourage innovation, diversity, and teamwork.

Read how the CDOC creates culture in Lessons learned from the Microsoft SOC—Part 1.

Learn more

To learn more about how to run an effective SOC:

The post Microsoft’s 4 principals for an effective security operations center appeared first on Microsoft Security.

Patching as a social responsibility

Microsoft Malware Protection Center - Wed, 10/09/2019 - 12:00pm

In the wake of the devastating (Not)Petya attack, Microsoft set out to understand why some customers weren’t applying cybersecurity hygiene, such as security patches, which would have helped mitigate this threat. We were particularly concerned with why patches hadn’t been applied, as they had been available for months and had already been used in the WannaCrypt worm—which clearly established a ”real and present danger.”

We learned a lot from this journey, including how important it is to build clearer industry guidance and standards on enterprise patch management. To help make it easier for organizations to plan, implement, and improve an enterprise patch management strategy, Microsoft is partnering with the U.S. National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).

NIST and Microsoft are extending an invitation for you to join this effort if you’re a:

  • Vendor—Any vendor who has technology offerings to help with patch management (scan, report, deploy, measure risk, etc.).
  • Organization or individual—All those who have tips and lessons learned from a successful enterprise management program (or lessons learned from failures, challenges, or any other situations).

If you have pertinent learnings that you can share, please reach out to

During this journey, we also worked closely with additional partners and learned from their experience in this space, including the:

  • Center for Internet Security (CIS)
  • U.S. Department of Homeland Security (DHS) Cybersecurity
  • Cybersecurity and Infrastructure Security Agency (CISA) (formerly US-CERT / DHS NCCIC)

A key part of this learning journey was to sit down and listen directly to our customer’s challenges. Microsoft visited a significant number of customers in person (several of which I personally joined) to share what we learned—which became part of the jointly endorsed mitigation roadmap—and to have some really frank and open discussions to learn why organizations really aren’t applying security patches.

While the discussions mostly went in expected directions, we were surprised at how many challenges organizations had on processes and standards, including:

  • “What sort of testing should we actually be doing for patch testing?”
  • “How fast should I be patching my systems?”

This articulated need for good reference processes was further validated by observing that a common practice for “testing” a patch before a deployment often consisted solely of asking whether anyone else had any issues with the patch in an online forum.

This realization guided the discussions with our partners towards creating an initiative in the NIST NCCoE in collaboration with other industry vendors. This project—kicking off soon—will build common enterprise patch management reference architectures and processes, have relevant vendors build and validate implementation instructions in the NCCoE lab, and share the results in the NIST Special Publication 1800 practice guide for all to benefit.

Applying patches is a critical part of protecting your system, and we learned that while it isn’t as easy as security departments think, it isn’t as hard as IT organizations think.

In many ways, patching is a social responsibility because of how much society has come to depend on technology systems that businesses and other organizations provide. This situation is exacerbated today as almost all organizations undergo digital transformations, placing even more social responsibility on technology.

Ultimately, we want to make it easier for everyone to do the right thing and are issuing this call to action. If you’re a vendor that can help or if you have relevant learnings that may help other organizations, please reach out to Now!

The post Patching as a social responsibility appeared first on Microsoft Security.

How to avoid getting caught in a “Groundhog Day” loop of security issues

Microsoft Malware Protection Center - Tue, 10/08/2019 - 12:00pm

It’s Cyber Security Awareness Month and it made me think about one of my favorite movies, called Groundhog Day. Have you ever seen it? Bill Murray is the cynical weatherman, Phil Connors, who gets stuck in an endless loop where he repeats the same day over and over again until he “participates in his own rescue” by becoming a better person.

Sometimes it can feel like we’re caught in our own repetitious loops in cybersecurity—I even did a keynote at RSA APJ on this very topic a few years ago. The good news is that we can get out of the loop. By learning lessons from the past and bringing them forward and applying them to today’s technologies, outcomes can be changed—with “change” being the operative word.

If companies continue to do things the same way—in insecure ways—attackers will come along and BOOM you’re in trouble. You may resolve that breach, but that won’t help in the long run. Unless the source of the problem is determined and changed, just like Phil Connors, you’ll wake up one day and BOOM—you’re attacked again.

How security experts can help organizations protect against cybercrime

We can learn from past mistakes. And to prove it, I’d like to cite a heartening statistic. Ransomware encounters decreased by 60 percent between March 2017 and December 2018. While attackers don’t share the specifics about their choice of approach, when one approach isn’t working, they move to another. After all, it’s a business—in fact it’s a successful (and criminal) business—bringing in nearly $200 billion in profits each year.1 We do know that ransomware has less of chance of spreading on fully patched and well-segmented networks and companies are less likely to pay ransoms when they have up-to-date, clean backups to restore from. In other words, it’s very likely that robust cybersecurity hygiene is an important contributor to the decrease in ransomware encounters. (See Lesson 1: Practice good cybersecurity hygiene below.)

The bad news of course is that attackers began to shift their efforts to crimes like cryptocurrency mining, which hijacks victims’ computing resources to make digital money for the attackers.1 But that’s because cybercriminals are opportunists and they’re always searching for the weakest link.

One of the best ways to thwart cybercrime is to involve security experts before deploying new products and/or services. A decade ago, this wasn’t typically done in many organizations. But with the rise of security awareness as part of the overall corporate risk posture, we’re seeing security involved early on in deployments of modern architectures, container deployments, digital transformations, and DevOps.

When security experts connect the wisdom of the past—such as the importance of protecting data in transit with encryption—to the technology rollouts of today, they can help organizations anticipate what could go wrong. This helps you bake controls and processes into your products and services before deployment. The people who have already learned the lessons you need to know can help so you don’t wake up to the same problems every (well, almost) day. When security experts carry those lessons forward, they can help end your Groundhog Day.

In addition, involving security experts early on doesn’t have to slow things down. They can actually help speed things up and prevent backtracking later in the product development cycle to fix problems missed the first time around.

Security can help anticipate problems and produce solutions before they occur. When Wi-Fi networking was first being deployed in the late 1990s, communications were protected with Wired Equivalent Privacy (WEP). But WEP suffered from significant design problems such as the initialization vector (IV) being part of the RC4 encryption key that were already known issues in the cryptographic community. The result was a lot of WEP crackers and the rapid development of the stronger Wi-Fi Protected Access (WPA) set of protocols. If designers had worked with crypto experts, who already had designed a solution free of known issues, time, money, and privacy could have been saved.

Traditional technology thinks about “use” cases. Security thinks about “misuse” cases. Product people focus on the business and social benefits of a solution. Security people think about the risks and vulnerabilities by asking these questions:

  • What happens if the solutions are attacked or used improperly?
  • How is this product or workload going to behave in a non-perfect environment?
  • Where is your system vulnerable and what happens when it comes under attack?

Security also remembers lessons learned while creating threat models to head off common mistakes at the past.

Rita: I didn’t know you could play like that.

Phil: I’m versatile.

Groundhog Day (1993) starring Bill Murray as Phil and Andie McDowell as Rita. Sony Pictures©

Example: Think about designing a car. Cars are cool because they can go fast—really fast. But if you had some security folks on the team, they’d be thinking about the fact that while going fast can be thrilling—you’re going to have to stop at some point.

Security are the kind of thinkers who would probably suggest brakes. And they would make sure that those brakes worked in the rain, snow, and on ice just as well as they worked on dry pavement. Furthermore—because security is obsessed (in a good way) with safety—they would be the ones to plan for contingencies, like having a spare tire and jack in the car in case you get a flat tire.

Learning from and planning for known past issues, like the network equivalent of flat tires, is a very important part of secure cyber design. Machine learning can provide intelligence to help avoid repeats of major attacks. For example, machine learning is very useful in detecting and dismantling fileless malware that lives “off the land” like the recent Astaroth campaign.

Top practices inspired by lessons learned by helping organizations be more secure

Thinking about and modeling for the types of problems that have occurred in the past helps keep systems more secure in the future. For example, we take off our shoes in the airport because someone smuggled explosives onto a plane by hiding it in their footwear.

How DO you stop someone who wants to steal, manipulate, or damage the integrity of your data? What can you do to stop them from trying to monetize it and put your company and customers in jeopardy of losing their privacy? I’m glad you asked—here are four lessons that can help your organization be more secure:

Lesson 1: Practice good cybersecurity hygiene—It may not be shiny and new, but cybersecurity hygiene really matters. This is perhaps the most important lesson we can learn from the past—taking steps to ensure the basics are covered can go a very long way for security. That 60 percent decrease in ransomware encounters globally mentioned earlier is most likely due to better cybersecurity hygiene.

Lesson 2: Schedule regular backups—With regular backups (especially cold backups, held offline), you always have an uncompromised version of your data.

Lesson 3: Use licensed software—Licensed software decreases the likelihood that bugs, worms, and other bad things won’t be infiltrating your infrastructure. Deploying necessary patching that makes systems less vulnerable to exploit is part of keeping the integrity of your licensed software intact.

Lesson 4: Lean into humans “being human” while leveraging technological advances—For example, acknowledge that humans aren’t great at remembering strong passwords, especially when they change frequently. Rather than berating people for their very human brains, focus on developing solutions, such as password wallets and passwordless solutions, which acknowledge how hard strong passwords are to remember without sacrificing security.

Rita: Do you ever have déjà vu?

Phil: Didn’t you just ask me that?

Groundhog Day (1993) Sony Pictures©

Admittedly, we can’t promise there won’t be some share of Groundhog Day repeats. But the point is progress, not perfection. And we are making significant progress in our approach to cybersecurity and resilience. Above are just a couple of examples.

I’d love to hear more from you about examples you may have to share, too! Reach out to me on LinkedIn or Twitter, @DianaKelley14. Also, bookmark the Security blog to keep up with our expert coverage on security matters.

1Cybercrime Profits Total nearly $200 Billion Each Year, Study Reveals

The post How to avoid getting caught in a “Groundhog Day” loop of security issues appeared first on Microsoft Security.

In hot pursuit of elusive threats: AI-driven behavior-based blocking stops attacks in their tracks

Microsoft Malware Protection Center - Tue, 10/08/2019 - 11:00am

Our experience in detecting and blocking threats on millions of endpoints tells us that attackers will stop at nothing to circumvent protections. Even one gap in security can be disastrous to an organization.

At Microsoft, we don’t stop finding new ways to fill in gaps in security. We go beyond strengthening existing defenses by introducing new and innovative layers of protection. While our industry-leading endpoint protection platform stops threats before they can even run, we continue improving protections for instances where sophisticated adversarial attacks manage to slip through.

Multiple layers of protection mean multiple hurdles that attackers need to overcome to perpetrate attacks. We continuously innovate threat and malware prevention engines on the client and in the cloud to add more protection layers that detect and block sophisticated and evasive threats before they can even run.

In recent months, we introduced two machine learning protection features within the behavioral blocking and containment capabilities in Microsoft Defender Advanced Threat Protection. In keeping with the defense in depth strategy, coupled with the “assume breach” mindset, these new protection engines specialize in detecting threats by analyzing behavior, and adding new layers of protection after an attack has successfully started running on a machine:

  • Behavior-based machine learning identifies suspicious process behavior sequences and advanced attack techniques observed on the client, which are used as triggers to analyze the process tree behavior using real-time machine learning models in the cloud
  • AMSI-paired machine learning uses pairs of client-side and cloud-side models that integrate with Antimalware Scan Interface (AMSI) to perform advanced analysis of scripting behavior pre- and post-execution to catch advanced threats like fileless and in-memory attacks

The figure below illustrates how the two behavior-based machine learning protections enrich post-breach detections:

Figure 1. Pre and post-execution detection engines in Microsoft Defender ATP’s antivirus capabilities

The pre-execution and post-execution detection engines make up two important components of comprehensive threat and malware prevention. They reflect the defense in depth principle, which entails multiple layers of protection for thorough, wide-range defense.

In detecting post-execution behavior, using machine learning is critical. Many attack techniques are also used by legitimate applications. For example, a very common, documented method used by both clean applications and malware is creating a service for persistence.

To distinguish between malicious and clean applications when an attack technique is observed, Windows Defender Antivirus monitors and sends suspicious behaviors and process trees to the cloud protection service for real-time classification by machine learning. Cloud-based post-execution detection engines isolate known good behaviors from malicious intent to stop attacks in real time.

Within milliseconds of an attack technique or suspicious script execution being observed, machine learning classifiers return a verdict and the client blocks the threat. The pre-execution models then learn from these malicious blocks afterwards to protect Microsoft Defender ATP customers before attacks can begin executing new cycles of infection.

How behavioral blocking and containment protected 100 organizations from credential theft

In early July, attackers launched a highly targeted credential theft attack against 100 organizations around the world, primarily in the United Arab Emirates, Germany, and Portugal. The goal of the attack was to install the notorious info-stealing backdoor Lokibot and to exfiltrate sensitive data.

Behavioral blocking and containment capabilities in Microsoft Defender ATP detected and foiled the attack in its early stages, protecting customers from damage.

Spear-phishing emails carrying lure documents were sent to the target organizations; in one instance, three distinct highly targeted emails with the same lure document were delivered to a single pharmaceutical ingredient supplier. The attacker used pharmaceutical industry jargon to improve the credibility of the email and in one case requested a quote on an ingredient that the target company was likely to produce.

Figure 2. Multiple spear-phishing emails attempted to deliver the same lure document to the same target

The lure document itself didn’t host any exploit code but used an external relationship to a document hosted on a compromised WordPress website. If recipients opened the attachment, the related remote document, which contained the exploit, was also automatically loaded. This allowed the remote document to take advantage of the previously fixed CVE-2017-11882 vulnerability in Equation Editor and execute code on the computer.

Figure 3. The lure document contains an external reference to the exploit document is hosted on a compromised WordPress website.

Upon successful exploitation, the attack downloaded and loaded the Lokibot malware, which stole credentials, exfiltrated stolen data, and waited for further instructions from a command-and-control (C&C) server.

The behavior-based machine learning models built into Microsoft Defender ATP caught attacker techniques at two points in the attack chain. The first detection layer spotted the exploit behavior. Machine learning classifiers in the cloud correctly identified the threat and immediately instructed the client to block the attack. In cases where the attack had proceeded past this layer of defense to the next stage of the attack, process hollowing would have been attempted. This, too, was detected by behavior-based machine learning models, which instructed the clients to block the attack, marking the second detection layer. As the attacks are blocked, the malicious processes and corresponding files are remediated, protecting targets from credential theft and further backdoor activities.

Figure 4. Credential theft attack chain showing multiple behavior-based protection layers that disrupted the attack

The behavior-based blocking raised an “Initial Access” alert in Microsoft Defender Security Center, the console for SecOps teams that gives complete visibility into their environments and across the suite of Microsoft Defender ATP tools that protect their endpoints:

Figure 5. Alert and process tree on Microsoft Defender Security Center for this targeted attack

This attack demonstrates how behavior-based machine learning models in the cloud add new layers of protection against attacks even after they have started running.

In the next sections, we will describe in detail the two machine learning protection features in behavioral blocking and containment capabilities in Microsoft Defender ATP.

Behavior-based machine learning protection

The behavior engine in the Windows Defender Antivirus client monitors more than 500 attack techniques as triggers for analyzing new and unknown threats. Each time one of the monitored attack techniques is observed, the process tree and behavior sequences are constructed and sent to the cloud, where behavior-based machine learning models classify possible threats. Figure 4 below illustrates a more detailed view of our process tree classification path:

Figure 6. Process tree classification path

Behavior-based detections are named according to the MITRE ATT&CK matrix to help identify the attack stage where the malicious behavior was observed:


Tactic Detection threat name Initial Access Behavior:Win32/InitialAccess.*!ml Execution Behavior:Win32/Execution.*!ml Persistence Behavior:Win32/Persistence.*!ml Privilege Escalation Behavior:Win32/PrivilegeEscalation.*!ml Defense Evasion Behavior:Win32/DefenseEvasion.*!ml Credential Access Behavior:Win32/CredentialAccess.*!ml Discovery Behavior:Win32/Discovery.*!ml Lateral Movement Behavior:Win32/LateralMovement.*!ml Collection Behavior:Win32/Collection.*!ml Command and Control Behavior:Win32/CommandAndControl.*!ml Exfiltration Behavior:Win32/Exfiltration.*!ml Impact Behavior:Win32/Impact.*!ml Uncategorized Behavior:Win32/Generic.*!ml

Since deployment, the behavior-based machine learning models have blocked attacker techniques like the following used by attacks in the wild:

  • Credential dumping from LSASS
  • Cross-process injection
  • Process hollowing
  • UAC bypass
  • Tampering with antivirus (such as disabling it or adding the malware as exclusion)
  • Contacting C&C to download payloads
  • Coin mining
  • Boot record modification
  • Pass-the-hash attacks
  • Installation of root certificate
  • Exploitation attempt for various vulnerabilities

These blocked behaviors show up as alerts in Microsoft Defender Security Center.

Figure 7. Alert for malicious behavior in Microsoft Defender Security Center

Machine learning protection for scripting engines with AMSI

Through the AMSI integration with scripting engines on Windows 10 and Office 365, Windows Defender Antivirus gains rich insight into the execution of PowerShell, VBScript, JavaScript and Office Macro VBA scripts to cut through obfuscation, protect against fileless attacks, and provide robust defenses against malicious script behavior.

To assist with fileless and evasive script attacks, scripting engines are instrumented to provide both behavior calls and dynamic content calls to the antivirus product. The type of integrations available varies based on the scripting engine. Table 1 below illustrates the current support with the Windows 10 and Office 365, and Figure 5 illustrates an example of the scripting engine dynamic script content and behavior calls for malicious scripts.


Microsoft AMSI integration point Dynamic script content calls Behavior calls PowerShell Y VBScript Y Y JavaScript Y Y Office VBA macros Y WMI Y MSIL .NET Y

Figure 8. Example dynamic script content and behavior calls for malicious scripts monitored by AMSI

Our scripting machine learning protection design can be seen in Figure 6 below. We deployed paired machine learning models for various scripting scenarios. Each pair of classifiers is made up of (1) a performance-optimized lightweight classifier that runs on the Windows Defender Antivirus client, and (2) a heavy classifier in the cloud. The role of the client-based classifier is to inspect the script content or behavior log to predict whether a script is suspicious. For scripts that are classified as suspicious, metadata describing the behavior or content is featurized and sent up to the cloud for real-time classification; the metadata that describes the content includes expert features, features selected by machine learning, and fuzzy hashes.

Figure 9. AMSI-paired models classification path

The paired machine learning model in the cloud then analyzes the metadata to decide whether the script should be blocked or not. If machine learning decides to block the file, the running script is aborted. This paired model architecture is used to offload the overhead of running intensive machine learning models to the cloud, and to make use of the global information available about the content through the Microsoft Intelligent Security Graph.

Malicious scripts blocked by AMSI-paired machine models are reported in Microsoft Defender Security Center using threat names like the following:

  • Trojan:JS/Mountsi.A!ml
  • Trojan:Script/Mountsi.A!ml
  • Trojan:O97M/Mountsi.A!ml
  • Trojan:VBS/Mountsi.A!ml
  • Trojan:PowerShell/Mountsi.A!ml
Behavioral blocking and containment for disrupting advanced attacks

The two new cloud-based post-execution detection engines we described in this blog are part of the behavioral blocking and containment capabilities that enabled Microsoft Defender ATP to protect the 100 organizations targeted in the credential theft attack we discussed earlier. Recently, we also documented how behavior-based protections are important components of the dynamic protection against the multi-stage, fileless Nodersok campaign.

These engines add to the many layers of machine learning-driven protections in the cloud and add protection against threats after they have begun running. To further illustrate how these behavior-based protections work, here’s a diagram that shows the multiple protection layers against an Emotet attack chain:

Figure 10. Multiple layers of behavior-based protection in Windows Defender Antivirus while executing an Emotet attack (SHA-256: ee2bbe2398be8a1732c0afc318b797f192ce898982bff1b109005615588facb0)

As part of our defense in depth strategy, these new layers of antivirus protection not only expand detection and blocking capabilities; they also provide even richer visibility into malicious behavior sequences, giving security operations more signals to use in investigating and responding to attacks through Microsoft Defender ATP capabilities like endpoint detection and response, threat and vulnerability management, and automated investigation and remediation.

Within milliseconds of an attack technique or suspicious script execution being observed, machine learning classifiers return a verdict and the client blocks the threat. Our pre-execution models then learn from these malicious blocks afterwards to protect Microsoft Defender ATP customers before the threats even begin executing.

Figure 11. Multiple layers of malware and threat prevention engines on the client and in the cloud

The impact of the continuous improvements in antivirus capabilities further show up in Microsoft Threat Protection, Microsoft’s comprehensive security solution for identities, endpoints, email and data, apps, and infrastructure. Through signal-sharing across Microsoft services, the richer machine learning-driven protection in Microsoft Defender ATP is amplified throughout protections for various attack surfaces.


Geoff McDonald
with Saad Khan
Microsoft Defender ATP Research

The post In hot pursuit of elusive threats: AI-driven behavior-based blocking stops attacks in their tracks appeared first on Microsoft Security.

CISO series: Lessons learned from the Microsoft SOC—Part 3a: Choosing SOC tools

Microsoft Malware Protection Center - Mon, 10/07/2019 - 5:20pm

The Lessons learned from the Microsoft SOC blog series is designed to share our approach and experience with security operations center (SOC) operations. Our learnings in the series come primarily from Microsoft’s corporate IT security operation team, one of several specialized teams in the Microsoft Cyber Defense Operations Center (CDOC).

Over the course of the series, we’ve discussed how we operate our SOC at Microsoft. In the last two posts, Part 2a, Organizing people, and Part 2b: Career paths and readiness, we discussed how to support our most valuable resources—people—based on successful job performance.

We’ve also included lessons learned from the Microsoft Detection and Response Team (DART) to help our customers respond to major incidents, as well as insights from the other internal SOC teams.

For a visual depiction of our SOC philosophy, download our Minutes Matter poster. To learn more about our Security operations, watch CISO Spotlight Series: The people behind the cloud.

As part of Cybersecurity Awareness month, today’s installment focuses on the technology that enables our people to accomplish their mission by sharing our current approach to technology, how our tooling evolved over time, and what we learned along the way. We hope you can use what we learned to improve your own security operations.

Our strategic approach to technology

Ultimately, the role of technology in a SOC is to help empower people to better contain risk from adversary attacks. Our design for the modern enterprise SOC has moved away from the classic model of relying primarily on alerts generated by static queries in an on-premise security information and event management (SIEM) system. The volume and sophistication of today’s threats have outpaced the ability of this model to detect and respond to threats effectively.

We also found that augmenting this model with disconnected point-solutions lead to additional complexity and didn’t necessarily speed up analysis, prioritization, orchestration, and execution of response action.

Selecting the right technology

Every tool we use must enable the SOC to better achieve its mission and provide meaningful improvement before we invest in purchasing and integrating it. Each tool must also meet rigorous requirements for the sheer scale and global footprint of our environment and the top-shelf skill level of the adversaries we face, as well as efficiently enable our analysts to provide high quality outcomes. The tools we selected support a range of scenarios.

In addition to enabling firstline responders to rapidly remediate threats, we must also enable deep subject matter experts in security and data science to reason over immense volumes of data as they hunt for highly skilled and well-funded nation state level adversaries.

Making the unexpected choice

Even though many of the tools we currently use are made by Microsoft, they still must meet our stringent requirements. All SOC tools—no matter who makes them—are strictly vetted and we don’t hesitate to reject tools that don’t work for our purposes. For example, our SOC rejected Microsoft’s Advanced Threat Analytics tool because of the infrastructure required to scale it up (despite some promising detection results in a pilot). It’s successor, Azure Advanced Threat Protection (Azure ATP) solved this infrastructure challenge by shifting to a SaaS architecture and is now in active use daily.

Our SOC analysts work with Microsoft engineering and third-party tool providers to drive their requirements and provide feedback. As an example, our SOC team has a weekly meeting with the Windows Defender ATP team to review learnings, findings, request features or changes, share engineering progress on requested features, and share attacker research from both teams. Even today, as we roll out Azure Sentinel, our SOC is actively working with the engineering team to ensure key requirements are met, so we can fully retire our legacy SIEM (more details below). Additionally, we regularly invite engineers from our product groups to join us in the SOC to learn how the technology is applied by our experts.

History and evolution to broad and deep tooling

Microsoft’s Corporate IT SOC protects a cross platform environment with a significant population of Windows, Linux, and Macs running a variety of Microsoft and non-Microsoft software. This environment is approximately 95 percent hosted on the cloud today. The tooling used in this SOC has evolved significantly over the years starting from the classic model centered around an on-premises SIEM.

Phase 1—Classic on-premises SIEM-centric model

This is the common model where all event data is fed into an on-premises SIEM where analytics are performed on the data (primarily static queries that were refined over time).

We experienced a set of challenges that we now view as natural limitations of this model. These challenges included:

  • Overwhelming event volume—High volume and growth (on the scale of 20+ billion events a day currently) exceeded the capacity of the on-premises SIEM to handle it.
  • Analyst overload and fatigue—The static rulesets generated excessive amounts of false positive alerts that lead to alert fatigue.
  • Poor investigation workflow—Investigation of events using the SIEM was clunky and required manual queries and manual steps when switching between tools.

Phase 2—Bolster on-premises SIEM weaknesses with cloud analytics and deep tools

We introduced several changes designed to address shortcomings of the classic model.

Three strategic shifts were introduced and included:

1. Cloud based log analytics—To address the SIEM scalability challenges discussed previously, we introduced cloud data lake and machine learning technology to more efficiently store and analyze events. This took pressure off our legacy SIEM and allowed our hunters to embrace the scale of cloud computing to apply advanced techniques like machine learning to reason over the data. We were early adopters of this technology before many current commercial offerings had matured, so we ended up with several “generations” of custom technology that we had to later reconcile and consolidate (into the Log Analytics technology that now powers Azure Sentinel).

Lesson learned: “Good enough” and “supported” is better than “custom.”

Adopt commercial products if they meet at least the “Pareto 80 percent” of your needs because the support of these custom implementations (and later rationalization effort) takes resources and effort away from hunting and other core mission priorities.

2. Specialized high-quality tooling—To address analyst overload and poor workflow challenges, we tested and adopted specialized tooling designed to:

  • Produce high quality alerts (versus high quantity of detailed data).
  • Enable analysts to rapidly investigate and remediate compromised assets.

It is hard to overstate the benefits of this incredibly successful integration of technology. These tools had a powerful positive impact on our analyst morale and productivity, driving significant improvements of our SOC’s mean time to acknowledge (MTTA) and remediate (MTTR).

We attribute a significant amount of this success of these tools to the direct real-world input that was used to design them.

  • SOC—The engineering group spent approximately 18-24 months with our SOC team focused on learning about SOC analyst needs, thought processes, pain points, and more while designing and building the first release of Windows Defender ATP. These teams still stay in touch weekly.
  • DART team—The engineering group directly integrated analysis and hunting techniques that DART developed to rapidly find and evict advanced adversaries from customers.

Here’s a quick summary of the key tools. We’ll share more details on how we use them in our next blog:

  • Endpoint—Microsoft Defender ATP is the default starting point for analysts for almost any investigation (regardless of the source of the alert) because of its powerful visibility and investigation capabilities.
  • Email—Office 365 ATP’s integration with Office 365 Exchange Online helps analysts rapidly find and remove phishing emails from mailboxes. The integration with Microsoft Defender ATP and Azure ATP enables analysts to handle common cases extremely quickly, which lead to growth in our analyst caseload (in a good way ).
  • Identity—Integrating Azure ATP helped complete the triad of the most attacked/utilized resources (Endpoint-Email-Identity) and enabled analysts to smoothly pivot across them (and added some useful detections too).
  • We also added Microsoft Cloud App Security and Azure Security Center to provide high quality detections and improve investigation experience as well.

Even before adding the Automated investigations technology (originally acquired from Hexadite), we found that Microsoft Defender ATP’s Endpoint Detection and Response (EDR) solution increased SOC’s efficiency to the point where Investigation teams analysts can start doing more proactive hunting part-time (often by sifting through lower priority alerts from Microsoft Defender ATP).

Lesson learned: Enable rapid end-to-end workflow for common Email-Endpoint identity attacks.

Ensure your technology investments optimize the analyst workflow to detect, investigate, and remediate common attacks. The Microsoft Defender ATP and connected tools (Office 365 ATP, Azure ATP) was a game changer in our SOC and enabled us to consistently remediate these attacks within minutes. This is our number one recommendation to SOCs as it helped with:

  • Commodity attacks—Efficiently dispatch (a high volume of) commodity attacks in the environment.
  • Targeted attacks—Mitigate impact advanced attacks by severely limiting attack operator time to laterally traverse and explore, hide, set up command/control (C2), etc.

3. Mature case management—To further improve analyst workflow challenges, we transitioned the analyst’s primary queue to our case management service hosted by a commercial SaaS provider. This further reduced our dependency on our legacy SIEM (primarily hosting legacy static analytics that had been refined over time).

Lesson learned: Single queue

Regardless of the size and tooling of your SOC, it’s important to have a single queue and govern quality of it.

This can be implemented as a case management solution, the alert queue in a SIEM, or as simple as the alert list in the Microsoft Threat Protection tool for smaller organizations. Having a single place to go for reactive analysis and ensuring that place produces high quality alerts are key enablers of SOC effectiveness and responsiveness. As a complement to the quality piece, you should also have a proactive hunting activity to ensure that attacker activities are not lost in high noise detection.

Phase 3—Modernize SIEM to cloud native

Our current focus is the transition of the remaining SIEM functions from our legacy capability to Azure Sentinel.

We’re now focused on refining our tool strategy and architecture into a model designed to optimize both breadth (unified view of all events) and depth capabilities. The specialized high-quality tooling (depth tooling) works great for monitoring the “front door” and some hunting but isn’t the only tooling we need.

We’re now in the early stages of operating Microsoft’s Azure Sentinel technology in our SOC to completely replace our legacy on-premises SIEM. This task is a bit simpler for us than most, as we have years of experience using the underlying event log analysis technology that powers Azure Sentinel (Azure Monitor technology, which was previously known as Azure Log Analytics and Operations Management Suite (OMS)).

Our SOC analysts have also been contributing heavily to Azure Sentinel and its community (queries, dashboards, etc.) to share what we have learned about adversaries with our customers.

Learn more details about this SOC and download slides from the CISO Workshop:

Lesson learned: Side-by-side transition state

Based on our experience and conversations with customers, we expect transitioning to cloud analytics like Azure Sentinel will often include a side-by-side configuration with an existing legacy SIEM. This could include a:

  • Short-term transition state—For organizations that are committed to rapidly retiring a legacy SIEM in favor of Azure Sentinel (often to reduce cost/complexity) and need operational continuity during this short bridge period.
  • Medium-term coexistence—For organizations with significant investment into an on-premises SIEM and/or a longer-term plan for cloud migration. These organization recognize the power of Data Gravity—placing analytics closer to the cloud data will avoid costs and challenges of transferring logs to/from the cloud.

Managing the SOC investigations across the SIEM platforms can be accomplished with reasonable efficiency using either a case management tool or the Microsoft Graph Security API (synchronizing Alerts between the two SIEM platforms).

Microsoft is continuing to invest in building more detailed guidance and capabilities to document learnings on this process and continue to refine technology to support it.

Learn more

To learn more, read previous posts in the “Lessons learned from the Microsoft SOC” series, including:

Also, see our full CISO series.

Watch the CISO Spotlight Series: The people behind the cloud.

For a visual depiction of our SOC philosophy, download our Minutes Matter poster.

Stayed tuned for the next segment in “Lessons learned from the Microsoft SOC” where we dive into more of the analyst experience of using these tools to rapidly investigate and remediate attacks. In the meantime, 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.

The post CISO series: Lessons learned from the Microsoft SOC—Part 3a: Choosing SOC tools appeared first on Microsoft Security.

Your password doesn’t matter—but MFA does!

Microsoft Malware Protection Center - Thu, 10/03/2019 - 2:50pm

Your pa$$word doesn’t matter—Multi-Factor Authentication (MFA) is the best step you can take to protect your accounts. Using anything beyond passwords significantly increases the costs for attackers, which is why the rate of compromise of accounts using any MFA is less than 0.1 percent of the general population.

All authenticators are vulnerable

There is a broad range of mechanisms to break authenticators. That doesn’t make all authenticators equally vulnerable. Costs vary massively by attack type, and attacks that preserve anonymity and don’t require proximity to the target are much easier to achieve. Channel-Jacking and Real-Time Phishing are the most dominant ways we see non-password authenticators compromised.

Channel independent, verifier impersonation-resistant authenticator types—such as smartcards, Windows Hello, and FIDO—are incredibly hard to crack. Given an overall strong authentication rate of only about 10 percent, doing any form of MFA takes you out of reach of most attacks. Turn on MFA now and start building a long-term authenticator strategy that relies on “phish proof” authenticators, such as Windows Hello and FIDO.

To learn more, read All your creds are belong to us!

The post Your password doesn’t matter—but MFA does! appeared first on Microsoft Security.

Forrester names Microsoft a Leader in 2019 Endpoint Security Suites Wave

Microsoft Malware Protection Center - Tue, 10/01/2019 - 1:30pm

As we continue as a company to empower every person on the planet to achieve more, we keep delivering on our mission through products that achieve the highest recognition in the industry. For the last several years we’ve been working hard to provide the leading endpoint security product in the market.

Today, we are proud to announce that Microsoft is positioned as a leader in The Forrester Wave: Endpoint Security Suites, Q3 2019, receiving among the second highest scores in both the strategy and market presence categories. According to Forrester, “Microsoft has a compelling vision for the future where endpoint threat prevention and detection are completely integrated and inseparable.”

We believe this latest recognition represents our ability to provide best-in-class protection and deliver on innovations that learn and evolve to keep pace with today’s threat landscape.


This recognition comes at a great point in our evolution journey. We are guided by a strong vision to provide the industry-best protection and we are committed to continue pushing the limits in protection, detection, and response capabilities to secure our customers.

Download this complimentary full report and read the analysis behind Microsoft’s positioning as a Leader.

For more information on our endpoint protection platform, or to sign up for a trial, visit our Microsoft Defender Advanced Threat Protection (ATP) page.

The Forrester Wave: Endpoint Security Suites, Q3 2019, Chris Sherman, September 23, 2019.

This graphic was published by Forrester Research as part of a larger research document and should be evaluated in the context of the entire document. The Forrester document is available upon request from



The post Forrester names Microsoft a Leader in 2019 Endpoint Security Suites Wave appeared first on Microsoft Security.

Rethinking how we learn security

Microsoft Malware Protection Center - Tue, 10/01/2019 - 12:00pm

A couple of years ago, I wrote an article on the relative lack of investor and startup interest in addressing a crucial CISO priority—the preparedness of employees on the security team. Considering what seems to be a steady stream of news about breaches, what can be done to encourage more people to get into cybersecurity and how we can better prepare cyber pros to succeed?

In my own experience, I’ve read white papers and manuals, taken bootcamps and practice tests, and slogged through hours of recorded content. It’s a lot to process, and mostly dependent on the quality of the instructor or delivery format. In this evolving threat environment, content is also outdated as soon as it’s published. Also, training security professionals are focused on certifications, not necessarily practical outcomes.

There’s also an organizational problem: Who in an enterprise owns cyber readiness? HR? A Chief Learning Officer? The CISO? If we’re going to find, hire, and retain tomorrow’s cyber workforce, we must rethink how we reach and prepare people for their careers, so they can continuously learn and stay current on the threats and the tools in front of them. With up to 2 million unfilled cyber roles, this is really a societal challenge.

One innovator that is addressing this is Boulder, Colorado-based Circadence Corporation. I met their CEO, Mike Moniz, at a cyber conference in DC. After one conversation, and upon seeing their “Project Ares®” cyber learning platform, I knew they were on to something. Since then, Circadence and Microsoft have built a very promising partnership to help Circadence scale globally to reach and train more of tomorrow’s cyber workforce. They’re doing this by using Azure infrastructure and platform services; and enjoy the partnership and help.

Circadence focuses on cybersecurity learning and readiness. They build and run immersive, gamified cyber ranges that create a real-time cyber learning environment. In particular is Project Ares, which supports all security proficiency levels of an individual or team—from early career starters to seasoned cyber professionals—for enterprise, government, and academic organizations. Artificial intelligence (AI) powers the delivery of gamified training exercises in battle room and mission virtual machine environments based on actual cyberattack scenarios happening today—such as ransomware, advanced persistent threats, and attacks against industrial control systems.

I signed up for a Circadence account and gave it a shot. I’m not a gamer, but I was really impressed with the UI. Was Circadence actually trying to make learning fun? Project Ares is rooted in proven learning theories and cognitive research. They used resources like Bloom’s Taxonomy of Learning and educational concepts like “reinforcement learning” and “cognitive disfluency” (interrupting the flow of learning with the inclusion of testing, questionnaires, and polls) to match accepted learning concepts with gamified experiences. This isn’t just about making a video game for cyber. And it isn’t just “fun” but informative, educational, practical, and equally innovative without being intimidating.

The learning scenarios are immersive and address varied learning styles, which are two critical design points for maintaining player engagement and lengthening attention span. The platform draws learners across the stages of Bloom’s Taxonomy by:

  • Starting with explanations of techniques, skills, or adversary tactics.
  • Progressing through application of those skills in controlled battle rooms.
  • Arriving at the synthesis of skills and critical thinking to analyze, evaluate, and take actions in an emulated, high-fidelity network against actual malware and emulated threat actors.

Project Ares provides multiple scenarios along a work-role learning path, where you’re required to not only read about cybersecurity, but also must evaluate events in a true network and generate options to achieve objectives. The current catalog contains over 30 cyber games, battle rooms, and missions that provide exposure and experience across many of NIST’s National Initiative on Cybersecurity Education (NICE) work roles in a modern, engaging way.

To learn more about security team training on gamified cyber security ranges in Azure, I sat down with Keenan Skelly, Vice President of Global Partnerships and Security Evangelist. You can watch my interview with Keenan.

This was a great overview of a partner thinking ahead in a creative way to address a major problem in cyber. I encourage anyone interested in improving their own cyber skills, or their team’s skills, to look at gamified learning. Given how younger people interact with IT, it’ll be increasingly important in how we attract them to the industry.

In my next post, I’ll dive deeper into practical learning and defender exercises. In the meantime, 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.

The post Rethinking how we learn security appeared first on Microsoft Security.

TLS version enforcement capabilities now available per certificate binding on Windows Server 2019

Microsoft Malware Protection Center - Mon, 09/30/2019 - 12:00pm

At Microsoft, we often develop new security features to meet the specific needs of our own products and online services. This is a story about how we solved a very important problem and are sharing the solution with customers. As engineers worldwide work to eliminate their own dependencies on TLS 1.0, they run into the complex challenge of balancing their own security needs with the migration readiness of their customers. Microsoft faced this as well.

To date, we’ve helped customers address these issues by adding TLS 1.2 support to older operating systems, by shipping new logging formats in IIS for detecting weak TLS usage by clients, as well as providing the latest technical guidance for eliminating TLS 1.0 dependencies.

Now Microsoft is pleased to announce a powerful new feature in Windows to make your transition to a TLS 1.2+ world easier. Beginning with KB4490481, Windows Server 2019 now allows you to block weak TLS versions from being used with individual certificates you designate. We call this feature “Disable Legacy TLS” and it effectively enforces a TLS version and cipher suite floor on any certificate you select.

Disable Legacy TLS also allows an online or on-premise web service to offer two distinct groupings of endpoints on the same hardware: one which allows only TLS 1.2+ traffic, and another which accommodates legacy TLS 1.0 traffic. The changes are implemented in HTTP.sys, and in conjunction with the issuance of additional certificates, allow traffic to be routed to the new endpoint with the appropriate TLS version. Prior to this change, deploying such capabilities would require an additional hardware investment because such settings were only configurable system-wide via registry.

For a deep dive on this important new feature and implementation details and scenarios, please see Technical Guidance for Disabling Legacy TLS. Microsoft will also look to make this feature available in its own online services based on customer demand.

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.

The post TLS version enforcement capabilities now available per certificate binding on Windows Server 2019 appeared first on Microsoft Security.

Bring your own LOLBin: Multi-stage, fileless Nodersok campaign delivers rare Node.js-based malware

Microsoft Malware Protection Center - Thu, 09/26/2019 - 1:34pm

We’ve discussed the challenges that fileless threats pose in security, and how Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) employs advanced strategies to defeat these sophisticated threats. Part of the slyness of fileless malware is their use of living-off-the-land techniques, which refer to the abuse of legitimate tools, also called living-off-the-land binaries (LOLBins), that already exist on machines through which malware can persist, move laterally, or serve other purposes.

But what happens when attackers require functionality beyond what’s provided by standard LOLBins? A new malware campaign we dubbed Nodersok decided to bring its own LOLBins—it delivered two very unusual, legitimate tools to infected machines:

  • Node.exe, the Windows implementation of the popular Node.js framework used by countless web applications
  • WinDivert, a powerful network packet capture and manipulation utility

Like any LOLBin, these tools are not malicious or vulnerable; they provide important capabilities for legitimate use. It’s not uncommon for attackers to download legitimate third-party tools onto infected machines (for example, PsExec is often abused to run other tools or commands). However, Nodersok went through a long chain of fileless techniques to install a pair of very peculiar tools with one final objective: turn infected machines into zombie proxies.

While the file aspect of the attack was very tricky to detect, its behavior produced is a visible footprint that stands out clearly for anyone who knows where to look. With its array of advanced defensive technologies, Microsoft Defender ATP, defeated the threat at numerous points of dynamic detection throughout the attack chain.

Attack overview

The Nodersok campaign has been pestering thousands of machines in the last several weeks, with most targets located in the United States and Europe. The majority of targets are consumers, but about 3% of encounters are observed in organizations in sectors like education, professional services, healthcare, finance, and retail.


Figure 1. Distribution of Nodersok’s enterprise targets by country and by sector

The campaign is particularly interesting not only because it employs advanced fileless techniques, but also because it relies on an elusive network infrastructure that causes the attack to fly under the radar. We uncovered this campaign in mid-July, when suspicious patterns in the anomalous usage of MSHTA.exe emerged from Microsoft Defender ATP telemetry. In the days that followed, more anomalies stood out, showing up to a ten-fold increase in activity:

Figure 2. Trending of Nodersok activity from August to September, 2019

After a process of tracking and analysis, we pieced together the infection chain:

Figure 3. Nodersok attack chain

Like the Astaroth campaign, every step of the infection chain only runs legitimate LOLBins, either from the machine itself (mshta.exe, powershell.exe) or downloaded third-party ones (node.exe, Windivert.dll/sys). All of the relevant functionalities reside in scripts and shellcodes that are almost always coming in encrypted, are then decrypted, and run while only in memory. No malicious executable is ever written to the disk.

This infection chain was consistently observed in several machines attacked by the latest variant of Nodersok. Other campaigns (possibly earlier versions) with variants of this malware (whose main JavaScript payload was named 05sall.js or 04sall.js) were observed installing malicious encoded PowerShell commands in the registry that would end up decoding and running the final binary executable payload.

Initial access: Complex remote infrastructure

The attack begins when a user downloads and runs an HTML application (HTA) file named Player1566444384.hta. The digits in the file name differ in every attack. Analysis of Microsoft Defender ATP telemetry points to compromised advertisements as the most likely infection vector for delivering the HTA files. The mshta.exe tool (which runs when an HTA file runs) was launched with the -embedding command-line parameter, which typically indicates that the launch action was initiated by the browser.

Furthermore, immediately prior to the execution of the HTA file, the telemetry always shows network activity towards suspicious advertisement services (which may vary slightly across infections), and a consistent access to legitimate content delivery service Cloudfront. Cloudfront is not a malicious entity or service, and it was likely used by the attackers exactly for that reason: because it’s not a malicious domain, it won’t likely raise alarms. Examples of such domains observed in several campaigns are:

  • d23cy16qyloios[.]cloudfront[.]net
  • d26klsbste71cl[.]cloudfront [.]net
  • d2d604b63pweib[.]cloudfront [.]net
  • d3jo79y1m6np83[.]cloudfront [.]net
  • d1fctvh5cp9yen[.]cloudfront [.]net
  • d3cp2f6v8pu0j2[.]cloudfront[.]net
  • dqsiu450ekr8q[.]cloudfront [.]net

It’s possible that these domains were abused to deliver the HTA files without alerting the browser. Another content delivery service abused later on in the attack chain is Cdn77. Some examples of observed URLs include:

  • hxxps://1292172017[.]rsc [.]cdn77 [.]org/images/trpl[.]png
  • hxxps://1292172017[.]rsc.cdn77[.]org/imtrack/strkp[.]png

This same strategy was also used by the Astaroth campaign, where the malware authors hosted their malware on the legitimate service.

First-stage JavaScript

When the HTA file runs, it tries to reach out to a randomly named domain to download additional JavaScript code. The domains used in this first stage are short-lived: they are registered and brought online and, after a day or two (the span of a typical campaign), they are dropped and their related DNS entries are removed. This can make it more difficult to investigate and retrieve the components that were delivered to victims. Examples of domains observed include:

  • Du0ohrealgeek[.]org – active from August 12 to 14
  • Hi5urautopapyrus[.]org – active from April 21 to 22
  • Ex9ohiamistanbul[.]net – active from August 1 to 2
  • Eek6omyfilmbiznetwork[.]org – active from July 23 to 24

This stage is just a downloader: it tries to retrieve either a JavaScript or an extensible style language (XSL) file from the command-and-control (C&C) domain. These files have semi-random names like 1566444384.js and 1566444384.xsl, where the digits are different in every download. After this file is downloaded and runs, it contacts the remote C&C domain to download an RC4-encrypted file named 1566444384.mp4 and a decryption key from a file named 1566444384.flv. When decrypted, the MP4 file is an additional JavaScript snippet that starts PowerShell:

Interestingly, it hides the malicious PowerShell script in an environment variable named “deadbeef” (first line), then it launches PowerShell with an encoded command (second line) that simply runs the contents of the “deadbeef” variable. This trick, which is used several times during the infection chain, is usually employed to hide the real malicious script so that it does not appear in the command-line of a PowerShell process.

Second-stage PowerShell

Nodersok’s infection continues by launching several instances of PowerShell to download and run additional malicious modules. All the modules are hosted on the C&C servers in RC4-encrypted form and are decrypted on the fly before they run on the device. The following steps are perpetrated by the various instances of PowerShell:

  • Download module.avi, a module that attempts to:
    • Disable Windows Defender Antivirus
    • Disable Windows updates
    • Run binary shellcode that attempts elevation of privilege by using auto-elevated COM interface
  • Download additional modules trpl.png and strkp.png hosted on a Cdn77 service
  • Download legitimate node.exe tool from the official website
  • Drop the WinDivert packet capture library components WinDivert.dll, WinDivert32.sys, and WinDivert64.sys
  • Execute a shellcode that uses WinDivert to filter and modify certain outgoing packets
  • Finally, drop the JavaScript payload along with some Node.js modules and libraries required by it, and run it via node.exe

This last JavaScript is the actual final payload written for the Node.js framework that turns the device into a proxy. This concludes the infection, at the end of which the network packet filter is active and the machine is working as a potential proxy zombie. When a machine turns into a proxy, it can be used by attackers as a relay to access other network entities (websites, C&C servers, compromised machines, etc.), which can allow them to perform stealthy malicious activities.

Node.js-based proxy engine

This is not the first threat to abuse Node.js. Some cases have been observed in the past (for example this ransomware from early 2016). However, using Node.js is a peculiar way to spread malware. Besides being clean and benign, Node.exe also has a valid digital signature, allowing a malicious JavaScript to operate within the context of a trusted process. The JavaScript payload itself is relatively simple: it only contains a set of basic functions that allows it to act as a proxy for a remote entity.

Figure 4. A portion of the malicious Node.js-based proxy

The code seems to be still in its infancy and in development, but it does work. It has two purposes:

  1. Connect back to the remote C&C, and
  2. Receive HTTP requests to proxy back to it

It supports the SOCKS4A protocol. While we haven’t observed network requests coming from attackers, we wrote what the Node.js-based C&C server application may look like: a server that sends HTTP requests to the infected clients that connect back to it, and receives the responses from said clients. we slightly modified the malicious JavaScript malware to make it log meaningful messages, ran a JavaScript server, ran the JavaScript malware, and it proxied HTTP requests as expected:

Figure 5.The debug messages are numbered to make it easier to follow the execution flow

The server starts, then the client starts and connects to it. In response, the server sends a HTTP request (using the Socks4A protocol) to the client. The request is a simple HTTP GET. The client proxies the HTTP request to the target website and returns the HTTP response (200 OK) and the HTML page back to the server. This test demonstrates that it’s possible to use this malware as a proxy.

05sall.js: A variant of Nodersok

As mentioned earlier, there exist other variants of this malware. For example, we found one named 05sall.js (possibly an earlier version). It’s similar in structure to the one described above, but the payload was not developed in Node.js (rather it was an executable). Furthermore, beyond acting as a proxy, it can run additional commands such as update, terminate, or run shell commands.

Figure 6. The commands that can be processed by the 05sall.js variant.

The malware can also process configuration data in JSON format. For example, this configuration was encoded and stored in the registry in an infected machine:

Figure 7. Configuration data exposing component and file names

The configuration is an indication of the modular nature of the malware. It shows the names of two modules being used in this infection (named block_av_01 and all_socks_05).

The WinDivert network packet filtering

At this point in the analysis, there is one last loose end: what about the WinDivert packet capture library? We recovered a shellcode from one of the campaigns. This shellcode is decoded and run only in memory from a PowerShell command. It installs the following network filter (in a language recognized by WinDivert):

This means Nodersok is intercepting packets sent out to initiate a TCP connection. Once the filter is active, the shellcode is interested only in TCP packets that match the following specific format:

Figure 8. Format of TCP packets that Nodersok is interested in

The packet must have standard Ethernet, IP, and 20 bytes TCP headers, plus an additional 20 bytes of TCP extra options. The options must appear exactly in the order shown in the image above:

  • 02 04 XX XX – Maximum segment size
  • 01 – No operation
  • 03 03 XX – Windows Scale
  • 04 02 – SACK permitted
  • 08 0A XX XX XX XX XX XX XX XX – Time stamps

If packets matching this criterion are detected, Nodersok modifies them by moving the “SACK Permitted” option to the end of the packet (whose size is extended by four bytes), and replacing the original option bytes with two “No operation” bytes.

Figure 9. The format of TCP packets after Nodersok has altered it: the “SACK permitted” bytes (in red) have been moved to the end of the packet, and their original location has been replaced by “No operation” (in yellow)

It’s possible that this modification benefits the attackers; for example, it may help evade some HIPS signatures.

Stopping the Nodersok campaign with Microsoft Defender ATP

Both the distributed network infrastructure and the advanced fileless techniques allowed this campaign fly under the radar for a while, highlighting how having the right defensive technologies is of utmost importance in order to detect and counter these attacks in a timely manner.

If we exclude all the clean and legitimate files leveraged by the attack, all that remains are the initial HTA file, the final Node.js-based payload, and a bunch of encrypted files. Traditional file-based signatures are inadequate to counter sophisticated threats like this. We have known this for quite a while, that’s why we have invested a good deal of resources into developing powerful dynamic detection engines and delivering a state-of-the-art defense-in-depth through Microsoft Defender ATP:

Figure 10. Microsoft Defender ATP protections against Nodersok

Machine learning models in the Windows Defender Antivirus client generically detects suspicious obfuscation in the initial HTA file used in this attack. Beyond this immediate protection, behavioral detection and containment capabilities can spot anomalous and malicious behaviors, such as the execution of scripts and tools. When the behavior monitoring engine in the client detects one of the more than 500 attack techniques, information like the process tree and behavior sequences are sent to the cloud, where behavior-based machine learning models classify files and identify potential threats.

Meanwhile, scripts that are decrypted and run directly in memory are exposed by Antimalware Scan Interface (AMSI) instrumentation in scripting engines, while launching PowerShell with a command-line that specifies encoded commands is defeated by command-line scanning. Tamper protection in Microsoft Defender ATP protects systems modifications that attempt to disable Windows Defender Antivirus.

These multiple layers of protection are part of the threat and malware prevention capabilities in Microsoft Defender ATP. The complete endpoint protection platform provides multiple capabilities that empower security teams to defend their organizations against attacks like Nodersok. Attack surface reduction shuts common attack surfaces. Threat and vulnerability management, endpoint detection and response, and automated investigation and remediation help organizations detect and respond to cyberattacks. Microsoft Threat Experts, Microsoft Defender ATP’s managed detection and response service, further helps security teams by providing expert-level monitoring and analysis.

With Microsoft Threat Protection, these endpoint protection capabilities integrate with the rest of Microsoft security solutions to deliver comprehensive protection for comprehensive security for identities, endpoints, email and data, apps, and infrastructure.


Andrea Lelli
Microsoft Defender ATP Research

The post Bring your own LOLBin: Multi-stage, fileless Nodersok campaign delivers rare Node.js-based malware appeared first on Microsoft Security.

How to prevent phishing attacks that target your customers with DMARC and Office 365

Microsoft Malware Protection Center - Thu, 09/26/2019 - 12:00pm

You already know that email is the number one attack vector for cybercriminals. But what you might not know is that without a standard email security protocol called Domain Message Authentication, Reporting, and Conformance (DMARC), your organization is open to the phishing attacks that target your customers, crater your email deliverability rates, and crush your email-based revenue streams.

For all the utility of email, which remains the ultimate app for business collaboration and communication, it does have a serious flaw: the ability for a bad actor to pretend to be someone else in an email message. This can be done through one of two attack techniques, spoofing and impersonation. Spoofing is when the sender is attempting to send mail from, or on behalf of, the exact target domain. Impersonation is when the sender if attempting to send mail that is a lookalike, or visually similar, to a targeted domain, targeted user, or targeted brand. When cybercriminals hijack your brand identity, especially your legitimate domains, the phishing attacks they launch against your customers, marketing prospects, and other businesses and consumers can be catastrophic for them—and your business.

Email-based brand spoofing and impersonations surged 250 percent in 2018, with consumers now losing $172 billion to these and other internet scams on an annual basis. More than 90 percent of businesses have been hit by such impersonations, with average losses from successful attacks now standing at $2 million—with an additional $7.9 million in costs when they result in a data breach.

DMARC can help you take control of who can send email messages on your behalf, eliminating the ability for cybercriminals to use your domain to send their illegitimate messages. In addition to blocking fake messages from reaching customers, it helps prevent your business-to-business customers from partner invoice scams like the kind that recently defrauded one large, publicly traded business that lost $45 million. Not a good look for your brand, and a sure way to lose your customers, partners, and brand reputation.

But to protect your corporate domains and prevent executive spoofing of your employees, DMARC must be implemented properly across all your domains and subdomains. And you’ll want your supply chain to do the same to protect your company and partners from such scams. Today, 50 percent of attacks involve “island hopping,” spoofing or impersonating one trusted organization to attack another within the same business ecosystem.

Great, but what exactly is DMARC?

For those not yet familiar with the term, DMARC acts as the policy layer for email authentication technologies already widely in use—including Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

At its most essential, DMARC gives organizations control over who is allowed to send emails on their behalf. It allows email receiver systems to recognize when an email is not coming from a specific brand’s approved domains—and gives guidance to the receiver about what to do with those unauthenticated email messages. DMARC with a p=quarantine or p=reject policy is required to block those illegitimate email messages from ever reaching their targets.

Today, 57 percent of consumer email in industries such as healthcare and retail are now fraudulent. Consumer-focused brand impersonations are up 11 times in the last five years, 80 percent involving email. In 2018, the IC3 received 20,373 BEC/E-mail Account Compromise (EAC) complaints with adjusted losses of over $1.2 billion. Those attacks target your accounting, payroll, and HR departments, so your outbound marketing programs can become toxic to recipients, obliterating your outbound email programs and the revenue they generate.

Microsoft support for email authentication and DMARC

As the vast majority of businesses continue to migrate to capable and robust cloud platforms such as Office 365, a new generation of cybercriminal organizations is rapidly innovating its methods to find nefarious new ways to circumvent the considerable security controls built into these platforms. Unfortunately, some organizations may not realize that they should fully implement DMARC to augment the security benefit of Office 365 email authentication.

Microsoft has implemented support for DMARC across all of its email platforms. This means that when someone sends an email to a Microsoft mailbox on a domain that has published a DMARC record with the reject policy, it will only deliver authenticated email to the mailbox, eliminating spoofing of email domains.

If you use Office 365 but aren’t utilizing custom domains, i.e. you use, you don’t need to do anything else to configure or implement DMARC for your organization. But if you have custom domains, or you’re using on-premises Exchange servers, in addition to Office 365, you’ll need to implement DMARC for outbound mail. All of which is straightforward but implementing it across your entire email ecosystem requires some strategy. To ensure your corporate domains are protected, you’ll need to first publish a DMARC record in DNS with a policy of reject. Microsoft uses Agari’s DMARC reporting tool to enhance protection of Microsoft domains from being used in phishing attacks.

Read more about how Microsoft uses Agari to protect its domain and how that is used to validate email in Office 365 in this Microsoft documentation.

The rise of automated, hosted email authentication

The truth is, properly implementing DMARC means you need to identify every single one of your domains and subdomains, across all business units and outside partners—not just the ones you know to send email. That’s because any domain can be spoofed or impersonated, which means every domain should be DMARC-protected to make sure email receiver infrastructures can assess whether incoming messages purporting to come from any of your domains are legit. Brand protection that only covers some domains isn’t really brand protection at all.

The task of identifying and onboarding thousands of domains controlled by multiple business units, outside agencies, and other external partners, both on Office 365 and off, can be daunting. As a result, many organizations may discover that working with a DMARC provider that can fully automate the implementation process across all these parties plus supply channel partners is their best chance for success. This is especially true for those that offer fully hosted email authentication (DMARC, SPF, and DKIM) to simplify the otherwise tedious and time-consuming process involved with preventing brand impersonations—including ones that leverage domain spoofing.

3 steps to get started with DMARC

The good news is that DMARC is supported by 2.5 billion email inboxes worldwide, and more are joining these ranks every day. But unfortunately, even among organizations with DMARC records assigned to their domains, few have them set to p=reject enforcement. As it stands now, nearly 90 percent of Fortune 500 businesses remain unprotected against email-based spoofing attacks, putting their customers, partners, and other businesses at risk for phishing.

When DMARC is implemented using email ecosystem management solutions, organizations have seen phishing emails sent by fraudsters seeking to spoof them drop to near zero. According to Forrester Research, organizations have also seen email conversion rates climb on average 10 percent, leading to an average $4 million boost in revenues thanks to increased email engagement.

While it’s no small task, there are three steps that will help you move forward with DMARC and get started:

  1. Create a new DMARC record with specific policies to protect your organization from spoofing attacks targeting your employees, customers, prospects, and more. Note that the policy must be a p=reject to prevent unauthorized mail from being received.
  2. Download Getting Started with DMARC, a special guide designed to provide an overview of DMARC and best practice resources.
  3. Request a free trial to Office 365 and see how Agari can help implement DMARC at your organization. As a member of the Microsoft Intelligent Security Association (MISA), and provider of DMARC implementation for more domains than any other provider, Agari offers a free trial to Office 365 users looking to protect their customers, employees, and partners from phishing-based brand spoofing attacks. Given the threat from impersonation scams, and the benefits that come from employing the right approaches to reducing it, don’t be surprised if DMARC-based email authentication jumps to the top of the to-do list for a growing number of businesses. With luck, brand imposters will never know what hit them.

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.

The post How to prevent phishing attacks that target your customers with DMARC and Office 365 appeared first on Microsoft Security.

Top 5 use cases to help you make the most of your Cloud Access Security Broker

Microsoft Malware Protection Center - Wed, 09/25/2019 - 12:00pm

The number of apps and the flexibility for users to access them from anywhere continues to increase. This presents a challenge for IT departments in ensuring secure access and protecting the flow of critical data with a consistent set of controls.

Cloud Access Security Brokers (CASBs) are a new generation of security solutions that are essential to any modern security strategy. CASBs provide a centralized experience that allows you to apply a standardized set of controls to the apps in your organization. The term Cloud Access Security Broker was first introduced by analyst firm Gartner and has since been one of the fastest growing security categories and is considered one of the top 10 security projects for companies to implement by 2020.

Microsoft Cloud App Security is a CASB that allows you to protect all apps in your organization, including third-party apps across cloud, on-premises, and custom applications. Powered by native integrations with Microsoft’s broader product ecosystem, Cloud App Security delivers state-of-the-art security for multi-cloud environments.

Due to the fast pace of the market, the capability set of CASBs continues to grow, making it increasingly challenging for customers to decide how to get started.

Today, we explore five of the top 20 use cases for CASBs we identified as giving you an immediate return on your investment with very little deployment effort needed before moving on to more advanced scenarios.

Use case #1: Discover all cloud apps and resources used in your organization

No matter where you are in your cloud journey, many of your users likely started leveraging cloud services a long time ago and have stored corporate data in various cloud applications.

A CASB provides you with full visibility over all data stored in sanctioned and connected cloud apps. It gives you deep insights about each file, allowing you to identify if it contains sensitive information, the owner and storage location, as well as the access level of the file. Access levels distinguish between private, internal, externally shared, and publicly shared files, allowing you to quickly identify potentially overexposed files putting sensitive information at risk.

Cloud App Security gives you multiple options to get started with Cloud Discovery. You can leverage firewall logs, an existing Secure Web Gateway, or the unique, single-click enablement via Microsoft Defender Advanced Threat Protection (ATP).

To learn how to get started with app discovery, read Discover and manage shadow IT in your network.

Use case #2: Identify and revoke access to risky OAuth apps

In recent years, OAuth apps have become a popular attack vector for adversaries. Hacker groups such as Fancy Bear have leveraged OAuth apps to trick users into authorizing the use of their corporate credentials, for example by duplicating the UI of a seemingly trustworthy platform.

A CASB enables you to closely monitor which OAuth apps are being authorized against your corporate environment and either manually review them or create policies that automatically revoke access if certain risky criteria are met. Key threat indicators are the combination of an app that has requested a high level of permissions, while having a low community use status, indicating that it’s not commonly found in other organizations and therefore more unlikely to be trustworthy.

Once you’ve enabled app discovery, all you need to do is connect the relevant apps like Office 365, Salesforce, or G-Suite to the service. You’re then alerted when new risky OAuth apps are authorized, so you can start managing them.

To learn more about how to get started with app discovery, read Manage OAuth apps.

Use case #3: Identify compromised user accounts

Identity attacks have increased by more than 300 percent over the past year, making them a key source of compromise and the number one threat vector for organizations.

A CASB learns the behavior of users and other entities in an organization and builds a behavioral profile around them. If an account is compromised and executes activities that differ from the baseline user profile, abnormal behavior detections are raised.

Using built-in and custom anomaly detections, IT is alerted on activities, such as impossible travel, as well as activities from infrequent countries, or the implementation of inbox forwarding rules where emails are automatically forwarded to external email addresses. These alerts allow you to act quickly and quarantine a user account to prevent damage to your organization. All you have to do is connect the relevant apps to Cloud App Security and activate our built-in threat detection policies.

To learn how to get started, read Monitor alerts in Cloud App Security.

Use case #4: Enforce DLP policies for sensitive data stored in your cloud apps

Cloud services such as Office 365 or Slack are key productivity solutions in many organizations today. Consequently, sensitive corporate data is uploaded and shared across them.

For existing data, a CASB solution can help you identify files that contain sensitive information and it provides several remediation options, including removing external sharing permissions, encrypting the file, placing it in admin quarantine, or deleting it if necessary.

Additionally, you can enforce data loss prevention (DLP) policies that scan every file as soon as it’s uploaded to a cloud app, to alert on policy violations and automatically apply data labels and relevant restrictions to protect your information. These policies can be created using advanced techniques such as data identities, regular expressions, OCR, and exact data matching.

To learn how to get started with a centralized DLP strategy across your key apps, read File policies.

Use case #5: Enforce adaptive session controls to manage user actions in real-time

In a cloud-first world, identity has become the new perimeter—protecting access to all your corporate resources at the front door.

Cloud App Security leverages Azure Active Directory (Azure AD) Conditional Access policies to determine a user’s session risk upon sign-in. Based on the risk level associated with a user session, you can enforce adaptive in-session controls that determine which actions a user can carry out and which may be limited or blocked entirely. This seamless identity-based experience ensures the upkeep of productivity, while preventing potentially risky user actions in real-time. The adaptive controls include the prevention of data exfiltration by blocking actions such as download, copy, cut, or print, as well as the prevention of malicious data infiltration to your cloud apps by preventing malicious uploads or pasting text.

You can apply a standardized set of controls to any app in your organizations, whether it’s a cloud app, on-premises app, or a custom application, giving you a consistent set of controls to protect your most sensitive information.

To get started with our built-in templates for inline controls, read Deploy Conditional Access App Control for featured apps.

Starting a CASB project can be daunting given the breadth of capabilities and possibilities of configuration. The five use cases outlined above, and the focus on simple deployment and optimization of UI in Cloud App Security, will ensure that you can make the most of your investment and get started quickly. For more use cases, download our Top 20 CASB use cases e-book.

Learn more and provide feedback

As always, we want to hear from you! If you have any suggestions, questions, or comments, please visit us on our TechCommunity page.

The post Top 5 use cases to help you make the most of your Cloud Access Security Broker appeared first on Microsoft Security.