Swedish Windows Security User Group

This guide provides steps organizations can take to assess whether users have been targeted or compromised by threat actors exploiting CVE-2023-23397. A successful exploit of this vulnerability can result in unauthorized access to an organization’s environment by triggering a Net-NTLMv2 hash leak. Understanding the vulnerability and how it has been leveraged by threat actors can help guide the overall investigative process.

This document covers:

• An overview of the vulnerability
• Exploit scenarios
• Post-exploit activities observed in attacks
• Techniques for determining if an organization was targeted or compromised via this vulnerability
• Mitigations available to protect your environment

Exploitation of CVE-2023-23397 leaves very few forensic artifacts to discover in traditional endpoint forensic analysis. This blog describes how Microsoft Incident Response (previously known as Microsoft Detection and Response Team – DART) was able to detect the abuse of CVE-2023-23397 and how organizations can identify historical and present evidence of compromise through this vulnerability.

This vulnerability triggers a Net-NTLMv2 hash leak. Abuse of the leaked Net-NTLMv2 hash is post-exploitation activity. In this blog, we emphasize specific observed post-exploitation activity that targeted Microsoft Exchange Server. However, there are numerous ways that a leaked Net-NTLMv2 hash could be used by a threat actor.

Understanding the vulnerability (CVE-2023-23397)

CVE-2023-23397 is a critical elevation of privilege vulnerability in Microsoft Outlook on Windows. It is exploited when a threat actor delivers a specially crafted message to a user. This message includes the PidLidReminderFileParameter extended Messaging Application Programming Interface (MAPI) property, which must be set to a Universal Naming Convention (UNC) path share on a threat actor-controlled server (via Server message block (SMB)/transmission control protocol (TCP) port 445).

In exploitation of CVE-2023-23397, threat actors can specify the value for the PidLidReminderFileParameter in specially crafted messages to trigger a Net-NTLMv2 hash leak to threat actor-controlled servers.

The user does not need to interact with the message: if Outlook on Windows is open when the reminder is triggered, it allows exploitation. The connection to the remote SMB server sends the user’s Net-NTLMv2 hash in a negotiation message, which the threat actor can either a) relay for authentication against other systems that support NTLMv2 authentication or b) perform offline cracking to extract the password. As these are NTLMv2 hashes, they cannot be leveraged as part of a Pass-the-Hash technique. All versions of Microsoft Outlook on Windows are impacted. Outlook for Android, iOS, Mac, and users who use Outlook on the web (OWA) without using the Outlook client are not affected.

Microsoft has traced evidence of potential exploitation of this vulnerability as early as April 2022.

This technique leverages the Transport Neutral Encapsulation Format (TNEF). TNEF is a Microsoft-specific format for transmitting formatted email messages. A TNEF message contains a plaintext version of the message and an attachment that packages the original formatted version of the message. Typically, this attachment is named Winmail.dat. The Winmail.dat attachment includes formatting, attachments, and Outlook-specific features such as meeting requests including extended MAPI Properties. Details about TNEF can be found here:

• https://learn.microsoft.com/office/client-developer/outlook/mapi/transport-neutral-encapsulation-format-tnef
• https://learn.microsoft.com/exchange/mail-flow/content-conversion/content-conversion.

Outlook on Windows is designed to enable a user to specify a custom sound file associated with a reminder.

Modifying this value sets the PidLidReminderFileParameter extended MAPI property, which is stored as a property associated with the specific mail object. A tool such as MFCMAPI (see https://github.com/stephenegriffin/mfcmapi) can be used to view extended MAPI properties associated with an object. In the following screenshot, the value of the PidLidReminderFileParameter is shown set to reminder.wav, the PidLidReminderSet is “True”, and the reminder times are set to occur in the past.

To further deceive users, threat actors may also set the PidLidReminderTime property to remain dormant in the mailbox until a future date.

The affected Net-NTLMv2 hash belongs to the user signed in to the Windows device where the Outlook client application is running, regardless of the identity that received the malicious message. If the user does not dismiss the reminder/task Outlook alert or the reminder is recurring (i.e., fires multiple times), the user’s Net-NTLMv2 hash can be leaked multiple times.

Note: Interaction based on the WebDAV protocol is not at risk of leaking credentials via this exploit technique. While the threat actor infrastructure might request Net-NTLMv2 authentication, Windows will honor the defined internet security zones and will not send (leak) Net-NTLMv2 hashes. In other words, the vulnerability only affects the SMB protocol. If a target device can communicate to threat actor infrastructure over port 445 (SMB), Net-NTLMv2 hashes might be sent; however, if this communication via SMB is not possible, Windows will fall back to leveraging WebDAV. WebDAV will set up a connection with the threat actor infrastructure, but Net-NTLMv2 hashes will not be sent.

Observed post-exploitation actions

In a recent engagement, Microsoft Incident Response has observed additional post-exploitation activities following exploitation of CVE-2023-23397. The presence of artifacts associated with these post-exploitation activities can strongly suggest compromise of user accounts. These post-exploitation activities include:

Initial access (authentication bypass):

Using a Net-NTLMv2 Relay attack against Exchange Servers (NOTE: Azure Active Directory, the default authentication service for Exchange Online, is not directly susceptible to a Net-NTLMv2 relay attack. However, it is possible that a federated identity provider may be susceptible).

Credential access/lateral movement:

Using the Exchange Web Services (EWS) API to send additional messages with the malicious value of the PidLidReminderFileParameter extended MAPI property to users inside and external to the organization.

Discovery/persistence:

Using the EWS API to enumerate folders in a compromised user’s mailbox and changing the mailbox folder permissions using the UpdateFolder API so that any authenticated user can access all mailbox folder content with “owner” privileges. This technique established additional persistent access to contents of user’s mailboxes even if a password was reset or otherwise remediated.

The following diagrams show initial access using a Net-NTLMv2 Relay attack, persistence via modifying mailbox folder permissions, and lateral movement by sending additional malicious messages.

Threat hunting guidance: Evidence of targeting

Organizations should use an in-depth and comprehensive threat hunting strategy to identify potential credential compromise through CVE-2023-23397. While running the Exchange scanning script provided by Microsoft is an effective first step, this script does not provide visibility into malicious messages for all scenarios.

• Outlook allows users to open multiple mailboxes at the same time. If a user has configured their Outlook to open mailboxes from multiple e-mail services, a malicious message received through one of those other services will still trigger the vulnerability but that message is not in the scanned mailboxes. (Note: Independent of what mailbox or the identity used to access the mailbox, if a malicious message is received, the credential that will leak belongs to the identity currently signed in to the Windows device.)
• Users may move messages to a local file (PST). Local e-mail stores are not scanned when scanning the Exchange environment. Archived messages may show evidence of a prior compromise. If the local files are open in Outlook, messages can still trigger the vulnerability.

If messages have been deleted from Exchange (some organizations may have a policy limiting data retention), then the messages will no longer be available in Exchange.

If no suspicious or malicious values are identified through the Exchange scanning script, organizations should also hunt for known threat actor indicators of compromise (IOCs) related to the exploitation of this vulnerability.

For example, if IP addresses and URIs are extracted from the PidLidReminderFileParameter values, incident responders should review all available security telemetry for presence of these newly identified indicators. Data sources can include:

• Firewall logs
• Proxy logs
• Azure Active Directory sign-in logs for users of Exchange Online
• IIS Logs for Exchange Server
• VPN logs
• RDP Gateway logs
• Endpoint telemetry from an endpoint detection and response (EDR) solution if available
• Forensic endpoint data such as windows event logs from end user systems

For example, using advanced hunting in Microsoft Defender for Endpoint, multiple tables can be queried simultaneously to uncover activities related to IP address indicators:

//Search for activity around IoAs
let IoCs = dynamic(["<IP Address 1>","<IP Address 2>"]);
let range = ago(30d);
union (DeviceProcessEvents | where Timestamp > range | where ProcessCommandLine has_any (IoCs)),
     (DeviceNetworkEvents | where Timestamp > range | where RemoteIP in (IoCs) or LocalIP in (IoCs)),
     (DeviceLogonEvents | where Timestamp > range | where RemoteIP in (IoCs))
| extend SignatureName = tostring(parse_json(AdditionalFields).SignatureName)
| project-reorder Timestamp, DeviceName, ActionType, LocalIP,RemoteIP, RemotePort,SignatureName,ProcessCommandLine
| sort by Timestamp desc

Hunting strategically

There are several approaches to identifying whether your organization was targeted, including the following (ordered from the most high-fidelity to more anomaly-based approach):

• Review suspicious messages, calendar items, or tasks with reminders that were reported by users
• Examine network logging and endpoint logging for evidence of known atomic indicators
• Scan Exchange for delivered messages with the PidLidReminderFileParameter set
• Hunt for anomalous behaviors based on:
  • NTLM authentication involving untrusted or external resources. This can be observed in Exchange Server logging, Microsoft Defender for Identity, and Microsoft Defender for Endpoint telemetry.
  • WebDAV connection attempts through process execution events.
  • SMBClient event log entries.
  • Firewall logs for suspicious outbound SMB connections.

Review suspicious messages, calendar items, or tasks reported by users

Users in targeted organizations will have received messages with the malicious value of the PidLidReminderFileParameter value set. In some cases, users may have reported these suspicious messages, tasks, or calendar invitations to their security team. A high-level investigation of messages potentially exploiting CVE-2023-23397 may not reveal any overt malicious elements, as embedding malicious URLs or other content in the message body itself is not necessary. A deeper analysis of the message’s extended MAPI properties (specifically, the PidLidReminderFileParameter value) is required to confirm if it is malicious.

Scan for messages with malicious properties

Organizations should search their Exchange environment for messages where the PidLidReminderFileParameter value is set. Microsoft has provided a script to enable organizations perform this search here, including instructions: https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/.

The script produces a CSV file enumerating each message that has the PidLidReminderFileParameter property set, and will report on targets that are local on the computer, internal to the network, or on the internet. Any messages identified where this property references a server in the “InternetZone” should be considered malicious. References to intranet servers should also be carefully analyzed. Figure 5 depicts a sample output from this script.

Customers with a large number of mailboxes in Exchange may consider customizing the script logic strategically, by:

• Initially targeting high-value users by specifying a list of mailboxes of interest.
• Timeboxing: As the first known exploitation of this vulnerability was in April 2022 performance can be improved by prioritizing a search from 2022 onwards. It is still recommended to search further historically as well, however with lower priority, as it is possible this exploit was used prior to April 2022.

• Running multiple concurrent scans across different user mailbox sets by using batching (see script documentation).

If any suspicious or malicious messages are identified via this script, organizations should further triage their environment, including:

• examination of the targeted users’ logon behaviors
• hunting for further presence of any malicious domains or IP addresses in available network and endpoint logging.

Artifacts on endpoints

Organizations should review SMBClient event logging, Process Creation events, and other available network telemetry to identify potential exploitation via CVE-2023-23397. To determine whether any such exploitation led to a threat actor gaining unauthorized access to the environment, analysis of authentication events, network perimeter logging, and Exchange Server logging (if Exchange Server is used by the organization) will be instrumental.

Microsoft-Windows-SMBClient/Connectivity event logs

This event logging channel records server errors and warnings for both SMB and WebDAV connections, and provides a source to identify potential compromise through CVE-2023-23397, as it may reveal failed outbound connection attempts to threat actor-controlled infrastructure.

The ServerName field in EventIds 30800, 30803, 30806, 30804, and 31001 should be monitored for non-trusted servers, as illustrated in Figure 6.  

It is critical to note that the presence of these events cannot be used to confirm whether credentials were leaked, and can only be used as evidence that an outbound connection attempt was made by the device but failed (due to a protocol or network error). Microsoft Incident Response observed during an engagement that a device affected by CVE-2023-23397 attempted to connect multiple times to threat actor infrastructure, failing occasionally and producing these event log entries, but otherwise successfully leaking credentials to the threat actor.

WebDAV Process Creation events

If SMB traffic to the internet is blocked by your organization or otherwise fails, Windows will fall back to using WebDAV to attempt to complete the connection. This behavior, paired with CVE-2023-23397 execution, results in a potentially unique Process Creation event and command line parameters that organizations can hunt in endpoint detection and response (EDR) telemetry or other endpoint logging (such as Sysmon logs, as depicted in Figure 7):

• Parent process command line: C:\Windows\system32\svchost.exe -k LocalService -p -s WebClient
• Child process command line: rundll32.exe C:\Windows\system32\davclnt.dll,DavSetCookie <IP Address> hxxp://<Threat actor IP>/folder/sound.wav

It is possible that the filesystem URL may not have a traditional .wav file extension.

It is critical to note that the presence of this process tree in your environment cannot be used to confirm whether credentials were leaked. It can only be used as evidence that a message exploiting CVE-2023-23397 was delivered, triggered an attempted outbound SMB connection/credential leak to threat actor infrastructure, but failed in the given instance as credentials cannot be leaked through WebDAV with this vulnerability. If this failure was the result of a transient network issue (rather than SMB being blocked deliberately and systemically), it is still possible that credentials may have been leaked.

Exchange Server logs

For organizations using Exchange Server, there are several log sources that can provide value in hunting for indicators of attack or compromise through CVE-2023-23397. These log sources may potentially reveal unauthorized access to Exchange Server via a Net-NTLMv2 Relay attack, as well as possible post-exploitation activities. These logs do not provide value in determining whether a NTLMv2 hash was leaked, however.

Microsoft provides this tool to enable organizations to collect relevant Exchange Server logs: https://microsoft.github.io/CSS-Exchange/Diagnostics/ExchangeLogCollector/.

Microsoft Incident Response recommends collecting all logs with the -AllPossibleLogs command line flag; however, a more minimal collection can be obtained using the following flags:

• -EWSLogs
• -IISLogs
• -PowerShellLogs
• -ServerInformation
• -ExchangeServerInformation
• -MessageTrackingLogs
• -OWALogs

Collected logs can be reviewed by ingesting them into Azure Data Explorer, Log Analytics in Azure Monitor, or another SIEM or log parsing utility (such as Log Parser Studio).

Exchange IIS logs

Analysis of IIS logs from Exchange Server (or, if the server is behind a reverse proxy, the IIS logs from the proxy server) can provide insight into potential threat actor behavior.

NOTE: If Exchange Server is protected by a reverse proxy, client IP values (cIP) in logging will only show the IP address of the proxy server. In this case, access to logs from the proxy is critical to determine if connections originated from untrusted IP addresses.

Reverse Proxy Logs

If a reverse proxy is implemented and configured to register headers, such as those that include authentication methods and Net-NTLMv2 negotiations, it is possible to identify Net-NTLMv2 Relay behavior. Microsoft Incident Response was able to leverage these logs in a recent engagement: certain users appeared to authenticate from their appropriate and expected workstations, but the authentications originated from IP addresses associated with threat actor infrastructure.

EWSLogs

Exchange Web Services (EWS) logs include the AuthenticationType. If a Net-NTLMv2 Relay attack was leveraged against an EWS Endpoint, it can often be seen in these logs. Strategies to hunt for anomalies in these logs include:

• Filtering EWSLogs by AuthenticationType for NTLM
• Grouping by ClientIpAddress (NOTE: The external client IP address may need to be parsed from the field, as it can contain the results of proxying the ClientIP to the Exchange Server backend component. Fields will be in the form <ClientIP>:<PortNumber> <ProxiedIPAddress>).
• Group by the AuthenticatedUser

Any authentications using NTLMv2 originating from unknown or untrusted IP addresses should be further examined. If a single external IP address is associated with multiple users’ authentications, and the IP address is not consistent with those users’ typical patterns of behavior (based on factors such as geolocation, hosting provider, or User Agent string), events associated with such an IP should be investigated further.

If a threat actor changes mailbox permissions or mailbox folder permissions as part of their post-exploitation behaviors, SoapActions including “GetFolder”, “UpdateFolder”, and “FindFolder” may be observed for the combination of the authenticated user and IP address.

If a threat actor attempts to access email for a compromised user, SoapActions including “ResolveNames”,”GetDelegate”,”GetFolder”,”FindFolder”,”FindItem”, and “GetItem” may be observed for the combination of the authenticated user and IP address.

The following Kusto Query Language (KQL) query can assist with parsing and summarizing EWS logging for the purposes described above, if the relevant logs have been ingested into Azure Data Explorer.

EWSLogging
| where AuthenticationType == 'NTLM'
| extend IpAddress = tostring(split(ClientIpAddress,":")[0])
| summarize count(), min(['DateTime']),max(['DateTime']), 
    make_set(SoapAction), make_set(UserAgent) by AuthenticatedUser, IpAddress

Exchange HTTP Proxy EWS Logs

HTTP Proxy EWS logs can be useful to identify the details of NTLMv2 authentications. The user name, workstation name, and domain name can be extracted from those values using the techniques described in  

• https://community.pulsesecure.net/t5/Pulse-Secure-vADC/HowTo-Decode-and-log-the-username-in-an-NTLM-connection/ta-p/28869
• https://davenport.sourceforge.net/ntlm.html

Exchange Server Message Tracking Logs

Exchange Server Message Tracking Logs are useful to identify messages with certain subjects or from certain sender IP address values. Refer to the following Microsoft Learn pages for more details:

• https://learn.microsoft.com/exchange/mail-flow/transport-logs/transport-logs?view=exchserver-2019
• https://learn.microsoft.com/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results

Additional indicators of compromise

Potential registry key modification

Microsoft Incident Response identified a registry key that can indicate that a reminder was triggered for a Note or Task item. This registry key holds certain properties (e.g., location and size) of the UI window that is created when the reminder triggered. If a user has not used the reminder functionality within Tasks or Notes, these registry keys will not exist. Figure 8 depicts the Task key as viewed in RegEdit:

• HKCU\Software\Microsoft\Office\<VERSION OF OUTLOOK>\Outlook\Tasks
• HKCU\Software\Microsoft\Office\<VERSION OF OUTLOOK>\Outlook\Notes

The presence of these keys provides evidence that a user has received a reminder for a Task or Note. If the presence of this registry key is identified, and appears to be anomalistic for your organization, threat hunters should examine the user’s mailbox as well as network/endpoint telemetry for further evidence of compromise using the techniques described in this blog, especially by performing temporal analysis around the LastModified timestamp of the registry keys.

Hunting for outbound SMB connections

Network perimeter telemetry and/or EDR data can be investigated for SMB connections involving external IP addresses as part of a larger threat hunting strategy.

The following query can be used in the advanced hunting portal of Microsoft Defender for Endpoint to further align SMB connections with Net-NTLMv2 behavior.

The query will identify connections involving port 445 (standard for SMB) involving remote public IP addresses. By filtering on both Local and Remote parameters, the query will also include records of the NetworkSignatureInspected ActionType. If threat actor infrastructure is attempting to harvest Net-NTLMv2 credentials, the NetworkSignatureInspected ActionType should include a SignatureName of NTLM-Challenge. This indicates a Net-NTLMv2 negotiation was attempted.

For more information about the NetworkSignatureInspected actions, check Hunting for network signatures in Microsoft Defender for Endpoint.

//Hunt for SMB to the internet
let range = ago(30d);
DeviceNetworkEvents
| where Timestamp > range
//Connections have RemotePort set to 445
//NetworkSignatureInspected have LocalPort set to 445
| where RemotePort == 445 or LocalPort == 445
| where not(ipv4_is_private(RemoteIP)) or not(ipv4_is_private(LocalIP))
| extend SignatureName = tostring(parse_json(AdditionalFields).SignatureName)
| project-reorder Timestamp, DeviceName, ActionType, LocalIP,RemoteIP, LocalPort, RemotePort,SignatureName
| sort by Timestamp desc

NOTE: Organizations may consider filtering out their own public IP address space from the query above.

Microsoft product detections

Organizations using Microsoft Defender for Endpoint or Microsoft Defender for Office 365 can identify threats using the following detections.

• Microsoft Defender for Endpoint provides detections with the following titles in the security center can indicate threat activity on your network:
  • Possible target of Net-NTLMv2 credential theft – This detects specific attacks observed by Microsoft prior to disclosure of the vulnerability and might not detect variations on the attack after publishing.
• Microsoft Defender for Office 365 detects messages exploiting this vulnerability and shows administrators the following alerts to indicate that the file contains a critical elevation of privilege exploit related to CVE-2023-23397:
  • Exploit_Office_CVE_2023_23397_A
  • Exploit_Office_CVE_2023_23397_B
  • Exploit_Office_CVE_2023_23397_C
  • Exploit_Office_CVE_2023_23397_D
  • Exploit_Office_CVE_2023_23397_E
  • Exploit_Office_CVE_2023_23397_F
  • Exploit_Office_CVE_2023_23397_G
  • Exploit_Office_CVE_2023_23397_H

Recommendations

Microsoft Incident Response recommends the following steps to mitigate this type of attack and the observed post-exploitation behavior:

• Ensure Microsoft Outlook is updated as soon as possible to mitigate the issue. If patching is not immediately possible, ensuring you have implemented these security best practices can help mitigate this threat:
  • Add users to the Protected Users group, which prevents the use of NTLM as an authentication mechanism. This might impact applications that require NTLM, but the settings will revert once the user is removed from the Protected Users group. This makes troubleshooting easier than other methods of disabling NTLM authentication. The Protected Users group provides credential protections beyond disabling NTLM and should be used for high-value accounts, such as domain administrators, when possible.
  • Block TCP 445/SMB outbound from your network by using a perimeter firewall, local firewall, and through your VPN settings. This helps prevent the exploitation of CVE-2023-23397 to send NTLM authentication messages to remote file shares. For remote users, it is important to check split tunnel VPN settings to ensure outbound traffic is blocked when they are not on your corporate network.
• For organizations leveraging on-premises Microsoft Exchange Server, apply the latest security updates to ensure that defense-in-depth mitigations are active.
• Where suspicious or malicious reminder values are observed, make sure to use the script to remove either the messages or just the properties, and consider initiating incident response activities.
• For any targeted or compromised user, reset the passwords of any account logged in to computers of which the user received suspicious reminders and initiate incident response activities.
• Use multifactor authentication to mitigate the impact of potential Net-NTLMv2 Relay attacks. NOTE: This will not prevent a threat actor from leaking credentials and cracking them offline.
• Disable unnecessary services on Exchange.
• Limit SMB traffic by blocking connections on ports 135 and 445 from all inbound IP addresses except those on a controlled allowlist.
• Disable NTLM in your environment.

Understanding mitigations

To address this vulnerability, you must install the Outlook security update, regardless of where your mail is hosted (e.g., Exchange Online, Exchange Server, some other platform) or your organization’s support for NTLM authentication.

When using Exchange Online or Exchange server as your mail host, you can take the following additional actions:

• Determine if your organization was targeted by actors attempting to use this vulnerability
• Provide defense in depth for new messages received outside your organization 

Protections in Outlook

Outlook for Windows first checks if the path specified by the  PidLidReminderFileParameter message property is to a location that is not in the local or trusted network. If the path points outside of the local or trusted network locations, the parameter is not honored when updates are installed.

Protections in Exchange Online

Exchange Online drops the PidLidReminderFileParameter message property at TNEF conversion when a new message is received from outside of the organization.

Protections for Exchange Server

Exchange Server (with March 2023 SU) drops the PidLidReminderFileParameter message property at TNEF conversion when a new message is received from outside of the organization.

Conclusion

While leveraging NTLMv2 hashes to gain unauthorized access to resources is not a new technique, the exploitation of CVE-2023-23397 is novel and stealthy. Even when users reported suspicious reminders on tasks, initial security review of the messages, tasks, or calendar items involved did not result in detection of the malicious activity. Furthermore, the lack of any required user interaction contributes to the unique nature of this vulnerability. In this document, Microsoft Incident Response has highlighted threat hunting techniques and strategy for exploitation of this CVE, alongside some hunting techniques for observed post-exploitation threat actor behaviors. Furthermore, a broad threat hunting for anomalous user activity consistent with credential compromise is advised.

Observed indicators of attack

Several malicious samples have been uploaded to VirusTotal.com and a signature has been created that identifies potentially malicious messages associated with exploitation of CVE-2023-23397.

VirusTotal subscribers can review those results here: https://www.virustotal.com/gui/search/crowdsourced_yara_rule%253A000bc4a247%257CEXPL_SUSP_Outlook_CVE_2023_23397_Exfil_IP_Mar23

Known IP addresses associated with exploitation of this vulnerability in the above VirusTotal results are listed below. NOTE: These IP addresses were assessed by Microsoft Threat Intelligence to be compromised infrastructure.

• 101.255.119[.]42
• 213.32.252[.]221
• 168.205.200[.]55
• 185.132.17[.]160
• 69.162.253[.]21
• 113.160.234[.]229
• 181.209.99[.]204
• 82.196.113[.]102
• 85.195.206[.]7
• 61.14.68[.]33

The post Guidance for investigating attacks using CVE-2023-23397 appeared first on Microsoft Security Blog.

At Microsoft, we define threat hunting as the practice of actively looking for cyberthreats that have covertly (or not so covertly) penetrated an environment. This involves looking beyond the known alerts or malicious threats to discover new potential threats and vulnerabilities.

Why do incident responders hunt?

The Microsoft Detection and Response Team (DART) mission is to respond to security incidents and help our customers become cyber-resilient. This involves incorporating threat hunting as part of our proactive and reactive investigative service offerings to determine the following:

• Whether systems are under targeted exploitation through investigation for signs of advanced implants and anomalous behavior.
• Identifying groundwork for the recovery process of evicting the attacker from the environment.
• Strategic recommendations for protecting against sophisticated threat actors.

In reactive incident response investigations, threat hunting helps determine the full scope of the incident and informs an effective recovery and remediation strategy. In proactive investigations, a threat hunt can discover latent threats or existing compromises as well as demonstrate the effectiveness of current security controls and their security operations processes. By uncovering novel attacker campaigns and previously undetected threats, DART provides valuable feedback to improve product detections, both for Microsoft security products and for the entire security ecosystem.

How do we approach threat hunting?

The canonical definition of threat hunting involves three interrelated things:

• Targeted threat hunting—We define targeted hunting as actively looking for and rooting out cyberthreats that have penetrated an environment, and looking beyond the known alerts or malicious threats to discover new potential threats and vulnerabilities. Targeted threat hunting has a scope where we are looking for specific classes of indicators. For example, given a recently revealed attack, an organization may want to assess its environment to see if it, too, has been affected.
• Security monitoring—Process of continuously monitoring the state of an environment to detect unusual or unauthorized activities. This involves a network operations center (NOC) and an SOC to ensure that networks are protected against disruptions and threats.
• Incident response investigation—An investigation to identify the root cause and develop a remediation plan to regain and retain positive control over the environment following the detection of unauthorized access or suspicious activity.

Each organization approaches threat hunting differently. Sometimes, the customer will have specific outcomes in mind that align with the known techniques. We center on a general approach based on anomaly detection and pivoting combined with a knowledge of the overall environment. This allows us to accomplish multiple goals, versus employing an approach solely focused on a targeted threat hunt where additional threats and risks may be overlooked.

We will go into more detail about hunting for anomalies later in this blog.

Threat hunting principles

Our forensic investigators at DART lean on the Alexiou Principle, which states four key questions for our investigators to answer:

1. What question are you trying to answer?

Threat hunting varies depending on the main objectives or questions that need to be answered. This involves trying to understand a threat actor’s main objective, the cyber terrain in which they operate, and understanding how you can get closer to those objectives. Framing the question clearly helps us define the scope of every threat hunt.

2. What data do you need to answer that question?

To answer the previous question would involve a two-pronged approach with a focus on determining what data is required, and how to obtain that data. During DART investigations, we often get a variety of datasets while entering a customer investigation, such as live feeds and telemetry. We want to pick up everything that is currently in the environment, enumerate directories that we know bad actors like to live in, collect event logs that will potentially show us evidence of historical or current badness, registry keys that we see bad actors like to tamper with, and many more.

We use a tiered data collection model and start by collecting a snapshot of the densest, most indicator-rich data we can from every object and endpoint we can reach. This data is intended to provide information about any known threats, known attack patterns, and many (but not all) indicators of suspicious or anomalous activity. Where systems of interest are identified, we return and collect a larger, more complete dataset of logs and forensic artifacts.

3. How do you extract that data?

Now that you’ve identified the data, you’ll need to capture it using various toolsets, such as a point-in-time snapshot tool or, if the customer doesn’t have one deployed already, an endpoint detection and response tool, such as Microsoft Defender for Endpoint, to obtain the data. From the analytics captured, we can see things that are potentially good, bad, or interesting. Part of this phase also takes data ingestion into account. We consider how the collected data is consumed and how to efficiently separate threats from the background noise of a complex global enterprise.

4. What does the data tell you?

Looking at the collected data now becomes an exercise in data analytics. It’s a question of evaluating prevalence and frequency by taking everything that occurs within an environment and trying to figure out what belongs and what doesn’t belong. This train of thought can take a handful of different forms, that can be something as simple as “How often does this secure hashing algorithm show up across the entire environment?” to a more nuanced and precise way, such as asking “How often does it show up only on domain controllers? On devices in this organizational unit? How about when it’s seen with this other user account?”

As it turns out, there are a lot of different ways for us to do this counting game. Our role as threat hunters is to figure out the most relevant, high-priority way to account for these interesting findings and see if patterns revealed themselves. We’re looking for indicators of attack or compromise that maybe others haven’t found. It all depends on what data is available to us and understanding it.

Understanding the data

We approach understanding the data by looking for anomalies, the current state, and the absence of data.

Where the rubber meets the road: forming the attack narrative

We believe there’s a clear art and science to threat hunting, but at the end of the day, we seek to understand the anomalies in the acquired evidence. One way we do this is by using the knowledge of what is typical in an environment to identify what isn’t. Understanding the typical scenario and marrying that with the knowledge of threat actor tools, techniques, and processes allows us to gain a deep understanding of the data and the systems we’re looking at. Stringing these anomalies together can then create a pattern of anomalies, helping us form a story using analytical opinions based on facts, also known as the attack narrative.

The ability to identify anomalies makes for an important skill set for an analyst, but understanding the current state is just as crucial. Anomaly-based hunting will be discussed in more detail in the second part of this series when we go into general hunting strategies.

Looking at the current state

If an investigator is lucky enough, they might be dealing with forensic data for the anomaly hunt. But often, there will be times when our observations are limited to the current state of the environment. Even if we don’t have the luxury of historical artifacts, looking at the current state can provide valuable information.

Our proactive Cybersecurity Operations Services prior to an incident allow organizations to gain better knowledge of their current security posture and risk exposure before an incident even occurs.

By understanding the current state and its configurations, you can determine where the potentially malicious or anomalous activity lies as an initial starting point.

Asking questions like “How did it get into that state? Was that it in that state intentionally or was that the result of somebody doing something malicious?” allows our investigators to build from something of interest, look a little bit closer, and then pivot from there until we find true signs of malicious activity.

Looking at the absence of data

The absence of data is just as important as understanding the presence of it. Often, we are provided with data that is lacking or missing, and so the questions gleaned from these observations become: “Why don’t I have that artifact(s)? What didn’t happen? Was it because this data wasn’t recorded? Was the data removed?”

In the absence of data, we also try to determine what could have happened at a given stage of a compromise and what normally happens at that stage. With that information, we try and form our hypothesis about the stages of compromise, if it occurs in an environment. For instance, a customer during an incident response engagement might halt further investigation or response simply because they’re not seeing data exfiltration activity on their sensors and logs.

The approach to understanding the data varies depending on the analyst, but the goal is to answer a series of questions and turn those questions into more questions, and then stop at some point so you can paint the most complete picture possible.

Knowing when to stop

Following an investigative trail results in some form of data aggregation. Knowing when to stop this trail can often be challenging. An indication of knowing when to stop is when the picture doesn’t change even after pulling in more information, leaving you with a nexus of truth about that event or indicator. A comparison to this is the computer science algorithm of depth-first search versus breadth-first search, where investigators can potentially chase one single trail too far, investing too much time on one possible indicator of an attack, and running out of time to investigate other possible indicators. One approach we take to avoid the pitfalls of digging for data is to consult with fellow analysts to get a different perspective to ensure that you are looking at everything from every possible angle. Weighted risk analysis also helps us narrow down what leads to follow. We ask ourselves “what is the probability that a lead I’m investigating will turn out to be malicious?” Multiply that by the potential impact that malicious activity would have. Using that value to rank which leads are most important to follow first helps find higher-risk threats (ransomware, full-domain compromises) faster than low-risk threats (adware, coin miners).

We’ve just described DART’s threat hunting principles and the art form that is understanding the data we’re dealing with when it comes to our incident response work, combing through the data, and creating patterns of suspicious activity by applying critical thinking. In our follow-up post, we will talk about general strategies behind threat hunting and how we work with threat intelligence. Stay tuned.

Learn more

Go to our DART blog series to learn more about the Microsoft Detection and Response Team.

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 The art and science behind Microsoft threat hunting: Part 1 appeared first on Microsoft Security Blog.

Over the past year, the Microsoft Detection and Response Team (DART), along with Microsoft’s threat intelligence teams, have observed an uptick in the use of password sprays as an attack vector. This threat is a moving target with techniques and tools always changing, and Microsoft continues to find new ways to detect these types of attacks and help protect its customers.

In this blog, we are going to define what password sprays are, detail DART’s investigation techniques and approach to responding to password spray attacks, and outline our recommendations for protecting against them.

Why are identity-based attacks suddenly so popular?

Previously, threat actors focused on attacking computers to gain access into an environment. As software becomes more intelligent at detecting abnormal programs and vulnerabilities, attacks against our customers are rapidly becoming more focused on breaking into identities rather than breaking into a network.

The approach to securing user accounts is well-intentioned, but it is often incomplete, with a large investment that typically goes into areas such as complex password policies and limiting access to resources from networks perceived as secure. While these mitigations are necessary best practices, in the case of a compromised trusted user, they are ineffective at preventing unauthorized access.

This is why identity attacks have become so popular. Once attackers have gained the credentials to an account, they can access any sensitive resources that users can access and have the malicious activity appear as normal. This creates a repeating cycle attack pattern, where one compromised account can lead to access to resources where additional credentials can be harvested, and thus even further resource access.

Figure 1. Identity-based attack lifecycle.

The anatomy of a password spray attack

To understand how to protect against, and investigate a password spray attack, it is important to understand what it is. Password spray attacks are authentication attacks that employ a large list of usernames and pair them with common passwords in an attempt to “guess” the correct combination for as many users as possible. These are different from brute-force attacks, which involve attackers using a custom dictionary or wordlist and attempting to attack a small number of user accounts.

Sophisticated password spray techniques include some of the following qualities:

Password spray methods:

• Low and slow: Patience is key for a determined threat actor. The most sophisticated password sprays will use several individual IP addresses to attack multiple accounts at the same time with a limited number of curated password guesses.
• Availability and reuse: With a new breach being announced publicly every month, the amount of compromised credentials posted on the dark web is rising rapidly. Attackers can utilize this tactic, also called “credential stuffing,” to easily gain entry because it relies on people reusing passwords and usernames across sites.

Password spray identifiers:

• User agents: This is not an immutable variable and is simple to spoof, so don’t always rely on the user agent string to tell the truth. That said, some example user agents often seen during a password spray are:
  • BAV2ROPC / CBAinPROD / CBAinTAR: These user agent strings represent a connection from a client that uses legacy authentication, a popular tool for a password spray attack.
  • Firefox/Chrome: More sophisticated password sprays using REST APIs often use headless browsers [a browser that doesn’t have a graphical user interface (GUI)] to target the API endpoints.
  • Python requests package: This is an automation library that can be used to generate requests to a website without user interaction.
• Targets: Password sprays have often targeted applications that are unsecured and use legacy authentication protocols. This is due to the fact that these protocols don’t offer a rich audit trail and are not able to enforce a multifactor authentication (MFA) requirement. More recently, things have changed somewhat, and we are seeing attackers switch to targeting applications that utilize the REST API, often considered to be more secure. Some commonly targeted applications are:
  • Exchange ActiveSync
  • IMAP, POP3, SMTP Auth
  • Exchange Autodiscover

Microsoft has implemented new and improved password spray detections over the last year to help continue to address password spray attacks.

Help! I’ve been sprayed!

DART is no stranger to password spray attacks. When it comes to investigating cybersecurity incidents, our team’s primary goal is to establish the facts and see where they lead us. Here are some of the questions our team typically considers at the start of each password spray attack incident:

• “Was the password spray successful?” This is perhaps the most important question to ask because it determines whether there is potential unauthorized access present in the environment. If it was determined to be successful, the investigator can continue down the list to gain additional information to understand how to proceed.
• “Which users are affected?” Enumerating the users that were victims of the password spray attack can change the direction of our investigation. For example, if the list of users affected is particularly targeted (maybe just in one department or all the staff members of a particular project), we can assume our threat actor knows what they are looking for and has done their research. This helps us adapt an action plan based on the permissions and access rights that a particular user has. We call this “scoping” the incident—in other words, understanding what machines and resources the attackers accessed, and determining the number of compromised users. This knowledge helps us with remediation and preventing attackers from entering the environment again in the future.
• “Were administrative accounts compromised?” If administrative control over a tenant is lost, the situation changes. A compromised tenant is a very different situation from a compromised user and has the potential to be much more damaging, so this is an important distinction for us to make.
• “What indicators do we have?” Information such as the time the spray was conducted, targeted user agent and endpoint, IP addresses, and other identifying information can help us understand if this was carried out by an opportunistic attacker or determined human adversary. There is also the possibility that we can use our threat intelligence to identify some potential next steps our adversary may have taken and the overall scope of compromise.

Our password spray investigations playbook contains in-depth guidance around investigating password spray attacks and offers information about Microsoft Active Directory Federation Services (ADFS), Microsoft’s solution for single sign-on (SSO), and web-based authentication.

Am I a target?

It’s important to understand the targets of the password spray to correctly determine the scope of the potential compromise. Recently, DART has seen an uptick in cloud administrator accounts being targeted in password spray attacks, so understanding the targets is a good place to start. Enumerate the users with the below permissions as the initial list to investigate, and then add users to it as the analysis proceeds:

• Security administrator
• Exchange service administrator
• Global administrator
• Conditional Access administrator
• SharePoint administrator
• Helpdesk administrator
• Billing administrator
• User administrator
• Authentication administrator
• Company administrator

In addition to privileged accounts such as these, identities with a high profile (such as C-level executives), or identities with access to sensitive data are also popular targets. It is easy to make exceptions to policy for staff who are in executive positions, but in reality, these are the most targeted accounts. Be sure to apply protection in a democratic way to avoid creating weak spots in configuration.

How can I check for suspicious activity?

To perform a thorough cloud investigation, exportation of logs and installation of PowerShell modules is inevitable and discussed in detail in our password spray investigation playbook, but there are other methods to gain insights quickly.

Microsoft Cloud App Security

The Microsoft Cloud App Security portal is a great first place to check for suspicious activity. If you have Cloud App Security enabled, follow these steps to check for suspicious activity.

1. Go to the Cloud App Security portal and sign in with the Security Administrator credentials.
2. Go to Alerts.
3. Filter for the users that you enumerated in the first step, check for any alerts associated with these users.

Figure 2. Sample alerts in Cloud App Security related to possible password spray attacks.

Here are some alerts that could be associated with a password spray incident:

• Activity from anonymous IP address.
• Activity from infrequent country.
• Activity from suspicious IP address.
• Impossible travel.

We describe additional Cloud App Security alerts in our documentation.

User investigation priority

For the accounts of interest, check the Cloud App Security investigation priority by navigating to the account under Users and accounts. The investigation priority score is based on security alerts, abnormal activities, and potential business and asset impact related to each user to help you assess how urgent it is to investigate each specific user.

1. Go to the Cloud App Security portal.
2. Go to Investigate then Users and accounts.
3. Check the investigation priority for all users of interest and, if needed, view related activity.

Figure 3. The user page in Cloud App Security shows the investigation priority.

Azure Active Directory

Microsoft Azure Active Directory (Azure AD) incorporates behavioral analysis algorithms into its detection logic natively, so there is a chance that an alert already exists about a password spray attack. Below are several places to check within the portals before going through the hassle of log exporting. Use the indicators of compromise (IOCs) from these alerts to further pivot such as user, IP address, time range, and more.

Identity Protection

Identity Protection is a tool in Azure AD designed to identify potential risky behavior surrounding authentication events. Users with an Azure AD Premium P2 license may follow these steps to check for suspicious activity:

1. Go to the Microsoft Azure portal.
2. Use the search bar to locate Azure AD.
3. Select Security from the left blade.
4. Review the reports under Risky sign-ins and Risky users for any of the users that you enumerated from the list.

Figure 4. Azure AD can display a list of risky sign-ins to identify potential risky behavior.

Revoke user access

If an identity is considered compromised, action should be taken immediately to ensure that access is revoked. This should include disabling the user’s device(s), a password reset, account disablement, and token revocation in Azure AD.

Recommendations for protecting against password sprays

Password sprays are worrisome but when we look at the statistics according to the Digital Shadows report “From Exposure to Takeover,” there are over five billion unique credential pairs available for sale worldwide, with new caches of credentials being exposed on a regular basis.¹ This kind of volume tells us that we should assume that a breach will occur and consider that a compromised username or password in any given organization is inevitable.

This doesn’t mean we should give up on passwords altogether, but the rabbit hole of password policies, and the potentially endless discussions about complexity, length, and “correct battery horse staple” (Don’t know what we are talking about? Look it up!) should be avoided in favor of applying Zero Trust logic to identity and authentication. This includes areas like:

• MFA and legacy authentication: You have probably heard this recommendation before: disabling legacy authentication and enabling MFA for all users is a critical step in securing your identity infrastructure and should be a priority if it has not already been done.
• Rethinking the password policy: The future is a world without passwords because it is too common that people reuse them between applications or create easily discoverable passwords. Passwordless authentication methods such as the Microsoft Authenticator App, Windows Hello for Business, and Fast Identity Online (FIDO) keys help improve both the user experience and security level of an authentication event. If a password must be used, ensure that the password policy does not allow key phrases related to the organization or commonly used passwords. Having a password policy of eight characters with an uppercase, lowercase, number, and symbol, is no longer secure with today’s graphics processing unit (GPU) capabilities. Attackers can crack a password with these elements in a matter of hours. 20-character small sentences may be easy for users to remember and are more secure than a complex 8-character password!
• MFA registration: The most effective way to protect against a password spray leading to a successful authentication is by using MFA. However, if the user is enabled for MFA, but never completes the registration process, they are left unprotected. Even worse, if a threat actor signs in and is prompted for MFA, they can register their own MFA details. This is an excellent cover for a threat actor because the authentication event is much less suspicious when MFA is satisfied. DART doesn’t recommend using location-based MFA policies (like only applying MFA when outside the corporate network) as this leaves room for this kind of loophole. Additionally, DART recommends that customers configure an MFA registration policy if possible to ensure that all enabled users register for MFA.
• Mailbox auditing: Use this script to ensure that the recommended mailbox auditing actions are configured on every mailbox in the organization. This ensures that post-exploitation auditing is as robust as possible, allowing for a more effective investigation.
• Administrative accounts: These are the keys to the kingdom and should have an extra level of protection. Ensure that administrative accounts are cloud-only and are not synchronized from Activity Directory. MFA should always be applied, and emergency access accounts should be created also.
• Policy gaps: Ensuring that weaknesses do not exist in your identity policies and processes is critical. All too often, DART finds that small misconfigurations can lead to an entry point for a threat actor. Let’s explore this idea further:
  • Conditional Access policies: These policies are a great way to apply access control logic to complex environments, helping customers walk the tightrope between protecting the organization and allowing staff to get on with their jobs. With complexity comes risk, and as previously mentioned, misconfigurations are all too common. Some pitfalls to watch out for:
    • Cloud Apps: Let’s look at a real-world example. A DART customer experienced a cloud identity breach and had in place an MFA policy for administrative accounts, applied to the Office 365 cloud app. However, the threat actor used the Azure Service Management API to connect to the environment. This cloud app was outside of the scope of the MFA Conditional Access policy, giving the threat actor access to the environment without requiring MFA. Make sure to have in place a Conditional Access policy that covers all cloud apps and applies MFA to give you a base level of protection.

Figure 5. Conditional Access policy in Azure AD.

• • • Policy exceptions: During day-to-day operations, changes are often made to a product configuration to facilitate business functions. One typical example of this kind of change is an account being removed or exempted from a security policy. This is something to be careful of—policy exceptions often begin as a temporary change but end up being permanent for one reason or another. It is also not uncommon for DART to observe exceptions for sensitive or high-profile accounts; the very type of account that makes an ideal target for cybercriminals. Use processes and technical solutions to ensure those policy exceptions are temporary and tracked. If they must remain, put in place some mitigating controls to reduce the attack surface of that particular account.

Assume breach

Password spray attacks are the perfect combination of low effort and high value for attackers, and even the most secure companies are likely to fall victim to them. However, preventing catastrophic damage is not a hopeless endeavor. By assessing both sides of the situation, the protection against the attack as well as the capabilities to investigate and remediate an attack, you can ensure a substantial amount of coverage against password spray destruction.

DART utilizes these strategies for everyday investigations. We encourage our customers to adopt passwordless technology and enable MFA, regardless of the provider. While attackers are most likely continuously exploring new ways to break into an environment, by assuming breach, we can help to safeguard against inevitable detrimental harm.

Learn more

Want to learn more about DART? Read our past blog posts.

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.

 

---

¹From Exposure to Takeover: The 15 billion stolen credentials allowing account takeover, Digital Shadows Photon Research Team, Digital Shadows.

The post Protect your business from password sprays with Microsoft DART recommendations appeared first on Microsoft Security Blog.

This blog is part two of a two-part series focused on how Microsoft DART helps customers with human-operated ransomware. For more guidance on human-operated ransomware and how to defend against these extortion-based attacks, refer to our human-operated ransomware docs page.

In part one of this blog series, we described the process and execution used in our customer engagements to provide perspective on the unique issues and challenges regarding human-operated ransomware. We also explained how Microsoft’s Detection and Response Team (DART) leverages Microsoft solutions to help combat this threat. In this post, we will tackle the risks of human-operated ransomware and detail DART’s security recommendations for tactical containment actions and post-incident activities in the event of an attack.

Understanding the risks of human-operated ransomware

Beyond the immediate threat of file encryption, there are several additional risks associated with human-operated ransomware events, some of which may be observed well after an investigation and the removal of the threat from the network. These risks include:

1. Disruption of business operations

Immediate actions need to be taken to reduce the blast radius of a ransomware event. In these cases, disabling portions of the network may feel like a self-inflicted denial of service, but they are necessary to counter the ransomware spread. The resulting business disruption may become public. If any affected systems are public-facing, it may require crisis communications.

2. Data theft

Most attackers are highly motivated to monetize their access to your network. In several cases investigated by DART, an attacker has performed reconnaissance for sensitive files (like contracts, financial documents, and internal communications), copied this data, and exfiltrated it before any ransomware was dropped. Taking this information before ransomware is deployed allows the attacker to have data to sell, leak, or simply show as proof that the attacker has had access to sensitive files.

3. Extortion

Data theft by ransomware operators opens an organization to extortion. It is not uncommon for threat actors to demand payment to prevent the leak of stolen data. These threats are typically sent via email with sample stolen documents attached as proof of possession. In some cases where DART has observed this activity, a threat actor accessed a cloud-based email account that was not protected by multifactor authentication (MFA) and sent threatening emails to the board of directors. The threat of extortion is still high, even when the threat actors are unsuccessful at deploying ransomware.

At DART, we often get asked, “Can you tell us which data was stolen?” To prove this requires concrete evidence, which would be either:

• A network capture that shows the actual data leaving the network (which rarely exists).

Or

• Finding the data outside the organization’s network, typically on a public file-sharing site. A log file showing ‘x’ bytes were transferred does not prove what data was stolen, and a command line history or event log showing a file archiving utility was run does not prove that data was stolen.

4. Follow-on attacks

To further their monetization efforts, attackers are also often observed deploying coin miners in compromised networks. This is a low-effort method to generate additional income from a victim organization when data theft or extortion are insufficient for the attacker. Depending on the attacker’s motivation, additional malware may be deployed that would allow other criminals to gain access to the environment. This access is monetized, and the sale of compromised network access is common in most human-operated ransomware cases, performed after the primary attacker has obtained what they initially sought.

5. Reputational damage

The risk of brand damage reputation is difficult to assess in the aftermath of a human-operated ransomware event. The reputation of an organization’s brand may include lost customer and shareholder trust and loyalty, as well as current and future business. The risk of brand damage reputation is difficult to assess in the aftermath of a human-operated ransomware event. Reputational damage may be more costly and require longer-term solutions than the response to the human-operated ransomware event.

6. Compliance and regulatory reporting

Potential reporting requirements are another organizational risk depending on the industry or affiliation. This may include compliance or regulatory reporting in cases where sensitive financial information or personally identifiable information (PII) is stolen. Fines and loss of accreditation may further damage an organization’s reputation.

Recommendations and best practices

Containment

Containment can only happen once we determine what needs to be contained. In the case of ransomware, the adversary’s goal is to obtain credentials that allow administrative control over a highly available server and then deploy the ransomware. In some cases, the threat actor identifies sensitive data and exfiltrates it to a location they control.

Tactical recovery will be unique for each customer and tailored to the customer’s environment, industry, and level of IT expertise and experience. The steps outlined below are recommended for short-term and tactical containment steps your organization can take. To learn more about securing privileged access for long-term guidance, visit our securing privileged access docs page. For a comprehensive view of ransomware and extortion and how to protect your organization, you can refer to our human-operated ransomware docs page.

Figure 1. Containment steps that can be done concurrently as new vectors are discovered.

After the first step of containment (assessing the scope of the situation), the second step is to preserve existing systems:

• Disable all privileged user accounts except for a few accounts used by your admins to assist in resetting the integrity of your Microsoft Azure Active Directory (Azure AD) infrastructure. If a user account is believed to be compromised, disable it immediately.
• Isolate compromised systems from the network, but do not shut them off.
• Isolate at least one known good domain controller in every domain—two is even better. Either disconnect them from the network or shut them down entirely. The object here is to stop the spread of ransomware to critical systems—identity being among the most vulnerable. If all your domain controllers are virtual, ensure that the virtualization platform’s system and data drives are backed to offline external media (not connected to the network) in case the virtualization platform itself is compromised.
• Isolate critical known good application servers (for example SAP, configuration management database (CMDB), billing, and accounting systems).

These two steps can be done concurrently as new vectors are discovered. Disable those vectors and then try to find a known good system to isolate from the network.

Other tactical containment actions can be accomplished:

• Reset the krbtgt password, twice in rapid succession. Consider using a scripted, repeatable process. This script enables you to reset the krbtgt account password and related keys while minimizing the likelihood of Kerberos authentication issues being caused by the operation. To minimize potential issues, the krbtgt lifetime can be reduced one or more times prior to the first password reset so that the two resets are done relatively quickly. NOTE: All domain controllers that you plan to keep in your environment must be online.
• Deploy a Group Policy to the entire domain(s) that prevents privileged log on (Domain Admins) to anything but Domain Controllers and privileged administrative-only workstations (if any).
• Install all missing security updates for operating systems and applications. Every missing update is a potential threat vector that adversaries can quickly identify and exploit. Microsoft Defender for Endpoint’s Threat and Vulnerability Management provides an easy way to see exactly what is missing—as well as the potential impact of the missing updates.
  • For Windows 10 (or higher) devices, confirm that the current version (or n-1) is running on every device.
  • Apply attack surface reduction (ASR) rules to prevent malware infection.
  • Enable all Windows 10 security features.
• Check that every external facing application, including VPN access, is protected by multifactor authentication, preferably using an authentication application that is running on a secured device.
• For devices not using Defender for Endpoint as their primary antivirus software, run a full scan with Microsoft Safety Scanner on isolated “known good” systems before reconnecting them to the network.
• For any legacy operating systems, upgrade to a supported OS or decommission these devices. If these options are not available, take every possible measure to isolate these devices, including network/VLAN isolation, IPsec rules, and log on restrictions, so they are only accessible to the applications by the users/devices to provide business continuity.

DART sometimes finds customers who are running mission critical systems on legacy operating systems (some as old as Windows NT 4) and applications, all on legacy hardware. This is one of the riskiest configurations possible—not only are these operating systems and applications insecure, if that hardware fails, backups typically cannot be restored on modern hardware. Unless replacement legacy hardware is available, these applications will cease to function.

Post-incident activities

DART recommends implementing the following security recommendations and best practices after each incident.

• Ensure that best practices are in place for email and collaboration solutions to make it more difficult for attackers to abuse them while allowing internal users to access external content easily and safely.
• Follow Zero Trust security best practices for remote access solutions to internal organizational resources.
• Starting with critical impact administrators, follow best practices for account security including using passwordless or MFA.
• Implement a comprehensive strategy to reduce the risk of privileged access compromise.
  • For cloud and forest/domain administrative access, see below for an overview of Microsoft’s privileged access model (PAM).
  • For endpoint administrative management, see below for details on the local administrative password solution (LAPS).
• Implement data protection to block ransomware techniques and to confirm rapid and reliable recovery from an attack.
• Review your critical systems. Check for protection and backups against deliberate attacker erasure/encryption. It’s important that these backups are periodically tested and validated.
• Ensure rapid detection and remediation of common attacks on endpoint, email, and identity.
• Actively discover and continuously improve the security posture of your environment.
• Update organizational processes to manage major ransomware events and streamline outsourcing to avoid friction.

Privileged access model (PAM)

Using the privileged access model (formerly known as the tiered administration model) enhances Azure AD’s security posture. This involves:

• Breaking out administrative accounts in a “Planed” environment—one account for each level, usually four:
  • Control Plane (formerly Tier 0): Administration of Domain Controllers and other crucial identity services (like Active Directory Federation Service (ADFS) or Azure AD Connect). This also includes applications that require administrative permissions to Azure AD, such as Exchange Server.
  • The next two Planes were formerly Tier 1:
    • Management Plane: Asset management, monitoring, and security.
    • Data/Workload Plane: Applications and application servers.
  • The next two Planes were formerly Tier 2:
    • User Access: Access rights for users (such as accounts).
    • App Access: Access rights for applications.
• Each one of these Planes will have a separate administrative workstation for each Plane and will only have access to systems in that Plane. Other accounts from other Planes will be denied access to workstations and servers in the other Planes through user rights assignments set to those machines.
• The net result of the PAM is that:
  • A compromised user account will only have access to the Plane it is a part of.
  • More sensitive user accounts will not be logging into workstations and servers with a lower Plane’s security level, thereby reducing lateral movement.

Local Administrative Password Solution (LAPS)

By default, Microsoft Windows and Azure AD have no centralized management of local administrative accounts on workstations and member servers. This usually results in a common password that is given for all these local accounts, or at the very least in groups of machines. This enables would-be attackers to compromise one local administrator account, and then use that account to gain access to other workstations or servers in the organization.

Microsoft’s Local Administrator Password Solution (LAPS) mitigates this by using a Group Policy client-side extension that changes the local administrative password at regular intervals on workstations and servers according to the policy set. Each of these passwords are different and stored as an attribute in the Azure AD computer object. This attribute can be retrieved from a simple client application, depending on the permissions assigned to that attribute.

LAPS requires the Azure AD schema to be extended to allow for the additional attribute, the LAPS Group Policy templates to be installed, and a small client-side extension to be installed on every workstation and member server to provide the client-side functionality.

Download LAPS from the official Microsoft Download Center.

Harden your environment

Each ransomware case is different and there is no one-size-fits-all approach. But there are things you can do now to harden your environment and prepare for a worst-case scenario. Although, these changes may impact how your organization currently works, consider the risk of not implementing them now versus dealing with a potential human-operated ransomware event. An organization that has fallen victim to a ransomware attack should keep the crucial human element in mind—real people are responding to the incident at the end of the day.

Learn more

Want to learn more about DART? Read our past blog posts.

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 A guide to combatting human-operated ransomware: Part 2 appeared first on Microsoft Security Blog.

This blog is part one of a two-part series focused on how Microsoft DART helps customers with human-operated ransomware. For more guidance on human-operated ransomware and how to defend against these extortion-based attacks, refer to our human-operated ransomware docs page.

Microsoft’s Detection and Response Team (DART) has helped customers of all sizes, across many industries and regions, investigate and remediate human-operated ransomware for over five years. This blog aims to explain the process and execution used in our customer engagements to provide perspective on the unique issues and challenges regarding human-operated ransomware. We will also discuss how DART leverages Microsoft solutions such as Microsoft Defender for Endpoint, Microsoft Defender for Identity, and Microsoft Cloud App Security (MCAS) within customer environments while collaborating with cross-functional threat intelligence teams across Microsoft who similarly track human-operated ransomware activities and behaviors.

Human-operated ransomware is not a malicious software problem—it’s a human criminal problem. The solutions used to address commodity problems aren’t enough to prevent a threat that more closely resembles a nation-state threat actor. It disables or uninstalls your antivirus software before encrypting files. They locate and corrupt or delete backups before sending a ransom demand. These actions are commonly done with legitimate programs that you might already have in your environment and are not considered malicious. In criminal hands, these tools are used maliciously to carry out attacks.

Responding to the increasing threat of ransomware requires a combination of modern enterprise configuration, up-to-date security products, and the vigilance of trained security staff to detect and respond to the threats before data is lost.

Key steps in DART’s approach to conducting ransomware incident investigations

To maximize DART’s efforts to restore business continuity while simultaneously analyzing the details of the incident, a careful and thorough investigation is coordinated with remediation measures to ensure that the root cause is determined. These efforts take place as we assist and advise customers with the task of getting the organization up and running again in a secure manner.

Every effort is made to determine how the adversary gained access to the customer’s assets so that vulnerabilities can be remediated. Otherwise, it is highly likely that the same type of attack will take place again in the future. In some cases, the threat actor takes steps to “cover their tracks” and destroy evidence, so it is possible that the entire chain of events may not be evident.

The following are three key steps in our ransomware investigations:

Figure 1. Key steps in DART’s ransomware investigations.

1. Assess the current situation

This is critical to understanding the scope of the incident and for determining the best people to assist and to plan and scope the investigation and remediation tasks. Asking these initial questions is crucial in helping us determine the situation being dealt with:

What initially made you aware of the ransomware attack?

If the initial threat was identified by IT staff (like noticing backups being deleted, antivirus (AV) alert, endpoint detection and response (EDR) alert, suspicious system changes), it is often possible to take quick decisive measures to thwart the attack, typically by disabling all inbound and outbound internet communication. This may temporarily affect business operations, but that would typically be much less impactful than an adversary deploying ransomware.

If the threat was identified by a user call to the IT helpdesk, there may be enough advance warning to take defensive measures to prevent or minimize the effects of the attack. If the threat was identified by an external entity (like law enforcement or a financial institution), it is likely that the damage is already done, and you will see evidence in your environment that the threat actor has already gained administrative control of your network. This can range from ransomware notes, locked screens, or ransom demands.

What date/time did you first learn of the incident?

Establishing the initial activity date and time is important because it helps narrow the scope of the initial triage for “quick wins.” Additional questions may include:

• What updates were missing on that date? This is important to understand what vulnerabilities may have been exploited by the adversary.
• What accounts were used on that date?
• What new accounts have been created since that date?

What logs (such as AV, EDR, and VPN) are available, and is there any indication that the actor is currently accessing systems?

Logs are an indicator of suspected compromise. Follow-up questions may include:

• Are logs being aggregated in a SIEM (like Microsoft Azure Sentinel, Splunk, ArcSight) and current? What is the retention period of this data?
• Are there any suspected compromised systems that are experiencing unusual activity?
• Are there any suspected compromised accounts that appear to be actively used by the adversary?
• Is there any evidence of active command and controls (C2s) in EDR, Firewall, VPN, Proxy, and other logs?

As part of assessing the current situation, DART may require a domain controller (DC) that was not ransomed, a recent backup of a DC, or a recent DC taken offline for maintenance/upgrades. We also ask our customers whether multifactor authentication (MFA) was required for everyone in the company and if Microsoft Azure Active Directory was used.

2. Identify line-of-business (LOB) apps that are unavailable due to the incident

This step is critical in figuring out the quickest way to get systems back online while obtaining the evidence required.

Does the application require an identity?

• How is authentication performed?
• How are credentials such as certificates or secrets stored and managed?

Are tested backups of the application, configuration, and data available?

Are the contents and integrity of backups regularly verified using a restore exercise? This is particularly important after configuration management changes or version upgrades.

3. Explain the compromise recovery (CR) process

This is a follow-up engagement that may be necessary if DART determines that the control plane (typically Active Directory) has been compromised.

DART’s investigation always has a goal of providing output that feeds directly into the CR process. CR is the process by which we remove the nefarious attacker control from an environment and tactically increase security posture within a set period. CR takes place post-security breach. To learn more about CR, read the Microsoft Compromise Recovery Security Practice team’s blog CRSP: The emergency team fighting cyber attacks beside customers.

Once we have gathered the responses to the questions above, we can build a list of tasks and assign owners. A key factor in a successful incident response engagement is thorough, detailed documentation of each work item (such as the owner, status, findings, date, and time), making the compilation of findings at the end of the engagement a straightforward process.

How DART leverages Microsoft security solutions to combat human-operated ransomware

DART leverages cross-functional teams, such as internal threat intelligence teams, who track adversary activities and behaviors, customer support, and product development teams behind Microsoft products and services. DART also collaborates with other incident response vendors the customer may have engaged and will share findings whenever possible.

DART relies heavily on data for all investigations. The team uses existing deployments of Microsoft solutions, such as Defender for Endpoint, Defender for Identity, and MCAS within customer environments along with custom forensic data collection for additional analysis. If these sensors are not deployed, DART also requests that the customer deploy these to gain deeper visibility into the environment, correlate against threat intelligence sources, and enable our analysts to scale in speed and agility.

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint is Microsoft’s enterprise endpoint security platform designed to help enterprise network security analysts prevent, detect, investigate, and respond to advanced threats. As shown in the image below, Defender for Endpoint can detect attacks using advanced behavioral analytics and machine learning. DART analysts use Defender for Endpoint for attacker behavioral analytics.

Figure 2. Sample alert in Microsoft Defender for Endpoint for a pass-the-ticket attack.

DART analysts can also perform advanced hunting queries to pivot off indicators of compromise (IOCs) or search for known behavior if a threat actor group is identified.

Figure 3. Advanced hunting queries to locate known attacker behavior.

In Defender for Endpoint, customers have access to a real-time expert-level monitoring and analysis service by Microsoft Threat Experts for ongoing suspected actor activity. Customers can also collaborate with experts on demand for additional insights into alerts and incidents.

Figure 4. Defender for Endpoint shows detailed ransomware activity.

Microsoft Defender for Identity

DART leverages Microsoft Defender for Identity to investigate known compromised accounts and to find potentially compromised accounts in your organization. Defender for Identity sends alerts for known malicious activity that actors often use such as DCSync attacks, remote code execution attempts, and pass-the-hash attacks. Defender for Identity enables our team to pinpoint nefarious activity and accounts to narrow down our investigation.

Figure 5. Defender for Identity sends alerts for known malicious activity related to ransomware attacks.

Microsoft Cloud App Security

MCAS allows DART analysts to detect unusual behavior across cloud apps to identify ransomware, compromised users, or rogue applications. MCAS is Microsoft’s cloud access security broker (CASB) solution that allows for monitoring of cloud services and data access in cloud services by users.

Figure 6. The Microsoft Cloud App Security dashboard allows DART analysis to detect unusual behavior across cloud apps.

Microsoft Secure Score

The Microsoft 365 Defender stack provides live remediation recommendations to reduce the attack surface. Microsoft Secure Score is a measurement of an organization’s security posture, with a higher number indicating more improvement actions taken. Refer to our documentation to find out more about how your organization can leverage this feature to prioritize remediation actions that are based on their environment.

Understand your business risks

Beyond the immediate risk of encrypted files, understanding the disruption to business operations, data theft, extortion, follow-on attacks, regulatory and compliance reporting, and damage to reputation fall outside technical controls. Microsoft DART recommends each organization weigh these risks when determining the appropriate way to respond based on the organization’s policies, risk appetite, and applicable regulatory requirements.

Microsoft Defender for Endpoint, Microsoft Defender for Identity, and MCAS all work seamlessly together to provide customers with enhanced visibility of the attacker’s actions within and investigate attacks. Given our vast experience and expertise in investigating countless human-operated ransomware events over the past few years, we have shared what we consider best practices.

Learn more

Want to learn more about DART? Read our past blog posts.

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 A guide to combatting human-operated ransomware: Part 1 appeared first on Microsoft Security Blog.

In the last post, we discussed Office 365 and how enabling certain features without understanding all the components can lead to a false sense of security. We demonstrated how implementing a break glass account, multi-factor authentication (MFA), and the removal of legacy authentication can help secure your users and point your organization’s security posture in the right direction. While implementing those controls is an excellent start to hardening your environment, it is just the beginning. Read that blog here.

Security is critical, and any way that we can expedite threat prevention is highly welcomed. What if there was a way to get into a more secure state quickly.  How much time would this give you back to focus your attention on other tasks like actual customers (user base, clients)?

Do you wish there was a quick approach for security configurations in Azure Active Directory (Azure AD) and Office 365? I know I do, and thankfully we have some options here, and they are Secure Score and security defaults. Many of our customers are not aware that these features exist, or if they are aware, they fail to take advantage of using them.

“This blog post will provide an overview of Microsoft Secure Score and security defaults—two features that are easy to utilize and can significantly improve your security in Azure AD and Office 365 configurations.” 

What is Microsoft Secure Score? I am glad you asked

Microsoft Secure Score is a measurement developed to help organizations understand where they are now and the steps needed to improve their security posture. Microsoft Secure Score summarizes the different security features and capabilities currently enabled and provides you with the ability to compare your Score with other companies like yours and identify recommendations for areas of improvement.

Figure 1: Microsoft Secure Score screen image

How does Secure Score help organizations?

Secure Score provides recommendations for protecting your organization from threats. Secure Score will:

• Objectively measure your identity security posture.
• Plan for security improvements.
• Review the success of your improvements.
• The Score can also reflect third-party solutions that have been implemented and have addressed recommended actions.
• The Secure Score reflects new services, thus keeping you up to date with new features and security settings that should be reviewed and if action on your part.

How is the Score determined?

Secure Score compares your organization’s configuration against anonymous data from other organizations with similar features to your organization, such as company size. Each improvement action is worth ten points or less, and most are scored in a binary fashion. If you implement the improvement action, like require MFA for Global Administrators or create a new policy or turn on a specific setting, you get 100 percent of the points. For other improvement actions, points are given as a percentage of the total configuration.

For example, an improvement action states you get ten points by protecting all your users with multi-factor authentication. You only have 50 of 100 total users protected, so that you would get a partial score of five points.

Additionally, your score will drop if routine security tasks are not completed regularly or when security configurations are changed. It will provide directions to the security team about what has changed and the security implications of those changes.

What are security defaults?

Security defaults, a one-click method for enabling basic identity security in an organization, are pre-configured security settings that help defend organizations against frequent identity-related attacks, such as password spray, replay, and phishing. Some of the critical features of Security Defaults include:

• Requiring all users to register for Azure AD Multi-Factor Authentication (MFA) using the Microsoft Authenticator app.
• Requiring administrators to perform multi-factor authentication.
• Blocking legacy authentication protocols.
• Requiring users to perform multi-factor authentication when necessary.
• Protecting privileged activities like access to the Azure portal.

When should you use security defaults?

It would be best if you used security defaults in the following cases:

• If you want to increase the overall security posture and don’t know how or where to start, security defaults are for you.
• If you are using the free tier of Azure Active Directory licensing, security defaults are for you.

How is the Score determined?

Microsoft Secure Score has recently added improvement actions to support security defaults in Azure Active Directory, making it easier to help protect your organization with pre-configured security settings for frequent attack vectors.

When you turn on security defaults, you will be awarded full points for the following improvement actions:

• Ensure all users can complete multi-factor authentication for secure access (nine points).
• Require MFA for administrative roles (ten points).
• Enable policy to block legacy authentication (seven points).

Get Started with Microsoft Secure Score and security defaults

Microsoft organizes Secure Score improvement actions into groups to help you focus on what you need to address for your organization:

• Identity (Azure AD accounts and roles).
• Data (Microsoft Information Protection).
• Device (Microsoft Defender ATP, known as Configuration score).
• Application (email and cloud apps, including Office 365 and Microsoft Cloud App Security).
• Infrastructure (no improvement actions for now).

Secure Score

• Start by logging into your Secure Score.
• View your scores and where you need to improve.
• Export all recommendations for your organization and turn this into an attack plan.
• Prioritize the recommendations you will implement over the next 30, 60, 90, and 180 days.
• Pick the tasks that are priorities for your organization and work these into your change control processes.

Security defaults

• Start by logging in to your  Azure portal as a security administrator, Conditional Access administrator, or global administrator.
• Browse to Azure Active Directory, and then Properties.
• Select Manage security defaults.
• Set the Enable security defaults, then toggle to Yes.
• Select Save.

Figure 2:  Enabling security defaults

There are many security enhancements that keep coming to Microsoft’s Cloud stack, so be sure you check your secure Score weekly. As the days go by and new security settings appear, your secure Score will reflect these changes. It is critical to check back often to ensure you are addressing any further recommendations.

Bumps in the road

Microsoft Secure Score and security defaults are straight forward ways to evaluate and improve your Azure AD and Office 365 configurations’ security. Security defaults help implement industry recommended practices, while Microsoft Secure Score creates a hands-on interface that simplifies the ongoing process of security assessment and improvement.

Our upcoming blog will explore the necessary built-in Azure tooling and open-source options that an organization can employ during investigative scenarios.

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 A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture appeared first on Microsoft Security.

Through difficult times, some adversaries will find opportunities and COVID-19 has proven to be a ripe opportunity for them to target a new, expanding, remote workforce. While these threats morph and evolve, Microsoft’s Detection and Response Team (DART) finds ways to endure and help organizations become more resilient

Cloud environments are continuously being put to the test during this challenging period. DART has seen various security configurations in our customers’ cloud tenants. The one commonality:  administrators flip the switch on a few security tasks without genuinely understanding the process and procedures needed to ensure everything works as designed and consequently create gaps in defenses and opportunities for attackers to circumvent security controls. When it comes to defense-in-depth, these controls must work in concert with one another.

Three measures you should employ to improve the security of your cloud environment

This post describes three security measures you should employ for your Azure AD/Office 365 environment when first setting up a new tenant, or when tightening the reins on a well-established tenant.

1. Create an emergency Global Administration account.
2. Enable Multi-factor Authentication (MFA).
3. Block legacy authentication.

1. Create an emergency Global Administrator account

An emergency Global Administrator account, also known as a “Break Glass Account”, is critical to the overall security posture of your tenant, and it prevents you from being accidentally locked out of your Azure Active Directory (Azure AD). Think about the consequences of your administrators getting locked out; you cannot sign in, activate users, assign licenses, or validate the actions happening in your tenant. Emergency access accounts are highly privileged and not assigned to specific users. These accounts must be excluded from your current security controls, and must have compensatory controls. These controls might include the following:

• Only allowing the “Break Glass Account” to log in from a particular IP address range.
• Implementing detection controls like enhanced alerting and/or monitoring the use of these accounts.

Use of emergency access accounts should be limited to true emergencies, when standard administrative accounts cannot be used. For detailed information, please see  https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-access.

2. Enable Multi-Factor Authentication (MFA)

Enabling MFA seems straightforward, right? Sadly, even today, it isn’t. You allow the Conditional Access Policy for the enablement of MFA, but for the sake of convenience,  permit exclusions to these policies, such as not enabling MFA for the Global Administrators or any of the other O365 workload (Exchange, SharePoint, OneDrive) Administrators and continue to enable Basic/Legacy Authentication. As a result, you now host an ineffective policy that puts your organization at tremendous risk. For detailed information, please see  https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa.

Real-World Scenario—A large company enabled MFA for all global administrators. Unbeknownst to the rest of the team, a user modified the policy to exclude a global administrator account. This user’s act put the company at considerable risk; the account was eventually compromised using a trivial Password Spray attack. It is bad enough when a standard user with no elevated privileges is compromised— Global Administrator accounts have access to all of Azure AD and Office 365, so when this account was affected, the organization’s entire tenant was compromised. Monitoring and alerting for the implementation of persistence mechanisms, such as the creation of a new mailbox forwarding rule, would have also triggered a security alert and a full incident response investigation of the modified tenant. This incident also could have been easily avoided by merely monitoring and alerting for the creation of Global Administrator accounts and any changes to these accounts. The threat actor has leveraged all these techniques to essentially gain and maintain access to the organization’s tenant to achieve their mission objective for data exposure and exfiltration.

3. Block Legacy Authentication

Legacy authentication refers to protocols that use basic authentication, such as Exchange Web Services (EWS), POP, SMTP, IMAP, and MAPI. These protocols cannot enforce any type of second-factor authentication (e.g., MFA), which makes them a popular entry point for bad actors. As such, for MFA to be useful, you also need to block legacy authentication.

There are still risks once you’ve disabled legacy authentication and enabled MFA. From an operational standpoint, understanding the implications of disabling legacy authentication is critical. You could disrupt essential workflows and disrupt access to applications not written to support modern authentication (including dated Outlook clients).

So, what can you do? Identify which users and applications are currently using legacy authentication in your tenant via Azure AD Sign-in logs. Configure exclusions for applications that cannot be modified to support modern authentication. Also, ensure you configure the policies granularly for more robust security configurations, such as only allowing specific users and a particular IP range to use legacy authentication. This way, you can make access to legacy authentication more stringent where you must use it, and you can block legacy authentication in other scenarios. Configure your conditional access policy to be in a report-only mode to ensure you understand what will happen when you flip on the policy. For more information, please see https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication.

Bricks laid, next: the mortar

There is a multitude of adversary tactics and techniques for the infiltration of a cloud environment. Based on DART’s observations from the frontlines, implementing these three security controls will help ensure the front and back doors to your organization’s cloud environment remain locked. DART recommends assessing these vulnerability points regularly so that when a real threat strikes, your defense-in-depth approach of technical controls, detection-in-depth, and monitoring and alerts will prepare your staff to jump into action quickly.

In an upcoming blog post, we’ll dive into what we like to call the “Easy Button” approach to security defaults. These pre-configured security settings help defend your organization against frequent identity-related attacks, such as password spray, replay, and phishing, and provide additional mortar towards the security foundation of your cloud environment.

Want to learn more about DART (Detection and Response Team)? Read our past blog posts here.

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 Microsoft Office 365—Do you have a false sense of cloud security? appeared first on Microsoft Security.

Through difficult times, some adversaries will find opportunities and COVID-19 has proven to be a ripe opportunity for them to target a new, expanding, remote workforce. While these threats morph and evolve, Microsoft’s Detection and Response Team (DART) finds ways to endure and help organizations become more resilient

Cloud environments are continuously being put to the test during this challenging period. DART has seen various security configurations in our customers’ cloud tenants. The one commonality:  administrators flip the switch on a few security tasks without genuinely understanding the process and procedures needed to ensure everything works as designed and consequently create gaps in defenses and opportunities for attackers to circumvent security controls. When it comes to defense-in-depth, these controls must work in concert with one another.

Three measures you should employ to improve the security of your cloud environment

This post describes three security measures you should employ for your Azure AD/Office 365 environment when first setting up a new tenant, or when tightening the reins on a well-established tenant.

1. Create an emergency Global Administration account.
2. Enable Multi-factor Authentication (MFA).
3. Block legacy authentication.

1. Create an emergency Global Administrator account

An emergency Global Administrator account, also known as a “Break Glass Account”, is critical to the overall security posture of your tenant, and it prevents you from being accidentally locked out of your Azure Active Directory (Azure AD). Think about the consequences of your administrators getting locked out; you cannot sign in, activate users, assign licenses, or validate the actions happening in your tenant. Emergency access accounts are highly privileged and not assigned to specific users. These accounts must be excluded from your current security controls, and must have compensatory controls. These controls might include the following:

• Only allowing the “Break Glass Account” to log in from a particular IP address range.
• Implementing detection controls like enhanced alerting and/or monitoring the use of these accounts.

Use of emergency access accounts should be limited to true emergencies, when standard administrative accounts cannot be used. For detailed information, please see  https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-access.

2. Enable Multi-Factor Authentication (MFA)

Enabling MFA seems straightforward, right? Sadly, even today, it isn’t. You allow the Conditional Access Policy for the enablement of MFA, but for the sake of convenience,  permit exclusions to these policies, such as not enabling MFA for the Global Administrators or any of the other O365 workload (Exchange, SharePoint, OneDrive) Administrators and continue to enable Basic/Legacy Authentication. As a result, you now host an ineffective policy that puts your organization at tremendous risk. For detailed information, please see  https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa.

Real-World Scenario—A large company enabled MFA for all global administrators. Unbeknownst to the rest of the team, a user modified the policy to exclude a global administrator account. This user’s act put the company at considerable risk; the account was eventually compromised using a trivial Password Spray attack. It is bad enough when a standard user with no elevated privileges is compromised— Global Administrator accounts have access to all of Azure AD and Office 365, so when this account was affected, the organization’s entire tenant was compromised. Monitoring and alerting for the implementation of persistence mechanisms, such as the creation of a new mailbox forwarding rule, would have also triggered a security alert and a full incident response investigation of the modified tenant. This incident also could have been easily avoided by merely monitoring and alerting for the creation of Global Administrator accounts and any changes to these accounts. The threat actor has leveraged all these techniques to essentially gain and maintain access to the organization’s tenant to achieve their mission objective for data exposure and exfiltration.

3. Block Legacy Authentication

Legacy authentication refers to protocols that use basic authentication, such as Exchange Web Services (EWS), POP, SMTP, IMAP, and MAPI. These protocols cannot enforce any type of second-factor authentication (e.g., MFA), which makes them a popular entry point for bad actors. As such, for MFA to be useful, you also need to block legacy authentication.

There are still risks once you’ve disabled legacy authentication and enabled MFA. From an operational standpoint, understanding the implications of disabling legacy authentication is critical. You could disrupt essential workflows and disrupt access to applications not written to support modern authentication (including dated Outlook clients).

So, what can you do? Identify which users and applications are currently using legacy authentication in your tenant via Azure AD Sign-in logs. Configure exclusions for applications that cannot be modified to support modern authentication. Also, ensure you configure the policies granularly for more robust security configurations, such as only allowing specific users and a particular IP range to use legacy authentication. This way, you can make access to legacy authentication more stringent where you must use it, and you can block legacy authentication in other scenarios. Configure your conditional access policy to be in a report-only mode to ensure you understand what will happen when you flip on the policy. For more information, please see https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication.

Bricks laid, next: the mortar

There is a multitude of adversary tactics and techniques for the infiltration of a cloud environment. Based on DART’s observations from the frontlines, implementing these three security controls will help ensure the front and back doors to your organization’s cloud environment remain locked. DART recommends assessing these vulnerability points regularly so that when a real threat strikes, your defense-in-depth approach of technical controls, detection-in-depth, and monitoring and alerts will prepare your staff to jump into action quickly.

In an upcoming blog post, we’ll dive into what we like to call the “Easy Button” approach to security defaults. These pre-configured security settings help defend your organization against frequent identity-related attacks, such as password spray, replay, and phishing, and provide additional mortar towards the security foundation of your cloud environment.

Want to learn more about DART (Detection and Response Team)? Read our past blog posts here.

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 Microsoft Office 365—Do you have a false sense of cloud security? appeared first on Microsoft Security.

Your network is unique. It’s a living, breathing system evolving over time. Data is created. Data is processed. Data is accessed. Data is manipulated. Data can be forgotten. The applications and users performing these actions are all unique parts of the system, adding degrees of disorder and entropy to your operating environment. No two networks on the planet are exactly the same, even if they operate within the same industry, utilize the exact same applications, and even hire workers from one another. In fact, the only attribute your network may share with another network is simply how unique they are from one another.

If we follow the analogy of an organization or network as a living being, it’s logical to drill down deeper, into the individual computers, applications, and users that function as cells within our organism. Each cell is unique in how it’s configured, how it operates, the knowledge or data it brings to the network, and even the vulnerabilities each piece carries with it. It’s important to note that cancer begins at the cellular level and can ultimately bring down the entire system. But where incident response and recovery are accounted for, the greater the level of entropy and chaos across a system, the more difficult it becomes to locate potentially harmful entities. Incident Response is about locating the source of cancer in a system in an effort to remove it and make the system healthy once more.

Let’s take the human body for example. A body that remains at rest 8-10 hours a day, working from a chair in front of a computer, and with very little physical activity, will start to develop health issues. The longer the body remains in this state, the further it drifts from an ideal state, and small problems begin to manifest. Perhaps it’s diabetes. Maybe it’s high blood pressure. Or it could be weight gain creating fatigue within the joints and muscles of the body. Your network is similar to the body. The longer we leave the network unattended, the more it will drift from an ideal state to a state where small problems begin to manifest, putting the entire system at risk.

Why is this important? Let’s consider an incident response process where a network has been compromised. As a responder and investigator, we want to discover what has happened, what the cause was, what the damage is, and determine how best we can fix the issue and get back on the road to a healthy state. This entails looking for clues or anomalies; things that stand out from the normal background noise of an operating network. In essence, let’s identify what’s truly unique in the system, and drill down on those items. Are we able to identify cancerous cells because they look and act so differently from the vast majority of the other healthy cells?

Consider a medium-size organization with 5,000 computer systems. Last week, the organization was notified by a law enforcement agency that customer data was discovered on the dark web, dated from two weeks ago. We start our investigation on the date we know the data likely left the network. What computer systems hold that data? What users have access to those systems? What windows of time are normal for those users to interact with the system? What processes or services are running on those systems? Forensically we want to know what system was impacted, who was logging in to the system around the timeframe in question, what actions were performed, where those logins came from, and whether there are any unique indicators. Unique indicators are items that stand out from the normal operating environment. Unique users, system interaction times, protocols, binary files, data files, services, registry keys, and configurations (such as rogue registry keys).

Our investigation reveals a unique service running on a member server with SQL Server. In fact, analysis shows that service has an autostart entry in the registry and starts the service from a file in the c:\windows\perflogs directory, which is an unusual location for an autostart, every time the system is rebooted. We haven’t seen this service before, so we investigate against all the systems on the network to locate other instances of the registry startup key or the binary files we’ve identified. Out of 5,000 systems, we locate these pieces of evidence on only three systems, one of which is a Domain Controller.

This process of identifying what is unique allows our investigative team to highlight the systems, users, and data at risk during a compromise. It also helps us potentially identify the source of attacks, what data may have been pilfered, and foreign Internet computers calling the shots and allowing access to the environment. Additionally, any recovery efforts will require this information to be successful.

This all sounds like common sense, so why cover it here? Remember we discussed how unique your network is, and how there are no other systems exactly like it elsewhere in the world? That means every investigative process into a network compromise is also unique, even if the same attack vector is being used to attack multiple organizational entities. We want to provide the best foundation for a secure environment and the investigative process, now, while we’re not in the middle of an active investigation.

The unique nature of a system isn’t inherently a bad thing. Your network can be unique from other networks. In many cases, it may even provide a strategic advantage over your competitors. Where we run afoul of security best practice is when we allow too much entropy to build upon the network, losing the ability to differentiate “normal” from “abnormal.” In short, will we be able to easily locate the evidence of a compromise because it stands out from the rest of the network, or are we hunting for the proverbial needle in a haystack? Clues related to a system compromise don’t stand out if everything we look at appears abnormal. This can exacerbate an already tense response situation, extending the timeframe for investigation and dramatically increasing the costs required to return to a trusted operating state.

To tie this back to our human body analogy, when a breathing problem appears, we need to be able to understand whether this is new, or whether it’s something we already know about, such as asthma. It’s much more difficult to correctly identify and recover from a problem if it blends in with the background noise, such as difficulty breathing because of air quality, lack of exercise, smoking, or allergies. You can’t know what’s unique if you don’t already know what’s normal or healthy.

To counter this problem, we pre-emptively bring the background noise on the network to a manageable level. All systems move towards entropy unless acted upon. We must put energy into the security process to counter the growth of entropy, which would otherwise exponentially complicate our security problem set. Standardization and control are the keys here. If we limit what users can install on their systems, we quickly notice when an untrusted application is being installed. If it’s against policy for a Domain Administrator to log in to Tier 2 workstations, then any attempts to do this will stand out. If it’s unusual for Domain Controllers to create outgoing web traffic, then it stands out when this occurs or is attempted.

Centralize the security process. Enable that process. Standardize security configuration, monitoring, and expectations across the organization. Enforce those standards. Enforce the tenet of least privilege across all user levels. Understand your ingress and egress network traffic patterns, and when those are allowed or blocked.

In the end, your success in investigating and responding to inevitable security incidents depends on what your organization does on the network today, not during an active investigation. By reducing entropy on your network and defining what “normal” looks like, you’ll be better prepared to quickly identify questionable activity on your network and respond appropriately. Bear in mind that security is a continuous process and should not stop. The longer we ignore the security problem, the further the state of the network will drift from “standardized and controlled” back into disorder and entropy. And the further we sit from that state of normal, the more difficult and time consuming it will be to bring our network back to a trusted operating environment in the event of an incident or compromise.

The post Success in security: reining in entropy appeared first on Microsoft Security.

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

COVID-19 and the SOC

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

A day in the life—remediation

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

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

Big Bang or clean as you go?

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

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

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

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

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

Automation and integration for the win

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

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

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

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

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

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

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

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

Continuous improvement

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

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

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

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

…until then, share and enjoy!

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

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

Recently, an organization in the public sector discovered that one of their internet-facing servers was misconfigured and allowed attackers to upload a web shell, which let the adversaries gain a foothold for further compromise. The organization enlisted the services of Microsoft’s Detection and Response Team (DART) to conduct a full incident response and remediate the threat before it could cause further damage.

DART’s investigation showed that the attackers uploaded a web shell in multiple folders on the web server, leading to the subsequent compromise of service accounts and domain admin accounts. This allowed the attackers to perform reconnaissance using net.exe, scan for additional target systems using nbstat.exe, and eventually move laterally using PsExec.

The attackers installed additional web shells on other systems, as well as a DLL backdoor on an Outlook Web Access (OWA) server. To persist on the server, the backdoor implant registered itself as a service or as an Exchange transport agent, which allowed it to access and intercept all incoming and outgoing emails, exposing sensitive information. The backdoor also performed additional discovery activities as well as downloaded other malware payloads. In addition, the attackers sent special emails that the DLL backdoor interpreted as commands.

Figure 1. Sample web shell attack chain

The case is one of increasingly more common incidents of web shell attacks affecting multiple organizations in various sectors. A web shell is a piece of malicious code, often written in typical web development programming languages (e.g., ASP, PHP, JSP), that attackers implant on web servers to provide remote access and code execution to server functions. Web shells allow adversaries to execute commands and to steal data from a web server or use the server as launch pad for further attacks against the affected organization.

With the use of web shells in cyberattacks on the rise, Microsoft’s DART, the Microsoft Defender ATP Research Team, and the Microsoft Threat Intelligence Center (MSTIC) have been working together to investigate and closely monitor this threat.

Web shell attacks in the current threat landscape

Multiple threat actors, including ZINC, KRYPTON, and GALLIUM, have been observed utilizing web shells in their campaigns. To implant web shells, adversaries take advantage of security gaps in internet-facing web servers, typically vulnerabilities in web applications, for example CVE-2019-0604 or CVE-2019-16759.

In our investigations into these types of attacks, we have seen web shells within files that attempt to hide or blend in by using names commonly used for legitimate files in web servers, for example:

• index.aspx
• fonts.aspx
• css.aspx
• global.aspx
• default.php
• function.php
• Fileuploader.php
• help.js
• write.jsp
• 31.jsp

Among web shells used by threat actors, the China Chopper web shell is one of the most widely used. One example is written in JSP:

We have seen this malicious JSP code within a specially crafted file uploaded to web servers:

Figure 2. Specially crafted image file with malicious JSP code

Another China Chopper variant is written in PHP:

Meanwhile, the KRYPTON group uses a bespoke web shell written in C# within an ASP.NET page:

Figure 3. Web shell written in C# within an ASP.NET page

Once a web shell is successfully inserted into a web server, it can allow remote attackers to perform various tasks on the web server. Web shells can steal data, perpetrate watering hole attacks, and run other malicious commands for further compromise.

Web shell attacks have affected a wide range of industries. The organization in the public sector mentioned above represents one of the most common targeted sectors.

Aside from exploiting vulnerabilities in web applications or web servers, attackers take advantage of other weaknesses in internet-facing servers. These include the lack of the latest security updates, antivirus tools, network protection, proper security configuration, and informed security monitoring. Interestingly, we observed that attacks usually occur on weekends or during off-hours, when attacks are likely not immediately spotted and responded to.

Unfortunately, these gaps appear to be widespread, given that every month, Microsoft Defender Advanced Threat Protection (ATP) detects an average of 77,000 web shell and related artifacts on an average of 46,000 distinct machines.

Figure 3: Web shell encounters 

Detecting and mitigating web shell attacks

Because web shells are a multi-faceted threat, enterprises should build comprehensive defenses for multiple attack surfaces. Microsoft Threat Protection provides unified protection for identities, endpoints, email and data, apps, and infrastructure. Through signal-sharing across Microsoft services, customers can leverage Microsoft’s industry-leading optics and security technologies to combat web shells and other threats.

Gaining visibility into internet-facing servers is key to detecting and addressing the threat of web shells. The installation of web shells can be detected by monitoring web application directories for web script file writes. Applications such as Outlook Web Access (OWA) rarely change after they have been installed and script writes to these application directories should be treated as suspicious.

After installation, web shell activity can be detected by analyzing processes created by the Internet Information Services (IIS) process w3wp.exe. Sequences of processes that are associated with reconnaissance activity such as those identified in the alert screenshot (net.exe, ping.exe, systeminfo.exe, and hostname.exe) should be treated with suspicion. Web applications such as OWA run from well-defined Application Pools. Any cmd.exe process execution by w3wp.exe running from an application pool that doesn’t typically execute processes such as ‘MSExchangeOWAAppPool’ should be treated as unusual and regarded as potentially malicious.

Microsoft Defender ATP exposes these behaviors that indicate web shell installation and post-compromise activity by analyzing script file writes and process executions. When alerted of these activities, security operations teams can then use the rich capabilities in Microsoft Defender ATP to investigate and resolve web shell attacks.

Figure 4. Sample Microsoft Defender ATP alerts related to web shell attacks

Figure 5. Microsoft Defender ATP alert process tree

As in most security issues, prevention is critical. Organizations can harden systems against web shell attacks by taking these preventive steps:

• Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Deploy latest security updates as soon as they become available.
• Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
• Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.
• Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
• Enable cloud-delivered protection to get the latest defenses against new and emerging threats.
• Educate end users about preventing malware infections. Encourage end users to practice good credential hygiene—limit the use of accounts with local or domain admin privileges.

 

 

Detection and Response Team (DART)

Microsoft Defender ATP Research Team

Microsoft Threat Intelligence Center (MSTIC)

 

The post Ghost in the shell: Investigating web shell attacks appeared first on Microsoft Security.

The increased connectivity of computers and the growth of Bring Your Own Device (BYOD) in most organizations is making the distribution of malicious software (malware) easier. Unlike other types of malicious programs that may usually go undetected for a longer period, a ransomware attack is usually experienced immediately, and its impact on information technology infrastructure is often irreversible.

As part of Microsoft’s Detection and Response Team (DART) Incident Response engagements, we regularly get asked by customers about “paying the ransom” following a ransomware attack. Unfortunately, this situation often leaves most customers with limited options, depending on the business continuity and disaster recovery plans they have in place.

The two most common options are either to pay the ransom (with the hopes that the decryption key obtained from the malicious actors works as advertised) or switch gears to a disaster recovery mode, restoring systems to a known good state.

The unfortunate truth about most organizations is that they are often only left with the only option of paying the ransom, as the option to rebuild is taken off the table by lack of known good backups or because the ransomware also encrypted the known good backups. Moreover, a growing list of municipalities around the U.S. has seen their critical infrastructure, as well as their backups, targeted by ransomware, a move by threat actors to better guarantee a payday.

We never encourage a ransomware victim to pay any form of ransom demand. Paying a ransom is often expensive, dangerous, and only refuels the attackers’ capacity to continue their operations; bottom line, this equates to a proverbial pat on the back for the attackers. The most important thing to note is that paying cybercriminals to get a ransomware decryption key provides no guarantee that your encrypted data will be restored.

So, what options do we recommend? The fact remains that every organization should treat a cybersecurity incident as a matter of when it will happen and not whether it will happen. Having this mindset helps an organization react quickly and effectively to such incidents when they happen. Two major industry standard frameworks, the Sysadmin, Audit, Network, and Security (SANS) and the National Institute of Standards and Technology (NIST), both have published similar concepts on responding to malware and cybersecurity incidents. The bottom line is that every organization needs to be able to plan, prepare, respond, and recover when faced with a ransomware attack.

Outlined below are steps designed to help organizations better plan and prepare to respond to ransomware and major cyber incidents.

How to plan and prepare to respond to ransomware

1. Use an effective email filtering solution

According to the Microsoft Security Intelligence Report Volume 24 of 2018, spam and phishing emails are still the most common delivery method for ransomware infections. To effectively stop ransomware at its entry point, every organization needs to adopt an email security service that ensures all email content and headers entering and leaving the organization are scanned for spam, viruses, and other advanced malware threats. By adopting an enterprise-grade email protection solution, most cybersecurity threats against an organization will be blocked at ingress and egress.

2. Regular hardware and software systems patching and effective vulnerability management

Many organizations are still failing to adopt one of the age-old cybersecurity recommendations and important defenses against cybersecurity attacks—applying security updates and patches as soon as the software vendors release them. A prominent example of this failure was the WannaCry ransomware events in 2017, one of the largest global cybersecurity attacks in the history of the internet, which used a leaked vulnerability in Windows networking Server Message Block (SMB) protocol, for which Microsoft had released a patch nearly two months before the first publicized incident. Regular patching and an effective vulnerability management program are important measures to defend against ransomware and other forms of malware and are steps in the right direction to ensure every organization does not become a victim of ransomware.

3. Use up-to-date antivirus and an endpoint detection and response (EDR) solution

While owning an antivirus solution alone does not ensure adequate protection against viruses and other advanced computer threats, it’s very important to ensure antivirus solutions are kept up to date with their software vendors. Attackers invest heavily in the creation of new viruses and exploits, while vendors are left playing catch-up by releasing daily updates to their antivirus database engines. Complementary to owning and updating an antivirus solution is the use of EDR solutions that collect and store large volumes of data from endpoints and provide real-time host-based, file-level monitoring and visibility to systems. The data sets and alerts generated by this solution can help to stop advanced threats and are often leveraged for responding to security incidents.

4. Separate administrative and privileged credentials from standard credentials

Working as a cybersecurity consultant, one of the first recommendations I usually provide to customers is to separate their system administrative accounts from their standard user accounts and to ensure those administrative accounts are not useable across multiple systems. Separating these privileged accounts not only enforces proper access control but also ensures that a compromise of a single account doesn’t lead to the compromise of the entire IT infrastructure. Additionally, using Multi-Factor Authentication (MFA), Privileged Identity Management (PIM), and Privileged Access Management (PAM) solutions are ways to effectively combat privileged account abuse and a strategic way of reducing the credential attack surface.

5. Implement an effective application whitelisting program

It’s very important as part of a ransomware prevention strategy to restrict the applications that can run within an IT infrastructure. Application whitelisting ensures only applications that have been tested and approved by an organization can run on the systems within the infrastructure. While this can be tedious and presents several IT administrative challenges, this strategy has been proven effective.

6. Regularly back up critical systems and files

The ability to recover to a known good state is the most critical strategy of any information security incident plan, especially ransomware. Therefore, to ensure the success of this process, an organization must validate that all its critical systems, applications, and files are regularly backed up and that those backups are regularly tested to ensure they are recoverable. Ransomware is known to encrypt or destroy any file it comes across, and it can often make them unrecoverable; consequently, it’s of utmost importance that all impacted files can be easily recovered from a good backup stored at a secondary location not impacted by the ransomware attack.

Learn more and keep updated

Learn more about how DART helps customers respond to compromises and become cyber-resilient. 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 Ransomware response—to pay or not to pay? appeared first on Microsoft Security.