Using Security Copilot, we were able to identify potential security issues in bootloader functionalities, focusing on filesystems due to their high vulnerability potential. This approach saved our team approximately a week’s worth of time that would have otherwise been spent manually reviewing the content. Through a series of prompts, we identified and refined security issues, ultimately uncovering an exploitable integer overflow vulnerability. Copilot also assisted in finding similar patterns in other files, ensuring comprehensive coverage and validation of our findings. This efficient process allowed us to confirm several additional vulnerabilities and extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2. We’re sharing this research as an example of the increased efficiency, streamlined workflows, and improved capabilities that AI solutions like Security Copilot can deliver for defenders, security researchers, and SOC analysts. As AI continues to emerge as a key tool in the cybersecurity community, Microsoft emphasizes the importance of vendors and researchers maintaining their focus on information sharing. This approach ensures that AI’s advantages in rapid vulnerability discovery, remediation, and accelerated security operations can effectively counter malicious actors’ attempts to use AI to scale common attack tactics, techniques, and procedures (TTPs).

While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot and install stealthy bootkits or potentially bypass other security mechanisms, such as BitLocker. The implications of installing such bootkits are significant, as this can grant threat actors complete control over the device, allowing them to control the boot process and operating system, compromise additional devices on the network, and pursue other malicious activities. Furthermore, it could result in persistent malware that remains intact even after an operating system reinstallation or a hard drive replacement.

We disclosed these vulnerabilities with the GRUB2, U-boot, and Barebox maintainers and worked with the GRUB2 maintainers to contribute fixes for the discovered vulnerabilities. To address the issues, the GRUB2 maintainers released security updates on February 18, 2025, and both the U-boot and Barebox maintainers released updates on February 19, 2025. We thank the GRUB2, U-boot, and Barebox maintainers as well as the open-source community for their quick response and collaborative efforts in addressing these issues, and we advise users to ensure their instances are up to date. We would also like to thank the RedHat support team for their assistance in disclosing these issues to manufacturers. The respective vulnerabilities are summarized in the following table:

In this blog, we detail how Secure Boot and GRUB2 function, explain how the GRUB2 vulnerabilities could have been exploited, and provide information on the vulnerabilities found in other open-source bootloaders to highlight the risks associated with unknowingly sharing vulnerable code among different open-source projects. As the boot process involves multiple components spanning different manufacturers and vendors, updates and fixes to the Secure Boot process can be particularly complex and run the risk of rendering a device unusable. As such, we are also sharing these findings with the security community to emphasize the importance of responsible disclosure and collaboration in the effort to enhance protection technologies and security across different devices and platforms.

Secure Boot and GRUB2

Before 2006, Intel-based computers booted into startup firmware code commonly known as the BIOS (Basic Input/Output System), which was responsible for hardware initialization and setup of common services to later be used by a bootloader. Ultimately, the BIOS would transfer control to a bootloader coded in real mode, which would commonly load an operating system (OS).

With time, attackers realized there is no root-of-trust verification of bootloaders by the firmware, thus began the era of bootkits, which are bootloader-based rootkits. To standardize the boot process, a unified firmware schema to replace BIOS was introduced in 2006, which is currently known as the Unified Extensible Firmware Interface (UEFI).

UEFI also helped combat bootkits, as it offers services that validate bootloaders and its own extensible modules by means of digital signatures. That protocol is known as Secure Boot and is essential to establishing a root of trust for the boot process, in which the firmware verifies UEFI drivers and OS modules with a platform key or a Key Exchange Key, and bootloaders verify the loaded operating system.

Trust is then achieved with the help of equipment manufacturers, which can sign code trusted by Secure Boot, by means of Certificate Authorities (CA). Essentially, manufacturers sign code with their private key, and their public key is signed with a root CA, commonly Microsoft’s UEFI CA. This is also essential to supporting non-Windows bootloaders such as GRUB2 (which commonly boots Linux) and allowing third party operating systems to benefit from Secure Boot. Since GRUB2 is fully open-sourced, vendors install a small program called a shim, which is signed by Microsoft’s UEFI CA and is responsible for validating the integrity of GRUB2. The shim can further consult a mechanism called Secure Boot Advanced Targeting (SBAT) for further revocation and management options as SBAT is used by the shim to provide a way to track and revoke individual software components based on metadata rather than cryptographic signatures alone.

The dangers of a GRUB2

Since bootloaders run before operating systems run, they mostly have UEFI-provided services as APIs to rely on. Therefore, bootloaders do not benefit from modern operating system security features, such as:

• No-Execute (NX): Known in Windows as Data Execution Prevention (DEP), and enforces memory page execute protections. Before the introduction of NX, attackers could override return addresses (which are maintained in-memory) and jump to arbitrary code (commonly a shellcode) that could be placed using the provided input.
• Address Space Layout Randomization (ASLR): This feature randomizes the base address of modules, which makes return address overrides and function pointer overrides highly unreliable since attackers do not know where usable code might be found.
• Safe dynamic allocators: Dynamic allocations are a favorite target for attackers, and modern operating systems harden their heap allocators with various techniques, including Safe Unlinking, type-safety, Pointer Authentication, and others.
• Stack cookies / Canaries: These are randomly generated values pushed between the return address and local variables on the stack, with the intent of detecting changes in their values before using the return address (commonly in a RET instruction).

Additionally, GRUB2 offers complex logic to implement various features, including:

• Image file parsers (PNG, TGA, and JPEG)
• Font parsing and support (PF2 file format)
• Network support (HTTP, FTP, DNS, ICMP, etc.)
• Various filesystem supportability (FAT, NTFS, EXT, JFS, HFS, ReiserFS, etc.)
• Bash-like command-line utility
• Extensible dynamic module loading capabilities

Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation. Considering the implication of defeating Secure Boot and strategically assessing the project (such as with Google’s Rule of 2), it is evident why GRUB2 may be of interest to vulnerability researchers.

Several memory corruption vulnerabilities have been uncovered in the past and are evident of the risks that we have mentioned. Noteworthy examples include:

Findings

Through a combination of static code analysis tools (such as CodeQL), fuzzing the GRUB2 emulator (grub-emu) with AFL++, manual code analysis, and using Microsoft Security Copilot, we have uncovered several vulnerabilities.

Using Security Copilot, we initially explored which functionalities in a bootloader have the most potential for vulnerabilities, with Copilot identifying network, filesystems, and cryptographic signatures as key areas of interest. Given our ongoing analysis of network vulnerabilities and the fact that cryptography is largely handled by UEFI, we decided to focus on filesystems.

Using the JFFS2 filesystem code as an example, we prompted Copilot to find all potential security issues, including exploitability analysis. Copilot identified multiple security issues, which we refined further by requesting Copilot to identify and provide the five most pressing of these issues. In our manual review of the five identified issues, we found three were false positives, one was not exploitable, and the remaining issue, which warranted our attention and further investigation, was an integer overflow vulnerability.

We used Security Copilot to successfully identify similar patterns in other GRUB2 files. Assuming the possibility of false negatives, we performed thorough validation and review of GRUB2 to avoid overlooking any issues, allowing us to confirm several additional vulnerabilities were present relating to the integer overflow.

Through this research, we have disclosed the following vulnerabilities:

Most of those vulnerabilities are simple memory corruption vulnerabilities. As an example, let us examine the JFS symbolic link resolution function:

The vulnerability is an overflow of the size variable:

• The size variable is declared as grub_size_t, which is ultimately defined as a 64-bit unsigned integer (uint64_t).
• The function grub_le_to_cpu64 converts a Little-Endian 64-bit value to the CPU’s native Endianess. Since x86-64 is already Little-Endian, it does nothing (on Big-Endian systems it reverses the byte-order of the 64-bit input value).
• Note the input data and its inode are fully attacker-controlled, since they supply the filesystem image. Therefore, size can get an arbitrary value, including the very large value 0xFFFFFFFFFFFFFFFF (which is the maximum value an unsigned 64-bit integer can get).
• The linknest checks are irrelevant for the vulnerability, but they assure the number of nested symbolic links to not exceed a limit (defined as 8).
• The size+1 calculation is an integer overflow—if size is 0xFFFFFFFFFFFFFFFF then size+1 is now 0. Note grub_malloc happily allocates a 0-byte chunk and returns it to the variable symlink.
• At this point, symlink is being written to by the function grub_jfs_read_file. The contents are arbitrarily set by the attacker, and while this function will never be able to read 0xFFFFFFFFFFFFFFFF bytes, an attacker would still be able to override important data beyond the limit of the symlink variable with an arbitrary payload.

It seems GRUB2 maintainers were aware of other types of integer overflow issues in the past and therefore introduced functions such as grub_add and grub_mul to handle addition and multiplication overflows safely. However, it seems there are quite a few places where those functions have not been considered.

The other vulnerabilities we’ve reported had similar out-of-bounds or integer overflow issues. In addition, we have reported a cryptographic side-channel attack issue, in which the function grub_crypto_memcmp does not perform its memory comparison in constant-time. The vulnerability is quite similar to one we disclosed on Netgear routers in the past.

Variant analysis and extensions to other bootloaders

After the discovery of the GRUB2 filesystem vulnerabilities and validating their exploitability, we concluded it is very likely other bootloaders might be affected by similar vulnerabilities, potentially as a result of the practice of copy-pasting filesystem parsing code between different open-source projects.

To test this hypothesis, we asked Security Copilot to find similar code in GitHub based on GRUB2’s filesystem implementations. This approach initially found many GRUB2 forks, so we continued to refine the search and manually review the results. Within those results, the U-boot and Barebox bootloaders, which are both commonly used for embedded systems, were identified as having shared code with GRUB2. Further investigation led us to identify similar vulnerabilities in both bootloaders, as detailed in the table below.

To exploit those in an embedded system context, attackers would most likely require physical access to those devices.

Enhancing security beyond Microsoft with research and threat intelligence sharing

As our research demonstrates, the discovered vulnerabilities can impact a wide range of systems and devices with varying impact. The vulnerabilities in GRUB2 can be exploited to bypass Secure Boot and allow threat actors to gain arbitrary code execution in the context of GRUB2, install stealthy bootkits and persistent malware, and compromise additional devices on the network. Additionally, there are further consequences to bypassing Secure Boot as it undermines the security mechanism designed to protect the boot process. Secure Boot bypasses can lead to threat actors loading untrusted software and malicious code during the boot process, evading detection by security solutions, and gaining full control of the system for potential widespread impact across operating systems relying on UEFI Secure Boot. While the vulnerabilities impacting U-boot and Barebox may be more difficult to exploit for threat actors by requiring physical device access, the issues still underscore the dangers of sharing susceptible code across multiple open-source projects.

This research also demonstrates the necessity of responsible vulnerability disclosure, threat intelligence sharing, and partner collaboration in addressing these issues to safeguard users against current and future threats. Given the complexity of the boot process, which involves multiple components from different manufacturers, coupled with the fact that updates to Secure Boot can run the risk of rendering a device unusable, responsible disclosure of these vulnerabilities is necessary to prevent threat actor exploitation and give teams time to effectively coordinate and collaborate on mitigation measures.

To address the discovered issues, the GRUB2 maintainers updated the vulnerable versions in SBAT while working with manufacturers to update DBX database entries as well as their shims to improve Secure Boot revocation management, particularly for bootloaders like shim that act as an intermediary between firmware Secure Boot verification and Linux distributions boot processes. In addition to deploying patches to address the vulnerabilities, the GRUB2 maintainers disabled some of the OS modules when Secure Boot is enabled to help ensure only trusted and verified code executes during the boot process, further reducing the attack surface. We would like to again thank the GRUB2 team and open-source community for their efforts in addressing these issues, as well as the U-boot and Barebox maintainers for quickly releasing fixes.

Leveraging AI like Security Copilot was invaluable in our research, saving us approximately a week’s worth of time by efficiently identifying and refining security issues in bootloader functionalities, ultimately allowing us to uncover several vulnerabilities. Identifying, disclosing, and contributing fixes for vulnerabilities, such as those mentioned in this blog post, is part of our ongoing commitment to enhance security at Microsoft and beyond. Microsoft is dedicated to improving security through research-driven protections and collaboration with customers, partners, and industry experts. Microsoft security researchers discover vulnerabilities and threats, translating this knowledge into enhanced solutions that protect users daily, and by expanding our research, we also contribute to the security of devices worldwide across all platforms.

Jonathan Bar Or

Microsoft 365 Defender Research Team

References

• https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html
• https://www.cve.org/CVERecord?id=CVE-2024-56737
• https://www.cve.org/CVERecord?id=CVE-2024-56738
• https://www.cve.org/CVERecord?id=CVE-2025-0677
• https://www.cve.org/CVERecord?id=CVE-2025-0678
• https://www.cve.org/CVERecord?id=CVE-2025-0684
• https://www.cve.org/CVERecord?id=CVE-2025-0685
• https://www.cve.org/CVERecord?id=CVE-2025-0686
• https://www.cve.org/CVERecord?id=CVE-2025-0689
• https://www.cve.org/CVERecord?id=CVE-2025-0690
• https://www.cve.org/CVERecord?id=CVE-2025-1118
• https://www.cve.org/CVERecord?id=CVE-2025-1125
• https://www.cve.org/CVERecord?id=CVE-2025-26726
• https://www.cve.org/CVERecord?id=CVE-2025-26727
• https://www.cve.org/CVERecord?id=CVE-2025-26728
• https://www.cve.org/CVERecord?id=CVE-2025-26729
• https://www.cve.org/CVERecord?id=CVE-2025-26721
• https://www.cve.org/CVERecord?id=CVE-2025-26722
• https://www.cve.org/CVERecord?id=CVE-2025-26723
• https://www.cve.org/CVERecord?id=CVE-2025-26724
• https://www.cve.org/CVERecord?id=CVE-2025-26725
• https://wiki.osdev.org/BIOS
• https://wiki.osdev.org/Bootloader
• https://d3fend.mitre.org/offensive-technique/attack/T1067/
• https://wiki.osdev.org/UEFI
• https://uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orleans_-_Microsoft_UEFI_CA.PDF
• https://www.gnu.org/software/grub/manual/grub/html_node/UEFI-secure-boot-and-shim.html
• https://github.com/rhboot/shim/blob/main/SBAT.md
• https://theapplewiki.com/wiki/Heap_Hardening
• https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
• https://nvd.nist.gov/vuln/detail/cve-2020-10713
• https://ubuntu.com/security/CVE-2021-3695
• https://ubuntu.com/security/CVE-2021-3696
• https://ubuntu.com/security/CVE-2021-3697
• https://ubuntu.com/security/CVE-2022-28733
• https://ubuntu.com/security/CVE-2022-28734
• https://ubuntu.com/security/CVE-2022-28735
• https://nvd.nist.gov/vuln/detail/cve-2023-4692
• https://codeql.github.com/
• https://github.com/AFLplusplus/AFLplusplus
• https://wiki.osdev.org/Endianness
• https://wiki.osdev.org/X86-64
• https://www.redhat.com/en/blog/inodes-linux-filesystem
• https://cwe.mitre.org/data/definitions/190.html
• https://cwe.mitre.org/data/definitions/208.html

Learn more

Security Copilot customers can use the standalone experience to create their own prompts or run pre-built promptbooks to automate incident response or investigation tasks related to this threat.

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://x.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 open-source bootloaders: Finding vulnerabilities faster with AI appeared first on Microsoft Security Blog.

GitHub was the primary platform used in the delivery of the initial access payloads and is referenced throughout this blog post; however, Microsoft Threat Intelligence also observed one payload hosted on Discord and another hosted on Dropbox.

The GitHub repositories, which were taken down, stored malware used to deploy additional malicious files and scripts. Once the initial malware from GitHub gained a foothold on the device, the additional files deployed had a modular and multi-stage approach to payload delivery, execution, and persistence. The files were used to collect system information and to set up further malware and scripts to exfiltrate documents and data from the compromised host. This activity is tracked under the umbrella name Storm-0408 that we use to track numerous threat actors associated with remote access or information-stealing malware and who use phishing, search engine optimization (SEO), or malvertising campaigns to distribute malicious payloads.

In this blog, we provide our analysis of this large-scale malvertising campaign, detailing our findings regarding the redirection chain and various payloads used across the multi-stage attack chain. We further provide recommendations for mitigating the impact of this threat, detection details, indicators of compromise (IOCs), and hunting guidance to locate related activity. By sharing this research, we aim to raise awareness about the tactics, techniques, and procedures (TTPs) used in this widespread activity so organizations can better prepare and implement effective mitigation strategies to protect their systems and data.

We would like to thank the GitHub security team for their prompt response and collaboration in taking down the malicious repositories.

GitHub activity and redirection chain

Since at least early December 2024, multiple hosts downloaded first-stage payloads from malicious GitHub repositories. The users were redirected to GitHub through a series of other redirections. Analysis of the redirector chain determined the attack likely originated from illegal streaming websites where users can watch pirated videos. The streaming websites embedded malvertising redirectors within movie frames to generate pay-per-view or pay-per-click revenue from malvertising platforms. These redirectors subsequently routed traffic through one or two additional malicious redirectors, ultimately leading to another website, such as a malware or tech support scam website, which then redirected to GitHub.

Multiple stages of malware were deployed in this campaign, as listed below, and the several different stages of activity that occurred depended on the payload dropped during the second stage.

• The first-stage payload that was hosted on GitHub served as the dropper for the next stage of payloads.
• The second-stage files were used to conduct system discovery and to exfiltrate system information that was Base64-encoded into the URL and sent over HTTP to an IP address. The information collected included data on memory size, graphic details, screen resolution, operating system (OS), and user paths.
• Various third-stage payloads were deployed depending on the second-stage payload. In general, the third-stage payload conducted additional malicious activities such as command and control (C2) to download additional files and to exfiltrate data, as well as defense evasion techniques.

The full redirect chain was composed of four to five layers. Microsoft researchers determined malvertising redirectors were contained within an iframe on illegal streaming websites.

There were several redirections that occurred before arriving at the malicious content stored on GitHub.

Attack chain

Once the redirection to GitHub occurred, the malware hosted on GitHub established the initial foothold on the user’s device and functioned as a dropper for additional payload stages and running malicious code. The additional payloads included information stealers to collect system and browser information on the compromised device, of which most were either Lumma stealer or an updated version of Doenerium. Depending on the initial payload, the deployment of NetSupport, a remote monitoring and management (RMM) software, was also often deployed alongside the infostealer. Besides the information stealers, PowerShell, JavaScript, VBScript, and AutoIT scripts were run on the host. The threat actors incorporated use of living-off-the-land binaries and scripts (LOLBAS) like PowerShell.exe, MSBuild.exe, and RegAsm.exe for C2 and data exfiltration of user data and browser credentials.

After the initial foothold was gained, the activity led to a modular and multi-stage approach to payload delivery, execution, and persistence. Each stage dropped another payload with a different function, as outlined below. Actions conducted across these stages include system discovery (memory, GPU, OS, signed-in users, and others), opening browser credential files, Data Protection API (DPAPI) crypt data calls, and other functions such as obfuscated script execution and named pipe creations to conduct data exfiltration. Persistence was achieved through modification of the registry run keys and the addition of a shortcut file to the Windows Startup folder.

Several stages of malicious activity to conduct deployment of additional malware, collections, and exfiltration of data to a C2 were observed. While not every single initial payload followed these exact steps, this is an overall view of what occurred across most incidents analyzed:

First-stage payload: Establishing a foothold on the host

During the first stage, a payload is dropped onto the user’s device from the binary hosted on GitHub, establishing a foothold on that device. As of mid-January 2025, the first-stage payloads discovered were digitally signed with a newly created certificate. A total of twelve different certificates were identified, all of which have been revoked.

Most of these initial payloads dropped the following legitimate files to leverage their functionality. These files were either leveraged by the first-stage payload or by later-stage payloads, depending on the actions being conducted.

Depending on the first-stage payload that was initially established on the compromised device, Microsoft observed different second-stage payloads and several different methods for delivering these payloads to the device.

Second-stage payload: System discovery, collection, and exfiltration

The main purpose of the second-stage payload is to conduct system discovery and collect that data for exfiltration to the C2. The system information collected includes data such as memory size, graphic card details, screen resolution, operating system, user paths, and a reference to the second-stage payload’s file name.

This was accomplished by querying the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName for the Windows OS version and running commands, such as the echo command, to gather the device’s name (%COMPUTERNAME%) and domain name (%USERDOMAIN%).

System data collected by the second-stage payload is Base64-encoded and exfiltrated as a query parameter to an IP address.

Third-stage payload: PowerShell and .exe binary

Depending on the second-stage payload, either one or multiple executables are dropped onto the compromised device, and sometimes an accompanying encoded PowerShell script. These files initiate a chain of events that conduct command execution, payload delivery, defensive evasion, persistence, C2 communications, and data exfiltration. The analysis of the dropped executables is first discussed below, followed by review of the PowerShell scripts observed.

Third-stage .exe analysis

The second-stage payloads run the dropped third-stage executables using the command prompt (for example, cmd.exe  /d /s /c “”C:\Users\<user>\AppData\Local\Temp\ApproachAllan.exe””). The /c flag ensures that the command runs and exits quickly. When the third-stage .exe runs, it drops a command file (.cmd) and launches it using the command prompt (for example, “cmd.exe” /c copy Beauty Beauty.cmd && Beauty.cmd). The .cmd file performs several actions, such as running tasklist, to initiate the discovery of running programs. This is followed by the findstr to search for keywords associated with security software:

The .cmd file also concatenates multiple files into one with a single character file name: “cmd /c copy /b ..\Verzeichnis + ..\Controlling + ..\Constitute + ..\Enjoyed + ..\Confusion + ..\Min +..\Statutory J”. This single character filename is used next.

Following this, the third-stage .exe produces an AutoIT v3 interpreter file that is renamed from the typical file name of AutoIt3.exe and uses a .com file extension. The .cmd file initiates the execution of the .com file against the single character binary (such as Briefly.com J). Note, most of the second-stage payloads follow this progression chain, and as mentioned a second-stage payload can also drop multiple executables, all following the same process. For example:

First stage

• X-essentiApp.exe

Second stage

• Ionixnignx.exe

Third stage

• EverybodyViewing.exe
• ReliefOrganizational.exe
• InflationWinston.exe

Third-stage command files

• Beauty.cmd
• Possess.cmd
• Villa.cmd

Fourth-stage AutoIT .com files

• Alexandria.com
• Kills.com
• Briefly.com

We observed multiple .com files originating from different dropped executables, each performing distinct functions while occasionally overlapping in behavior. These files facilitate persistence, process injection, remote debugging, and data exfiltration through various mechanisms. One .com file, such as Alexandria.com, drops a .scr file (another renamed AutoIT interpreter), and a .js (JavaScript) file with the same name as the .scr file. The purpose of the JavaScript file is to ensure persistence by creating a .url internet shortcut that points to the JavaScript file and is placed in the Startup folder, ensuring that the .scr file executes when the .js file executes (through Wscript.exe) upon user sign-in. Alternatively, persistence can be achieved using scheduled task creation. The .scr file can initiate C2 connections, enable remote debugging on Chrome or Edge within a hidden desktop session, or create TCP listening sockets on ports 9220-9229. This functionality allows threat actors to monitor browsing activity and interact with an active browser instance. These files can also open sensitive data files, indicating their role in facilitating post-exploitation activities.

Another .com file, such as affiliated.com, also focuses on remote debugging and browser monitoring. In addition to remote monitoring, affiliated.com initiates network connections to Telegram, Let’s Encrypt, and threat actor domains, potentially for C2 or exfiltration. It also accesses DPAPI to decrypt sensitive stored credentials and retrieve browser data.

The final observed .com file, such as Briefly.com, exhibits behavior similar to affiliated.com but extends its capabilities to include screenshot capture, data exfiltration, and PowerShell-based execution. This file accesses browser and user data for collection, establishes connections to Pastebin and additional C2 domains, and drops the fourth-stage PowerShell script.

The order in which these .com files run is not strictly defined, as one or multiple files can perform overlapping functions depending on the third-stage payload. In many cases, the .com files also leverage LOLBAS like RegAsm.exe by dropping a legitimate file into the %TEMP% directory or injecting malicious code into it using NtAllocateVirtualMemory and SetThreadContext API function calls. RegAsm.exe is used to establish C2 connections over TCP ports 15647 or 9000, exfiltrating data, accessing DPAPI for decryption, monitoring keystrokes using the WH_KEYBOARD_LL hook, and more. This flexibility in execution allows threat actors to tailor their approach based on environmental factors, such as security configurations and user activity.

Browser data files seen accessed:

• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\cookies.sqlite
• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\formhistory.sqlite
• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\key4.db
• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\logins.json
• \AppData\Local\Google\Chrome\User Data\Default\Web Data
• \AppData\Local\Google\Chrome\User Data\Default\Login Data
• \AppData\Local\Microsoft\Edge\User Data\Default\Login Data

User data file paths seen accessed:

• C:\\Users\<user>\\OneDrive
• C:\\Users\<user>\\Documents
• C:\\Users\<user>\\Downloads

Third-stage PowerShell analysis

If a PowerShell script is also dropped by the second-stage payload, it includes Base64-obfuscated commands to conduct actions, such as use curl to download additional files like NetSupport from the C2, create persistence for the NetSupport RAT, and exfiltrate system information to C2 servers. To ensure no errors or the progress meter is displayed on the compromised device, the curl command is often used with the –silent option when downloading files from the C2. PowerShell is often configured to run without restrictions with the -ExecutionPolicy Bypass parameter.

As an example, in some of the incidents, when the second-stage payload runs, a PowerShell script is dropped and executed. The script sends the compromised device’s name to the C2 and downloads NetSupport RAT from the same C2.

• Second-stage payload: Squarel.exe
• PowerShell script: SHA-256: d70ccae7914fc8c36c9e11b2a7f10bebd7f5696e78d8836554f4990b0f688dbb
• C2 domain: keikochio[.]com
• NetSupport RAT: SHA-256: 32a828e2060e92b799829a12e3e87730e9a88ecfa65a4fc4700bdcc57a52d995

In another case, a second-stage payload drops a PowerShell script, which connects to hxxps://ipinfo[.]io to gather the compromised device’s external-facing IP address. This information is sent to a Telegram chat, then drops presentationhost.exe (a renamed NetSupport binary) and remcmdstub.exe (NetSupport Command Manager) into the %TEMP% directory. Finally, the PowerShell script establishes persistence for presentationhost.exe by adding it to the auto-start extensibility points (ASEP) registry keys. When it runs, the NetSupport RAT connects to the C2 and captures a screenshot of the compromised device’s desktop. It also delivers a Lumma executable that drops a VBScript file with the same name. The VBScript file runs encoded PowerShell to initiate C2 connections and launches MSBuild.exe to enable Chrome remote debugging on a hidden desktop. Additionally, presentationhost.exe initiates remcmdstub.exe, which leverages iScrPaint.exe (iTop Screen Recorder) to run MSBuild.exe and access browser credential files for exfiltration. The iScrPaint.exe file also establishes persistence by placing a .lnk shortcut in the Windows Startup folder, ensuring it runs on system reboot.

• Second-stage payload: Application.exe
• PowerShell script: SHA-256: 483796a64f004a684a7bc20c1ddd5c671b41a808bc77634112e1703052666a64
• C2: hxxp://5.10.250[.]240/fakeurl.htm

The last observed third-stage PowerShell script was dropped by three second-stage payloads. The script sends the compromised device’s name to the C2 server. It then changes the working directory to $env:APPDATA, before using Start-BitsTransfer to download NetSupport from the C2. To evade detection, it modifies system security settings forcing TLS1.2 for encrypted C2 communication. These files are extracted into a newly created WinLibraryClient directory under AppData and then are launched. The script establishes persistence for the client32.exe (NetSupport RAT) by modifying the ASEP registry. Client32.exe initiates C2 connections to hxxp://79.132.128[.]77/fakeurl.htm.

• Second-stage payloads: SalmonSamurai.exe, LakerBaker.exe, and DisplayPhotoViewer.exe
• PowerShell script: SHA-256: 670218cfc5c16d06762b6bc74cda4902087d812e72c52d6b9077c4c4164856b6
• C2 domain: stocktemplates[.]net

Additionally, one observed execution included registry enumeration of HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\ to identify installed applications and security software. It also queries the system’s domain status using Windows Management Instrumentation (WMI) and scans for cryptocurrency wallets, including Ledger Live, Trezor Suite, KeepKey, BCVault, OneKey, and BitBox, indicating potential financial data theft.

Fourth-stage PowerShell analysis

Depending on the .com file that ran (like Briefly.com), the renamed AutoIT file may drop a PowerShell script (SHA-256: 2a29c9904d1860ea3177da7553c8b1bf1944566e5bc1e71340d9e0ff079f0bd3). The obfuscated PowerShell code uses the Add-MpPreference cmdlet to modify Microsoft Defender to add in exclusion paths for Microsoft Defender, so the specified folders are not scanned.

The script above is sometimes followed by an instance of Base64-encoded PowerShell commands. The PowerShell commands perform the following actions:

• Sends a web request to hxxps://360[.]net and closes the response.
• Sends a web request to hxxps://baidu[.]com and closes the response.
• Downloads data from hxxps://klipcatepiu0[.]shop/int_clp_sha.txt using a web client.
• Writes the downloaded data to a memory stream and saves it as a .zip file named null.zip (SHA-256: f07b8e5622598c228bfc9bff50838a3c4fffd88c436a7ef77e6214a40b0a2bae) in the C:\Users\<Username>\AppData\Local\Temp directory.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of this threat.

Strengthen Microsoft Defender for Endpoint configuration

• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint. 
• Enable network protection in Microsoft Defender for Endpoint. 
• Turn on web protection.
• 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.  
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors. 
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block execution of potentially obfuscated scripts
  • Block JavaScript or VBScript from launching downloaded executable content
  • Block process creations originating from PSExec and WMI commands
  • Block credential stealing from the Windows local security authority subsystem 
  • Block use of copied or impersonated system tools

Strengthen operating environment configuration

• Require multifactor authentication (MFA). While certain attacks such as adversary-in-the-middle (AiTM) phishing attempt to circumvent MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Implement Entra ID Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable Network Level Authentication for Remote Desktop Service connections.
• Enable Local Security Authority (LSA) protection to block credential stealing from the Windows local security authority subsystem. 
• AppLocker can restrict specific software tools prohibited within the organization, such as reconnaissance, fingerprinting, and RMM tools, or grant access to only specific users.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Trojan:Win64/LummaStealer
• Trojan:Win32/Malgent
• Behavior:Win32/Eldorado
• Behavior:Win32/LuammaStealer
• Trojan:PowerShell/Powdow
• Trojan:Win64/Shaolaod
• Behavior:Win64/Shaolaod

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Possible theft of passwords and other sensitive web browser information
• Possible Lumma Stealer activity
• Renamed AutoIt tool
• Use of living-off-the-land binary to run malicious code
• Suspicious startup item creation
• Suspicious Scheduled Task Process Launched
• Suspicious DPAPI Activity
• Suspicious implant process from a known emerging threat
• Security software tampering
• Suspicious activity linked to a financially motivated threat actor detected
• Ransomware-linked threat actor detected
• A file or network connection related to a ransomware-linked emerging threat activity group detected
• Information stealing malware activity
• Possible NetSupport Manager activity
• Suspicious sequence of exploration activities
• Defender detection bypass
• Suspicious Location of Remote Management Software
• A process was injected with potentially malicious code
• Process hollowing detected
• Suspicious PowerShell download or encoded command execution
• Suspicious PowerShell command line
• Suspicious behavior by cmd.exe was observed
• Suspicious Security Software Discovery
• Suspicious discovery indicative of Virtualization/Sandbox Evasion
• A process was launched on a hidden desktop
• Monitored keystrokes
• Suspicious Process Discovery
• Suspicious Javascript process
• A suspicious file was observed
• Anomaly detected in ASEP registry

Microsoft Defender for Cloud

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Detected suspicious combination of HTA and PowerShell
• Suspicious PowerShell Activity Detected
• Traffic detected from IP addresses recommended for blocking
• Attempted communication with suspicious sinkholed domain
• Communication with suspicious domain identified by threat intelligence
• Detected obfuscated command line
• Detected suspicious named pipe communications

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

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 intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Storm-0408
• Agent Tesla credential theft malware
• Information stealers
• Lumma stealer
• Abuse of remote monitoring and management tools
• Malicious use of PowerShell

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Github-hosted first-stage payload certificate serial numbers

let specificSerialNumbers = dynamic(["70093af339876742820d7941", "15042512e67e8275f3f7f36b", "5608cab7e2ce34d53abcbb73",
 "0fa27d2553f24da79d1cc6bd8773ee9a", "7a7bf2ae0cbc0f5500db2946", "30d6c83a715bddb32e7956fe52d6b352",
  "301385aa36fae635e74bb88e", "30013cbbb16a7fd3c57f82707fb99c32", "5d00264a6b804ae6b28d9b16",
   "3a9c76f8304f77bd271921d9982f1ab6", "01f2c6c363767056abd80e9c", "0b09c88c0c8d15bed51a9eb4440f4bb0"]); 
union
(
    DeviceFileCertificateInfo
    | where CertificateSerialNumber in (specificSerialNumbers)
    | project DeviceName, CertificateSerialNumber, Signer, SHA1, IsSigned, Issuer, Timestamp
),
(
    DeviceTvmCertificateInfo
    | where SerialNumber in (specificSerialNumbers)
    | project DeviceId, SerialNumber, SignatureAlgorithm, Thumbprint, Path, IssueDate, ExpirationDate
)

Dropbox-hosted first-stage payload certificate serial number

Surface devices that may contain first-stage payloads hosted on Dropbox related to this activity. This query will search for the unique serial number of the known certificate related to this activity.

let specificSerialNumbers = dynamic(["7a7bf2ae0cbc0f5500db2946"]); 
union
(
    DeviceFileCertificateInfo
    | where CertificateSerialNumber in (specificSerialNumbers)
    | project DeviceName, CertificateSerialNumber, Signer, SHA1, IsSigned, Issuer, Timestamp
),
(
    DeviceTvmCertificateInfo
    | where SerialNumber in (specificSerialNumbers)
    | project DeviceId, SerialNumber, SignatureAlgorithm, Thumbprint, Path, IssueDate, ExpirationDate
)

Second-stage C2 IP addresses

Surface devices that may have communicated with second stage C2 IP addresses related to this activity.

let ipAddressToSearch = dynamic(["159.100.18.192", "192.142.10.246", "79.133.46.35", "84.200.24.191", "84.200.24.26", "89.187.28.253", "185.92.181.1"]);
union isfuzzy=true
(
    AzureDiagnostics
    | where identity_claim_ipaddr_s == ipAddressToSearch or conditions_sourceIP_s == ipAddressToSearch or CallerIPAddress == ipAddressToSearch or clientIP_s == ipAddressToSearch or clientIp_s == ipAddressToSearch or primaryIPv4Address_s == ipAddressToSearch or conditions_destinationIP_s == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AzureDiagnostics", IPAddress = coalesce(identity_claim_ipaddr_s, conditions_sourceIP_s, CallerIPAddress, clientIP_s, clientIp_s, primaryIPv4Address_s, conditions_destinationIP_s), AdditionalInfo = tostring(AdditionalFields)
),
(
    IdentityQueryEvents
    | where IPAddress == ipAddressToSearch or DestinationIPAddress == ipAddressToSearch
    | project Timestamp, Table = "IdentityQueryEvents", IPAddress = coalesce(IPAddress, DestinationIPAddress), AdditionalInfo = Query
),
(
    AADSignInEventsBeta
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "AADSignInEventsBeta", IPAddress, AdditionalInfo = UserAgent
),
(
    Heartbeat
    | where ComputerIP == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "Heartbeat", IPAddress = ComputerIP, AdditionalInfo = OSName
),
(
    CloudAppEvents
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "CloudAppEvents", IPAddress, AdditionalInfo = UserAgent
),
(
    DeviceNetworkEvents
    | where LocalIP == ipAddressToSearch or RemoteIP == ipAddressToSearch
    | project Timestamp, Table = "DeviceNetworkEvents", IPAddress = coalesce(LocalIP, RemoteIP), AdditionalInfo = InitiatingProcessCommandLine
),
(
    AADUserRiskEvents
    | where IpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADUserRiskEvents", IPAddress = IpAddress, AdditionalInfo = RiskEventType
),
(
    AADNonInteractiveUserSignInLogs
    | where IPAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADNonInteractiveUserSignInLogs", IPAddress, AdditionalInfo = UserAgent
),
(
    MicrosoftAzureBastionAuditLogs
    | where TargetVMIPAddress == ipAddressToSearch or ClientIpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "MicrosoftAzureBastionAuditLogs", IPAddress = coalesce(TargetVMIPAddress, ClientIpAddress), AdditionalInfo = UserAgent
)
| sort by Timestamp desc

Fourth-stage C2 IP addresses

Surface devices that may have communicated with fourth stage C2 IP addresses related to this activity.

let ipAddressToSearch = dynamic(["45.141.84.60", "91.202.233.18", "154.216.20.131", "5.10.250.240", "79.132.128.77"]);
union isfuzzy=true
(
    AzureDiagnostics
    | where identity_claim_ipaddr_s == ipAddressToSearch or conditions_sourceIP_s == ipAddressToSearch or CallerIPAddress == ipAddressToSearch or clientIP_s == ipAddressToSearch or clientIp_s == ipAddressToSearch or primaryIPv4Address_s == ipAddressToSearch or conditions_destinationIP_s == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AzureDiagnostics", IPAddress = coalesce(identity_claim_ipaddr_s, conditions_sourceIP_s, CallerIPAddress, clientIP_s, clientIp_s, primaryIPv4Address_s, o),
(
    IdentityQueryEvents
    | where IPAddress == ipAddressToSearch or DestinationIPAddress == ipAddressToSearch
    | project Timestamp, Table = "IdentityQueryEvents", IPAddress = coalesce(IPAddress, DestinationIPAddress), AdditionalInfo = Query
),
(
    AADSignInEventsBeta
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "AADSignInEventsBeta", IPAddress, AdditionalInfo = UserAgent
),
(
    Heartbeat
    | where ComputerIP == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "Heartbeat", IPAddress = ComputerIP, AdditionalInfo = OSName
),
(
    CloudAppEvents
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "CloudAppEvents", IPAddress, AdditionalInfo = UserAgent
),
(
    DeviceNetworkEvents
    | where LocalIP == ipAddressToSearch or RemoteIP == ipAddressToSearch
    | project Timestamp, Table = "DeviceNetworkEvents", IPAddress = coalesce(LocalIP, RemoteIP), AdditionalInfo = InitiatingProcessCommandLine
),
(
    AADUserRiskEvents
    | where IpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADUserRiskEvents", IPAddress = IpAddress, AdditionalInfo = RiskEventType
),
(
    AADNonInteractiveUserSignInLogs
    | where IPAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADNonInteractiveUserSignInLogs", IPAddress, AdditionalInfo = UserAgent
),
(
    MicrosoftAzureBastionAuditLogs
    | where TargetVMIPAddress == ipAddressToSearch or ClientIpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "MicrosoftAzureBastionAuditLogs", IPAddress = coalesce(TargetVMIPAddress, ClientIpAddress), AdditionalInfo = UserAgent
)
| sort by Timestamp desc

Browser remote debugging 

Identify AutoIT scripts launching chromium-based browsers (such as chrome.exe, msedge.exe, brave.exe) in remote debugging mode.

DeviceProcessEvents 
| where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe" // Check for "AutoIt" scripts, even if it's renamed.  
| where ProcessCommandLine has "--remote-debugging-port" // Identify Chromium based browsers (chrome.exe, msedge.exe, brave.exe etc) being launched in remote debugging mode. 
| project DeviceId, Timestamp, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine

DPAPI decryption via AutoIT

Identify DPAPI decryption activity originating from AutoIT scripts.

DeviceEvents
| where ActionType == "DpapiAccessed"
| where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe"
| where (AdditionalFields has_any("Google Chrome", "Microsoft Edge") and AdditionalFields has_any("SPCryptUnprotect"))
| extend json = parse_json(AdditionalFields)
| extend dataDesp = tostring(json.DataDescription.PropertyValue)
| extend opType = tostring(json.OperationType.PropertyValue)
| where (dataDesp in~ ("Google Chrome", "Microsoft Edge") and opType =~ "SPCryptUnprotect")
| project Timestamp, ReportId, DeviceId, ActionType, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, AdditionalFields, dataDesp, opType

DPAPI decryption via LOLBAS binaries

Identify DPAPI decryption activity originating from LOLBAS binaries (RegAsm.exe and MSBuild.exe).

DeviceEvents
| where ActionType == "DpapiAccessed"
| where InitiatingProcessFileName has_any ("RegAsm.exe", "MSBuild.exe")
| where (AdditionalFields has_any("Google Chrome", "Microsoft Edge") and  AdditionalFields has_any("SPCryptUnprotect"))
| extend json = parse_json(AdditionalFields)
| extend dataDesp = tostring(json.DataDescription.PropertyValue)
| extend opType = tostring(json.OperationType.PropertyValue)
| where (dataDesp in~ ("Google Chrome", "Microsoft Edge") and opType =~ "SPCryptUnprotect")
| project Timestamp, ReportId, DeviceId, ActionType, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, AdditionalFields, dataDesp, opType

Sensitive browser file access via AutoIT

Identify AutoIT scripts (renamed or otherwise) accessing sensitive browser files.

let browserDirs = pack_array(@"\Google\Chrome\User Data\", @"\Microsoft\Edge\User Data\", @"\Mozilla\Firefox\Profiles\"); 
let browserSensitiveFiles = pack_array("Web Data", "Login Data", "key4.db", "formhistory.sqlite", "cookies.sqlite", "logins.json", "places.sqlite", "cert9.db");
DeviceEvents
| where AdditionalFields has_any ("FileOpenSource") // Filter for "File Open" events.
| where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe"
| where (AdditionalFields has_any(browserDirs) or  AdditionalFields has_any(browserSensitiveFiles)) 
| extend json = parse_json(AdditionalFields)
| extend File_Name = tostring(json.FileName.PropertyValue)
| where (File_Name has_any (browserDirs) and File_Name has_any (browserSensitiveFiles))
| project Timestamp, ReportId, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, File_Name

Sensitive browser file access via LOLBAS binaries

Identify LOLBAS binaries (RegAsm.exe and MSBuild.exe) accessing sensitive browser files.

let browserDirs = pack_array(@"\Google\Chrome\User Data\", @"\Microsoft\Edge\User Data\", @"\Mozilla\Firefox\Profiles\"); 
let browserSensitiveFiles = pack_array("Web Data", "Login Data", "key4.db", "formhistory.sqlite", "cookies.sqlite", "logins.json", "places.sqlite", "cert9.db");
DeviceEvents
| where AdditionalFields has_any ("FileOpenSource") // Filter for "File Open" events.
| where InitiatingProcessFileName has_any ("RegAsm.exe", "MSBuild.exe")
 | where (AdditionalFields has_any(browserDirs) or  AdditionalFields has_any(browserSensitiveFiles)) 
| extend json = parse_json(AdditionalFields)
| extend File_Name = tostring(json.FileName.PropertyValue)
| where (File_Name has_any (browserDirs) and File_Name has_any (browserSensitiveFiles))
| project Timestamp, ReportId, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, File_Name

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.

Indicators of compromise

Streaming website domains with malicious iframe

Malicious iframe redirector domains

Malvertisement distributor

Malvertising website domains

GitHub referral URLs

GitHub URLs

DropBox URL

Discord URL

First stage GitHub-hosted payloads

First-stage Dropbox-hosted payload

First-stage Discord-hosted payload

Certificate signatures of GitHub-hosted payloads

Certificate signature of Dropbox-hosted payload

Second-stage payloads

Second-stage C2s

Third-stage payloads: .exe and PowerShell files

Fourth-stage AutoIT, NetSupport RAT, PowerShell, and Lumma

Third-stage C2s

Fourth-stage C2s

Fourth-stage testing connectivity sites

References

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
• https://github.com/antivirusevasion69/doenerium
• https://curl.se/docs/manpage.html#-s
• https://www.virustotal.com/gui/file/2a29c9904d1860ea3177da7553c8b1bf1944566e5bc1e71340d9e0ff079f0bd3

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://x.com/MsftSecIntel.

Hear more about this discovery and how threat actors in this campaign leverage trusted platforms and advanced techniques to achieve their malicious goals in this episode of the Microsoft Threat Intelligence podcast, hosted by Sherrod DeGrippo: https://thecyberwire.com/podcasts/microsoft-threat-intelligence/39/notes. 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 Malvertising campaign leads to info stealers hosted on GitHub appeared first on Microsoft Security Blog.

Because Kerberoasting enables cyberthreat actors to steal credentials and quickly navigate through devices and networks, it’s essential for administrators to take steps to reduce potential cyberattack surfaces. This blog explains Kerberoasting risks and provides recommended actions administrators can take now to help prevent successful Kerberoasting cyberattacks. 

What is Kerberoasting? 

Kerberoasting is a cyberattack that targets the Kerberos authentication protocol with the intent to steal AD credentials. The Kerberos protocol conveys user authentication state in a type of message called a service ticket which is encrypted using a key derived from an account password. Users with AD credentials can request tickets to any service account in AD.  

In a Kerberoasting cyberattack, a threat actor that has taken over an AD user account will request tickets to other accounts and then perform offline brute-force attacks to guess and steal account passwords. Once the cyberthreat actor has credentials to the service account, they potentially gain more privileges within the environment. 

AD only issues and encrypts service tickets for accounts that have Service Principal Names (SPNs) registered. An SPN signifies that an account is a service account, not a normal user account, and that it should be used to host or run services, such as SQL Server. Since Kerberoasting requires access to encrypted service tickets, it can only target accounts that have an SPN in AD. 

SPNs are not typically assigned to normal user accounts which means they are better protected against Kerberoasting. Services that run as AD machine accounts instead of as standalone service accounts are better protected against compromise using Kerberoasting. AD machine account credentials are long and randomly generated so they contain sufficient entropy to render brute-force cyberattacks impractical.  

The accounts most vulnerable to Kerberoasting are those with weak passwords and those that use weaker encryption algorithms, especially RC4. RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly. However, other encryption algorithms are still vulnerable when weak passwords are used. While AD will not try to use RC4 by default, RC4 is currently enabled by default, meaning a cyberthreat actor can attempt to request tickets encrypted using RC4. RC4 will be deprecated, and we intend to disable it by default in a future update to Windows 11 24H2 and Windows Server 2025. 

What are the risks associated with Kerberoasting? 

Kerberoasting is a low-tech, high-impact attack. There are many open-source tools which can be used to query potential target accounts, get service tickets to those accounts, and then use brute force cracking techniques to obtain the account password offline. 

This type of password theft helps threat actors pose as legitimate service accounts and continue to move vertically and laterally through the network and machines. Kerberoasting typically targets high privilege accounts which can be used for a variety of attacks such as rapidly distributing malicious payloads like ransomware to other end user devices and services within a network.    

Accounts without SPNs, such as standard user or administrator accounts, are susceptible to similar brute-force password guessing attacks and the recommendations below can be applied to them as well to mitigate risks. 

How to detect Kerberoasting? 

Administrators can use the techniques described below to detect Kerberoasting cyberattacks in their network. 

• Check for ticket requests with unusual Kerberos encryption types. Cyberthreat actors can downgrade Kerberos ticket encryption to RC4 since cracking it is significantly faster. Admins can check the events in the Microsoft Defender XDR and filter the results based on the ticket encryption type to check for weaker encryption type usage.  

• Check for alerts from Microsoft Defender. Microsoft Defender XDR will raise an alert with an external ID 2410 for suspected Kerberos SPN exposure.  

• Check for repeated service ticket requests. Check if a single user is requesting multiple service tickets for Kerberoasting-vulnerable accounts in a short time period.  

Recommendations to help prevent Kerberoasting from succeeding 

Microsoft recommends that IT administrators take the following steps to help harden their environments against Kerberoasting: 

• Use Group Managed Service Accounts (gMSA) or Delegated Managed Service Accounts (dMSA) wherever possible:  
  • These accounts are ideal for multi-server applications that require centralized credential management and enhanced security against credential-based attacks, such as IIS, SQL Server, or other Windows services running in a domain-joined environment. 
  • Group Managed Service Account (gMSA) is an Active Directory account type that allows multiple servers or services to use the same account with automatic password management and simplified SPN handling. Passwords for gMSAs are 120 characters long, complex, and randomly generated, making them highly resistant to brute-force cyberattacks using currently known methods.  
  • Delegated Managed Service Accounts (dMSA) are the newest iteration of managed service accounts available on Windows Server 2025. Like gMSAs, they restrict which machines can make use of the accounts and they provide the same password mitigations against Keberoasting. However, unlike gMSAs, dMSAs have the added benefit of supporting seamless migration of standalone service accounts with passwords to the dMSA account type. They can also be optionally integrated with Credential Guard so that even if the server using dMSA is compromised, the service account credentials remain protected.  
• If customers cannot use gMSA or dMSA, then manually set randomly generated, long passwords for service accounts:  
  • Service account administrators should maintain at least a 14-character minimum password. If possible, we recommend setting even longer passwords and randomly generating them for service accounts which will provide better protection against Kerberoasting. This recommendation also applies to normal user accounts.  
  • Ban commonly used passwords and audit the passwords for service accounts so that there is an inventory of accounts with weak passwords and can be remediated.  

• Make sure all service accounts are configured to use AES (128 and 256 bit) for Kerberos service ticket encryption: 
  • Once the encryption type for a service account is updated to Advanced Encryption Standard (AES), change the password for the account to ensure that the password is encrypted using AES. If the password is not changed after updating the encryption type, the account may still be vulnerable to Kerberoasting. AES alone is not a solution for brute forcing and needs to be used in combination with strong passwords. A weak password can still be brute forced even if AES is used for encryption. 
  • In a future update to Windows 11 24H2 and Windows Server 2025 we intend to disable RC4 encryption by default. We recommended manually disabling the RC4 encryption type on service accounts in environments without these updates.  
  • For more information on configuring encryption type, please visit: Active Directory Hardening Series – Part 4 – Enforcing AES for Kerberos – Microsoft Community Hub, Network security Configure encryption types allowed for Kerberos – Windows 10 | Microsoft Learn, and Decrypting the Selection of Supported Kerberos Encryption Types – Microsoft Community Hub 
• Audit the user accounts with SPNs:  
  • User accounts with SPNs should be audited. SPNs should be removed from accounts where they are not needed to reduce the cyberattack surface. 

Conclusion 

Kerberoasting is a threat to Active Directory environments due to its ability to exploit weak passwords and gain unauthorized access to service accounts. By understanding how Kerberoasting works and implementing the recommended guidance shared in this blog, organizations can significantly reduce their exposure to Kerberoasting.  

We truly believe that security is a team effort. By partnering with Original Equipment Manufacturers (OEMs), app developers, and others in the ecosystem, along with helping people to be better at protecting themselves, we are delivering a Windows experience that is more secure by design and secure by default. The Windows Security Book is available to help you learn more about what makes it easy for users to stay secure with Windows.

Next steps with Microsoft Security

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. 

References  

Directory Hardening Series – Part 4 – Enforcing AES for Kerberos – Microsoft Community Hub 

Stopping Active Directory attacks and other post-exploitation behavior with AMSI and machine learning | Microsoft Security Blog 

 Network security Configure encryption types allowed for Kerberos – Windows 10 | Microsoft Learn,  

Decrypting the Selection of Supported Kerberos Encryption Types – Microsoft Community Hub 

Delegated Managed Service Accounts FAQ | Microsoft Learn 

The post Microsoft’s guidance to help mitigate Kerberoasting   appeared first on Microsoft Security Blog.

OpenVPN is widely used by thousands of companies spanning various industries across major platforms such as Windows, iOS, macOS, Android, and BSD. As such, exploitation of the discovered vulnerabilities, which affect all versions of OpenVPN prior to version 2.6.10 (and 2.5.10), could put endpoints and enterprises at significant risk of attack.

We reported the discovery to OpenVPN through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) in March 2024 and worked closely with OpenVPN to ensure that the vulnerabilities are patched. Information on the security fixes released by OpenVPN to address these vulnerabilities can be found here: OpenVPN 2.6.10. We strongly urge OpenVPN users to apply the latest security updates as soon as possible. We also thank OpenVPN for their collaboration and recognizing the urgency in addressing these vulnerabilities.

Below is a list of the discovered vulnerabilities discussed in this blog:

In this blog post, we detail our analysis of the discovered vulnerabilities and the impact of exploitation. In addition to patching, we provide guidance to mitigate and detect threats attempting to exploit these vulnerabilities. This research emphasizes the need for responsible disclosure and collaboration among the security community to defend devices across platforms and build better protection for all, spanning the entire user-device ecosystem. The discovery of these vulnerabilities further highlights the critical importance of ensuring the security of enterprise and endpoint systems and underscores the need for continuous monitoring and protection of these environments.

What is OpenVPN?

OpenVPN is a virtual private network (VPN) system that creates a private and secure point-to-point or site-to-site connection between networks. The OpenVPN open-source project is widely popular across the world, including the United States, India, France, Brazil, the United Kingdom, and Germany, as well as industries spanning the information technology, financial services, telecommunications, and computer software sectors. This project supports different major platforms and is integrated into millions of devices globally.

OpenVPN is also the name of the tunneling protocol it uses, which employs the Secure Socket Layer (SSL) encryption protocol to ensure that data shared over the internet remains private, using AES-256 encryption. Since the source code is available for audit, vulnerabilities can be easily identified and fixed.

OpenVPN analysis

We discovered the vulnerabilities while examining the OpenVPN open-source project to enhance enterprise security standards. During this research, we checked two other popular VPN solutions and found that at the time they were impacted by a vulnerability (CVE-2024-1305). Following this discovery, we started hunting for and uncovered additional vulnerable drivers with the same issue and decided to investigate open-source VPN projects. Upon confirming that the same vulnerability was located in the OpenVPN open-source repository, our research then focused on examining the architecture and security model of the OpenVPN project for Windows systems.

OpenVPN architecture

OpenVPN server client architecture

OpenVPN is a sophisticated VPN system meticulously engineered to establish secure point-to-point or site-to-site connections. It supports both routed and bridged configurations, as well as remote access capabilities, making it a versatile choice for various networking needs. OpenVPN comprises both client and server applications, ensuring a comprehensive solution for secure communication.

With OpenVPN, peers can authenticate each other through multiple methods, including pre-shared secret keys, certificates, or username/password combinations. In multi-client server environments, the server can generate and issue an individual authentication certificate for each client, leveraging robust digital signatures and a trusted certificate authority. This ensures an elevated level of security and integrity in the authentication process, enhancing the overall reliability of the VPN connection. 

Client-side architecture

The client-side architecture is where we discovered the additional three vulnerabilities (CVE-2024-27459, CVE-2024-24974, and CVE-2024-27903):

OpenVPN’s client architecture can be summarized in the following simplified diagram:

openvpnserv.exe and openvpn.exe

The system service launches elevated commands on behalf of the user, handling tasks such as adding or deleting DNS configurations, IP addresses, and routes, and enabling Dynamic Host Configuration Protocol (DHCP). These commands are received from the openvpn.exe process through a named pipe created for these two entities, such as “openvpn/service_XXX” where XXX is the thread ID (TID) that is being passed to the newly created process as a command line argument.

The launched commands arrive in the form of a binary structure that contains the relevant information for the specific command, with the structure being validated and only then launching the appropriate command. The below figure displays an example of the structure that contains information for adding/deleting DNS configuration:

Additionally, openvpnserv.exe serves as the management unit, spawning openvpn.exe processes upon requests from different users on the machine. This can be done automatically using the OpenVPN GUI or by sending specifically crafted requests. Communication for this process occurs through a second named pipe, such as “openvpn/service”.

Openvpn.exe is the user mode process being spawned on behalf of the client. When openvpn.exe starts, it receives a path for a configuration file (as a command line argument). The configuration file that’s provided holds different information.

A lot of fields can be managed in configuration files, such as:

1. Tunnel options
2. Server mode options
3. Client mode options

Plugin mechanism in openvpn.exe

Another mechanism of interest for us is the plugin mechanism in openvpn.exe, which can extend the functionality to add additional logic, such as authentication plugins to bring authentication against Lightweight Directory Access Protocol (LDAP) or Radius or other Pluggable Authentication Module
(PAM) backends. Some of the existing plugins are:

1. Radiusplugin – Radius authentication support for open OpenVPN.
2. Eurephia – Authentication and access control plugin for OpenVPN.
3. Openvpn_defer_auth – OpenVPN plugin to perform deferred authentication requests.

The plugin mechanism fits into the earlier diagram, as shown in Figure 2.

The plugin is loaded as a directive in the configuration file, which looks like:

Furthermore, the number of callbacks defined in the plugin launch on behalf of the loading process (openvpn.exe), such as:

1. openvpn_plugin_func_v1 – This function is called by OpenVPN each time the OpenVPN reaches a point where plugin calls should happen.
2. openvpn_plugin_{open, func}_v3() – Defines the version of the v3 plugin argument.

OpenVPN security model

As previously mentioned, we discovered four vulnerabilities on the client side of OpenVPN’s architecture.

As described before, openvpnserv.exe (SYSTEM service) spawns the openvpn.exe process as a result of the request from the user. Furthermore, the spawned process runs in the context of the user who requested to create the new process, which is achieved through named pipe impersonation, as displayed in the below image:

The ImpersonateNamedPipeClient function impersonates a named pipe client application.

Furthermore, to prevent unwanted behavior, specific EXPLICIT_ACCESS must be granted for any new process:

This explicit access, in addition to the earlier described “elevated commands” launched by openvpnserv.exe on request from the openvpn.exe process, and other comprehensive inspection of the passed arguments  ensure that malicious behavior cannot be launched in the name of the impersonated user.

Vulnerability analysis

CVE-2024-1305    

We identified a vulnerability in the “tap-windows6” project that involves developing the Terminal Access Point (TAP) adapter used by OpenVPN. In the project’s src folder, the device.c file contains the code for the TAP device object and its initialization.

In the device.c file, the CreateTapDevice method initializes a dispatch table object with callbacks for methods managing various Input/Output Controls (IOCTLs) for the device. One of these methods is TapDeviceWrite, which handles the write IOCTL.

The TapDeviceWrite method performs several operations and eventually calls TapSharedSendPacket. This method, in turn, calls NdisAllocateNetBufferAndNetBufferLists twice. In one scenario, it calls this function with the fullLength parameter, defined as follows:

Both PacketLength and PrefixLength are parameters passed from the TapDeviceWrite call and, therefore, attacker controlled. If these values are large enough, their sum (fullLength) can overflow (a 32-bit unsigned integer). This overflow results in the allocation of a smaller-than-expected memory size, which subsequently causes a memory overflow issue.

CVE-2024-27459  

The second vulnerability that we discovered resided in the communication mechanism between the openvpn.exe process and the openvpnserv.exe service. As described earlier, both of which communicate through a named pipe:

The openvpnserv.exe service will read the message size in an infinite loop from the openvpn.exe process and then handle the message received by calling the HandleMessage method. The HandleMessage method reads the size provided by the infinite loop and casts the read bytes into the relevant type accordingly:

This communication mechanism presents an issue as reading the “user” provided number of bytes on to an “n bytes” long structure located on the stack will produce a stack overflow vulnerability.

CVE-2024-24974  

The third vulnerability involves unprivileged access to an operating system resource. The openvpnserv.exe service spawns a new openvpn.exe process based on user requests received through the “\\openvpn\\service” named pipe. This vulnerability allows remote access to the named service pipe, enabling an attacker to remotely interact with and launch operations on it.

CVE-2024-27903  

Lastly, we identified a vulnerability in OpenVPN’s plugin mechanism that permits plugins to be loaded from various paths on an endpoint device. This behavior can be exploited by attackers to load harmful plugins from these different paths.

Exploiting and chaining the vulnerabilities

All the identified vulnerabilities can be exploited once an attacker gains access to a user’s OpenVPN credentials, which could be accomplished using credential theft techniques, such as purchasing stolen credentials on the dark web, using info-stealing malware, or sniffing network traffic to capture NTLMv2 hashes and then using cracking tools like HashCat or John the Ripper to decode them. The discovered vulnerabilities could then be combined to achieve different exploitation results, or chained together to form a sophisticated attack chain, as detailed in the below sections.

RCE exploitation

We first explored how an attacker could achieve remote code execution (RCE) exploitation using CVE-2024-24974 and CVE-2024-27903.

To successfully exploit these vulnerabilities and achieve RCE, an attacker must first obtain an OpenVPN user’s credentials. The attacker’s device must then launch the NET USE command with the stolen credentials to remotely access the operating system resources and grant the attacker access to the named pipes objects devices.

Next, the attacker can send a “connect” request to the “\\openvpn\\service” named pipe to launch a new instance of openvpn.exe on its behalf.

In the request, a path to a configuration file (\\\\DESKTOP-4P6938I\\share\\OpenVPN\\config\\sample.ovpn) is specified that’s located on the attacker-controlled device. A log path is also provided into which the loaded plugin will write its logs (“–log \\\\\{TARGET_MACHINE_PLACEHOLDER}\\share\\OpenVPN\\log\\plugin_log.txt\).

The provided configuration has instructions to load malicious plugin, as such:

After successful exploitation, the attacker can read the log provided on the attacker-controlled device.

LPE exploitation

Next, we investigated how an attacker could achieve local privilege execution (LPE) using CVE-2024-27459 and CVE-2024-27903. To successfully achieve an LPE exploit in this context, an attacker must load a malicious plugin into the normal launching process of openvpn.exe by using a malicious configuration file.

First, the attacker will connect to a local device “\\openvpn\\service” named pipe with a command that instructs openvpnserv.exe to launch openvpn.exe based on the attacker-provided malicious configuration.

The malicious configuration will include a line like the below example:

For the malicious plugin to successfully communicate with openvpnserv.exe, it must hijack the number of the handle used by openvpn.exe to communicate with the inner named pipe connecting the openvpv.exe process and the openvpnserv.exe service. This can be achieved, for instance, by parsing command line arguments, as displayed below:

This works because when the openvpn.exe process spawns, it’s being passed the TID (as a command line argument) that the inner named pipe (which is being used for communication between this specific OpenVPN instance and the openvpnserv.exe service) will have. For instance, if the inner named pipe created is “\\openvpn\\service_1234” then openvpn.exe will be launched with an extra argument of 1234.

Next, attackers can exploit the stack overflow vulnerability by sending data bigger than the MSG structure. It is important to note that there are stack protection mechanisms in place, called stack canaries, which make exploitation much more challenging. Thus, when triggering the overflow:

After the crash of openvpnserv.exe, the attacker has a slot of time in which they can reclaim the named pipe “\\openvpn\\service”.

If successful, the attacker then poses as the server client side of the named pipe “\\openvpn\\service”. From that moment on, every attempt to connect to the “\\openvpn\\service” named pipe will result in a connection to the attacker. If a privileged enough user, such as a SYSTEM or Administrator user, is connected to the named pipe, the attacker can impersonate that user:

The attacker can then start an elevated process on the user’s behalf, thus achieving LPE.

Chaining it all together

As our research demonstrated, an attacker could leverage at least three of the four discovered vulnerabilities to create exploits to achieve RCE and LPE, which could then be chained together to create a powerful attack chain.

A number of adjustments are needed for the full attack chain to be exploited as presented in this blog post, mainly the malicious payload that crashes openvpnserv.exe and the malicious payload that actually behaves as openvpnserv.exe after openvpnserv.exe is crashed all have to be loaded with the malicious plugin. After successfully achieving LPE, attackers will use different techniques, such as Bring Your Own Vulnerable Driver (BYOVD) or exploiting known vulnerabilities, to achieve a stronger grasp of the endpoint. Through these techniques, the attacker can, for instance, disable Protect Process Light (PPL) for a critical process such as Microsoft Defender or bypass and meddle with other critical processes in the system. These actions enable attackers to bypass security products and manipulate the system’s core functions, further entrenching their control and avoiding detection.

Critical importance of endpoint security in private and enterprise sectors

With OpenVPN being widely used across various vendors, industries, and fields, the presented vulnerabilities may impact numerous sectors, device types, and verticals. Exploiting these vulnerabilities requires user authentication, a deep understanding of OpenVPN’s inner workings, and intermediate knowledge of the operating system. However, a successful attack could significantly impact endpoints in both the private and enterprise sectors. Attackers could launch a comprehensive attack chain on a device using a vulnerable version of OpenVPN, achieving full control over the target endpoint. This control could enable them to steal sensitive data, tamper with it, or even wipe and destroy critical information, causing substantial harm to both private and enterprise environments.

The discovery of these vulnerabilities underscores the importance of responsible disclosure to secure enterprise and endpoint systems, in addition to the collective efforts of the security community to protect devices across various platforms and establish stronger safeguards for everyone. We would like to again thank OpenVPN for their partnership and swift action in addressing these vulnerabilities.

Mitigation and protection guidance

OpenVPN versions prior to 2.5.10 and 2.6.10 are vulnerable to discussed vulnerabilities.

It is recommended to first identify if a vulnerable version is installed and, if so, immediately apply the relevant patch found here: OpenVPN 2.6.10.

Additionally, follow the below recommendations to further mitigate potential exploitation risks affiliated with the discovered vulnerabilities:

• Apply patches to affected devices in your network. Check the OpenVPN website for the latest patches.
• Make sure OpenVPN clients are disconnected from the internet and segmented.
• Limit access to OpenVPN clients to authorized users only. 
• Due to the nature of the CVEs, which still require a username and password, prioritizing patching is difficult. Reduce risk by ensuring proper segmentation, requiring strong usernames and passwords, and reducing the number of users that have writing authentication.

Microsoft Defender XDR detections

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alert can indicate associated threat activity:

• Suspicious OpenVPN named pipe activity

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used in this threat:

• CVE-2024-27459
• CVE-2024-24974
• CVE-2024-27903
• CVE-2024-1305

Microsoft Defender for IoT

Microsoft Defender for IoT raises alerts for the following vulnerabilities, exploits, and behavior associated with this threat:

• Suspicion of Malicious Activity

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

This query identifies connection to OpenVPN’s named pipe from remote host:

DeviceEvents  
| where ActionType == "NamedPipeEvent"
| extend JsonAdditionalFields=parse_json(AdditionalFields)
| extend PipeName=JsonAdditionalFields["PipeName"]
| where PipeName == "\\Device\\NamedPipe\\openvpn\\service" and isnotempty( RemoteIP) 

This query identifies image load into OpenVPN’s process from share folder:

DeviceImageLoadEvents 
|where InitiatingProcessFileName == "openvpn.exe" and FolderPath startswith "\\\\"

This query identifies process connect to OpenVPN’s named pipe as server which it is not openvpnserv.exe:

DeviceEvents  
| where ActionType == "NamedPipeEvent"
| extend JsonAdditionalFields=parse_json(AdditionalFields)
| extend PipeName=JsonAdditionalFields["PipeName"], NamedPipeEnd=JsonAdditionalFields["NamedPipeEnd"]
|where PipeName == "\\Device\\NamedPipe\\openvpn\\service" and NamedPipeEnd == "Server" and InitiatingProcessFileName != "openvpnserv.exe"

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.

List of devices with OpenVPN vulnerabilities

DeviceTvmSoftwareVulnerabilities
| where OSPlatform contains "Windows"
| where CveId in ("CVE-2024-27459","CVE-2024-24974","CVE-2024-27903","CVE-2024-1305") 
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,
CveId,VulnerabilitySeverityLevel
| join kind=inner ( DeviceTvmSoftwareVulnerabilitiesKB | project CveId, CvssScore,IsExploitAvailable,VulnerabilitySeverityLevel,PublishedDate,VulnerabilityDescription,AffectedSoftware ) on CveId
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,
CveId,VulnerabilitySeverityLevel,CvssScore,IsExploitAvailable,PublishedDate,VulnerabilityDescription,AffectedSoftware

Named pipe creation activity of OpenVPN

let PipeNames = pack_array('\\openvpn/service','\\openvpn/service_','openvpn','openvpn/service','\\openvpn\\service_');
DeviceEvents
| where TimeGenerated > ago(30d)
| where ActionType == "NamedPipeEvent"
| where ProcessCommandLine contains "openvpn.exe" or InitiatingProcessCommandLine contains "openvpn.exe"
| extend Fields=parse_json(AdditionalFields)
| where Fields.FileOperation == "File created"
| where Fields.PipeName has_any (PipeNames)
| project TimeGenerated,ActionType,DeviceName,InitiatingProcessAccountDomain,InitiatingProcessAccountName,InitiatingProcessFolderPath,
InitiatingProcessCommandLine,ProcessCommandLine,Fields.FileOperation,Fields.PipeName

Vladimir Tokarev

Microsoft Threat Intelligence Community

References

• https://blackhat.com/us-24/briefings/schedule/#ovpnx–zero-days-leading-to-rce-lpe-and-kce-via-byovd-affecting-millions-of-openvpn-endpoints-across-the-globe-38900
• https://enlyft.com/tech/products/openvpn
• https://github.com/OpenVPN/openvpn/blob/v2.6.10/Changes.rst
• https://github.com/OpenVPN/openvpn/blob/v2.5.10/Changes.rst
• https://forums-new.openvpn.net/forum/announcements/69-release-openvpn-version-2-6-10
• https://openvpn.net/community-downloads/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27459
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-24974
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27903
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-1305
• https://openvpn.net/as-docs/site-to-site-routing.html#site-to-site-routing
• https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
• https://github.com/OpenVPN/openvpn/blob/master/include/openvpn-plugin.h.in
• https://www.lifewire.com/net-use-command-2618096
• https://wikipedia.org/wiki/Stack_buffer_overflow#Stack_canaries
• https://community.openvpn.net/openvpn/wiki/Downloads
• https://www.cisa.gov/secure-our-world/use-strong-passwords

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 Chained for attack: OpenVPN vulnerabilities discovered leading to RCE and LPE appeared first on Microsoft Security Blog.

Today’s threat landscape is unlike any we’ve seen before. Attacks are growing in speed, scale, and sophistication. In 2015, our identity systems were detecting around 115 password attacks per second. Less than a decade later, that number has surged 3,378% to more than 4,000 password attacks per second.¹ This landscape requires stronger and more comprehensive security approaches than ever before, across all devices and technologies we use in our lives both at home and at work.

Cybersecurity at the forefront of all we do

We’ve always had a longstanding commitment to security in Windows. Several years back, when we saw cyberattackers increasingly exploiting hardware, we introduced the Secured-core PC to help secure from chip to cloud and that critical layer of computing.

As we’ve seen identity-based cyberattacks increase at an alarming rate over the years, we’ve expanded our passwordless offerings quickly and broadly. In September 2023, we announced expanded passkey support with cross-device authentication, and have continued to build on that momentum. Earlier this month we announced passkey support for Microsoft consumer accounts and for device-bound passkeys in the Microsoft Authenticator app for iOS and Android users, expanding our support of this industry initiative backed by the FIDO Alliance. Passkeys on Windows are protected by Windows Hello technology that encompasses both Windows Hello and Windows Hello for Business. This latest step builds on nearly a decade of critical work strengthening Windows Hello to give users easier and more secure sign-in options and eliminate points of vulnerability.

Earlier this month we expanded our Secure Future Initiative (SFI), making it clear that we are prioritizing security above all else. SFI, a commitment we shared first in November 2023, prioritizes designing, building, testing, and operating our technology in a way that helps to ensure secure and trustworthy product and service delivery. With these commitments in mind, we’ve not only built new security features into Windows 11, but we’ve also doubled down on security features that will be turned on by default. Our goal remains simple: make it easy to stay safe with Windows. 

Today we are sharing exciting updates that make Windows more secure out of the box, by design and by default.

Windows 11

Create, collaborate, and keep your stuff protected.

Learn more

Modern, secure hardware

We believe security is a team sport. We are working in close partnership with our Original Equipment Manufacturer (OEM) partners to complement OEM security features and deliver more secure devices out of the box.

While Secured-core PCs were once considered specialized devices for those handling sensitive data, now Windows users can benefit from enhanced security and AI on one device. We announced that all Copilot+ PCs will be Secured-core PCs, bringing advanced security to both commercial and consumer devices. In addition to the layers of protection in Windows 11, Secured-core PCs provide advanced firmware safeguards and dynamic root-of-trust measurement to help protect from chip to cloud. 

Microsoft Pluton security processor will be enabled by default on all Copilot+ PCs. Pluton is a chip-to-cloud security technology—designed by Microsoft and built by silicon partners—with Zero Trust principles at the core. It helps protect credentials, identities, personal data, and encryption keys, making it significantly harder to remove, even if a cyberattacker installs malware or has physical possession of the PC.

All Copilot+ PCs will also ship with Windows Hello Enhanced Sign-in Security (ESS). This provides more secure biometric sign ins and eliminates the need for a password. ESS provides an additional level of security to biometric data by leveraging specialized hardware and software components, such as virtualization-based security (VBS) and Trusted Platform Module 2.0 to help isolate and protect authentication data and secure the channel on which it is communicated. ESS is also available on other compatible Windows 11 devices.

Stay ahead of evolving threats with Windows

To enhance user security from the start, we’re continuously updating security measures and enabling new defaults within Windows.

Windows 11 is designed with layers of security enabled by default, so you can focus on your work, not your security settings. Out-of-the-box features such as credential safeguards, malware shields, and application protection led to a reported 58% drop in security incidents, including a 3.1 times reduction in firmware attacks. In Windows 11, hardware and software work together to help shrink the attack surface, protect system integrity, and shield valuable data.² 

Credential and identity theft is a prime focus of cyberattackers. Enabling multifactor authentication with Windows Hello, Windows Hello for Business, and passkeys are effective multifactor authentication solutions. But, as more people enable multifactor authentication, cyberattackers are moving away from simple password-based attacks and focusing energy on other types of credential theft. We have been working to make this more difficult with our latest updates:

• Local Security Authority protection: Windows has several critical processes to verify a user’s identity, including the Local Security Authority (LSA). LSA authenticates users and verifies Windows sign ins, handling tokens and credentials, such as passwords, that are used for single sign-on to Microsoft accounts and Microsoft Azure services. LSA protection, previously on by default for all new commercial devices, is now also enabled by default for new consumer devices. For users upgrading where it has not previously been enabled, For new consumer devices and for users upgrading where it has not been enabled, LSA protection will enter into a grace period. LSA protection prevents LSA from loading untrusted code and prevents untrusted processes from accessing LSA memory, offering significant protection against credential theft.³ 
• NT LAN Manager (NTLM) deprecation: Ending the use of NTLM has been a huge ask from our security community as it will strengthen authentication. NTLM is being deprecated, meaning that, while supported, it is no longer under active feature development. We are introducing new features and tools to ease customers’ transitions to stronger authentication protocols.
• Advancing key protection in Windows using VBS: Now available in public preview for Windows Insiders, this feature helps to offer a higher security bar than software isolation, with stronger performance compared to hardware-based solutions, since it is powered by the device’s CPU. While hardware-backed keys offer strong levels of protection, VBS is helpful for services with high security, reliability, and performance requirements.
• Windows Hello hardening: With Windows Hello technology being extended to protect passkeys, if you are using a device without built-in biometrics, Windows Hello has been further hardened by default to use VBS to isolate credentials, protecting from admin-level attacks.

We have also prioritized helping users know what apps and drivers can be trusted to better protect people from phishing attacks and malware. Windows is both creating new inbox capabilities as well as providing more features for the Windows app developer community to help strengthen app security.

• Smart App Control: Now available and on by default on select new systems where it can provide an optimal experience, Smart App Control has been enhanced with AI learning. Using an AI model based on the 78 trillion security signals Microsoft collects each day, this feature can predict if an app is safe. The policy keeps common, known-to-be-safe apps running while unknown, malware-connected apps are blocked. This is incredibly effective protection against malware.
• Trusted Signing: Unsigned apps pose significant risks. In fact, Microsoft research has revealed that a lot of malware comes in the form of unsigned apps. The best way to ensure seamless compatibility with Smart App Control is with signing of your app. Signing contributes to its trustworthiness and helps ensure that an existing “good reputation” will be inherited by future app updates, making it less likely to be blocked inadvertently by threat detection systems. Recently moved into public preview, trusted signing makes this process simpler by managing every aspect of the certificate lifecycle. And it integrates with popular development tooling like Azure DevOps and GitHub.
• Win32 app isolation: A new security feature, currently in preview, Win32 app isolation makes it easier for Windows app developers to contain damage and safeguard user privacy choices in the event of an application compromise. Win32 app isolation is built on the foundation of AppContainers, which offer a security boundary, and components that virtualize resources and provide brokered access to other resources—like printer, registry, and file access. Win32 app isolation is close to general availability thanks to feedback from our developer community. App developers can now use Win32 app isolation with seamless Visual Studio integration.
• Making admin users more secure: Most people run as full admins on their devices, which means apps and services have the same access to the kernel and other critical services as users. And the problem is that these apps and services can access critical resources without the user knowing. This is why Windows is being updated to require just in time administrative access to the kernel and other critical services as needed, not all the time, and certainly not by default. This makes it harder for an app to unexpectedly abuse admin privileges and secretly put malware or malicious code on Windows. When this feature is enabled, such as when an app needs special permissions like admin rights, you’ll be asked for approval. When an approval is needed, Windows Hello provides a secure and easy way to approve or deny these requests, giving you, and only you, full control over your device. Currently in private preview, this will be available in public preview soon. 
• VBS enclaves: Previously available to Windows security features only, VBS enclaves are now available to third-party application developers. This software-based trusted executive environment within a host application’s address space offers deep operating system protection of sensitive workloads, like data decryption. Try the VBS enclave APIs to experience how the enclave is shielded from both other system processes and the host application itself. This results in more security for your sensitive workloads.

As we see cyberattackers come up with new strategies and targets, we continue to harden Windows code to address where bad actors are spending their time and energy.

• Windows Protected Print: In late 2023, we launched Windows Protected Print Mode to build a more modern and secure print system that maximizes compatibility and puts users first. This will be the default print mode in the future.
• Tool tips: In the past, tool tips have been exploited, leading to unauthorized access to memory. In older Windows versions, tool tips were managed as a single window for each desktop, established by the kernel and recycled for displaying any tool tip. We are revamping how tool tips work to be more secure for users. With the updated approach, the responsibility for managing the lifecycle of tool tips has been transferred to the respective application that is being used. Now, the kernel monitors cursor activity and initiates countdowns for the display and concealment of tool tip windows. When these countdowns conclude, the kernel notifies the user-level environment to either generate or eliminate a tool tip window.
• TLS server authentication: TLS (transport layer security) server authentication certificates verify the server’s identity to a client and ensure secure connections. While 1024-bit RSA encryption keys were previously supported, advancements in computing power and cryptanalysis require that Windows no longer trust these weak key lengths by default. As a result, TLS certificates with RSA keys less than 2048 bits chaining to roots in the Microsoft Trusted Root Program will not be trusted.

Lastly, with each Windows release we add more levers for commercial customers to lock down Windows within their environment.

• Config Refresh: Config Refresh allows administrators to set a schedule for devices to reapply policy settings without needing to check in to Microsoft Intune or other mobile device management vendors, helping to ensure settings remain as configured by the IT admin. It can be set to refresh every 90 minutes by default or as frequently as every 30 minutes. There is also an option to pause Config Refresh for a configurable period, useful for troubleshooting or maintenance, after which it will automatically resume or can be manually reactivated by an administrator.
• Firewall: The Firewall Configuration Service Provider (CSP) in Windows now enforces an all-or-nothing application of firewall rules from each atomic block of rules. Previously, if the CSP encountered an issue with applying any rule from a block, the CSP would not only stop that rule, but also would cease to process subsequent rules, leaving a potential security gap with partially deployed rule blocks. Now, if any rule in the block cannot be applied successfully to the device, the CSP will stop processing subsequent rule and all rules from that same atomic block will be rolled back, eliminating the ambiguity of partially deployed rule blocks.
• Personal Data Encryption (PDE): PDE enhances security by encrypting data and only decrypting it when the user unlocks their PC using Windows Hello for Business. PDE enables two levels of data protection. Level 1, where data remains encrypted until the PC is first unlocked; or Level 2, where files are encrypted whenever the PC is locked. PDE complements BitLocker’s volume level protection and provides dual-layer encryption for personal or app data when paired with BitLocker. PDE is in preview now and developers can leverage the PDE API to protect their app content, enabling IT admins to manage protection using their mobile device management solution. 
• Zero Trust DNS: Now in private preview, this feature will natively restrict Windows devices to connect only to approved network destinations by domain name. Outbound IPv4 and IPv6 traffic is blocked and won’t reach the intended destination unless a trusted, protected DNS server resolved it, or an IT admin configures an exception. Plan now to avoid blocking issues by configuring apps and services to use the system DNS resolver.

Explore the new Windows 11 security features

We truly believe that security is a team sport. By partnering with OEMs, app developers and others in the ecosystem—along with helping people to be better at protecting themselves—we are delivering a Windows that is more secure by design and secure by default. The Windows Security Book is available to help you learn more about what makes it easy for users to stay secure with Windows.

Learn more about Windows 11.

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.

¹Microsoft Password Guidance, Microsoft Identity Protection Team. 2016.

²Windows 11 Survey Report, Techaisle. February 2022.

³Users can manage their LSA protection state in the Windows Security Application under Device Security -> Core Isolation -> Local Security Authority.

The post New Windows 11 features strengthen security to address evolving cyberthreat landscape appeared first on Microsoft Security Blog.

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

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.

¹How 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.

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.

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_*

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.

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
or 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

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.

Microsoft Intune

Enhance security and IT efficiency with the Microsoft Intune Suite.

Learn more

The broad value of the Intune Suite

While the solutions of the Intune Suite launched at different points in time, three fundamental principles have been there from the beginning.

First, one place for workloads adjacent to Unified Endpoint Management. If you’re currently using a mix of third-party solutions, the integrated experience in Microsoft Intune provides security and efficiency on multiple levels. First, one unified solution means fewer integrations to manage across third parties, meaning fewer attack vectors for malicious actors. And second, on a deeper level, the broader Intune proposition (both Intune Suite and Intune) is integrated with Microsoft 365 and Microsoft Security solutions. This provides a consolidated and seamless experience for IT professionals with a single pane of glass for end-to-end endpoint management.

Second, all parts of the Intune Suite are ready to support your cloud and AI-enabled future. Intune Suite will help accelerate organizations’ digital transformation to cloud native and simplify their IT operations. Additionally, data from Intune Suite are consolidated with other Intune and security data, meaning complete visibility across the device estate, informing and improving emerging technologies like Microsoft Copilot for Security. The more interrelated data that Copilot can use, the more it can proactively advise on the next best action.

Lastly, Intune Suite is available in a single unified plan. So, rather than having separate solutions for remote assistance, privilege management, analytics, and more, these advanced solutions can all be consolidated and simplified into one. This provides value in two ways: directly, by reducing the overall licensing cost, as the cost of Intune Suite is less than purchasing separate solutions; and the economic value of the Intune Suite is also in indirect savings: no need to manage separate vendors, train IT admins on separate tools, or maintain costly on-premises public key infrastructure (PKI). The Intune Suite makes it easier for IT admins, reducing overhead costs.

“With what we get out of Intune Suite, we can eliminate other products that our customers need. It’s now a suite of many components that enable customers who want to consolidate solutions and save money.”

—Mattias Melkersen Kalvåg, Mobility and Windows Management Consultant at MINDCORE, and| Microsoft Certified Professional & MVP

From today: A comprehensive suite across applications, access needs, and support

Let’s get into specifics. For application security, Enterprise App Management helps you find, deploy, and update your enterprise apps. And Endpoint Privilege Management lets you manage elevation rules on a per-app basis so that even standard users can run approved privileged apps. Cloud PKI lets you manage certificates from the cloud in lieu of complex, on-premises PKI infrastructure. And Microsoft Tunnel for Mobile Application Management (MAM) is perfect for unenrolled, personal mobile devices, to help broker secure access to line of business apps. Advanced Analytics gives you data-rich insights across your endpoints. And Remote Help lets you view and control your PCs, Mac computers, and specialized mobile devices, right from the Intune admin center. Let us take each of those three product areas in turn.

Increase endpoint security with Enterprise App Management and Endpoint Privilege Management

Enterprise App Management gives you a new app catalog, allowing you to easily distribute managed apps, but also keep them patched and always up to date. With this initial release, you will be able to discover and deploy highly popular, pre-packaged apps, so you no longer need to scour the Internet to find their installation files, repackage, and upload them into Intune. Simply add and deploy the apps directly from their app publishers. You can also allow the apps you trust to self-update, and when a new update is available, it is just one click to update all your devices with that app installed. We will continuously expand and enrich the app catalog functionality in future releases to further advance your endpoint security posture and simplify operations. 

“I’m very excited about Enterprise App Management as it’s powered by a strong app catalog and natively integrated in Intune. This single pane of glass experience is what we’re all looking for.”

—Niklas Tinner, Microsoft MVP and Senior Endpoint Engineer at baseVISION AG

For more control over your apps, with Endpoint Privilege Management, you can scope temporary privilege elevation, based on approved apps and processes. Then, as a user in scope for this policy, you can elevate only the processes and apps that have been approved. For example, users can only run a single app for a short period of time as an administrator. Unlike other approaches that give local admin permissions or virtually unlimited scope, you can selectively allow a user to elevate in a one-off scenario by requesting Intune admin approval, without you needing to define the policy ahead of time.

“Endpoint Privilege Management offers tight integration into the operating system. And the focus that Microsoft has over only elevating specific actions and apps versus making you an admin for a period of time—this is security at its best, going for the least privileged access.”

—Michael Mardahl, Cloud Architect at Apento

Cloud PKI and Microsoft Tunnel for MAM powers secure access

With Cloud PKI, providing both root and issuing Certificate Authorities (CA) in the cloud, you can simply set up a PKI in minutes, manage the certificate lifecycle, reduce the need for extensive technical expertise and tools, and minimize the effort and cost of maintaining on-premises infrastructure. In addition, support for Bring-Your-Own CA is available, allowing you to anchor Intune’s Issuing CA to your own private CA. Certificates can be deployed automatically to Intune-managed devices for scenarios such as authentication to Wi-Fi, VPN, and more; a modern PKI management option that works well to secure access with Microsoft Entra certificate-based authentication. In the initial release, Cloud PKI will also work with your current Active Directory Certificate Services for SSL and TLS certificates, but you do not need to deploy certificate revocation lists, Intune certificate connectors, Network Device Enrollment Service (NDES) servers, or any reverse proxy infrastructure. You can issue, renew, or revoke certificates directly from the Intune admin center automatically or manually. 

Microsoft Tunnel for MAM helps secure mobile access to your private resources. Microsoft Tunnel for MAM works similarly to Microsoft Tunnel for managed devices; however, with this advanced solution, Microsoft Tunnel for MAM works with user-owned (non-enrolled) iOS and Android devices. Microsoft Tunnel for MAM provides secure VPN access at the app level, for just the apps and browser (including Microsoft Edge) your IT admin explicitly authorizes. So, for personally owned devices, the user can access approved apps, without your company’s data moving onto the user’s personal device. App protection policies protect the data within the apps, preventing unauthorized data leakage to other apps or cloud storage locations.

“Cloud PKI within the Intune Suite allows you to go cloud native in terms of certificate deployment, which means you can provision PKIs with just a few clicks—that’s a blessing for all the IT administrators. With this built-in service, Microsoft hosts everything for you to manage certificates.”  

—Niklas Tinner

Resolve support issues quicker with Advanced Analytics and Remote Help

Advanced Analytics in Intune is a powerful set of tools for actionable reporting and AI-driven analytics. It provides deep, near real-time insights into your connected devices and managed apps that help you understand, anticipate, and proactively improve the user experience. We continue to infuse AI and machine learning into our analytics products. For example, you can get ahead of battery degradation in your device fleet through our advanced statistical analysis and use that information to prioritize hardware updates. Intune Suite now includes real-time device querying on-demand using Kusto Query Language for individual devices, useful for troubleshooting and resolving support calls quicker.

With Remote Help, you can also streamline the way you remotely view and interact with your managed devices, for both user-requested or unattended sessions. As a help desk technician, you can securely connect to both enrolled and unenrolled devices. Users also have peace of mind in being able to validate the technician’s identity, to avoid help desk spoofing attempts. Right now, Remote Help works for remote viewing and controlling in Windows PCs and Android dedicated Enterprise devices, and supports remote viewing for macOS. Especially useful for frontline workers, Remote Help for Android allows help desk administrators to configure and troubleshoot unattended devices, meaning issues can be revolved off-shift.

“Remote Help takes away the requirement and the need for third-party remote help tools. Remote Help is native, it’s interactive, and you don’t have to worry about installing anything, it’s already there. It’s part of Intune, it’s part of the build.”

—Matthew Czarnoch, Cloud and Infrastructure Operations Manager at RLS (Registration and Licensing Services)

To see many of these new capabilities in action, we invite you to watch this new Microsoft Mechanics video.

Analyst recognition for Microsoft

With the additions to the Intune Suite now available, IT can power a more secure and productive future at an important time as AI comes online. Notably, analyst recognition is validating the importance of its value. For example, Microsoft again assumes the strongest leadership position in the Omdia Universe: Digital Workspace Management and Unified Endpoint Management Platforms 2024. Omdia wrote: “Microsoft is focused on reducing management costs by utilizing the Microsoft Intune Suite and integrating different solutions with it.” They added: “The company plans to invest in Endpoint Analytics and Security Copilot to introduce data-driven management, helping IT professionals shift from reactive, repetitive tasks to strategic ones by utilizing Endpoint Analytics and automation.” Omdia’s recognition follows that from others like Forrester, who named Microsoft as a Leader in The Forrester Wave™ for Unified Endpoint Management, Q4 2023.

Get started with consolidated endpoint management solutions with the Microsoft Intune Suite

The February 2024 release of the solutions in the Intune Suite marks a key milestone, offering a consolidated, comprehensive solution set together in a cost-effective bundle (and available as individual add-on solutions) for any plan that includes Intune. And in April 2024, they will also be available to organizations and agencies of the United States government community cloud. We look forward to hearing your reactions to the new Intune Suite.

• Microsoft Intune News at Microsoft Ignite 2023.
• Learn more about Microsoft Intune.
• Omdia Universe: Digital Workspace Management/Unified Endpoint Management Platforms 2024.
• Forrester Wave™ for Unified Endpoint Management, Q4 2023. 
• Microsoft Cloud PKI blog announcement at Microsoft Ignite 2023.
• Microsoft Intune Enterprise App Management blog announcement at Microsoft Ignite 2023.
• Microsoft Intune Advanced Analytics blog announcement at Microsoft Ignite 2023.

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.

¹Ease the burden of managing and protecting endpoints with Microsoft advanced solutions, Dilip Radhakrishnan and Gideon Bibliowicz. April 5, 2022.

The Forrester Wave™ is copyrighted by Forrester Research, Inc. Forrester and Forrester Wave™ are trademarks of Forrester Research, Inc. The Forrester Wave™ is a graphical representation of Forrester’s call on a market and is plotted using a detailed spreadsheet with exposed scores, weightings, and comments. Forrester does not endorse any vendor, product, or service depicted in the Forrester Wave™. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.

The Forrester Wave™: Unified Endpoint Management, Q4 2023, Andrew Hewitt, Glen O’Donnell, Angela Lozada, Rachel Birrell. November 19, 2023.

The post 3 new ways the Microsoft Intune Suite offers security, simplification, and savings appeared first on Microsoft Security Blog.

In this blog, I will focus on how you can accelerate your transition to cloud native endpoint management. Many of my customer conversations are centered on how best to transition, with the value of a cloud first approach already understood. In many cases, there is a strong desire to move to the cloud, but lack of a step-by-step plan to make the move a reality. I detail below a three-phase approach that simplifies the process of getting to fully cloud-based management. First, modernize all management workloads by moving them from on premises to Intune. Second, hybrid Entra join and enroll your existing PCs in Intune. Third, for new Windows devices, go straight to cloud native. 

Microsoft Intune

Protect and manage endpoints in one place.

Discover more 

This three-phase approach enables you to achieve faster time to value, lessen the experience impact to your users, and finally, simplify your architecture and reduce your total cost of ownership. 

Enabling workloads in Intune

Enabling all management workloads from the cloud is the fastest way to reduce the complexity and cost of current technology and get closer to a single pane of glass. When making the transition from Microsoft Configuration Manager (ConfigMgr) to Intune, there are two types of cloud workloads you will enable. The first are management functions that you move from ConfigMgr to the cloud, such as updates, app deployment, and policy configuration. The second functions are net new capabilities only made possible by the cloud—such as automation, analytics, and generative AI related workloads.

Customers often ask me whether there is a logical order for moving workloads. Given the benefits, all workloads should be moved as soon as you are able, but moving them step-by-step can make sense to align with business goals. In general, you should start by enabling the net new cloud workloads discussed above, then move the existing workloads from ConfigMgr.  

For those existing workloads, a common approach is to start with compliance and security workloads, followed by policy. This helps with Zero Trust initiatives, and ensures you have strong security policies in place during the transition.

For example, Petrobras, the Brazilian energy company that moved to a cloud-native strategy with Intune, saw better policy enforcement for remote devices.

“Despite the increased access by our remote workforce, our recent audits have quite surprisingly revealed that we haven’t had any security incidents or data leakage.” —Alexandre Ribeiro Dantas, Information Security Manager at Petrobras

With security policies in place, we often see customers next move updates (patch) workloads to the cloud to take advantage of the Microsoft modern approach to updating devices on any network, anywhere in the world. National Australia Bank (NAB) is a great example of this. Their goal was to adopt a modern approach to patching.

“Windows 10 was the catalyst for retooling our environment and getting to where we are today, moving patch compliance from 60% to 97% across 45,000 endpoints.”—Andrew Zahradka, Head of Workplace Compute Technology at National Australia Bank

Apps are often the last workload migrated, as there is frequently an advantage to rationalizing application estates before migrating them. When migrating apps, we don’t recommend migrating all apps like-for-like from on-premises to the cloud. Instead, we recommend reviewing the apps and removing unused applications prior to migration. We have seen this result in organizations dropping from thousands of applications to hundreds that need to be migrated.   

Of course, in some instances, there may be one or two workloads that can’t immediately be moved to the cloud. Our recommendation here is not to let one or two laggard workloads stop you from gaining the rest of the benefits from moving to the cloud. Instead, try to manage all workloads natively in the cloud everywhere possible, and use ConfigMgr as a side car helper until you can modernize the laggard workloads.  

Enroll existing Windows devices in Intune 

The next step is to begin to enroll devices—enroll your clients managed by ConfigMgr into Intune and hybrid join them to Microsoft Entra ID (previously Azure Active Directory). 

This is a transitory step, not the end game. It takes time to transition to the cloud and modernize your directory and management solutions. By taking this first step of enrollment and hybrid Entra join, you receive the benefits of the cloud workloads and can transition away from dual management—such as existing devices receiving workloads from on-premise ConfigMgr, and new devices from the cloud.  For identity management, we recommend you hybrid join your existing devices with Entra ID while new devices are joined directly or natively with Entra ID. Hybrid join is the interim step, specifically for your existing Active Directory joined devices. It brings you the benefits of cloud without resetting and reprovisioning the device and disrupting the user. Hybrid devices will then age out of your environment as they are replaced with cloud-native, Entra join new devices through the natural lifecycle at refresh, or opportunistically if there’s an event, such as break-fix, that requires a device be reimaged. 

Microsoft has many partners with deep expertise in migrating Windows to the cloud who have seen success using this approach. They recently held a discussion on some of the lessons they’ve learned in cloud migrations, which I would encourage you to view. Peter Klapwijk, an Infrastructure Engineer, best sums up this stage.

“If a company has the Intune licenses, they should definitely start switching on co-management, to make use of the benefits [of which a single portal, remote actions, and endpoint analytics were mentioned]“—Peter Klapwijk, Infrastructure Engineer at NN Group

With new Windows deployments, go direct to cloud native

As you refresh or reset Windows devices, our recommendation is to manage them as fully cloud native. This represents an opportunity to reimagine what Windows management should look like in your organization. This greenfield approach sets a North Star for your organization’s transition and reduces the risk of recreating outdated legacy approaches in the cloud. 

This is especially true for Windows 11 devices. As the best version of Windows, it makes sense to use Windows 11 for any new devices, regardless of the provisioning method.

“Windows 11 Enterprise with Microsoft Intune has streamlined device provisioning, updates, security configurations, and troubleshooting processes. By centralizing these tasks, we’ve been able to achieve operational efficiencies, optimize resource allocation, and effectively manage our technology environment with a lean IT team.“—Blake T. Lunsford, Director of IT, Alabama Appellate Court System

Many customers opt to skip the co-management phase of migration completely, bringing new devices on as cloud native. These customers use their hardware refresh cycle as the catalyst to move to cloud native. Existing devices remain with on-premises management while new devices are deployed as fully cloud native. After a full hardware refresh cycle over 2-3 years, all Windows devices will eventually be managed exclusively in the cloud. For example, Cognizant empowers all its employees to implement new device setup remotely without any intervention from IT.

“Day one productivity was never the plan. This was a big project that was supposed to be completed over a two-year period. Yet, within a week, we started delivering a successful Autopilot Intune migration. From then on, we delivered laptops from our suppliers directly to employees at home.“—Ramesh Gopalakrishnan, Cognizant’s Director for Digital Workplace Services

Lastly, customers have asked whether they should delay their Windows 11 upgrades if they are not ready to move ahead with management modernization. The guidance here is clear: prioritize rolling out Windows 11 with the management tools and processes you already have in place today, such as ConfigMgr. Or if you have non-Windows 11 capable devices but would like to leverage Windows 11 features and capabilities, you can do so with Windows 365 Cloud PC, until new capable devices have been acquired.  

Next steps

We are excited to be seeing more and more companies move to a fully cloud native approach for endpoint management, so I hope if you’re not there already, this blog helps you identify the proper steps to get there. No matter where you are on the journey, we encourage you to learn more and get your plans set in 2024! Keep a look out for our third and final blog in this series, where I will focus on the process of implementation and communication with stakeholders.  

In the meantime, learn more about Microsoft Intune. 

To continue reading, see the final blog in this series:

• How to achieve cloud-native endpoint management with Microsoft Intune

The post Best practices in moving to cloud native endpoint management appeared first on Microsoft Security Blog.

From more secure and easy-to-use authentication with multifactor authentication to adding extra layers of protection for applications and data, we’ve simplified and enabled more security features by default than ever before with Windows 11. These features are designed to help stop attacks we’re seeing now as well the more sophisticated and targeted attacks that we expect to become more mainstream in the future. We have also begun to adopt memory-safe languages like Rust, starting with using Rust code for two traditional attack targets—Font Parsing and Win32k Kernel.

When we launched Windows 11 it came with new hardware and software features like secure boot, virtualization-based security, hypervisor-protected code integrity, and Windows Hello using the Trusted Platform Module (TPM) on by default in many regions. Since turning those features on, organizations have reported a 58 percent reduction in security incidents, and a three times reduction in firmware attacks—a highly attractive and lucrative target for attackers. Our data shows that 83 percent of Windows 11 devices use three or more security features. 

We’re excited to take the next step on this journey with updates for security and IT professionals available today and on by default for new installs of Windows 11.

New Windows 11 security features

Windows 11 features give you the power to create, collaborate, and keep your stuff protected.

Learn more

The next step towards eliminating passwords entirely

Microsoft global threat intelligence processes more than 65 trillion security signals every day. That intel has shown us there are more than 4,000 password attacks every second.² Everyday cybercriminals as well as nation-state attackers like Peach Sandstorm are leveraging password spray attacks to compromise high-value targets in sectors like satellite, defense, and pharmaceuticals. Organizations can reduce their risk of compromise to these kinds of attacks with Windows passwordless authentication and multifactor authentication features that offer more protection than traditional passwords.

Passkeys make passwordless easier and more universal: Windows 11 will make it much harder for hackers who exploit stolen passwords through phishing attacks by empowering users to replace passwords with passkeys. Passkeys are the cross-platform future of secure sign-in management. Microsoft and other technology leaders are promoting passkeys as part of the FIDO Alliance. A passkey creates a unique, unguessable cryptographic credential that is securely stored on your device. Instead of using a username and password to access a website or application, Windows 11 users will be able to use and protect passkeys using Windows Hello or Windows Hello for Business, or their phone. This will allow users to access the site or app using their face, fingerprint, or device PIN. Passkeys on Windows 11 will work on multiple browsers including Microsoft Edge, Google Chrome, Firefox, and others. Setting up a passkey in Windows is accomplished by:

• The website or application owner creates a passkey and offers it to you as a sign-in option instead of your password—website and app owners will need to develop their own passkeys infrastructure on their sign-in experience.
• Once you create the passkey on your device, the next time you sign in to that website or app from your device it will recognize that you have its passkey, and you can use it instead of a password. If you are using Windows Hello or Windows Hello for Business, you will be able to use your face, PIN, or fingerprint to sign in more easily. In addition, you can now use a passkey from your phone or tablet to complete the sign-in process.
• Users will have a management dashboard through Settings –> Accounts –> Passkeys to see and manage passkeys on their Windows 11 device.

Simplifying and modernizing security for IT by reducing the attack surface 

The latest Windows 11 will also include powerful new tools that enable IT teams to keep their organizations and employees more secure. We’re improving authentication, making it easier for IT to lock down and maintain policy configurations, adding more controls through Intune.

Phish-resistant credentials with Windows Hello for Business Passwordless: Windows 11 devices with Windows Hello for Business or FIDO2 security keys can protect user identities by removing the need to use passwords from day one. IT can now set a policy for Microsoft Entra ID-joined machines, so users no longer see the option to enter a password when accessing company resources. Once the policy is set, it will remove passwords from the Windows user experience, both for device unlock as well as in-session authentication scenarios. With this change, users can now navigate through their core authentication scenarios using strong, phish-resistant credentials like Windows Hello for Business or FIDO2 security keys. If ever necessary, users can leverage recovery mechanisms such as Windows Hello for Business PIN reset or web sign-in. Web sign-in is now available for all supported Microsoft Entra ID authentication mechanisms in addition to Temporary Access Pass (TAP) and education scenarios.

Maintain IT policy control with Config Refresh: Config Refresh is designed to revert policies to a secured state if they’ve been tampered with by potentially unwanted applications or user tampering with the registry. Config Refresh allows Windows 11 devices to be reset every 90 minutes by default, or every 30 minutes if desired, within the policy configuration service provider (CSP). This capability ensures that your settings are retained in the way IT configured them. The policy CSP covers hundreds of settings that were traditionally set with Group Policy and does so through Mobile Device Management, like Microsoft Intune. To enable help desk technicians to support their teams more efficiently Config Refresh can also be paused by IT administrators for a configurable period of time, after which it will be automatically re-enabled. It can also be turned back on at any time by an IT administrator. Starting today, Config Refresh is available to our Insiders and coming soon to all organizations.

Only allow trusted apps with Custom App Control: Applications are the lifeblood of our digital experiences, but they can also become entry points for attackers. With application control, only approved and trusted apps are allowed onto devices. By controlling unwanted or malicious code from running, application control is a critical part of an overall security strategy. Application control is often cited as one of the most effective means of defending against malware. Organizations using Windows 10 and above use App Control for Business (formerly called Windows Defender Application Control) and its next-generation capabilities to protect their digital estate from malicious code. Organizations using Microsoft Intune to manage their devices are now able to configure App Control for Business in the admin console, including setting up Intune as a managed installer.

New configurations in Windows Firewall: We are excited to announce some enhanced management and capabilities for the built-in Windows Firewall to help IT provide better overall protection. Windows Firewall now supports:

• Application Control for Business (previously known as Windows Defender Application Control) app ID tagging with Windows Firewall rules though Intune. This enables IT to target Windows Firewall rules to specific applications without an absolute file path. 
• The ability to configure network list manager settings to determine when a Microsoft Entra ID (previously known as Azure Active Directory) device is on your on-premises domain subnets so firewall rules can properly apply. The network list manager settings for Windows Firewall can be used for location awareness. 
• There is now better support in settings to configure more granular Windows Firewall logging for domain, private, and public firewall profiles, as well as the ability to specify Windows Firewall inbound and outbound rules for ICMP types and codes.

Our continued investment in security and innovation

Our MORSE team, Microsoft Offensive Research and Security Engineering, has been working hard to ensure security is a critical piece of the software development lifecycle. In the last year, the team has dedicated 1.9 million virtual machine hours and more than 84,000 Azure CPU cores dedicated to proactively fuzzing code. In addition to that, we’ve made nearly 700 improvements in our code just the last few months by strengthening the software development lifecycle with security checks and balances, including new automation and AI to help developers find bugs on their own. The proactive work of this team to continue to improve the integrity of our code both old and new is part of our commitment to ongoing investment and innovation in security. The team has released learnings and tools to the community as well like our open source fuzzing tool, Microsoft OneFuzz.

We’re looking forward to continuing this journey to make Windows more secure from the chip to the cloud with every update.

Learn more

Learn more about Windows 11 security features.

Download our Windows security book.

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

¹New security features for Windows 11 will help protect hybrid work, David Weston. April 5, 2022.

²Microsoft Entra expands into Security Service Edge and Azure AD becomes Microsoft Entra ID, Joy Chik. July 11, 2023.

³Microsoft internal data.

The post New security features in Windows 11 protect users and empower IT appeared first on Microsoft Security Blog.