Microsoft

The post Microsoft named overall leader in KuppingerCole Leadership Compass for ITDR appeared first on Microsoft Security Blog.

Microsoft discovered a path traversal-affiliated vulnerability pattern in multiple popular Android applications that could enable a malicious application to overwrite files in the vulnerable application’s home directory. The implications of this vulnerability pattern include arbitrary code execution and token theft, depending on an application’s implementation. Arbitrary code execution can provide a threat actor with full control over an application’s behavior. Meanwhile, token theft can provide a threat actor with access to the user’s accounts and sensitive data.

We identified several vulnerable applications in the Google Play Store that represented over four billion installations. We anticipate that the vulnerability pattern could be found in other applications. We’re sharing this research so developers and publishers can check their apps for similar issues, fix as appropriate, and prevent introducing such vulnerabilities into new apps or releases.  As threats across all platforms continue to evolve, industry collaboration among security researchers, security vendors, and the broader security community is essential in improving security for all. Microsoft remains committed to working with the security community to share vulnerability discoveries and threat intelligence to protect users across platforms.

After discovering this issue, we identified several vulnerable applications. As part of our responsible disclosure policy, we notified application developers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) and worked with them to address the issue. We would like to thank the Xiaomi, Inc. and WPS Office security teams for investigating and fixing the issue. As of February 2024, fixes have been deployed for the aforementioned apps, and users are advised to keep their device and installed applications up to date.

Recognizing that more applications could be affected, we acted to increase developer awareness of the issue by collaborating with Google to publish an article on the Android Developers website, providing guidance in a high-visibility location to help developers avoid introducing this vulnerability pattern into their applications. We also wish to thank Google’s Android Application Security Research team for their partnership in resolving this issue.

In this blog post, we continue to raise developer and user awareness by giving a general overview of the vulnerability pattern, and then focusing on Android share targets, as they are the most prone to these types of attacks. We go through an actual code execution case study where we demonstrate impact that extends beyond the mobile device’s scope and could even affect a local network. Finally, we provide guidance to users and application developers and illustrate the importance of collaboration to improve security for all.

Overview: Data and file sharing on Android

The Android operating system enforces isolation by assigning each application its own dedicated data and memory space. To facilitate data and file sharing, Android provides a component called a content provider, which acts as an interface for managing and exposing data to the rest of the installed applications in a secure manner. When used correctly, a content provider provides a reliable solution. However, improper implementation can introduce vulnerabilities that could enable bypassing of read/write restrictions within an application’s home directory.

The Android software development kit (SDK) includes the FileProvider class, a subclass of ContentProvider that enables file sharing between installed applications. An application that needs to share its files with other applications can declare a FileProvider in its app manifest and declare the specific paths to share.

Every file provider has a property called authority, which identifies it system-wide, and can be used by the consumer (the app that wants to access the shared files) as a form of address. This content-based model bears a strong resemblance to the web model, but instead of the http scheme, consumers utilize the content scheme along with the authority, followed by a pseudo-path to the file that they want to access.

For example, assuming that the application com.example.server shares some files under the file:///data/data/com.example.server/files/images directory that it has previously declared as shared using the name shared_images, a consumer can use the content://[authority]/shared_images/[sub-path]/[filename] URI to index these files.

Access is given by the data sharing application most commonly using the grantUriPermissions attribute of the Android manifest, in combination with special flags that are used to define a read or write mode of operation. The data sharing application creates and sends an intent to the consumer that provides temporary fine-grained access to a file.  Finally, when a provider receives a file access request, it resolves the actual file path that corresponds to the incoming URI and returns a file descriptor to it.  

Implementation pitfalls

This content provider-based model provides a well-defined file-sharing mechanism, enabling a serving application to share its files with other applications in a secure manner with fine-grained control. However, we have frequently encountered cases where the consuming application doesn’t validate the content of the file that it receives and, most concerning, it uses the filename provided by the serving application to cache the received file within the consuming application’s internal data directory. If the serving application implements its own malicious version of FileProvider, it may be able to cause the consuming application to overwrite critical files.

Share targets

In simple terms, a share target is an Android app that declares itself to handle data and files sent by other apps. Common application categories that can be share targets include mail clients, social networking apps, messaging apps, file editors, browsers, and so on. In a common scenario, when a user clicks on a file, the Android operating system triggers the share-sheet dialog asking the user to select the component that the file should be sent to:

Figure 1. The Android share sheet dialog

While this type of guided file-sharing interaction itself may not trigger a successful attack against a share target, a malicious Android application can create a custom, explicit intent and send a file directly to a share target with a malicious filename and without the user’s knowledge or approval. Essentially, the malicious application is substituting its own malicious FileProvider implementation and provides a filename that is improperly trusted by the consuming application.

Figure 2. Dirty stream attack

In Figure 2, the malicious app, on the left, creates an explicit intent that targets the file processing component of the share target, on the right, and attaches a content URI as an intent’s extra. It then sends this intent to the share target using the startActivity API call.

After this point, most of the share targets that we have reviewed seem to follow a specific code pattern that includes the following steps:

1. Request the actual filename from the remote file provider
2. Use this filename to initialize a file that is subsequently used to initialize a file output stream
3. Create an input stream using the incoming content URI
4. Copy the input stream to the output stream

Since the rogue app controls the name as well as the content of the file, by blindly trusting this input, a share target may overwrite critical files in its private data space, which may lead to serious consequences.

Impact

We identified this vulnerability pattern in the then-current versions of several Android applications published on the Google Play Store, including at least four with more than 500 million installations each. In each case, we responsibly disclosed to the vendor. Two example vulnerable applications that we identified are Xiaomi Inc.’s File Manager (1B+ installs) and WPS Office (500M+ installs).

In Xiaomi Inc.’s File Manager, we were able to obtain arbitrary code execution in version V1-210567. After our disclosure, Xiaomi published version V1-210593, and we verified that the vulnerability has been addressed. In WPS Office, we were able to obtain arbitrary code execution in version 16.8.1. After our disclosure, WPS published and informed us that the vulnerability has been addressed as of version 17.0.0.

The potential impact varies depending on implementation specifics. For example, it’s very common for Android applications to read their server settings from the shared_prefs directory. In such cases, the malicious app can overwrite these settings, causing the vulnerable app to communicate with an attacker-controlled server and send the user’s authentication tokens or other sensitive information.

In a worst-case (and not so uncommon) scenario, the vulnerable application might load native libraries from its data directory (as opposed to the more secure /data/app-lib directory, where the libraries are protected from modification). In this case, the malicious application can overwrite a native library with malicious code that gets executed when the library is loaded. In the following section, we use Xiaomi Inc.’s File Manager to illustrate this case. We demonstrated the ability for a malicious application to overwrite the application’s shared preferences, write a native library to the application’s internal storage, and cause the application to load the library. These actions provided arbitrary code execution with the file manager’s user ID and permissions.

In the following sections, we focus on this case and delve into the technical details of this vulnerability pattern.

Case study: Xiaomi Inc.’s File Manager

Xiaomi Inc.’s File Manager is the default file manager application for Xiaomi devices and is published under the package name com.mi.android.globalFileexplorer on the Google Play Store, where it has been installed over one billion times.

Figure 3. Xiaomi’s File Manager profile according to Android rank (source: File Manager)

Besides having full access to the device’s external storage, the application requests many permissions, including the ability to install other applications:

Figure 4. A snapshot of the application’s permissions

Further, it offers a junk files cleaner plugin as well as the ability to connect to remote FTP and SMB shares:

Figure 5. Connecting to remote shares using the file manager Vulnerability assessment findings

During our investigation, we identified that the application exports the CopyFileActivity, an activity alias of the com.android.fileexplorer.activity.FileActivity, which is used to handle copy-from-to file operations:

Figure 6. Triggering the copy to CopyFileActivity

Since this activity is exported, it can be triggered by any application installed on the same device by using an explicit intent of action SEND or SEND_MULTIPLE and attaching a content URI corresponding to a file stream.

Upon receiving such an intent, the browser performs a validity check, which we found to be insufficient:

Figure 7. Validating an incoming copy file request

As depicted above, the initCopyOrMoveIntent method calls the checkValid method passing as an argument a content URI (steps 1 and 2). However, the checkValid method is designed to handle a file path, not a content URI. It always returns true for a content URI. Instead, a safer practice is to parse the string as a URI, including ensuring the scheme is the expected value (in this case, file, not content).The checkValid method verifies that the copy or move operation doesn’t affect the private directory of the app, by initializing a file object using the incoming string as an argument to the File class constructor and comparing its canonical path with the path that corresponds to the home directory of the application (steps 3 and 4). Given a content URI as a path, the File constructor normalizes it (following a Unix file system normalization), thus the getCanonicalPath method returns a string starting with “/content:/“, which will always pass the validity check. More specifically, the app performs a query to the remote content provider for the _size, _display_name and _data columns (see line 48 below). Then it uses the values returned by these rows to initialize the fields of an object of the com.android.fileexplorer.mode.c class:

Figure 8. Getting file metadata from the remote content provider

Given the case that the _display_name and _data values, returned from the external file provider, are relative paths to the destination directory, after exiting from the method above, these class fields will contain values like the ones depicted below:

Figure 9. The file model initialized after calling the method a

As shown above, the paths (variables d and e) of this file-model point to files within the home directory of the application, thus the file streams attached to the incoming intent are going to be written under the specific locations.

Getting code execution

As previously mentioned, the application uses a plugin to clean the device’s junk files:

Figure 10. The junk files cleaner plugin user interface

When the application loads this plugin, it makes use of two native libraries: libixiaomifileu.so, which fetches from the /data/app directory, and libixiaomifileuext.so from the home directory:

Figure 11. Tracing the loaded native libraries using medusa

As apps don’t have write access to the /data/app folder, the libixiaomifileu.so file stored there cannot be replaced. The easiest way to get code execution is to replace the libixiaomifileuext.so with a malicious one. However, an attempt to do so would fail since in this particular case, the vulnerability that we described can only be used to write new files within the home directory, not overwrite existing files. Our next inquiry was to determine how the application loads the libixiaomifileu.so.

Our assessment showed that before the application loads this library, it follows the following steps:

1. Calculate the hash of the file libixiaomifileu.so, located in the /data/app directory

2. Compare this hash with the value assigned to the “libixiaomifileu.so_hm5” string, fetched from the com.mi.android.globalFileexprorer_preferences.xml file

Figure 12. the com.mi.android.globalFileexprorer_preferences.xml

3. If the values don’t match, search for the libixiaomifileu.so file in the /files/lib path in the home directory

4. If the file is found there, calculate its hash and compare it again with the value from the shared_preferences folder

5. If the hashes match, load the file under the /files/lib using the System.load method

Given this behavior, in order to get code execution with the file manager’s user ID, an attacker must take the following steps:

1. Use the path traversal vulnerability to save a malicious library as /files/lib/libixiaomifileu.so (the file does not already exist in that directory, so overwriting is not an issue)

2. Calculate the hash of this library to replace the value of the libixiaomifileu.so_hm5 string

3. Trigger the junk cleaner plugin with an explicit intent, since the activity that loads the native libraries is exported

An acute reader might have noticed that the second step requires the attacker to force the browser to overwrite the com.mi.android.globalFileexprorer_preferences.xml, which, as we already mentioned, was not possible.

To overcome this restriction, we referred to the actual implementation of the SharedPreferences class, where we found that when an Android application uses the getSharedPreferences API method to retrieve an instance of the SharedPreferences class, giving the name of the shared preferences file as an argument, then the constructor of the SharedPreferencesImpl class performs the following steps:

1. Create a new file object using the name provided to the getSharedPreferences method, followed by the .xml extension, followed by the .bak extension

2. Check if this file exists, and in case it does, delete the original xml file and replace it with the one created in the first step

Through this behavior, we were able to save the com.mi.android.globalFileexprorer_preferences.xml.bak under the shared preferences folder (as during the application’s runtime it is unlikely to exist), so when the app tried to verify the hash, the original xml file was already replaced by our own copy. After this point, by using a single intent to start the junk cleaner plugin, we were able to trick the application to load the malicious library instead of the one under the /data/app folder and get code execution with the browser’s user ID.

Impact

One reason we chose to use this app as a showcase is because the impact extends beyond the user’s mobile device. The application gives the option to connect to remote file shares using the FTP and SMB protocols and the user credentials are saved in clear text in the /data/data/com.mi.android.globalFileexplorer/files/rmt_i.properties file:

Figure 13. SMB/FTP credentials saved in clear text

If a third party app was able to exploit this vulnerability and obtain code execution, an attacker could retrieve these credentials. The impact would then extend even further, since by the time that a user requests to open a remote share, the browser creates the directory /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ where it saves the files that the user retrieves:

Figure 14. SMB shared files, saved in the external storage

This means that a remote attacker would be able to read or write files to SMB shares of a local network, assuming that the device was connected to it. The same stands for FTP shares as they are handled exactly in the same way:

Figure 15. FTP shared files, saved in the external storage

In summary, the exploitation flow is depicted in the figure below:

Figure 16. Getting remote access to local shares

In step 1, the user opens a malicious app that may pose as a file editor, messaging app, mail client, or any app in general and request the user to save a file. By the time that the user attempts to save such a file, no matter what destination path they choose to save it, the malicious app forces the file browser app to write it under its internal /files/lib folder. Then, the malicious app can start the junk cleaner using an explicit intent (no user interaction is required) and this will lead to code execution with the browser’s ID (step 2).

In step 3, the attacker uses the arbitrary code execution capability to retrieve the SMB and FTP credentials from the rmt_i.properties file. Subsequently, the attacker can now jump to step 5 and access the shares directly using the stolen credentials. Alternatively, after retrieving the share credentials, the mobile device can connect to a local network (step 4) and access an SMB or FTP share, allowing the attacker to access the shared files through the /sdcard/Android/data/com.mi.android.globalFileexplorer/files/usbTemp/ folder (step 5).

Recommendations

Recognizing that this vulnerability pattern may be widespread, we shared our findings with Google’s Android Application Security Research team. We collaborated with Google to author guidance for Android application developers to help them recognize and avoid this pattern. We recommend developers and security analysts familiarize themselves with the excellent Android application security guidance provided by Google as well as make use of the Android Lint tool included with the Android SDK and integrated with Android Studio (supplemented with Google’s additional security-focused checks) to identify and avoid potential vulnerabilities. GitHub’s CodeQL also provides capabilities to identify vulnerabilities.

To prevent these issues, when handling file streams sent by other applications, the safest solution is to completely ignore the name returned by the remote file provider when caching the received content. Some of the most robust approaches we encountered use randomly generated names, so even in the case that the content of an incoming stream is malformed, it won’t tamper with the application.

In cases where such an approach is not feasible, developers need to take extra steps to ascertain that the cached file is written to a dedicated directory. As an incoming file stream is usually identified by a content URI, the first step is to reliably identify and sanitize the corresponding filename. Besides filtering characters that may lead to a path traversal and before performing any write operation, developers must verify that the cached file is within the dedicated directory by performing a call to the File.getCanonicalPath and validating the prefix of the returned value.

Another area to safeguard is in the way developers try to extract a filename from a content URI. Developers often use Uri.getLastPathSegment(), which returns the (URL) decoded value of the last path URI segment. An attacker can craft a URI with URL encoded characters within this segment, including characters used for path traversal. Using the returned value to cache a file can again render the application vulnerable to this type of attack.

For end users, we recommend keeping mobile applications up to date through the Google Play Store (or other appropriate trusted source) to ensure that updates addressing known vulnerabilities are installed. Users should only install applications from trusted sources to avoid potentially malicious applications. We recommend users who accessed SMB or FTP shares through the Xiaomi app before updates to reset credentials and to investigate for any anomalous behavior. Microsoft Defender for Endpoint on Android can alert users and enterprises to malicious applications, and Microsoft Defender Vulnerability Management can identify installed applications with known vulnerabilities.

Dimitrios Valsamaras

Microsoft Threat Intelligence

References

• https://www.blackhat.com/asia-23/briefings/schedule/index.html#dirty-stream-attack-turning-android-share-targets-into-attack-vectors-30234
• https://developer.android.com/privacy-and-security/risks/untrustworthy-contentprovider-provided-filename
• https://developer.android.com/reference/androidx/core/content/FileProvider
• https://developer.android.com/guide/topics/manifest/provider-element#gprmsn
• https://play.google.com/store/apps/details?id=com.mi.android.globalFileexplorer
• https://play.google.com/store/apps/details?id=cn.wps.moffice_eng
• https://googlesamples.github.io/android-custom-lint-rules/checks/UnsafeDynamicallyLoadedCode.md.html
• https://androidrank.org/application/file_manager/com.mi.android.globalFileexplorer
• https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/SharedPreferencesImpl.java;l=150
• https://developer.android.com/privacy-and-security/risks
• https://developer.android.com/studio/write/lint#gradle
• https://github.com/google/android-security-lints/
• https://codeql.github.com/codeql-query-help/java/

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post “Dirty stream” attack: Discovering and mitigating a common vulnerability pattern in Android apps appeared first on Microsoft Security Blog.

The post ​​Investigating industrial control systems using Microsoft’s ICSpector open-source framework appeared first on Microsoft Security Blog.

The cloud security market continues to evolve, reflecting the diligent efforts of security professionals globally. They are at the forefront of developing innovative solutions and strategies to address the sophisticated tactics of cyberattackers. The necessity for these solutions to stay ahead of potential exploitation methods is clear. One notable advancement in this ongoing effort is the emergence of the cloud-native application protection platform, or CNAPP. In Microsoft’s guide “From plan to deployment: implementing a cloud-native application protection platform (CNAPP) strategy,” we explore all the aspects of this emerging trend, what it can mean for your organization, and how to get started.

CNAPP combines several cybersecurity capabilities—cloud security posture management (CSPM), cloud infrastructure entitlement management (CIEM), and cloud workload protection (CWP), among others—into one platform. This platform protects your organization through every operation, from concept development to runtime use. And it’s tailored to applications native to a multicloud environment. As a result, you can both ensure management access and strengthen app-related defenses against potential vulnerabilities in multicloud setups.

Choosing CNAPP as your solution can help chief information security officers (CISOs) build impact.1 When weighing the value of CNAPP, consider these numbers:

• 40% of organizations used a CNAPP in 2023 and an additional 45% expect to use one by the end of 2024.2
• 87% of organizations embrace multicloud.3
• 82% of breaches involved data stored in the cloud.4
• $4.45 million is the average cost of a data breach.5
• 54% of organizations do not include security in the development phase.6

Read on for five of the biggest insights found in the guide and download “From plan to deployment: implementing a cloud-native application protection platform (CNAPP) strategy” to dive deeper into this important subject. Use it as a valuable resource to guide your CNAPP planning.

Implementing a CNAPP strategy

Learn how a cloud-native application protection platform can strengthen your organization's security strategy.

Get the guide Insight #1: AI can tighten security and deliver insights

AI and machine learning play key roles in threat mitigation and security operations for cloud security. In fact, they could even be considered the backbone of these strategies because they give you the ability to analyze and respond to threats in real-time. Seconds matter in cybersecurity and could be the difference between minimal and major damage from a cyberattack.

AI and machine learning can also provide an assist by increasing predictive analysis and automating security tasks, helping your employees prioritize strategic security tasks. Manually managing today’s complex cloud infrastructures simply isn’t possible. The key is to include human oversight with human-in-the-loop monitoring of the technologies.

Insight #2: CNAPP can address challenges like alert overload and more

CNAPP holds day-to-day ease for security teams and strategic value for decision-makers. And there’s an urgent need for an end-to-end platform for cloud security—even better if powered by AI and machine learning. CNAPP helps you address some of the biggest challenges in cloud security, including:

• Building security into software during development: Security as code, which involves building security into software during development, will keep gaining momentum. CNAPP benefits the development process in several ways, including ensuring security is part of application development and forging collaboration between the developers and security teams.  
• Improving multicloud security posture: With CNAPP solutions, you can get an aggregation and analysis of data from multiple cloud platforms and services in a unified dashboard. These centralized insights can help security teams prioritize tasks more easily. Expanding multicloud visibility and enhancing multiplatform protection are two advantages of recent Microsoft Security innovations.
• Decreasing costs and tackling advanced cyberthreats: Security operations center (SOC) analysts and security admins could be easily overwhelmed by the modern digital threat landscape and frustrated by the number of signals. The predictive analytics of CNAPP solutions can make it easier for them to identify and mitigate potential risks while automating security responses to threats.

Insight #3: Effective cybersecurity takes a good partner  

The next wave of multicloud security with Microsoft Defender for Cloud

Read more

Keeping user needs in mind, Microsoft has its own CNAPP solution—Microsoft Defender for Cloud. This comprehensive security solution has robust security features to safeguard a wide array of resources, including servers, containers, databases, applications, and, crucially, data storage solutions like Microsoft Azure Storage, across various cloud platforms. Implementing Microsoft Defender for Cloud can protect against current threats and position your organization to confidently address emerging security threats in the cloud.

Cybersecurity is a dual effort between cloud service providers and users. Microsoft Defender for Cloud models this collaborative approach with a more integrated and proactive strategy than is common with traditional security. Among other attributes, it aligns with DevOps, features rapid deployment capabilities, and offers two levels of CSPM functionality—foundational and premium from an offering called Microsoft Defender Cloud Security Posture Management. Deploying CSPM services should be a part of your CNAPP strategy.

It also integrates with other cybersecurity solutions. But given the way Microsoft embraces innovation, it’s probably no surprise that we’ll continue to evolve this solution to keep pace with fluid technological advancement. So, as usual, watch this space for exciting announcements to come.

Insight #4: Operationalizing CNAPP is a multipronged approach

With any solution, the benefits can’t be realized if your users aren’t adopting it. Operationalizing Microsoft Defender for Cloud takes both integrating it into daily operations and satisfying your users’ needs by continuously evolving cloud security. You want your users to manage it and use the platform’s capabilities. This includes its functionalities across Microsoft Azure, Amazon Web Services, and Google Cloud Platform.

Other factors of operationalizing CNAPP include:

• Monitoring continuously, evaluating risk, and assessing status.
• Managing identity entitlement.
• Training employees to use security tools.
• Setting processes in place that can mitigate and remediate unhealthy resources.
• Fostering a culture of security awareness.

Insight #5: CNAPP is a critical part of a modern SOC

The SOC is critical and you strive for it to be efficient and effective. The insights from a CNAPP like Microsoft Defender for Cloud can dramatically transform SOC operations due to its total visibility, real-time monitoring, compliance and risk management tools, multiple integrations, and advanced analytics.

You can take a more proactive, strategic approach to cloud security with capabilities like:

• Detailed insights into threats and vulnerabilities, including their possible severity and impact.
• Automated compliance assessments based on industry standards.
• Post-incident analysis support through incident information.

Strengthening the SOC even further is a new Microsoft Defender for Cloud integration with Microsoft Defender XDR. You gain access to Defender for Cloud alerts and incidents within the Microsoft Defender portal for richer investigation context.

These highlights are just the beginning of what you can accomplish with CNAPP.

Explore the future of CNAPP and cloud security

Building a secure-first organization is critical to counter the continual stream of cyberthreats and the increasingly sophisticated nature of them. The future holds significant promise for CNAPP, and Microsoft is leading in this effort with solutions like Microsoft Defender for Cloud. Get details on CNAPP use case scenarios and Defender for Cloud’s integrations with other Microsoft products—and strategies for adopting and operationalizing it—in our guide “From plan to deployment: implementing a cloud-native application protection platform (CNAPP) strategy.” Or, watch our podcast for an expert discussion on how CNAPP helps you address modern challenges. Learn more about how Defender for Cloud can help you protect your multicloud resources, workloads, and apps.

Learn more

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 on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

1Want to build impact as a CISO? Choose CNAPP as your solution, CSO. May 26, 2024. 

2The future of cloud security: Top trends to watch in 2024, InfoWorld. March 14, 2024. 

32023 State of the Cloud Report, Flexera.

4Microsoft Enterprise DevOps Report. 

5Cost of a Data Breach Report, IBM. 2023. 

6Microsoft Cloud Security Priorities and Practices Research. 

The post 5 ways a CNAPP can strengthen your multicloud security environment appeared first on Microsoft Security Blog.

There’s an increasing demand for skilled cybersecurity professionals. It’s being driven by a surge in cyberthreats and more sophisticated attackers. However, many employers are hesitant to fill open cybersecurity roles and are hiring conservatively in case of economic downturn—even though they understand the importance of having the right expertise to mitigate contemporary cyberrisks.

Organizations face an increasingly complex cybersecurity landscape. The cybersecurity workforce growth rate lags behind the necessary 12.6% annual expansion to effectively counter cyberthreats, only achieving an 8.7% increase. This shortfall leaves a gap of approximately 4 million professionals worldwide. Amidst this challenge, companies navigate layoffs, budget cuts, and hiring freezes with expectations of further economic tightening in 2024.1

Windows Internals Book

Learn more

Yet cybersecurity expertise is crucial, especially when dealing with complex issues like analyzing Windows Internals during forensic investigations—a task that requires deep technical knowledge to interpret various artifacts and timestamps accurately. To help like-minded defenders tackle this difficult task, Microsoft Incident Response experts have created a guide on using Windows Internals for forensic investigations.

Guidance for Incident Responders

The new guide from the Microsoft Incident Response team helps simplify forensic investigations.

Get the guide Microsoft Incident Response guide highlights

Our guide serves as an essential resource, meticulously structured to illuminate commonly seen, but not commonly understood, Windows Internals features in forensic investigations. Understanding these artifacts will strengthen your ability to conduct Windows forensic analysis. Equipped with this information and your new findings, you’ll be able to construct more complete timelines of activity. It includes the following topics:

• AmCache’s contribution to forensic investigations: The AmCache registry hive’s role in storing information about executed and installed applications is crucial, yet it’s often mistakenly believed to capture every execution event. This misunderstanding can lead to significant gaps in forensic narratives, particularly where malware employs evasion techniques. Moreover, the lack of execution timestamp specificity in AmCache data further complicates accurate timeline reconstruction.
• Browser forensics: Uncovering digital behaviors: The comprehensive analysis of browser artifacts is fraught with challenges, particularly regarding the interpretation of local file access records. The misconception that browsers do not track local file access can lead to significant oversight in understanding user behavior, underscoring the need for thorough and nuanced analysis of browser data.
• The role of Link files and Jump Lists in forensics: Link, or LNK, files and Jump Lists are pivotal for documenting user behaviors. However, investigators sometimes neglect the fact that they’re prone to manipulation or deletion by users or malware. This oversight can lead to flawed conclusions. Furthermore, Windows’ automatic maintenance tasks, which can alter or delete these artifacts, add another layer of complexity to their analysis.
• Prefetch files and program execution: Prefetch files’ role in improving application launch times and their forensic value in tracking application usage is well-documented. However, the common error of conflating the prefetch file’s creation date with the last execution date of an application leads to mistaken conclusions about usage patterns. Also, overlooking the aggregation of data from multiple prefetch files can result in a fragmented understanding of application interactions over time.
• ShellBags forensic analysis: ShellBags, with their ability to record user interactions with the File Explorer environment, offer a rich source of information. Yet not all investigators recognize that ShellBags track deleted and moved folders, in addition to current ones. This oversight can lead to incomplete reconstructions of user activities.
• Shimcache’s forensic evolution: The Shimcache has long served as a source of forensic information, particularly as evidence of program execution. However, the changes in Windows 10 and later have significantly impacted the forensic meaning of Shimcache artifacts: indicating file presence, and not indicating execution. This misunderstanding can mislead investigators, especially since Shimcache logs the last modification timestamp, not execution time, and data is only committed to disk upon shutdown or reboot.
• Forensic insights with SRUM: SRUM’s tracking of application execution, network activity, and resource consumption is a boon for forensic analysts. However, the wealth of data can also be overwhelming, leading to crucial details being missed or misinterpreted. For instance, the temporal discrepancies between the SRUM database and system logs can confuse investigators, making it challenging to align activities accurately. Additionally, the finite storage of SRUM data means older information can be overwritten without notice, a fact that’s often overlooked, resulting in gaps in data analysis.
• The importance of User Access Logging (UAL): UAL’s tracking of user activities based on roles and access origins is essential for security analysis, especially since this feature is designed for Windows Server operating systems (specifically 2012 and later). Its vast data volume can be daunting, leading to potential oversight of unusual access patterns or lateral movements. Additionally, the annual archiving system of UAL data can cause confusion regarding the longevity and accessibility of logs, impacting long-term forensic investigations.
• Decoding UserAssist for forensic evidence: The UserAssist feature’s tracking of GUI-based program interactions is often misunderstood, with analysts mistakenly prioritizing run counts over focus time. This misstep can lead to inaccurate assumptions about application usage, as focus time—a more reliable indicator of execution—gets overlooked.

Why read this guide today

Bridging the gap between gaining insights from the Microsoft Incident Response team and the practical application of these strategies within your own organization underscores a journey from knowledge acquisition to operational implementation. By downloading the guide, you’re not just accessing a wealth of expert strategies, you’re initiating a critical shift towards a more resilient cybersecurity posture. This transition naturally leads to the understanding that while the right tools and strategies are vital, the true essence of cybersecurity lies in the practice and adoption of a security-minded culture within your organization.

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 on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

1How the Economy, Skills Gap and Artificial Intelligence are Challenging the Global Cybersecurity Workforce, ISC2. 2023.

The post New Microsoft Incident Response guide helps simplify cyberthreat investigations appeared first on Microsoft Security Blog.

Microsoft Threat Intelligence is publishing results of our longstanding investigation into activity by the Russian-based threat actor Forest Blizzard (STRONTIUM) using a custom tool to elevate privileges and steal credentials in compromised networks. Since at least June 2020 and possibly as early as April 2019, Forest Blizzard has used the tool, which we refer to as GooseEgg, to exploit the CVE-2022-38028 vulnerability in Windows Print Spooler service by modifying a JavaScript constraints file and executing it with SYSTEM-level permissions. Microsoft has observed Forest Blizzard using GooseEgg as part of post-compromise activities against targets including Ukrainian, Western European, and North American government, non-governmental, education, and transportation sector organizations. While a simple launcher application, GooseEgg is capable of spawning other applications specified at the command line with elevated permissions, allowing threat actors to support any follow-on objectives such as remote code execution, installing a backdoor, and moving laterally through compromised networks.

Forest Blizzard often uses publicly available exploits in addition to CVE-2022-38028, such as CVE-2023-23397. Linked to the Russian General Staff Main Intelligence Directorate (GRU) by the United States and United Kingdom governments, Forest Blizzard primarily focuses on strategic intelligence targets and differs from other GRU-affiliated and sponsored groups, which Microsoft has tied to destructive attacks, such as Seashell Blizzard (IRIDIUM) and Cadet Blizzard (DEV-0586). Although Russian threat actors are known to have exploited a set of similar vulnerabilities known as PrintNightmare (CVE-2021-34527 and CVE-2021-1675), the use of GooseEgg in Forest Blizzard operations is a unique discovery that had not been previously reported by security providers. Microsoft is committed to providing visibility into observed malicious activity and sharing insights on threat actors to help organizations protect themselves. Organizations and users are to apply the CVE-2022-38028 security update to mitigate this threat, while Microsoft Defender Antivirus detects the specific Forest Blizzard capability as HackTool:Win64/GooseEgg.

This blog provides technical information on GooseEgg, a unique Forest Blizzard capability. In addition to patching, this blog details several steps users can take to defend themselves against attempts to exploit Print Spooler vulnerabilities. We also provide additional recommendations, detections, and indicators of compromise. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the necessary information to secure their accounts.

Who is Forest Blizzard?

Forest Blizzard primarily targets government, energy, transportation, and non-governmental organizations in the United States, Europe, and the Middle East. Microsoft has also observed Forest Blizzard targeting media, information technology, sports organizations, and educational institutions worldwide. Since at least 2010, the threat actor’s primary mission has been to collect intelligence in support of Russian government foreign policy initiatives. The United States and United Kingdom governments have linked Forest Blizzard to Unit 26165 of the Russian Federation’s military intelligence agency, the Main Intelligence Directorate of the General Staff of the Armed Forces of the Russian Federation (GRU). Other security researchers have used GRU Unit 26165, APT28, Sednit, Sofacy, and Fancy Bear to refer to groups with similar or related activities.

GooseEgg

Microsoft Threat Intelligence assesses Forest Blizzard’s objective in deploying GooseEgg is to gain elevated access to target systems and steal credentials and information. While this actor’s TTPs and infrastructure specific to the use of this tool can change at any time, the following sections provide additional details on Forest Blizzard tactics, techniques, and procedures (TTPs) in past compromises.

Launch, persistence, and privilege escalation

Microsoft has observed that, after obtaining access to a target device, Forest Blizzard uses GooseEgg to elevate privileges within the environment. GooseEgg is typically deployed with a batch script, which we have observed using the name execute.bat and doit.bat. This batch script writes the file servtask.bat, which contains commands for saving off/compressing registry hives. The batch script invokes the paired GooseEgg executable and sets up persistence as a scheduled task designed to run servtask.bat.

Figure 1. Batch file

The GooseEgg binary—which has included but is not limited to the file names justice.exe and DefragmentSrv.exe—takes one of four commands, each with different run paths. While the binary appears to launch a trivial given command, in fact the binary does this in a unique and sophisticated manner, likely to help conceal the activity.

The first command issues a custom return code 0x6009F49F and exits; which could be indicative of a version number. The next two commands trigger the exploit and launch either a provided dynamic-link library (DLL) or executable with elevated permissions. The fourth and final command tests the exploit and checks that it has succeeded using the whoami command.

Microsoft has observed that the name of an embedded malicious DLL file typically includes the phrase “wayzgoose”; for example, wayzgoose23.dll. This DLL, as well as other components of the malware, are deployed to one of the following installation subdirectories, which is created under C:\ProgramData. A subdirectory name is selected from the list below:

• Microsoft
• Adobe
• Comms
• Intel
• Kaspersky Lab
• Bitdefender
• ESET
• NVIDIA
• UbiSoft
• Steam

A specially crafted subdirectory with randomly generated numbers and the format string \v%u.%02u.%04u is also created and serves as the install directory. For example, a directory that looks like C:\ProgramData\Adobe\v2.116.4405 may be created. The binary then copies the following driver stores to this directory:

• C:\Windows\System32\DriverStore\FileRepository\pnms003.inf_*
• C:\Windows\System32\DriverStore\FileRepository\pnms009.inf_*

Figure 2. GooseEgg binary adding driver stores to an actor-controlled directory

Next, registry keys are created, effectively generating a custom protocol handler and registering a new CLSID to serve as the COM server for this “rogue” protocol. The exploit replaces the C: drive symbolic link in the object manager to point to the newly created directory. When the PrintSpooler attempts to load C:\Windows\System32\DriverStore\FileRepository\pnms009.inf_amd64_a7412a554c9bc1fd\MPDW-Constraints.js, it instead is redirected to the actor-controlled directory containing the copied driver packages.

Figure 3. Registry key creation Figure 4. C: drive symbolic link hijack

The “MPDW-constraints.js” stored within the actor-controlled directory has the following patch applied to the convertDevModeToPrintTicket function:

function convertDevModeToPrintTicket(devModeProperties, scriptContext, printTicket) {try{ printTicket.XmlNode.load('rogue9471://go'); } catch (e) {}

The above patch to the convertDevModeToPrintTicket function invokes the “rogue” search protocol handler’s CLSID during the call to RpcEndDocPrinter. This results in the auxiliary DLL wayzgoose.dll launching in the context of the PrintSpooler service with SYSTEM permissions. wayzgoose.dll is a basic launcher application capable of spawning other applications specified at the command line with SYSTEM-level permissions, enabling threat actors to perform other malicious activities such as installing a backdoor, moving laterally through compromised networks, and remotely executing code.

Recommendations

Microsoft recommends the following mitigations defend against attacks that use GooseEgg.

Reduce the Print Spooler vulnerability

Microsoft released a security update for the Print Spooler vulnerability exploited by GooseEgg on October 11, 2022 and updates for PrintNightmare vulnerabilities on June 8, 2021 and July 1, 2021. Customers who have not implemented these fixes yet are urged to do so as soon as possible for their organization’s security. In addition, since the Print Spooler service isn’t required for domain controller operations, Microsoft recommends disabling the service on domain controllers. Otherwise, users can install available Windows security updates for Print Spooler vulnerabilities on Windows domain controllers before member servers and workstations. To help identify domain controllers that have the Print Spooler service enabled, Microsoft Defender for Identity has a built-in security assessment that tracks the availability of Print Spooler services on domain controllers.

Be proactively defensive

• For customers, follow the credential hardening recommendations in our on-premises credential theft overview to defend against common credential theft techniques like LSASS access.
• Run Endpoint Detection and Response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not 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.    
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume. 
• 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 majority of new and unknown variants.

Microsoft Defender XDR customers can turn on the following attack surface reduction rule to prevent common attack techniques used for GooseEgg. Microsoft Defender XDR detects the GooseEgg tool and raises an alert upon detection of attempts to exploit Print Spooler vulnerabilities regardless of whether the device has been patched.

•  Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Detecting, hunting, and responding to GooseEgg Microsoft Defender XDR detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• HackTool:Win64/GooseEgg

Microsoft Defender for Endpoint

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Possible exploitation of CVE-2021-34527
• Possible source of PrintNightmare exploitation
• Possible target of PrintNightmare exploitation attempt
• Potential elevation of privilege using print filter pipeline service
• Suspicious behavior by spoolsv.exe
• Forest Blizzard Actor activity detected

Microsoft Defender for Identity

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Suspected Windows Print Spooler service exploitation attempt (CVE-2021-34527 exploitation)

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Actor Profile: Forest Blizzard
• Abuse of Windows Print Spooler for privilege escalation and persistence

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

Hunt for filenames, file extensions in ProgramData folder and file hash

let filenames = dynamic(["execute.bat","doit.bat","servtask.bat"]); DeviceFileEvents | where TimeGenerated > ago(60d) // change the duration according to your requirement | where ActionType == "FileCreated" | where FolderPath == "C:\\ProgramData\\" | where FileName in~ (filenames) or FileName endswith ".save" or FileName endswith ".zip" or ( FileName startswith "wayzgoose" and FileName endswith ".dll") or SHA256 == "7d51e5cc51c43da5deae5fbc2dce9b85c0656c465bb25ab6bd063a503c1806a9" // hash value of execute.bat/doit.bat/servtask.bat | project TimeGenerated, DeviceId, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessAccountName,InitiatingProcessAccountUpn

Hunt for processes creating scheduled task creation

DeviceProcessEvents | where TimeGenerated > ago(60d) // change the duration according to your requirement | where InitiatingProcessSHA256 == "6b311c0a977d21e772ac4e99762234da852bbf84293386fbe78622a96c0b052f" or SHA256 == "6b311c0a977d21e772ac4e99762234da852bbf84293386fbe78622a96c0b052f" //hash value of justice.exe | where InitiatingProcessSHA256 == "c60ead92cd376b689d1b4450f2578b36ea0bf64f3963cfa5546279fa4424c2a5" or SHA256 == "c60ead92cd376b689d1b4450f2578b36ea0bf64f3963cfa5546279fa4424c2a5" //hash value of DefragmentSrv.exe or ProcessCommandLine contains "schtasks /Create /RU SYSTEM /TN \\Microsoft\\Windows\\WinSrv /TR C:\\ProgramData\\servtask.bat /SC MINUTE" or ProcessCommandLine contains "schtasks /Create /RU SYSTEM /TN \\Microsoft\\Windows\\WinSrv /TR C:\\ProgramData\\execute.bat /SC MINUTE" or ProcessCommandLine contains "schtasks /Create /RU SYSTEM /TN \\Microsoft\\Windows\\WinSrv /TR C:\\ProgramData\\doit.bat /SC MINUTE" or ProcessCommandLine contains "schtasks /DELETE /F /TN \\Microsoft\\Windows\\WinSrv" or InitiatingProcessCommandLine contains "schtasks /Create /RU SYSTEM /TN \\Microsoft\\Windows\\WinSrv /TR C:\\ProgramData\\servtask.bat /SC MINUTE" or InitiatingProcessCommandLine contains "schtasks /Create /RU SYSTEM /TN \\Microsoft\\Windows\\WinSrv /TR C:\\ProgramData\\execute.bat /SC MINUTE" or InitiatingProcessCommandLine contains "schtasks /Create /RU SYSTEM /TN \\Microsoft\\Windows\\WinSrv /TR C:\\ProgramData\\doit.bat /SC MINUTE" or InitiatingProcessCommandLine contains "schtasks /DELETE /F /TN \\Microsoft\\Windows\\WinSrv" | project TimeGenerated, AccountName,AccountUpn,ActionType, DeviceId, DeviceName,FolderPath, FileName

Hunt for JavaScript constrained file

DeviceFileEvents | where TimeGenerated > ago(60d) // change the duration according to your requirement | where ActionType == "FileCreated" | where FolderPath startswith "C:\\Windows\\System32\\DriverStore\\FileRepository\\" | where FileName endswith ".js" or FileName == "MPDW-constraints.js"

Hunt for creation of registry key / value events

DeviceRegistryEvents | where TimeGenerated > ago(60d) // change the duration according to your requirement | where ActionType == "RegistryValueSet" | where RegistryKey contains "HKEY_CURRENT_USER\\Software\\Classes\\CLSID\\{026CC6D7-34B2-33D5-B551-CA31EB6CE345}\\Server" | where RegistryValueName has "(Default)" | where RegistryValueData has "wayzgoose.dll" or RegistryValueData contains ".dll"

 Hunt for custom protocol handler

DeviceRegistryEvents | where TimeGenerated > ago(60d) // change the duration according to your requirement | where ActionType == "RegistryValueSet" | where RegistryKey contains "HKEY_CURRENT_USER\\Software\\Classes\\PROTOCOLS\\Handler\\rogue" | where RegistryValueName has "CLSID" | where RegistryValueData contains "{026CC6D7-34B2-33D5-B551-CA31EB6CE345}" Indicators of compromise

Batch script artifacts:

• execute.bat
• doit.bat
• servtask.bat
• 7d51e5cc51c43da5deae5fbc2dce9b85c0656c465bb25ab6bd063a503c1806a9

GooseEgg artifacts:

• justice.pdb
• wayzgoose.pdb

IndicatorTypeDescriptionc60ead92cd376b689d1b4450f2578b36ea0bf64f3963cfa5546279fa4424c2a5SHA-256Hash of GooseEgg binary DefragmentSrv.exe6b311c0a977d21e772ac4e99762234da852bbf84293386fbe78622a96c0b052fSHA-256Hash of GooseEgg binary justice.exe41a9784f8787ed86f1e5d20f9895059dac7a030d8d6e426b9ddcaf547c3393aaSHA-256Hash of wayzgoose[%n].dll – where %n is a random number References

• https://media.defense.gov/2021/Jul/01/2002753896/-1/-1/1/CSA_GRU_GLOBAL_BRUTE_FORCE_CAMPAIGN_UOO158036-21.PDF
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34527
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1675
• https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-074a

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Analyzing Forest Blizzard’s custom post-compromise tool for exploiting CVE-2022-38028 to obtain credentials appeared first on Microsoft Security Blog.

Attackers are constantly seeking new vulnerabilities to compromise Kubernetes environments. Microsoft recently uncovered an attack that exploits new critical vulnerabilities in OpenMetadata to gain access to Kubernetes workloads and leverage them for cryptomining activity.

OpenMetadata is an open-source platform designed to manage metadata across various data sources. It serves as a central repository for metadata lineage, allowing users to discover, understand, and govern their data. On March 15, 2024, several vulnerabilities in OpenMetadata platform were published. These vulnerabilities (CVE-2024-28255, CVE-2024-28847, CVE-2024-28253, CVE-2024-28848, CVE-2024-28254), affecting versions prior to 1.3.1, could be exploited by attackers to bypass authentication and achieve remote code execution. Since the beginning of April, we have observed exploitation of this vulnerability in Kubernetes environments.

Microsoft highly recommends customers to check clusters that run OpenMetadata workload and make sure that the image is up to date (version 1.3.1 or later). In this blog, we share our analysis of the attack, provide guidance for identifying vulnerable clusters and using Microsoft security solutions like Microsoft Defender for Cloud to detect malicious activity, and share indicators of compromise that defenders can use for hunting and investigation.

Attack flow

For initial access, the attackers likely identify and target Kubernetes workloads of OpenMetadata exposed to the internet. Once they identify a vulnerable version of the application, the attackers exploit the mentioned vulnerabilities to gain code execution on the container running the vulnerable OpenMetadata image.

After establishing a foothold, the attackers attempt to validate their successful intrusion and assess their level of control over the compromised system. This reconnaissance step often involves contacting a publicly available service. In this specific attack, the attackers send ping requests to domains that end with oast[.]me and oast[.]pro, which are associated with Interactsh, an open-source tool for detecting out-of-band interactions.

OAST domains are publicly resolvable yet unique, allowing attackers to determine network connectivity from the compromised system to attacker infrastructure without generating suspicious outbound traffic that might trigger security alerts. This technique is particularly useful for attackers to confirm successful exploitation and validate their connectivity with the victim, before establishing a command-and-control (C2) channel and deploying malicious payloads.

After gaining initial access, the attackers run a series of reconnaissance commands to gather information about the victim environment. The attackers query information on the network and hardware configuration, OS version, active users, etc.

As part of the reconnaissance phase, the attackers read the environment variables of the workload. In the case of OpenMetadata, those variables might contain connection strings and credentials for various services used for OpenMetadata operation, which could lead to lateral movement to additional resources.

Once the attackers confirm their access and validate connectivity, they proceed to download the payload, a cryptomining-related malware, from a remote server. We observed the attackers using a remote server located in China. The attacker’s server hosts additional cryptomining-related malware that are stored, for both Linux and Windows OS.

Figure 1. Additional cryptomining-related malware in the attacker’s server

The downloaded file’s permissions are then elevated to grant execution privileges. The attacker also added a personal note to the victims:

Figure 2. Note from attacker

Next, the attackers run the downloaded cryptomining-related malware, and then remove the initial payloads from the workload. Lastly, for hands-on-keyboard activity, the attackers initiate a reverse shell connection to their remote server using Netcat tool, allowing them to remotely access the container and gain better control over the system. Additionally, for persistence, the attackers use cronjobs for task scheduling, enabling the execution of the malicious code at predetermined intervals.

How to check if your cluster is vulnerable

Administrators who run OpenMetadata workload in their cluster need to make sure that the image is up to date. If OpenMetadata should be exposed to the internet, make sure you use strong authentication and avoid using the default credentials.

To get a list of all the images running in the cluster:

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep 'openmetadata'

If there is a pod with a vulnerable image, make sure to update the image version for the latest version.

How Microsoft Defender for Cloud capabilities can help

This attack serves as a valuable reminder of why it’s crucial to stay compliant and run fully patched workloads in containerized environments. It also highlights the importance of a comprehensive security solution, as it can help detect malicious activity in the cluster when a new vulnerability is used in the attack. In this specific case, the attackers’ actions triggered Microsoft Defender for Containers alerts, identifying the malicious activity in the container. In the example below, Microsoft Defender for Containers alerted on an attempt to initiate a reverse shell from a container in a Kubernetes cluster, as happened in this attack:

Figure 3. Microsoft Defender for Containers alert for detection of potential reverse shell

To prevent such attacks, Microsoft Defender for Containers provides agentless vulnerability assessment for Azure, AWS, and GCP, allowing you to identify vulnerable images in the environment, before the attack occurs.  Microsoft Defender Cloud Security Posture Management (CSPM) can help to prioritize the security issues according to their risk. For example, Microsoft Defender CSPM highlights vulnerable workloads exposed to the internet, allowing organizations to quickly remediate crucial threats.

Organizations can also monitor Kubernetes clusters using Microsoft Sentinel via Azure Kubernetes Service (AKS) solution for Sentinel, which enables detailed audit trail for user and system actions to identify malicious activity.

Indicators of compromise (IoCs) TypeIoCExecutable SHA-2567c6f0bae1e588821bd5d66cd98f52b7005e054279748c2c851647097fa2ae2dfExecutable SHA-25619a63bd5d18f955c0de550f072534aa7a6a6cc6b78a24fea4cc6ce23011ea01dExecutable SHA-25631cd1651752eae014c7ceaaf107f0bf8323b682ff5b24c683a683fdac7525badIP8[.]222[.]144[.]60IP61[.]160[.]194[.]160IP8[.]130[.]115[.]208

Hagai Ran Kestenberg, Security Researcher
Yossi Weizman, Senior Security Research Manager

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Attackers exploiting new critical OpenMetadata vulnerabilities on Kubernetes clusters appeared first on Microsoft Security Blog.

The Department of Defense (DoD) Zero Trust Strategy1 and accompanying execution roadmap2 sets a path for achieving enterprise-wide target-level Zero Trust by 2027. The roadmap lays out vendor-agnostic Zero Trust activities that DoD Components and Defense Industrial Base (DIB) partners should complete to achieve Zero Trust capabilities and outcomes.

Microsoft commends the DoD for approaching Zero Trust as a mindset, not a capability or device that may be bought.1 Zero Trust can’t be achieved by a single technology, but through tight integration between solutions across product categories. Deciphering how security products achieve Zero Trust based on marketing materials alone is a daunting task. IT leaders need to select the right tools. Security architects need to design integrated solutions. Implementers need to deploy, configure, and integrate tools to achieve the outcomes in each Zero Trust activity.

Today, we are excited to announce Zero Trust activity-level guidance for DoD Components and DIB partners implementing the DoD Zero Trust Strategy. To learn more, see Configure Microsoft cloud services for the DoD Zero Trust Strategy.

In this blog, we’ll review the DoD Zero Trust Strategy and discuss how our new guidance helps DoD Components and DIB partners implement Zero Trust. We’ll cover the Microsoft Zero Trust platform and relevant features for meeting DoD’s Zero Trust requirements, and close with real-world DoD Zero Trust deployments.

Microsoft supports the DoD’s Zero Trust Strategy

The DoD released its formal Zero Trust Strategy in October 2022.1 The strategy is a security framework and mindset that set a path for achieving Zero Trust. The strategy outlines strategic goals for adopting culture, defending DoD Information Systems, accelerating technology implementation, and enabling Zero Trust.

The DoD Zero Trust Strategy includes seven pillars that represent protection areas for Zero Trust:

1. User
2. Device
3. Applications and workloads
4. Data
5. Network
6. Automation and orchestration
7. Visibility and analytics

In January 2023, the DoD published a capabilities-based execution roadmap for implementing Zero Trust.2 The roadmap details 45 Zero Trust capabilities spanning the seven pillars. The execution roadmap details the Zero Trust activities DoD Components should perform to achieve each Zero Trust capability. There are 152 Zero Trust activities in total, divided into Target Level Zero Trust and Advanced Level Zero Trust phases with deadlines of 2027 and 2032, respectively.

The Zero Trust activity-level guidance we’re announcing in this blog continues Microsoft’s commitment to supporting DoD’s Zero Trust strategy.3 It serves as a reference for how DoD Components should implement Zero Trust activities using Microsoft cloud services. Microsoft product teams and security architects supporting DoD worked in close partnership to provide succinct, actionable guidance side-by-side with the DoD Zero Trust activity text and organized by product with linked references.

We scoped the guidance to features available today (including public preview) for Microsoft 365 DoD and Microsoft Azure Government customers. As the security landscape changes, Microsoft will continue innovating to meet the needs of federal and DoD customers.4 We’re excited to bring entirely new Zero Trust technologies like Microsoft Copilot for Security and Security Service Edge to United States Government clouds in the future.5

Look out for announcements in the Microsoft Security Blog and check Microsoft’s DoD Zero Trust documentation to see the latest guidance.

Microsoft’s Zero Trust platform

Microsoft is proud to be recognized as a Leader in the Forrester Wave™: Zero Trust Platform Providers, Q3 2023 report.6 The Microsoft Zero Trust platform is a modern security architecture that emphasizes proactive, integrated, and automated security measures. Microsoft 365 E5 combines best-in-class productivity apps with advanced security capabilities that span all seven pillars of the DoD Zero Trust Strategy.

“Single products/suites can be adopted to address multiple capabilities. Integrated vendor suites of products rather than individual components will assist in reducing cost and risk to the government.”

 —Department of Defense Zero Trust Reference Architecture Version 2.07

Zero Trust Rapid Modernization Plan

Read more

Microsoft 365 is a comprehensive and extensible Zero Trust platform.8 It’s a hybrid cloud, multicloud, and multiplatform solution. Pre-integrated extended detection and response (XDR) services coupled with modern cloud-based device management, and a cloud-based identity and access management service, provide a direct and rapid modernization path for the DoD and DIB organizations.

Read on to learn about Microsoft cloud services that support the DoD Zero Trust Strategy.

Figure 1. Microsoft Zero Trust Architecture.

Microsoft Entra ID is an integrated multicloud identity and access management solution and identity provider. Microsoft Entra ID is tightly integrated with Microsoft 365 and Microsoft Defender XDR services to provide a comprehensive suite Zero Trust capabilities including strict identity verification, enforcing least privilege, and adaptive risk-based access control.

Microsoft Entra ID is built for cloud-scale, handling billions of authentications every day. It uses industry standard protocols and is designed for both Microsoft and non-Microsoft apps. Establishing Microsoft Entra ID as your organization’s Zero Trust identity provider lets you configure, enforce, and monitor adaptive Zero Trust access policies in a single location. Conditional Access is the Zero Trust authorization engine for Microsoft Entra ID. It enables dynamic, adaptive, fine-grained, risk-based, access policies for any workload.

Microsoft Entra ID is essential to the user pillar and has a role in all other pillars of the DoD Zero Trust Strategy.

Microsoft Intune is a multiplatform endpoint and application management suite for Windows, MacOS, Linux, iOS, iPadOS, and Android devices. Microsoft Intune configuration policies manage devices and applications. Microsoft Defender for Endpoint helps organizations prevent, detect, investigate, and respond to advanced threats on devices. Microsoft Intune and Defender for Endpoint work together to enforce security policies, assess device health, vulnerability exposure, risk level, and configuration compliance status. Conditional Access policies requiring a compliant device help achieve comply-to-connect  outcomes in the DoD Zero Trust Strategy.

Microsoft Intune and Microsoft Defender for Endpoint help achieve capabilities in the device pillar.

GitHub is a cloud-based platform where you can store, share, and work together with others to write code. GitHub Advanced Security includes features that help organizations improve and maintain code by providing code scanning, secret scanning, security checks, and dependency review throughout the deployment pipeline. Microsoft Entra Workload ID helps organizations use continuous integration and continuous delivery (CI/CD) with GitHub Actions.

GitHub and Azure DevOps are essential to the applications and workloads pillar.

Microsoft Purview is a range of solutions for unified data security, data governance, and risk and compliance management. Microsoft Purview Information Protection lets you define and label sensitive information types. Auto-labeling within Microsoft 365 clients ensure data is appropriately labeled and protected. Microsoft Purview Data Loss Prevention integrates with Microsoft 365 services and apps, and Microsoft Defender XDR components to detect and prevent data loss.

Microsoft Purview features align to the data pillar activities.

Azure networking services include a range of software-defined network resources that can be used to provide networking capabilities for connectivity, application protection, application delivery, and network monitoring. Azure networking resources like Microsoft Azure Firewall Premium, Azure DDoS Protection, Microsoft Azure Application Gateway, Azure API Management, Azure Virtual Network, and Network Security Groups, all work together to provide routing, segmentation, and visibility into your network.

Azure networking services and network segmentation architectures are essential to the network pillar.

Automate threat response with playbooks in Microsoft Sentinel

Learn more

Microsoft Defender XDR is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response actions. It correlates millions of signals across endpoints, identities, email, and applications to automatically disrupt attacks. Microsoft Defender XDR’s automated investigation and response and Microsoft Sentinel playbooks are used to complete security orchestration, automation, and response (SOAR) activities.

Microsoft Defender XDR plays a key role in automation and orchestration and visibility and analytics pillars.

Microsoft Sentinel is a cloud-based security information and event management (SIEM) you deploy in Azure. Microsoft Sentinel operates at cloud scale to accelerate security response and save time by automating common tasks and streamlining investigations with incident insights. Built-in data connectors make it easy to ingest security logs from Microsoft 365, Microsoft Defender XDR, Microsoft Entra ID, Azure, non-Microsoft clouds, and on-premises infrastructure.

Microsoft Sentinel is essential to automation and orchestration and visibility and analytics pillars along with any activities requiring SIEM integration.

Real-world pilots and implementations

The DoD is embracing Zero Trust as a continuous modernization effort. Microsoft has partnered with DoD Components for several years, onboarding Microsoft 365 services, integrating apps with Microsoft Entra, migrating Azure workloads, managing devices with Microsoft Intune, and building security operations around Microsoft Defender XDR and Microsoft Sentinel.

One such example is the United States Navy’s innovative Flank Speed program. The Navy’s large-scale deployment follows Zero Trust capabilities put forth in the DoD’s strategy. These capabilities include comply-to-connect, continuous authorization, least-privilege access, and data-centric security controls.9 To date, Flank Speed has onboarded more than 560,000 users and evaluated the effectiveness of its robust cybersecurity tools through Purple Team assessments.10

Another example is Army 365, the United States Army’s Microsoft 365 environment.11 Army 365 has onboarded more than 1.4 million users and migrated petabytes of data.12 The secure collaboration environment incorporates Zero Trust principles in a secure collaboration environment with identity and device protections and includes support for bring your own device (BYOD) through Azure Virtual Desktop.13

DoD Zero Trust Strategy and Roadmap

Learn how to configure Microsoft cloud services for the DoD Zero Trust Strategy.

Learn more Learn more

Embrace proactive security with Zero Trust.

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 on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

1DoD Zero Trust strategy, DoD CIO Zero Trust Portfolio Management Office. October 2022.

2Zero Trust Capability Execution Roadmap, DoD CIO Zero Trust Portfolio Management Office. January 2023.

3Microsoft supports the DoD’s Zero Trust strategy, Steve Faehl. November 22, 2022.

45 ways to secure identity and access for 2024, Joy Chik. January 10, 2024.

5Microsoft Entra Expands into Security Service Edge with Two New Offerings, Sinead O’Donovan. July 11, 2023.

6Forrester names Microsoft a Leader in the 2023 Zero Trust Platform Providers Wave™ report, Joy Chik. September 19, 2023.

7Department of Defense (DoD) Zero Trust Reference Architecture Version 2.0, Defense Information Systems Agency (DISA), National Security Agency (NSA) Zero Trust Engineering Team. July 2022.

8How Microsoft is partnering with vendors to provide Zero Trust solutions, Vasu Jakkal. October 21, 2021.

9Flank Speed Has Paved the Way for Navy to Become ‘Leaders in Zero Trust Implementation,’ Says Acting CIO Jane Rathbun, Charles Lyons-Burt, GovCon Wire. June 2023.

10Flank Speed makes significant strides in DOD Zero Trust Activity alignment, Darren Turner, PEO Digital. December 2023.

11Army launches upgraded collaboration platform; cybersecurity at the forefront, Alexandra Snyder. June 17, 2021.

12Cohesive teams drive NETCOM’s continuous improvement, Army 365 migration, Enrique Tamez Vasquez, NETCOM Public Affairs Office. March 2023.

13BYOD brings personal devices to the Army network, Army Office of the Deputy Chief of Staff, G-6. February 2024.

The post New Microsoft guidance for the DoD Zero Trust Strategy appeared first on Microsoft Security Blog.

We’re thrilled to announce that Forrester has recognized Microsoft as a Leader in the Forrester Wave™: Workforce Identity Platforms, Q1 2024 report. We’re proud of this recognition, which we believe reflects our commitment to delivering advanced solutions that cater to the evolving needs of our customers in the workforce identity space.

Identity professionals have a tough job. Every day, they deal with a digital landscape that’s always changing and with attacks that are always intensifying. To protect workforce identities and devices, they must secure access to data, applications, and resources across various environments—from any location and on any network. Moreover, they’re under constant pressure to secure not only an increasingly mobile and remote workforce, but also organizational resources that are increasingly distributed across multicloud environments.

We spend a lot of time with our customers to understand and address their challenges, and we’re grateful for their partnership. Their needs inspire the features and capabilities in Microsoft Entra, and we’ll keep collaborating with them to enhance our unified platform by strengthening identity security, improving user experiences, and integrating advanced technologies such as generative AI.

Leading the way in the workforce identity

In their earlier report, The Workforce Identity Platforms Landscape, Q4 2023, Forrester defined a workforce identity platform as a security platform that unifies the governance, administration, and enforcement of identity safeguards across human (employees, contractors, partners) and machine (service accounts, devices, bots, containers) identities to protect access to corporate assets and resources such as networks, business systems, applications, and data.

In The Forrester Wave™ report, Forrester recognized Microsoft Entra for its adaptive policy engine, well-integrated identity lifecycle management, and end-to-end approach to identity threat detection. The report also stated that Microsoft Entra supports a breadth of authentication methods (including passwordless options) for accessing all your apps and resources (cloud-based, legacy, and non-Microsoft). We believe the report demonstrates the value that the Microsoft Entra product portfolio brings to our customers, which we are always striving to improve. 

Looking to the future

It’s clear that—because AI is reshaping modern threats—AI-powered defenses are crucial. An AI-powered workforce identity platform empowers security and IT professionals to collaborate more effectively, gain deeper insights into security threats, and respond faster to emerging challenges.

We were happy to see Forrester cite Microsoft’s superior workforce identity vision that is underscored by its forward-looking innovation strategy in their evaluation. Looking forward, we’ll keep integrating our industry-leading AI capabilities with Microsoft Entra to help our customers future-proof their defenses and stay resilient against evolving cyberthreats in the workforce identity space.

Microsoft Entra

Safeguard connections between people, apps, resources, and devices with multicloud identity and network access solutions.

Explore products Learn more

To learn more about Microsoft Entra solutions, visit our website. Bookmark the Microsoft Entra blog to keep up with our expert coverage on workforce identity matters.

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 on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Forrester Wave™: Workforce Identity Platforms, Q1 2024, Geoff Cairns, Merrit Maxim, Lok Sze Sung, Pater Harrison. March 19, 2023. 

The post ​​Microsoft recognized as a Leader in the Forrester Wave™: Workforce Identity Platform, Q1 2024 appeared first on Microsoft Security Blog.

As we continue to integrate generative AI into our daily lives, it’s important to understand the potential harms that can arise from its use. Our ongoing commitment to advance safe, secure, and trustworthy AI includes transparency about the capabilities and limitations of large language models (LLMs). We prioritize research on societal risks and building secure, safe AI, and focus on developing and deploying AI systems for the public good. You can read more about Microsoft’s approach to securing generative AI with new tools we recently announced as available or coming soon to Microsoft Azure AI Studio for generative AI app developers.

We also made a commitment to identify and mitigate risks and share information on novel, potential threats. For example, earlier this year Microsoft shared the principles shaping Microsoft’s policy and actions blocking the nation-state advanced persistent threats (APTs), advanced persistent manipulators (APMs), and cybercriminal syndicates we track from using our AI tools and APIs.

In this blog post, we will discuss some of the key issues surrounding AI harms and vulnerabilities, and the steps we are taking to address the risk.

The potential for malicious manipulation of LLMs

One of the main concerns with AI is its potential misuse for malicious purposes. To prevent this, AI systems at Microsoft are built with several layers of defenses throughout their architecture. One purpose of these defenses is to limit what the LLM will do, to align with the developers’ human values and goals. But sometimes bad actors attempt to bypass these safeguards with the intent to achieve unauthorized actions, which may result in what is known as a “jailbreak.” The consequences can range from the unapproved but less harmful—like getting the AI interface to talk like a pirate—to the very serious, such as inducing AI to provide detailed instructions on how to achieve illegal activities. As a result, a good deal of effort goes into shoring up these jailbreak defenses to protect AI-integrated applications from these behaviors.

While AI-integrated applications can be attacked like traditional software (with methods like buffer overflows and cross-site scripting), they can also be vulnerable to more specialized attacks that exploit their unique characteristics, including the manipulation or injection of malicious instructions by talking to the AI model through the user prompt. We can break these risks into two groups of attack techniques:

• Malicious prompts: When the user input attempts to circumvent safety systems in order to achieve a dangerous goal. Also referred to as user/direct prompt injection attack, or UPIA.
• Poisoned content: When a well-intentioned user asks the AI system to process a seemingly harmless document (such as summarizing an email) that contains content created by a malicious third party with the purpose of exploiting a flaw in the AI system. Also known as cross/indirect prompt injection attack, or XPIA.

Today we’ll share two of our team’s advances in this field: the discovery of a powerful technique to neutralize poisoned content, and the discovery of a novel family of malicious prompt attacks, and how to defend against them with multiple layers of mitigations.

Neutralizing poisoned content (Spotlighting)

Prompt injection attacks through poisoned content are a major security risk because an attacker who does this can potentially issue commands to the AI system as if they were the user. For example, a malicious email could contain a payload that, when summarized, would cause the system to search the user’s email (using the user’s credentials) for other emails with sensitive subjects—say, “Password Reset”—and exfiltrate the contents of those emails to the attacker by fetching an image from an attacker-controlled URL. As such capabilities are of obvious interest to a wide range of adversaries, defending against them is a key requirement for the safe and secure operation of any AI service.

Our experts have developed a family of techniques called Spotlighting that reduces the success rate of these attacks from more than 20% to below the threshold of detection, with minimal effect on the AI’s overall performance:

• Spotlighting (also known as data marking) to make the external data clearly separable from instructions by the LLM, with different marking methods offering a range of quality and robustness tradeoffs that depend on the model in use.

Mitigating the risk of multiturn threats (Crescendo)

Our researchers discovered a novel generalization of jailbreak attacks, which we call Crescendo. This attack can best be described as a multiturn LLM jailbreak, and we have found that it can achieve a wide range of malicious goals against the most well-known LLMs used today. Crescendo can also bypass many of the existing content safety filters, if not appropriately addressed. Once we discovered this jailbreak technique, we quickly shared our technical findings with other AI vendors so they could determine whether they were affected and take actions they deem appropriate. The vendors we contacted are aware of the potential impact of Crescendo attacks and focused on protecting their respective platforms, according to their own AI implementations and safeguards.

At its core, Crescendo tricks LLMs into generating malicious content by exploiting their own responses. By asking carefully crafted questions or prompts that gradually lead the LLM to a desired outcome, rather than asking for the goal all at once, it is possible to bypass guardrails and filters—this can usually be achieved in fewer than 10 interaction turns. You can read about Crescendo’s results across a variety of LLMs and chat services, and more about how and why it works, in our research paper.

While Crescendo attacks were a surprising discovery, it is important to note that these attacks did not directly pose a threat to the privacy of users otherwise interacting with the Crescendo-targeted AI system, or the security of the AI system, itself. Rather, what Crescendo attacks bypass and defeat is content filtering regulating the LLM, helping to prevent an AI interface from behaving in undesirable ways. We are committed to continuously researching and addressing these, and other types of attacks, to help maintain the secure operation and performance of AI systems for all.

In the case of Crescendo, our teams made software updates to the LLM technology behind Microsoft’s AI offerings, including our Copilot AI assistants, to mitigate the impact of this multiturn AI guardrail bypass. It is important to note that as more researchers inside and outside Microsoft inevitably focus on finding and publicizing AI bypass techniques, Microsoft will continue taking action to update protections in our products, as major contributors to AI security research, bug bounties and collaboration.

To understand how we addressed the issue, let us first review how we mitigate a standard malicious prompt attack (single step, also known as a one-shot jailbreak):

• Standard prompt filtering: Detect and reject inputs that contain harmful or malicious intent, which might circumvent the guardrails (causing a jailbreak attack).
• System metaprompt: Prompt engineering in the system to clearly explain to the LLM how to behave and provide additional guardrails.

Defending against Crescendo initially faced some practical problems. At first, we could not detect a “jailbreak intent” with standard prompt filtering, as each individual prompt is not, on its own, a threat, and keywords alone are insufficient to detect this type of harm. Only when combined is the threat pattern clear. Also, the LLM itself does not see anything out of the ordinary, since each successive step is well-rooted in what it had generated in a previous step, with just a small additional ask; this eliminates many of the more prominent signals that we could ordinarily use to prevent this kind of attack.

To solve the unique problems of multiturn LLM jailbreaks, we create additional layers of mitigations to the previous ones mentioned above: 

• Multiturn prompt filter: We have adapted input filters to look at the entire pattern of the prior conversation, not just the immediate interaction. We found that even passing this larger context window to existing malicious intent detectors, without improving the detectors at all, significantly reduced the efficacy of Crescendo. 
• AI Watchdog: Deploying an AI-driven detection system trained on adversarial examples, like a sniffer dog at the airport searching for contraband items in luggage. As a separate AI system, it avoids being influenced by malicious instructions. Microsoft Azure AI Content Safety is an example of this approach.
• Advanced research: We invest in research for more complex mitigations, derived from better understanding of how LLM’s process requests and go astray. These have the potential to protect not only against Crescendo, but against the larger family of social engineering attacks against LLM’s. 

How Microsoft helps protect AI systems

AI has the potential to bring many benefits to our lives. But it is important to be aware of new attack vectors and take steps to address them. By working together and sharing vulnerability discoveries, we can continue to improve the safety and security of AI systems. With the right product protections in place, we continue to be cautiously optimistic for the future of generative AI, and embrace the possibilities safely, with confidence. To learn more about developing responsible AI solutions with Azure AI, visit our website.

To empower security professionals and machine learning engineers to proactively find risks in their own generative AI systems, Microsoft has released an open automation framework, PyRIT (Python Risk Identification Toolkit for generative AI). Read more about the release of PyRIT for generative AI Red teaming, and access the PyRIT toolkit on GitHub. If you discover new vulnerabilities in any AI platform, we encourage you to follow responsible disclosure practices for the platform owner. Microsoft’s own procedure is explained here: Microsoft AI Bounty.

The Crescendo Multi-Turn LLM Jailbreak Attack

Read about Crescendo’s results across a variety of LLMs and chat services, and more about how and why it works.

Read the paper

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 on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post How Microsoft discovers and mitigates evolving attacks against AI guardrails appeared first on Microsoft Security Blog.