As security incidents and events keep making headlines, Microsoft is committed to helping our customers and the rest of the security community to make sense of the risks and offer recommendations. Old and new malware continues to get propagated through massive botnets, attackers are increasing focus on easier attack methods such as phishing, and ransomware attacks have evolved to be more rapid and destructive. The latest Microsoft Security Intelligence Report, which is now available for download at www.microsoft.com/sir, dives deep into each of these key themes and offers insight into additional threat intelligence.

The report, which is based on Microsofts analysis of on-premises systems and cloud services, focuses on threat trends since February 2017. Anonymous data sources for the report come from consumer and commercial on-premises systems and cloud services that Microsoft operates on a global scale, such as Windows, Bing, Office 365, and Azure. At Microsoft, we have massive depth and breadth of intelligence. Across these services, each month we scan 400 billion email messages for phishing and malware, process 450 billion authentications, execute more than 18 billion web page scans, and scan more than 1.2 billion devices for threats.

Here are three key themes from the report:

Botnets continue to impact millions of computers globally.
In November 2017, as part of a public/private global partnership, Microsoft disrupted the command-and-control infrastructure of one of the largest malware operations in the world the Gamarue botnet. Microsoft analyzed over 44,000 malware samples, which uncovered the botnets sprawling infrastructure, and discovered that Gamarue distributed over 80 different malware families. The top three malware classes distributed by the Gamarue botnet were ransomware, trojans, and backdoors. The disruption resulted in a 30% drop in infected devices in just a three month-period.

Easy marks methods like phishing are commonly used by cybercriminals.
As software vendors incorporate stronger security measures into their products, it is becoming more expensive for hackers to successfully penetrate software. By contrast, it is easier and less costly to trick a user into clicking a malicious link or opening a phishing email. In 2017 we saw low-hanging fruit methods being used such as phishing — to trick users into handing over credentials and other sensitive information. In fact, phishing was the top threat vector for Office 365-based threats during the second half of 2017. Other low-hanging fruit for attackers are poorly secured cloud apps. In our research, we found that 79% of SaaS storage apps and 86% of SaaS collaboration apps do not encrypt data both at rest and in transit.

Ransomware remains a force to be reckoned with.
Money is ultimately what drives cybercriminals, so extorting cryptocurrency and other payments by threatening potential victims with the loss of their data remains an attractive strategy. During 2017, three global ransomware outbreaksWannaCrypt, Petya/NotPetya, and BadRabbitaffected corporate networks and impacted hospitals, transportation, and traffic systems. We found that the region with the greatest number of ransomware encounters was Asia. The ransomware attacks observed last year were very destructive and moved at an incredibly rapid pace. Because of the automated propagation techniques, they infected computers faster than any human could respond and they left most victims without access to their files indefinitely.

A key insight in the report is that these threats are interrelated. For example, ransomware was one of the most prominent types of malware distributed by the Gamarue botnet. Another example is that cybercriminals are attempting to take advantage of legitimate platform features to attach a ‘weaponized’ document (for example, a Microsoft Office document) containing ransomware in a phishing email.

What can be done in the enterprise? Following standard information security practices, such as keeping software and security solutions up-to-date, is important. The proliferation of low-cost attack methods such as social engineering is a reminder of the importance of security awareness training for employees to keep them apprised of latest phishing techniques. The report covers more detailed recommendations.

Research and engineering teams from Windows Defender, Office, Azure, Bing, the Microsoft Digital Crimes Unit, and others generously contributed their findings and insights to this Security Intelligence Report. You can download it today at www.microsoft.com/sir.

Finally, tune into our webcast on April 10, 2018 at 10am PDT: Microsoft Security Intelligence Report Volume 23Breaking Botnets and Wrestling Ransomware, where well do a deep dive on the insights from the Security Intelligence Report and discuss recommendations on how to protect your organization. Register today.

For our perspectives on additional trending threats and topics, check out the Microsoft Secure Blog, and the Microsoft Security site to learn about Microsoft’s enterprise cybersecurity solutions.

The annual PWN2OWN exploit contest at the CanSecWest conference in Vancouver, British Columbia, Canada, brings together some of the top security talent from across the globe in a friendly competition. For the participants, these events are a platform to demonstrate world-class skills and vie for significant cash prizes. For companies like Microsoft, where we have a large number of teams focused on security, contests like this provide an additional avenue for external input from researchers. It is this community collaboration that led us to partner with Trend Micro/ZDI to sponsor this years contest.

Microsoft regularly leverages input from the community using programs such as bug bounties and the BlueHat prize in a relentless pursuit to improve the security of our products and expand our understanding of the latest threats.

Exploit contests are great opportunities as it allows Microsoft engineers to exchange ideas face-to-face with the community. This includes intricate details such as attack approaches, techniques used, and opportunities for improvement against similar attacks. While bug bounty programs focus on vulnerabilities, contests like PWN2OWN focus on exploit chains which typically are only seen in real attacks. The opportunity to understand exploits without impact to customers is invaluable. Microsoft has used this to drive security innovations into the platform and in products like Microsoft Edge. Microsoft sponsored several competition targets running the latest Windows Insider preview builds for on Microsoft Surface devices to help direct the community to gain insight into some of our most important areas. None of the competition targets running the latest Windows insider previewer were successfully exploited by contestants.

To demonstrate the effectiveness of this partnership, Microsoft provided an overview of some of the mitigations influenced by offensive security research community in a recent blackhat presentation.

We believe this engagement with researchers has resulted in durable, real-world protection for customers. As an example, Microsoft Edge has still not been impacted by a zero-day exploit in the wild. In addition, this years PWN2OWN entries were not able to escape the Windows Defender Application Guard isolation protection.

Engaging with the research community and creating platforms for transparent information sharing across the wider defender community is a key part of Microsofts strategy to keep customers safe. We will continue to push for deeper collaboration through future events and programs.

On March 7, we reported that a massive Dofoil campaign attempted to install malicious cryptocurrency miners on hundreds of thousands of computers. Windows Defender Antivirus, with its behavior monitoring, machine learning technologies, and layered approach to security detected and blocked the attack within milliseconds.Windows 10 S, a special configuration of Windows 10 providing Microsoft-verified security, was not vulnerable to this attack.

Immediately upon discovering the attack, we looked into the source of the huge volume of infection attempts. Traditionally, Dofoil (also known as Smoke Loader) is distributed in multiple ways, including spam email and exploit kits. In the outbreak, which began in March 6, a pattern stood out: most of the malicious files were written by a process called mediaget.exe.

This process is related to MediaGet, a BitTorrent client that we classify as potentially unwanted application (PUA). MediaGet is often used by people looking to download programs or media from websites with dubious reputation. Downloading through peer-to-peer file-sharing apps like this can increase the risk of downloading malware.

During the outbreak, however, Dofoil didnt seem to be coming from torrent downloads. We didnt see similar patterns in other file-sharing apps. The process mediaget.exe always wrote the Dofoil samples to the %TEMP% folder using the file name my.dat. The most common source of infection was the file %LOCALAPPDATA%\MediaGet2\mediaget.exe (SHA-1: 3e0ccd9fa0a5c40c2abb40ed6730556e3d36af3c).

Tracing the infection timeline

Our continued investigation on the Dofoil outbreak revealed that the March 6 campaign was a carefully planned attack with initial groundwork dating back to mid-February. To set the stage for the outbreak, attackers performed an update poisoning campaign that installed a trojanized version of MediaGet on computers. The following timeline shows the major events related to the Dofoil outbreak.

MediaGet update poisoning

The update poisoning campaign that eventually led to the outbreak is described in the following diagram. A signed mediaget.exe downloads an update.exe program and runs it on the machine to install a new mediaget.exe. The new mediaget.exe program has the same functionality as the original but with additional backdoor capability.

Figure 2. Update poisoning flow

The malicious update process is recorded by Windows Defender ATP. The following alert process tree shows the original mediaget.exe dropping the poisoned signed update.exe.

Figure 3. Windows Defender ATP detection of malicious update process

Poisoned update.exe

The dropped update.exe is a packaged InnoSetup SFX which has an embedded trojanized mediaget.exe, update.exe. When run, it drops a trojanized unsigned version of mediaget.exe.

Figure 4.Certificate information of the poisoned update.exe

Update.exe is signed by a third-party developer company completely unrelated with MediaGet and probably also victim of this plot; update.exe was code signed with a different cert just to pass the signing requirement verification as seen in the original mediaget.exe. The update code will check the certificate information to verify whether it is valid and signed. If it is signed, it will check that the hash value matches the value retrieved from the hash server located in mediaget.com infrastructure. The figure below shows a code snippet that checks for valid signatures on the downloaded update.exe.

Figure 5. mediaget.exe update code

Trojanized mediaget.exe

The trojanized mediaget.exe file, detected by Windows Defender AV as Trojan:Win32/Modimer.A, shows the same functionality as the original one, but it is not signed by any parties and has additional backdoor functionality. This malicious binary has 98% similarity to the original, clean MediaGet binary. The following PE information shows the different PDB information and its file path left in the executable.

Figure 6. PDB path comparison of signed and trojanized executable

When the malware starts, it builds a list of command-and-control (C&C) servers.

Figure 7. C&C server list

One notable detail about the embedded C&C list is that the TLD .bit is not an ICANN-sanctioned TLD and is supported via NameCoin infrastructure. NameCoin is a distributed name server system that adopts the concept of blockchain model and provides anonymous domains. Since .bit domains cant be resolved by ordinary DNS servers, the malware embeds a list of 71 IPv4 addresses that serve as NameCoin DNS servers.

The malware then uses these NameCoin servers to perform DNS lookups of the .bit domains. From this point these names are in the machine’s DNS cache and future lookups will be resolved without needing to specify the NameCoin DNS servers.

The first contact to the C&C server starts one hour after the program starts.

Figure 8. C&C connection start timer

The malware picks one of the four C&C servers at random and resolves the address using NameCoin if its a .bit domain. It uses HTTP for command-and-control communication.

Figure 9. C&C server connection

The backdoor code collects system information and sends them to the C&C server through POST request.

Figure 10. System information

The C&C server sends back various commands to the client. The following response shows the HASH, IDLE, and OK commands. The IDLE command makes the process wait a certain time, indicated in seconds (for example, 7200 seconds = 2 hours), before contacting C&C server again.

Figure 11. C&C commands

One of the backdoor commands is a RUN command that retrieves a URL from the C&C server command string. The malware then downloads a file from the URL, saves it as %TEMP%\my.dat, and runs it.

Figure 12. RUN command processing code

This RUN command was used for the distribution of the Dofoil malware starting March 1 and the malware outbreak on March 6. Windows Defender ATP alert process tree shows the malicious mediaget.exe communicating with goshan.online, one of the identified C&C servers. It then drops and runs my.dat (Dofoil), which eventually leads to the CoinMiner component.

Figure 13.Dofoil, CoinMiner download and execution flow

Figure 14. Windows Defender ATP alert process tree

The malware campaign used Dofoil to deliver CoinMiner, which attempted to use the victims computer resources to mine cryptocurrencies for the attackers. The Dofoil variant used in the attack showed advanced cross-process injection techniques, persistence mechanisms, and evasion methods. Windows Defender ATP can detect these behaviors across the infection chain.

We have shared details we uncovered in our investigation with MediaGets developers to aid in their analysis of the incident.

We have shared details of the malicious use of code-signing certificate used in update.exe (thumbprint: 5022EFCA9E0A9022AB0CA6031A78F66528848568) with the certificate owner.

Real-time defense against malware outbreaks

The Dofoil outbreak on March 6, which was built on prior groundwork, exemplifies the kind of multi-stage malware attacks that are fast-becoming commonplace. Commodity cybercrime threats are adopting sophisticated methods that are traditionally associated with more advanced cyberattacks. Windows Defender Advanced Threat Protection (Windows Defender ATP) provides the suite of next-gen defenses that protect customers against a wide range of attacks in real-time.

The surge in Bitcoin prices has driven widescale interest in cryptocurrencies. While the future of digital currencies is uncertain, they are shaking up the cybersecurity landscape as they continue to influence the intent and nature of attacks.

Cybercriminals gave cryptocurrencies a bad name when ransomware started instructing victims to pay ransom in the form of digital currencies, most notably Bitcoin, the first and most popular of these currencies. It was not an unexpected move digital currencies provide the anonymity that cybercriminals desire. The sharp increase in the value of digital currencies is a windfall for cybercriminals who have successfully extorted Bitcoins from ransomware victims.

These dynamics are driving cybercriminal activity related to cryptocurrencies and have led to an explosion of cryptocurrency miners (also called cryptominers or coin miners) in various forms. Mining is the process of running complex mathematical calculations necessary to maintain the blockchain ledger. This process rewards coins but requires significant computing resources.

Coin miners are not inherently malicious. Some individuals and organizations invest in hardware and electric power for legitimate coin mining operations. However, others are looking for alternative sources of computing power; as a result, some coin miners find their way into corporate networks. While not malicious, these coin miners are not wanted in enterprise environments because they eat up precious computing resources.

As expected, cybercriminals see an opportunity to make money and they customize coin miners for malicious intents. Crooks then run malware campaigns that distribute, install, and run the trojanized miners at the expense of other peoples computing resources. On March 6, Windows Defender Advanced Threat Protection (Windows Defender ATP) blocked a massive coin mining campaign from the operators of Dofoil (also known as Smoke Loader).

Coin mining malware

Cybercriminals repackage or modify existing miners and then use social engineering, dropper malware, or exploits to distribute and install the trojanized cryptocurrency miners on target computers. Every month from September 2017 to January 2018, an average of 644,000 unique computers encountered coin mining malware.

Interestingly, the proliferation of malicious cryptocurrency miners coincide with a decrease in the volume of ransomware. Are these two trends related? Are cybercriminals shifting their focus to cryptocurrency miners as primary source of income? Its not likely that cybercriminals will completely abandon ransomware operations any time soon, but the increase in trojanized cryptocurrency miners indicates that attackers are definitely exploring the possibilities of this newer method of illicitly earning money.

We have seen a wide range of malicious cryptocurrency miners, some of them incorporating more sophisticated mechanisms to infect targets, including the use of exploits or self-distributing malware. We have also observed that established malware families long associated with certain modus operandi, such as banking trojans, have started to include coin mining routines in recent variants. These developments indicate widespread cybercriminal interest in coin mining, with various attackers and cybercriminal groups launching attacks.

Infection vectors

The downward trend in ransomware encounters may be due to an observed shift in the payload of one of its primary infection vectors: exploit kits. Even though there has been a continuous decrease in the volume of exploit kit activity since 2016, these kits, which are available as a service in cybercriminal underground markets, are now also being used to distribute coin miners. Before ransomware, exploit kits were known to deploy banking trojans.

DDE exploits, which have also been known to distribute ransomware, are now delivering miners. For example, a sample of the malware detected as Trojan:Win32/Coinminer (SHA-256: 7213cbbb1a634d780f9bb861418eb262f58954e6e5dca09ca50c1e1324451293) is installed by Exploit:O97M/DDEDownloader.PA, a Word document that contains the DDE exploit. The exploit launches a cmdlet that executes a malicious PowerShell script (Trojan:PowerShell/Maponeir.A), which then downloads the trojanized miner: a modified version of the miner XMRig, which mines Monero cryptocurrency.

Other miners use reliable social engineering tactics to infect machines. Cybercriminals have been distributing a file called flashupdate, masquerading the file as the Flash Player. The download link itselfseen in spam campaigns and malicious websitesalso uses the string flashplayer. Detected as Trojan:Win32/Coinminer, this trojanized coin miner (SHA-256 abbf959ac30d23cf2882ec223966b0b8c30ae85415ccfc41a5924b29cd6bd4db) likewise uses a modified version of the XMRig miner.

Persistence mechanisms

For cryptocurrency miners, persistence is a key element. The longer they stay memory-resident and undetected, the longer they can mine using stolen computer resources. While more traditional persistence mechanisms like scheduled tasks and autostart registry entries are common, cybercriminals can also use more advanced methods like code injection and other fileless techniques, which can allow them to evade detection.

One example of coin mining malware that uses code injection is a miner detected as Trojan:Win32/CoinMiner.BW!bit (SHA-256: f9c67313230bfc45ba8ffe5e6abeb8b7dc2eddc99c9cebc111fcd7c50d11dc80), which spawns an instance of notepad.exe and then injects its code. Once in memory, it uses some binaries related to legitimate cryptocurrency miners but runs them using specific parameters so that coins are sent to the attackers wallet.

We also came across a malicious PowerShell script, detected as TrojanDownloader:PowerShell/CoinMiner (SHA-256: 5d7e0fcf45004a7a4e27dd42c131bcebfea04f14540bd0f17635505b42a96d6e), that downloads mining code that it executes using its own parameters. It adds a scheduled task so that it runs every time the computer starts.

Spreading capabilities and other behaviors

Some coin miners have other capabilities. For example, a miner detected as Worm:Win32/NeksMiner.A (SHA-256: 80f098ac43f17dbd0f7bb6bad719cc204ef76015cbcdae7b28227c4471d99238) drops a copy in the root folder of all available drives, including mapped network drives and removable drives, allowing it to spread as these drives are accessed using other computers. It then runs legitimate cryptocurrency miners but using its own parameters.

As trojanized cryptocurrency miners continue evolving to become the monetization tool of choice for cybercriminals, we can expect the miners to incorporate more behaviors from established threat types.

Browser-based coin miners (cryptojacking)

Coin mining scripts hosted on websites introduced a new class of browser-based threats a few years ago. The increased interest in cryptocurrencies has intensified this trend. When the said websites are accessed, the malicious scripts mine coins using the visiting devices computing power. While some websites claim legitimacy by prompting the visitor to allow the coin mining script to run, others are more dubious.

Some of these websites, usually video streaming sites, appear to have been set up by cybercriminals specifically for coin mining purposes. Others have been compromised and injected with the offending scripts. One such coin miner is hidden in multiple layers of iframes.

We have also seen have seen tech support scam websites that double as coin miners. Tech support scam websites employ techniques that can make it difficult to close the browser. Meanwhile, a coin mining script runs in the background and uses computer resources.

Figure 3. A sample tech support scam website with a coin mining script

Unauthorized use of legitimate coin miners

On top of malware and malicious websites, enterprises face the threat of another form of cryptocurrency miners: legitimate but unauthorized miners that employees and other parties sneak in to take advantage of sizable processing power in enterprise environments.

While the presence of these miners in corporate networks dont necessarily indicate a bigger attack, they are becoming a corporate issue because they consume precious computing resources that are meant for critical business processes. Miners in corporate networks also result in additional energy consumption, leading to unnecessary costs. Unlike their trojanized counterparts, which arrive through known infection methods, non-malicious but unauthorized cryptocurrency miners might be trickier to detect and block.

In January 2018, Windows enterprise customers who have enabled the potentially unwanted application (PUA) protection feature encountered coin miners in more than 1,800 enterprise machines, a huge jump from the months prior. We expect this number to grow exponentially as we heighten our crackdown on these unwanted applications.

While non-malicious, miners classified as potentially unwanted applications (PUA) are typically unauthorized for use in enterprise environments because they can adversely affect computer performance and responsiveness. In contrast, trojanized miners are classified as malware; as such, they are automatically detected and blocked by Microsoft security products. Potentially unwanted applications are further differentiated from unwanted software, which are also considered malicious because they alter your Windows experience without your consent or control.

Windows Defender AV blocks potentially unwanted applications when a user attempts to download or install the application and if the program file meets one of several conditions. Potentially unwanted applications that are blocked appear in the quarantine list in the Windows Defender Security Center app.

In September 2017, around 2% of potentially unwanted applications blocked by Windows Defender AV are coin miners. This figure has increased to around 6% in January 2018, another indication of the increase of these unwanted applications in corporate networks.

Figure 5. Breakdown of potentially unwanted applications

Protecting corporate networks from cryptocurrency miners

Windows 10 Enterprise customers benefit from Windows Defender Advanced Threat Protection, a wide and robust set of security features and capabilities that help prevent coin minters and other malware.

Trojanized cryptocurrency miners are blocked by the same machine learning technologies, behavior-based detection algorithms, generics, and heuristics that allow Window Defender AV to detect most malware at first sight and even stop malware outbreaks, such as the massive Dofoil coin miner campaign. By leveraging Antimalware Scan Interface (AMSI), which provides the capability to inspect script malware even with multiple layers of obfuscation, Windows Defender AV can also detect script-based coin miners.

Malicious websites that host coin miners, such as tech support scam pages with mining scripts, can be blocked by Microsoft Edge using Windows Defender SmartScreen and Windows Defender AV.

Corporate networks face the threat of both non-malicious and trojanized cryptocurrency miners. Windows 10 S, a special configuration of Windows 10, can help prevent threats like coin miners and other malware by working exclusively with apps from the Microsoft Store and by using Microsoft Edge as the default browser, providing Microsoft-verified security.

Security operations personnel can use the advanced behavioral and machine learning detection libraries in Windows Defender Endpoint Detection and Response (Windows Defender EDR) to detect coin mining activity and other anomalies in the network.

Just before noon on March 6 (PST), Windows Defender AV blocked more than 80,000 instances of several sophisticated trojans that exhibited advanced cross-process injection techniques, persistence mechanisms, and evasion methods. Behavior-based signals coupled with cloud-powered machine learning models uncovered this new wave of infection attempts. The trojans, which are new variants of Dofoil (also known as Smoke Loader), carry a coin miner payload. Within the next 12 hours, more than 400,000 instances were recorded, 73% of which were in Russia. Turkey accounted for 18% and Ukraine 4% of the global encounters.

Within minutes, an anomaly detection alert notified us about a new potential outbreak.

After analysis, our response team updated the classification name of this new surge of threats to the proper malware families. People affected by these infection attempts early in the campaign would have seen blocks under machine learning names like Fuery, Fuerboos, Cloxer, or Azden. Later blocks show as the proper family names, Dofoil or Coinminer.

Artificial intelligence and behavior-based detection in Windows Defender AV has become one of the mainstays of our defense system. The AI-based pre-emptive protection provided against this attack is similar to how layered machine learning defenses stopped an Emotet outbreak last month.

Code injection and coin mining

Dofoil is the latest malware family to incorporate coin miners in attacks. Because the value of Bitcoin and other cryptocurrencies continues to grow, malware operators see the opportunity to include coin mining components in their attacks. For example, exploit kits are now delivering coin miners instead of ransomware. Scammers are adding coin mining scripts in tech support scam websites. And certain banking trojan families added coin mining behavior.

The Dofoil campaign we detected on March 6 started with a trojan that performs process hollowing on explorer.exe. Process hollowing is a code injection technique that involves spawning a new instance of legitimate process (in this case c:\windows\syswow64\explorer.exe) and then replacing the legitimate code with malware.

Even though it uses the name of a legitimate Windows binary, its running from the wrong location. The command line is anomalous compared to the legitimate binary. Additionally, the network traffic from this binary is suspicious.

Unlike many coin mining malware that are trojanized versions of legitimate coin miners, the Dofoil component is a bespoke miner. Based on its code, it supports NiceHash, which means it can mine different cryptocurrencies. The samples we analyzed mined Electroneum coins.

Persistence

For coin miner malware, persistence is key. These types of malware employ various techniques to stay undetected for long periods of time in order to mine coins using stolen computer resources.

To stay hidden, Dofoil modifies the registry. The hollowed explorer.exe process creates a copy of the original malware in the Roaming AppData folder and renames it to ditereah.exe. It then replaces the OneDrive entry in the registryRun key,pointingto the newly created malware copy.

Command and communication

Dofoil is an enduring family of trojan downloaders. These connect to command and control (C&C) servers to listen for commands to download and install malware. In the March 6 campaign, Dofoils C&C communication involves the use of the decentralized Namecoin network infrastructure.

The hollowed explorer.exe process writes and runs another binary, D1C6.tmp.exe (SHA256: 5f3efdc65551edb0122ab2c40738c48b677b1058f7dfcdb86b05af42a2d8299c) into the Temp folder. D1C6.tmp.exe then drops and executes a copy of itself named lyk.exe. Once running, lyk.exe connects to IP addresses that act as DNS proxy servers for the Namecoin network. It then attempts to connect to the C&C server vinik.bit inside the NameCoin infrastructure. The C&C server commands the malware to connect or disconnect to an IP address; download a file from a certain URL and execute or terminate the specific file; or sleep for a period of time.

Stay protected with Windows 10

With the rise in valuation of cryptocurrencies, cybercriminal groups are launching more and more attacks to infiltrate networks and quietly mine for coins.

Windows Defender AVs layered approach to security, which uses behavior-based detection algorithms, generics, and heuristics, as well as machine learning models in both the client and the cloud, provides real-time protection against new threats and outbreaks.

Windows 10 S, a special configuration of Windows 10, helps protect against coin miners and other threats. Windows 10 S works exclusively with apps from the Microsoft Store and uses Microsoft Edge as the default browser, providing Microsoft verified security.

We often allude to the benefits of having an integrated threat protection stack in Office 365. Today we wanted to take the opportunity to walk you through how the combined features and services in the Office 365 threat management stack help your organization protect, detect, and respond to a potential phishing attack. Phishing is the term for socially engineered attacks designed to harvest credentials or personally identifiable information (PII). Attackers use a variety of strategies to make the recipient believe the email is coming from a legitimate source. Phish emails often convey a sense of urgency to the recipient to take an action described in the email. We see phishing emails come in a variety of forms including:

Spoofing: where the sending domain matches a legitimate business

Impersonation: of users, domain, and brands (where emails are crafted to look like they are coming from specific users, domains and brands)

End to end security focus

The Office 365 threat protection stack combines a rich set of features designed to prevent phishing attacks, as well as capabilities offered to security teams that more effectively and efficiently enable detection and response to phishing attacks. Our services help:

Protect set up and configure Office 365s security services to keep end users secure.

Detect determine if a threat has entered the tenant and who or what was impacted.

Respond remediate a threat or attack to return your tenant to a safe, no threat state

Protect

Our protection investments begin with a view to eliminating attacks before they impact your organization. Office 365 offers a rich, robust, comprehensive, and multi-layered solution to address phish attacks. Figure 1 shows the Anti-Phish stack leveraged by Office 365. During the mail-flow protection stage, all emails must pass our authentication which includes explicit anti-spoof frameworks including SPF, DMARC, and DKIM. Emails must also pass implicit authentication built on additional machine learning models which determine email authenticity. Additionally, our newly launched anti-impersonation features are designed to flag highly targeted and advanced spear-phishing emails. Content in the form of attachments, links, and images are examined. Further, attachments and links are detonated and examined for malicious content. Soon we will launch internal safe links enabling protection from compromised user accounts.

Figure 1. Office 365 threat protection anti-phish stack

Office 365 threat protection also offers organizations the ability to train users to be more vigilant against the variety of threat scenarios that impact organizations. Attack Simulator is a new feature in public previewoffered to Office 365 Threat Intelligence customers. One of the initial threat simulations available in Attack Simulator is a Display Name Spear Phishing Attack. Spear phishing is a subset of phishing attacks which is targeted, often aimed at a specific group, individual, or organization. These attacks are customized and tend to leverage a sender name or common domain that creates trust with the recipient. Attack Simulator harnesses signal from Office 365 Threat Intelligence which provides visibility into an organizations most targeted and potentially most vulnerable users and enables admins to launch simulated threats targeting those very same users. This provides the most targeted users with training on how to recognize phish emails and provides admins visibility on how those users behave during an attack – enabling optimal policy updates and security protocols. Figure 2 shows an example of a simulated phish email created with Attack Simulator.

Figure 2. Example spear phishing email created with Attack Simulator

We believe customers will benefit from Attack Simulator and the ability to help train end users to spot malicious emails. One key aspect of that training is to inspect the URL behind the hyperlink. With the Native Link Rendering feature launching later this year, end users can hover over hyperlinks in their email and view where the link is pointing to. This is useful since the actual destination of a link can provide important indicators of whether the link is trustworthy or linking to a malicious site. Figure 3 demonstrates how native link rendering allows the user to inspect a link in the body of an email.

Figure 3. Native Link Rendering

If an Office 365 Advanced Threat Protection (ATP) user does click on a malicious link, they will be protected by ATP Safe Links at the time of click. This is part of the post-delivery protection layer shown in Figure 1. Time-of-click protection offered by ATP Safe Links is important because many of todays advanced threats leverage some form of link morphing. The email initially includes a benign link and passes through basic security filters undetected. Once past these filters, the link morphs and points to a malicious site. Therefore, time-of-click protection is essential for protecting users from these threats.

In the event an end user believes a link might be malicious, they can submit the email directly to Microsoft for analysis. Admins should enable the Report Message (Figure 4) add-in which end users can use to submit suspicious emails directly to Microsoft. Our 3500+ security engineering team will review the email and determine if it is actually malicious. If Microsoft classifies the email as malicious, new instances of the email are flagged and blocked across all Office 365 tenants.

Figure 4. Report Message Button

Giving end users the ability to report messages directly enables Microsoft to quickly expand its telemetry and depth of the threat landscape and broaden protection for all our customers. In fact, customers using the Exchange Online Protection (EOP) secure email gateway service, which is available with every Office 365 license, also benefit from our powerful integration and signal sharing across the Microsoft ecosystem.

Another key post-delivery anti-phishing feature is Zero-hour Auto Purge (ZAP), which moves all instances of malicious emails that Microsoft discovers to the junk mail folder – even after it has landed in a user inbox. This process happens quickly and emails that are not initially classified malicious but flagged by Office 365 ATP (or even services from our Windows platform such as Windows Defender Advanced Threat Protection) will be ZAPed to the junk mail folder. This new threat telemetry integrates with the Microsoft Intelligent Security Graph so that future instances of the newly classified malicious email will be blocked across the entire Microsoft ecosystem. We can evolve and stay ahead of the changing threat landscape by leveraging the direct threat telemetry from end users, continuously, and rapidly enhancing our protection for all our customers.

Figure 5. EOP ZAP Protection

Detect

With the newly released real-time ATP reports, customers have visibility into all malicious emails that targeted the tenant and blocked by Office 365. Administrators that use ATP can also see all emails that have been flagged and submitted by their end users as potential threats. With the User-reported threats view (Figure 6), admins can identify the sender of the email, the number of instances of the email, and the number of users who received the email. The ability to view emails submitted by end users is an extremely valuable tool because it empowers organizations security teams to identify malicious emails and trigger investigations on potential threats and impacts. The combination of these reports provides administrators and security teams a comprehensive view into the breadth and depth of different phishing campaigns targeting their organization. The User-reported submissions are also sent to Microsoft for further analysis.

Figure 6. User submissions report

Respond

We have demonstrated how Office 365 protects organizations from phishing campaigns using a multi-layered approach. Office 365 Threat Intelligence completes the threat protection stack by allowing organizations to more effectively and efficiently investigate, respond to, and remediate attacks to the organization. In fact, since Microsoft IT began leveraging Office 365 Threat Intelligence average time to resolution for social engineering incidents has reduced by 80 percent, and case throughput has increased 37 percent per month. Many enterprises have security operations teams whose goal is to assess the impact of threats to an organization. Using the Threat Explorer feature in the Security and Compliance Center, security analysts and administrators can search for all instances of potentially malicious emails. Thanks to a back-end designed specifically for efficient threat investigation and remediation, malicious emails can be quickly and easily identified with Threat Explorer. As shown in Figure 7, Threat Explorer provides many filtering and search options such as sender, recipient, subject, and several more to find the malicious emails. From the User-reported threats view, admins gain visibility into the sender of the email. This is critical since emails that are part of a phishing campaign often come from a unique sender address. Threat Explorer allows admins to filter by sender to find all emails sent from a specific email address. Once this filter has been applied, all emails sent from the unique address will be displayed in Threat Explorer. The admin can then select all the emails that need to be investigated from a specific sender from the message list at the bottom of the Threat Explorer.

Figure 7. Threat Explorer

After selecting the emails to investigate, admins can choose a variety of actions that can be taken on the messages including: move to junk, move to deleted items, soft delete, hard delete, and move to inbox as shown in Figure 8. Analysts can easily trigger the action to purge the malicious email campaign from all mailboxes in the organization or queue the incident for a manager to approve the action.

Figure 8. Triggering an action

There are common security issues admins may need to check over time for phish or other problems. Whether just reviewing events, getting alerts, or determining threat trends and reporting, Office 365’s Threat Intelligence Threat Tracker enables ongoing supervision of your security tasks. The Tracker Saved Query feature shown in Figure 9 allows you to save frequent searches, so admins can navigate quickly to a consistent set of events in Explorer. In case you need ongoing monitoring, you can setup tracking on the queries to get trending information on phish, malware, or other security events.

Figure 9. Saving an Explorer query in Office 365 Threat Intelligence

Office 365 Threat Protection

Microsoft has heavily invested in helping secure our customers for several years. In the last few years, as the level of cybercrime has increased, we have also increased our efforts and focus on developing and continuously enhancing advanced security solutions to protect customers from a wide variety of threats and types of attack. In this phishing scenario, you see a part of this continued focus on engineering security services giving end users ultimate protection from modern threats, while giving administrators a powerful set of tools with maximum control and flexibility for their security requirements. To begin experiencing best of breed protection for all your Office 365 users, we invite you to sign up for an Office 365 E5 trial today. Make sure to provide us your feedback so we can continue delivering the features and enhancements needed to keep your organization secure.

This blog is part of a series that responds to common questions we receive from customers about how to most effectively deploy Microsoft 365 Security. In this series youll find context, answers, and guidance for deployment and driving adoption within your organization.

This past year, weve been listening to our customers questions about how to deploy and drive adoption around the full suite of Microsoft 365 Security products. The questions we get most often include:

In what order should I deploy security features?

How do I deploy quickly and with minimal business disruption?

How do I as an IT Pro get buy-in from my business decision makers?

How do I get my users to actually use the solution?

How will this impact my end users?

This blog series will provide you with our best answers to these and related questions and offer tips from our security deployment experts.

The Security capabilities in Microsoft 365 integrate where it counts and offers specialized tools for different functions. The result is a comprehensive security solution across your identity, devices, apps, and infrastructure:

One of the most common questions we receive is Where do I begin? Microsoft has provided a sampling of the most common security scenarios customers like you may be wanting to accomplish. To help you envision your plan, we provided the optimum combination of Microsoft 365 products and features you need to bring your scenarios to life Microsoft Security such as:

Work securely from anywhere, anytime

Detect and protect against external threats

Protect your data on files, apps, and devices

Protect your users and their accounts

How do I get started?

The first step to any effective security strategy is careful planning. Here are a few best practices to get you started:

Know your goals and tackle quick wins first. Trying to address every security challenge that comes along can quickly become overwhelming. Get very specific about what you are hoping to gain from a solution. And dont let the search for the perfect setup stand in the way of getting started with quick wins today. For example, setting up self-service password resets or getting company apps securely behind your cloud firewall can quickly show business value.

Map your key stakeholders and influencers. In addition to key influencers (CTO, CSO, CEO, business development managers, etc.), make sure to involve department managers and explore how the new security will impact people, processes, and data internally as well as externally with customers and partners.

Build a good communications plan. Quick user adoption starts with early user communication. Prepare your end users for the changes in advance so that there are no surprises. Communicate every step of the way during pilot and deployment phases. Dont just provide technical details, but try to capture also what they care abouthow the new scenarios will help them to do their job better, how to get started with the new software, where to go for more training, etc.

Well explore these and other planning best practices in future blog posts. Then well move on to key deployment and adoption considerations as well as specific security scenarios. Check back in a few weeks for our next blog post when we drill into FastTrack for Microsoft 365 Security.

Need help getting started? FastTrack provides you with a set of best practices, tools, resources, and experts committed to making your experience with the Microsoft Cloud a great one. Get started on your journey today with a request for assistance from the FastTrack security page.

Todays report, Critical Infrastructure Protection in Latin America and the Caribbean 2018, developed in partnership between Microsoft and the Organization of American States (OAS), demonstrates the value of regional cooperation in global efforts to increase the security of the online environment where it matters most. It acknowledges that rather than focusing on all politics is local or living in a global village, regions have a key role to play in formulating policies and delivering outcomes for cybersecurity in general, and critical infrastructure protection (CIP) in particular.

Glocalization, a buzz phrase from the turn of the millennium, seems well suited to cybersecurity, given the Internets simultaneously global reach and local impact. This duality is important to keep in mind when considering the fact that protecting increasingly connected critical infrastructure is a challenge for nations all over the world, and it poses the question of whether the same solutions can be applied across the varied landscapes in which we operate. Regional elements are important in that context, as they provide us with an opportunity to investigate whether the solutions to global cybersecurity challenges need to be tailored to a particular context to be effective, whilst at the same time allowing us to retain a level of scale.

The latter comes about, as even allowing for the global nature of the online environment, we need to recognize that culture, geography, as well as economic relations and trade, are likely to result in a greater level of interconnectivity between neighboring states than far-flung places on opposite sides of the world. In the world of CIP, this means we are more likely to see the same provider operate across two countries in the same region, the same threat actor target linguistically-linked entities, and the consequences of the same cyber-attacks spill across borders.

Close communication and information sharing amongst and between the different regional stakeholders involved in CIP is therefore even more important. This report makes it clear that policymaking in the age of the Internet needs governments working alongside private industry to deliver effective results, leveraging the respective expertise and capabilities of the two groups. But it also reminds us that regional dialogue as well as bilateral discussions between neighboring states, and even between private sector operators in adjacent jurisdictions, helps protect us all.

The need for increased communication and new regional partnerships are only a few of the recommendations that the report puts forward. It also issues a call for risk management to be placed at the center of any CIP initiative, as well as for a move from cybersecurity towards cyber resilience. Moreover, and particularly relevant to the region of Latin America and the Caribbean, the report encourages a holistic approach to CIP at the national level, with governments urged to put forward cybersecurity frameworks, guidelines, and baselines for operators that are outcomes-focused and can withstand the quick pace of technological evolution. Similarly, the report recognizes the need to ensure a clear division of responsibilities in cybersecurity, and a dedicated effort to foster trust between the different entities and stakeholders that must be involved in protecting critical infrastructure.

The examples of global best practices that the report lays out will be recognizable to anyone with experience in the sector. Yet, the report goes a step further by placing these familiar practices in a regional context through the results of an innovative survey of CIP stakeholders across the region. At the global level, we might take for granted the logic behind why we engage in multi-stakeholder dialogue, or why a clear division of responsibilities is so important in modern technology. The survey shows that even in a region where very few CIP frameworks exist, public-private partnerships, within and across countries, have begun to emerge organically and are valued.

At the same time, the survey helps reinforce how much is still to be done on cybersecurity globally. To highlight just one example, almost half of the over 500 respondents, who are trying to protect the most vital national assets in Latin America and the Caribbean, have not yet endorsed risk management. How can the private sector and governments with advanced risk management capabilities best support capacity building in regions of the world trying to protect the infrastructure underpinning their societies, governments, and economies? I believe that this report is the beginning of a dialogue and roadmap for risk reduction.

Its access to sophisticated zero-day exploits for Microsoft and Adobe software

Its use of an advanced piece of government-grade surveillance spyware FinFisher, also known as FinSpy and detected by Microsoft security products as Wingbird

FinFisher is such a complex piece of malware that, like other researchers, we had to devise special methods to crack it. We needed to do this to understand the techniques FinFisher uses to compromise and persist on a machine, and to validate the effectiveness of Office 365 ATP detonation sandbox, Windows Defender Advanced Threat Protection (Windows Defender ATP) generic detections, and other Microsoft security solutions.

This task proved to be nontrivial. FinFisher is not afraid of using all kinds of tricks, ranging from junk instructions and spaghetti code to multiple layers of virtual machines and several known and lesser-known anti-debug and defensive measures. Security analysts are typically equipped with the tools to defeat a good number of similar tricks during malware investigations. However, FinFisher is in a different category of malware for the level of its anti-analysis protection. Its a complicated puzzle that can be solved by skilled reverse engineers only with good amount of time, code, automation, and creativity. The intricate anti-analysis methods reveal how much effort the FinFisher authors exerted to keep the malware hidden and difficult to analyze.

This exercise revealed tons of information about techniques used by FinFisher that we used to make Office 365 ATP more resistant to sandbox detection and Windows Defender ATP to catch similar techniques and generic behaviors. Using intelligence from our in-depth investigation, Windows Defender ATP can raise alerts for malicious behavior employed by FinFisher (such as memory injection in persistence) in different stages of the attack kill chain. Machine learning in Windows Defender ATP further flags suspicious behaviors observed related to the manipulation of legitimate Windows binaries.

While our analysis has allowed us to immediately protect our customers, wed like to share our insights and add to the growing number of published analyses by other talented researchers (listed below this blog post). We hope that this blog post helps other researchers to understand and analyze FinFisher samples and that this industry-wide information-sharing translate to the protection of as many customers as possible.

Spaghetti and junk codes make common analyst tools ineffective

In analyzing FinFisher, the first obfuscation problem that requires a solution is the removal of junk instructions and spaghetti code, which is a technique that aims to confuse disassembly programs. Spaghetti code makes the program flow hard to read by adding continuous code jumps, hence the name. An example of FinFishers spaghetti code is shown below.

Figure 2. The spaghetti code in FinFisher dropper

This problem is not novel, and in common situations there are known reversing plugins that may help for this task. In the case of FinFisher, however, we could not find a good existing interactive disassembler (IDA) plugin that can normalize the code flow. So we decided to write our own plugin code using IDA Python. Armed with this code, we removed this first layer of anti-analysis protection.

Removing the junk instructions revealed a readable block of code. This code starts by allocating two chunks of memory: a global 1 MB buffer and one 64 KB buffer per thread. The big first buffer is used as index for multiple concurrent threads. A big chunk of data is extracted from the portable executable (PE) file itself and decrypted two times using a custom XOR algorithm. We determined that this chunk of data contains an array of opcode instructions ready to be interpreted by a custom virtual machine program (from this point on referenced generically as VM) implemented by FinFisher authors.

Figure 3. The stages of the FinFisher multi-layered protection mechanisms

Stage 0: Dropper with custom virtual machine

The main dropper implements the VM dispatcher loop and can use 32 different opcodes handlers. Th 64KB buffer is used as a VM descriptor data structure to store data and the just-in-time (JIT) generated code to run. The VM dispatcher loop routine ends with a JMP to another routine. In total, there are 32 different routines, each of them implementing a different opcode and some basic functionality that the malware program may execute.

Figure 4. A snapshot of the code that processes each VM opcode and the associate interpreter

The presence of a VM and virtualized instruction blocks can be described in simpler terms: Essentially, the creators of FinFisher interposed a layer of dynamic code translation (the virtual machine) that makes analysis using regular tools practically impossible. Static analysis tools like IDA may not be useful in analyzing custom code that is interpreted and executed through a VM and a new set of instructions. On the other hand, dynamic analysis tools (like debuggers or sandbox) face the anti-debug and anti-analysis tricks hidden in the virtualized code itself that detects sandbox environments and alters the behavior of the malware.

At this stage, the analysis can only continue by manually investigating the individual code blocks and opcode handlers, which are highly obfuscated (also using spaghetti code). Reusing our deobfuscation tool and some other tricks, we have been able to reverse and analyze these opcodes and map them to a finite list that can be used later to automate the analysis process with some scripting.

The opcode instructions generated by this custom VM are divided into different categories:

Conditional branching opcodes, which implement a code branch based on conditions (equals to JC, JE, JZ, other similar branching opcodes)

Load/Store opcodes, which write to or read from particular addresses of the virtual address space of the process

Specialized opcodes for various purposes, like execute specialized machine instruction that are not virtualized

We are publishing below the (hopefully) complete list of opcodes used by FinFisher VM that we found during our analysis and integrated into our de-virtualization script:

INDEX

MNEMONIC

DESCRIPTION

0x0

EXEC

Execute machine code

0x1

JG

Jump if greater/Jump if not less or equal

0x2

WRITE

Write a value into the dereferenced internal VM value (treated as a pointer)

0x3

JNO

Jump if not overflow

0x4

JLE

Jump if less or equal (signed)

0x5

MOV

Move the value of a register into the VM descriptor (same as opcode 0x1F)

0x6

JO

Jump if overflow

0x7

PUSH

Push the internal VM value to the stack

0x8

ZERO

Reset the internal VM value to 0 (zero)

0x9

JP

Jump if parity even

0xA

WRITE

Write into an address

0xB

ADD

Add the value of a register to the internal VM value

0xC

JNS

Jump if not signed

0xD

JL

Jump if less (signed)

0xE

EXEC

Execute machine code and branch

0xF

JBE

Jump if below or equal or Jump if not above

0x10

SHL

Shift left the internal value the number of times specified into the opcodes

0x11

JA

Jump if above/Jump if not below or equal

0x12

MOV

Move the internal VM value into a register

0x13

JZ

JMP if zero

0x14

ADD

Add an immediate value to the internal Vm descriptor

0x15

JB

Jump if below (unsigned)

0x16

JS

Jump if signed

0x17

EXEC

Execute machine code (same as opcode 0x0)

0x18

JGE

Jump if greater or equal/Jump if not less

0x19

DEREF

Write a register value into a dereferenced pointer

0x1A

JMP

Special obfuscated Jump if below opcode

0x1B

*

Resolve a pointer

0x1C

LOAD

Load a value into the internal VM descriptor

0x1D

JNE

Jump if not equal/Jump if not zero

0x1E

CALL

Call an external function or a function located in the dropper

0x1F

MOV

Move the value of a register into the VM descriptor

0x20

JNB

Jump if not below/Jump if above or equal/Jump if not carry

0x21

JNP

Jump if not parity/Jump if parity odd

Each virtual instruction is stored in a special data structure that contains all the information needed to be properly read and executed by the VM. This data structure is 24 bytes and is composed of some fixed fields and a variable portion that depends on the opcode. Before interpreting the opcode, the VM decrypts the opcodes content (through a simple XOR algorithm), which it then relocates (if needed), using the relocation fields.

Here is an approximate diagram of the opcode data structure:

Figure 5. A graphical representation of the data structure used to store each VM opcode

The VM handler is completely able to generate different code blocks and deal with relocated code due to address space layout randomization (ASLR). It is also able to move code execution into different locations if needed. For instance, in the case of the Execute opcode (0x17), the 32-bit code to run is stored entirely into the variable section with the value at offset 5 specifying the number of bytes to be copied and executed. Otherwise, in the case of conditional opcodes, the variable part can contain the next JIT packet ID or the next relative virtual address (RVA) where code execution should continue.

Of course, not all the opcodes are can be easily read and understood due to additional steps that the authors have taken to make analysis extremely complicated. For example, this is how opcode 0x1A is implemented: The opcode should represent a JB (Jump if below) function, but its implemented through set carry (STC) instruction followed by a JMP into the dispatcher code that will verify the carry flag condition set by STC.

Figure 6. One of the obfuscation tricks included by the malware authors in a VM opcode dispatcher

Even armed with the knowledge we have described so far, it still took us many hours to write a full-fledged opcode interpreter thats able to reconstruct the real code executed by FinFisher.

Stage 1: Loader malware keeps sandbox and debuggers away

The first stage of FinFisher running through this complicated virtual machine is a loader malware designed to probe the system and determine whether its running in a sandbox environment (typical for cloud-based detonation solution like Office 365 ATP).

The loader first dynamically rebuilds a simple import address table (IAT), resolving all the API needed from Kernel32 and NtDll libraries. It then continues executing in a spawned new thread that checks if there are additional undesired modules inside its own virtual address space (for example, modules injected by certain security solutions). It eventually kills all threads that belong to these undesired modules (using ZwQueryInformationThread native API with ThreadQuerySetWin32StartAddress information class).

The first anti-sandbox technique is the loader checking the code segment. If its not 0x1B (for 32-bit systems) or 0x23 (for 32-bit system under Wow64), the loader exits.

Next, the dropper checks its own parent process for indications that it is running in a sandbox setup. It calculates the MD5 hash of the lower-case process image name and terminates if one of the following conditions are met:

The MD5 hash of the parent process image name is either D0C4DBFA1F3962AED583F6FCE666F8BC or 3CE30F5FED4C67053379518EACFCF879

The parent processs full image path is equal to its own process path

If these initial checks are passed, the loader builds a complete IAT by reading four imported libraries from disk (ntdll.dll, kernel32.dll, advapi32.dll, and version.dll) and remapping them in memory. This technique makes use of debuggers and software breakpoints useless. During this stage, the loader may also call a certain API using native system calls, which is another way to bypass breakpoints on API and security solutions using hooks.

At this point, the fun in analysis is not over. A lot of additional anti-sandbox checks are performed in this exact order:

Check that the malware is not executed under the root folder of a drive

Check that the malware file is readable from an external source

Check that the hash of base path is not 3D6D62AF1A7C8053DBC8E110A530C679

Check that the full malware path contains only human readable characters (a-z, A-Z, and 0-9)

Check that no node in the full path contains the MD5 string of the malware file

Fingerprint the system and check the following registry values:

HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid should not be “6ba1d002-21ed-4dbe-afb5-08cf8b81ca32”

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId should not be “55274-649-6478953-23109”, “A22-00001”, or “47220”

HARDWARE\Description\System\SystemBiosDate should not contain 01/02/03

Check that the mutex WininetStartupMutex0 does not already exist

Check that no DLL whose base name has hash value of 0xC9CEF3E4 is mapped into the malware address space

The hashes in these checks are most likely correspond to sandbox or security products that the FinFisher authors want to avoid.

Next, the loader checks that its not running in a virtualized environment (VMWare or Hyper-V) or under a debugger. For the hardware virtualization check, the loader obtains the hardware device list and checks if the MD5 of the vendor ID is equal to a predefined list. In our tests, the malware sample was able to easily detect both VMWare and Hyper-V environments through the detection of the virtualized peripherals (for example, Vmware has VEN_15AD as vendor ID, HyperV has VMBus as bus name). Office 365 ATP sandbox employs special mechanisms to avoid being detected by similar checks.

The loaders anti-debugger code is based on the following three methods:

The first call aims to destroy the debugger connection:
ZwSetInformationThread(GetCurrentProcess(), ThreadHideFromDebugger, NULL, 0);
NOTE: This call completely stops the execution of WinDbg and other debuggers

The second call tries to detect the presence of a debugger:
ZwQueryInformationProcess(CurProc, ProcessDebugPort, &debugPort, sizeof(ULONG_PTR))
ZwQueryInformationProcess(CurProc, ProcessDebugObjectHandle, &debugObjHandle, sizeof(ULONG_PTR))

Finally, if the loader is happy with all the checks done so far, based on the victim operating system (32 or 64-bit) it proceeds to decrypt a set of fake bitmap resources (stage 2) embedded in the executable and prepares the execution of a new layer of VM decoding.

Each bitmap resource is extracted, stripped of the first 0x428 bytes (BMP headers and garbage data), and combined into one file. The block is decrypted using a customized algorithm that uses a key derived from the original malware droppers TimeDateStamp field multiplied by 5.

Figure 8. The fake bitmap image embedded as resource

The 32-bit stage 2 malware uses a customized loading mechanism (i.e., the PE file has a scrambled IAT and relocation table) and exports only one function. For the 64-bit stage 2 malware, the code execution is transferred from the loader using a well-known technique called Heavens Gate. In the next sections, for simplicity, we will continue the analysis only on the 64-bit payload.

Figure 9. Heavens gate is still in use in 2017

Stage 2: A second multi-platform virtual machine

The 64-bit stage 2 malware implements another loader combined with another virtual machine. The architecture is quite similar to the one described previously, but the opcodes are slightly different. After reversing these opcodes, we were able to update our interpreter script to support both 32-bit and 64-bit virtual machines used by FinFisher.

INDEX

MNEMONIC

DESCRIPTION

0x0

JMP

Special obfuscated conditional Jump (always taken or always ignored)

0x1

JMP

Jump to a function (same as opcode 0x10)

0x2

CALL

Call to the function pointed by the internal VM value

0x3

CALL

Optimized CALL function (like the 0x1E opcode of the 32-bit VM)

0x4

EXEC

Execute code and move to the next packet

0x5

JMP

Jump to an internal function

0x6

NOP

No operation, move to the next packet

0x7

CALL

Call an imported API (whose address is stored in the internal VM value)

0x8

LOAD

Load a value into the VM descriptor structure *

0x9

STORE

Store the internal VM value inside a register

0xA

WRITE

Resolve a pointer and store the value of a register in its content

0xB

READ

Move the value pointed by the VM internal value into a register

0xC

LOAD

Load a value into the VM descriptor structure (not optimized)

0xD

CMP

Compare the value pointed by the internal VM descriptor with a register

0xE

CMP

Compare the value pointed by the internal VM descriptor with an immediate value

0xF

XCHG

Exchange the value pointed by the internal VM descriptor with a register

0x10

SHL

Jump to a function (same as opcode 0x1)

This additional virtual machine performs the same duties as the one already described but in a 64-bit environment. It extracts and decrypts the stage 3 malware, which is stored in encrypted resources such as fake dialog boxes. The extraction method is the same, but the encryption algorithm (also XOR) is much simpler. The new payload is decrypted, remapped, and executed in memory, and represents the installation and persistence stage of the malware.

Stage 3: Installer that takes DLL side-loading to a new level

Stage 3 represents the setup program for FinFisher. It is the first plain stage that does not employ a VM or obfuscation. The code supports two different installation methods: setup in a UAC-enforced environment (with limited privileges), or an installation with full-administrative privileges enabled (in cases where the malware gains the ability to run with elevated permissions). We were a bit disappointed that we did not see traces of a true privilege escalation exploit after all this deobfuscation work, but it seems these FinFisher samples were designed to work just using UAC bypasses.

The setup code receives an installation command from the previous stage. In our test, this command was the value 3. The malware creates a global event named 0x0A7F1FFAB12BB2 and drops some files under a folder located in C:\ProgramData or in the user application data folder. The name of the folder and the malware configuration are read from a customized configuration file stored in the resource section of the setup program.

Here the list of the files potentially dropped during the installation stage:

FILE NAME

STAGE

DESCRIPTION

d3d9.dll

Stage 4

Malware loader used for UAC environments with limited privileges; also protected by VM obfuscation

aepic.dll
sspisrv.dlluserenv.dll

Stage 4

Malware loader used in presence of administrative privileges; executed from (and injected into) a fake service; also protected by VM obfuscation

msvcr90.dll

Stage 5

Malware payload injected into the explorer.exe or winlogon.exe process; also protected by VM obfuscation

<randomName>.cab

Config

Main configuration file; encrypted

setup.cab

Unknown

Last section of the setup executable; content still unknown

<randomName>.7z

Plugin

Malware plugin used to spy the victim network communications

wsecedit.rar

Stage 6

Main malware executable

After writing some of these files, the malware decides which kind of installation to perform based on the current privilege provided by the hosting process (for example, if a Microsoft Office process was used as exploit vector):

Installation process under UAC

When running under a limited UAC account, the installer extracts d3d9.dll and creates a persistence key under HKCU\Software\Microsoft\Windows\Run. The malware sets a registry value (whose name is read from the configuration file) to C:\Windows\system32\rundll32.exe c:\ProgramData\AuditApp\d3d9.dll, Control_Run. Before doing this, the malware makes a screenshot of the screen and displays it on top of all other windows for few seconds. This indicates that the authors are trying to hide some messages showed by the system during the setup process.

When loaded with startup command 2, the installer can copy the original explorer.exe file inside its current running directory and rename d3d9.dll to uxtheme.dll. In this case the persistence is achieved by loading the original explorer.exe from its startup location and, using DLL side-loading, passing the execution control to the stage 4 malware (discussed in next section).

Finally, the malware spawns a thread that has the goal to load, remap, and relocate the stage 5 malware. In this context, there is indeed no need to execute the stage 4 malware. The msvcr90.dll file is opened, read, and decrypted, and the code execution control is transferred to the RunDll exported routine.

In the case of 32-bit systems, the malware may attempt a known UAC bypass by launching printui.exe system process and using token manipulation with NtFilterToken as described in this blog post.

Installation process with administrative privilege

This installation method is more interesting because it reveals how the malware tries to achieve stealthier persistence on the machine. The method is a well-known trick used by penetration testers that was automated and generalized by FinFisher

The procedure starts by enumerating the KnownDlls object directory and then scanning for section objects of the cached system DLLs. Next, the malware enumerates all .exe programs in the %System% folder and looks for an original signed Windows binary that imports from at least one KnownDll and from a library that is not in the KnownDll directory. When a suitable .exe file candidate is found, it is copied into the malware installation folder (for example, C:\ProgramData). At this point the malware extracts and decrypts a stub DLL from its own resources (ID 101). It then calls a routine that adds a code section to a target module. This section will contain a fake export table mimicking the same export table of the original system DLL chosen. At the time of writing, the dropper supports aepic.dll, sspisrv.dll, ftllib.dll, and userenv.dll to host the malicious FinFisher payload. Finally, a new Windows service is created with the service path pointing to the candidate .exe located in this new directory together with the freshly created, benign-looking DLL.

In this way, when the service runs during boot, the original Windows executable is executed from a different location and it will automatically load and map the malicious DLL inside its address space, instead of using the genuine system library. This routine is a form of generic and variable generator of DLL side-loading combinations.

In the past, we have seen other activity groups like LEAD employ a similar attacker technique named proxy-library to achieve persistence, but not with this professionalism. The said technique brings the advantage of avoiding auto-start extensibility points (ASEP) scanners and programs that checks for binaries installed as service (for the latter, the service chosen by FinFisher will show up as a clean Windows signed binary).

The malware cleans the system event logs using OpenEventLog/ClearEventLog APIs, and then terminates the setup procedure with a call to StartService to run the stage 4 malware.

Stage 4: The memory loader Fun injection with GDI function hijacking

Depending on how stage 4 was launched, two different things may happen:

In the low-integrity case (under UAC) the installer simply injects the stage 5 malware into the bogus explorer.exe process started earlier and terminates

In the high-integrity case (with administrative privileges or after UAC bypass), the code searches for the process hosting the Plug and Play service (usually svchost.exe) loaded in memory and injects itself into it

For the second scenario, the injection process works like this:

The malware opens the target service process.

It allocates and fills four chunks of memory inside the service process. One chunk contains the entire malware DLL code (without PE headers). Another chunk is used to copy a basic Ntdll and Kernel32 import address table. Two chunks are filled with an asynchronous procedure call (APC) routine code and a stub.

It opens the service thread of the service process and uses the ZwQueueApcThread native API to inject an APC.

The APC routine creates a thread in the context of the svchost.exe process that will map and execute the stage 5 malware into the winlogon.exe process.

The injection method used for winlogon.exe is also interesting and quite unusual. We believe that this method is engineered to avoid trivial detection of process injection using the well-detected CreateRemoteThread or ZwQueueApcThread API.

The malware takes these steps:

Check if the system master boot record (MBR) contains an infection marker (0xD289C989C089 8-bytes value at offset 0x2C), and, if so, terminate itself

Check again if the process is attached to a debugger (using the techniques described previously)

Read, decrypt, and map the stage 5 malware (written in the previous stage in msvcr90.dll)

Open winlogon.exe process

Load user32.dll system library and read the KernelCallbackTable pointer from its own process environment block (PEB) (Note: The KernelCallbackTable points to an array of graphic functions used by Win32 kernel subsystem module win32k.sys as call-back into user-mode.)

Calculate the difference between this pointer and the User32 base address.

Copy the stage 5 DLL into winlogon.exe

Allocate a chunk of memory in winlogon.exe process and copy the same APC routine seen previously

Read and save the original pointer of the __fnDWORD internal User32 routine (located at offset +0x10 of the KernelCallbackTable) and replace this pointer with the address of the APC stub routine

After this function pointer hijacking, when winlogon.exe makes any graphical call (GDI), the malicious code can execute without using CreateRemoteThread or similar triggers that are easily detectable. After execution it takes care of restoring the original KernelCallbackTable.

Stage 5: The final loader takes control

The stage 5 malware is needed only to provide one more layer of obfuscation, through the VM, of the final malware payload and to set up a special Structured Exception Hander routine, which is inserted as Wow64PrepareForException in Ntdll. This special exception handler is needed to manage some memory buffers protection and special exceptions that are used to provide more stealthy execution.

After the VM code has checked again the user environment, it proceeds to extract and execute the final un-obfuscated payload sample directly into winlogon.exe (alternatively, into explorer.exe) process. After the payload is extracted, decrypted, and mapped in the process memory, the malware calls the new DLL entry point, and then the RunDll exported function. The latter implements the entire spyware program.

Stage 6: The payload is a modular spyware framework for further analysis

Our journey to deobfuscating FinFisher has allowed us to uncover the complex anti-analysis techniques used by this malware, as well as to use this intel to protect our customers, which is our top priority. Analysis of the additional spyware modules is future work.

It is evident that the ultimate goal of this program is to steal information. The malware architecture is modular, which means that it can execute plugins. The plugins are stored in its resource section and can be protected by the same VM. The sample we analyzed in October, for example, contains a plugin that is able to spy on internet connections, and can even divert some SSL connections and steal data from encrypted traffic.

Some FinFisher variants incorporate an MBR rootkit, the exact purpose of which is not clear. Quite possibly, this routine targets older platforms like Windows 7 and machines not taking advantage of hardware protections like UEFI and SecureBoot, available on Windows 10. Describing this additional piece of code in detail is outside the scope of this analysis and may require a new dedicated blog post.

Defense against FinFisher

Exposing as much of FinFishers riddles as possible during this painstaking analysis has allowed us to ensure our customers are protected against this advanced piece of malware.

We hope that this writeup of our journey through all the multiple layers of protection, obfuscation, and anti-analysis techniques of FinFisher will be useful to other researchers studying this malware. We believe that an industry-wide collaboration and information-sharing is important in defending customers against this complex piece of malware. For further reading, we recommend these other great references:

Azure is Microsofts cloud computing environment. It offers customers three primary service delivery models including infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). Adopting cloud technologies requires a shared responsibility model for security, with Microsoft responsible for certain controls and the customer others, depending on the service delivery model chosen. To ensure that a customers cloud workloads are protected, it is important that they carefully consider and implement the appropriate architecture and enable the right set of configuration settings.

Microsoft has developed a set of Azure security guidelines and best practices for our customers to follow. These guides can be found in theAzure security best practices and patterns documentation. In addition, were excited to announce the availability of the Center for Internet Securitys (CIS) Microsoft Azure Foundations Security Benchmark, developed in partnership with Microsoft. CIS is a non-profit entity focused on developing global standards and recognized best practices for securing IT systems and data against the most pervasive attacks.

The CIS Microsoft Azure Foundations Security Benchmark provides prescriptive guidance for establishing a secure baseline configuration for Microsoft Azure. Its scope is designed to assist organizations in establishing the foundation level of security for anyone adopting the Microsoft Azure cloud. The benchmark should not be considered as an exhaustive list of all possible security configurations and architecture but as a starting point. Each organization must still evaluate their specific situation, workloads, and compliance requirements and tailor their environment accordingly.

The CIS benchmark contains two levels, each with slightly different technical specifications:

Level 1 Recommended, minimum security settings that should be configured on any system and should cause little or no interruption of service or reduced functionality.

Level 2 Recommended security settings for highly secure environments and could result in some reduced functionality.

The CIS Microsoft Azure Foundations Security Benchmark is divided into the following sections:

Recommendations regarding general security and operational controls, including those related to Azure Key Vault and Resource Locks.

3

Total Recommendations

92

Each recommendation contains several sections, including a recommendation identification number, title, and description; level or profile applicability; rationale; instructions for auditing the control; remediation steps; impact of implementing the control; default value; and references. As an example, the first control contained in the benchmark is under the Identity and Access Management section and is titled: 1.1 Ensure that multi-factor authentication is enabled for all privileged users (Scored). A control is marked as Scored or Not Scored based on whether it can be programmatically tested. In this case, recommendation 1.1 can be audited leveraging the Microsoft Graph and PowerShell commandlet. The specific steps for auditing the control are contained in the “Audit” section for this specific recommendation. This recommendation is listed as a Level 1 control because it is only applied to Azure administrative users and would not have a company-wide impact or produce less functionality for users. The rationale for recommendation 1.1 is that Azure administrative accounts need to be protected due to their powerful privileges, and with multiple factors for authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk to the Azure tenant.

In the first blog post of this 3-part series, we introduced what rapid cyberattacks are and illustrated how rapid cyberattacks are different in terms of execution and outcome. In the second blog post, we provided some details on Petya and how it worked. In this final blog post, we will share:

Microsofts roadmap of recommendations to mitigate rapid cyberattacks.

Outside-in perspectives on rapid cyberattacks and mitigation methods based on a survey of global organizations.

Because of how critical security hygiene issues have become and how challenging it is for organizations to follow the guidance and the multiple recommended practices, Microsoft is taking a fresh approach to solving them. Microsoft is working actively with NIST, the Center for Internet Security (CIS), DHS NCCIC (formerly US-CERT), industry partners, and the cybersecurity community to jointly develop and publish practical guides on critical hygiene and to implement reference solutions starting with these recommendations on rapid cyberattacks as related to patch management.

We recognize every organization has unique challenges and investments in cybersecurity (people and technology) and cannot possibly make every single recommendation a top nor immediate priority. Accordingly, we have broken down the primary (default) recommendations for mitigating rapid cyberattacks into three buckets:

Quick wins: what we recommend organizations accomplish in the first 30 days

Less than 90 days: what we recommend organizations accomplish in the medium term

Next quarter and beyond: what we recommend organizations accomplish in the longer term

The following list is our primary recommendations on how to mitigate these attacks.

This list has been carefully prioritized based on Microsofts direct experience investigating (and helping organizations recover from) these attacks as well as collaboration with numerous industry experts. This is a default set of recommendations and should be tailored to each enterprise based on defenses already in place. You can read more about the details of each recommendation in the slide text and notes of the published slide deck.

In prioritizing the quick wins for the first 30 days, the primary considerations we used are:

Whether the measure directly mitigates a key attack component.

Whether most enterprises could rapidly implement the mitigation (configure, enable, deploy) without significant impact on existing user experiences and business processes.

Figure 3: Mapping each recommendation into the mitigation strategy components

In addition to the primary recommendations, Microsoft has an additional set of recommendations that could provide significant benefits depending on circumstances of the organization:

There are specific reasons why these 12 recommendations, although helpful for certain organizations/circumstances, were excluded from the list of primary recommendations. You can read about those reasons in the slide notes of the published slide deckif interested.

Outside-in perspectives on rapid cyberattacks and mitigation methods

In late November 2017 Microsoft hosted a webinar on this topic and solicited feedback from the attendees which comprised of 845 IT professionals from small organizations to large global enterprises. Here are a few interesting insights from the poll questions.

Rapid cyberattack experience

When asked if they had experienced a rapid cyberattack (e.g. WannaCrypt, Petya or other), ~38% stated they did.

When we asked within how many days (<7 or 30 or 90) they can patch various systems, it seems most respondents believed their team is good at patching quickly:

83% can patch workstations within 30 days; 44% within 7 days

81% can patch servers within 30 days; 51% within 7 days

54% can patch Linux/Other devices within 30 days; 25% within 7 days

Removal of SMBv1

When asked where they are on the path towards removing SMBv1, 26% said they have completed removing it, another 21% said they are in progress or in the process of doing so, and ~18% more are planning to do so.

Adopting roadmap recommendations

When asked what is blocking them from adopting Microsofts roadmap recommendations for securing against rapid cyberattacks, the top three reasons respondents shared are:

Lack of time

Lack of resources

Lack of support from upper management/executive buy-in

To help organizations overcome these challenges, Microsoft can be engaged to:

Investigate an active incident with enterprise-wide malware hunting, analysis, and reverse engineering techniques. This includes providing tailored cyberthreat intelligence and strategic guidance to harden the environment against advanced and persistent attacks. Microsoft can provide onsite teams and remote support to help you investigate suspicious events, detect malicious attacks, and respond to security breaches.

Proactively hunt for persistent adversaries in your environment using similar methods as an active incident response (above).
Contact your Microsoft Technical Account Manager (TAM) or Account Executive to learn more about how to engage Microsoft for incident response.

Contact your Microsoft Technical Account Manager (TAM) or Account Executive to learn more about how to engage Microsoft for incident response.

More information

We hope you found the 3-part blog series on the topic of rapid cyberattacks and some recommendations on how to mitigate them useful.

For more information and resources on rapid cyber attacks, please visit the additional links here:

This last October we saw more countries than ever participate in initiatives to raise cybersecurity awareness. What was once largely a US approach has evolved into events and initiatives around the world by governments, civil society groups, and private sector partners. This increased breadth and depth of activity reflects governments increased understanding of the importance of cybersecurity, not only for their operations but for the lives of their citizens. My teams research indicates that today over half of the worlds countries are leading some sort of national level initiative for cybersecurity, with countless other efforts at sectoral, state, city, or other levels.

However, developing effective approaches to tackling cybersecurity at a national level isnt easy, especially if they are going to have widespread or long-lasting effects. The complexity of developing approaches for an issue that truly touches all aspects of the modern economy and society cannot be understated and if approached in the wrong way can create a quagmire of laws, bodies, and processes. The different aspects of cybersecurity such as promoting online safety, workforce skills development, and critical infrastructure protection, all cut across an unprecedented range of traditional government departments, from defense and foreign affairs, to education and finance. Effectively, cybersecurity is one of the first policy areas that challenges traditional national governance structures and policy making. It is unlikely to be the last, with issues such as artificial intelligence hard on its heels.

To deal with this challenge, governments are exploring new governance models. Some countries have created a dedicated department within a particular ministry, such as India. Others have looked at extending the work traditionally done by the police or a national computer security incident response team, such as Malaysia. Moreover, countries as diverse as Australia, France, Brazil, Indonesia, Tanzania, Belarus, Israel, and Singapore, already have specific bodies of government responsible for cybersecurity.

However, despite the fact that many countries have already taken steps to establish or strengthen their own cybersecurity bodies; no single, optimum, model can be pointed to. The reasons are many, from different governance set ups, to varying levels of investment and expertise available, to the fact that dealing with cybersecurity is a relatively new endeavor for governments.

Taking this variety into account, and coupling it with our own perspective and experience, Microsoft has collected good practices that we believe can support national engagement on cybersecurity. Today we are releasing a new whitepaper: Building an Effective National Cybersecurity Agency. Its core insights center around the following set of recommendations for governments in order to avoid becoming bogged down in cybersecurity challenges that are otherwise avoidable:

Appoint a single national cybersecurity agency.Having a single authority creates a focal point for key functions across the government, which ensures policies are prioritized and harmonized across the nation.

Provide the national cybersecurity agency with a clear mandate. Cybersecurity spans different stakeholders with overlapping priorities. Having a clear mandate for the agency will help set expectations for the roles and responsibilities and facilitate the intra-governmental processes.

Ensure the national cybersecurity agency has appropriate statutory powers. Currently, most national cybersecurity agencies are established not by statute but by delegating existing powers from other parts of government. As cybersecurity becomes an issue for national legislature, agencies might have to be given clear ownership of implementation.

Implement a five-part organizational structure. The five-part structure we propose in the paper allows for a multifaceted interaction across internal government and regulatory stakeholders, as well as external and international stakeholders, and aims to tackle both regulatory and other cybersecurity aspects.

Expect to evolve and adapt. Regardless of how the structure of the national cybersecurity agency begins, the unavoidability of change in the technology and threat landscape will require it to evolve and adapt over time to be able to continue to fulfill its mandate.

As the challenges and opportunities that come as a result of ICT proliferation continue to evolve, governments will need to ensure they are sufficiently equipped to face them, both today and in the future. Bringing together diverse stakeholders across different agencies, such as defense, commerce, and foreign affairs, and backgrounds, including those from law, engineering, economics, ad policy, will enable our society to both deal with the threats and harness the opportunities of cyberspace. It is this diversity of stakeholders that contributes to the challenge cybersecurity poses for traditional governance.

But cybersecurity is the first of many emerging areas that necessitates new and creative solutions that allows policymakers to work hand in hand with their counterparts across government, civil society and industry. For cybersecurity, as well as the issues to come, cooperation is the underpinning of achieving these goals. However, cooperation cannot be created organically, it must grow from an effectively structured governance system. Establishing a national cybersecurity agency will enable governments to do just that.

At 12:46 a.m. local time on February 3, a Windows 7 Pro customer in North Carolina became the first would-be victim of a new malware attack campaign for Trojan:Win32/Emotet. In the next 30 minutes, the campaign tried to attack over a thousand potential victims, all of whom were instantly and automatically protected by Windows Defender AV.

How did Windows Defender AV uncover the newly launched attack and block it at the outset? Through layered machine learning, including use of both client-side and cloud machine learning (ML) models. Every day, artificial intelligence enables Windows Defender AV to stop countless malware outbreaks in their tracks. In this blog post, well take a detailed look at how the combination of client and cloud ML models detects new outbreaks.

Figure 1. Layered detected model in Windows Defender AV

Client machine learning models

The first layer of machine learning protection is an array of lightweight ML models built right into the Windows Defender AV client that runs locally on your computer. Many of these models are specialized for file types commonly abused by malware authors, including, JavaScript, Visual Basic Script, and Office macro. Some models target behavior detection, while other models are aimed at detecting portable executable (PE) files (.exe and .dll).

In the case of the Emotet outbreak on February 3, Windows Defender AV caught the attack using one of the PE gradient boosted tree ensemble models. This model classifies files based on a featurization of the assembly opcode sequence as the file is emulated, allowing the model to look at the files behavior as it was simulated to run.

The tree ensemble was trained using LightGBM, a Microsoft open-source framework used for high-performance gradient boosting.

Figure 3a. Visualization of the LightBGM-trained client ML model that successfully classified Emotet’s emulation behavior as malicious. A set of 20 decision trees are combined in this model to classify whether the files emulated behavior sequence is malicious or not.

Figure 3b. A more detailed look at the first decision tree in the model. Each decision is based on the value of a different feature. Green triangles indicate weighted-clean decision result; red triangles indicate weighted malware decision result for the tree.

When the client-based machine learning model predicts a high probability of maliciousness, a rich set of feature vectors is then prepared to describe the content. These feature vectors include:

Behavior during emulation, such as API calls and executed code

Similarity fuzzy hashes

Vectors of content descriptive flags optimized for use in ML models

Researcher-driven attributes, such as packer technology used for obfuscation

File name

File size

Entropy level

File attributes, such as number of sections

Partial file hashes of the static and emulated content

This set of features form a signal sent to the Windows Defender AV cloud protection service, which runs a wide array of more complex models in real-time to instantly classify the signal as malicious or benign.

Real-time cloud machine learning models

Windows Defender AVs cloud-based real-time classifiers are powerful and complex ML models that use a lot of memory, disk space, and computational resources. They also incorporate global file information and Microsoft reputation as part of the Microsoft Intelligent Security Graph (ISG) to classify a signal. Relying on the cloud for these complex models has several benefits. First, it doesnt use your own computers precious resources. Second, the cloud allows us to take into consideration the global information and reputation information from ISG to make a better decision. Third, cloud-based models are harder for cybercriminals to evade. Attackers can take a local client and test our models without our knowledge all day long. To test our cloud-based defenses, however, attackers have to talk to our cloud service, which will allow us to react to them.

The cloud protection service is queried by Windows Defender AV clients billions of times every day to classify signals, resulting in millions of malware blocks per day, and translating to protection for hundreds of millions of customers. Today, the Windows Defender AV cloud protection service has around 30 powerful models that run in parallel. Some of these models incorporate millions of features each; most are updated daily to adapt to the quickly changing threat landscape. All together, these classifiers provide an array of classifications that provide valuable information about the content being scanned on your computer.

Classifications from cloud ML models are combined with ensemble ML classifiers, reputation-based rules, allow-list rules, and data in ISG to come up with a final decision on the signal. The cloud protection service then replies to the Windows Defender client with a decision on whether the signal is malicious or not all in a fraction of a second.

Figure 4. Windows Defender AV cloud protection service workflow.

In the Emotet outbreak, one of our cloud ML servers in North America received the most queries from customers; corresponding to where the outbreak began. At least nine real-time cloud-based ML classifiers correctly identified the file as malware. The cloud protection service replied to signals instructing the Windows Defender AV client to block the attack using two of our ML-based threat names, Trojan:Win32/Fuerboos.C!cl and Trojan:Win32/Fuery.A!cl.

Deep learning on the full file content

Automatic sample submission, a Windows Defender AV feature, sent a copy of the malware file to our backend systems less than a minute after the very first encounter. Deep learning ML models immediately analyzed the file based on the full file content and behavior observed during detonation. Not surprisingly, deep neural network models identified the file as a variant of Trojan:Win32/Emotet, a family of banking Trojans.

While the ML classifiers ensured that the malware was blocked at first sight, deep learning models helped associate the threat with the correct malware family. Customers who were protected from the attack can use this information to understand the impact the malware might have had if it were not stopped.

Intelligent real-time protection against modern threats

Machine learning and AI are at the forefront of the next-gen real-time protection delivered by Windows Defender AV. These technologies, backed by unparalleled optics into the threat landscape provided by ISG as well as world-class Windows Defender experts and researchers, allow Microsoft security products to quickly evolve and scale to defend against the full range of attack scenarios.

Many organizations are undergoing a digital transformation that leverages a mix of cloud and on-premises assets to increase business efficiency and growth. While increased dependence on technology is necessary for this transformation, and to position the business for success, it does pose risks from security threats. An organization cannot afford to wait until after users and systems have been compromised; it must be proactive.

It is impossible to be 100 percent secure. It can take less than 48 hours for attackers to gain complete control of a network,[1] and the median time to discover a breach is 99 days[2]. With incidents costing an average of $141 per lost or stolen record[3]and some cybersecurity events such as Petya costing $200-310 million[4], organizations must develop comprehensive risk management plans. These plans must keep a hybrid infrastructure resilient to a range of cyber threats encompassing both established and emerging threats. In addition, plans must help to manage the risk of emerging vulnerabilities, such as the recently disclosed processor vulnerabilities named Spectre and Meltdown.

Microsoft helps multiple global enterprises mitigate business impact by offering prescriptive guidance, as well as partnering with them to build a cyber resiliency plan and roadmap.

To learn more about how Microsoft views the importance of cyber resilience for the modern enterprise, get prescriptive guidance on building a cyber resiliency plan and roadmap, and find out what Microsoft is doing to help enterprises rapidly become resilient to commonly encountered attacks and vulnerabilities, check out these resources:

Microsoft as a Trusted Advisor and Partner on Cyber Resilience white paper co-authored by members of Microsoft Enterprise Cybersecurity Group

The word strategy has its origins in the Roman Empire and was used to describe the leading of troops in battle. From a military perspective, strategy is a top-level plan designed to achieve one or more high-order goals. A clear strategy is especially important in times of uncertainty as it provides a framework for those involved in executing the strategy to make the decisions needed for success.

In a corporate or government entity, the primary role of the Chief Information Security Officer (CISO) is to establish a clear cybersecurity strategy and oversee its execution. To establish an effective strategy, one must first understand, and it is recommended to document, the following:

Resources. The most critical component of a successful strategy is the proper utilization of available resources. As such, a CISO must have a clear picture of their annual budget, including operating and capital expenditures. In addition, the CISO must understand not just the number of vendors and full-time employees under their span of control, but also the capabilities and weaknesses of these resources. The CISO must also have an appreciation for the capabilities of key resources that are essential to effective security but not necessarily under their direct supervision, such as server and desktop administrators, the team responsible for patching, etc. One of the most difficult aspects of the CISO job is that to be successful you must positively influence the actions of other teams whose jobs are critical to the success of the security program, and your career, but who are not under your direct control.

Business Drivers. At the end of the day, CISOs have a finite amount of resources to achieve goals and cannot apply the same level of protection to all digital assets. To help make resource allocation decisions, the CISO must clearly understand the business they have been charged with protecting. What is most important to the success of the business? Which lines of business produce the most revenue, and which digital assets are associated with those lines? For governments, which services are essential for residents’ health and for maintaining government operations, and which digital assets are associated with those services and functions?

Data. Data is the lifeblood of most companies and is often the target of cyber criminals, whether to steal or encrypt for ransom. Once business drivers have been identified, the CISO should inventory the data that is important to the lines of business. This should include documenting the format, volume, and locations of the data and the associated data steward. In large organizations, this can be extremely challenging, but it is essential to have a clear picture of the storage and processing of the entitys crown jewels.

Controls. Before formulating a strategy, the CISO must gain an understanding of the status of the safeguards or countermeasures that have been deployed within an environment to minimize the security risks posed to digital assets. These will include controls to minimize risks to the confidentiality, integrity, or availability of the assets. In determining the sufficiency of a control, assess its design and operating effectiveness. Does the control cover all assets or a subset? Is the control effective at reducing the risk to an acceptable level or is the residual risk still high? For example, one control found to be effective in minimizing risk to the confidentiality of data is to require a second factor of authentication prior to granting access to sensitive records. If such a control is implemented, what percentage of users require a second authentication factor before accessing the companys most sensitive data? What is the likelihood that a user will acknowledge a second factor in error as the result of a phishing test?

Threats. Identifying the threats to an organization is one of the more difficult tasks in developing a cyber strategy, as cyber threats tend to be asymmetric and constantly evolving. Still, it is important to identify the most likely threat actors and the motivations, tactics, techniques, and procedures used to achieve their goals.

Once a CISO has a clear picture of the items discussed above, they can begin formulating a strategy appropriate to the task at hand. There is no one size fits all approach, as each organization is unique, but there are models and frameworks that have proven helpful over time, including those developed by the National Institute of Standards and Technology, Cyber Kill Chain, Center for Internet Security, SANS, and the Australian Signals Directorate, among others. An effective strategy must also consider human and organizational dynamics. For example, employees will typically work around a control that increases the actual, or perceived, amount of effort to perform a given task, especially when they feel that the effort is not commensurate with the threat being addressed.

At Microsoft, we are continuously evaluating the current threats faced by our customers and building products and services to help CISOs execute their strategies. The design of our products not only accounts for the techniques utilized by cyber attackers, but also incorporates features that address the human dynamics within an enterprise and the staff and retention challenges faced by security teams. A few examples of these design principles in practice include building security features and functions within our productivity tools such as Office 365 Advanced Threat Protection, using auto-classification to reduce the workload on end users with Azure Information Protection, and increasing the efficiency and effectiveness of security teams with Windows Defender Advanced Threat Protection.

In the first blog post of this 3-part series, we introduced what rapid cyberattacks are and illustrated how they are different in terms of execution and outcome. Next, we will go into some more details on the Petya (aka NotPetya) attack.

How Petya worked

The Petya attack chain is well understood, although a few small mysteries remain. Here are the four steps in the Petya kill chain:

Figure 1:How the Petya attack worked

Prepare – The Petya attack began with a compromise of the MEDoc application. As organizations updated the application, the Petya code was initiated.

Enter – When MEDoc customers installed the software update, the Petya code ran on an enterprise host and began to propagate in the enterprise.

Credential theft Impersonated any currently logged on accounts (including service accounts).

Note that Petya only compromised accounts that were logged on with an active session (e.g. credentials loaded into LSASS memory).

Execute – Petya would then reboot and start the encryption process. While the screen text claimed to be ransomware, this attack was clearly intended to wipe data as there was no technical provision in the malware to generate individual keys and register them with a central service (standard ransomware procedures to enable recovery).

Unknowns and Unique Characteristics of Petya:

Although it is unclear if Petya was intended to have as widespread an impact as it ended up having, it is likely that this attack was built by an advanced group, considering the following:

The Petya attack wiped the event logs on the system, which is unneeded as the drive was wiped later anyways. This leaves an open question on whether this is just standard anti-forensic practice (as is common for many advanced attack groups) or whether there were other attack actions/operations being covered up by Petya.

The supply chain approach taken by Petya requires a well-funded adversary with a high level of investment into attack skills/capability. Although supply chain attacks are rising, these still represent a small percentage of how attackers get into corporate environments and require a higher degree of sophistication to execute.

Petya and Traversal/Propagation

Our observation was that Petya spread more by using identity impersonation techniques than through MS17-010 vulnerability exploitation. This is likely because of the emergency patching initiatives organizations followed to deploy MS17-010 in response to the WannaCrypt attacks and associated publicity.

The Petya attacks also resurfaced a popular misconception about mitigating lateral traversal which comes up frequently in targeted data theft attacks. If a threat actor has acquired the credentials needed for lateral traversal, you can NOT block the attack by disabling execution methods like PowerShell or WMI. This is not a good choke point because legitimate remote management requires at least one process execution method to be enabled.

Figure 2:How the Petya attack spreads

Youll see in the illustration above that achieving traversal requires three technical phases:

1st phase: Targeting Identify which machines to attack/spread to next.

Petyas targeting mechanism was consistent with normal worm behavior. However, Petya did include a unique innovation where it acquired IPs to target from the DHCP subnet configuration from servers and DCs to accelerate its spread.

A unique aspect of Petya is that it used automated credential theft and re-use to spread, in addition to the vulnerability exploitation. As mentioned earlier, most of the propagation in the attacks we investigated was due to the impersonation technique. This resulted in impersonation of the SYSTEM context (computer account) as well as any other accounts that were logged in to those systems (including service accounts, administrators, and standard users).

3rd phase: Process execution Obtain the means to launch the malware on the compromised machine.

This phase is not an area we recommend focusing defenses on because:

An attacker (or worm) with legitimate credentials (or impersonated session) can easily use another available process execution method.

Remote management by IT operations requires at least one process execution method to be available.

Because of this, we strongly advise organizations to focus mitigation efforts on the privilege acquisition phase (2) for both rapid destruction and targeted data theft attacks, and not prioritize blocking at the process execution phase (3).

Figure 3:Most Petya propagations were due to impersonation (credential theft)

Because of the dual channel approach to propagation, even an organization that had reached 97% of their endpoints with MS17-010 patching was infected enterprise-wide by Petya. This shows that mitigating just one vector is not enough.

The good news here is that any investment made into credential theft defenses (as well as patching and other defenses) will directly benefit your ability to stave off targeted data theft attacks because Petya simply re-used attack methods popularized in those attacks.

Attack and Recovery Experience: Learnings from Petya

Many impacted organizations were not prepared for this type of disaster in their disaster recovery plan. The key areas of learnings from real world cases of these attacks are:

Figure 4:Common learnings from rapid cyberattack recovery

Offline Recovery Required Many organizations affected by Petya found that their backup applications and Operating System (OS) deployment systems were taken out in the attack, significantly delaying their ability to recover business operations. In some cases, IT staff had to resort to printed documentation because the servers housing their recovery process documentation were also down.

Communications down Many organizations also found themselves without standard corporate communications like email. In almost all cases, company communications with employees was reliant on alternate mechanisms like WhatsApp, copy/pasting broadcast text messages, mobile phones, personal email addresses, and Twitter.

In several cases, organizations had a fully functioning Office 365 instance (SaaS services were unaffected by this attack), but users couldnt access Office 365 services because authentication was federated to the on premises Active Directory (AD), which was down.

There has been an increase in free versions of programs that purport to scan computers for various errors, and then use alarming, coercive messages to scare customers into buying a premium version of the same program. The paid version of these programs, usually called cleaner or optimizer applications, purportedly fixes the problems discovered by the free version. We find this practice problematic because it can pressure customers into making unnecessary purchase decisions.

To help protect customers from receiving such coercive messaging, we are updating our evaluation criteria to specify that programs must not use alarming or coercive messaging that can put pressure on customers into making a purchase or performing other actions. We use the evaluation criteria to determine what programs are identified as malware and unwanted software. In the future, programs that display coercive messaging will be classified as unwanted software, detected, and removed.

This update comes in addition to our other long-standing customer protection requirements designed to keep our customers from being deceived by programs that display misleading, exaggerated, or threatening messages about a systems health. In February 2016, we required cleaner and optimizer programs that purport to clean up systems and optimize performance to provide customers with detailed information about what purportedly needs to be fixed. This requirement aims to protect customers from programs that present aggregate “error results with no specific details, without providing customers with the ability to assess and validate the so-called errors.

Programs must not display alarming or coercive messages or misleading content to pressure you into paying for additional services or performing superfluous actions.

Software that coerces users may display the following characteristics, among others:

Reports errors in an exaggerated or alarming manner about the users system and requires the user to pay for fixing the errors or issues monetarily or by performing other actions such as taking a survey, downloading a file, signing up for a newsletter, etc.

Suggests that no other actions will correct the reported errors or issues

Requires the user to act within a limited period of time to get the purported issue resolved

Customer protection is our top priority. We adjust, expand, and update our evaluation criteria based on customer feedback and in order to capture the latest developments in unwanted software and other threats. We encourage our customers to submit programs that exhibit unwanted behaviors related to coercive messaging, or other unwanted or malicious behaviors in general.

In December, the Internet Governance Forum (IGF) brought the world together to talk about the internet. I tend to take a definite interest in cybersecurity, but there were many more important topics discussed. They ranged from diversity in the technology sector through to philosophy in the digital age. Cybersecurity was, nonetheless, a major theme. My colleagues and I found an agenda packed with varied sessions that sought to tackle anything from effective cooperation between CERTS, the difficulties in developing an international framework for cybersecurity norms and other issues the Digital Geneva Convention touches on, to the very real cross-border legal challenges in cloud forensics.

The real strength of the IGF is not just its breadth of topics, but also the way in which it deliberately fosters multi-stakeholder discussions. Delegates have equal voices, whether they are civil society groups, governments, or businesses. And while there were differences in opinion and perspectives, all are heard and as such contribute to richer conversations, and ultimately more valuable outcomes.

Certainly, the expectation is not that there would be immediate policy outcomes from the IGF. Ideas need time to grow and evolve. The exchanges of ideas can and does contribute to decision-making for Microsoft, and hopefully across the other participants attending. I found it particularly valuable to hear the voices and opinions of the civil society. Whether it was hearing a perspective of humanitarian actors, or understanding the challenges related to cybersecurity policy making in emerging markets.

Microsoft believes that this wider discussion among stakeholders leads to deeper understanding of the complex challenges posed by cyberspace. Thats why we took the opportunity of this years IGF to organize a series of both smaller and individualized, as well as larger discussions around the different aspects of our proposal for a Digital Geneva Convention. The discussions investigated what the industry tech accord could involve and what the civil society would like us to do as an industry, but they also looked at the feasibility of creating a convention that would protect civilians and civilian infrastructure in cyberspace from harm by states and at what the path on that decade long road would be. We will be taking these insights and ideas back with us and incorporating them into our plans for 2018.

The Digital Geneva Convention was however by far not the only cybersecurity-focused topic we engaged in. There were sessions that looked at increasing CERT capacities, encryption, the exchange of cybersecurity best practices within IGF, as well those that sought to outline the future of global cybersecurity capacity building, which we believe is essential to the worlds collective ability to respond to cyber-attacks and needed both for individual countries and at the level of regional groupings such as ASEAN and the OAS. We also previewed the research that we are planning to publish shortly that looks at the latest global cybersecurity policy and legislative trends, analyzing data from over 100 countries and highlighting increased activity across critical infrastructure policies, militarization of cyberspace continues, expansion of law enforcement powers, cybercrime legislation, and cybersecurity skills concerned. Overall, my colleagues across Microsoft contributed to over 20 different sessions and panels, including on affordable access to the internet, where we were able to outline elements of our Airband Initiative, digital civility, where we presented the results of our latest study (to be released publicly shortly), future of work and artificial intelligence, and others.

Multi-stakeholder fora like the IGF are essential to preserving an open, global, safe, secure, resilient, and interconnected Internet. What the world needs is more such broad-based, holistic policy discussions. When it comes to building policy in cyberspace, policy-makers must acknowledge the interdependence of economic, socio-cultural, technological, and governance factors. That means they should actively foster more multi-stakeholder policy development for a, learning from the IGF. For the technology sector and civil society groups, our task must be to continue to push for inclusive, open, transparent, bottom-up policy-making, and to make the most of the opportunities that do exist.

Attackers are determined to circumvent security defenses using increasingly sophisticated techniques. Fileless malware boosts the stealth and effectiveness of an attack, and two of last years major ransomware outbreaks (Petya and WannaCry) used fileless techniques as part of their kill chains.

The idea behind fileless malware is simple: If tools already exist on a device (for example PowerShell.exe or wmic.exe) to fulfill an attackers objectives, then why drop custom tools that could be flagged as malware? If an attacker can take over a process, run code in its memory space, and then use that code to call tools that are already on a device, the attack becomes more difficult to detect.

Successfully using this approach, sometimes called living off the land, is not a walk in the park. Theres another thing that attackers need to deal with: Establishing persistence. Memory is volatile, and with no files on disk, how can attackers get their code to auto-start after a system reboot and retain control of a compromised system?

Misfox: A fileless gateway to victim networks

In April 2016, a customer contacted the Microsoft Incident Response team about a case of cyber-extortion. The attackers had requested a substantial sum of money from the customer in exchange for not releasing their confidential corporate information that the attackers had stolen from the customers compromised computers. In addition, the attackers had threatened to “flatten” the network if the customer contacted law enforcement. It was a difficult situation.

The Microsoft Incident Response team investigated machines in the network, identified targeted implants, and mapped out the extent of the compromise. The customer was using a well-known third-party antivirus product that was installed on the vast majority of machines. While it was up-to-date with the latest signatures, the AV product had not detected any targeted implants.

The Microsoft team then discovered that the attackers attempted to encrypt files with ransomware twice. Luckily, those attempts failed. As it turned out, the threat to flatten the network was a plan B to monetize the attack after their plan A had failed.

Whats more, the team also discovered that the attackers had covertly persisted in the network for at least seven months through two separate channels:

The first channel involved a backdoor named Swrort.A that was deployed on several machines; this backdoor was easily detected by antivirus.

The second channel was much more subtle and interesting, because:

It did not infect any files on the device

It left no artifacts on disk

Common file scanning techniques could not detect it

Should you disable PowerShell?
No. PowerShell is a powerful and secure management tool and is important for many system and IT functions. Attackers use malicious PowerShell scripts as post-exploitation technique that can only take place after an initial compromise has already occurred. Its misuse is a symptom of an attack that begins with other malicious actions like software exploitation, social engineering, or credential theft. The key is to prevent an attacker from getting into the position where they can misuse PowerShell. For tips on mitigating PowerShell abuse, continue reading.

The second tool was a strain of fileless malware called Misfox. Once Misfox was running in memory, it:

Created a registry run key that launches a “one-liner” PowerShell cmdlet

Launched an obfuscated PowerShell script stored in the registry BLOB; the obfuscated PowerShell script contained a reflective portable executable (PE) loader that loaded a Base64-encoded PE from the registry

Misfox did not drop any executable files, but the script stored in the registry ensured the malware persisted.

Fileless techniques

Misfox exemplifies how cyberattacks can incorporate fileless components in the kill chain. Attackers use several fileless techniques that can make malware implants stealthy and evasive. These techniques include:

Reflective DLL injectionReflective DLL injection involves the manual loading of malicious DLLs into a process’ memory without the need for said DLLs to be on disk. The malicious DLL can be hosted on a remote attacker-controlled machine and delivered through a staged network channel (for example, Transport Layer Security (TLS) protocol), or embedded in obfuscated form inside infection vectors like macros and scripts. This results in the evasion of the OS mechanism that monitors and keeps track of loading executable modules. An example of malware that uses Reflective DLL injection is HackTool:Win32/Mikatz!dha.

Memory exploits
Adversaries use fileless memory exploits to run arbitrary code remotely on victim machines. For example, the UIWIX threat uses the EternalBlue exploit, which was used by both Petya and WannaCry, and has been observed to install the DoublePulsar backdoor, which lives entirely in the kernel’s memory (SMB Dispatch Table). Unlike Petya and Wannacry, UIWIX does not drop any files on disk.

Script-based techniques
Scripting languages provide powerful means for delivering memory-only executable payloads. Script files can embed encoded shellcodes or binaries that they can decrypt on the fly at run time and execute via .NET objects or directly with APIs without requiring them to be written to disk. The scripts themselves can be hidden in the registry (as in the case of Misfox), read from network streams, or simply run manually in the command-line by an attacker, without ever touching the disk.

WMI persistence
Weve seen certain attackers use the Windows Management Instrumentation (WMI) repository to store malicious scripts that are then invoked periodically using WMI bindings. This article [PDF] presents very good examples.

Fileless malware-specific mitigations on Microsoft 365

Microsoft 365 brings together a set of next-gen security technologies to protect devices, SaaS apps, email, and infrastructure from a wide spectrum of attacks. The following Windows-related components from Microsoft 365 have capabilities to detect and mitigate malware that rely on fileless techniques:

Windows Defender Antivirus

Windows Defender AV blocks the vast majority of malware using generic, heuristic, and behavior-based detections, as well as local and cloud-based machine learning models. Windows Defender AV protects against fileless malware through these capabilities:

Detecting script-based techniques by leveraging AMSI, which provides the capability to inspect PowerShell and other script types, even with multiple layers of obfuscation

Detecting and remediating WMI persistence techniques by scanning the WMI repository, both periodically and whenever anomalous behavior is observed

Windows Defender Exploit Guard

Windows Defender Exploit Guard (Windows Defender EG), a new set of host intrusion prevention capabilities, helps reduce the attack surface area by locking down the device against a wide variety of attack vectors. It can help stop attacks that use fileless malware by:

Mitigating user-mode memory exploits through the Exploit protection module, which consists of a number of exploit mitigations that can be applied either at the operating system level or at the individual app level

Mitigating many script-based fileless techniques, among other techniques, through Attack Surface Reduction (ASR) rules that lock down application behavior

Tip
On top of technical controls, it is important that administrative controls related to people and processes are also in place. The use of fileless techniques that rely on PowerShell and WMI on a remote victim machine requires that the adversary has privileged access to those machines. This may be due to poor administrative practices (for example, configuring a Windows service to run in the context of a domain admin account) that can enable credential theft. Read more about Securing Privileged Access.

Windows Defender Application Control

Windows Defender Application Control (WDAC) offers a mechanism to enforce strong code Integrity policies and to allow only trusted applications to run. In the context of fileless malware, WDAC locks down PowerShell to Constrained Language Mode, which limits the extended language features that can lead to unverifiable code execution, such as direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects. This essentially mitigates PowerShell-based reflective DLL injection attacks.

Windows Defender Advanced Threat Protection

Windows Defender Advanced Threat Protection (Windows Defender ATP) is the integrated platform for our Windows Endpoint Protection (EPP) and Endpoint Detection and Response (EDR) capabilities. When it comes to post breach scenarios ATP alerts enterprise customers about highly sophisticated and advanced attacks on devices and corporate networks that other preventive protection features have been unable to defend against. It uses rich security data, advanced behavioral analytics, and machine learning to detect such attacks. It can help detect fileless malware in a number of ways, including:

Windows 10 S

Windows 10 S is a special configuration of Windows 10 that combines many of the security features of Microsoft 365 automatically configured out of the box. It reduces attack surface by only allowing apps from the Microsoft Store. In the context of fileless malware, Windows 10 S has PowerShell Constrained Language Mode enabled by default. In addition, industry-best Microsoft Edge is the default browser, and Hypervisor Code Integrity (HVCI) is enabled by default.

Rapid cyberattacks like Petya and WannaCrypt have reset our expectations on the speed and scope of damage that a cyberattack can inflict. The Microsoft Enterprise Cybersecurity Group Detection and Response team worked extensively to help customers respond to and recover from these kinds of attacks. In 2017, among the global enterprise customers that we worked with, these rapid cyberattacks took down most or all IT systems in just about one hour, resulting in $200M – 300M USD of damage at several customers. [1]

Attackers assembled several existing techniques into a new form of attack that was both:

Fast – Took about an hour to spread throughout the enterprise

Disruptive – Created very significant business disruption at global enterprises

What is a rapid cyberattack?

Rapid cyberattacks are fast, automated, and disruptivesetting them apart from the targeted data theft attacks and various commodity attacks, including commodity ransomware, that security programs typically encounter:

Figure 1: Characteristics of rapid cyberattacks

Rapid and Automated – Much like the worms of decades past (remember Nimda? SQL Slammer?), these attacks happen very rapidly because self-propagation is fully automated once the malware is launched.

Disruptive Rapid cyberattacks are designed to be disruptive to business and IT operations by encrypting data and rebooting systems.

What are the technical and business impacts of a rapid cyberattack?

From a technical perspective, this represents the near-worst case technical risk, and resulting business risk, from a cybersecurity attack. While many of us in cybersecurity have grown accustomed to and jaded with sales presentations describing doomsday scenario tactics, these attacks indisputably represent real world cases of mass business impact on organizations.

For many of the Petya victims, most or all their computers were taken down in about one hour (~62,000 servers and workstations in a global network, in one case). In these customer environments where our incident response teams were engaged, many critical business operations came to a full stop while the IT team recovered systems.

From a business perspective, some organizations suffered losses in the range $200M – 300M USD and had to change the operating results they reported to shareholders. Note that the actual level of business impact can vary by industry, organization size, existing risk management controls, and other factors. However, its clear that the monetary and resource impacts from rapid attacks can be significant.

What makes rapid cyberattacks different from other attacks?

Petya differed from several accepted attack norms, taking many defenders by surprise. Here are four of the ways it did so:

Figure 2: What made Petya different

Supply chain – One of the more unusual aspects of the Petya attack is that it used a supply chain attack to enter target environments instead of phishing or browsing, which are vastly more prevalent methods used by threat actors for most attacks. While we are seeing an emerging trend of supply chain attacks, particularly in IT supply chain components like the MEDoc application, it is still a small minority of attack volume vs. the usual phishing/browsing attack methods.

Multi-technique While Petya wasnt the first malware to automate propagation or use multiple propagation techniques, its implementation was an extremely effective combination of exploiting a powerful software vulnerability and using impersonation techniques.

Fast The propagation speed of Petya cannot be understated. Prior to AV signatures being available, it left very little time for defenders to react (detect + manually respond or detect + write automatic response rules), leaving defenders completely reliant on preventive controls under Protect function in the NIST cybersecurity frameworkand recovery processes.

Destructive Petya rebooted the system and encrypted the master file table (MFT) of the filesystem. This made it more difficult to recover individual machines, but also spared many enterprises an even worse impact because it didnt encrypt storage which wasnt accessible after this reboot (e.g. Petyas boot code didnt have SAN drivers and couldnt reach that storage).