Archive

Archive for the ‘Incident response’ Category

Token tactics: How to prevent, detect, and respond to cloud token theft

November 16th, 2022 No comments

As organizations increase their coverage of multifactor authentication (MFA), threat actors have begun to move to more sophisticated techniques to allow them to compromise corporate resources without needing to satisfy MFA. Recently, the Microsoft Detection and Response Team (DART) has seen an increase in attackers utilizing token theft for this purpose. By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. This poses to be a concerning tactic for defenders because the expertise needed to compromise a token is very low, is hard to detect, and few organizations have token theft mitigations in their incident response plan.

Why it matters

In the new world of hybrid work, users may be accessing corporate resources from personally owned or unmanaged devices which increases the risk of token theft occurring. These unmanaged devices likely have weaker security controls than those that are managed by organizations, and most importantly, are not visible to corporate IT. Users on these devices may be signed into both personal websites and corporate applications at the same time, allowing attackers to compromise tokens belonging to both.

As far as mitigations go, publicly available open-source tools for exploiting token theft already exist, and commodity credential theft malware has already been adapted to include this technique in their arsenal. Detecting token theft can be difficult without the proper safeguards and visibility into authentication endpoints. Microsoft DART aims to provide defenders with the knowledge and strategies necessary to mitigate this tactic until permanent solutions become available.

Tokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a resource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that token, the user must sign into Azure AD using their credentials. At that point, depending on policy, they may be required to complete MFA. The user then presents that token to the web application, which validates the token and allows the user access.

Flowchart for Azure Active Directory issuing tokens.
Figure 1. OAuth Token flow chart

When Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA, and more. It also includes any privilege a user has in Azure AD. If you sign in as a Global Administrator to your Azure AD tenant, then the token will reflect that. Two of the most common token theft techniques DART has observed have been through adversary-in-the-middle (AitM) frameworks or the utilization of commodity malware (which enables a ‘pass-the-cookie’ scenario).

With traditional credential phishing, the attacker may use the credentials they have compromised to try and sign in to Azure AD. If the security policy requires MFA, the attacker is halted from being able to successfully sign in. Though the users’ credentials were compromised in this attack, the threat actor is prevented from accessing organizational resources.

Flowchart describing how credential phishing attacks are mitigated by multifactor authentication.
Figure 2. Common credential phishing attack mitigated by MFA

Adversary-in-the-middle (AitM) phishing attack

Attacker methodologies are always evolving, and to that end DART has seen an increase in attackers using AitM techniques to steal tokens instead of passwords. Frameworks like Evilginx2 go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token.

Flowchart describing how an adversary in the middle attack works.
Figure 3. Adversary-in-the-middle (AitM) attack flowchart

If a regular user is phished and their token stolen, the attacker may attempt business email compromise (BEC) for financial gain. If a token with Global Administrator privilege is stolen, then they may attempt to take over the Azure AD tenant entirely, resulting in loss of administrative control and total tenant compromise.

Pass-the-cookie attack

A “pass-the-cookie” attack is a type of attack where an attacker can bypass authentication controls by compromising browser cookies. At a high level, browser cookies allow web applications to store user authentication information. This allows a website to keep you signed in and not constantly prompt for credentials every time you click a new page.

“Pass-the-cookie” is like pass-the-hash or pass-the-ticket attacks in Active Directory. After authentication to Azure AD via a browser, a cookie is created and stored for that session. If an attacker can compromise a device and extract the browser cookies, they could pass that cookie into a separate web browser on another system, bypassing security checkpoints along the way. Users who are accessing corporate resources on personal devices are especially at risk. Personal devices often have weaker security controls than corporate-managed devices and IT staff lack visibility to those devices to determine compromise. They also have additional attack vectors, such as personal email addresses or social media accounts users may access on the same device. Attackers can compromise these systems and steal the authentication cookies associated with both personal accounts and the users’ corporate credentials.

Flowchart describing how pass-the-cookie attack works
Figure 4. Pass-the-cookie attack flowchart

Commodity credential theft malware like Emotet, Redline, IcedID, and more all have built-in functionality to extract and exfiltrate browser cookies. Additionally, the attacker does not have to know the compromised account password or even the email address for this to work those details are held within the cookie.

Recommendations

Protect

Organizations can take a significant step toward reducing the risk of token theft by ensuring that they have full visibility of where and how their users are authenticating. To access critical applications like Exchange Online or SharePoint, the device used should be known by the organization. Utilizing compliance tools like Intune in combination with device based conditional access policies can help to keep devices up to date with patches, antivirus definitions, and EDR solutions. Allowing only known devices that adhere to Microsoft’s recommended security baselines helps mitigate the risk of commodity credential theft malware being able to compromise end user devices.

For those devices that remain unmanaged, consider utilizing session conditional access policies and other compensating controls to reduce the impact of token theft:

Protect your users by blocking initial access:

  • Plan and implement phishing resistant MFA solutions such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for users.
    • While this may not be practical for all users, it should be considered for users of significant privilege like Global Admins or users of high-risk applications.
  • Users that hold a high level of privilege in the tenant should have a segregated cloud-only identity for all administrative activities, to reduce the attack surface from on-premises to cloud in the event of on-premises domain compromise and abuse of privilege. These identities should also not have a mailbox attached to them to prevent the likelihood of privileged account compromise via phishing techniques.

We recognize that while it may be recommended for organizations to enforce location, device compliance, and session lifetime controls to all applications it may not always be practical. Decisionmakers should instead focus on deploying these controls to applications and users that have the greatest risk to the organization which may include:

  • Highly privileged users like Global Administrators, Service Administrators, Authentication Administrators, and Billing Administrators among others.
  • Finance and treasury type applications that are attractive targets for attackers seeking financial gain.
  • Human capital management (HCM) applications containing personally identifiable information that may be targeted for exfiltration.
  • Control and management plane access to Microsoft 365 Defender, Azure, Office 365 and other cloud app administrative portals.
  • Access to Office 365 services (Exchange, SharePoint, and Teams) and productivity-based cloud apps.
  • VPN or remote access portals that provide external access to organizational resources.

Detect

When a token is replayed, the sign-in from the threat actor can flag anomalous features and impossible travel alerts. Azure Active Directory Identity Protection and Microsoft Defender for Cloud Apps both alert on these events. Azure AD Identity Protection has a specific detection for anomalous token events. The token anomaly detection in Azure AD Identity Protection is tuned to incur more noise than other alerts. This helps ensure that genuine token theft events aren’t missed.

DART recommends focusing on high severity alerts and focusing on those users who trigger multiple alerts rapidly. Detection rules that map to the MITRE ATT&CK framework can help detect genuine compromise. For example, a risky sign-in followed closely by indicators of persistence techniques, such as mailbox rule creation.

Response and investigation

If a user is confirmed compromised and their token stolen, there are several steps DART recommends evicting the threat actor. Azure AD provides the capability to revoke a refresh token. Once a refresh token is revoked, it’s no longer valid. When the associated access token expires, the user will be prompted to re-authenticate. The following graphic outlines the methods by which access is terminated entirely:

Chart showing refresh revocation by type
Figure 5. Refresh token revocation by type

It’s crucial to use both the Azure AD portal, Microsoft Graph, or Azure AD PowerShell in addition to resetting the users’ passwords to complete the revocation process.

Importantly, revoking refresh tokens via the above methods doesn’t invalidate the access token immediately, which can still be valid for up to an hour. This means the threat actor may still have access to a compromised user’s account until the access token expires. Azure AD now supports continuous access evaluation for Exchange, SharePoint and Teams, allowing access tokens to be revoked in near real time following a ‘critical event’. This helps to significantly reduce the up to one hour delay between refresh token revocation and access token expiry.

Microsoft DART also recommends checking the compromised user’s account for other signs of persistence. These can include:

  • Mailbox rules – threat actors often create specific mailbox rules to forward or hide email. These can include rules to hide emails in folders that are not often used. For example, a threat actor may forward all emails containing the keyword ‘invoice’ to the Archive folder to hide them from the user or forward them to an external email address.
  • Mailbox forwarding – email forwarding may be configured to send a copy of all email to an external email address. This allows the threat actor to silently retrieve a copy of every email the user receives.
  • Multifactor authentication modification – DART has detected instances of threat actors registering additional authentication methods against compromised accounts for use with MFA, such as phone numbers or authenticator apps.
  • Device enrollment – in some cases, DART has seen threat actors add a device to an Azure AD tenant they control. This is an attempt to bypass conditional access rules with exclusions such as known devices.
  • Data exfiltration – threat actors may use the inbuilt sharing functionality in SharePoint and OneDrive to share important or sensitive documents and organizational resources externally.

To strengthen your security posture, you should configure alerts to review high-risk modifications to a tenant. Some examples of this are:

  • Modification or creation of security configurations
  • Modification or creation of Exchange transport rules
  • Modification or creation of privileged users or roles

Incident responders should review any audit logs related to user activity to look for signs of persistence. Logs available in the Unified Audit Log, Microsoft Defender for Cloud Apps, or SIEM solutions like Microsoft Sentinel can aid with investigations.

Conclusion

Although tactics from threat actors are constantly evolving, it is important to note that multifactor authentication, when combined with other basic security hygiene—utilizing antimalware, applying least privilege principals, keeping software up to date and protecting data—still protects against 98% of all attacks.

Fundamentally, it is important to consider the identity trust chain for the organization, spanning both internally and externally. The trust chain includes all systems (such as identity providers, federated identity providers, MFA services, VPN solutions, cloud-service providers, and enterprise applications) that issue access tokens and grant privilege for identities both cloud and on-premises, resulting in implicit trust between them.

In instances of token theft, adversaries insert themselves in the middle of the trust chain and often subsequently circumvent security controls. Having visibility, alerting, insights, and a full understanding of where security controls are enforced is key. Treating both identity providers that generate access tokens and their associated privileged identities as critical assets is strongly encouraged.

Adversaries have and will continue to find ways to evade security controls. The tactics utilized by threat actors to bypass controls and compromise tokens present additional challenges to defenders. However, by implementing the controls presented in this blog DART believes that organizations will be better prepared to detect, mitigate, and respond to threats of this nature moving forward.

The post Token tactics: How to prevent, detect, and respond to cloud token theft appeared first on Microsoft Security Blog.

The final report on NOBELIUM’s unprecedented nation-state attack

December 15th, 2021 No comments

This is the final post in a four-part series on the NOBELIUM nation-state cyberattack. In December 2020, Microsoft began sharing details with the world about what became known as the most sophisticated nation-state cyberattack in history. Microsoft’s four-part video series “Decoding NOBELIUM” pulls the curtain back on the NOBELIUM incident and how world-class threat hunters from Microsoft and around the industry came together to take on the most sophisticated nation-state attack in history. In this last post, we’ll reflect on lessons learned as covered in the fourth episode of the docuseries. 

Nation-state attacks are a serious and growing threat that organizations of all sizes face. Their primary objective is to gain strategic advantage for their country, such as by stealing secrets, gathering cyber intelligence, conducting reconnaissance, or disrupting operations. These efforts are typically conducted by state-sponsored actors with significant expertise and funding, making them a particularly challenging adversary to defend against.

NOBELIUM, a Russian-linked group, is perhaps best known for the widespread SolarWinds supply chain breach. The incident was part of an even larger and more advanced campaign that had been quietly underway for more than a year. As details of this attack were uncovered, it became clear that it was the most sophisticated nation-state cyberattack in history.

In the final episode of our “Decoding NOBELIUM” series, we provide an after-action report that explores Microsoft’s findings and discusses lessons learned.

NOBELIUM deployed extensive tactics

Let’s start by reviewing the key stages of the attack.

The intrusion

It’s critical to understand how NOBELIUM achieved penetration into environments. Going beyond the supply chain compromise, this actor also deployed many common-place tactics like password spraying or exploiting the vulnerabilities of unpatched devices to steal credentials and gain access to systems. Ultimately, NOBELIUM leveraged a wide range of techniques to achieve penetration and adapted their toolset to each victim’s unique environment in order to achieve their goals.

The exploitation

Once NOBELIUM had gained entry, they followed the typical pattern for internal reconnaissance: discover the elevated accounts, find out which machines were there, and create a sophisticated map to understand how to reach their targets. They demonstrated extensive knowledge of enterprise environments and cybersecurity systems by evading defenses, masking activities in regular system processes, and hiding malware under many layers of code.

The exfiltration

Armed with an understanding of their target’s environment, NOBELIUM executed their plan—gaining access to their source codes, harvesting emails, or stealing production secrets.

NOBELIUM demonstrated patience and stealth

The NOBELIUM group moved methodically to avoid getting caught. “They were so deliberate and careful about what they did. It wasn’t like a smash and grab, where they came in and just vacuumed up everything and fled,” said Security Analyst Joanne of the Microsoft Digital Security and Resilience (DSR) Security Operations Center (SOC) Hunt Team.

It took time to move undetected through networks, gathering information and gaining access to privileged networks. For example, they disabled organizations’ endpoint detection and response (EDR) solutions from being launched upon system startups. NOBELIUM then waited up to a month for computers to be rebooted on a patch day and took advantage of vulnerable machines that hadn’t been patched.

“The adversary showed discipline in siloing all of the technical indicators that would give up their presence,” said John Lambert, General Manager of the Microsoft Threat Intelligence Center. “Malware was named different things. It was compiled in different ways. The command and control domains they would use differed per victim. As they moved laterally within a network from machine to machine, NOBELIUM took great pains to clean up after each step.”

Preparing for future nation-state attacks

When adversaries take this much care in hiding their activities, it can take the detection of many seemingly benign activities across different vectors pulled together to highlight one overall technique.

“In order to respond to an attack like NOBELIUM, with its scope and breadth and sophistication, you need to have visibility into various entities across your entire digital state,” explains Sarah Fender, Partner Group Program Manager for Microsoft Sentinel. “You need to have visibility into security data and events relating to users and endpoints, infrastructure, on-premises and in the cloud, and the ability to quickly analyze that data.”

NOBELIUM leveraged users and credentials as a critical vector for intrusion and escalation. Identity-based attacks are on the rise. “Once I can authenticate into your environment, I don’t need malware anymore, so that means monitoring behaviors,” says Roberto, Principal Consultant and Lead Investigator for Microsoft’s Detection and Response Team. “Building a profile for when Roberto’s using his machine, he accesses these 25 resources, and he does these kinds of things and he’s never been in these four countries. If I ever see something that doesn’t fit that pattern, I need to alert on it.” 

Bottom line: ensure you are protecting your identities.

Finally, if we’ve learned anything, it’s that we need to take care of our security teams, especially during a cybersecurity incident. 

“Defender fatigue is a real thing,” says Lambert. “You have to be able to invest in those defenders so that they can surge when they need to. Security, like other professions, is not just a job, it’s also a calling. But it also leads to fatigue and exhaustion if the incident drumbeat is too strong. You have to have reserves and plan for that so that you can support your defenders and rest them in between incidents.”

As we prepare for future attacks, it comes down to joining forces. 

“When I think about what this incident means going forward, it certainly reinforces the need for the world to work together on these threats,” explains Lambert. “No one company sees it all and it is very important, especially with sophisticated threats, to be able to work very quickly with lines of trust established. This is not just about companies working together, it’s also about individuals trusting each other, impacted companies, fellow security industry companies, and government institutions.”

How can you protect your organization and defenders?

Learn more in the final episode of our four-part video series “Decoding NOBELIUM,” where security professionals give insights from the after-action report on NOBELIUM. Thanks for joining us for this series and check out the other posts in the series:

Microsoft is committed to helping organizations stay protected from cyberattacks, whether cybercriminal or nation-state. Consistent with our mission to provide security for all, Microsoft will use our leading threat intelligence and a global team of dedicated cybersecurity defenders to partner across the security industry and help protect our customers and the world. Just some recent examples of Microsoft’s efforts to combat nation-state attacks include:

  • The investigation of ongoing targeted activity by NOBELIUM against privileged accounts of service providers to gain access to downstream customers.
  • The September 2021 discovery and investigation of a NOBELIUM malware referred to as FoggyWeb.
  • The May 2021 profiling of NOBELIUM’s early-stage toolset of EnvyScout, BoomBox, NativeZone, and VaporRage.
  • Issuing more than 1,600 notifications to more than 40 IT companies alerting them to targeting by several Iranian threat groups (from May through October, those threats were 10 to 13 percent of the total notifications).
  • The seizure of websites operated by NICKEL, a China-based threat actor, and the disruption of ongoing attacks targeting organizations in 29 countries.
  • The investigation of Iran-linked DEV-0343, conducting password spraying focused on United States and Israeli defense technology companies, Persian Gulf ports of entry, and global maritime transportation companies with a business presence in the Middle East.

For immediate support, visit the Microsoft Security Response Center (MSRC) where you can report an issue and get guidance from the latest security reports and Microsoft Security Response Center 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 The final report on NOBELIUM’s unprecedented nation-state attack appeared first on Microsoft Security Blog.

Behind the unprecedented effort to protect customers against the NOBELIUM nation-state attack

December 2nd, 2021 No comments

This is the third in a four-part blog series on the NOBELIUM nation-state cyberattack. In December 2020, Microsoft began sharing details with the world about what became known as the most sophisticated nation-state cyberattack in history. Microsoft’s four-part video series “Decoding NOBELIUM” pulls the curtain back on the NOBELIUM incident and how world-class threat hunters from Microsoft and around the industry came together to take on the most sophisticated nation-state attack in history. In this third post, we’ll explore Microsoft’s response to the NOBELIUM attack covered in the third episode of the docuseries.

Defending against a major cyberattack requires the same level of readiness that you need for any major crisis, according to Microsoft 365 Security Chief of Staff Elizabeth Stephens, a 19-year Marine Corps veteran who served in three combat deployments. There’s a mission. There’s a plan of action. And there’s an expert team ready to go. Stephens was part of a dedicated response team that was mobilized in response to the NOBELIUM nation-state attack in December 2020.

“All of the teams came together in a way that very much reminded me of the way my Marine Corps came together,” said Stephens. “The way we respond is very much like first responders. We pride ourselves on being able to come together regardless of our areas of specialty and expertise and fill in the gaps between each other very quickly to get a mission completed. [It’s about] selflessness and the sense of, if we weren’t defending then who else was going to?”

As explained in our first post in the series, How nation-state attackers like NOBELIUM are changing cybersecurity, these sophisticated actors are working to further a given country’s interests through cyberespionage or intelligence-gathering efforts. The multi-pronged attack, which included supply chain compromise from NOBELIUM, a Russian-linked group of hackers, is widely recognized as the most sophisticated nation-state cyberattack in history. When an attack of this magnitude is discovered, the response is equally significant. In the second post in the series, The hunt for NOBELIUM, the most sophisticated nation-state attack in history, we covered the initial industry-wide investigation and gathering of data to understand the attack.

In the third episode of our “Decoding NOBELIUM” series, we reveal new details about how Microsoft worked to disrupt the adversary and safeguard the organizations: notifying and supporting impacted customers, deploying novel prevention rapidly, and providing detection measures to protect all of its customers against the threat.

Notifying customers of the NOBELIUM attack

Customers needed to be notified quickly so they could investigate and understand the scope of the attack inside their environments. Once the threat hunters began isolating threat markers for NOBELIUM activity, they could effectively identify and contact impacted customers. The security community, traditionally, tells customers that they will never receive a phone call from defenders—and to view any calls suspiciously. In this case, with attackers having access to victim environments, there was no safe alternative. Making a call with the difficult news of a sophisticated incursion would be hard enough, but in some instances, they had to find creative ways to validate that it was, in fact, Microsoft on the phone. As part of the notification, the team shared information and guidance about the attack to enable the customer to further investigate the scope and act to begin remediation. The news of NOBELIUM’s activity understandably stunned customers.

“To see the look on people’s faces as the gravity of that [situation] settled in, was certainly sobering for me and my team, but it was also a tremendous incentive to keep going until we could get to the very bottom of it,” said Franklin, Microsoft Identity Security Response Team Lead.

Building product detections to support customers

Those customer contacts were just part of Microsoft’s response to this attack. Microsoft’s threat hunters continued to pore over massive amounts of aggregated telemetry—including user, email, collaboration tools, endpoint, cloud activity, and cloud application security—to identify more subtle attack markers. Called tactics, techniques, and procedures (TTP), these markers were used to track NOBELIUM’s movements.

“By taking a holistic view, we are able to track attackers that move from domain to domain and that is usually where they get lost in the noise, in the transitions,” said Michael Shalev, Principal Program Manager for Microsoft 365 Defender.

The team identified more than 70 TTPs associated with the NOBELIUM attack that we shared publicly. Together, they painted a picture of how the NOBELIUM group operated. Microsoft teams determined which TTPs were specific to an organization, and which were found across the impacted organizations. They quickly used these TTPs to build automated detections into security products so impacted organizations could “return their network and assets to a healthy state” and unimpacted organizations could protect themselves from similar threats, Shalev explained.

Releasing detections into security products in response to a specific attack isn’t new; Microsoft regularly releases detections into security products in response to attacks. But the release volume after the NOBELIUM incident was unprecedented. During a three-week period, Microsoft researchers released multiple detections a day—in the form of targeted custom queries shared through blog posts or updates released directly into the products to enable real-time action. “Seconds count when responding to an attack like this,” said Partner Product Manager Sarah Fender of Microsoft Sentinel, Microsoft’s cloud-native security information and event management platform.

For example, the threat hunters discovered specific techniques that NOBELIUM used to evade security software and analyst tools. As there can be benign reasons to turn off sensors or logging, the TTP research was critical to detecting when the activity was malicious. In response, the Microsoft Defender for Endpoint team developed new anti-tampering policies, hunting queries, and detections to identify and send alerts on these specific NOBELIUM-related activities.

“You really have to meet the customer where they are because the attack is so significant that they’re all going to need help in different sorts of ways,” said Cristin Goodwin, Associate General Counsel for the Microsoft Digital Security Unit.

Cybersecurity strategies and available resources

In the third episode of our “Decoding NOBELIUM” series, security professionals share insights on defending customers after NOBELIUM’s discovery. Watch the episode for guidance on effective cybersecurity hygiene. Look out for the final post in the NOBELIUM nation-state attack series, where we will offer a fuller breakdown of the NOBELIUM attack and share predictions and tips for the future of cybersecurity. Read our previous posts in this series:

Microsoft is committed to helping organizations stay protected from cyberattacks whether cybercriminal or nation-state. Consistent with our mission to provide security for all, Microsoft will use our leading threat intelligence and a global team of dedicated cybersecurity defenders to help protect our customers and the world. Just two recent examples of Microsoft’s efforts to combat nation-state attacks include a September 2021 discovery, an investigation of a NOBELIUM malware referred to as FoggyWeb, and our May 2021 profiling of NOBELIUM’s early-stage toolset compromising EnvyScout, BoomBox, NativeZone, and VaporRage.

For immediate support, visit the Microsoft Security Response Center where you can report an issue and get guidance from the latest security reports and Microsoft Security Response Center blogs.

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 Behind the unprecedented effort to protect customers against the NOBELIUM nation-state attack appeared first on Microsoft Security Blog.

Microsoft open sources CodeQL queries used to hunt for Solorigate activity

February 25th, 2021 No comments

A key aspect of the Solorigate attack is the supply chain compromise that allowed the attacker to modify binaries in SolarWinds’ Orion product. These modified binaries were distributed via previously legitimate update channels and allowed the attacker to remotely perform malicious activities, such as credential theft, privilege escalation, and lateral movement, to steal sensitive information. The incident has reminded organizations to reflect not just on their readiness to respond to sophisticated attacks, but also the resilience of their own codebases.

Microsoft believes in leading with transparency and sharing intelligence with the community for the betterment of security practices and posture across the industry as a whole. In this blog, we’ll share our journey in reviewing our codebases, highlighting one specific technique: the use of CodeQL queries to analyze our source code at scale and rule out the presence of the code-level indicators of compromise (IoCs) and coding patterns associated with Solorigate. We are open sourcing the CodeQL queries that we used in this investigation so that other organizations may perform a similar analysis. Note that the queries we cover in this blog simply serve to home in on source code that shares similarities with the source in the Solorigate implant, either in the syntactic elements (names, literals, etc.) or in functionality. Both can occur coincidentally in benign code, so all findings will need review to determine if they are actionable. Additionally, there is no guarantee that the malicious actor is constrained to the same functionality or coding style in other operations, so these queries may not detect other implants that deviate significantly from the tactics seen in the Solorigate implant. These should be considered as just a part in a mosaic of techniques to audit for compromise.

Microsoft has long had integrity controls in place to verify that the final compiled binaries distributed to our servers and to our customers have not been maliciously modified at any point in the development and release cycle. For example, we verify that the source file hashes generated by the compiler match the original source files. Still, at Microsoft, we live by the “assume breach” philosophy, which tells us that regardless of how diligent and expansive our security practices are, potential adversaries can be equally as clever and resourced. As part of the Solorigate investigation, we used both automated and manual techniques to validate the integrity of our source code, build environments, and production binaries and environments.

Microsoft’s contribution during Solorigate investigations reflects our commitment to a community-based sharing vision described in Githubification of InfoSec. In keeping with our vision to grow defender knowledge and speed community response to sophisticated threats, Microsoft teams have openly and transparently shared indicators of compromise, detailed attack analysis and MITRE ATT&CK techniques, advanced hunting queries, incident response guidance, and risk assessment workbooks during this incident. Microsoft encourages other security organizations that share the “Githubification” vision to open source their own threat knowledge and defender techniques to accelerate defender insight and analysis. As we have shared before, we have compiled a comprehensive resource for technical details of the attack, indicators of compromise, and product guidance at https://aka.ms/solorigate. As part of Microsoft’s sweeping investigation into Solorigate, we reviewed our own environment. As we previously shared, these investigations found activity with a small number of internal accounts, and some accounts had been used to view source code, but we found no evidence of any modification to source code, build infrastructure, compiled binaries, or production environments.

A primer on CodeQL and how Microsoft utilizes it

CodeQL is a powerful semantic code analysis engine that is now part of GitHub. Unlike many analysis solutions, it works in two distinct stages. First, as part of the compilation of source code into binaries, CodeQL builds a database that captures the model of the compiling code. For interpreted languages, it parses the source and builds its own abstract syntax tree model, as there is no compiler. Second, once constructed, this database can be queried repeatedly like any other database. The CodeQL language is purpose-built to enable the easy selection of complex code conditions from the database.

One of the reasons we find so much utility from CodeQL at Microsoft is specifically because this two-stage approach unlocks many useful scenarios, including being able to use static analysis not just for proactive Secure Development Lifecycle analysis but also for reactive code inspection across the enterprise. We aggregate the CodeQL databases produced by the various build systems or pipelines across Microsoft to a centralized infrastructure where we have the capability to query across the breadth of CodeQL databases at once. Aggregating CodeQL databases allows us to search semantically across our multitude of codebases and look for code conditions that may span between multiple assemblies, libraries, or modules based on the specific code that was part of a build. We built this capability to analyze thousands of repositories for newly described variants of vulnerabilities within hours of the variant being described, but it also allowed us to do a first-pass investigation for Solorigate implant patterns similarly, quickly.

We are open sourcing several of the C# queries that assess for these code-level IoCs, and they can currently be found in the CodeQL GitHub repository. The Solorigate-Readme.md within that repo contains detailed descriptions of each query and what code-level IoCs each one is attempting to find. It also contains guidance for other query authors on making adjustments to those queries or authoring queries that take a different tactic in finding the patterns.

GitHub will shortly publish guidance on how they are deploying these queries for existing CodeQL customers. As a reminder, CodeQL is free for open-source projects hosted by GitHub.

Our approach to finding code-level IoCs with CodeQL queries

We used two different tactics when looking for code-level Solorigate IoCs. One approach looks for particular syntax that stood out in the Solorigate code-level IoCs; the other approach looks for overall semantic patterns for the techniques present in the code-level IoCs.

The syntactic queries are very quick to write and execute while offering several advantages over comparable regular expression searches; however, they are brittle to the malicious actor changing the names and literals they use. The semantic patterns look for the overall techniques used in the implant, such as hashing process names, time delays before contacting the C2 servers, etc. These are durable to substantial variation, but they are more complicated to author and more compute-intensive when analyzing many codebases at once.

Sample technique from implant with corresponding CodeQL query

By combining these two approaches, the queries are able to detect scenarios where the malicious actor changed techniques but used similar syntax, or changed syntax but employed similar techniques. Because it’s possible that the malicious actor could change both syntax and techniques, CodeQL was but one part of our larger investigative effort.

Next steps with CodeQL

The queries we shared in this blog and described in Solorigate-Readme.md target patterns specifically associated with the Solorigate code-level IoCs, but CodeQL also provides many other options to query for backdoor functionality and detection-evasion techniques.

These queries were relatively quick to author, and we were able to hunt for patterns much more accurately across our CodeQL databases and with far less effort to manually review the findings, compared to using text searches of source code. CodeQL is a powerful developer tool, and our hope is that this post inspires organizations to explore how it can be used to improve reactive security response and act as a compromise detection tool.

In future blog posts, we’ll share more ways that Microsoft uses CodeQL. We’ll also continue open-sourcing queries and utilities that build upon CodeQL so that others may benefit from them and further build upon them.

The post Microsoft open sources CodeQL queries used to hunt for Solorigate activity appeared first on Microsoft Security.

Advice for incident responders on recovery from systemic identity compromises

December 21st, 2020 No comments

As Microsoft alongside our industry partners and the security community continues to investigate the extent of the Solorigate attack, our goal is to provide the latest threat intelligence including IOCs and guidance across our products and solutions to help the community fight back against, harden your infrastructure, and begin to recover from this attack of unprecedented scale. As new information becomes available, we will make updates to this article.

This blog will outline lessons learned from this and other incident response to date in on-premises and cloud environments. This latest guidance is for customers looking to re-establish trusted identities for credentials that are suspected of compromise by Solorigate malware.

This article is intended to give experienced incident responders some advice on techniques to consider when helping an organization respond to a suspected systemic identity compromise, like we’re seeing in some victims of the Solorigate malware, based on our experience in the field in similar scenarios. Re-establishing trust in the organization’s on-premises and cloud environments with minimal business impact requires in-depth investigation and an understanding of potential methods of persistence. While not meant to cover every possible scenario, this guidance is intended to summarize our experience with similar customer breaches and will be updated if we learn of new information that would help with successful recovery. Please review the resources referenced at the end of this article for additional information. This information is provided as-is and constitutes generalized guidance; the ultimate determination about how to apply this guidance to your IT environment and tenant(s) must consider your unique environment and needs, which each Customer is in the best position to determine.

The Solorigate investigation referenced in this guidance is ongoing at the time of publication and our teams continue to act as first responders to these attacks. As new information becomes available, we will make updates through our Microsoft Security Response Center (MSRC) blog.

Overview of the intrusion

As described in this Microsoft blog post, the hallmarks of this actor’s activity include, but are not limited to, the following techniques that are likely to result in systemic identity compromise:

  • An intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold in the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for these files. Read our in-depth technical analysis of the Solorigate malware.
  • An intruder using administrative permissions (acquired through an on-premises compromise) to gain access to an organization’s trusted SAML token-signing certificate. This enables them to forge SAML tokens to impersonate any of the organization’s existing users and accounts, including highly privileged accounts.
  • Anomalous logins using the SAML tokens signed with a compromised token-signing certificate, which can be used against any on-premises resources (regardless of identity system or vendor) as well as against any cloud environment (regardless of vendor) because they have been configured to trust the certificate. An organization may miss the use of illegitimate SAML tokens because they are signed with a legitimate certificate.
  • The use of highly privileged accounts (acquired through the technique above or other means) to add illegitimate credentials to existing application service principals, enabling the attacker to call APIs with the permission assigned to that application.

Overview of response objectives

Organizations that have experienced systemic identity compromise need to start recovery by re-establishing trustworthy communications. This will enable effective triage and coordination of business operations recovery.

Many organizations have complex internal and external interdependencies. Core business processes and applications in an organization are likely to be temporarily impacted during recovery efforts until trust within your environment is re-established. Microsoft recommends that Incident Responders establish secure communications with key organizational personnel as the first step toward organizational recovery. If your investigation indicates that the attacker has used techniques outside of identity compromise at lower levels of your organizations’ infrastructure, such as hardware or firmware attacks, you will need to address those threats to reduce the risk of re-compromise.

Response objectives in approximate order:

  1. Establish secure communications for personnel key to the investigation and response effort.
  2. Investigate the environment for persistence and initial access point, while establishing continuous monitoring operations during recovery efforts.
  3. Regain and retain administrative control of your environment and remediate or block possible persistence techniques and initial access exploits.
  4. Improve posture by enabling security features and capabilities following best practice recommendations.

We recommend that incident responders review and digest the entirety of this guidance before taking action, as the specific order of actions taken to achieve the response objectives is very situational and depends heavily on the results (and completeness) of investigation and the business constraints of the specific organization. The following sections describe the incident Response techniques we recommend you consider for each of the above objectives.

Establish secure communications and productivity

Successful response requires being able to communicate without the attacker eavesdropping on your communications. Until you have achieved assurance in the privacy of your communications on your current infrastructure, use completely isolated identities and communication resources to coordinate your response and discuss topics that could potentially tip off the attacker to your investigation. Until your investigation has achieved assurance in actor eviction, we strongly recommend that you keep all incident-related comms isolated to enable you to have the element of surprise when taking remediation actions.

  • Initial one-on-one and group communications can be achieved through phone (PSTN) calling, conference bridges not connected to the corporate infrastructure, and end-to-end encrypted messaging solutions.
  • One way that many customers have established secure productivity and collaboration is to create a new Office 365 tenant which is completely isolated from the organization’s production tenant and create accounts only for the key personnel needed, and any incident response vendors or partners who need to be part of the response.
    • Make sure to follow best practices for securing this tenant, especially administrative accounts and rights by default. The new tenant should be limited on Administrative rights along with no trusts with outside applications or vendors. If you need further assistance or want information on hardening Microsoft 365, you can review the guidance here.

Investigate your environment

Once your incident responders and key personnel have a secure place to collaborate, the next step is to investigate the suspected compromised environment. Successful investigation will be a balance between getting to the bottom of every anomalous behavior to fully scope the extent of attacker activity and persistence and taking action quickly to stop any further activity on objectives by the attacker. Successful remediation requires as complete an understanding of the initial method of entry and persistence mechanisms controlled by the attacker as possible. Any persistence mechanisms missed could result in continued access by the attacker and potential for re-compromise.

  • Investigate and review cloud environment logs for suspicious actions and attacker IOCs, including:
    • Unified Audit Logs (UAL).
    • Azure Active Directory (Azure AD) logs.
    • Active Directory logs.
    • Exchange on-prem logs.
    • VPN logs.
    • Engineering systems logging.
    • Antivirus and endpoint detection logging.
  • Review endpoint audit logs for changes from on-premises for actions including, but not limited to, the following:
    • Group membership changes.
    • New user account creation.
    • Delegations within Active Directory.
    • Along with other typical signs of compromise or activity.
  • Review Administrative rights in your environments
    • Review privileged access in the cloud and remove any unnecessary permissions. Implement Privileged Identity Management (PIM); setup Conditional Access policies to limit administrative access during hardening.
    • Review privileged access on-premise and remove unnecessary permissions. Reduce membership of built-in groups, verify Active Directory delegations, harden Tier 0 environment, and limit who has access to Tier 0 assets.
    • Review all Enterprise Applications for delegated permissions and consent grants that allow (sample script to assist):
      • Modification of privileged users and roles.
      • Reading or accessing all mailboxes.
      • Sending or forwarding email on behalf of other users.
      • Accessing all OneDrive or SharePoint sites content.
      • Adding service principals that can read/write to the Directory.
    • Review access and configuration settings for the following Office 365 products:
      • SharePoint Online Sharing
      • Teams
      • PowerApps
      • OneDrive for Business
    • Review user accounts
      • Review and remove guest users that are no longer needed.
      • Review email configurations using Hawk or something similar.
        • Delegates
        • Mailbox folder permissions
        • ActiveSync mobile device registrations
        • Inbox Rules
        • Outlook on the Web Options
      • Validate that both MFA and self-service password reset (SSPR) contact information for all users is correct.

You may find that one or more of the logging sources above are data sources that the organization does not currently include in its security program. Some of them, especially the logging available in the cloud, are available only if configured and we recommend that you configure them as soon as possible to enable both the detections in the next section and forensics review of logs going forward. Make sure to configure your log retention to support your organization’s investigation goals going forward and retain evidence, if needed for legal, regulatory, or insurance purposes.

Establish continuous monitoring

There are many ways to detect activity associated with this campaign. Exactly how your organization will detect attacker behavior depends on which security tools you have available, or choose to deploy in response. Microsoft has provided examples publicly for some of the core security products and services that we offer and are continually updating those documents as new threat intelligence is identified related to this attacker. If you use other vendor’s products, review your vendor’s recommendations, and review the Microsoft documentation below to understand the detection techniques if you need to implement analogous detections in your environment on your own.

For readers using Azure Sentinel in their environments, review SolarWinds Post-Compromise Hunting guidance.

For readers using Microsoft Defender for Endpoint, review our guidance here, and review Microsoft Defender Antivirus guidance.

Azure Active Directory sign-ins

You can view this information from the Azure Active Directory Sign-in blade by selecting an appropriate time window and then downloading the report as either a CSV or JSON file. NOTE: You can download interactive, as well as non-interactive, sign-in reports via this interface. Once you have downloaded the results, look for the value “MFA requirement satisfied by claim in the token” in the “MFA result” field.

You can also use the Get-AzureADAuditSignInLogs cmdlet (see the details here) and filter the results to only return entries that match this field value, as seen in this example:

Get-AzureADAuditSignInLogs -All:$true -Filter "createdDateTime gt <startdate> and createdDateTime lt <enddate>"  | where {$_.Status.AdditionalDetails -eq "MFA requirement satisfied by claim in the token"} | select-object CreatedDateTime, IpAddress,UserAgent, ResourceDisplayName, CorrelationId, RequestId, UserPrincipalName -ExpandProperty Status

If your ADFS environment is configured to send a claim for MFA being satisfied, this may not be a strong signal. However, for many organizations using ADFS, and this claim is not included per your configuration; in those cases, the presence of this claim may be a strong indicator of attacker activity. You may also wish to add additional filters or conditions in the where clause to further improve your signal to noise ratio, such as only surfacing results from domains that are federated.

If suspicious sign-ins are detected, you can further pivot your investigation based on IP addresses identified, user accounts identified, and/or other indicators such as the UserAgent string and client operating system observed, if based on your knowledge of your environment these appear to be strong indicators.

Analysis of risky sign-in events

In some cases, Azure Active Directory and its Identity Protection platform will generate risk events associated with the use of attacker generated SAML tokens. These can be labeled as “unfamiliar properties”, “anonymous IP address”, “impossible travel” and the other risk events as described here.

Closely analyze all risk events associated with accounts that have administrative privileges. It is also important to analyze events that have been dismissed or remediated as some of these actions are done automatically. For example, a risk event for an anonymous IP address can be automatically remediated because the user passed MFA.

Detection of domain authentication properties

The attacker may attempt to manipulate the domain authentication policies which are recorded in the Azure Active Directory Audit Logs and reflected in the Unified Audit Log. An attacker who has gained access with Global Administrator privileges can modify the domains that are federated and/or trusted. Review any events associated with “Set domain authentication” in either the Unified Audit Log, Azure AD Audit Logs, and/or your SIEM environment. Verify that all activities were expected and planned.

The sample command below returns the entries from the Unified Audit Log which were associated with manipulation of domain authentication settings.

Search-UnifiedAuditLog -StartDate <startdate> -EndDate <enddate> -ResultSize 5000 -Operations "Set domain authentication"

Detection of credentials to a service principal associated with an OAuth application

If the attacker has gained control of a credential with sufficient privileges, the attack pattern includes locating an application that has been granted the ability to access any user’s e-mail in the organization and adding attacker controlled credentials to that application. In some cases, the attacker has modified these applications granting them additional rights such as access to all e-mail in the organization.

The following are operations that would be consistent with attacker behavior:

  • Add service principal credentials.
  • Update application- certificates and secrets management.
  • Update service principal.
  • Add app role assignment to service principal.
  • Add app role assignment grant to user.
  • Add OAuth2PermissionGrant.

Detection e-mail access by applications

Detection of access to e-mail by applications can be achieved using the Advanced Auditing capabilities of Office 365. Access to messages inside of Office 365 is audited via the MailItemsAccessed capability.

Analyze events in the Unified Audit Log for the Operation of MailItemsAccessed.

Detection of non-interactive sign-ins to service principals

Azure Active Directory in the Sign-In reports provides reporting of non-interactive sign-ins using credentials issued to service principals (as was observed in this attack). Analyzing the sign-ins for service principals reports can provide valuable data such as the IP Address the attacker was using to access the applications for e-mail access.

If there is evidence found that uncovers administrative permissions acquired through the on-premises compromise to gain access to your organization’s global administrator account and/or trusted SAML token signing certificate, Microsoft recommends taking the following immediate actions:

Remediate and retain administrative control

Regaining and retaining administrative control of your environment

If your investigation has identified that the attacker has administrative control in the organization’s cloud environment and/or on-prem, it’s critical to regain control in such a way as to ensure that the attacker isn’t persistent. Exactly which steps you will take depend both on what persistence you discovered in your investigation, and your level of confidence in the completeness of that investigation and discovery of all possible methods of entry and persistence. While it is possible to regain control with high confidence, even in the face of an incomplete investigation, doing so requires significant impact to business operations, so most organizations choose to remediate based on the results of the investigation in our experience.

We recommend you consider the following steps when building your administrative control recovery plan, but the exact order and timing should be planned based on the results of your investigation and understanding of adversary owned administrative assets and methods of persistence.

  • Ensure that any actions described here are performed from a trusted device built from a clean source, such as a privileged access workstation.
  • If the organization has lost control of its token signing certificates or federated trust the highest assurance approach is to remove trust and switch to cloud mastered identity while remediating on-prem. A detailed plan for doing so is beyond the scope of this document and requires careful planning and understanding of the business operations impacts of isolating identity. Review the Azure Active Directory guidance or key considerations.
  • Should your organization choose not to break trust while recovering administrative control on-prem, you’ll need to rotate your SAML token signing certificate once you have regained administrative control on-prem and blocked the attacker’s ability to access the signing certificate again. It’s critical that your organization follow the certificate rotation instructions below to ensure that the attacker doesn’t maintain the ability to forge tokens for your domain.

Rotation of ADFS token signing certificate

For a compromised or potentially compromised ADFS Token Signing certificate, rotating the Token Signing certificate a single time would still allow the previous Token Signing certificate to work. The rationale for this is to permit a grace period to update your Relying Party Trusts prior to expiration of the certificate during normal rotation of the signing certificate.

If instead of rolling the Token Signing Certificate your organization feels the need to replace the ADFS servers with known clean systems, you can follow steps to remove the existing ADFS from your environment and build a new one.

Delete Azure AD Cloud Provisioning agent configuration.

Should your organization decide to rotate the certificate on your current ADFS servers, follow these steps in the below order, from the ADFS server:

  1. Check to make sure that your AutoCertificateRollover is set to True.
    Get-AdfsProperties | FL AutoCert*, Certificate*
    • If it is not, you can set it with this command:
      Set-ADFSProperties -AutoCertificateRollover $true
  2. Connect to the Microsoft Online Service
    Connect-MsolService
  3. Document both your on-premise and cloud Token Signing Certificate thumbprint and expiration dates.
    Get-MsolFederationProperty -DomainName <domain>
    
  4. Replace the primary Token Signing certificate using the -Urgent switch to cause ADFS to replace the primary certificate immediately without making it a Secondary certificate.
    Update-AdfsCertificate -CertificateType Token-Signing -Urgent
  5. Create a secondary Token Signing certificate without using the -Urgent switch to allow for two on-premise Token Signing certificates, before syncing with Azure cloud.
    Update-AdfsCertificate -CertificateType Token-Signing
    
  6. Update the cloud environment with both the primary and secondary certificates on-premise to immediately remove the cloud published token signing certificate. If this step is not completed using this method you leave the potential for the old token signing certificate to still authenticate users.
    Update-MsolFederatedDomain -DomainName <domain>
     
    
  7. Verification that you completed the above steps and removed the certificate that was displayed in Step 3 above.
    Get-MsolFederationProperty -DomainName <domain>
    
  8. Revoke refresh tokens via PowerShell, information can be found here and you can also reference how to “Revoke user access in Azure Active Directory.”
    • Note: This will log users out of their phone, current webmail sessions, along with other items that are using Tokens and Refresh Tokens.

Additional cloud remediation activities to complete

  • Reset passwords on any break-glass accounts and reduce the number of break-glass accounts to the absolute minimum required.
  • We recommend that service and user accounts with Privileged access should be Cloud Only accounts and not use on-premise accounts synced or federated to Azure Active Directory.
  • Enforce Multi-Factor Authentication (MFA) across all elevated users in the tenant. We recommend enforcing MFA across all users in the tenant.
  • Implement Privileged Identity Management (PIM) and conditional access to limit administrative access.
    • For Office 365 users, implement Privileged Access Management (PAM) to limit access to sensitive capabilities (including eDiscovery, Global Admin, Account Administration, and more).
  • Review and reduce all Enterprise Applications delegated permissions or consent grants that allow such as:
    • Modification of privileged users and roles.
    • Reading, sending email, or accessing all mailboxes.
    • Accessing OneDrive, Teams, or SharePoint content.
    • Adding of Service Principals that can read/write to the Directory.
    • Application Permissions versus Delegated Access.

Additional on-premises remediation activities to complete

  • Rebuild systems that were identified as compromised by the attacker during your investigation.
  • Remove unnecessary members from Domain Admins, Backup Operators, and Enterprise Admin groups. Reference Microsoft’s Securing Privileged Access.
  • Reset passwords of all privileged accounts in the environment.
    • Privilege accounts are not limited to Built-In groups but can also be groups that are delegated access to Server Administration / Workstation Administration and other aspects of your environment.
  • Reset the krbtgt account using this script twice.
    • Note: If you are using Read-Only Domain Controllers, you will need to run the script for Read-Write Domain Controllers and Read-Only Domain Controllers.
  • After you validate that no persistence mechanisms created by the attacker exist or remain on your system, schedule a restart. This can assist with removing memory resident malware.
  • Reset each domain controller’s DSRM (Directory Services Restore Mode) password to something unique and complex.

Remediate or block persistence discovered during investigation

Remediate the persistence techniques identified in your investigation stage earlier. Investigation is an iterative process and you’ll need to balance the organizational desire to remediate as you identify anomalies and the chance that remediation will alert the attacker of your detection and cause them to react by changing techniques or creating additional persistence. For Office 365 accounts, automatically remediate known persistence techniques, if any are discovered, using the scripts described

Remediate user and service account access

Some of the user-level actions we recommend were described above already, specifically in terms of ensuring that MFA is enabled and running specific remediation scripts to clean up known persistence techniques. Here are some additional steps you should consider taking to remediate and restore user accounts:

  • Enforce conditional access based on trusted device.
    • If possible, enforce location-based conditional access that suits your organizational requirements.
  • For any user accounts suspected of being compromised, immediately reset passwords after eviction; make sure you also implement a mid-term plan to reset credentials for all accounts in your directory.
  • After credential rotation, use PowerShell to revoke refresh tokens immediately. More information can be found here and additional resources can be found at Revoke user access in an emergency in Azure Active Directory | Microsoft Docs.

Improve security posture

After a security event is a good time for organizations to reflect on their security strategy and priorities. Incident Responders are often asked to provide recommendations after an event on what investments the organization should prioritize now that it’s been faced with new threats. In addition to the recommendations documented earlier, we recommend you consider these areas of focus for your post-incident review recommendations that are responsive to the post-exploitation techniques used by this attacker and the common security posture gaps that enable them.

General security posture

  • Review Microsoft Secure Score for security fundamentals recommendations customized for the Microsoft products and services you consume.
  • Ensure that your organization has EDR and SIEM solutions in place.
  • Review Microsoft’s Enterprise access model.

Identity

  1. Review Five steps to securing your identity infrastructure and prioritize steps as appropriate for your Identity architecture.
  2. Consider migrating to Azure AD Security Defaults for your authentication policy- details can be found here.
  3. Eliminate your organization’s use of legacy authentication, if systems or applications still require it- review the guidance here.
    • As announced last year, the Exchange Team is planning to disable Basic Authentication for the EAS, EWS, POP, IMAP, and RPS protocols in the second half of 2021. As a point of clarity, Security Defaults and Authentication Policies are separate but provide complementary features. We recommend that customers use Authentication Policies to turn off Basic Authentication for a subset of Exchange Online protocols or to gradually turn off Basic Authentication across a large organization. While more details will come in future announcements, as mentioned in April, we plan to begin disabling Basic Authentication in existing tenants with no recorded usage as early as October 2020. We will provide notifications via Message Center posts before we disable Basic Authentication for any tenant.
  4. In order to help protect your ADFS/Azure AD Connect systems, beyond the ADFS guidance located, we recommend that you consider the following actions:
    • Treat your ADFS infrastructure and AD Connect infrastructure as a Tier 0 asset.
    • Restrict local administrative access to the system, including the account that is used to run the ADFS service.
      • The least privilege necessary for the account running ADFS is the Log on as a Service User Right Assignment.
    • Restrict administrative access to limited users and from limited IP address ranges by leveraging Windows Firewall policies for Remote Desktop.
      • It is recommended to set up a Tier 0 jump box or equivalent system.
    • Block all inbound SMB access to the systems from anywhere in the environment. See this resource for further details.
      • Get the Windows Firewall logs to a SIEM for historical and proactive monitoring.
    • If you are using a Service Account and your environment supports it, migrate from a Service Account to a group Managed Service Account (gMSA). If you cannot move to a gMSA, rotate the password on the Service Account to a complex password.
    • Ensure Verbose logging is enabled on your ADFS systems by executing the following commands:
Set-AdfsProperties -AuditLevel verbose
Restart-Service -Name adfssrv
Auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

Contributors: We thank the team at FireEye for their contributions and review.

The post Advice for incident responders on recovery from systemic identity compromises appeared first on Microsoft Security.

Empower your analysts to reduce burnout in your security operations center

July 28th, 2020 No comments

Effective cybersecurity starts with a skilled and empowered team. In a world with more remote workers and an evolving threat landscape, you need creative problem solvers defending your organization. Unfortunately, many traditional security organizations operate in a way that discourages growth, leading to burnout and high turnover.

Sixty-six percent of IT professionals say they have considered finding a new job with less stress. Fifty-one percent are even willing to take a pay cut. And the average tenure of a cybersecurity analyst is only one to three years. Even if stressed employees don’t quit, they may become cynical or lose focus, putting your organization at risk. Given the huge talent shortage—estimated between one and three million cybersecurity professionals—it’s critical to understand some of the factors that lead to burnout, so you can grow and retain your team. In this blog, I’ll provide insights into what drives burnout and walk through recommendations for using automation, training, and metrics to build a more effective security organization.

Burnout in the security operations center

Burnout starts with a vicious cycle. Because management has a limited budget, they staff many of their positions with entry-level roles. Security organizations are inherently risk-averse, so managers are reticent to give low-skilled roles decision-making authority. Security professionals in such an environment have few opportunities to use creative problem-solving skills, limiting the opportunity for them to grow their skills. If their skills don’t grow, they don’t advance and neither does the organization.

This cycle was documented in 2015, when Usenix studied burnout in a security operations center (SOC). By embedding an anthropologically trained computer science graduate in a SOC for 6 months, researchers identified four key areas that interact with each other to contribute to job satisfaction:

  • Skills: To effectively do their job, people need to know how to use security tools where they work. They also need to understand the security landscape and how it is changing.
  • Empowerment: Autonomy plays a major role in boosting morale.
  • Creativity: People often confront challenges that they haven’t seen before or that don’t map onto the SOC playbook. To uncover novel approaches they need to think outside the box, but creativity suffers when there is a lack of variation in operational tasks.
  • Growth: Growth is when a security analyst gains intellectual capacity. There is a strong connection between creativity and growth.

Image of the Human Capital Cycle

Graphic from A Human Capital Model for Mitigating Security Analyst Burnout, USENIX Association, 2015.

To combat the vicious cycle of burnout, you need to create a positive connection between these four areas and turn it into a virtuous cycle. Strategic investments in growth, automation, and metrics can make a real difference without requiring you to rewrite roles. Many of these recommendations have been implemented in the Microsoft SOC, resulting in a high-performing culture. I also believe you can expand these learnings to your entire security organization, who may also be dealing with stress related to remote work and COVID-19.

Create a continuous learning culture

Managers are understandably wary about giving too much decision-making authority to junior employees with limited skills, but if you give them no opportunities to try new ideas they won’t improve. Look for lower-risk opportunities for Tier One analysts to think outside set procedures. They may periodically make mistakes, but if you foster a culture of continuous learning and a growth mindset they will gain new skills from the experience.

To advance skills on your team, it’s also important to invest in training. The threat landscape changes so rapidly that even your most senior analysts will need to dedicate time to stay up to date. The Microsoft SOC focuses its training on the following competencies:

  • Technical tools/capabilities.
  • Our organization (mission and assets being protected).
  • Attackers (motivations, tools, techniques, habits, etc.).

Not all training should be formal. Most managers hire junior employees with the hope that they will learn on the job, but you need to create an environment that facilitates that. An apprenticeship model provides growth opportunities for both junior and senior members of your team.

Support operational efficiency with automation

At Microsoft, we believe the best use of artificial intelligence and automation is to support humans—not replace them. In the SOC, technology can reduce repetitive tasks so that people can focus on more complex threats and analysis. This allows defenders to use human intelligence to proactively hunt for adversaries that got past the first line of defense. Your organization will be more secure, and analysts can engage in interesting challenges.

Solutions like Microsoft Threat Protection can reduce some of the tedium involved in correlating threats across domains. Microsoft Threat Protection orchestrates across emails, endpoints, identity, and applications to automatically block attacks or prioritize incidents for analysts to pursue.

Azure Sentinel, a cloud-native SIEM, uses machine learning algorithms to reduce alert fatigue. Azure Sentinel can help identify complex, multi-stage attacks by using a probabilistic kill chain to combine low fidelity signals into a few actionable alerts.

It isn’t enough to apply machine learning to today’s monotonous challenges. Engage your team in active reflection and continuous improvement so they can finetune automation, playbooks, and other operations as circumstances change.

Track metrics that encourage growth

Every good SOC needs to track its progress to prove its value to the organization, make necessary improvements, and build the case for budgets. But don’t let your metrics become just another checklist. Measure data that is motivational to analysts and reflects the successes of the SOC. It’s also important to allocate the tracking of metrics to the right team members. For example, managers rather than analysts should be responsible for mapping metrics to budgets.

The Microsoft SOC tracks the following metrics:

Time to acknowledgment: For any alert that has a track record of 90 percent true positive, Microsoft tracks how long between when an alert starts “blinking” and when an analyst starts the investigation.

Time to remediate: Microsoft tracks how long it takes to remediate an incident, so we can determine if we are reducing the time that attackers have access to our environment.

Incidents remediated manually and via automation: To evaluate the effectiveness of our automation technology and to ensure we are appropriately staffed, we track how many incidents we remediate via automation versus manual effort.

Escalations between tiers: We also track issues that are remediated through tiers to accurately capture the amount of work that is happening at each tier. For example, if an incident gets escalated from Tier One to Tier Two, we don’t want to fully attribute the work to Tier Two or we may end up understaffing Tier One.

As organizations continue to confront the COVID-19 pandemic and eventually move beyond it, many security teams will be asked to do more with less. A continuous learning culture that uses automation and metrics to encourage growth will help you build a creative, problem-solving culture that is able to master new skills.

Read more about Microsoft Threat Protection.

Find out about Azure Sentinel.

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 Empower your analysts to reduce burnout in your security operations center appeared first on Microsoft Security.

Hello open source security! Managing risk with software composition analysis

July 20th, 2020 No comments

When first learning to code many people start with a rudimentary “Hello World” program. Building the program teaches developers the basics of a language as they write the code required to display “Hello World” on a screen. As developers get more skilled, the complexity of the programs they build increases.

But building a complex app entirely from scratch these days is not the norm because there are so many fantastic services and functions available to developers via libraries, plug-ins, and APIs that developers can consume as part of their solution. If you were building a website to show off your amazing nail art or community farm you wouldn’t build your own mapping tool for directions, you’d plug in a map tool service like Bing Maps. And if another developer has already built out a robust, well-vetted open-source cryptographic library, you’re better off using that rather than trying to roll your own.

Today’s apps are rich composites of components and services—many of which are open source. Just how many? Well, the Synopsis 2020 Open Source Security and Risk Analysis Report found that “open source components and libraries are the foundation of literally every application in every industry.” But just like any other software, open-source components must be assessed and managed to ensure that the final product is secure. So how can you take advantage of the benefits of open source without increasing risk? Software Composition Analysis (SCA)!

SCA Explained

SCA is a lifecycle management approach to tracking and governing the open source components in use in an organization. SCA provides insight into which components are being used, where they are being used, and if there are any security concerns or updates required. This approach provides the following benefits:

  • Quickly respond to vulnerabilities: Understanding which components you are using will allow you to take action when you learn of a security vulnerability. This is critical when components are re-used in a number of places. For example, the infamous “heartbleed” vulnerability in the popular OpenSSL library affected hundreds of thousands of web servers. When the ASN1 parsing issue was announced, attackers immediately began trying to exploit it. Organizations with an SCA program were better able to rapidly and completely replace or patch their systems, reducing their risk.
  • Provide guidance to your developers: Developers usually work under a deadline and need ways to build great apps quickly. If they don’t have a process for finding the right open source component, they may select one that’s risky. An approved repository of open source components and a process for getting new components into the repository can go a long way to support the development teams’ need for speed, in a secure way.

Define your strategy

A strong SCA program starts with a vision. If you document your strategy, developers and managers alike will understand your organization’s approach to open source. This will guide decision-making during open-source selection and contribution. Consider the following:

  • Licensing: Not all open source projects document their licensing, but if there isn’t a license, it’s technically not open source and is subject to copyright laws. Some licenses are very permissive and will let you do whatever you want with the code as long as you acknowledge the author. Other licenses, often referred to as copyleft licenses require that any derivative code be released with the same open source license. You also need to be aware of licenses that restrict patenting. Your strategy should outline the licensing that is appropriate for your business.
  • Supportability: What is your philosophy on support? If you have the right skills, you can choose to support the software yourself. Some open-source companies include support subscriptions that you can purchase. You can also hire third-party organizations to provide support. Make sure your team understands your support policy.
  • Security: There are several approaches that you can use to vet third-party code. Developers can evaluate public resources to uncover vulnerabilities. You can also require that they perform static analysis to uncover unreported security issues. If you want to be more comprehensive add dynamic analysis, code review, and security configuration review.

Establish governance

Your strategy will help you align on objectives and guidelines, but to put it in action, you’ll need to define processes and responsibilities.

  • Approved open source projects: Are there open source projects that are well-aligned with your organization that you’d like developers to consider first? How about open source software that is banned?
  • Approval process: Determine how you will engage legal experts to review licenses, how developers should request approvals, and who makes the final decision.
  • Security response: Document how you will respond and who is responsible if a security vulnerability is reported.
  • Support: Determine how you will engage support when non-security bugs are identified.

Create a toolkit

To manage your open source software, you need to track the components and open-source licenses that are currently in use. It’s also important to scan software for vulnerabilities. Open source and commercial tools are available and can be integrated into your continuous integration/continuous deployment process.

Microsoft Application Inspector is a static analysis tool that you can use to detect poor programming practices and other interesting characteristics in the code. It can help you identify unexpected features that require additional scrutiny.

Build engagement

Building consensus for the open-source security program is just as important as the program components. Make sure all your resources, approved open source licenses, and processes are easily accessible. When you roll out the program, clearly communicate why it’s important. Train your developers in the process and the tools they will use and provide regular updates as things change.

Open Source is a vibrant and valuable part of the development process. With the right program and tools in place, it can also be a well-governed and risk-managed process that helps developers deliver more secure software faster.

Read Microsoft’s guidance for managing third part components.

Find advice for selecting and gaining approval for open source in your organization.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Or reach out to me on LinkedIn or Twitter.

The post Hello open source security! Managing risk with software composition analysis appeared first on Microsoft Security.

How to gain 24/7 detection and response coverage with Microsoft Defender ATP

May 6th, 2020 No comments

This blog post is part of the Microsoft Intelligence Security Association guest blog series. To learn more about MISA, go here.

Whether you’re a security team of one or a dozen, detecting and stopping threats around the clock is a challenge. Security incidents don’t happen exclusively during business hours: attackers often wait until the late hours of the night to breach an environment.

At Red Canary, we work with security teams of all shapes and sizes to improve detection and response capabilities. Our Security Operations Team investigates threats in customer environments 24/7/365, removes false positives, and delivers confirmed threats with context. We’ve seen teams run into a wide range of issues when trying to establish after-hours coverage on their own, including:

  • For global enterprises, around-the-clock monitoring can significantly increase the pressure on a U.S.–based security team. If you have personnel around the world, a security team in a single time zone isn’t sufficient to cover the times that computing assets are used in those environments.
  • In smaller companies that don’t have global operations, the security team is more likely to be understaffed and unable to handle 24/7 security monitoring without stressful on-call schedules.
  • For the security teams of one, being “out of office” is a foreign concept. You’re always on. And you need to set up some way to monitor the enterprise while you’re away.

Microsoft Defender Advanced Threat Protection (ATP) is an industry leading endpoint security solution that’s built into Windows with extended capabilities to Mac and Linux servers. Red Canary unlocks the telemetry delivered from Microsoft Defender ATP and investigates every alert, enabling you to immediately increase your detection coverage and waste no time with false positives.

Here’s how those who haven’t started with Red Canary yet can answer the question, “How can I support my 24/7 security needs with Microsoft Defender ATP?”

No matter how big your security team is, the most important first step is notifying the right people based on an on-call schedule. In this post, we’ll describe two different ways of getting Microsoft Defender ATP alerts to your team 24×7 and how Red Canary has implemented this for our customers.

Basic 24/7 via email

Microsoft Defender Security Center allows you to send all Microsoft Defender ATP alerts to an email address. You can set up email alerts under Settings → Alert notifications.

MISA1

Email notification settings in Microsoft Defender Security Center.

These emails will be sent to your team and should be monitored for high severity situations after-hours.

If sent to a ticketing system, these emails can trigger tickets or after-hours pages to be created for your security team. We recommend limiting the alerts to medium and high severity so that you won’t be bothered for informational or low alerts.

MISA2

Setting up alert emails in Microsoft Defender ATP to be sent to a ticketing system.

Now any future alerts will create a new ticket in your ticketing system where you can assign security team members to on-call rotations and notify on-call personnel of new alerts (if supported). Once the notification is received by on-call personnel, they would then log into Microsoft Defender’s Security Center for further investigation and triage. 

Enhanced 24/7 via APIs

What if you want to ingest alerts to a system that doesn’t use email? You can do this by using the Microsoft Defender ATP APIs. First, you’ll need to have an authentication token. You can get the token like we do here:

MISA3

API call to retrieve authentication token.

Once you’ve stored the authentication token you can use it to poll the Microsoft Defender ATP API and retrieve alerts from Microsoft Defender ATP. Here’s an example of the code to pull new alerts.

MISA4

API call to retrieve alerts from Microsoft Defender ATP.

The API only returns a subset of the data associated with each alert. Here’s an example of what you might receive.

MISA5

Example of a Microsoft Defender ATP alert returned from the API.

You can then take this data and ingest it into any of your internal tools. You can learn more about how to access Microsoft Defender ATP APIs in the documentation. Please note, the limited information included in an alert email or API response is not enough to triage the behavior. You will still need to log into the Microsoft Defender Security Center to find out what happened and take appropriate action.

24/7 with Red Canary

By enabling Red Canary, you supercharge your Microsoft Defender ATP deployment by adding a proven 24×7 security operations team who are masters at finding and stopping threats, and an automation platform to quickly remediate and get back to business.

Red Canary continuously ingests all of the raw telemetry generated from your instance of Microsoft Defender ATP as the foundation for our service. We also ingest and monitor Microsoft Defender ATP alerts. We then apply thousands of our own proprietary analytics to identify potential threats that are sent 24/7 to a Red Canary detection engineer for review.

Here’s an overview of the process (to go behind the scenes of these operations check out our detection engineering blog series):

MISA6

Managed detection and response with Red Canary.

Red Canary is monitoring your Microsoft Defender ATP telemetry and alerts. If anything is a confirmed threat, our team creates a detection and sends it to you using a built-in automation framework that supports email, SMS, phone, Microsoft Teams/Slack, and more. Below is an example of what one of those detections might look like.

MISA7

Red Canary confirms threats and prioritizes them so you know what to focus on.

At the top of the detection timeline you’ll receive a short description of what happened. The threat has already been examined by a team of detection engineers from Red Canary’s Cyber Incident Response Team (CIRT), so you don’t have to worry about triage or investigation. As you scroll down, you can quickly see the results of the investigation that Red Canary’s senior detection engineers have done on your behalf, including detailed notes that provide context to what’s happening in your environment:

MISA8

Notes from Red Canary senior detection engineers (in light blue) provide valuable context.

You’re only notified of true threats and not false positives. This means you can focus on responding rather than digging through data to figure out what happened.

What if you don’t want to be woken up, you’re truly unavailable, or you just want bad stuff immediately dealt with? Use Red Canary’s automation to handle remediation on the fly. You and your team can create playbooks in your Red Canary portal to respond to threats immediately, even if you’re unavailable.

MISA9

Red Canary automation playbook.

This playbook allows you to isolate the endpoint (using the Machine Action resource type in the Microsoft Defender ATP APIs) if Red Canary identifies suspicious activity. You also have the option to set up Automate playbooks that depend on an hourly schedule. For example, you may want to approve endpoint isolation during normal work hours, but use automatic isolation overnight:

MISA10

Red Canary Automate playbook to automatically remediate a detection.

Getting started with Red Canary

Whether you’ve been using Microsoft Defender ATP since it’s preview releases or if you’re just getting started, Red Canary is the fastest way to accelerate your security operations program. Immediate onboarding, increased detection coverage, and a 24/7 CIRT team are all at your fingertips.

Terence Jackson, CISO at Thycotic and Microsoft Defender ATP user, describes what it’s like working with Red Canary:

“I have a small team that has to protect a pretty large footprint. I know the importance of detecting, preventing, and stopping problems at the entry point, which is typically the endpoint. We have our corporate users but then we also have SaaS customers we have to protect. Currently my team tackles both, so for me it’s simply having a trusted partner that can take the day-to-day hunting/triage/elimination of false positives and only provide actionable alerts/intel, which frees my team up to do other critical stuff.”

Red Canary is the fastest way to enhance your detection coverage from Microsoft Defender ATP so you know exactly when and where to respond.

Contact us to see a demo and learn more.

The post How to gain 24/7 detection and response coverage with Microsoft Defender ATP 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.

Defending the power grid against supply chain attacks: Part 3 – Risk management strategies for the utilities industry

April 22nd, 2020 No comments

Over the last fifteen years, attacks against critical infrastructure (figure1) have steadily increased in both volume and sophistication. Because of the strategic importance of this industry to national security and economic stability, these organizations are targeted by sophisticated, patient, and well-funded adversaries.  Adversaries often target the utility supply chain to insert malware into devices destined for the power grid. As modern infrastructure becomes more reliant on connected devices, the power industry must continue to come together to improve security at every step of the process.

Aerial view of port and freeways leading to downtown Singapore.

Figure 1: Increased attacks on critical infrastructure

This is the third and final post in the “Defending the power grid against supply chain attacks” series. In the first blog I described the nature of the risk. Last month I outlined how utility suppliers can better secure the devices they manufacture. Today’s advice is directed at the utilities. There are actions you can take as individual companies and as an industry to reduce risk.

Implement operational technology security best practices

According to Verizon’s 2019 Data Breach Investigations Report, 80 percent of hacking-related breaches are the result of weak or compromised passwords. If you haven’t implemented multi-factor authentication (MFA) for all your user accounts, make it a priority. MFA can significantly reduce the likelihood that a user with a stolen password can access your company assets. I also recommend you take these additional steps to protect administrator accounts:

  • Separate administrative accounts from the accounts that IT professionals use to conduct routine business. While administrators are answering emails or conducting other productivity tasks, they may be targeted by a phishing campaign. You don’t want them signed into a privileged account when this happens.
  • Apply just-in-time privileges to your administrator accounts. Just-in-time privileges require that administrators only sign into a privileged account when they need to perform a specific administrative task. These sign-ins go through an approval process and have a time limit. This will reduce the possibility that someone is unnecessarily signed into an administrative account.

 

Image 2

Figure 2: A “blue” path depicts how a standard user account is used for non-privileged access to resources like email and web browsing and day-to-day work. A “red” path shows how privileged access occurs on a hardened device to reduce the risk of phishing and other web and email attacks. 

  • You also don’t want the occasional security mistake like clicking on a link when administrators are tired or distracted to compromise the workstation that has direct access to these critical systems.  Set up privileged access workstations for administrative work. A privileged access workstation provides a dedicated operating system with the strongest security controls for sensitive tasks. This protects these activities and accounts from the internet. To encourage administrators to follow security practices, make sure they have easy access to a standard workstation for other more routine tasks.

The following security best practices will also reduce your risk:

  • Whitelist approved applications. Define the list of software applications and executables that are approved to be on your networks. Block everything else. Your organization should especially target systems that are internet facing as well as Human-Machine Interface (HMI) systems that play the critical role of managing generation, transmission, or distribution of electricity
  • Regularly patch software and operating systems. Implement a monthly practice to apply security patches to software on all your systems. This includes applications and Operating Systems on servers, desktop computers, mobile devices, network devices (routers, switches, firewalls, etc.), as well as Internet of Thing (IoT) and Industrial Internet of Thing (IIoT) devices. Attackers frequently target known security vulnerabilities.
  • Protect legacy systems. Segment legacy systems that can no longer be patched by using firewalls to filter out unnecessary traffic. Limit access to only those who need it by using Just In Time and Just Enough Access principles and requiring MFA. Once you set up these subnets, firewalls, and firewall rules to protect the isolated systems, you must continually audit and test these controls for inadvertent changes, and validate with penetration testing and red teaming to identify rogue bridging endpoint and design/implementation weaknesses.
  • Segment your networks. If you are attacked, it’s important to limit the damage. By segmenting your network, you make it harder for an attacker to compromise more than one critical site. Maintain your corporate network on its own network with limited to no connection to critical sites like generation and transmission networks. Run each generating site on its own network with no connection to other generating sites. This will ensure that should a generating site become compromised, attackers can’t easily traverse to other sites and have a greater impact.
  • Turn off all unnecessary services. Confirm that none of your software has automatically enabled a service you don’t need. You may also discover that there are services running that you no longer use. If the business doesn’t need a service, turn it off.
  • Deploy threat protection solutions. Services like Microsoft Threat Protection help you automatically detect, respond to, and correlate incidents across domains.
  • Implement an incident response plan: When an attack happens, you need to respond quickly to reduce the damage and get your organization back up and running. Refer to Microsoft’s Incident Response Reference Guide for more details.

Speak with one voice

Power grids are interconnected systems of generating plants, wires, transformers, and substations. Regional electrical companies work together to efficiently balance the supply and demand for electricity across the nation. These same organizations have also come together to protect the grid from attack. As an industry, working through organizations like the Edison Electric Institute (EEI), utilities can define security standards and hold manufacturers accountable to those requirements.

It may also be useful to work with The Federal Energy Regulatory Committee (FERC), The North American Electric Reliability Corporation (NERC), or The United States Nuclear Regulatory Commission (U.S. NRC) to better regulate the security requirements of products manufactured for the electrical grid.

Apply extra scrutiny to IoT devices

As you purchase and deploy IoT devices, prioritize security. Be careful about purchasing products from countries that are motivated to infiltrate critical infrastructure. Conduct penetration tests against all new IoT and IIoT devices before you connect them to the network. When you place sensors on the grid, you’ll need to protect them from both cyberattacks and physical attacks. Make them hard to reach and tamper-proof.

Collaborate on solutions

Reducing the risk of a destabilizing power grid attack will require everyone in the utility industry to play a role. By working with manufacturers, trade organizations, and governments, electricity organizations can lead the effort to improve security across the industry. For utilities in the United States, several public-private programs are in place to enhance the utility industry capabilities to defend its infrastructure and respond to threats:

Read Part 1 in the series: “Defending the power grid against cyberattacks

Read “Defending the power grid against supply chain attacks: Part 2 – Securing hardware and software

Read how Microsoft Threat Protection can help you better secure your endpoints.

Learn how MSRC developed an incident response plan

Bookmark the Security blog to keep up with our expert coverage on security matters. For more information about our security solutions visit our website. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Defending the power grid against supply chain attacks: Part 3 – Risk management strategies for the utilities industry appeared first on Microsoft Security.

MITRE ATT&CK APT 29 evaluation proves Microsoft Threat Protection provides deeper end to end view of advanced threats

April 21st, 2020 No comments

As attackers use more advanced techniques, it’s even more important that defenders have visibility not just into each of the domains in their environment, but also across them to piece together coordinated, targeted, and advanced attacks. This level of visibility will allow us to get ahead of attackers and close the gaps through which they enter. To illustrate that imperative, the 2019 MITRE ATT&CK evaluation centered on an advanced nation-state threat actor known to the industry as Advanced Persistent Threat (APT) 29 (also known as Cozy Bear) which largely overlaps with the activity group that Microsoft calls YTTRIUM. . The test involved a simulation of 58 attacker techniques in 10 kill chain categories.

Microsoft participated in the second MITRE ATT&CK endpoint detection product evaluation published today. The evaluation is designed to test security products based on the ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) framework, which is highly regarded in the security industry as one of the most comprehensive catalog of attacker techniques and tactics. Threat hunters use this framework to look for specific techniques that attackers often use to penetrate defenses. Testing that incorporates a comprehensive view of an environment’s ability to monitor and detect malicious activity with the existing tools that defenders have deployed across an organization is critical.

Although this test was focused on endpoint detection and response, MITRE ran the simulated APT29 attack from end to end and across multiple attack domains, meaning defenders benefited from visibility beyond just endpoint protection. This gave Microsoft the unique opportunity to bring Microsoft Threat Protection (MTP) to the test.

Microsoft Threat Protection expands Microsoft Defender ATP from endpoint detection and response (EDR) to an extended detection and response (XDR) solution, and is designed to provide extended detection and response by combining protection for endpoints (Microsoft Defender ATP), email and productivity tools (Office 365 ATP), identity (Azure ATP), and cloud applications (Microsoft Cloud App Security/MCAS). As customers face attacks across endpoints, cloud, applications and identities, MTP looks across these domains to understand the entire chain of events, identifies affected assets, like users, endpoints, mailboxes, and applications, and auto-heals them back to a safe state.

Microsoft Threat Protection delivers coverage across the entire kill chain, not just the endpoint

To fully execute the end to end attack simulation of APT29, MITRE required participants to turn off all proactive protection and blocking capabilities. For Microsoft Threat Protection, this meant that all the capabilities that would normally block this kind of attack such as automatic remediation flows, application isolation, attack surface reduction, network protection, exploit protection, controlled folder access, and next-gen antivirus prevention were turned off. However, Microsoft Threat Protection audit capabilities for these features enabled recording of a variety of points during the attack when MTP (had it been fully enabled) would have prevented or blocked execution, likely stopping the attack in its tracks.

During this evaluation Microsoft Threat Protection delivered on providing the deep and broad optics, near real time detection through automation, and a complete, end-to-end view of the attack story. Here is how Microsoft Threat Protection stood out:

  • Depth and breadth of optics: Our uniquely integrated operating system, directory, and cloud sensors contributed deep and broad telemetry coverage. AI-driven, cloud-powered models collaborating across domains identified malicious activities and raised alerts on attacker techniques across the entire attack kill chain:
    • Microsoft Defender ATP recorded and alerted on endpoint activities including advanced file-less techniques, privilege escalation, and credential theft and persistence – leveraging deep sensors like AMSI, WMI, and LDAP.
    • Azure ATP watched and detected account compromise at the domain level, and lateral movement, such as pass-the-hash and the more sophisticated pass-the-ticket (Golden Ticket attack).
    • Microsoft Cloud App Security identified exfiltration of data to the cloud (OneDrive).
  • Detection and containment in near real time:Nation state attacks of this magnitude can take place over the course of as little as a few hours, which means that Security Operations Centers (SOCs) often have little to no time to respond. Near-real-time automated detection of advanced techniques is critical to address this challenge. Where possible, active blocking, prevention and automatic containment will make the difference between an attempted versus a successful compromise. MTP’s prevention capabilities along with fast detection and behavioral blocking are exactly designed for this purpose.
  • A complete attack story: Throughout this evaluation, Microsoft Defender ATP, Azure ATP, and Microsoft Cloud App Security, combined with the expertise of Microsoft Threat Experts generated nearly 80 alerts – for SOC teams, manually following up on each one of these alerts is overwhelming. MTP consolidated the alerts into just two incidents, dramatically simplifying the volume of triage and investigation work needed. This gives the SOC the ability to prioritize and address the incident as a whole and enables streamlined triage, investigation, and automated response process against the complete attack. With MTP we have built in automation that identifies the complex links between attacker activities and builds correlations across domains that piece together the attack story with all of its related alerts, telemetry, evidence and affected assets into coherent incidents. These comprehensive incidents are then prioritized and escalated to the SOC.

 

Microsoft Threat Experts, our managed threat hunting service, also participated in the evaluation this year. Our security experts watched over the signals collected in real time and generated comprehensive, complementary alerts, which enriched the automated detections with additional details, insights and recommendations for the SOC.

Real world testing is critical

Attackers are using advanced, persistent, and intelligent techniques to penetrate today’s defenses. This method of testing leans heavily into real-world exploitations rather than those found solely in a lab or simulated testing environment. Having been part of the inaugural round of the MITRE ATT&CK evaluation in 2018, Microsoft enthusiastically took on the challenge again, as we believe this to be a great opportunity, alongside listening to customers and investing in research, to continuously drive our security products to excellence and protect our customers.

This year, for the first time, we were happy to answer the community call from MITRE, alongside other security vendors, to contribute unique threat intelligence and research content about APT29, as well as in evolving the evaluation based on the experience and feedback from last year, yielding a very collaborative and productive process.

Thank you to MITRE and our customers and partners for your partnership in helping us deliver more visibility and automated protection, detection, response, and prevention of threats for our customers.

– Moti Gindi, CVP, Microsoft Threat Protection

The post MITRE ATT&CK APT 29 evaluation proves Microsoft Threat Protection provides deeper end to end view of advanced threats 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.

CISO series: Lessons learned from the Microsoft SOC—Part 3b: A day in the life

December 23rd, 2019 No comments

The Lessons learned from the Microsoft SOC blog series is designed to share our approach and experience with security operations center (SOC) operations. We share strategies and learnings from our SOC, which protects Microsoft, and our Detection and Response Team (DART), who helps our customers address security incidents. For a visual depiction of our SOC philosophy, download our Minutes Matter poster.

For the next two installments in the series, we’ll take you on a virtual shadow session of a SOC analyst, so you can see how we use security technology. You’ll get to virtually experience a day in the life of these professionals and see how Microsoft security tools support the processes and metrics we discussed earlier. We’ll primarily focus on the experience of the Investigation team (Tier 2) as the Triage team (Tier 1) is a streamlined subset of this process. Threat hunting will be covered separately.

Image of security workers in an office.

General impressions

Newcomers to the facility often remark on how calm and quiet our SOC physical space is. It looks and sounds like a “normal” office with people going about their job in a calm professional manner. This is in sharp contrast to the dramatic moments in TV shows that use operations centers to build tension/drama in a noisy space.

Nature doesn’t have edges

We have learned that the real world is often “messy” and unpredictable, and the SOC tends to reflect that reality. What comes into the SOC doesn’t always fit into the nice neat boxes, but a lot of it follows predictable patterns that have been forged into standard processes, automation, and (in many cases) features of Microsoft tooling.

Routine front door incidents

The most common attack patterns we see are phishing and stolen credentials attacks (or minor variations on them):

  • Phishing email → Host infection → Identity pivot:

Infographic indicating: Phishing email, Host infection, and Identity pivot

  • Stolen credentials → Identity pivot → Host infection:

Infographic indicating: Stolen credentials, Identity pivot, and Host infection

While these aren’t the only ways attackers gain access to organizations, they’re the most prevalent methods mastered by most attackers. Just as martial artists start by mastering basic common blocks, punches, and kicks, SOC analysts and teams must build a strong foundation by learning to respond rapidly to these common attack methods.

As we mentioned earlier in the series, it’s been over two years since network-based detection has been the primary method for detecting an attack. We attribute this primarily to investments that improved our ability to rapidly remediate attacks early with host/email/identity detections. There are also fundamental challenges with network-based detections (they are noisy and have limited native context for filtering true vs. false positives).

Analyst investigation process

Once an analyst settles into the analyst pod on the watch floor for their shift, they start checking the queue of our case management system for incidents (not entirely unlike phone support or help desk analysts would).

While anything might show up in the queue, the process for investigating common front door incidents includes:

  1. Alert appears in the queue—After a threat detection tool detects a likely attack, an incident is automatically created in our case management system. The Mean Time to Acknowledge (MTTA) measurement of SOC responsiveness begins with this timestamp. See Part 1: Organization for more information on key SOC metrics.

Basic threat hunting helps keep a queue clean and tidy

Require a 90 percent true positive rate for alert sources (e.g., detection tools and types) before allowing them to generate incidents in the analyst queue. This quality requirement reduces the volume of false positive alerts, which can lead to frustration and wasted time. To implement, you’ll need to measure and refine the quality of alert sources and create a basic threat hunting process. A basic threat hunting process leverages experienced analysts to comb through alert sources that don’t meet this quality bar to identify interesting alerts that are worth investigating. This review (without requiring full investigation of each one) helps ensure that real incident detections are not lost in the high volume of noisy alerts. It can be a simple part time process, but it does require skilled analysts that can apply their experience to the task.

  1. Own and orient—The analyst on shift begins by taking ownership of the case and reading through the information available in the case management tool. The timestamp for this is the end of the MTTA responsiveness measurement and begins the Mean Time to Remediate (MTTR) measurement.

Experience matters

A SOC is dependent on the knowledge, skills, and expertise of the analysts on the team. The attack operators and malware authors you defend against are often adaptable and skilled humans, so no prescriptive textbook or playbook on response will stay current for very long. We work hard to take good care of our people—giving them time to decompress and learn, recruiting them from diverse backgrounds that can bring fresh perspectives, and creating a career path and shadowing programs that encourage them to learn and grow.

  1. Check out the host—Typically, the first priority is to identify affected endpoints so analysts can rapidly get deep insight. Our SOC relies on the Endpoint Detection and Response (EDR) functionality in Microsoft Defender Advanced Threat Protection (ATP) for this.

Why endpoint is important

Our analysts have a strong preference to start with the endpoint because:

  • Endpoints are involved in most attacks—Malware on an endpoint represents the sole delivery vehicle of most commodity attacks, and most attack operators still rely on malware on at least one endpoint to achieve their objective. We’ve also found the EDR capabilities detect advanced attackers that are “living off the land” (using tools deployed by the enterprise to navigate). The EDR functionality in Microsoft Defender ATP provides visibility into normal behavior that helps detect unusual command lines and process creation events.
  • Endpoint offers powerful insights—Malware and its behavior (whether automated or manual actions) on the endpoint often provides rich detailed insight into the attacker’s identity, skills, capabilities, and intentions, so it’s a key element that our analysts always check for.

Identifying the endpoints affected by this incident is easy for alerts raised by the Microsoft Defender ATP EDR, but may take a few pivots on an email or identity sourced alert, which makes integration between these tools crucial.

  1. Scope out and fill in the timeline—The analyst then builds a full picture and timeline of the related chain of events that led to the alert (which may be an adversary’s attack operation or false alarm positive) by following leads from the first host alert. The analyst travels along the timeline:
  • Backward in time—Track backward to identify the entry point in the environment.
  • Forward in time—Follow leads to any devices/assets an attacker may have accessed (or attempted to access).

Our analysts typically build this picture using the MITRE ATT&CK™ model (though some also adhere to the classic Lockheed Martin Cyber Kill Chain®).

True or false? Art or science?

The process of investigation is partly a science and partly an art. The analyst is ultimately building a storyline of what happened to determine whether this chain of events is the result of a malicious actor (often attempting to mask their actions/nature), a normal business/technical process, an innocent mistake, or something else.

This investigation is a repetitive process. Analysts identify potential leads based on the information in the original report, follow those leads, and evaluate if the results contribute to the investigation.

Analysts often contact users to identify whether they performed an anomalous action intentionally, accidentally, or was not done by them at all.

Running down the leads with automation

Much like analyzing physical evidence in a criminal investigation, cybersecurity investigations involve iteratively digging through potential evidence, which can be tedious work. Another parallel between cybersecurity and traditional forensic investigations is that popular TV and movie depictions are often much more exciting and faster than the real world.

One significant advantage of investigating cyberattacks is that the relevant data is already electronic, making it easier to automate investigation. For many incidents, our SOC takes advantage of security orchestration, automation, and remediation (SOAR) technology to automate investigation (and remediation) of routine incidents. Our SOC relies heavily on the AutoIR functionality in Microsoft Threat Protection tools like Microsoft Defender ATP and Office 365 ATP to reduce analyst workload. In our current configuration, some remediations are fully automatic and some are semi-automatic (where analysts review the automated investigations and propose remediation before approving execution of it).

Document, document, document

As the analyst builds this understanding, they must capture a complete record with their conclusions and reasoning/evidence for future use (case reviews, analyst self-education, re-opening cases that are later linked to active attacks, etc.).

As our analyst develops information on an incident, they capture the common, most relevant details quickly into the case such as:

  • Alert info: Alert links and Alert timeline
  • Machine info: Name and ID
  • User info
  • Event info
  • Detection source
  • Download source
  • File creation info
  • Process creation
  • Installation/Persistence method(s)
  • Network communication
  • Dropped files

Fusion and integration avoid wasting analyst time

Each minute an analyst wastes on manual effort is another minute the attacker has to spread, infect, and do damage during an attack operation. Repetitive manual activity also creates analyst toil, increases frustration, and can drive interest in finding a new job or career.

We learned that several technologies are key to reducing toil (in addition to automation):

  • Fusion—Adversary attack operations frequently trip multiple alerts in multiple tools, and these must be correlated and linked to avoid duplication of effort. Our SOC has found significant value from technologies that automatically find and fuse these alerts together into a single incident. Azure Security Center and Microsoft Threat Protection include these natively.
  • Integration—Few things are more frustrating and time consuming than having to switch consoles and tools to follow a lead (a.k.a., swivel chair analytics). Switching consoles interrupts their thought process and often requires manual tasks to copy/paste information between tools to continue their work. Our analysts are extremely appreciative of the work our engineering teams have done to bring threat intelligence natively into Microsoft’s threat detection tools and link together the consoles for Microsoft Defender ATP, Office 365 ATP, and Azure ATP. They’re also looking forward to (and starting to test) the Microsoft Threat Protection Console and Azure Sentinel updates that will continue to reduce the swivel chair analytics.

Stay tuned for the next segment in the series, where we’ll conclude our investigation, remediate the incident, and take part in some continuous improvement activities.

Learn more

In the meantime, bookmark the Security blog to keep up with our expert coverage on security matters and follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

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

Watch the CISO Spotlight Series: Passwordless: What’s It Worth.

Also, see our full CISO series and download our Minutes Matter poster for a visual depiction of our SOC philosophy.

The post CISO series: Lessons learned from the Microsoft SOC—Part 3b: A day in the life appeared first on Microsoft Security.

Norsk Hydro responds to ransomware attack with transparency

December 17th, 2019 No comments

Last March, aluminum supplier Norsk Hydro was attacked by LockerGoga, a form of ransomware. The attack began with an infected email and locked the files on thousands of servers and PCs. All 35,000 Norsk Hydro employees across 40 countries were affected. In the throes of this crisis, executives made three swift decisions:

  • Pay no ransom.
  • Summon Microsoft’s cybersecurity team to help restore operations.
  • Communicate openly about the breach.

Read Hackers hit Norsk Hydro with ransomware to learn why this approach helped the company recover and get back to business as usual.

The post Norsk Hydro responds to ransomware attack with transparency 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.