Archive

Archive for the ‘Detection and Response Team (DART)’ Category

Protect your business from password sprays with Microsoft DART recommendations

October 26th, 2021 No comments

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.

Graphic shows a repeating identity-based attack lifecycle pattern.

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.

Screenshot showing sample alerts in the Microsoft Cloud App Security alerts page.

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.

Screenshot displays a sample investigation priority page in Microsoft Cloud App Security.

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.

Screenshot shows the risky sign-ins page in the Microsoft Azure portal.

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.1 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.

Screenshot showing how to configure the Conditional Access policy in Azure AD.

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.

 


1From 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.

A guide to combatting human-operated ransomware: Part 2

September 27th, 2021 No comments

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.

Graphic outlines DART’s containment steps, which cover assessing the scope of the situation and preserving existing systems.

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.
  • 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.

A guide to combatting human-operated ransomware: Part 1

September 20th, 2021 No comments

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:

Graphic illustrates the steps, goals, and initial questions in DART’s ransomware investigation assistance.

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.

Screengrab from the Microsoft Defender Security Center that shows a pass-the-ticket attack alert.

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.

Screengrab from the Microsoft Defender Security Center that shows advanced hunting, a query-based threat hunting tool.

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.

Screengrab from the Microsoft Defender Security Center that shows sample ransomware alerts.

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.

Screengrab of alerts in Microsoft Defender for Identity showing malicious activity related to ransomware attacks.

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.

Screengrab of the Microsoft Cloud App Security dashboard showing open alerts and a sample list of users to investigate.

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.

A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture

December 17th, 2020 No comments

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.

Microsoft Secure Score screen image

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.

Enabling security defaults

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.

Microsoft Office 365—Do you have a false sense of cloud security?

August 11th, 2020 No comments

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.

Microsoft Office 365—Do you have a false sense of cloud security?

August 11th, 2020 No comments

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.

Success in security: reining in entropy

May 20th, 2020 No comments

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.

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

May 5th, 2020 No comments

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

COVID-19 and the SOC

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

A day in the life—remediation

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

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

Big Bang or clean as you go?

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

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

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

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

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

Automation and integration for the win

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

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

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

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

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

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

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

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

Continuous improvement

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

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

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

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

…until then, share and enjoy!

P.S. If you are looking for more information on the SOC and other cybersecurity topics, check out previous entries in the series (Part 1 | Part 2a | Part 2b | Part 3a | Part 3b), Mark’s List (https://aka.ms/markslist), and our new security documentation site—https://aka.ms/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.

Ghost in the shell: Investigating web shell attacks

February 4th, 2020 No comments

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.

Ransomware response—to pay or not to pay?

December 16th, 2019 No comments

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.