{ "id": "677f4fe6-9710-4de1-96d7-d235052a84db", "created_at": "2026-04-06T01:31:30.149476Z", "updated_at": "2026-04-10T03:24:29.810482Z", "deleted_at": null, "sha1_hash": "8ab0463b8966e2e4b85c2b8e17a42c0b6d4f7327", "title": "CyberArk Labs: From Safe Mode to Domain Compromise", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2339704, "plain_text": "CyberArk Labs: From Safe Mode to Domain Compromise\r\nBy Doron Naim\r\nPublished: 2016-09-15 · Archived: 2026-04-06 01:10:38 UTC\r\nOverview\r\nCyberArk Labs recently identified what it believes to be a significant risk related to Windows Safe Mode, which is\r\nbuilt into all Windows Operating Systems (OS) on both PCs and servers. Once attackers break through the\r\nperimeter and gain local administrator privileges on an infected Windows-based machine, they can remotely\r\nactivate Safe Mode to bypass and manipulate endpoint security measures. In Safe Mode, the attackers are able to\r\nfreely run tools to harvest credentials and laterally move to connected systems – all while remaining undetected.\r\nThis exploit can also work in Windows 10, despite the presence of the Microsoft’s Virtual Secure Module (VSM).\r\nBy exploiting these weaknesses, attackers can turn infected endpoints into launching points for pass-the-hash\r\nattacks, which can provide attackers with access to more machines on which they can re-use these same attack\r\ntechniques to ultimately compromise the entire Windows environment.\r\nhttps://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise\r\nPage 1 of 5\n\nIntroduction\r\nSafe Mode is a long-standing, basic function of the Windows OS that was designed to provide a lean environment\r\nin which users can examine and resolve issues that cannot be resolved in Normal Mode. Safe Mode was first\r\nreleased in 1995 when “security” and “cyber” were still terms of science fiction. Back then, vendors were focused\r\non system stability, efficiency and business operations – meaning security was usually neglected. Yet, as the\r\nInternet has become ubiquitous, such technologies have become tools of opportunity for cyber attackers.\r\nBecause Safe Mode was purposely designed to be lean, it restricts most third-party software, including security\r\ntools, from running. As a result, cyber attackers on compromised machines can remotely reboot those machines\r\ninto Safe Mode to disable and evade endpoint defenses and subsequently launch their attacks. Given the number\r\nof Windows systems in use, this risk impacts billions of PCs and servers globally.\r\nThis blog will outline the privileged attack pathway that starts with Safe Mode, address how Safe Mode can be\r\nused to manipulate endpoint security measures, and suggest steps your organization should take right now to\r\nmitigate this risk.\r\nDescription of Risk\r\nIt’s fairly easy for attackers to break through the perimeter and gain access to at least one machine on a corporate\r\nnetwork. In fact, in a recent report by FireEye, 84 percent of organizations surveyed admitted to falling victim to\r\nat least one spear-phishing attack in 2015 (1). Once the attacker has access to a machine, the attacker will attempt\r\nto gain local administrator rights either by leveraging the user’s existing privileges or by using an exploit to\r\nelevate to these privileges.\r\nOnce attackers have remote, local administrator access to infected machines, they need to evade a variety of\r\nendpoint security measures such as anti-virus and endpoint threat detection tools. Next, to maximize their success,\r\nattackers typically scour endpoints looking for credentials that can be reused to laterally move throughout the\r\nnetwork. With this in mind, several tools, including Microsoft’s recently released Virtual Secure Module (VSM),\r\nhave been created to operate at the endpoint level to limit the use of attack tools and protect credentials from pass-the-hash attacks. These tools can be highly effective, but the catch is, they are typically designed to operate only in\r\nNormal Mode.\r\nEnter, Safe Mode. Safe Mode, by design, does not boot any software or drivers that are not critical to the\r\noperation of Windows. As a result, by remotely forcing a reboot in Safe Mode, attackers inside a compromised\r\nsystem are able to operate freely, as most endpoint defenses are not enabled. And because VSM is only enabled in\r\nNormal Mode, attackers can also capture credential hashes needed to laterally move through the environment –\r\ndespite Microsoft’s claims that pass-the-hash risks have been mitigated (2).\r\nExploiting Safe Mode to Escalate an Attack\r\nThis example explains how Safe Mode can be exploited to allow an attacker to capture user credentials and\r\nexecute pass-the-hash attacks to achieve lateral movement. This pattern of credential capture and lateral\r\nmovement can be reused by an attacker multiple times until an eventual domain compromise in achieved.\r\nTo successfully exploit this weakness in Safe Mode, attackers must complete three steps:\r\nhttps://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise\r\nPage 2 of 5\n\n1. Change system settings to move the OS into Safe Mode during the next reboot\r\n2. Configure attack tools to load in Safe Mode\r\n3. Force the reboot of the machine to begin the exploit\r\nThis process is actually much easier than it sounds, and it can typically be done without the user noticing that\r\nanything has gone wrong. The steps below show just how simple this entire process can be.\r\nStep 1: Remotely configure a machine to boot in Safe Mode\r\nTo remotely force a Windows-based machine into Safe Mode during the next reboot, attackers can use BCDEdit to\r\nconfigure the system to boot in Minimal Safe Mode. Once this change is made, the machine will – by default –\r\nboot in Minimal Safe Mode, which is the default Safe Mode boot option that runs only the minimal drivers and\r\nservices needed to start Windows and prevents connections to the Internet and network.\r\nStep 2: Configure attack tools to load in Safe Mode\r\n Remember that, by design, Safe Mode loads only a minimal set of drivers and tools. To gain a presence in Safe\r\nMode, the attacker must somehow enable his or her attack tools to run in this lean state. This can be done in a few\r\nways, two of which include:\r\nMalicious Service. Attackers can create a malicious service that is configured to load in Safe Mode. The\r\nservice can be included in the attacker’s initial payload.\r\nMalicious COM Object. Attackers can register a malicious COM object that is loaded by explorer.exe.\r\nThis enables that attacker’s code to run each time the explorer.exe needs to parse icons. (Yes, surprisingly\r\nthis works in Safe Mode, as well.)\r\nWith these tools in place, the attacker’s malicious code will automatically run during the next reboot.\r\nSince most endpoint security solutions are not effective in Minimal Safe Mode, these attack tools can easily evade\r\nendpoint security measures. In this state, the attacker is able to freely use his or her tools to steal credentials from\r\nLSASS.exe and then reuse those credentials to continue the attack path of lateral movement and privilege\r\nescalation.\r\nStep 3: Restart the machine to execute the next phase of the attack\r\nThis can easily be done in a variety of ways, including directly from the command line in Normal Mode.\r\nBut wait! How does the attacker do this without the victim noticing?  Sure, the attacker can arbitrarily force a\r\nrestart, but this will likely look suspicious to the user and prompt a phone call to the IT team. Instead, to stay\r\nunder the radar, the attacker can also either wait until the next restart or show the victim an “update” window with\r\na message that says the PC must be rebooted. This “update” window can purposely be designed to look like a\r\nlegitimate Windows pop-up.\r\nNext, depending on the attacker’s goal, there are a few techniques an attacker can use to continue to stay hidden\r\nfrom the victim. Let’s look at the techniques based on the attacker’s goal:\r\nhttps://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise\r\nPage 3 of 5\n\nCredential Theft. If the attacker’s goal is to steal credentials for future use, then the attacker actually\r\nwants the user to log on to the system. As the user logs in, the attacker can capture the credentials. In this\r\ncase, the attacker will likely use the COM object technique to execute code that will change the\r\nbackground, look and feel of Safe Mode – making it appear that the user is still in Normal Mode. As soon\r\nas the user enters his or her credentials, a second “update” window can prompt the user to reboot yet again\r\nto move the machine back into the actual Normal Mode. Just as mentioned above, this secondary reboot\r\nprompt can mimic a legitimate Windows prompt to prevent the user from noticing anything suspicious.\r\nLateral Movement. If the attacker’s goal is to perform a pass-the-hash attack using previously\r\ncompromised credentials, then the attacker does not need the user to login. In this case, the attacker is\r\nbetter off creating a service. At the time of reboot, the service can automatically run code to execute a pass-the-hash attack and then immediately reboot the machine again back into Normal Mode. These back-to-back restarts are indistinguishable to the user, and thus further prevent the user from noticing that\r\nsomething went wrong. Based on tests conducted by CyberArk Labs, we found this technique to be highly\r\neffective in stealthily enabling lateral movement.\r\nWhat about Event Log? Someone can definitely see that a PC went to Safe Mode. That is correct, but at this\r\npoint I’ll encourage you read to research by my colleague, Roi Cohen, “Can Incident Response and Audit Teams\r\nAlways Trust Windows Security Event Logs?”\r\nExploiting Safe Mode to Manipulate Security Measures\r\nThe next example will show how attackers can not only avoid endpoint security defenses in Safe Mode but also\r\nmanipulate these solutions within Safe Mode. This example was tested against McAfee LiveSafe, Avira Free\r\nAntivirus, Trend Micro Maximum Security 10 and Windows Defender.\r\nAll of these solutions run in Normal Mode and some can run in Network Safe Mode, which is a Safe Mode boot\r\noption that boots the minimal drivers and services need to start Windows, as well as the drivers and services\r\nneeded connect to the Internet and network. However, none of these solutions runs in Minimal Safe Mode. As\r\nsuch, registry keys associated with these solutions cannot be modified in Normal Mode or Network Safe Mode,\r\nbut they can be modified in Minimal Safe Mode.\r\nOnce an attacker has booted a machine into Minimal Safe Mode, the attacker can access registry keys and alter\r\nconfigurations to disable or manipulate endpoint security solutions. Once that’s complete, an attacker can reboot\r\nthe machine back into Normal Mode and freely proceed with the attack without the risk of being blocked by an\r\nendpoint security solution.\r\nWhen testing this in our lab, we attempted to use Mimikatz in Normal Mode to steal credentials from memory.\r\nWhen endpoint security solutions were properly configured, Mimikatz was removed each time we attempted to\r\nuse it – including when we attempted to copy it to the disk. After we modified the registry keys in Minimal Safe\r\nMode, we were able to seamlessly run Mimikatz, write the tool to the disk, and successfully capture credentials\r\nwithout setting off any alarms.\r\nMitigation\r\nhttps://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise\r\nPage 4 of 5\n\nThough this risk is built in to all Windows OSes, there are a few proactive steps organizations can take to mitigate\r\nthis risk. Recommendations include the following:\r\nEnforce the principle of least privilege. The ability to remotely load a machine into Safe Mode from\r\nNormal Mode is only present when an attacker is able to operate with local administrator privileges. By\r\nremoving local administrator privileges from standard users, organizations can reduce their exposure to this\r\ntype of exploit.\r\nRotate privileged account credentials. To successfully execute a pass-the-hash attack, the compromised\r\ncredential hash must still be valid. By proactively rotating privileged account credentials, organizations can\r\nfrequently and automatically invalidate password hashes that may exist on machines throughout the\r\nenvironment. As a result, attackers can still capture the password hashes from compromised machines, but\r\nthe hashes will be useless.\r\nEmploy security tools that operate in Safe Mode. Security tools that only function properly in Normal\r\nMode can leave organizations exposed to this type of attack. When evaluating endpoint security tools,\r\nensure that the solution you select is able to function in Safe Mode.\r\nMonitor the use of Safe Mode. This can be done both proactively and after the fact. Set alerts to know\r\nwhen a machine boots in Safe Mode, and monitor the Windows Event Log to search for this type of event.\r\nNote, however, that recent research indicates that the Windows Event Log may not be entirely trusted.\r\n Disclosure Timeline\r\nFebruary 24, 2016: Initial discovery by CyberArk Labs\r\nMay 2, 2016: Risk reported to Microsoft Security Response Center\r\nMay 2, 2016: Microsoft responded that they did not consider the submission a valid vulnerability as it\r\nrequires an attacker to have already compromised the machine.*\r\nSeptember 15, 2016: Public disclosure\r\n *According to Microsoft’s “Ten Immutable Laws of Security”\r\n1 https://www2.fireeye.com/rs/fireye/images/fireeye-how-stop-spearphishing.pdf\r\n2 https://www.blackhat.com/docs/us-15/materials/us-15-Moore-Defeating%20Pass-the-Hash-Separation-Of-Powers.pdf\r\nSource: https://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise\r\nhttps://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.cyberark.com/resources/blog/cyberark-labs-from-safe-mode-to-domain-compromise" ], "report_names": [ "cyberark-labs-from-safe-mode-to-domain-compromise" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439090, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8ab0463b8966e2e4b85c2b8e17a42c0b6d4f7327.pdf", "text": "https://archive.orkl.eu/8ab0463b8966e2e4b85c2b8e17a42c0b6d4f7327.txt", "img": "https://archive.orkl.eu/8ab0463b8966e2e4b85c2b8e17a42c0b6d4f7327.jpg" } }