Archive

Archive for the ‘cybersecurity’ Category

Making Azure Sentinel work for you

July 9th, 2020 No comments

Microsoft Azure Sentinel is the first Security Incident and Event Management (SIEM) solution built into a major public cloud platform that delivers intelligent security analytics across enterprise environments and offers automatic scalability to meet changing needs. This new white paper outlines best practice recommendations for configuring data sources for Azure Sentinel, using Azure Sentinel during incident response, and proactively hunting for threats using Azure Sentinel.

Research shows that, on average, 44% of security alerts that are raised by security solutions go uninvestigated. Organizations simply lack the time, tools, and talent to investigate and correlate every single alert. In many cases this results in a focus on alerts that are flagged as “critical” or “very important” and lower severity alerts are ignored. However, experience shows that investigating those lower severity alerts – and how they may be correlated to show more worrying combinations of actions – can reveal attacker behaviors that would otherwise fly under the radar.

Azure Sentinel is an incredibly powerful tool that can help you collect security data across your entire hybrid organization from devices, users, apps, servers, and any cloud. Using these data sources you can build a more complete picture of the threats that your organization faces, conduct deep threat hunts across your environment, and use the power of automation and orchestration in the cloud to help free up your security analysts to focus on their highest-value tasks.

Traditional SIEMs have proven to be expensive to own and operate, often requiring you to commit up front and incur high cost for infrastructure maintenance and data ingestion. Azure Sentinel provides you with SIEM-as-a-service and SOAR-as-a-service for the SOC: your birds-eye view across the enterprise; putting the cloud and large-scale intelligence from decades of Microsoft security experience to work. Following the best practices outlined within this white paper will help you eliminate security infrastructure setup and maintenance and provide you with scalability to meet your security needs— all while reducing costs and increasing visibility and control. 

For more information on Microsoft Security Solutions, visit our website. 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 Making Azure Sentinel work for you appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents

July 9th, 2020 No comments

Cybersecurity incidents are never contained to just one of your organization’s assets. Most attacks involve multiple elements across domains, including email, endpoints, identities, and applications. To rapidly understand and address incidents, your Security Operations Center (SOC) analysts need to be able to see and track all the signals from each domain, correlate and group alerts that are related, prioritize them based on their severity level, and remediate all affected assets to return them and your workforce to a secure state.

Getting a unified view of an attack is a top SOC analyst priority in quickly building the end-to-end picture of attacks and tracking all relevant details necessary for effective remediation. Navigating multiple products and switching between tools introduce friction that slows down investigations, giving attackers more time to inflict damage.

Microsoft Threat Protection (MTP) addresses this critical SOC need through incidents, which empower SOC analysts by automatically fusing attack evidence and providing a consolidated view of an attack chain and affected assets, as well as a single-click remediation with easy-to-read analyst workflows. MTP harnesses the power of multiple solutions in the Microsoft 365 security portfolio – Office 365 Advanced Threat Protection (ATP), Azure ATP, Microsoft Defender ATP, and Microsoft Cloud App Security – to deliver cross-domain visibility and coordinated defense.

A complete look at the attack chain to prevent attack sprawl

A typical attack starts with a phishing email that installs malware on an endpoint. The malware then steals the user’s credentials, which the attackers utilize to access resources on other endpoints, on-premises applications, and cloud services. Individual security solutions that focus on only one domain may alert on and remediate a portion of the attack but will likely miss other parts of the attacker operations, putting an organization at risk while creating a false sense of security.

The incidents view in Microsoft Threat Protection solves this challenge by providing a single place to view and investigate an attack across stages, from initial access to impact. Based on individual detection leads, MTP uses artificial intelligence (AI) to automatically expand an investigation, like an experienced analyst would, and gather related telemetry and other alerts that belong to the same attack. MTP also uses AI to continually analyze the vast amount of available data and, if necessary, suggest more evidence for the analyst to add to the incident. This enables your SOC analysts to focus on what matters, while MTP saves them time and helps discover undetected evidence.

Even if you don’t have all the Microsoft 365 security solutions in your organization, MTP incidents correlate threat data for the services you have deployed, reducing the clutter and providing one view of the attack, including all relevant alerts, impacted assets and associated risk levels, remediation actions and status.

Screenshot of Microsoft 365 security center showing the overview tab of the Incidents view

Streamlining investigations across domains

Microsoft Threat Protection simplifies the complex task of investigating end-to-end attacks by allowing SOC analysts to pivot and see entities – devices, files, users, emails, and processes – in the right context within a single view.

MTP breaks down the silos and combines all alerts and insights automatically across Microsoft 365 services to reveal the full picture, helping ease digital forensics work for SOC analysts. This also enables analysts to gain comprehensive understanding of attacks that they wouldn’t otherwise get from isolated out-of-context alerts.

But MTP doesn’t stop there. To help support effective triage processes, MTP prioritizes incidents, illustrates the attack chain progression, shows the attack timeline, and generates a comprehensive name for the incident. With just one click, analysts can answer questions like: Does a file observed on one device exist on other devices? Which email messages did a file come from, and was this file also shared through a cloud app?

In addition, SOC analysts can easily search for additional related activities with Go hunt, which automatically creates and runs an advanced hunting query based on information from the incident. SOC analysts can also use attack-specific insights gained during hunting to capture fine-tuned logic and nuances in a custom detection. Custom detections continuously hunt for new activities and pull new findings to the relevant incident automatically, further enriching your view of the attack.

A clear view of the remediation status

When your organization is under attack, it’s essential to act swiftly but thoughtfully through a thorough understanding at any point in time of the remediation status of all affected assets and entities. MTP incidents play a critical part in remediation by:

  • Removing some of the burden off the analysts’ shoulders by launching automated investigation and response (AIR) self-healing playbooks that conduct in-depth asset-based investigation and work to find and remediate all malicious evidence (attack tools, malware), persistence methods (Oauth apps, ASEP in devices), exfiltration activities (email FWD rules, SPO shares),
  • Orchestrating cross-asset and cross-domain playbook invocations, tracking attacker activity across the environment
  • Providing a comprehensive view of the remediation status based on actions taken by AIR, in addition to manual actions by the analyst

When the investigation is complete, MTP incidents capture the investigation comments for record-keeping and knowledge-sharing with peers, with easy and in-context information for reference.

Microsoft Threat Protection provides the SOC with a complete picture of attacks in real-time

The incidents view in Microsoft Threat Protection correlates alerts and all affected entities into a cohesive view that enables your SOC to determine the full scope of threats across your Microsoft 365 services. Armed with a complete picture of attacks in real-time, your SOCs are better empowered to defend your organization against threats.

MTP delivers coordinated defense by leveraging the power of multiple Microsoft 365 security solutions. Through automation, built-in intelligence, and end-to-end visibility into malicious activities, MTP detects, correlates, blocks, remediates, and prevents attacks.

Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost or deployment. Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense.

To learn more about coordinated defense, read these blog posts in the Inside Microsoft Threat Protection series:

 

Idan Pelleg

Microsoft Threat Protection Team

The post Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents

July 9th, 2020 No comments

Cybersecurity incidents are never contained to just one of your organization’s assets. Most attacks involve multiple elements across domains, including email, endpoints, identities, and applications. To rapidly understand and address incidents, your Security Operations Center (SOC) analysts need to be able to see and track all the signals from each domain, correlate and group alerts that are related, prioritize them based on their severity level, and remediate all affected assets to return them and your workforce to a secure state.

Getting a unified view of an attack is a top SOC analyst priority in quickly building the end-to-end picture of attacks and tracking all relevant details necessary for effective remediation. Navigating multiple products and switching between tools introduce friction that slows down investigations, giving attackers more time to inflict damage.

Microsoft Threat Protection (MTP) addresses this critical SOC need through incidents, which empower SOC analysts by automatically fusing attack evidence and providing a consolidated view of an attack chain and affected assets, as well as a single-click remediation with easy-to-read analyst workflows. MTP harnesses the power of multiple solutions in the Microsoft 365 security portfolio – Office 365 Advanced Threat Protection (ATP), Azure ATP, Microsoft Defender ATP, and Microsoft Cloud App Security – to deliver cross-domain visibility and coordinated defense.

A complete look at the attack chain to prevent attack sprawl

A typical attack starts with a phishing email that installs malware on an endpoint. The malware then steals the user’s credentials, which the attackers utilize to access resources on other endpoints, on-premises applications, and cloud services. Individual security solutions that focus on only one domain may alert on and remediate a portion of the attack but will likely miss other parts of the attacker operations, putting an organization at risk while creating a false sense of security.

The incidents view in Microsoft Threat Protection solves this challenge by providing a single place to view and investigate an attack across stages, from initial access to impact. Based on individual detection leads, MTP uses artificial intelligence (AI) to automatically expand an investigation, like an experienced analyst would, and gather related telemetry and other alerts that belong to the same attack. MTP also uses AI to continually analyze the vast amount of available data and, if necessary, suggest more evidence for the analyst to add to the incident. This enables your SOC analysts to focus on what matters, while MTP saves them time and helps discover undetected evidence.

Even if you don’t have all the Microsoft 365 security solutions in your organization, MTP incidents correlate threat data for the services you have deployed, reducing the clutter and providing one view of the attack, including all relevant alerts, impacted assets and associated risk levels, remediation actions and status.

Screenshot of Microsoft 365 security center showing the overview tab of the Incidents view

Streamlining investigations across domains

Microsoft Threat Protection simplifies the complex task of investigating end-to-end attacks by allowing SOC analysts to pivot and see entities – devices, files, users, emails, and processes – in the right context within a single view.

MTP breaks down the silos and combines all alerts and insights automatically across Microsoft 365 services to reveal the full picture, helping ease digital forensics work for SOC analysts. This also enables analysts to gain comprehensive understanding of attacks that they wouldn’t otherwise get from isolated out-of-context alerts.

But MTP doesn’t stop there. To help support effective triage processes, MTP prioritizes incidents, illustrates the attack chain progression, shows the attack timeline, and generates a comprehensive name for the incident. With just one click, analysts can answer questions like: Does a file observed on one device exist on other devices? Which email messages did a file come from, and was this file also shared through a cloud app?

In addition, SOC analysts can easily search for additional related activities with Go hunt, which automatically creates and runs an advanced hunting query based on information from the incident. SOC analysts can also use attack-specific insights gained during hunting to capture fine-tuned logic and nuances in a custom detection. Custom detections continuously hunt for new activities and pull new findings to the relevant incident automatically, further enriching your view of the attack.

A clear view of the remediation status

When your organization is under attack, it’s essential to act swiftly but thoughtfully through a thorough understanding at any point in time of the remediation status of all affected assets and entities. MTP incidents play a critical part in remediation by:

  • Removing some of the burden off the analysts’ shoulders by launching automated investigation and response (AIR) self-healing playbooks that conduct in-depth asset-based investigation and work to find and remediate all malicious evidence (attack tools, malware), persistence methods (Oauth apps, ASEP in devices), exfiltration activities (email FWD rules, SPO shares),
  • Orchestrating cross-asset and cross-domain playbook invocations, tracking attacker activity across the environment
  • Providing a comprehensive view of the remediation status based on actions taken by AIR, in addition to manual actions by the analyst

When the investigation is complete, MTP incidents capture the investigation comments for record-keeping and knowledge-sharing with peers, with easy and in-context information for reference.

Microsoft Threat Protection provides the SOC with a complete picture of attacks in real-time

The incidents view in Microsoft Threat Protection correlates alerts and all affected entities into a cohesive view that enables your SOC to determine the full scope of threats across your Microsoft 365 services. Armed with a complete picture of attacks in real-time, your SOCs are better empowered to defend your organization against threats.

MTP delivers coordinated defense by leveraging the power of multiple Microsoft 365 security solutions. Through automation, built-in intelligence, and end-to-end visibility into malicious activities, MTP detects, correlates, blocks, remediates, and prevents attacks.

Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost or deployment. Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense.

To learn more about coordinated defense, read these blog posts in the Inside Microsoft Threat Protection series:

 

Idan Pelleg

Microsoft Threat Protection Team

The post Inside Microsoft Threat Protection: Correlating and consolidating attacks into incidents appeared first on Microsoft Security.

Introducing Kernel Data Protection, a new platform security technology for preventing data corruption

July 8th, 2020 No comments

Attackers, confronted by security technologies that prevent memory corruption, like Code Integrity (CI) and Control Flow Guard (CFG), are expectedly shifting their techniques towards data corruption. Attackers use data corruption techniques to target system security policy, escalate privileges, tamper with security attestation, modify “initialize once” data structures, among others.

Kernel Data Protection (KDP) is a new technology that prevents data corruption attacks by protecting parts of the Windows kernel and drivers through virtualization-based security (VBS). KDP is a set of APIs that provide the ability to mark some kernel memory as read-only, preventing attackers from ever modifying protected memory. For example, we’ve seen attackers use signed but vulnerable drivers to attack policy data structures and install a malicious, unsigned driver. KDP mitigates such attacks by ensuring that policy data structures cannot be tampered with.

The concept of protecting kernel memory as read-only has valuable applications for the Windows kernel, inbox components, security products, and even third-party drivers like anti-cheat and digital rights management (DRM) software. On top of the important security and tamper protection applications of this technology, other benefits include:

  • Performance improvements – KDP lessens the burden on attestation components, which would no longer need to periodically verify data variables that have been write-protected
  • Reliability improvements – KDP makes it easier to diagnose memory corruption bugs that don’t necessarily represent security vulnerabilities
  • Providing an incentive for driver developers and vendors to improve compatibility with virtualization-based security, improving adoption of these technologies in the ecosystem

KDP uses technologies that are supported by default on Secured-core PCs, which implement a specific set of device requirements that apply the security best practices of isolation and minimal trust to the technologies that underpin the Windows operating system. KDP enhances the security provided by the features that make up Secured-core PCs by adding another layer of protection for sensitive system configuration data.

In this blog we’ll share technical details about how Kernel Data Protection works and how it’s implemented on Windows 10, with the goal of inspiring and empowering driver developers and vendors to take full advantage of this technology designed to tackle data corruption attacks.

Kernel Data Protection: An overview

In VBS environments, the normal NT kernel runs in a virtualized environment called VTL0, while the secure kernel runs in a more secure and isolated environment called VTL1. More details on VBS and the secure kernel are available on Channel 9 here and here. KDP is intended to protect drivers and software running in the Windows kernel (i.e., the OS code itself) against data-driven attacks. It is implemented in two parts:

  • Static KDP enables software running in kernel mode to statically protect a section of its own image from being tampered with from any other entity in VTL0.
  • Dynamic KDP helps kernel-mode software to allocate and release read-only memory from a “secure pool”. The memory returned from the pool can be initialized only once.

The memory managed by KDP is always verified by the secure kernel (VTL1) and protected using second level address translation (SLAT) tables by the hypervisor. As a result, no software running in the NT kernel (VTL0) will ever be able to modify the content of the protected memory.

Both dynamic and static KDP, which are already available in the latest Windows 10 Insider Build and work with any kind of memory, except for executable pages. Protection for executable pages is already provided by hypervisor-protected code integrity (HVCI), which prevents any non-signed memory from being ever executable, granting the W^X (a page that is either writable or executable, but never both) condition. HVCI and the W^X conditions are not explained in this article (refer to the new upcoming Windows Internals book for further details).

Static KDP

A driver that wants a section of its image protected through static KDP should call the MmProtectDriverSection API, which has the following prototype:

NTSTATUS MmProtectDriverSection (PVOID AddressWithinSection, SIZE_T Size, ULONG Flags)

A driver specifies an address located inside a data section and, optionally, the size of the protected area and some flags. As of this writing, the “size” parameter is reserved for future use: the entire data section where the address resides will always be protected by the API.

In case the function succeeds, the memory backing the static section becomes read-only for VTL0 and protected through the SLAT. Unloading a driver that has a protected section is not allowed; attempting to do so will result in, by design, a blue screen error. However, we know that sometimes a driver should be able to be unloaded. Therefore, we have introduced the MM_PROTECT_DRIVER_SECTION_ALLOW _UNLOAD flag (1). If the caller specifies it, the system will be able to unload the target driver, which means that in this case, the protected section will be first unprotected and then released by NtUnloadDriver.

Dynamic KDP

Dynamic KDP allows a driver to allocate and initialize read-only memory using services provided by a secure pool, which is managed by the secure kernel. The consumer first creates a secure pool context associated with a tag. All of the consumer’s future memory allocations will be associated with the created secure pool context. After the context is created, read-only allocations can be performed through a new extended parameter to the ExAllocatePool3 API:

PVOID ExAllocatePool3 (POOL_FLAGS Flags, SIZE_T NumberOfBytes, ULONG Tag, PCPOOL_EXTENDED_PARAMETER ExtendedParameters, ULONG Count);

The caller can then specify the size of the allocation and the initial buffer from where to copy the memory in a POOL_EXTENDED_PARAMS_SECURE_POOL data structure. The returned memory region can’t be modified by any entity running in VTL0. In addition, at allocation time, the caller supplies a tag and a cookie value, which are encoded and embedded into the allocation. The consumer can, at any time, validate that an address is within the memory range reserved for dynamic KDP allocations and that the expected cookie and tag are in fact encoded into a given allocation. This allows the caller to check that their pointer to a secure pool allocation has not been switched with a different allocation.

Similar to static KDP, by default the memory region can’t be freed or modified. The caller can specify at allocation time that the allocation is freeable or modifiable using the SECURE_POOL_FLAGS_FREEABLE (1) and SECURE_POOL_FLAG_MODIFIABLE(2) flags. Using these flags reduces the security of allocation but allows dynamic KDP memory to be used in scenarios where leaking all allocations would be infeasible, such as allocations which are made per process on the machine.

Implementing KDP on Windows 10

As mentioned, both static KDP and dynamic KDP rely on the physical memory being protected by the SLAT in the hypervisor. When a processor supports the SLAT, it uses another layer for memory address translation. (Note: AMD implements the SLAT through “nested page tables”, while Intel uses the term “extended page tables”.)

The second-level address translation (SLAT)

When the hypervisor enables SLAT support, and a VM is executing in VMX non-root mode, the processor translates an initial virtual address called Guest Virtual Address (GVA, or stage 1 virtual address in ARM64) in an intermediate physical address called Guest Physical Address (GPA, or IPA in ARM64). This translation is still managed by the page tables, addressed by the CR3 control register managed by the Guest OS. The final result of the translation yields back to the processor a GPA, with the access protection specified in the guest page tables. Note that only software operating in kernel mode can interact with page tables. A rootkit usually operates in kernel mode and can indeed modify the protection of the intermediate physical pages.

The hypervisor helps the processor to translate the GPA using the extended (or nested) page tables. On non-SLAT systems, when a virtual address is not present in the TLB, the processor needs to consult all the page tables in the hierarchy to reconstruct the final physical address. As shown in Figure 1, the virtual address is split into four parts (on LA48 systems). Each part represents the index into a page table of the hierarchy. The physical address of the initial PML4 table is specified by the CR3 register. This explains why the processor is always able to translate the address and get the next physical address of the next table in the hierarchy. It’s important to note that in each page table entry of the hierarchy, the NT kernel specifies a page protection through a set of attributes. The final physical address is accessible only if the sum of the protections specified in each page table entry allows it.

Diagram showing X64 stage 1 address translation from virtual address to guest physical address

Figure 1. The X64 Stage 1 address translation (Virtual address to guest physical address)

When the SLAT is on, the intermediate physical address specified in the guest’s CR3 register needs to be translated to a real system physical address (SPA). The mechanism is similar: the hypervisor configures the nCR3 field of the active virtual machine control block (VMCB) representing the currently executing VM to the physical address of the nested (or extended) page tables (note that the field is called “EPT pointer” in the Intel architecture). The nested page tables are built in a similar way to standard page tables, so the processor needs to scan the entire hierarchy to find the correct physical address, as illustrated in figure 2. In the figure, “n” indicates nested page tables in the hierarchy, which is managed by the hypervisor, while “g” indicates guest page tables, which is managed by the NT Kernel.

Diagram showing X64 stage 2 physical address translation from GPA to SPA

Figure 2. The X64 Stage 2 physical address translation (GPA to SPA)

As shown, the final translation of a guest virtual address to a system physical address goes through two translation types: GVA to GPA, configured by the guest VM’s kernel, and GPA to SPA, configured by the hypervisor. Note that in the worst case, the translation involves all four page hierarchy levels, which results in 20 table lookups. The mechanism could be slow and is mitigated by processor support for an enhanced TLB. In the TLB entries, another ID that identifies the currently executing VM is included (called virtual processor identifier or VPID in Intel systems, address space ID or ASID in AMD systems), so the processor can cache the translation result of a virtual address belonging to two different VMs without any collision.

Diagram showing nested entry of an NPT page table in the hierarchy

Figure 3. Nested entry of an NPT page table in the hierarchy

As highlighted in Figure 3, an NPT entry specifies multiple access protection attributes. This allows the hypervisor to further protect the system physical address (the NPT cannot be accessed by any other entity except for the hypervisor itself). When the processor attempts to read, write, or run an address to which the NPTs disallow access, an NPT violation (EPT violation in Intel architecture) is raised, and a VM exit is generated. A VM exit generated by NTP violation does not happen frequently. In general, it is produced in nested configurations or when Software MBEC is in use for HVCI. If the NPT violation happens for other reasons, the Microsoft Hypervisor injects an access violation exception to the current virtual processor (VP), which is managed by the guest OS in different ways but typically through a bug check if no exception handler elects to handle the exception.

Static KDP implementation

The SLAT protection is the main principle that allows KDP to exist. In Windows, dynamic and static KDP implementations are similar and are managed by the secure kernel. The secure kernel is the only entity that is able to emit the ModifyVtlProtectionMask hypercall to the hypervisor with the goal of modifying the SLAT access protection for a physical page mapped in the lower VTL0.

For static KDP, the NT kernel verifies that the driver is not a session driver or mapped with large pages. If one of these conditions exists, or if the section is a discardable section, static KDP can’t be applied. If the entity that called the MmProtectDriverSection API did not request the target image to be unloadable, the NT kernel performs the first call into the secure kernel, which pins the normal address range (NAR) associated with the driver. The “pinning” operation prevents the address space of the driver from being reused, making the driver not unloadable. The NT kernel then brings all the pages that belong to the section in memory and makes them private (i.e., not addressed by the prototype PTEs). The pages are then marked as read-only in the leaf PTE structures (highlighted as “gPTE” in figure 2). At this stage, the NT kernel can finally call the secure kernel for protecting the underlying physical pages through the SLAT. The secure kernel applies the protection in two phases:

  1. Register all the physical pages that belong to the section and mark them as “owned by VTL0” by adding the proper NTEs (normal table addresses) in the database and updating the underlying secure PFNs, which belong to VTL1. This allows the secure kernel to track the physical pages, which still belong to the NT kernel.
  2. Apply the read-only protection to the VTL0 SLAT table. The hypervisor uses one SLAT table and VMCB per VTL.

The target image’s section is now protected. No entity in VTL0 will be able to write to any of the pages belonging to the section. As highlighted, the secure kernel in this scenario has protected some memory pages that were initially allocated by the NT kernel in VTL0.

Dynamic KDP implementation

Dynamic KDP uses services provided by the new segment heap for allocating memory from a secure pool, which is almost entirely managed by the secure kernel.

In early phases of its boot process, the NT memory manager calculates the randomized virtual base address of a 512GB region used for the secure pool, which spans exactly one of the 256 kernel PML4 entries. Later in phase 1, the NT memory manager emits a secure call, internally named  INITIALIZE_SECURE_POOL, which includes the calculated memory region and allows the secure kernel to initialize the secure pool.

The secure kernel creates a NAR representing the entire 512GB virtual region belonging to the unsecure NT kernel, and initializes all the relative NTEs belonging to the NAR. The secure pool virtual address space in the secure kernel is 256GB wide, which means that the PML4 mapping it is shared with some other content and is not at the same base address compared to the NT one. So, while initializing the secure pool descriptor, the secure kernel also calculates a delta value, which is the difference between the secure pool base address in the secure kernel and the one reserved in the NT kernel (as shown in figure 4). This is important, because it allows the secure kernel to specify to the NT kernel where to map a physical page belonging to the secure pool.

Diagram showing the secure pool from VTL1 to VT0 delta

Figure 4. The Secure Pool VTL1 to VTL 0 DELTA value.

When software running in VTL0 kernel requests some memory to be allocated from the secure pool, a secure call is made to the secure kernel, which invokes the internal RtlpHpAllocateHeap heap function, which is exposed in both VTLs. If the segment heap calculates that there are no more free memory segments left in the secure pool, it calls the SkmmAllocatePoolMemory routine, which allocates new memory pages for the pool. The heap always tries to avoid committing new memory pages if it doesn’t really need to.

Like the NtAllocateVirtualMemory API, which is exposed by the NT kernel, the SkmmAllocatePoolMemory API supports two kinds of operations: reserve and commit. A reserve operation allows the secure kernel’s memory manager to reserve some PTEs needed for the pool allocation. A commit operation actually allocates free physical pages.

Physical pages are allocated from a bundle of free pages that belong to the secure kernel, whose secure PFNs are in the secure state, and mapped in the VTL 1’s page table, which means that all the VTL 1 paging table hierarchy are allocated. Like static KDP, the secure kernel sends the “ModifyVtlProtectionMask” hypercall to the hypervisor, with the goal of mapping the physical pages as read-only in the VTL0 SLAT table. After the pages become accessible to VTL0, the secure kernel copies the data specified by the caller and calls back NT.

The NT kernel uses services provided by the memory manager to map the guest physical pages in VTL0. Remember that the entire root partition physical address space of both VTL0 and VTL1 is mapped with the identity mapping, meaning that a guest physical page number valid in VTL0 is also valid in VTL1. The secure kernel asks the NT memory manager to map a page belonging to the secure pool by knowing exactly which virtual address the page should be mapped to. This is thanks to the delta value calculated previously in phase 1 (figure 4).

The allocation is returned to the caller in VTL0. The underlaying pages, as with static KDP, are no more writable from any entity in VTL0.

Astute readers will note that the above description of KDP deals only with establishing SLAT protections for the guest physical address(es) backing a given protected memory region. KDP does not enforce how the virtual address range mapping a protected region is translated. Today, the secure kernel verifies only on a periodic basis that protected memory regions translate to the appropriate, SLAT-protected GPA. The design of KDP permits the possibility of future extensions to assert more direct control over the address translation hierarchy of protected memory regions.

Applications of KDP on inbox components

To demonstrate how KDP can provide value two inbox components, we’re highlighting how it’s implemented in CI.dll, the code integrity engine in Windows, and the Windows Defender System Guard runtime attestation engine.

First, CI.dll. The goal of using KDP is to protect internal policy state after it has been initialized (i.e., read from the registry or generated at boot time). These data structures are critical to protect as if they are tampered with—a driver that is properly signed but vulnerable could attack the policy data structures and then install an unsigned driver on the system. With KDP, this attack is mitigated by ensuring the policy data structures cannot be tampered with.

Second, Windows Defender System Guard. To provide runtime attestation, the attestation broker is only allowed to connect to the attestation driver one time. This is because the state is stored in VTL1 memory. The driver stores the connection state in its memory and this needs to be protected to prevent an attack from trying to reset the connection with a potentially tampered with broker agent. KDP can lock these variables and ensure that only a single connection between the broker and driver can be established.

Code integrity and Windows Defender System Guard are two of the critical features of Secured-core PCs. KDP enhances protection for these vital security systems and raise the bar that attackers need to overcome to compromise Secured-core PCs.

These are just a few examples of how useful protecting kernel and driver memory as read-only can be for the security and integrity of the system. As KDP is adopted more broadly, we expect to be able to expand the scope of protection as we look to protect against data corruption attacks more broadly.

Getting started with KDP

Both dynamic and static KDP do not have any further requirements other than the ones needed for running virtualization-based security. In ideal conditions, VBS can be started on any computer that supports:

  • Intel, AMD or ARM virtualization extensions
  • Second-level address translation: NPT for AMD, EPT for Intel, Stage 2 address translation for ARM
  • Optionally, hardware MBEC, which reduces the performance cost associated with HVCI

More info on the requirements for VBS can be found here. On Secured-core PCs, virtualization-based security is supported and hardware-backed security features are enabled by default. Customers can find Secured-core PCs from a variety of partner vendors that feature the comprehensive Secured-core security features that are now enhanced by KDP.

 

Andrea Allievi

Security Kernel Core Team

The post Introducing Kernel Data Protection, a new platform security technology for preventing data corruption appeared first on Microsoft Security.

New study shows customers save time, resources and improve security with Microsoft Cloud App Security

July 7th, 2020 No comments

The global pandemic has forever changed our workplaces and reshaped our cybersecurity priorities. While in recent months cloud apps have helped people around the globe stay productive and connected. They also pose an increased cybersecurity risk to businesses large and small, especially when you don’t know which cloud apps your employees may be using.  Now, as many countries and companies are entering a new phase toward hybrid work environments, we must apply digital empathy—the idea that cyber systems need to provide both strong security and a great user experience—to address this critical security and compliance priority.

Even before COVID-19, software-as-a-service (SaaS) was growing rapidly because the cloud makes it easy and cost-effective for people to find the tools they need. At the same time, businesses using conventional security suites to try to address vulnerabilities and protect their estates were finding limited success with low visibility into their data, user behavior and sensitive data moving to the cloud.

According to a May 2020 Forrester Consulting Total Economic Impact™ (TEI) Study commissioned by Microsoft, these limitations have led to the rise of shadow IT, difficulty recognizing and remediating security threats, and the need to rapidly adapt to new compliance requirements for the cloud. The study interviewed four existing customers in four industries, including manufacturing, medical devices, education, and health care. It also provided a closer look at the potential financial impact of using Microsoft’s Cloud App Security solution to gain visibility of an organization’s native and third-party applications. That included easier monitoring of security and risks associated with cloud applications and sensitive data, improving detection and remediation of incidents, and improving compliance.

The Forrester study shows a three-year 151% ROI and less than 3-month payback on Cloud App Security investment

To better understand the benefits, costs and risks associated with a Microsoft Cloud App Security investment, Forrester interviewed four organizations with years of experience using Cloud App Security. It also developed a financial analysis of a composite organization to create a financial model framework. The results show organizations can save time and resources with a three-year ROI of 151% and payback of less than 3 months by more easily discovering potential security and compliance risks, automating threat protection and providing more time for people to focus their attention on higher priorities.

Key findings include:

  • 80% reduction in time to monitor, assess and govern cloud application portfolio risks.
  • 75% elimination of threats automatically due to increased visibility and automated threat protection.
  • 40% reduction in the likelihood of a data breach with the potential savings of more than $1.6 million over three years.
  • 90% reduction in the hours required to audit cloud apps.

When customers deploy Cloud App Security in their environment(s), they are frequently surprised at how many apps it uncovers. For almost any use case, employees can often quickly begin using an app without support from IT. This can result in hundreds or even thousands of unmanaged apps—what we refer to as Shadow IT. Although employees mean well, they don’t always understand the security and compliance risks associated with sharing and storing data in cloud apps. One of the organizations interviewed used MCAS to discover 9,000 apps being used by employees—1,600 of which did not meet the company’s security standards and were immediately shut down.

A pull quote.

Another customer in the study noted the compliance benefits were critical as the health care organization moved sensitive information off-premises to the cloud. “We’ve been somewhat slow to move to the cloud because of protected health information and Health Insurance Portability and Accountability Act (HIPAA) regulations,” said the CIO interviewed. In researching cloud application security brokers, this leader realized the ability to get good governance, compliance and audit support was key as the organization moved to the cloud.

From using AI to crunch massive data sets, to analyzing threats in a fraction of a second, given the global scale of the pandemic, integrated security and diversity of data are two key advantages organizations reap as a result of leveraging the cloud. These are also two advantages among the five significant longer-term cybersecurity paradigm shifts, including digital empathy, zero trust, and cyber resilience strategies, that we anticipate as a result of organizations needing to respond quickly to the challenges of the pandemic.

Our Microsoft Cloud App Security Journey

At Microsoft, we’ve been on a journey with our customers gathering feedback and enhancing Microsoft Cloud App Security to meet their needs. The software has matured significantly, with new capabilities released every two weeks such as integrations with our 1st party security and compliance products as well as many 3rd party vendors that continue to represent a large portion of the market.  These product improvements have led to the benefits and value described in this independent study with MCAS customers, and these benefits also ring true for Microsoft’s own Security Operations Center.

In an organization as large as ours with 156,000 worldwide employees, 160+ physical data centers in 60 countries and countless endpoints to monitor, it’s a significant task to track all the cloud services that our employees use. When the company team first deployed Cloud App Security in 2017, it created visibility they didn’t have before across all the non-Microsoft apps used. Once discovered, the team leveraged more than 80 risk factors built into Cloud App Security to evaluate them for compliance with corporate policies. If an app doesn’t meet the company standards, the team can block it from the network. Conversely, the team also uses Cloud App Security to sanction approved apps and if an app is really popular, onboard it onto Azure Active Directory (Azure AD) for single sign-on (SSO), further improving security for employees. Being able to weed out vulnerable apps and apply Azure AD security controls to non-Microsoft apps gives a lot more control over the app portfolio.

The Microsoft SOC receives tens of thousands of security signals a day. With integrated user and entity behavioral analytics (UEBA) and machine learning (ML) algorithms in MCAS our team can weed out false positives, detect behavioral anomalies across all our cloud apps and better respond to threats. This helps us uncover ransomware, compromised users, or rogue applications. This past June we released new documentation to help customers get familiar with our UEBA alerts.

Microsoft’s SOC team echoed the report’s findings on the usefulness of Cloud App Security in investigation and remediation.  Allowing SOC analysts to see the data that is truly necessary helps them to ask the right kinds of questions, pivot with agility in pursuit of data that sparks curiosity and leads to better response patterns.

They also pointed out that Cloud App Security’s ability to assist in further refining the detections that already exist, emailing or texting analysts in custom policy designs and leveraging the powerful API integrations, including SIEM integrations, all led to better response and deeper, more correlated incidents across multiple data sets.  The ability to customize queries remove alerts on “normal behavior” allows teams to zero in on abnormalities and even create a detection rule.

The remediation tools natively available in Cloud App Security which allow immediate revoking of user tokens (therefore prompting an immediate request to re-sign in) drastically simplifies the time to respond and the ability to increase agility when answering an attack.  One of the most challenging things in this environment is how much the speed of attack has increased in recent years.  With Cloud App Security, the team is better postured to identify a compromised user account, enforce revocation of user tokens to mitigate the threat, as well as analyze the touchpoints along the way that provides a deeper understanding of the “BDA” or – before, during, and after – phases of the attack. These findings can ultimately lead to stronger preventative (and detective) controls that address the root cause of the attack.

In a post-pandemic world where our cybersecurity priorities have forever shifted, all companies big and small must think differently about how to keep their data and people safe. By applying digital empathy to their approach, trusting nothing and no one in their Zero Trust journey, and leveraging the power of the cloud and threat intelligence from their tools and people, we all will be stronger and safer no matter what global event, security risks or cyberattacks come next.

Learn more

Read Forrester’s Total Economic Impact ™ of Microsoft Cloud App Security for details on how Cloud App Security can save time and money.

Find out how Cloud App Security can help you manage and secure your cloud environment.

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 New study shows customers save time, resources and improve security with Microsoft Cloud App Security appeared first on Microsoft Security.

Afternoon Cyber Tea: Cybersecurity & IoT: New risks and how to minimize them

July 2nd, 2020 No comments

Recently, Microsoft announced our acquisition of CyberX, a comprehensive network-based security platform with continuous threat monitoring and analytics. This solution builds upon our commitment to provide a unified IoT security solution that addresses connected devices spread across both industrial and IT environments and provides a trusted, easy-to-use platform for our customers and partners to build connected solutions – no matter where they are starting in their IoT journey.

Every year billions of new connected devices come online. These devices enable businesses to finetune operations, optimize processes, and develop analytics-based services. Organizations are clearly benefiting from IoT as shared in the IoT Signals research report produced by Microsoft. But while the benefit is great, we must not ignore the potential security risks. To talk about how companies can reduce their risk from connected devices, Dr. Andrea Little Limbago joined me on Cyber Tea with Ann Johnson.

Dr. Andrea Little Limbago is a cybersecurity researcher, quant analyst, and computational social scientist at Virtru. With a background in social science, Andera has a unique perspective that I think you’ll find interesting.

Andrea and I talked about the role of automation in attacks and defense and how privacy and security advocates can come together to accomplish their overlapping goals. We also talked about how to safeguard your organization when you can’t inventory all your IoT devices.

It isn’t just businesses that are investing in connected devices. If you have IoT devices in your home, Andrea offered some great advice for protecting your privacy and your data. Listen to Cybersecurity and IoT: New Risks and How to Minimize Them to hear our conversation.

Lack of visibility into the devices currently connected to the network is a widespread problem. Many organizations also struggle to manage security on existing devices. The acquisition of CyberX complements existing Azure IoT security capabilities. I’m excited because this helps our customers discover their existing IoT assets, and both manage and improve the security posture of those devices. Expect more innovative solutions as we continue to integrate CyberX into Microsoft’s IoT security portfolio.

What’s next

In this important cyber series, I talk with cybersecurity influencers about trends shaping the threat landscape and explore the risk and promise of systems powered by AI, Internet of Things (IoT), and other emerging tech.

You can listen to Afternoon Cyber Tea with Ann Johnson on:

§  Apple Podcasts—You can also download the episode by clicking the Episode Website link.

§  Podcast One—Includes option to subscribe, so you’re notified as soon as new episodes are available.

§  CISO Spotlight page—Listen alongside our CISO Spotlight episodes, where customers and security experts discuss similar topics such as Zero Trust, compliance, going passwordless, and more.

If you are interested in how businesses across the globe are benefiting from IoT, read IoT Signals, a research report produced by Microsoft.

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. Or reach out to me on LinkedIn or Twitter if you have guest or topic suggestions.

The post Afternoon Cyber Tea: Cybersecurity & IoT: New risks and how to minimize them appeared first on Microsoft Security.

Best security, compliance, and privacy practices for the rapid deployment of publicly facing Microsoft Power Apps intake forms

June 29th, 2020 No comments

With the dawn of the COVID-19 pandemic, state and federal agencies around the globe were looking at ways to modernize data intake for social services recipients. The government of a country of about 40 million citizens reached out to Microsoft and asked us to assist in this endeavor. Going paperless eliminates waiting in line at an agency office, and lowers the chance of COVID-19 transmission. The ability to make requests or apply for federal or local assistance online makes the process safer and more efficient, as once data is collected citizens should start receiving funds more accurately and quickly.

Security is a major concern of not only major governments but of other entities using Microsoft Power App intake forms. Organizations and agencies needed to be certain that Microsoft Power App intake forms could not be used to collect data from large, sensitive databases containing personal information like names, addresses, Social Security or national security identification numbers, telephone numbers, or bank account information for direct deposit. If internet-facing forms collect personal information, and are not securely implemented, bad actors can use those forms to cleverly gain access to millions—if not billions—of personal records.

We authored this white paper specifically for those agencies and organizations who are transforming data intake to partially or 100-percent paperless. Microsoft wants to ensure that customers are implementing our technologies with the most secure approach possible, and adhering to compliance with all data privacy laws. Microsoft is also making recommendations in the white paper regarding the best way to implement the NIST Cybersecurity Framework in order to identify, protect, detect, respond, and recover from cybersecurity attacks.

For more information on Microsoft Security Solutions, visit our website. 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 Best security, compliance, and privacy practices for the rapid deployment of publicly facing Microsoft Power Apps intake forms appeared first on Microsoft Security.

Lessons learned from the Microsoft SOC—Part 3d: Zen and the art of threat hunting

June 25th, 2020 No comments

An image of a black male developer at work in an Enterprise office workspace.

Threat hunting is a powerful way for the SOC to reduce organizational risk, but it’s commonly portrayed and seen as a complex and mysterious art form for deep experts only, which can be counterproductive. In this and the next blog we will shed light on this important function and recommend simple ways to get immediate and meaningful value out of threat hunting.

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

Before we dive in, let’s clarify the definition of “threat hunting.”  There are various disciplines and processes that contribute to the successful proactive discovery of threat actor operations. For example, our Hunting Team works with threat intelligence to help shape and guide their efforts, but our threat intelligence teams are not “threat hunters.”  When we use the term “threat hunting,” we are talking about the process of experienced analysts proactively and iteratively searching through the environment to find attacker operations that have evaded other detections.

Hunting is a complement to reactive processes, alerts, and detections, and enables you to proactively get ahead of attackers. What sets hunting apart from reactive activities is the proactive nature of it, where hunters spend extended focus time thinking through issues, identifying trends and patterns, and getting a bigger picture perspective.

A successful hunting program is not purely proactive however as it requires continuously balancing attention between reactive efforts and proactive efforts. Threat hunters will still need to maintain a connection to the reactive side to keep their skills sharp and fresh and keep attuned to trends in the alert queue. They will also need to jump in to help with major incidents at a moment’s notice to help put out the fire. The amount of time available for proactive activities will depend heavily on whether or not you have a full-time or part-time hunting mission.

Our SOC approaches threat hunting by applying our analysts to different types of threat hunting tasks:

1. Proactive adversary research and threat hunting

This is what most of our threat hunters spend the majority of their time doing. The team searches through a variety of sources including alerts, external indicators of compromise and other sources. The team primarily works to build and refine structured hypotheses of what the attackers may do based on threat intelligence (TI), unusual observations in the environment, and their own experience. In practice, this type of threat hunting includes:

  • Proactive search through the data (queries or manual review).
  • Proactive development of hypotheses based on TI and other sources.

2. Red and purple teaming

Some of our threat hunters work with red teams who simulate attacks and others who conduct authorized penetration testing against our environment. This is a rotating duty for our threat hunters and typically involves purple teaming, where both red and blue teams work to do their jobs and learn from each other. Each activity is followed up by fully transparent reviews that capture lessons learned which are shared throughout the SOC, with product engineering teams, and with other security teams in the company.

3. Incidents and escalations

Proactive hunters aren’t sequestered somewhere away from the watch floor. They are co-located with reactive analysts; they frequently check in with each other, share what they are working on, share interesting findings/observations, and generally maintain situational awareness of current operations. Threat hunters aren’t necessarily assigned to this task full time; they may simply remain flexible and jump in to help when needed.

These are not isolated functions— the members of these teams work in the same facility and frequently check in with each other, share what they are working on, and share interesting findings/observations.

What makes a good threat hunter?

While any high performing analyst has good technical skills, a threat hunter must be able to see past technical data and tools to attackers’ actions, motivations, and ideas. They need to have a “fingertip feel” (sometimes referred to as Fingerspitzengefühl), which is a natural sense of what is normal and abnormal in security data and the environment. Threat hunters can recognize when an alert (or cluster of alerts/logs) seem different or out of place.

One way to think about the qualities that make up a good threat hunter is to look at the Three F’s.

Functionality

This is technical knowledge and competency of investigating and remediating incidents. Security analysts (including threat hunters) should be proficient with the security tools, general flow of investigation and remediation, and the types technologies commonly deployed in enterprise environments.

Familiarity

This is “know thyself” and “know thy enemy” and includes familiarity with your organization’s specific environment and familiarity with attacker tactics, techniques, and procedures (TTPs). Attacker familiarity starts with understanding common adversary behaviors and then grows into a deeper sense of specific adversaries (including technologies, processes, playbooks, business priorities and mission, industry, and typical threat patterns). Familiarity also includes the relationships threat hunters develop with the people in your organization, and their roles/responsibilities. Familiarity with your organization is highly valued for analysts on investigation teams, and critical for effective threat hunting.

Flexibility

Flexibility is a highly valued attribute of any analyst role, but it is absolutely required for a threat hunter. Flexibility is a mindset of being adaptable in what you may do every day and how you do it. This manifests in how you understand problems, process information, and pursue solutions. This mindset comes from within each person and is reflected in almost everything they do.

Where any threat analyst (or threat hunter) can take a particular alert or event and run it into the ground, a good threat hunter will take a step back and look at a collection of data, alerts or events. Threat hunters must be inquisitive and unrelentingly curious about things—to the point that it bugs them if they don’t have a clear understanding of something. Instead of just answering a question, threat hunters are constantly trying to ask better questions of the data, coming up with creative new angles to answer them, and seeing what new questions they raise. Threat hunting also requires humility, to be able to quickly admit your mistakes so you can rapidly re-enter learning mode.

Threat hunting tooling

Threat hunting naturally pulls in a wide variety of tools, but our team has grown to prefer a few of the Microsoft tools whose design they have influenced.

  • Advanced hunting in Microsoft Threat Protection (MTP) tends to be the go-to tool for anything related to endpoints, identities, email, Azure resources, and SaaS applications.
  • Our teams also use Azure Sentinel, Jupyter notebooks, and custom analytics to hunt across broad datasets like application and network data, as well as diving deeper into identity, endpoint, Office 365, and other log data.

Our threat hunting teams across Microsoft contribute queries, playbooks, workbooks, and notebooks to the Azure Sentinel Community, including specific hunting queries that your teams can adapt and use.

Conclusion

We have discussed the art of threat hunting, different approaches to it, and what makes a good threat hunter. In the next entry, we dive deeper into how to build and refine a threat hunting program. If you are looking for more information on the SOC and other cybersecurity topics, check out previous entries in the series (Part 1 | Part 2a | Part 2b | Part 3a | Part 3b| Part 3c), Mark’s List, and our new security documentation site. Be sure to bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Lessons learned from the Microsoft SOC—Part 3d: Zen and the art of threat hunting appeared first on Microsoft Security.

Defending Exchange servers under attack

June 24th, 2020 No comments

Securing Exchange servers is one of the most important things defenders can do to limit organizational exposure to attacks. Any threat or vulnerability impacting Exchange servers should be treated with the highest priority because these servers contain critical business data, as well as highly privileged accounts that attackers attempt to compromise to gain admin rights to the server and, consequently, complete control of the network.

If compromised, Exchange servers provide a unique environment that could allow attackers to perform various tasks using the same built-in tools or scripts that admins use for maintenance. This is exacerbated by the fact that Exchange servers have traditionally lacked antivirus solutions, network protection, the latest security updates, and proper security configuration, often intentionally, due to the misguided notion that these protections interfere with normal Exchange functions. Attackers know this, and they leverage this knowledge to gain a stable foothold on a target organization.

There are two primary ways in which Exchange servers are compromised. The first and more common scenario is attackers launching social engineering or drive-by download attacks targeting endpoints, where they steal credentials and move laterally to other endpoints in a progressive dump-escalate-move method until they gain access to an Exchange server.

The second scenario is where attackers exploit a remote code execution vulnerability affecting the underlying Internet Information Service (IIS) component of a target Exchange server. This is an attacker’s dream: directly landing on a server and, if the server has misconfigured access levels, gain system privileges.

The first scenario is more common, but we’re seeing a rise in attacks of the second variety; specifically, attacks that exploit Exchange vulnerabilities like CVE-2020-0688. The security update that fixes this vulnerability has been available for several months, but, notably, to this day, attackers find vulnerable servers to target.

In many cases, after attackers gain access to an Exchange server, what follows is the deployment of web shell into one of the many web accessible paths on the server. As we discussed in a previous blog, web shells allow attackers to steal data or perform malicious actions for further compromise.

Behavior-based detection and blocking of malicious activities on Exchange servers

Adversaries like using web shells, which are relatively small pieces of malicious code written in common programming languages, because these can be easily modified to evade traditional file-based protections. A more durable approach to detecting web shell activity involves profiling process activities originating from external-facing Exchange applications.

Behavior-based blocking and containment capabilities in Microsoft Defender ATP, which use engines that specialize in detecting threats by analyzing behavior, surface suspicious and malicious activities on Exchange servers. These detection engines are powered by cloud-based machine learning classifiers that are trained by expert-driven profiling of legitimate vs. suspicious activities in Exchange servers.

In April, multiple Exchange-specific behavior-based detections picked up unusual activity. The telemetry showed attackers operating on on-premises Exchange servers using deployed web shells. Whenever attackers interacted with the web shell, the hijacked application pool ran the command on behalf of the attacker, generating an interesting process chain. Common services, for example Outlook on the web  (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the  Exchange Control Panel or ECP), executing net.exe, cmd.exe, and other known living-off-the-land binaries (LOLBins) like mshta.exe is very suspicious and should be further investigated.

Figure 1. Behavior-based detections of attacker activity on Exchange servers

In this blog, we’ll share our investigation of the Exchange attacks in early April, covering multiple campaigns occurring at the same time. The data and techniques from this analysis make up an anatomy of Exchange server attacks. Notably, the attacks used multiple fileless techniques, adding another layer of complexity to detecting and resolving these threats, and demonstrating how behavior-based detections are key to protecting organizations.

Figure 2. Anatomy of an Exchange server attack

Initial access: Web shell deployment

Attackers started interacting with target Exchange servers through web shells they had deployed. Any path accessible over the internet is a potential target for web shell deployment, but in these attacks, the most common client access paths were:

  • %ProgramFiles%\Microsoft\Exchange Server\<version>\ClientAccess
  • %ProgramFiles%\Microsoft\Exchange Server\<version>\FrontEnd

The ClientAccess and FrontEnd directories provide various client access services such as Outlook on the web, EAC, and AutoDiscover, to name a few. These IIS virtual directories are automatically configured during server installation and provide authentication and proxy services for internal and external client connections.

These directories should be monitored for any new file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process results in more reliable signals. Common services like OWA or ECP dropping .aspx or .ashx files in any of the said directories is highly suspicious.

In our investigation, most of these attacks used the China Chopper web shell. The attackers tried to blend the web shell script file with other .aspx files present on the system by using common file names. In many cases, hijacked servers used the ‘echo’ command to write the web shell. In other cases, certutil.exe or powershell.exe were used. Here are some examples of the China Chopper codes that were dropped in these attacks:

We also observed the attackers switching web shells or introducing two or more for various purposes. In one case, the attackers created an .ashx version of a popular, publicly available .aspx web shell, which exposes minimum functionality:

Figure 3. Microsoft Defender ATP alert for web shell

Reconnaissance

After web shell deployment, attackers typically ran an initial set of exploratory commands like whoami, ping, and net user. In most cases, the hijacked application pool services were running with system privileges, giving attackers the highest privilege.

Attackers enumerated all local groups and members on the domain to identify targets. Interestingly, in some campaigns, attackers used open-source user group enumerating tools like lg.exe instead of the built-in net.exe. Attackers also used the EternalBlue exploit and nbtstat scanner to identify vulnerable machines on the network.

Next, the attackers ran built-in Exchange Management Shell cmdlets to gain more information about the exchange environment. Attackers used these cmdlets to perform the following:

  • List all Exchange admin center virtual directories in client access services on all Mailbox servers in the network
  • Get a summary list of all the Exchange servers in the network
  • Get information on mailboxes, such as size and number of items, along with role assignments and permissions.

Figure 4. Microsoft Defender ATP alert showing process tree for anomalous account lookups

Persistence

On misconfigured servers where they have gained the highest privileges, attackers were able to add a new user account on the server. This gave the attackers the ability to access the server without the need to deploy any remote access tools.

The attackers then added the newly created account to high-privilege groups like Administrators, Remote Desktop Users, and Enterprise Admins, practically making the attackers a domain admin with unrestricted access to any users or group in the organization.

Figure 5. Microsoft Defender ATP alert showing process tree for addition of local admin using Net commands

Credential access

Exchange servers contain the most sensitive users and groups in an organization. Gaining credentials to these accounts could virtually give attackers domain admin privileges.

In our investigation, the attackers first dumped user hashes by saving the Security Account Manager (SAM) database from the registry.

Next, the attackers used the ProcDump tool to dump the Local Security Authority Subsystem Service (LSASS) memory. The dumps were later archived and uploaded to a remote location.

In some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server.

Figure 6. Microsoft Defender ATP alert on detection of Mimikatz

In environments where Mimiktaz was blocked, attackers dropped a modified version with hardcoded implementation to avoid detection. Attackers also added a wrapper written in the Go programming language to make the binary more than 5 MB. The binary used the open-source MemoryModule library to load the binary using reflective DLL injection. Thus, the payload never touched the disk and was present only in memory, achieving a fileless persistence.

The attackers also enabled ‘wdigest’ registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attacker to steal the actual password, not just the hash.

Another example of stealthy execution that attackers implemented was creating a wrapper binary for ProcDump and Mimikatz. When run, the tool dropped and executed the ProcDump binary to dump the LSASS memory. The memory dump was loaded inside the same binary and parsed to extract passwords, another example of reflective DLL injection where the Mimikatz binary was present only in memory.

With attacker-controlled accounts now part of Domain Admins group, the attackers performed a technique called DCSYNC attack, which abuses the Active Directory replication capability to request account information, such as the NTLM hashes of all the users’ passwords in the organization. This technique is extremely stealthy because it can be performed without running a single command on the actual domain controller.

Lateral movement

In these attacks, the attackers used several known methods to move laterally:

  • The attackers heavily abused WMI for executing tools on remote systems.

  • The attackers also used other techniques such as creating service or schedule task on remote systems.

  • In some cases, the attackers simply run commands on remote systems using PsExec.

Exchange Management Shell abuse

The Exchange Management Shell is the PowerShell interface for administrators to manage the Exchange server. As such, it exposes many critical Exchange PowerShell cmdlets to allow admins to perform various maintenance tasks, such as assigning roles and permissions, and migration, including importing and exporting mailboxes. These cmdlets are available only on Exchange servers in the Exchange Management Shell or through remote PowerShell connections to the Exchange server.

To understand suspicious invocation of the Exchange Management Shell, we need to go one step back in the process chain and analyze the responsible process. As mentioned, common application pools MSExchangeOWAAppPool or MSExchangeECPAppPool accessing the shell should be considered suspicious.

In our investigation, attackers leveraged these admin cmdlets to perform critical tasks such as exporting mailboxes or running arbitrary scripts. Attackers used different ways to load and run PowerShell cmdlets through the Exchange Management Shell.

In certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity.

These cmdlets allowed the attackers to perform the following:

  • Search received email

In our investigations, attackers were primarily interested in received emails. They searched for message delivery information filtered by the event ‘Received’. The search time frame showed the attackers were initially interested in the entire log history. Later, a similar command was run with a trimmed timeline of one year.

  • Export mailbox

Attackers exported mailboxes through these four steps:

    1. Granted ApplicationImpersnation role to the attacker-controlled account. This effectively allowed the supplied account to access all mailboxes in the organization.
    2. Granted ‘Mailbox Import Export’ role to the attacker-controlled account. This role is required to be added before attempting mailbox export.
    3. Exported the mailbox with filter “Received -gt ‘01/01/2020 0:00:00’”.
    4. Removed the mailbox export request to avoid raising suspicion.

Tampering with security tools

As part of lateral movement, the attackers attempted to disable Microsoft Defender Antivirus. Attackers also disabled archive scanning to bypass detection of tools and data compressed in .zip files, as well as created exclusion for .dat extension. The attackers tried to disable automatic updates to avoid any detection by new intelligence updates. For Microsoft Defender ATP customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Remote access

The next step for attackers was to create a network architecture using port forwarding tools like plink.exe, a command line connection tool like ssh. Using these tools allowed attackers to bypass network restrictions and remotely access machines through Remote Desktop Protocol (RDP). This is a very stealthy technique: attackers reused dumped credentials to access the machines through encrypted tunneling software, eliminating the need to deploy backdoors, which may have a high chance of getting detected.

Exfiltration

Finally, dumped data was compressed using the utility tool rar.exe. The compressed data mostly comprised of the extracted .pst files, along with memory dumps.

Improving defenses against Exchange server compromise

As these attacks show, Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive, fileless techniques. For example, at every stage in the attack chain above, the attackers abused existing tools (LOLBins) and scripts to accomplish various tasks. Even in cases where non-system binaries were introduced, they were either legitimate and signed, like plink.exe, or just a proxy for the malicious binary, for example, the modified Mimikatz where the actual malicious payload never touched the disk.

Keeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take to ensure they don’t fall victim to Exchange server compromise.

  1. Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations in Exchange servers. Deploy the latest security updates, especially for server components like Exchange, as soon as they become available. Specifically, check that the patches for CVE-2020-0688 is in place. Use threat and vulnerability management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

  1. Keep antivirus and other protections enabled

It’s critical to protect Exchange servers with antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and WMI. Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT pros to help determine the true impact of these settings. Security teams and IT pros should collaborate on applying mitigations and appropriate settings.

  1. Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

  1. Restrict access

Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and Enable MFA. Use tools like LAPS.

Place access control list (ACL) restrictions on ECP and other virtual directories in IIS. Don’t expose the ECP directory to the web if it isn’t necessary and to anyone in the company who doesn’t need to access it. Apply similar restrictions to other application pools.

  1. Prioritize alerts

Pay attention to and immediately investigate alerts indicating suspicious activities on Exchange servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Common application pools like ‘MSExchangeOWAAppPool’ or ‘MSExchangeECPAppPool’ are commonly hijacked by attackers through web shell deployment. Prioritize alerts related to processes such as net.exe, cmd.exe, and mshta.exe originating from these pools or w3wp.exe in general.

Behavior-based blocking and containment capabilities in Microsoft Defender Advanced Threat Protection stop many of the malicious activities we described in this blog. Behavior-based blocking and containment stops advanced attacks in their tracks by detecting and halting malicious processes and behaviors.

 

 

Figure 7. Microsoft Defender ATP alerts on blocked behaviors

In addition, Microsoft Defender ATP’s endpoint detection and response (EDR) sensors provide visibility into other suspicious and malicious activities on Exchange servers, which are raised as alerts. The new alert page presents data in an investigation-driven approach meant to empower SecOps teams to easily investigate and take actions.

Figure 8. Microsoft Defender ATP alert and process tree

If these alerts are immediately prioritized, security operations teams can better mitigate attacks and prevent further damage. Beyond resolving these alerts in the shortest possible time, however, organizations should focus on investigating the end-to-end attack chain and trace the vulnerability, misconfiguration, or other weakness in the infrastructure that allowed the attack to occur.

Microsoft Defender ATP is a component of the broader Microsoft Threat Protection (MTP), which provides comprehensive visibility into advanced attacks by combining the capabilities of Office 365 ATP, Azure ATP, Microsoft Cloud App Security, and Microsoft Defender ATP. Through the incidents view, MTP provides a consolidated picture of related attack evidence that shows the complete attack story, empowering SecOps teams to thoroughly investigate attacks.

In addition, MTP’s visibility into malicious artifacts and behavior empowers security operations teams to proactively hunt for threats on Exchange servers. For example, MTP can be connected to Azure Sentinel to enable web shell threat hunting.

Through built-in intelligence and automation, Microsoft Threat Protection coordinates protection, detection, and response across endpoints, identity, data, and apps. Learn more.

 

Hardik Suri

Microsoft Defender ATP Research Team

 

MITRE ATT&CK techniques

Initial access

Execution

Persistence

Privilege escalation

Defense evasion

Credential access

Discovery

Lateral movement

Collection

Command and control

Exfiltration

 

The post Defending Exchange servers under attack appeared first on Microsoft Security.

Microsoft continues to extend security for all with mobile protection for Android

June 23rd, 2020 No comments

Just a year ago, we shared our first steps on a journey to enable our customers to protect endpoints running a variety of platforms with our announcement of Microsoft Defender ATP for Mac. Knowing that each of our customers have unique environments and unique needs and are looking for more unification in their security solutions, we communicated our commitment to build security solutions from Microsoft, not just for Microsoft. Since then, we’ve announced capabilities for Linux servers, and at RSA, and we offered you a sneak peek into our mobile threat defense investments.

Today, I’m proud to announce the public preview of Microsoft Defender ATP for Android.

Protecting mobile devices from evolving threats, phishing attacks, unwanted apps

As more business is getting done on mobile devices, the lines blur between work and personal life. The threats here are unique. For example, one of the biggest and fastest growing threats on mobile is phishing attacks, majority of which happen outside of email, such as via phishing sites, messaging apps, games, and other applications, and are tricky to spot on smaller form factors. Other common mobile threats include malicious applications that users are lured into downloading, as well as increased risk introduced by rooted devices that may allow unnecessary escalated privileges and the installation of unauthorized applications.

In this rapidly evolving world of mobile threats, Microsoft is taking a holistic approach to tackling these challenges and to securing enterprises and their data with our new mobile threat defense capabilities. We’re leveraging our unique visibility into the threat landscape and the vast signal, intelligence, and security expertise we have from across domains, such as our expertise in phishing and email, our endpoint threat research on malware and attacker techniques, and our focus on identity and zero trust to bring protection capabilities to mobile. Our integrated approach to security enables us to provide more complete coverage. Leveraging these capabilities, Microsoft Defender ATP for Android will help to protect our customers and their users by delivering:

  • Protection from phishing and access to risky domains and URLs through web protection capabilities that will block unsafe sites accessed through SMS/text, WhatsApp, email, browsers, and other apps. We’re using the same Microsoft Defender SmartScreen services that are on Windows to quickly detect malicious sites which means that a decision to block a suspicious site will apply across all devices in the enterprise.
  • Proactive scanning of malicious applications, files, and potentially unwanted applications (PUA) that users may download to their mobile devices. Our capabilities and investments in cloud-powered protection and intelligence on application reputation allow us to quickly detect sophisticated malware and apps that that may display undesirable behavior.
  • Adding layers of protection to help prevent and limit the impact of breaches in an organization. By leveraging tight integration with Microsoft Endpoint Manager and Conditional Access, mobile devices that have been compromised with malicious apps or malware are considered high risk and are blocked from accessing corporate resources.
  • A unified security experience through Microsoft Defender Security Center where defenders can see alerts and easily get the additional context they need to quickly assess and respond to threats across Windows, Mac, Linux, and now mobile devices.

There’s more to share on how these capabilities work and how to get started on the blog in the Microsoft Defender ATP tech community.

In the coming months we will be releasing additional capabilities on Android and you will hear more from us about our investments in mobile threat defense for iOS devices as well.

I’m also thrilled to share that our initial release of Microsoft Defender ATP for Linux is now generally available. Customers have asked us to broaden our selection of platforms natively supported by Microsoft Defender ATP, and today we’re excited to officially start our journey with Linux. This release marks an important moment for all Microsoft Defender ATP customers when Microsoft Defender ATP becomes a truly unified solution to secure the full spectrum of desktop and server platforms that are common across enterprise environments: Windows, macOS, and Linux.

We are committed to helping organizations secure their unique and heterogenous environments and we have so much more in store for you this year. We’re excited for you to join us in our journey as we continue to deliver the industry’s best in integrated threat protection solutions.

For more information on Microsoft Security Solutions, visit our website. 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.

 

-Rob

The post Microsoft continues to extend security for all with mobile protection for Android appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Mapping attack chains from cloud to endpoint

June 18th, 2020 No comments

The increasing pervasiveness of cloud services in today’s work environments, accelerated by a crisis that forced companies around the globe to shift to remote work, is significantly changing how defenders must monitor and protect organizations. Corporate data is spread across multiple applications—on-premises and in the cloud—and accessed by users from anywhere using any device. With traditional surfaces expanding and network perimeters disappearing, novel attack scenarios and techniques are introduced.

Every day, we see attackers mount an offensive against target organizations through the cloud and various other attack vectors with the goal of finding the path of least resistance, quickly expanding foothold, and gaining control of valuable information and assets. To help organizations fend off these advanced attacks, Microsoft Threat Protection (MTP) leverages the Microsoft 365 security portfolio to automatically analyze cross-domain threat data, building a complete picture of each attack in a single dashboard. With this breadth and depth of clarity, defenders can focus on critical threats and hunting for sophisticated breaches across endpoints, email, identities and applications.

Among the wide range of actors that Microsoft tracks—from digital crime groups to nation-state activity groups—HOLMIUM is one of the most proficient in using cloud-based attack vectors. Attributed to a Middle East-based group and active since at least 2015, HOLMIUM has been performing espionage and destructive attacks targeting aerospace, defense, chemical, mining, and petrochemical-mining industries. HOLMIUM’s activities and techniques overlap with what other researchers and vendors refer to as APT33, StoneDrill, and Elfin.

HOLMIUM has been observed using various vectors for initial access, including spear-phishing email, sometimes carrying archive attachments that exploit the CVE-2018-20250 vulnerability in WinRAR, and password-spraying. Many of their recent attacks, however, have involved the penetration testing tool Ruler used in tandem with compromised Exchange credentials.

The group used Ruler to configure a specially crafted Outlook Home Page URL to exploit the security bypass vulnerability CVE-2017-11774, which was fixed shortly after it was discovered. Successful exploitation automatically triggered remote code execution of a script when an Outlook client synced with a mailbox and rendered the profile Home Page URL. These scripts, usually VBScript followed by PowerShell, in turn initiated the delivery of various payloads.

In this blog, the first in the Inside Microsoft Threat Protection series, we will show how MTP provides unparalleled end-to-end visibility into the activities of nation-state level attacks like HOLMIUM. In succeeding blog posts in this series, we will shine a spotlight on aspects of the coordinated defense delivered by Microsoft Threat Protection.

Tracing an end-to-end cloud-based HOLMIUM attack

HOLMIUM has likely been running cloud-based attacks with Ruler since 2018, but a notable wave of such attacks was observed in the first half of 2019. These attacks combined the outcome of continuous password spray activities against multiple organizations, followed by successful compromise of Office 365 accounts and the use of Ruler in short sequences to gain control of endpoints. This wave of attacks was the subject of a warning from US Cybercom in July 2019.

These HOLMIUM attacks typically started with intensive password spray against exposed Active Directory Federation Services (ADFS) infrastructure; organizations that were not using multi-factor authentication (MFA) for Office 365 accounts had a higher risk of having accounts compromised through password spray. After successfully identifying a few user and password combinations via password spray, HOLMIUM used virtual private network (VPN) services with IP addresses associated with multiple countries to validate that the compromised accounts also had access to Office 365.

Figure 1. Password spray and compromised account sign-ins by HOLMIUM as detected in Azure Advanced Threat Protection (ATP) and Microsoft Cloud App Security (MCAS)

Armed with a few compromised Office 365 accounts and not blocked by MFA defense, the group launched the next step with Ruler and configured a malicious Home Page URL which, once rendered during a normal email session, resulted in the remote code execution of a PowerShell backdoor through the exploitation of a vulnerability like CVE-2017-11774. The two domains abused by HOLMIUM and observed during this 2019 campaign were “topaudiobook.net” and “customermgmt.net”.

Figure 2. Exploitation of Outlook Home Page feature using Ruler-like tools

Figure 3. Weaponized home page and initial PowerShell payload

This initial foothold allowed HOLMIUM to run their custom PowerShell backdoor (known as POWERTON) directly from an Outlook process and to perform the installation of additional payloads on the endpoint with different persistence mechanisms, such as WMI subscription (T1084) or registry autorun keys (T1060). Once the group has taken control of the endpoint (in addition to the cloud identity), the next phase was hours of exploration of the victim’s network, enumerating user accounts and machines for additional compromise, and lateral movement within the perimeter. HOLMIUM attacks typically took less than a week from initial access via the cloud to obtaining unhampered access and full domain compromise, which then allowed the attackers to stay persistent for long periods of time, sometimes for months on end.

Figure 4. Snippets of HOLMIUM PowerShell backdoor (POWERTON) implementing two different persistence mechanisms: WMI event subscription (T1084) and Registry run keys or Startup folder (T1060)

HOLMIUM attacks as seen and acted upon by Microsoft Threat Protection

HOLMIUM attacks demonstrate how hybrid attacks that span from cloud to endpoints require a wide range of sensors for comprehensive visibility. Enabling organizations to detect attacks like these by correlating events in multiple domains – cloud, identity, endpoints – is the reason why we build products like Microsoft Threat Protection. As we described in our analysis of HOLMIUM attacks, the group compromised identities in the cloud and leveraged cloud APIs to gain code execution or persist. The attackers then used a cloud email configuration to run specially crafted PowerShell on endpoints every time the Outlook process is opened.

During these attacks, many target organizations reacted too late in the attack chain—when the malicious activities started manifesting on endpoints via the PowerShell commands and subsequent lateral movement behavior. The earlier attack stages like cloud events and password spray activities were oftentimes missed or sometimes not linked with activities observed on the endpoint. This resulted in gaps in visibility and, subsequently, incomplete remediation.

While it’s relatively easy to remediate and stop malicious processes and downloaded malware on endpoints using endpoint security solutions, such a conventional approach would mean that the attack is persistent in the cloud, so the endpoint could be immediately compromised again. Remediating identities in the cloud is a different story.

Figure 5. The typical timeline of a HOLMIUM attack kill-chain

In an organization utilizing MTP, multiple expert systems that monitor various aspects of the network would detect and raise alerts on HOLMIUM’s activities. MTP sees the full attack chain across domains beyond simply blocking on endpoints or zapping emails, thus putting organizations in a superior position to fight the threat.

Figure 6. MTP components able to prevent or detect HOLMIUM techniques across the kill chain.

These systems work in unison to prevent attacks or detect, block, and remediate malicious activities. Across affected domains, MTP detects signs of HOLMIUM’s attacks:

  • Azure ATP identifies account enumeration and brute force attacks
  • MCAS detects anomalous Office 365 sign-ins that use potentially compromised credentials or from suspicious locations or networks
  • Microsoft Defender ATP exposes malicious PowerShell executions on endpoints triggered from Outlook Home Page exploitation

Figure 7. Activities detected across affected domains by different MTP expert systems

Traditionally, these detections would each be surfaced in its own portal, alerting on pieces of the attack but requiring the security team to stitch together the full picture. With Microsoft Threat Protection, the pieces of the puzzle are fused automatically through deep threat investigation. MTP generates a combined incident view that shows the end-to-end attack, with all related evidence and affected assets in one view.

Figure 8. The MTP incident brings together in one view the entire end-to-end attack across domain boundaries

Understanding the full attack chain enables MTP to automatically intervene to block the attack and remediate assets holistically across domains. In HOLMIUM attacks, MTP not only stops the PowerShell activity on endpoints but also contains the impact of stolen user accounts by marking them as compromised in Azure AD. This invokes Conditional Access as configured in Azure AD and applies conditions like MFA or limitations on the user account’s permissions to access organizational resources until the account is remediated fully.

Figure 9. Coordinated automatic containment and remediation across email, identity, and endpoints

Security teams can dig deep and expand their investigation into the incident in Microsoft 365 Security Center, where all details and related activities are available in one place. Furthermore, security teams can hunt for more malicious activities and artifacts through advanced hunting, which brings together all the raw data collected across product domains into one unified schema with powerful query constructs.

Figure 10. Hunting for activities across email, identity, endpoint and cloud applications

Finally, when the attack is blocked and all affected assets are remediated, MTP helps organizations identify improvements to their security configuration that would prevent the attacker from returning. The Threat Analytics report provides an exposure view and recommends prevention measures relevant to the threat. For example, the Analytics Report for HOLMIUM recommended, among other things, applying the appropriate security updates to prevent tools like Ruler from operating, as well as completely eliminating this attack vector in the organization.

Figure 11. Threat Analytics provides organizational exposure and recommended mitigations for HOLMIUM 

Microsoft Threat Protection: Stop attacks with automated cross-domain security

HOLMIUM exemplifies the sophistication of today’s cyberattacks, which leverage techniques spanning organizational cloud services and on-prem devices. Organizations must equip themselves with security tools that enable them to see the attack sprawl and respond to these attacks holistically and automatically. Protecting organizations from sophisticated attacks like HOLMIUM is the backbone of MTP.

Microsoft Threat Protection harnesses the power of Microsoft 365 security products and brings them together into an unparalleled coordinated defense that detects, correlates, blocks, remediates, and prevents such attacks across an organization’s Microsoft 365 environment. Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost. Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense.

 

The post Inside Microsoft Threat Protection: Mapping attack chains from cloud to endpoint appeared first on Microsoft Security.

Moving to cloud-based SIEM: the cost advantage

June 17th, 2020 No comments

Companies weigh multiple factors in any technology implementation, balancing risks with business needs and IT capabilities. And while the same is true with cloud-based security information and event management (SIEM) solutions, cost overwhelmingly shapes the discussion as well.

For example, according to new IDG research among 300 IT and security leaders, the top outcomes respondents expect by switching to cloud-based SIEM include:

  • Forty percent—lower staffing costs.
  • Forty percent—lower operational expenses (OpEx).
  • Thirty-four percent—lower capital expenses (CapEx).

“If you look at it on the surface, the cloud is more expensive than on-premises. But you have to factor in the soft costs…” said one technology services CIO. In fact, for this CIO and his company, it no longer made sense to continue running traditional on-premises SIEM in his datacenter.

“It was very hard to continue to expand,” he explained. “It wasn’t super cost effective. It was pushing our bandwidth. Managing it internally required skillsets that I wouldn’t need with a cloud-based implementation.”

This blog will summarize some of the key findings in a new IDG report published by Microsoft Azure. You can learn about additional challenges to security operations teams by reading the IDG report: SIEM Shift: How the Cloud is Transforming Security Operations.

Unmasking cost factors

All those soft costs add up. IDG found that cloud-based SIEM users spend, on average, $541,000 per year to support their solution, while on-premises companies are averaging $607,000.

Traditional on-premises SIEM users reported higher costs across the board—including for licensing, maintenance, software, and staffing expenditures. They were also more likely to cite hidden costs associated with supporting their on-premises solutions, including:

  • Staffing/training SIEM analysts.
  • Initial purchase/licensing costs.
  • Integration of data sources.

On the other hand, respondents using cloud-based SIEM solutions are focused on finding further efficiencies. For example, they’re automating operations at nearly double the rate of on-premises users. They’ve discovered that by shifting these tasks to an automated cloud solution, personnel can focus on more strategic initiatives.

Following a transition to cloud-based SIEM, “Nobody lost their job,” said one senior solutions architect for a telecom company. In fact, those workers who originally supported the on-premises solution were retrained and moved into DevOps, he said.

The bottom line

On-premises SIEM users are 11 percent more likely than cloud-based implementers to cite total cost of ownership as an existing challenge, according to IDG. As data volumes continue to grow, managing total cost of ownership (TCO) for traditional SIEM can become unwieldy. Infrastructure expenses will increase, right along with the staffing needs to support the solution.

“When you look at total cost of ownership, the cloud SIEM model becomes very attractive,” said Bob Bragdon, Senior Vice President and Publisher, CSO. “Particularly in terms of not having to build out and maintain a supporting infrastructure. When you can push that to the cloud and move from a CapEx model to an OpEx model, the financial dynamics shift considerably.”

Learn about other areas where on-premises and cloud-based SIEM like Azure Sentinel measure up by reading the IDG report: SIEM Shift: How the Cloud is Transforming Security Operations.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on Twitter: @MSFTSecurity for the latest news and updates on cybersecurity.

The post Moving to cloud-based SIEM: the cost advantage appeared first on Microsoft Security.

UEFI scanner brings Microsoft Defender ATP protection to a new level

June 17th, 2020 No comments

Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) is extending its protection capabilities to the firmware level with a new Unified Extensible Firmware Interface (UEFI) scanner.

Hardware and firmware-level attacks have continued to rise in recent years, as modern security solutions made persistence and detection evasion on the operating system more difficult. Attackers compromise the boot flow to achieve low-level malware behavior that’s hard to detect, posing a significant risk to an organization’s security posture.

Windows Defender System Guard helps defend against firmware attacks by providing guarantees for secure boot through hardware-backed security features like hypervisor-level attestation and Secure Launch, also known as Dynamic Root of Trust (DRTM), which are enabled by default in Secured-core PCs. The new UEFI scan engine in Microsoft Defender ATP expands on these protections by making firmware scanning broadly available.

The UEFI scanner is a new component of the built-in antivirus solution on Windows 10 and gives Microsoft Defender ATP the unique ability to scan inside of the firmware filesystem and perform security assessment. It integrates insights from our partner chipset manufacturers and further expands the comprehensive endpoint protection provided by Microsoft Defender ATP.

How the UEFI scanner in Microsoft Defender ATP works

The new UEFI scanner reads the firmware file system at runtime by interacting with the motherboard chipset. To detect threats, it performs dynamic analysis using multiple new solution components that include:

  • UEFI anti-rootkit, which reaches the firmware through Serial Peripheral Interface (SPI)
  • Full filesystem scanner, which analyzes content inside the firmware
  • Detection engine, which identifies exploits and malicious behaviors

Firmware scanning is orchestrated by runtime events like suspicious driver load and through periodic system scans. Detections are reported in Windows Security, under Protection history.

Screenshot of Windows Security notification showing detection of malicious content in non-volatile memory (NVRAM)

Figure 1. Windows Security notification showing detection of malicious content in non-volatile memory (NVRAM)

Microsoft Defender ATP customers will also see these detections raised as alerts in Microsoft Defender Security Center, empowering security operations teams to investigate and respond to firmware attacks and suspicious activities at the firmware level in their environments.

Screenshot of Microsoft Defender ATP alert for detection of malicious code in firmware

Figure 2. Microsoft Defender ATP alert for detection of malicious code in firmware

Security operations teams can also use the advanced hunting capabilities in Microsoft Defender ATP to hunt for these threats:

DeviceEvents
| where ActionType == "AntivirusDetection"
| extend ParsedFields=parse_json(AdditionalFields)
| extend ThreatName=tostring(ParsedFields.ThreatName)
| where ThreatName contains_cs "UEFI"
| project ThreatName=tostring(ParsedFields.ThreatName),
 FileName, SHA1, DeviceName, Timestamp
| limit 100

To detect unknown threats in SPI flash, signals from the UEFI scanner are analyzed to identify anomalies and where they have been executed. Anomalies are reported to the Microsoft Defender Security Center for investigation.

Screenshot of Microsoft Defender ATP alert for possible malware implant in UEFI file system

Figure 3. Microsoft Defender ATP alert for possible malware implant in UEFI file system

These events can likewise be queried through advanced hunting:

DeviceAlertEvents
| where Title has "UEFI"
| summarize Titles=makeset(Title) by DeviceName, DeviceId, bin(Timestamp, 1d)
| limit 100

How we built the UEFI scanner

The Unified Extensible Firmware Interface (UEFI) is a replacement for legacy BIOS. If the chipset is configured correctly (UEFI & chipset configuration itself) and secure boot is enabled, the firmware is reasonably secure. To perform a hardware-based attack, attackers exploit a vulnerable firmware or a misconfigured machine to deploy a rootkit, which allows attackers to gain foothold on the machine.

Figure 4. Expected boot flow vs. compromised boot flow

As figure 4 shows, for devices that are configured correctly, the boot path from power-on to OS initialization is reliable. If secure boot is disabled or if the motherboard chipset is misconfigured, attackers can change the contents of UEFI drivers that are unsigned or tampered with in the firmware. This could allow attackers to take over control of devices and give them the capability to deprivilege the operating system kernel or antivirus to reconfigure the security of the firmware.

Diagram of UEFI platform initalization

Figure 5. UEFI platform initialization

The Serial Peripheral Interface (SPI) flash stores important information. Its structure depends on OEMs design, and commonly includes processor microcode update, Intel Management Engine (ME), and boot image, a UEFI executable. When a computer runs, processors execute the firmware code from SPI flash for a while during UEFI’s SEC phase. Instead of memory, the flash is permanently mapped to x86 reset vector (physical address 0xFFFF_FFF0). However, attackers can interfere with memory access to reset vector by software. They do this by reprogramming the BIOS control register on misconfigured devices, making it even harder for security software to determine exactly what gets executed during boot.

Once an implant is deployed, it’s hard to detect. To catch threats at this level, security solutions at the OS level relies on information from the firmware, but the chain of trust is weakened.

Technically, the firmware is not stored and is not accessible from main memory. As opposed to other software, it’s stored in SPI flash storage, so the new UEFI scanner must follow the hardware protocol provided by hardware manufacturers. To be compatible and be up to date with all platforms, it needs to take into consideration protocol differences.

Diagram of UEFI scanner internals

Figure 6. UEFI scanner internals overview

The UEFI scanner performs dynamic analysis on the firmware it gets from the hardware flash storage. By obtaining the firmware, the scanner is able to parse the firmware, enabling Microsoft Defender ATP to inspect firmware content at runtime.

Comprehensive security levels up with low-level protections

The new UEFI scanner adds to a rich set of Microsoft technologies that integrate to deliver chip-to-cloud security, from a strong hardware root of trust to cloud-powered security solutions at the OS level.

Hardware backed security features like Secure Launch and device attestation help stop firmware attacks. These features, which are enabled by default in Secured-core PCs, seamlessly integrate with Microsoft Defender ATP to provide comprehensive endpoint protection.

With its UEFI scanner, Microsoft Defender ATP gets even richer visibility into threats at the firmware level, where attackers have been increasingly focusing their efforts on. Security operations teams can use this new level of visibility, along with the rich set of detection and response capabilities in Microsoft Defender ATP, to investigate and contain such advanced attacks.

This level of visibility is also available in Microsoft Threat Protection (MTP), which delivers an even broader cross-domain defense that coordinates protection across endpoints, identities, email, and apps.

 

 

Kelvin Chan, Shweta Jha, Gowtham Reddy A

Microsoft Defender ATP team

 

 

The post UEFI scanner brings Microsoft Defender ATP protection to a new level appeared first on Microsoft Security.

Exploiting a crisis: How cybercriminals behaved during the outbreak

June 16th, 2020 No comments

In the past several months, seemingly conflicting data has been published about cybercriminals taking advantage of the COVID-19 outbreak to attack consumers and enterprises alike. Big numbers can show shifts in attacker behavior and grab headlines. Cybercriminals did indeed adapt their tactics to match what was going on in the world, and what we saw in the threat environment was parallel to the uptick in COVID-19 headlines and the desire for more information.

If one backtracked to early February, COVID-19 news and themed attacks were relatively scarce. It wasn’t until February 11, when the World Health Organization named the global health emergency as “COVID-19”, that attackers started to actively deploy opportunistic campaigns. The week following that declaration saw these attacks increase eleven-fold. While this was below two percent of overall attacks Microsoft saw each month, it was clear that cybercriminals wanted to exploit the situation: eople around the world were becoming aware of the outbreak and were actively seeking information and solutions to combat it.

Worldwide, we observed COVID-19 themed attacks peak in the first two weeks of March. That coincided with many nations beginning to take action to reduce the spread of the virus and travel restrictions coming into effect. By the end of March, every country in the world had seen at least one COVID-19 themed attack.

Graph showing trend of COVID-19 themed attacks and mapping key events during the outbreak

Figure 1. Trend of COVID-19 themed attacks

The rise in COVID-19 themed attacks closely mirrored the unfolding of the worldwide event. The point of contention was whether these attacks were new or repurposed threats. Looking through Microsoft’s broad threat intelligence on endpoints, email and data, identities, and apps, we concluded that this surge of COVID-19 themed attacks was really a repurposing from known attackers using existing infrastructure and malware with new lures.

In fact, the overall trend of malware detections worldwide (orange line in Figure 2) did not vary significantly during this time. The spike of COVID-19 themed attacks you see above (yellow line in Figure 1) is barely a blip in the total volume of threats we typically see in a month. Malware campaigns, attack infrastructure, and phishing attacks all showed signs of this opportunistic behavior. As we documented previously, these cybercriminals even targeted key industries and individuals working to address the outbreak. These shifts were typical of the global threat landscape, but what was peculiar in this case was how the global nature and universal impact of the crisis made the cybercriminal’s work easier. They preyed on our concern, confusion, and desire for resolution.

Graph showing trend of all attacks versus COVID-19 themed attacks

Figure 2. Trend of overall global attacks vs. COVID-19 themed attacks

After peaking in early March, COVID-19 themed attacks settled into a “new normal”. While these themed attacks are still higher than they were in early February and are likely to continue as long as COVID-19 persists, this pattern of changing lures prove to be outliers, and the vast majority of the threat landscape falls into typical phishing and identity compromise patterns.

Cybercriminals are adaptable and always looking for the best and easiest ways to gain new victims. Commodity malware attacks, in particular, are looking for the biggest risk-versus-reward payouts. The industry sometimes focuses heavily on advanced attacks that exploit zero-day vulnerabilities, but every day the bigger risk for more people is being tricked into running unknown programs or Trojanized documents. Likewise, defenders adapt and drive up the cost of successful attacks. Starting in April, we observed defenders greatly increasing phishing awareness and training for their enterprises, raising the cost and complexity barrier for cybercriminals targeting their employees. These dynamics behave very much like economic models if you turn “sellers” to “cybercriminals” and “customers” to “victims”.

Graph showing trend of COVID-19 themed attacks

Figure 3. Trend of COVID-19 themed attacks

Lures, like news, are always local

Cybercriminals are looking for the easiest point of compromise or entry. One way they do this is by ripping lures from the headlines and tailoring these lures to geographies and locations of their intended victims. This is consistent with the plethora of phishing studies that show highly localized social engineering lures. In enterprise-focused phishing attacks this can look like expected documents arriving and asking the user to take action.

During the COVID-19 outbreak, cybercriminals closely mimicked the local developments of the crisis and the reactions to them. Here we can see the global trend of concern about the outbreak playing out with regional differences. Below we take a deeper look at three countries and how local events landed in relation to observed attacks.

FOCUS: United Kingdom

Attacks targeting the United Kingdom initially followed a trajectory similar to the global data, but spiked early, appearing to be influenced by the news and concerns in the nation. Data shows a first peak approximately at the first confirmed COVID-19 death in the UK, with growth beginning again with the FTSE 100 stock crash on March 9, and then ultimately peaking around the time the United States announced a travel ban to Europe.

Graph showing trend of COVID-19 themed attacks and mapping key events during the outbreak in the UK

Figure 4. Trend of COVID-19 themed attacks in the United Kingdom showing unique encounters (distinct malware files) and total encounters (number of times the files are detected)

In the latter half of March, the United Kingdom increased transparency and information to the public as outbreak protocols were implemented, including the closure of schools. The attacks dropped considerably all the way to April 5, when Queen Elizabeth II made a rare televised address to the nation. The very next day, Prime Minister Boris Johnson, who was hospitalized on April 6 due to COVID-19, was moved to intensive care. Data shows a corresponding increase in attacks until April 12, the day the Prime Minister was discharged from the hospital. The level of themed attacks then plateaued at about 3,500 daily attacks until roughly the end of April. The UK government proclaimed the country had passed the peak of infections and began to restore a new normalcy. Attacks took a notable drop to around 2,000 daily attacks.

Sample phishing email with COVID-19 themed lure

Sample phishing email using COVID-19 themed lure

Figure 5. Sample COVID-19 themed lures in attacks seen in the UK

FOCUS: Republic of Korea

The Republic of Korea was one of the earliest countries hit by COVID-19 and one of the most active in combating the virus. We observed attacks in Korea increase and, like the global trend, peak in early March. However, the spike in attacks for this country is steeper than the worldwide average, coinciding with the earlier arrival of the virus here.

Graph showing trend of COVID-19 themed attacks and key events during the outbreak in South Korea

Figure 6. Trend of COVID-19 themed attacks in the Republic of Korea showing unique encounters (distinct malware files) and total encounters (number of times the files are detected)

Interestingly, themed attacks were minimal at the beginning of February despite the impact of the virus. Cybercriminals did not truly ramp up attacks until the middle of February, closely mapping key events like identifying patients from the Shincheonji religious organization, military base lock downs, and international travel restrictions. While these national news events did not create the attacks, it’s clear cybercriminals saw an opening to compromise more victims.

Increased testing and transparency about the outbreak mapped to a downward trajectory of attacks in the first half of March. Looking forward through the end of May, the trend of themed attacks targeting Korean victims significantly departed from the global trajectory. We observed increasing attacks as the country restored some civic life. Attacks ultimately reached a peak around May 23. Analysis is still ongoing to understand the dynamics that drove this atypical increase.

FOCUS: United States

COVID-19 themed attacks in the United States largely followed the global attack trend. The initial ascent began mid-February after the World Health Organization officially named the virus. Attacks reached first peak at the end of February, coinciding with the first confirmed COVID-19 death in the country, and hit its highest point by mid-March, coinciding with the announced international travel ban. The last half of March saw a significant decrease in themed attacks. Telemetry from April and May shows themed attacks leveling off between 20,000 and 30,000 daily attacks. The same pattern of themed attacks mirroring the development of the outbreak and local concern likely played out at the state level, too.

Graph showing trend of COVID-19 themed attacks and mapping key events during the outbreak in the United States

Figure 7. Trend of COVID-19 themed attacks in the United States showing unique encounters (distinct malware files) and total encounters (number of times the files are detected)

Sample COVID-19 themed lure

Figure 8. Sample COVID-19 themed lures in attacks seen in the US

Conclusions

The COVID-19 outbreak has truly been a global event. Cybercriminals have taken advantage of the crisis to lure new victims using existing malware threats. In examining the telemetry, these attacks appear to be highly correlated to local interest and news.

Overall, COVID-19 themed attacks are just a small percentage of the overall threats the Microsoft has observed over the last four months. There was a global spike of themed attacks cumulating in the first two weeks of March. Based on the overall trend of attacks it appears that the themed attacks were at the cost of other attacks in the threat environment.

These last four months have seen a lot of focus on the outbreak – both virus and cyber. The lessons we draw from Microsoft’s observations are:

  • Cybercriminals adapt their tactics to take advantage of local events that are likely to lure the most victims to their schemes. Those lures change quickly and fluidly while the underlying malware threats remain.
  • Defender investment is best placed in cross-domain signal analysis, update deployment, and user education. These COVID-19 themed attacks show us that the threats our users face are constant on a global scale. Investments that raise the cost of attack or lower the likelihood of success are the optimal path forward.
  • Focus on behaviors of attackers will be more effective than just examining indicators of compromise, which tend to be more signals in time than durable.

To help organizations stay protected from the opportunistic, quickly evolving threats we saw during the outbreak, as well as the much larger total volume of threats, Microsoft Threat Protection (MTP) provides cross-domain visibility. It delivers coordinated defense by orchestrating protection, detection, and response across endpoints, identities, email, and apps.

Organizations should further improve security posture by educating end users about spotting phishing and social engineering attacks and practicing credential hygiene. Organizations can use Microsoft Secure Score to assesses and measure security posture and apply recommended improvement actions, guidance, and control. Using a centralized dashboard in Microsoft 365 security center, organizations can compare their security posture with benchmarks and establish key performance indicators (KPIs).

 

The post Exploiting a crisis: How cybercriminals behaved during the outbreak appeared first on Microsoft Security.

Stay ahead of multi-cloud attacks with Azure Security Center

June 15th, 2020 No comments

The COVID-19 crisis has challenged just about every business on the planet to quickly adapt and transform. With massive workforces now remote, IT administrators and security professionals are under increased pressure to keep these workers connected and productive while combating evolving threats, many of which are taking advantage of the situation.

For example, in the process of monitoring 8 trillion daily signals from a range of Microsoft products, services, and feeds, the Microsoft security team has identified multiple COVID-19-themed email campaigns that deliver the powerful credential-stealing program Agent Tesla.

To learn how to defend against these threats and others, join me and Eric Doerr, General Manager of Microsoft Security Response Center, in our next Azure Security Experts Virtual Events Series, Stay Ahead of Attacks with Azure Security Center, on June 30, 2020, from 10:00 AM to 11:00 AM Pacific Time.

There, we’ll step through three strategies to help you lock down your environment:

  • Protect all cloud resources across cloud-native workloads, virtual machines, data services, containers, and IoT edge devices.
  • Strengthen your overall security posture with enhanced Azure Secure Score.
  • Connect Azure Security Center with Azure Sentinel for proactive hunting and threat mitigation with advanced querying and the power of AI.

You’ll see demos of Secure Score and other Security Center features, while Stuart Gregg, Security Operations Manager at global online fashion retailer ASOS shares how his organization has gained stronger threat protection by pairing these technologies with smarter security management practices.

You’ll have the opportunity to take deep dives into how to use Security Center to achieve hybrid and multi-cloud threat protection for:

  • Servers and virtual machines. Learn how to protect your Linux and Windows virtual machines (VMs) using new Security Center features Just-In-Time VM Access, adaptive network hardening, and adaptive application controls. You’ll learn, too, how Security Center works with Microsoft Defender Advanced Threat Protection for Servers to provide threat detection for endpoint servers.
  • Cloud-native workloads. You’ll learn how Security Center supports containers and provides vulnerability assessment.
  • Data services. Breakthroughs in big data and machine learning make it possible for Security Center to detect anomalous database access and query patterns, SQL injection attacks, and other threats targeting your SQL databases in Azure. Learn, too, about malware reputation screening for Azure Storage and threat protection for Azure Key Vault.

In just one hour, you’ll learn how to implement broad threat protection across all your cloud resources, improve your cloud security posture management, keep up with compliance requirements, and stay ahead of a constantly evolving threat landscape.

Register now >

How do I learn more about Azure security and connect with peers and security experts?

In staying ahead of evolving security threats, it’s helpful to stay connected to other security professionals. Here are several ways to do that:

Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Stay ahead of multi-cloud attacks with Azure Security Center appeared first on Microsoft Security.

Blue teams helping red teams: A tale of a process crash, PowerShell, and the MITRE ATT&CK evaluation

June 11th, 2020 No comments

In September 2019, MITRE evaluated Microsoft Threat Protection (MTP) and other endpoint security solutions. The ATT&CK evaluation lasted for three days, with a professional red team from MITRE emulating many advanced attack behaviors used by the nation-state threat group known as YTTRIUM (APT29). After releasing the results of the evaluation, MITRE published the emulation methodology, including all of the attack scripts, tools, and code.

During the evaluation, the Microsoft Threat Protection team noted an interesting behavior related to one of the steps in the APT29 attack chain: Step 19 was supposed to perform stealthy deletion of files using the SDELETE tool reflectively loaded in memory. However, we observed that the step repeatedly caused process crashes during the execution of red team operations.

Crashes are unexpected surprises that could be a true gem for defenders for being a major indicator of an imminent attack, ruining the party for red teams and real attackers alike. Inspired by the transparency of MITRE publishing all the payloads and tools used in the attack simulation, in this blog post, we’ll describe the mystery that is Step 19, share our root cause analysis of the Step 19 attack script, and tell a story about how blue teams, once in a while, share important learnings for red teams and their tools.

Step 19 of the APT29 evaluation

The APT29 emulation involved 20 steps consisting of attacker techniques from the MITRE ATT&CK matrix related to the APT29 group. These steps were executed in the course of two days (plus an extra day reserved as a buffer), 10 steps per day. Since these steps spanned the entire attack chain, each step logically flowed from the previous one.

Step 19 was part of the attack chain executed on the second day. It emulated the attacker’s goal of deleting artifacts from the machine at the end of the breach using the SDELETE tool, which was loaded via PowerShell through a reflective loader mechanism, without ever touching disk.

Figure 1. Step 19 of the MITRE evaluation

This was done by dropping and running a script file called wipe.ps1, in a process that included:

  1. Loading a PowerShell reflective loader
  2. Reflectively loading sdelete.exe, a Sysinternals tool for secure file deletions
  3. Running the reflected exe with the desired files to be deleted

It’s important to note that the wipe.ps1 payload was based on and inspired by the famous “Invoke-ReflectivePEInjection” script from Joseph Bialek (@JosephBialek) and Matt Graeber (@mattifestation), which is also affected by the same issue that we discovered in our investigation and root cause analysis.

Figure 2. Microsoft Threat Protection detection of the reflective loader with relevant cmdlets

Figure 3. Entire script fetched using advanced hunting (truncated for brevity)

Microsoft Threat Protection automatically detected the execution of the reflective loader via PowerShell; however, during the execution of this attack, the telemetry provided by the product also captured the launch of WerFault.exe process (the Windows Error Reporting process) forked from PowerShell.exe, which was a sign of a crashing process.

Having noticed the repeated process crashing behavior, we decided to investigate further to understand what was happening in Step 19, and we observed the following:

 

Test Result
Execution in MITRE test environment #1 (primary) with MTP wipe.ps1 generated crash
Execution in MITRE test environment #2 (backup) with MTP wipe.ps1 generated crash
Execution in MITRE private environment without MTP wipe.ps1 executed with no crashes
Onboarding MTP to MITRE private environment wipe.ps1 generated crash

Indeed, it looked as if MTP was the cause of the wipe.ps1 script crashing. However, we validated that this shouldn’t be the case. Therefore, we performed an extensive analysis independent of the MITRE test, with the hope of finding the root cause of this behavior and sharing with MITRE, red teams, and other researchers.

Deep dive into the crash

Debugging the script wipe.ps1, we noticed an unexpected crash in the GetCommandLineW API, which was quite odd.

Figure 4. Call stack analysis for crash

Since the crash happens at kernelbase!GetCommandLineW, we examined its code before reflective loading:

Figure 5. GetCommandLineW code before patching

Note that the code consists of:

  1. An assignment to the RAX register (the return value register); the returned Unicode string is pointed by address 00007ffd200f9e68, as shown in the debugging session
  2. The RET instruction, which causes the function to return from the function
  3. Padding with the byte CC, which is encoded as INT 3; this is a debug-breakpoint and should never be executed due to the RET instruction

We then examined the code at the moment of the crash:

Figure 6. GetCommandLineW code at the crash

Note that there’s no RET instruction, so INT 3 (debug-breakpoint) was executed, causing the crash during the test (since no debugger is attached). Noting the byte encoding of the instructions and comparing them at a normal state and in the moment of the crash, we noticed a one-byte difference: the second byte changed from 8B to B8, causing a complete modification of the interpreted instruction! 8B is the opcode for a relative addressing move, while B8 is an immediate value move. The first byte 48 is a REX.W prefix, making the instruction refer to 64-bit operands.

Clearly, something strange was happening in the attack script wipe.ps1, so we decided to perform an extensive, line-by-line analysis of the attack script internals.

Anatomy of the reflective loader

As mentioned, the reflective loader used in the MITRE evaluation was inspired by Invoke-ReflectivePEInjection from PowerSploit, so analysis was relatively easier, vis-à-vis reverse engineering a new reflective loader.

A reflective loader is a tool for loading executable code into a process address space without invoking the operating system API, allowing attackers to avoid security products’ instrumentation of APIs such as LoadLibrary WinAPI that loads a DLL. Since .exe files are compiled with relocation tables (due to address space layout randomization (ASLR) support), many reflective loaders support loading of .exe files as well as DLLs.

When reflectively loading an .exe file, special care must be taken, as processes tend to rely on certain memory structures to be uniquely reserved to them. This is especially true for structures like the Process Environment Block (PEB), which contains important information about the current running process without transitioning into kernel mode. The reflective loader used by MITRE indeed takes special care of certain APIs that obtain information from the PEB; it does so by inline hooking.

Specifically, the reflective loader hooks the function GetCommandLineW that we saw earlier. Unless it does so, the reflected .exe code (sdelete.exe in this case) would fetch the original command line (the one for PowerShell.exe in this case) instead of the intended command line. Here’s a step-by-step analysis of the hooking:

  1. In the Update-ExeFunctions PowerShell function, the code fetches GetCommandLineW (and GetCommandLineA) by calling GetProcAddress on kernelbase.dll.

  1. The reflective loader then prepares a shellcode composed of the following parts:
    1. Possible REX.W prefix (byte 48) in case of a 64-bit process
    2. The MOV immediate instruction opcode (byte B8)
    3. An immediate value, which is an allocated address for the new command line buffer
    4. The RET instruction (byte C3)

  1. The reflective loader hooks the GetCommandLineW function by doing the following:
    1. Change the page permissions to RWX with the VirtualProtect API
    2. Call Write-BytesToMemory to copy the REX.W prefix and the MOV opcode to their place
    3. Call StructureToPtr to encode the new address after the MOV instructionl; this also takes care of endianness
    4. Call Write-BytesToMemory again, this time to copy the RET instruction

When performed correctly and fully, this should work well. However, our debugging showed only one-byte change (from 8B to B8) and no RET instruction. This meant that either StructureToPtr had some bug, or that patching was done partially. Assuming the latter, we concluded that the crash happens during the patching itself, after placing the MOV instruction but before encoding the new address, i.e. right after invoking Write-BytesToMemory.

Partial patching and unexpected callbacks

Debugging further, we discovered that the crash indeed happens after the first Write-BytesToMemory cmdlet. The call stack analysis showed that the call originates from PowerShell itself (or more precisely, from the CLR which is invoked by PowerShell), which is odd. This means that some code in PowerShell somehow tries to fetch the current process command line immediately after the cmdlet is executed.

We discovered that the code responsible for fetching the command line is the code that generates Event Tracing for Windows (ETW) for cmdlets. The Microsoft-Windows-PowerShell event provider exposes event IDs that log cmdlets, such as event 7937. Here’s an example of such an event:

Figure 7. Cmdlet tracing with ETW

Note the captured information, such as the cmdlet name, cmdlet type, and the process command line. The ETW writer for cmdlets is invoked after the cmdlet has finished running and has logged all the information. The command line itself is fetched by the ETW writer by invoking GetCommandLineW.

This means that an the ETW writer invoked for the first Write-BytesToMemory would invoke GetCommandLineW, but since only the first two bytes were patched, then GetCommandLineW is “half-patched”, eventually executing INT 3 and causing a crash.

While this explains the crash, it doesn’t explain why there was no crash when Microsoft Threat Protection was not present. The solution for this is simple: if there are no ETW listeners to the event, the ETW writer is never invoked, and therefore never tries to fetch the command line. Indeed, Microsoft Threat Protection listens to many ETW providers, including the Microsoft-Windows-PowerShell ETW.

To summarize, here is a flow diagram showing how this scenario runs:

Figure 8. Flow chart for the first Write-BytesToMemory cmdlet run

This conclusively proves that if any ETW listener registers to this ETW event (and not just Microsoft Threat Protection), the PowerSploit reflective loader implementation will crash. We reproduced this behavior without Microsoft Threat Protection and reported it to the MITRE red team to decide the course of action with Step 19.

What red teams can learn from this incident

PowerSploit is a known and widely used infrastructure for red teams. It’s used extensively and its codebase is regularly checked and updated. Even such a well-established project may contain unexpected bugs, some of which could only occur under special conditions such as specific environment changes like the one we described here.

Data we gathered using the advanced hunting capability in MTP further establishes this strong correlation: in real-world environments, 66% of the Invoke-ReflectivePEInjection invocations end up crashing their hosting PowerShell instance. This is a statistically significant proof of this bug in PowerSploit.

Figure 9. Advanced hunting query for correlating PowerShell crashes and Cmdlet invocation

The TL;DR advice for red teams is this: if you use “Invoke-ReflectivePEInjection” script during your regular penetration testing, be aware of an unexpected surprise in certain circumstances that may lead to immediate detection.

We thank MITRE for leading a transparent and collaborative evaluation process that encourages partnership and threat intelligence sharing. To learn how Microsoft Threat Protection did in the evaluation, read: Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation.

 

 

Jonathan Bar Or

Microsoft Threat Protection Research Team

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Blue teams helping red teams: A tale of a process crash, PowerShell, and the MITRE ATT&CK evaluation appeared first on Microsoft Security.

What’s new in Microsoft 365 Compliance and Risk Management

June 11th, 2020 No comments

The world has dramatically changed over the past three months. As Satya shared in our recent quarterly earnings, we have seen two years’ worth of digital transformation in two months. With that significant amount of rapid change, it’s more important than ever to make sure your business-critical data is kept private and secure while ensuring you remain compliant with privacy laws and regulations.

As the world continues to adjust, many of the customers I’ve been talking with lately have started to focus on cost optimization—how to do more with what they already have or even consolidate the number of systems they have to maintain.

Within Microsoft 365 Compliance, we have been working alongside many of you to help you through the crisis, as well as continue to evaluate the implications of tech decisions on security, privacy, and compliance. With that in mind, here’s a summary of some of the investments we’ve made in the last two months in Microsoft 365 Compliance to help you to get the most out of Microsoft 365 and take a more integrated approach to secure, protect, and manage your data, while mitigating risk.

Data protection

With Microsoft Information Protection (MIP), we are building a unified set of capabilities for classification, labeling, and protection not only in Office apps, but also in other popular productivity services where information resides (e.g., OneDrive, SharePoint, and Exchange). For example, to help you to have a more holistic understanding of the sensitive data in your digital estate, we recently announced the general availability of the data classification capabilities in the Microsoft 365 compliance center. These capabilities enable you to discover, classify, review, and monitor your data and establish appropriate policies to better protect and govern critical data (e.g., by applying sensitivity and retention labels or data loss prevention policies).

Another core component of Microsoft Information Protection is the ability to apply sensitivity labels. You can apply a sensitivity label to important documents or emails and associate it with protection policies and actions like encryption and visual marking. You can also be assured that the protection will persist with the document throughout its lifecycle. You can also apply sensitivity labels to a Microsoft Teams site, SharePoint site, or Microsoft 365 group and help to ensure appropriate device and privacy settings.

Since labeling can help you to protect your data, you need a method that will scale with the vast amount of data you have. To help you achieve that scale, we are announcing general availability for automatic classification with sensitivity labels for documents stored on OneDrive and SharePoint, and for emails in transit in Exchange.

Users can also manually classify emails and documents by applying these labels based on their assessment of the content and their interpretation of the organizational guidelines. In fact, we recently announced the general availability of sensitivity labels with protection for Office files in SharePoint and OneDrive. Now your users can apply sensitivity labels, with protection policies, not just in Office apps on Windows, Mac, iOS, and Android but also in Office on the web. For files labeled and protected with encryption and stored in SharePoint and OneDrive, your users can search for content within these documents, coauthor using Office web apps, and be assured that the protection will persist even after the document is downloaded.

We have also worked with other productivity tools like Microsoft Power BI to make it easy to apply a sensitivity label to Power BI artifacts—including dashboards and reports that are created from a single or multiple data sources. This helps to ensure the persistent protection of the data—even if exported to a file format such as Excel, as the exported file inherits the sensitivity label and associated protection settings. Now generally available, when you connect to a Power BI dataset from Excel, that dataset’s sensitivity label will be inherited and applied to the Excel file and all associated outcomes like headers, footers, and encryption.

Data governance

The increased volume of information and multiple collaboration tools can create complexity for managing business records with serious cost and risk implications. As organizations across a variety of industries face ever-increasing regulations, many companies move data to different systems of record to manage them and comply with regulations. However, moving content to a different system, instead of managing it in place, can increase the risk of missing records or not declaring them properly.

We have also worked with other productivity tools like Microsoft Power BI to make it easy to apply Microsoft Information Protection’s sensitivity label to Power BI artifacts – including dashboards, datasets, dataflows and reports. Now generally available, this ensures the persistent protection of the data – even if exported to a file format such as Excel, as the exported file inherits the sensitivity label and associated protection settings. Rolling out soon is the persistence of label and protection when you embed a Power BI report in Microsoft Teams or when you maintain a live connection between an Excel file and a labeled Power BI data set.

Compliance and security in Microsoft Teams

With the move to remote work, many companies are operating solely in platforms like Microsoft Teams to stay connected, productive, and collaborative and keep their businesses moving forward. However, the move to remote work only seems to amplify the need for security, privacy, and compliance. We built Teams with that mind. Data in Teams is encrypted at rest and in transport, and uses secure real-time protocol for video, audio, and desktop sharing.

Last month, we shared that there are also several tools that help you remain in control and protect sensitive documents and data in Microsoft 365. For example, you can restrict Teams experiences for guests and people outside of your organization. You can also govern the apps to which each user has access. Setting up DLP policies in Teams can protect your data and take specific actions when sensitive information is shared.

There’s so much more. Read the Microsoft 365 blog for details.

Managing insider risk and maintaining your culture

We also know that stressful events contribute to the likelihood of insider risks, such as leakages, IP theft, or data harassment. Insider Risk Management looks at activity from across Microsoft 365, including Teams, to identify potential suspicious activity early.

Communication Compliance, part of the new Insider Risk Management solution set in Microsoft 365, leverages machine learning to quickly identify and take action on code of conduct policy violations in company communications channels, including Teams. Communication Compliance reasons over language used in Teams—and now also Yammer—which may indicate issues related to threats (harm to oneself or others). Detecting this type of language in a timely manner not only minimizes the impact of internal risk, but also can help to support employee mental health in uncertain times like this.

Commitment to continued investment

This new remote work world makes data protection, governance, and security arguably more important than ever. We continue to innovate across Microsoft 365 Compliance to ensure you have the tools you need to help keep your data safe while addressing compliance and proper risk management.

The post What’s new in Microsoft 365 Compliance and Risk Management appeared first on Microsoft Security.

Categories: Compliance, cybersecurity, Microsoft 365 Tags:

The science behind Microsoft Threat Protection: Attack modeling for finding and stopping evasive ransomware

June 10th, 2020 No comments

The linchpin of successful cyberattacks, exemplified by nation state-level attacks and human-operated ransomware, is their ability to find the path of least resistance and progressively move across a compromised network. Determining the full scope and impact of these attacks is one the most critical, but often most challenging, parts of security operations.

To provide security teams with the visibility and solutions to fight cyberattacks, Microsoft Threat Protection (MTP) correlates threat signals across multiple domains and point solutions, including endpoints, identities, data, and applications. This comprehensive visibility allows MTP to coordinate prevention, detection, and response across your Microsoft 365 data.

One of the many ways that MTP delivers on this promise is by providing high-quality consolidation of attack evidence through the concept of incidents. Incidents combine related alerts and attack behaviors within an enterprise. An example of an incident is the consolidation of all behaviors indicating ransomware is present on multiple machines, and connecting lateral movement behavior with initial access via brute force. Another example can be found in the latest MITRE ATT&CK evaluation, where Microsoft Threat Protection automatically correlated 80 distinct alerts into two incidents that mirrored the two attack simulations.

The incident view helps empower defenders to quickly understand and respond to the end-to-end scope of real-world attacks. In this blog we will share details about a data-driven approach for identifying and augmenting incidents with behavioral evidence of lateral movement detected through statistical modeling. This novel approach, an intersection of data science and security expertise, is validated and leveraged by our own Microsoft Threat Experts in identifying and understanding the scope of attacks.

Identifying lateral movement

Attackers move laterally to escalate privileges or to steal information from specific machines in a compromised network. Lateral movement typically involves adversaries attempting to co-opt legitimate management and business operation capabilities, including applications such as Server Message Block (SMB), Windows Management Instrumentation (WMI), Windows Remote Management (WinRM), and Remote Desktop Protocol (RDP). Attackers target these technologies that have legitimate uses in maintaining functionality of a network because they provide ample opportunities to blend in with large volumes of expected telemetry and provide paths to their objectives. More recently, we have observed attackers performing lateral movement, and then using the aforementioned WMI or SMB to deploy ransomware or data-wiping malware to multiple target machines in the network.

A recent attack from the PARINACOTA group, known for human-operated attacks that deploy the Wadhrama ransomware, is notable for its use of multiple methods for lateral movement. After gaining initial access to an internet-facing server via RDP brute force, the attackers searched for additional vulnerable machines in the network by scanning on ports 3389 (RDP), 445 (SMB), and 22 (SSH).

The adversaries downloaded and used Hydra to brute force targets via SMB and SSH. In addition, they used credentials that they stole through credential dumping using Mimikatz to sign into multiple other server machines via Remote Desktop. On all additional machines they were able to access, the attackers performed mainly the same activities, dumping credentials and searching for valuable information.

Notably, the attackers were particularly interested in a server that did not have Remote Desktop enabled. They used WMI in conjunction with PsExec to allow remote desktop connections on the server and then used netsh to disable blocking on port 3389 in the firewall. This allowed the attackers to connect to the server via RDP.

They eventually used this server to deploy ransomware to a huge portion of the organization’s server machine infrastructure. The attack, an example of a human-operated ransomware campaign, crippled much of the organization’s functionality, demonstrating that detecting and mitigating lateral movement is critical.

PARINACOTA ransomware attack chain

Figure 1. PARINACOTA attack with multiple lateral movement methods

A probabilistic approach for inferring lateral movement

Automatically correlating alerts and evidence of lateral movement into distinct incidents requires understanding the full scope of an attack and establishing the links of an attacker’s activities that show movement across a network. Distinguishing malicious attacker activities among the noise of legitimate logons in complex networks can be challenging and time-consuming. Failing to get an aggregated view of all related alerts, assets, investigations, and evidence may limit the action that defenders take to mitigate and fully resolve an attack.

Microsoft Threat Protection uses its unique cross-domain visibility and built-in automation powered to detect lateral movement The data-driven approach to detecting lateral movement involves understanding and statistically quantifying behaviors that are observed to a part of one attack chain, for example, credential theft followed by remote connections to other devices and further unexpected or malicious activity.

Dynamic probability models, which are capable of self-learning over time using new information, quantify the likelihood of observing lateral movement given relevant signals. These signals can include the frequency of network connections between endpoints over certain ports, suspicious dropped files, and types of processes that are executed on endpoints. Multiple behavioral models encode different facets of an attack chain by correlating specific behaviors associated with attacks. These models, in combination with anomaly detection, drive the discovery of both known and unknown attacks.

Evidence of lateral movement can be modeled using a graph-based approach, which involves constructing appropriate nodes and edges in the right timeline. Figure 2 depicts a graphical representation of how an attacker might laterally move through a network. The objective of graphing an attack is to discover related subgraphs with high enough confidence to surface for immediate further investigation. Building behavioral models that can accurately compute probabilities of attacks is key to ensuring that confidence is correctly measured and all related events are combined.

Visualization of network with an attacker moving laterally

Figure 2. Visualization of network with an attacker moving laterally (combining incidents 1, 2, 4, 5)

Figure 3 outlines the steps involved for modeling lateral movement and encoding behaviors that are later referenced for augmenting incidents. Through advanced hunting, examples of lateral movement are surfaced, and real attack behaviors are analyzed. Signals are then formed by aggregating telemetry, and behavioral models are defined and computed.

Diagram showing steps for specifying statistical models for detecting lateral movement

Figure 3. Specifying statistical models to detect lateral movement encoding behaviors

Behavioral models are carefully designed by statisticians and threat experts working together to combine best practices from probabilistic reasoning and security, and to precisely reflect the attacker landscape.

With behavioral models specified, the process for incident augmentation proceeds by applying fuzzy mapping to respective behaviors, followed by estimating the likelihood of an attack. For example, if there’s sufficient confidence that the relative likelihood of an attack is higher, including the lateral movement behaviors, then the events are linked. Figure 4 shows the flow of this logic. We have demonstrated that the combination of this modeling with a feedback loop based on expert knowledge and real-world examples accurately discovers attack chains.

Diagram showing steps of algorithm for augmenting incidents using graph inference

Figure 4. Flow of incident augmentation algorithm based on graph inference

Chaining together the flow of this logic in a graph exposes attacks as they traverse a network. Figure 5 shows, for instance, how alerts can be leveraged as nodes and DCOM traffic (TCP port 135) as edges to identify lateral movement across machines. The alerts on these machines can then be fused together into a single incident. Visualizing these edges and nodes in a graph shows how a single compromised machine could allow an attacker to move laterally to three machines, one of which was then used for even further lateral movement.

Diagram showing relevant alerts as an attack move laterally from one machine to other machines

Figure 5. Correlating attacks as they pivot through machines

Augmenting incidents with lateral movement intel

The PARINACOTA attack we described earlier is a human-operated ransomware campaign that involved compromising six newly onboarded servers. Microsoft Threat Protection automatically correlated the following events into an incident that showed the end-to-end attack chain:

  • A behavioral model identified RDP inbound brute force attempts that started a few days before the ransomware was deployed, as depicted in Figure 6.
  • When the initial compromise was detected, the brute force attempts were automatically identified as the cause of the breach.
  • Following the breach, attackers dropped multiple suspicious files on the compromised server and proceeded to move laterally to multiple other servers and deploy the ransomware payload. This attack chain raised 16 distinct alerts that Microsoft Threat Protection, applying the probabilistic reasoning method, correlated into the same incident indicating the spread of ransomware, as illustrated in Figure 7.

Graph showing increased daily inbound RDP traffic

Figure 6. Indicator of brute force attack based on time series count of daily inbound public IP

Diagram showing ransomware being deployed after an attacker has moved laterally

Figure 7. Representation of post breach and ransomware spreading from initial compromised server

Another area where constructing graphs is particularly useful is when attacks originate from unknown devices. These unknown devices can be misconfigured machines, rogue devices, or even IoT devices within a network. Even when there’s no robust telemetry from devices, they can still be used as linking points for correlating activity across multiple monitored devices.

In one example, as demonstrated in figure 8, we saw lateral movement from an unmonitored device via SMB to a monitored device. That device then established a connection back to a command-and-control (C2), set up persistence, and collected a variety of information from the device. Later, the same unmonitored device established an SMB connection to a second monitored device. This time, the only actions the attacker took was to collect information from the device.

The two devices shared a common set of events that were correlated into the same incident:

  • Sign-in from an unknown device via SMB
  • Collecting device information

Diagram showing suspicious traffic from unknown devices

Figure 8: Correlating attacks from unknown devices

Conclusion

Lateral movement is one of the most challenging areas of attack detection because it can be a very subtle signal amidst the normal hum of a large environment. In this blog we described a data-driven approach for identifying lateral movement in enterprise networks, with the goal of driving incident-level discovery of attacks, delivering on the Microsoft Threat Protection (MTP) promise to provide coordinated defense against attacks. This approach works by:

  • Consolidating signals from Microsoft Threat Protection’s unparalleled visibility into endpoints, identities, data, and applications.
  • Forming automated, compound questions of the data to identify evidence of an attack across the data ecosystem.
  • Building subgraphs of lateral movement across devices by modeling attack behavior probabilistically.

This approach combines industry-leading optics, expertise, and data science, resulting in automated discovery of some of the most critical threats in customer environments today. Through Microsoft Threat Protection, organizations can uncover lateral movement in their networks and gain understanding of end-to-end attack chains. Microsoft Threat Protection empowers defenders to automatically stop and resolve attacks, so security operations teams can focus their precious time and resources to more critical tasks, including performing mitigation actions that can remove the ability of attackers to move laterally in the first place, as outlined in some of our recent investigations here and here.

 

 

Justin Carroll, Cole Sodja, Mike Flowers, Joshua Neil, Jonathan Bar Or, Dustin Duran

Microsoft Threat Protection Team

 

The post The science behind Microsoft Threat Protection: Attack modeling for finding and stopping evasive ransomware appeared first on Microsoft Security.

11 security tips to help stay safe in the COVID-19 era

June 9th, 2020 No comments

The COVID-19 pandemic has changed our daily routines, the ways we work, and our reliance on technology. Many of us are now working remotely, students are attending classes virtually, and we’re relying more on social media and social networks to stay connected as we define what our new normal looks like.

As we spend more time online, it’s important to remember that the basics of online safety have not changed. These guidelines provide a strong foundation for digital security, but as we think about the “new normal” and how the internet is woven into the fabric of our lives, extra steps may be necessary to further reduce risk.

So, in addition to the security policies implemented by your work or school, here are a few more practices we recommend you—and your family and friends—adopt to further increase personal cybersecurity resilience.

Keep devices secure and up to date

  1. Turn on automatic security updates, antivirus, and firewall. The reality of cyberthreats is that they often prey upon the devices that are the easiest to compromise: those without a firewall, without an antivirus service, or without the latest security updates. To reduce this risk, turn on automatic updates to ensure your devices have the latest security fixes, enable or install an antivirus solution that runs continuously, and configure a firewall. Modern computers have many of these features available and enabled by default, but it is a good idea to check all three are correctly set up.
  2. Don’t forget networking devices. Device safety includes your networking devices, too. As with computing devices, make sure that you check for and apply all updates for your networking devices. Many devices use default passwords, which means attackers have an easy list to try. Make sure to check your networking devices are not using default admin passwords or ones that are easily guessable (like your birthday). It’s also good hygiene to update your Wi-Fi credentials to strong passwords with a mix of upper- and lowercase letters as well as symbols and numbers.
  3. Use Wi-Fi encryption options for access. Wireless access points offer the ability to require passwords to gain access to the network. You should take advantage of this feature to ensure only authorized users are on your home network.

Secure your identity, guard your privacy

  1. Protect your digital identity. With more of our lives connected in the virtual realm, your digital identity becomes even more important to protect. Use strong passwords or, if possible, biometric authentication like your face or fingerprint, and wherever possible enable multi-factor authentication (MFA). Among others, Google and Microsoft both offer free MFA applications that are easy to set up and use.
  2. Keep your guard up in online chats and conferencing services. As we spend more time on virtual conferences and video calls, it is important to think about privacy. Consider these questions when trying new services:
    • Who can access or join the meeting/call?
    • Can it be recorded? If yes, do all participants know?
    • Are chats preserved and shared?
    • If there is file sharing, where are those files stored?
  3. Use background blur or images to obscure your location. One of the more popular features on video conferencing tools like Zoom, Skype, and Microsoft Teams is the ability to blur or change your background. This can be an important privacy step that you can take to maintain privacy between home and work environments.

Protect business data while at home

  1. Use the right file-sharing service for the right task. While working remotely, it’s easy for lines to blur between work and home. It’s important to ensure that your business data does not get mixed with your personal data. Remember to use business resources, like SharePoint or OneDrive for Business, to store and share content for work. Don’t use consumer offerings for business data while you are remote. Where possible, consider enabling Windows Information Protection to reduce the risk of unintentional (and intentional) enterprise data leakage via consumer services.
  2. Turn on device encryption. Device encryption ensures that data on your device is safe from unauthorized access should your device be stolen or lost.

Be aware of phishing and identity scams

Cybercriminals continue to exploit victims even through this global crisis. Based on what Microsoft has observed over the last two months, cybercriminals are utilizing new lures related to the coronavirus outbreak and are being indiscriminate in their targeting. As we move into this “new normal” of more virtual engagement, the same vigilance you kept at the office or classroom applies at home. Here are a couple of observed attack methods to keep top of mind:

  1. Identity compromise is still number one point of entry. Attackers are looking to steal your digital identity for monetization, spam, and access. Be on the lookout for unexpected websites and applications asking you to sign in with your credentials. The same goes for MFA requests. If you did not initiate the request, do not verify it. Report suspected sites and uninitiated authentication requests through your browser or applications.
  2. Phishing is still out there. Be wary of offers that are too good to be true, pressure time, or promise a free prize. These are the same bad guys from before, but now they’re using the outbreak and public fear to drive a different action. For more information on phishing attacks, read Protecting against coronavirus themed phishing attacks.
  3. Don’t fall victim to tech support scams. Tech support scams are an industry-wide issue where scammers use scare tactics to try and trick you into paying for unnecessary services that supposedly fix a device, operating system, or software problem. Please note that Microsoft will never contact you with an unsolicited offer to address a technical issue. And error and warning messages in Microsoft products never include a phone number to call. If you receive an unsolicited tech support call telling you there is something wrong with your computer—even if the caller offers to correct the issue for free—hang up and report the call to https://www.microsoft.com/reportascam. For more information on tech support scams, visit this page: https://support.microsoft.com/en-us/help/4013405/windows-protect-from-tech-support-scams.

With awareness and these few simple steps, you can better prepare yourself for this new world of secure remote work and social interaction. And as attackers evolve, we’ll be here to help you adapt and stay safe.

To learn more about Microsoft security solutions, visit our website. 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 11 security tips to help stay safe in the COVID-19 era appeared first on Microsoft Security.

4 identity partnerships to help drive better security

May 28th, 2020 No comments

At Microsoft, we are committed to driving innovation for our partnerships within the identity ecosystem. Together, we are enabling our customers, who live and work in a heterogenous world, to get secure and remote access to the apps and resources they need. In this blog, we’d like to highlight how partners can help enable secure remote access to any app, access to on-prem and legacy apps, as well as how to secure seamless access via passwordless apps. We will also touch on how you can increase security visibility and insights by leveraging Azure Active Directory (Azure AD) Identity Protection APIs.

Secure remote access to cloud apps

As organizations adopt remote work strategies in today’s environment, it’s important their workforce has access to all the applications they need. With the Azure AD app gallery, we work closely with independent software vendors (ISV) to make it easy for organizations and their employees and customers to connect to and protect the applications they use. The Azure AD app gallery consists of thousands of applications that make it easy for admins to set up single sign-on (SSO) or user provisioning for their employees and customers. You can find popular collaboration applications to work remotely such Cisco Webex, Zoom, and Workplace from Facebook or security focused applications such as Mimecast, and Jamf. And if you don’t find the application your organization needs, you can always make a nomination here.

The Azure AD Gallery

The Azure AD Gallery.

Secure hybrid access to your on-premises and legacy apps

As organizations enable their employees to work from home, maintaining remote access to all company apps, including those on-premises and legacy, from any location and any device, is key to safeguard the productivity of their workforce. Azure AD offers several integrations for securing on-premises SaaS applications like SAP NetWeaver, SAP Fiori systems, Oracle PeopleSoft and E-Business Suite, and Atlassian JIRA and Confluence through the Azure AD App Gallery. For customers who are using Akamai Enterprise Application Access (EAA), Citrix Application Delivery Controller (ADC), F5 BIG-IP Access Policy Manager (APM), or Zscaler Private Access (ZPA), Microsoft has partnerships to provide remote access securely and help extend policies and controls that allow businesses to manage and govern on-premises legacy apps from Azure AD without having to change how the apps work.

Our integration with Zscaler allows a company’s business partners, such as suppliers and vendors, to securely access legacy, on-premises applications through the Zscaler B2B portal.

Integration with Zscaler

Go passwordless with FIDO2 security keys

Passwordless methods of authentication should be part of everyone’s future. Currently, Microsoft has over 100-million active passwordless end-users across consumer and enterprise customers. These passwordless options include Windows Hello for Business, Authenticator app, and FIDO2 security keys. Why are passwords falling out of favor? For them to be effective, passwords must have several characteristics, including being unique to every site. Trying to remember them all can frustrate end-users and lead to poor password hygiene.

Since Microsoft announced the public preview of Azure AD support for FIDO2 security keys in hybrid environments earlier this year, I’ve seen more organizations, especially with regulatory requirements, start to adopt FIDO2 security keys. This is another important area where we’ve worked with many FIDO2 security key partners who are helping our customers to go passwordless smoothly.

Partner logos

Increase security visibility and insights by leveraging Azure AD Identity Protection APIs

We know from our partners that they would like to leverage insights from the Azure AD Identity Protection with their security tools such as security information event management (SIEM) or network security. The end goal is to help them leverage all the security tools they have in an integrated way. Currently, we have the Azure AD Identity Protection API in preview that our ISVs leverage. For example, RSA announced at their 2020 conference that they are now leveraging our signals to better defend their customers.

We’re looking forward to working with many partners to complete these integrations.

If you haven’t taken advantage of any of these types of solutions, I recommend you try them out today and let us know what you think. If you have product partnership ideas with Azure AD, feel free to connect with me via LinkedIn or Twitter.

The post 4 identity partnerships to help drive better security appeared first on Microsoft Security.