As we head into our annual partner conference, Microsoft Inspire, I’m excited to make a major announcement! The Microsoft Virus Initiative (MVI) is formally joining the Microsoft Intelligent Security Association (MISA).
For more than 20 years, Microsoft and our antimalware partners have collaborated through MVI to help develop integrated and compatible solutions for Windows. MISA was created as an ecosystem of independent software vendors that have integrated their security solutions to help defend against a world of increasing threats. Our mission is to provide better security for our shared customers by integrating across the security ecosystem to gain more signals, increase visibility, and better protect against threats. That’s why we’re thrilled to welcome members of MVI!
Stopping malware at scale with the power of the cloud
Antivirus and antimalware products have long been the backbone of security solutions. As modern security products evolve, more antimalware providers are taking advantage of the power of the cloud, transforming how we protect, detect, and respond to threats at scale. Antimalware products play a key role in achieving our shared vision of collaboration that reduces security complexity and delivers better protection to customers.
By joining MISA, Microsoft’s antimalware partners will help break down silos and help customers realize the benefit of using solutions from multiple vendors in harmony. This is done by connecting the security ecosystem to gain more signal, increase visibility, and protect against threats.
At the annual MVI Partner Forum in Redmond, Washington, Microsoft reiterated that we’re investing heavily in both security and partnerships throughout the upcoming fiscal year. This includes expanding the size of the association and adding additional member benefits.
As a security provider to 95 percent of the Fortune 500, our customers are diverse and have different needs and configurations. In 2018, we created MISA to build an ecosystem of intelligent security solutions that better defend against a world of increased threats by sharing security signals across the Microsoft security stack. Since its launch, the organization has more than doubled, and we now have 59 members. Most recently, as part of Microsoft’s participation in the FIDO2 alliance, we welcomed new FIDO key partners Feitian and HID Global. You can read more about these partnerships in this recent blog.
The prevailing perception about fileless threats, among the security industry’s biggest areas of concern today, is that security solutions are helpless against these supposedly invincible threats. Because fileless attacks run the payload directly in memory or leverage legitimate system tools to run malicious code without having to drop executable files on the disk, they present challenges to traditional file-based solutions.
But let’s set the record straight: being fileless doesn’t mean being invisible; it certainly doesn’t mean being undetectable. There’s no such thing as the perfect cybercrime: even fileless malware leaves a long trail of evidence that advanced detection technologies in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) can detect and stop.
I recently unearthed a widespread fileless campaign called Astaroth that completely “lived off the land”: it only ran system tools throughout a complex attack chain. The attack involved multiple steps that use various fileless techniques and proved a great real-world benchmark for Microsoft Defender ATP’s capabilities against fileless threats.
In this blog, I will share my analysis of a fileless attack chain that demonstrates:
Attackers would go to great lengths to avoid detection
Exposing a fileless info-stealing campaign with Microsoft Defender ATP next-generation protection
I was doing a standard review of Windows Defender Antivirus telemetry when I noticed an anomaly from a detection algorithm designed to catch a specific fileless technique. Telemetry showed a sharp increase in the use of the Windows Management Instrumentation Command-line (WMIC) tool to run a script (a technique that MITRE refers to XSL Script Processing), indicating a fileless attack.
Figure 1. Windows Defender Antivirus telemetry shows a sudden increase in suspicious activity
After some hunting, I discovered the campaign that aimed to run the Astaroth backdoor directly in memory. Astaroth is a notorious info-stealing malware known for stealing sensitive information like credentials, keystrokes, and other data, which it exfiltrates and sends to a remote attacker. The attacker can then use stolen data to try moving laterally across networks, carry out financial theft, or sell victim information in the cybercriminal underground.
All the payloads are Base64-encoded and decoded using the Certutil tool. Two of them result in plain DLL files (the others remain encrypted). The Regsvr32 tool is then used to load one of the decoded DLLs, which in turn decrypts and loads other files until the final payload, Astaroth, is injected into the Userinit process.
It’s interesting to note that at no point during the attack chain is any file run that’s not a system tool. This technique is called living off the land: using legitimate tools that are already present on the target system to masquerade as regular activity.
The attack chain above shows only the Initial Access and Execution stages. In these stages, the attackers used fileless techniques to attempt to silently install the malware on target devices. Astaroth is a notorious information stealer with many other post-breach capabilities that are not discussed in this blog. Preventing the attack in these stages is critical.
These protection technologies stop threats at first sight, use the power of the cloud, and leverage Microsoft’s industry-leading optics to deliver effective protection. This defense-in-depth is observed in the way these technologies uncovered and blocked the attack at multiple points in Astaroth’s complex attack chain.
Figure 3. Microsoft Defender ATP solutions for fileless techniques used by Astaroth
For traditional, file-centric antivirus solutions, the only window of opportunity to detect this attack may be when the two DLLs are decoded after being downloaded—after all, every executable used in the attack is non-malicious. If this were the case, this attack would pose a serious problem: since the DLLs use code obfuscation and are likely to change very rapidly between campaigns, focusing on these DLLs would be a vicious trap.
However, as mentioned, next generation protection capabilities in Microsoft Defender ATP catch fileless techniques. Let’s break down the attack steps, enumerate the techniques used using MITRE technique ID as reference, and map the relevant Microsoft Defender ATP protection.
Step 1: Arrival
The victim receives an email with a malicious URL:
The URL uses misleading names like certidao.htm (Portuguese for “certificate”), abrir_documento.htm (“open document”), pedido.htm (“order”), etc.
When clicked, the malicious link redirects the victim to the ZIP archive certidao.htm.zip, which contains a similarly misleading named LNK file certidao.htm.lnk. When clicked, the LNK file runs an obfuscated BAT command-line.
Microsoft Defender ATP next-gen protection defenses:
Command-line scanning: Trojan:Win32/BadEcho.A
Heuristics engine: Trojan:Win32/Linkommer.A
Windows Defender SmartScreen
Step 2: WMIC abuse, part 1
The BAT command runs the system tool WMIC.exe:
One of the decoded payload files (a DLL) is run within the contexct of the Regsvr32 system tool:
The file falxconxrenw64.~ is a proxy: it loads and runs a second DLL, falxconxrenw98.~, and passes it to a third DLL that is obtained by reading files falxconxrenwxa.~ and falxconxrenwxb.~. The DLL falxconxrenw98.~ then reflectively loads the third DLL.
Attack surface reduction: An attack surface reduction rule detects the loading of a DLL that does not meet the age and prevalence criteria (i.e., a new unknown DLL)
Step 7: Userinit abuse
The newly loaded DLL reads and decrypts the file falxconxrenwgx.gif into a DLL. It runs the system tool userinit.exe into which it injects the decrypted DLL. The file falxconxrenwgx.gif is again a proxy that reads, decrypts, and reflectively loads the DLL falxconxrenwg.gif. This last DLL is the malicious info stealer known as Astaroth.
Attack surface reduction: An attack surface reduction rule detects the loading of a DLL that does not meet the age and prevalence criteria (i.e., a new unknown DLL)
Comprehensive protection against fileless attacks with Microsoft Threat Protection
The strength of next-generation protection engines in exposing fileless techniques add to the capabilities of the unified endpoint protection platform, Microsoft Defender ATP. Activities related to fileless techniques are reported in Microsoft Defender Security Center as alerts, so security operations teams can further investigate and respond to attacks using endpoint detection and response, advanced hunting, and other capabilities in Microsoft Defender ATP.
Figure 4. Details of Windows Defender Antivirus detections of fileless techniques and malware reported in Microsoft Defender Security Center; details also indicate whether threat is remediated, as was the case with the Astaroth attack
The rest of Microsoft Defender ATP’s capabilities beyond next-generation protection enable security operations teams to detect and remediate fileless threats and other attacks. Notably, Microsoft Defender ATP endpoint detection and response (EDR) has strong and durable detections for fileless and living-off-the-land techniques across the entire attack chain.
Figure 5. Alerts in Microsoft Defender Security Center showing detection of fileless techniques by antivirus and EDR capabilities
We also published a threat analytics report on living-off-the-land binaries to help security operations assess organizational security posture and resilience against these threats. New Microsoft Defender ATP services like threat and vulnerability management and Microsoft Threat Experts (managed threat hunting), further assist organizations in defending against fileless threats.
Through signal-sharing and orchestration of threat remediation across Microsoft’s security technologies, these protections are further amplified in Microsoft Threat Protection, Microsoft’s comprehensive security solution for the modern workplace. For this Astaroth campaign, Office 365 Advanced Threat Protection (Office 365 ATP) detects the emails with malicious links that start the infection chain.
To come back to one of my original points in this blog post, being fileless doesn’t mean being invisible; it certainly doesn’t mean being undetectable.
An analogy: Pretend you are transported to the world of H.G. Wells’ The Invisible Man and can render yourself invisible. You think, great, you can walk straight into a bank and steal money. However, you soon realize that things are not as simple as they sound. When you walk out in the open and it’s cold, your breath’s condensation gives away your position; depending on the type of the ground, you can leave visible footmarks; if it’s raining, water splashing on you creates a visible outline. If you manage to get inside the bank, you still make noise that security guards can hear. Motion detection sensors can feel your presence, and infrared cameras can still see your body heat. Even if you can open a safe or a vault, these storage devices may trigger an alert, or someone may simply notice the safe opening. Not to mention that if you somehow manage to grab the money and put them in a bag, people are likely to notice a bag that’s walking itself out of the bank.
Being invisible may help you for some things, but you should not be under the illusion that you are invincible. The same applies to fileless malware: abusing fileless techniques does not put malware beyond the reach or visibility of security software. On the contrary, some of the fileless techniques may be so unusual and anomalous that they draw immediate attention to the malware, in the same way that a bag of money moving by itself would.
Using invisible techniques and being actually invisible are two different things. Using advanced technologies, Microsoft Defender ATP exposes fileless threats like Astaroth before these attacks can cause more damage.
I’m excited to announce that Microsoft’s Threat & Vulnerability Management solution is generally available as of June 30! We have been working closely with customers for more than a year to incorporate their real needs and feedback to better address vulnerability management. Our goal is to empower defenders with the tools they need to better protect against evolving threats, and we believe this solution will help provide that additional visibility and agility they need.
Threat & Vulnerability Management (TVM) is a built-in capability in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) that uses a risk-based approach to discover, prioritize, and remediate endpoint vulnerabilities and misconfigurations. With Microsoft Defender ATP’s Threat & Vulnerability Management, customers benefit from:
Continuous discovery of vulnerabilities and misconfigurations
Prioritization based on business context and dynamic threat landscape
Correlation of vulnerabilities with endpoint detection and response (EDR) alerts to expose breach insights
Machine-level vulnerability context during incident investigations
Built-in remediation processes through unique integration with Microsoft Intune and Microsoft System Center Configuration Manager
Traditional vulnerability scanning only happens periodically, leaving organizations with security blind spots between scans. The one-size-fits-all approach that these traditional solutions use ignores critical business-specific context, as well as the dynamic threat landscape. This is coupled with the fact that mitigation of vulnerabilities is a manual process, often across teams, that can take days, weeks, or months to complete. This leaves a window of opportunity for attackers and puts our defenders in a tough spot.
To address these challenges Microsoft partnered with a dozen enterprise customers on the design and creation of this new Threat & Vulnerability Management solution. One of them is Telit, a global leader in IoT enablement offering end-to-end IoT solutions, including enterprise-grade hardware, connectivity, platform, and consulting services. Telit already had a well-defined vulnerability management program in place, but said they were missing several critical capabilities, including visibility, prioritization, and remediation.
Our design partners play a key role throughout the entire process, from planning and building to operationalizing and maturing the product so we can deliver the best experience. Many of our customers have existing vulnerability management programs, so we knew that to have them switch to Microsoft we would need a disruptive approach to vulnerability management. From private preview to general availability and beyond, our key goals were to bridge the gap between Security and IT roles in threat protection, to reduce time to threat resolution while enabling real-time prioritization and risk reduction based on the evolving threat landscape and business context. The team continues to incorporate feedback from customers and partners, adding these new capabilities on a monthly basis.
“Telit’s previous threat and vulnerability solutions were limited to on-premises connected endpoints. Moving to Microsoft’s TVM cloud-based solution provides us much better visibility into roaming endpoints with a continuous assessment, especially when our endpoints are connected to untrusted networks.”
— Itzik Menashe, VP of IT & Information Security, Telit
Working together with Telit, we quickly understood that the current prioritization norm is not enough to properly reduce risk in an organization. We consulted with our partners on a new risk-based approach, which is focused on continuous discovery of vulnerabilities and misconfigurations and correlated those insights with context specific to their business and the dynamic threat landscape.
Microsoft’s built-in, end-to-end remediation process helps Telit bridge the gap between their security and operations teams. The unique integration with Microsoft Intune allows their security team to create remediation requests with a click of a button, and the operations team receives the requests automatically with all relevant information and can start the remediation process right away. The security team can then watch their exposure score drop in real time as remediation progresses.
“Microsoft’s TVM provides Telit with an easy-to-use solution that incorporates strong discovery capabilities, a risk-based approach to prioritization, and an effective remediation process. With this solution we are able to cover a large number of endpoints using a very small team of security engineers.”
— Mor Asher, Global IT and Information Security Manager, Telit
The product experience and ease of implementation was a big driver for Telit and thousands of other active customers to start using Microsoft Defender ATP Threat & Vulnerability Management. Telit had Microsoft Defender ATP’s TVM up and running within seconds.
To learn more about threat and vulnerability management watch our video that walks you through the experience.
If you already have Microsoft Defender ATP, the TVM solution is now available within your ATP portal. If you would like to sign up for a trial of Microsoft Defender ATP including TVM, sign up here.
We’re excited for our customers to evaluate this new solution and are looking forward to continued feedback.
With the Windows 10 May 2019 Update we delivered several important features for Windows Defender Application Control (WDAC), which was originally introduced to Windows as part of a scenario called Device Guard. WDAC works in conjunction with features like Windows Defender Application Guard, which provides hardware-based isolation of Microsoft Edge for enterprise-defined untrusted sites, to strengthen the security posture of Windows 10 systems.
Our focus for this release was responding to some longstanding feedback on manageability improvements. We’re excited to introduce the following new capabilities in Windows Defender Application Control:
File path rules, including optional runtime admin protection checks
Multiple policy file support with composability
Application Control CSP to provide a new, richer MDM policy management capability
COM object registration support in policy
Disabling script enforcement rule option
Application control is frequently identified as one of the most effective mitigations against modern security threats, because anything that’s not allowed by policy is blocked from running. Even striving towards a simple policy like mandating that only signed code is allowed to execute can be incredibly impactful: in a recent analysis of Windows Defender ATP data, we saw that 96% of malware encountered is unsigned. Systems like Windows 10 in S mode, which uses WDAC technology to enforce that all code must be signed by Windows and Microsoft Store code signing certificates, have no malware infection issues.
The new capabilities are designed to ease the journey for customers adopting application control in real-world environments with large numbers of applications, users, and devices.
File path rules, including optional runtime admin protection checks
For many customers looking to adopt application execution control while balancing IT overhead, rules based on file paths on managed client systems provide a useful model. The Windows 10 May 2019 Update introduces support for both allow and deny rules based on file path in Windows Defender Application Control.
File path rules had been one of the few features available in AppLocker, the older native application control technology, that were not available to WDAC; deployment tools and methodologies built on top of AppLocker like AaronLocker have relied on these rules as an important simplifying option for policy management. As we sought to close that gap, we wanted to preserve the stronger security posture available with WDAC that customers have come to expect. To this end, WDAC applies, by default, an option to check at runtime that apps and executables allowed based on file path rules must come from a file path that’s only writable by administrator or higher privileged accounts. This runtime check provides an additional safeguard for file path rules that are otherwise inherently weaker than other identifiers like hash or signer rules, which rely on cryptographically verifiable attributes.
This runtime capability can be controlled with the “Disabled:Runtime FilePath Rule Protection” rule option.
The following example shows how to easily create rules for anything allowed under “Program Files” and “Program Files (x86)”, and then merge them with the sample policy that allows all Windows signed code (available under C:\Windows\schemas\CodeIntegrity\ExamplePolicies). The resulting merged policy file allows all Windows signed code and applications installed under “Program Files” and “Program Files (x86)” with the runtime protection that checks that anything executing under those paths is coming from a location only writable by administrator or higher privileged accounts.
Multiple policy file support with composability
Limiting support to a single policy file means that a variety of app control scenarios from potentially different stakeholders or business groups need to be maintained in one place. This comes with an associated overhead: the coordination required to converge on the appropriate rules encapsulated in a single policy file.
With the Windows 10 May 2019 Update multiple policy files are supported for WDAC. To facilitate composing behavior from multiple policy files, we have introduced the concept of base and supplemental policies:
Base policies – For any execution to be allowed, the application must pass each base policy independently. Base policies are used together to further restrict what’s allowed. For example:
Let’s assume a system has two policies: Base Policy A and Base Policy B with their own sets of rules. For foo.exe to run, it must be allowed by the rules in Base Policy A and also the rules in Base Policy B. Windows Defender Application Control policies on prior Windows 10 systems will continue to work on the May 2019 Update and will be treated as base policies.
Supplemental policies – As the name suggests, supplemental policies complement base policies with additional rules to be considered as part of the base policies they correspond to. Supplemental policies are tied to a specific base policy with an ID; a base policy may have multiple supplemental policies. Supplemental policies expand what is allowed by any base policy, but deny rules specified in a supplemental policy will not be honored.
Application Control CSP
Customers have been able to deploy Windows Defender Application Control policies via MDM using the CodeIntegrity node of the AppLocker configuration service provider (CSP). The AppLocker CSP has a number of limitations, most notably the lack of awareness of rebootless policy deployment support.
The Windows 10 May 2019 Update now has a new Application Control CSP, which introduces much richer support for policy deployment over MDM and also provides support for:
Rebootless policy deployment (For policies that have the “Enabled:Update Policy No Reboot” option set, the new Application Control CSP will not schedule a reboot on client systems getting the policy)
Support for the new multiple policies
For device management software vendors, better error reporting
COM object registration support
Windows Defender Application Control enforces a built-in allow list of COM object registrations to reduce the risk introduced from certain powerful COM objects. Customers have reported that while this capability is desirable from a security perspective, there are specific cases in their environments where they’d like to allow the registration of additional COM objects required for their business.
With the Windows 10 May 2019 Update customers can now specify COM objects that need to be allowed in environments they’re managing with Windows Defender Application Control policies.
Disabled: Script Enforcement rule option support
The Windows 10 May 2019 Update with KB4497935 introduces proper support for the Disabled: Script Enforcement rule option.
Customers recognize the importance of having restrictions on script hosts but are often looking to break up their application control projects into smaller chunks to help with deployment feasibility. The “Disabled:Script Enforcement” rule option in the policy now turns off policy enforcement for MSIs, PowerShell scripts, and wsh-hosted scripts. This will allow IT departments to tackle EXE, DLL, and driver enforcement without needing to also simultaneously address script host control.
We’re also working on supplementing the documentation we have out now. Stay tuned for updates from our team for tools and guidance on GitHub that provide more practical examples and ready-to-use scripts.
Nazmus Sakib Senior Program Manager, Windows Defender Application Control team
Windows Defender Antivirus is the next-generation protection component of Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP), Microsoft’s unified endpoint security platform. Much like how Microsoft Defender ATP integrates multiple capabilities to address the complex security challenges in modern enterprises, Windows Defender Antivirus uses multiple engines to detect and stop a wide range of threats and attacker techniques at multiple points.
These next-generation protection engines provide industry-best detection and blocking capabilities. Many of these engines are built into the client and provide advanced protection against majority of threats in real-time. When the client encounters unknown threats, it sends metadata or the file itself to the cloud protection service, where more advanced protections examine new threats on the fly and integrate signals from multiple sources.
These next-generation protection engines ensure that protection is:
Accurate: Threats both common and sophisticated, a lot of which are designed to try and slip through protections, are detected and blocked
Real-time: Threats are prevented from getting on to devices, stopped in real-time at first sight, or detected and remediated in the least possible time (typically within a few milliseconds)
Intelligent: Through the power of the cloud, machine learning (ML), and Microsoft’s industry-leading optics, protection is enriched and made even more effective against new and unknown threats
Here’s a rundown of the many components of the next generation protection capabilities in Microsoft Defender ATP:
In the cloud:
Metadata-based ML engine – Specialized ML models, which include file type-specific models, feature-specific models, and adversary-hardened monotonic models, analyze a featurized description of suspicious files sent by the client. Stacked ensemble classifiers combine results from these models to make a real-time verdict to allow or block files pre-execution.
Behavior-based ML engine – Suspicious behavior sequences and advanced attack techniques are monitored on the client as triggers to analyze the process tree behavior using real-time cloud ML models. Monitored attack techniques span the attack chain, from exploits, elevation, and persistence all the way through to lateral movement and exfiltration.
File classification ML engine – Multi-class, deep neural network classifiers examine full file contents, provides an additional layer of defense against attacks that require additional analysis. Suspicious files are held from running and submitted to the cloud protection service for classification. Within seconds, full-content deep learning models produce a classification and reply to the client to allow or block the file.
Detonation-based ML engine – Suspicious files are detonated in a sandbox. Deep learning classifiers analyze the observed behaviors to block attacks.
Reputation ML engine – Domain-expert reputation sources and models from across Microsoft are queried to block threats that are linked to malicious or suspicious URLs, domains, emails, and files. Sources include Windows Defender SmartScreen for URL reputation models and Office 365 ATP for email attachment expert knowledge, among other Microsoft services through the Microsoft Intelligent Security Graph.
Smart rules engine – Expert-written smart rules identify threats based on researcher expertise and collective knowledge of threats.
On the client:
Behavior monitoring engine – The behavior monitoring engine monitors for potential attacks post-execution. It observes process behaviors, including behavior sequence at runtime, to identify and block certain types of activities based on predetermined rules.
Memory scanning engine – This engine scans the memory space used by a running process to expose malicious behavior that may be hiding through code obfuscation.
AMSI integration engine – Deep in-app integration engine enables detection of fileless and in-memory attacks through Antimalware Scan Interface (AMSI), defeating code obfuscation. This integration blocks malicious behavior of scripts client-side.
Heuristics engine – Heuristic rules identify file characteristics that have similarities with known malicious characteristics to catch new threats or modified versions of known threats.
Emulation engine – The emulation engine dynamically unpacks malware and examines how they would behave at runtime. The dynamic emulation of the content and scanning both the behavior during emulation and the memory content at the end of emulation defeat malware packers and expose the behavior of polymorphic malware.
Network engine – Network activities are inspected to identify and stop malicious activities from threats.
Together with attack surface reduction—composed of advanced capabilities like hardware-based isolation, application control, exploit protection, network protection, controlled folder access, attack surface reduction rules, and network firewall—these next-generation protection engines deliver Microsoft Defender ATP’s pre-breach capabilities, stopping attacks before they can infiltrate devices and compromise networks.
As part of Microsoft’s defense-in-depth solution, the superior performance of these engines accrues to the Microsoft Defender ATP unified endpoint protection, where antivirus detections and other next-generation protection capabilities enrich endpoint detection and response, automated investigation and remediation, advanced hunting, threat and vulnerability management, managed threat hunting service, and other capabilities.
The enormous evolution of Microsoft Defender ATP’s next generation protection follows the same upward trajectory of innovation across Microsoft’s security technologies, which the industry recognizes, and customers benefit from. We will continue to improve and lead the industry in evolving security.
Tanmay Ganacharya (@tanmayg) Principal Director, Microsoft Defender ATP Research
Given what it is I do, I don't squander a minute of precious time, unless something is very important, and this is very important.
Let me explain why this is so alarming, concerning and so important to cyber security, and why at many organizations (e.g. U.S. Govt., Paramount Defenses etc.), this could've either possibly resulted in, or in itself, be considered a cyber security breach.
Disclaimer: I'm not making any value judgment about Lenovo ; I'm merely basing this on what's already been said.
As you know, Microsoft's been brazenly leaving billions of people and thousands of organizations worldwide with no real choice but to upgrade to their latest operating system, Windows 10, which albeit is far from perfect, is much better than Windows Vista, Windows 8 etc., even though Windows 10's default settings could be considered an egregious affront to Privacy.
Consequently, at Paramount Defenses, we too felt that perhaps it was time to consider moving on to Windows 10, so we too figured we'd refresh our workforce's PCs. Now, of the major choices available from amongst several reputable PC vendors out there, Microsoft's Surface was one of the top trustworthy contenders, considering that the entirety of the hardware and software was from the same vendor (, and one that was decently trustworthy (considering that most of the world is running their operating system,)) and that there seemed to be no* pre-installed drivers or software that may have been written in China, Russia etc.
Side-note: Based on information available in the public domain, in all likelihood, software written in / maintained from within Russia, may still likely be running as System on Domain Controllers within the U.S. Government.
So we decided to consider evaluating Microsoft Surface devices and thus purchased a couple of brand-new Microsoft Surface devices from our local Microsoft Store for an initial PoC, and I decided to personally test-drive one of them -
The very first thing we did after unsealing them, walking through the initial setup and locking down Windows 10's unacceptable default privacy settings, was to connect it to the Internet over a secure channel, and perform a Windows Update.
I should mention that there was no other device attached to this Microsoft Surface, except for a Microsoft Signature Type Cover, and in particular there were no mice of any kind, attached to this new Microsoft surface device, whether via USB or Bluetooth.
Now, you're not going to believe what happened within minutes of having clicked the Check for Updatesbutton!
Windows Update Downloaded and Installed anUntrusted Self-Signed Lenovo Device Driver on Microsoft Surface! -
Within minutes, Windows Update automatically downloaded and had installed, amongst other packages (notably Surface Firmware,) an untrusted self-signed Kernel-mode device-driver, purportedly Lenovo - Keyboard, Other hardware - Lenovo Optical Mouse (HID), on this brand-new Microsoft Surface device, i.e. one signed with an untrusted WDK Test Certificate!
Here's a snapshot of Windows Update indicating that it had successfully downloaded and installed a Lenovo driver on this Surface device, and it specifically states "Lenovo - Keyboard, Other hardware - Lenovo Optical Mouse (HID)" -
We couldn't quite believe this. How could this be possible? i.e. how could a Lenovo driver have been installed on a Microsoft Surface device?
So we checked the Windows Update Log, and sure enough, as seen in the snapshot below, the Windows Update Log too confirmed that Windows Update had just downloaded and installed a Lenovo driver -
We wondered if there might have been any Lenovo hardware components installed on the Surface so we checked the Device Manager, and we could not find a single device that seemed to indicate the presence of any Lenovo hardware. (Later, we even took it back to the Microsoft Store, and their skilled tech personnel confirmed the same finding i.e. no Lenovo hardware on it.)
Specifically, as you can see below, we again checked the Device Manager, this time to see if it might indicate the presence of any Lenovo HID, such as a Lenovo Optical Mouse, and as you can see in the snapshot below, the only two Mice and other pointing devices installed on the system were from Microsoft - i.e. no Lenovo mouse presence indicated by Device Manager -
Next, we performed a keyword search of the Registry, and came across a suspicious Driver Package, as seen below -
It seemed suspicious to us because as can be seen in the snapshot above, all of the other legitimate driver package keys in the Registry had (as they should) three child sub-keys i.e. Configurations, Descriptors and Strings, but this specific one only had one subkey titled Properties, and when we tried to open it, we received an Access Denied message!
As you can see above, it seemed to indicate that the provider was Lenovo and that the INF file name was phidmou.inf, and the OEM path was "C:\Windows\SoftwareDistribution\Download\Install", so we looked at the file system but this path didn't seem to exist on the file-system. So we performed a simple file-system search "dir /s phidmou.*" and as seen in the snapshot below, we found one instance of such a file, located in C:\Windows\System32\DriverStore\FileRepository\.
Here's that exact location on the file-system, and as evidenced by the Created date and time for that folder, one can see that this folder (and thus all of its contents), were created on April 01, 2018 at around 1:50 am, which is just around the time the Windows Update log too confirmed that it had installed the Lenovo Driver -
When we opened that location, we found thirteen items, including six drivers -
Next, we checked the Digital Signature on one of the drivers, PELMOUSE.SYS, and we found that it was signed using a self-signed test Windows Driver certificate, i.e. the .sys files were SELF-SIGNED by a WDKTestCert and their digital signatures were NOT OK, in that they terminated in a root certificate that is not trusted by the trust provider -
Finally, when we clicked on the View Certificate button, as can be seen below, we could see that this driver was in fact merely signed by a test certificate, which is only supposed to be used for testing purposes during the creation and development of Kernel-mode drivers. Quoting from Microsoft's documentation on Driver Testing "However, eventually it will become necessary to test-sign your driver during its development, and ultimately release-sign your driver before publishing it to users." -
Clearly, the certificate seen above is NOT one that is intended to be used for release signing, yet, here we have a Kernel-mode driver downloaded by Windows Update and installed on a brand new Microsoft surface, and all its signed by is a test certificate, and who knows who wrote this driver!
Again, per Microsoft's guidelines on driver signing, which can also be found here, "After completing test signing and verifying that the driver is ready for release, the driver package has to be release signed", and AFAIK, release signing not only requires the signer to obtain and use a code-signing certificate from a code-signing CA, it also requires a cross cert issued by Microsoft.
If that is indeed the case, then a Kernel-mode driver that is not signed with a valid code-signing certificate, and one whose digital signature does not contain Microsoft's cross cert, should not even be accepted into the Windows Update catalog.
It is thus hard to believe that a Windows Kernel-Mode Driver that is merely self-signed using a test certificate would even make it into the Windows Update catalog, and further it seems that in this case, not only did it make it in, it was downloaded, and in fact successfully installed onto a system, which clearly seems highly suspicious, and is fact alarming and deeply-concerning!
How could this be? How could Windows Update (a trusted system process of the operating system), which we all (have no choice but to) trust (and have to do so blindly and completely) have itself installed an untrusted self-signed Lenovo driver (i.e. code running in Kernel-Mode) on a Microsoft Surface device?
Frankly, since this piece of software was signed using a self-signed test cert, who's to say this was even a real Lenovo driver? It could very well be some malicious code purporting to be a Lenovo driver. Or, there is also the remote possibility that it could be a legitimate Lenovo driver, that is self-signed, but if that is the case, its installation should not have been allowed to succeed.
To us, this is unacceptable, alarming and deeply concerning, and here's why.
We just had, on a device we consider trustworthy (, and could possibly have engaged in business on,) procured from a vendor we consider trustworthy (considering that the entire world's cyber security ultimately depends on them), an unknown, unsigned piece of software of Chinese origin that is now running in Kernel-mode, installed on the device, by this device's vendor's (i.e. Microsoft's) own product (Windows operating system's) update program!
We have not had an opportunity to analyze this code, but if it is indeed malicious in any way, in effect, it would've, unbeknownst to us and for no fault of ours, granted System-level control over a trusted device within our perimeter, to some entity in China.
How much damage could that have caused? Well, suffice it to say that, for they who know Windows Security well, if this was indeed malicious, it would've been sufficient to potentially compromise any organization within which this potentially suspect and malicious package may have been auto-installed by Windows update. (I've elaborated a bit on this below.)
In the simplest scenario, if a company's Domain Admins had been using this device, it would've been Game Over right there!
This leads me to the next question - we can't help but wonder how many such identical Surface devices exist out there today, perhaps at 1000s of organizations, on which this suspicious unsigned Lenovo driver may have been downloaded and installed?
This also leads me to another very important question - Just how much trust can we, the world, impose in Windows Update?
In our case, it just so happened to be, that we happened to be in front of this device during this Windows update process, and that's how we noticed this, and by the way, after it was done, it gave the familiar Your device is upto date message.
Speaking which, here's another equally important question - For all organizations that are using Windows Surface, and may be using it for mission-critical or sensitive purposes (e.g. AD administration), what is the guarantee that this won't happen again?
I ask because if you understand cyber security, then you know, that it ONLY takes ONE instance of ONE malicious piece of software to be installed on a system, to compromise the security of that system, and if that system was a highly-trusted internal system (e.g. that machine's domain computer account had the "Trusted for Unconstrained Delegation" bit set), then this could very likely also aid perpetrators in ultimately gaining complete command and control of the entire IT infrastructure. As I have already alluded to above, if by chance the target/compromised computer was one that was being used by an Active Directory Privileged User, then, it would be tantamount to Game Over right then and there!
Think about it - this could have happened at any organization, from say the U.S. Government to the British Government, or from say a Goldman Sachs to a Palantir, or say from a stock-exchange to an airline, or say at a clandestine national security agency to say at a nuclear reactor, or even Microsoft itself. In short, for absolutely no fault of theirs, an organization could potentially have been breached by a likely malicious piece of software that the operating system's own update utility had downloaded and installed on the System, and in 99% of situations, because hardly anyone checks what gets installed by Windows Update (now that we have to download and install a whopping 600MB patch every Tuesday), this would likely have gone unnoticed!
Again, to be perfectly clear, I'm not saying that a provably malicious piece of software was in fact downloaded and installed on a Microsoft Surface device by Windows Update. What I'm saying is that a highly suspicious piece of software, one that was built and intended to run in Kernel-mode and yet was merely signed with a test certificate, somehow was automatically downloaded and installed on a Microsoft Surface device, and that to us is deeply concerning, because in essence, if this could happen, then even at organizations that may be spending millions on cyber security, a single such piece of software quietly making its way in through such a trusted channel, could possibly instantly render their entire multi-million dollar cyber security apparatus useless, and jeopardize the security of the entire organization, and this could happen at thousands of organizations worldwide.
With full respect to Microsoft and Mr. Nadella, this is deeply concerning and unacceptable, and I'd like some assurance, as I'm sure would 1000s of other CEOs and CISOs, that this will never happen again, on any Surface device, in any organization.
In our case, this was very important, because had we put that brand new Surface device that we procured from none other than the Microsoft Store, into operation (even it we had re-imaged it with an ultra-secure locked-down internal image), from minute one, post the initial Windows update, we would likely have had a potentially compromised device running within our internal network, and it could perhaps have led to us being breached.
If I Were Microsoft, I'd Send a Plane Dear Microsoft, we immediately quarantined that Microsoft Surface device, and we have it in our possession.
If I were you, I'd send a plane to get it picked up ASAP, so you can thoroughly investigate every little aspect of this to figure out how this possibly happened, and get to the bottom of it! (Petty process note: The Microsoft Store let us keep the device for a bit longer, but will not let us return the device past June 24, and the only reason we've kept it, is in case you'd want to analyze it.) Here's why. At the very least, if I were still at Microsoft, and in charge of Cyber Security -
I'd want to know how an untrusted Kernel-mode device driver made it into the Windows Catalog
I'd want to know why a Microsoft Surface device downloaded a purportedly Lenovo driver
I'd want to know how Windows 10 permitted and in fact itself installed an untrusted driver
I'd want to know exactly which SKUs of Microsoft Surface this may have happened on
I'd want to know exactly how many such Microsoft Surface devices out there may have downloaded this package
Further, and as such, considering that Microsoft Corp itself may easily have thousands of Surface devices being used within Microsoft itself, if I were still with Microsoft CorpSec, I'd certainly want to know how many of their own Surface devices may have automatically downloaded and installed this highly suspicious piece of untrusted self-signed software.
In short, Microsoft, if you care as deeply about cyber security as you say you do, and by that I'm referring to what Mr. Nadella, the CEO of Microsoft, recently said (see video below: 0:40 - 0:44) and I quote "we spend over a billion dollars of R&D each year, in building security into our mainstream products", then you'll want to get to the bottom of this, because other than the Cloud, what else could be a more mainstream product for Microsoft today than, Microsoft Windows and Microsoft Surface ?! -
Folks, the only reason I decided to publicly share this is because I care deeply about cyber security, and I believe that this could potentially have impacted the foundational cyber security of any, and potentially, of thousands of organizations worldwide.
Hopefully, as you'll agree, a trusted component (i.e. Windows Update) of an operating system that virtually the whole world will soon be running on (i.e. Windows 10), should not be downloading and installing a piece of software that runs in Kernel-mode, when that piece of software isn't even digitally signed by a valid digital certificate, because if that piece of software happened to be malicious, then in doing so, it could likely, automatically, and for no fault of its users, instantly compromise the cyber security of possibly thousands of organizations worldwide. This is really as simple, as fundamental and as concerning, as that.
All in all, the Microsoft Surface is an incredible device, and because, like Apple's computers, the entire hardware and software is in control of a single vendor, Microsoft has a huge opportunity to deliver a trustworthy computing device to the world, and we'd love to embrace it. Thus, it is vital for Microsoft to ensure that its other components (e.g. Update) do not let the security of its mainstream products down, because per the Principle of Weakest Link, "a system is only as secure as is its weakest link."
For those may not know what Active Directory Security is (i.e. most CEOs, a few CISOs, and most employees and citizens,) suffice it to say that global security may depend on Active Directory Security, and thus may be a matter of paramount defenses.
Most respectfully, Sanjay
PS: Full Disclosure: I had also immediately brought this matter to the attention of the Microsoft Store. They escalated it to Tier-3 support (based out of New Delhi, India), who then asked me to use the Windows Feedback utility to share the relevant evidence with Microsoft, which I immediately and dutifully did, but/and I never heard back from anyone at Microsoft in this regard again.
PS2: Another small request to Microsoft - Dear Microsoft, while at it, could you please also educate your global customer base about the paramount importance of Active Directory Effective Permissions, which is the ONE capability without which not a single object in any Active Directory deployment can be adequately secured! Considering that Active Directory is the foundation of cyber security of over 85% of all organizations worldwide, this is important. Over the last few years, we've had almost 10,000 organizations from 150+ countries knock at our doors, and virtually none of them seem to know this most basic and cardinal fact of Windows Security. I couldn't begin to tell you how shocking it is for us to learn that most Domain Admins and many CISOs out there don't have a clue. Can you imagine just how insecure and vulnerable an organization whose Domain Admins don't even know what Active Directory Effective Permissions are, let alone possessing this paramount capability, could be today?