Archive

Author Archive

Small businesses targeted by highly localized Ursnif campaign

September 6th, 2018 No comments

Cyber thieves are continuously looking for new ways to get people to click on a bad link, open a malicious file, or install a poisoned update in order to steal valuable data. In the past, they cast as wide a net as possible to increase the pool of potential victims. But attacks that create a lot of noise are often easier to spot and stop. Cyber thieves are catching on that we are watching them, so they are trying something different. Now were seeing a growing trend of small-scale, localized attacks that use specially crafted social engineering to stay under the radar and compromise more victims.

In social engineering attacks, is less really more?

A new malware campaign puts that to the test by targeting home users and small businesses in specific US cities. This was a focused, highly localized attack that aimed to steal sensitive info from just under 200 targets. Macro-laced documents masqueraded as statements from legitimate businesses. The documents are then distributed via email to target victims in cities where the businesses are located.

With Windows Defender AVs next gen defense, however, the size of the attack doesnt really matter.

Several cloud-based machine learning algorithms detected and blocked the malicious documents at the onset, stopping the attack and protecting customers from what would have been the payload, info-stealing malware Ursnif.

The map below shows the location of the targets.

Figure 1. Geographic distribution of target victims

Highly localized social engineering attack

Heres how the attack played out: Malicious, macro-enabled documents were delivered as email attachments to target small businesses and users. Each document had a file name that spoofed a legitimate business name and masqueraded as a statement from that business. In total, we saw 21 unique document file names used in this campaign.

The attackers sent these emails to intended victims in the city or general geographic area where the businesses are located. For example, the attachment named Dolan_Care_Statement.doc was sent almost exclusively to targets in Missouri. The document file name spoofs a known establishment in St. Louis. While we do not believe the establishment itself was affected or targeted by this attack, the document purports to be from the said establishment when its really not.

The intended effect is for recipients to get documents from local, very familiar business or service providers. Its part of the social engineering scheme to increase likelihood that recipients will think the document is legitimate and take the bait, when in reality it is a malicious document.

Most common lure document file names Top target cities
Dockery_FloorCovering_Statement Johnson City, TN
Kingsport, TN
Knoxville, TN
Dolan_Care_Statement St. Louis, MO
Chesterfield, MO
Lees Summit, MO
DMS_Statement Omaha, NE
Wynot, NE
Norwalk, OH
Dmo_Statement New Braunfels, TX
Seguin, TX
San Antonio, TX
DJACC_Statement Miami, FL
Flagler Beach, FL
Niles, MI
Donovan_Construction_Statement Alexandria, VA
Mclean, VA
Manassas, VA

Table 1. Top target cities of most common document file names

When recipients open the document, they are shown a message that tricks the person into enabling the macro.

Figure 2. Document tricks victim into enabling the macro

As is typical in social engineering attacks, this is not true. If the recipient does enable the macro, no content is shown. Instead the following process is launched to deobfuscate a PowerShell command.

Figure 3. Process to deobfuscate PowerShell

Figure 4. PowerShell command

The PowerShell script connects to any of 12 different URLs that all deliver the payload.

Figure 5. Deobfuscated PowerShell command

The payload is Ursnif, info-stealing malware. When run, Ursnif steals information about infected devices, as well as sensitive information like passwords. Notably, this infection sequence (i.e., cmd.exe process deobfuscates a PowerShell that in turn downloads the payload) is a common method used by other info-stealing malware like Emotet and Trickbot.

How machine learning stopped this small-scale, localized attack

As the malware campaign got under way, four different cloud-based machine learning models gave the verdict that the documents were malicious. These four models are among a diverse set of models that help ensure we catch a wide range of new and emerging threats. Different models have different areas of expertise; they use different algorithms and are trained on their unique set of features.

One of the models that gave the malicious verdict is a generic model designed to detect non-portable executable (PE) threats. We have found that models like this are effective in catching social engineering attacks, which typically use non-PE files like scripts and, as is the case for this campaign, macro-laced documents.

The said non-PE model is a simple averaged perceptron algorithm that uses various features, including expert features, fuzzy hashes of various file sections, and contextual data. The simplicity of the model makes it fast, enabling it to give split-second verdicts before suspicious files could execute. Our analysis into this specific model showed that the expert features and fuzzy hashes had the biggest impact in the models verdict and the eventual blocking of the attack.

Figure 6. Impact of features used by one ML model that detected the attack

Next-generation protection against malware campaigns regardless of size

Machine learning and artificial intelligence power Windows Defender AV to detect and stop new and emerging attacks before they can wreak havoc. Every day, we protect customers from millions of distinct, first-seen malware. Our layered approach to intelligent, cloud-based protection employs a diverse set of machine learning models designed to catch the wide range of threats: from massive malware campaigns to small-scale, localized attacks.

The latter is a growing trend, and we continue to watch the threat landscape to keep machine learning effective against attacks. In a recent blog post, we discussed how we continue to harden machine learning defenses.

Windows Defender AV delivers the next-gen protection capabilities in the Windows Defender Advanced Threat Protection (Windows Defender ATP). Windows Defender ATP integrates attack surface reduction, next-gen protection, endpoint detection and response (EDR), automatic investigation and response, security posture, and advanced hunting capabilities. .

Because of this integration, antivirus detections, such as those related to this campaign, are surfaced in Windows Defender Security Center. Using EDR capabilities, security operations teams can then investigate and respond to the incident. Attack surface reduction rules also block this campaign, and these detections are likewise surfaced in Windows Defender ATP.To test how Windows Defender ATP can help your organization detect, investigate, and respond to advanced attacks, sign up for a free trial.

Across the whole Microsoft 365 threat protection, detections and other security signals are shared among Office 365 ATP, Windows Defender ATP, and Azure ATP. In this Ursnif campaign, the antivirus detection also enables the blocking of related emails in Office 365. This demonstrates how signal sharing and orchestration of remediation across solutions in Microsoft 365 results in better integrated threat protection.

 

 

Bhavna Soman
Windows Defender Research

 

Indicators of compromise (IOCs)

Infector:

Hashes
407a6c99581f428634f9d3b9ec4b79f79c29c79fdea5ea5e97ab3d280b2481a1
77bee1e5c383733efe9d79173ac1de83e8accabe0f2c2408ed3ffa561d46ffd7
e9426252473c88d6a6c5031fef610a803bce3090b868d9a29a38ce6fa5a4800a
f8de4ebcfb8aa7c7b84841efd9a5bcd0935c8c3ee8acf910b3f096a5e8039b1f

File names
CSC_Statement.doc
DBC_Statement.doc
DDG_Statement.doc
DJACC_Statement.doc
DKDS_Statement.doc
DMII_Statement.doc
dmo_statement.doc
DMS_Statement.doc
Dockery_Floorcovering_Statement.doc
Docktail_Bar_Statement.doc
doe_statement.doc
Dolan_Care_Statement.doc
Donovan_Construction_Statement.doc
Donovan_Engineering_Statement.doc
DSD_Statement.doc
dsh_statement.doc
realty_group_statement.doc
statement.doc
tri-lakes_motors_statement.doc
TSC_Statement.doc
UCP_Statement.doc

Payload (Ursnif)

Hashes
31835c6350177eff88265e81335a50fcbe0dc46771bf031c836947851dcebb4f
bd23a2eec4f94c07f4083455f022e4d58de0c2863fa6fa19d8f65bfe16fa19aa
75f31c9015e0f03f24808dca12dd90f4dfbbbd7e0a5626971c4056a07ea1b2b9
070d70d39f310d7b8842f645d3ba2d44b2f6a3d7347a95b3a47d34c8e955885d
15743d098267ce48e934ed0910bc299292754d02432ea775957c631170778d71

URLs
hxxp://vezopilan[.]com/tst/index[.]php?l=soho6[.]tkn
hxxp://cimoselin[.]com/tst/index[.]php?l=soho2[.]tkn
hxxp://cimoselin[.]com/tst/index[.]php?l=soho4[.]tkn
hxxp://vedoriska[.]com/tst/index[.]php?l=soho6[.]tkn
hxxp://baberonto[.]com/tst/index[.]php?l=soho3[.]tkn

hxxp://hertifical[.]com/tst/index[.]php?l=soho8[.]tkn
hxxp://hertifical[.]com/tst/index[.]php?l=soho6[.]tkn
hxxp://condizer[.]com/tst/index[.]php?l=soho1[.]tkn
hxxp://vezeronu[.]com/tst/index[.]php?l=soho2[.]tkn
hxxp://vezeronu[.]com/tst/index[.]php?l=soho5[.]tkn

hxxp://zedrevo[.]com/tst/index[.]php?l=soho8[.]tkn
hxxp://zedrevo[.]com/tst/index[.]php?l=soho10[.]tkn

*Note: The first four domains above are all registered in Russia and are hosted on the IP address 185[.]212[.]44[.]114. The other domains follow the same URL pattern and are also pushing Ursnif, but no registration info is available.

 

 

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Partnering with the industry to minimize false positives

August 16th, 2018 No comments

Every day, antivirus capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP) protect millions of customers from threats. To effectively scale protection, Windows Defender ATP uses intelligent systems that combine multiple layers of machine learning models, behavior-based detection algorithms, generics, and heuristics that make a verdict on suspicious files, most of the time in a fraction of a second.

This multilayered approach allows us to proactively protect customers in real-time, whether in the form of stopping massive malware outbreaks or detecting limited sophisticated cyberattacks. This quality of antivirus capabilities is reflected in the consistently high scores that Windows Defender ATP gets in independent tests and the fact that our antivirus solution is the most deployed in the enterprise.

The tradeoff of an intelligent, scalable approach is that some of our more aggressive classifiers from time to time misclassify normal files as malicious (false positives). While false positives are a very tiny occurrence compared to the large number of malware we correctly identify (true positives) and protect customers from, we are aware of the impact that misclassified files might have. Keeping false positives at a minimum is an equally important quality metric that we continually work to improve on.

Avoiding false positives is a two-way street between security vendors and developers. Publishing apps to the Microsoft Store is the best way for vendors and developers to ensure their programs are not misclassified. For customers, apps from the Microsoft Store are trusted and Microsoft-verified.

Here are other ways developers can raise the level of trust by both security vendors and customers and help make sure programs and files are not inadvertently detected as malware.

Digitally sign files

Digital signatures are an important way to ensure the integrity of software. By verifying the identity of the software publisher, a signature assures customers that they know who provided the software theyre installing or running. Digital signatures also assure customers that the software they received is in the same condition as when the publisher signed it and the software has not been tampered with.

Code signing does not necessarily guarantee the quality or functionality of software. Digitally signed software can still contain flaws or security vulnerabilities. However, because software vendors reputations are based on the quality of their code, there is an incentive to fix these issues.

We use the reputation of digital certificates to help determine the reputation of files signed by them. The reverse is also true: we use the reputation of digitally signed files to determine the reputation of the digital certificates they are signed with. One of the most effective ways for developers to reduce the chances of their software being detected as malware is it to digitally sign files with a reputable certificate.

The second part of reducing the risk of unintended detection is to build a good reputation on that certificate. Microsoft uses many factors to determine the reputation of a certificate, but the most important are the files that are signed by it. If all the files using a certificate have good reputation and the certificate is valid, then the certificate keeps a good reputation.

Extended validation (EV) code signing is a more advanced version of digital certificates and requires a more rigorous vetting and authentication process. This process requires a more comprehensive identity verification and authentication process for each developer. The EV code signing certificates require the use of hardware to sign applications. This hardware requirement is an additional protection against theft or unintended use of code signing certificates. Programs signed by an EV code signing certificate can immediately establish reputation with Windows Defender ATP even if no prior reputation exists for that file or publisher.

Keep good reputation

To gain positive reputation on multiple programs and files, developers sign files with a digital certificate with positive reputation. However, if one of the files gains poor reputation (e.g., detected as malware) or if the certificate was stolen and used to sign malware, then all of the files that are signed with that certificate will inherit the poor reputation. This situation could lead to unintended detection. This framework is implemented this way to prevent the misuse of reputation sharing.

We thus advise developers to not share certificates between programs or other developers. This advice particularly holds true for programs that incorporate bundling or use advertising or freemium models of monetization. Reputation accruesif a software bundler includes components that have poor reputation, the certificate that bundler is signed with gets the poor reputation.

Be transparent and respect users ability to choose

Malware threats use a variety of techniques to hide. Some of these techniques include file obfuscation, being installed in nontraditional install locations, and using names that dont reflect that purpose of the software.

Customers should have choice and control over what happens on their devices. Using nontraditional install locations or misleading software names reduce user choice and control.

Obfuscation has legitimate uses, and some forms of obfuscation are not considered malicious. However, many techniques are only employed to evade antivirus detection. Developers should refrain from using non-commercial packers and obfuscation software.

When programs employ malware-like techniques, they trigger flags in our detection algorithms and greatly increase the chances of false positives.

Keep good company

Another indicator that can influence the reputation of a file are the other programs the file is associated with. This association can come from what the program installs, what is installed at the same time as the program, or what is seen on the same machines as the file. Not all of these associations directly lead to detections, however, if a program installs other programs or files that have poor reputation, then by association that program gains poor reputation.

Understand the detection criteria

Microsofts policy aims to protect customers against malicious software while minimizing the restrictions on developers. The diagram below demonstrates the high-level evaluation criteria Microsoft uses for classifying files:

  • Malicious software: Performs malicious actions on a computer
  • Unwanted software: Exhibits the behavior of adware, browser modifier, misleading, monitoring tool, or software bundler
  • Potentially unwanted application (PUA): Exhibits behaviors that degrade the Windows experience
  • Clean: We trust the file is not malicious, is not inappropriate for an enterprise environment, and does not degrade the Windows experience

These evaluation criteria describe the characteristics and behavior of malware and potentially unwanted applications and guide the proper identification of threats. Developers should make sure their programs and files dont demonstrate undesirable characteristics or behavior to minimize chances their programs are not misclassified.

Challenging a detection decision

If you follow these pieces of advice and we unintentionally detect your file, you can help us fix the issue by reporting it through the Windows Defender Security Intelligence portal.

Customer protection is our top priority. We deliver this through Windows Defender ATPs unified endpoint security platform. Helping Microsoft maintain high-quality protection benefits customers and developers alike, allowing for an overall productive and secure computing experience.

 

 

Michael Johnson

Windows Defender Research

 

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Categories: cybersecurity, Tips & Talk Tags:

Protecting the protector: Hardening machine learning defenses against adversarial attacks

Harnessing the power of machine learning and artificial intelligence has enabled Windows Defender Advanced Threat Protection (Windows Defender ATP) next-generation protection to stop new malware attacks before they can get started often within milliseconds. These predictive technologies are central to scaling protection and delivering effective threat prevention in the face of unrelenting attacker activity.

Consider this: On a recent typical day, 2.6 million people encountered newly discovered malware in 232 different countries (Figure 1). These attacks were comprised of 1.7 million distinct, first-seen malware and 60% of these campaigns were finished within the hour.

Figure 1. A single day of malware attacks: 2.6M people from 232 countries encountering malware

While intelligent, cloud-based approaches represent a sea change in the fight against malware, attackers are not sitting idly by and letting advanced ML and AI systems eat their Bitcoin-funded lunch. If they can find a way to defeat machine learning models at the heart of next-gen AV solutions, even for a moment, theyll gain the breathing room to launch a successful campaign.

Today at Black Hat USA 2018, in our talk Protecting the Protector: Hardening Machine Learning Defenses Against Adversarial Attacks, we presented a series of lessons learned from our experience investigating attackers attempting to defeat our ML and AI protections. We share these lessons in this blog post; we use a case study to demonstrate how these same lessons have hardened Microsofts defensive solutions in the real world. We hope these lessons will help provide defensive strategies on deploying ML in the fight against emerging threats.

Lesson: Use a multi-layered approach

In our layered ML approach, defeating one layer does not mean evading detection, as there are still opportunities to detect the attack at the next layer, albeit with an increase in time to detect. To prevent detection of first-seen malware, an attacker would need to find a way to defeat each of the first three layers in our ML-based protection stack.

Figure 2. Layered ML protection

Even if the first three layers were circumvented, leading to patient zero being infected by the malware, the next layers can still uncover the threat and start protecting other users as soon as these layers reach a malware verdict.

Lesson: Leverage the power of the cloud

ML models trained on the backend and shipped to the client are the first (and fastest) layer in our ML-based stack. They come with some drawbacks, not least of which is that an attacker can take the model and apply pressure until it gives up its secrets. This is a very old trick in the malware authors playbook: iteratively tweak prospective threats and keep scanning it until its no longer detected, then unleash it.

Figure 3. Client vs. cloud models

With models hosted in the cloud, it becomes more challenging to brute-force the model. Because the only way to understand what the models may be doing is to keep sending requests to the cloud protection system, such attempts to game the system are out in the open and can be detected and mitigated in the cloud.

Lesson: Use a diverse set of models

In addition to having multiple layers of ML-based protection, within each layer we run numerous individual ML models trained to recognize new and emerging threats. Each model has its own focus, or area of expertise. Some may focus on a specific file type (for example, PE files, VBA macros, JavaScript, etc.) while others may focus on attributes of a potential threat (for example, behavioral signals, fuzzy hash/distance to known malware, etc.). Different models use different ML algorithms and train on their own unique set of features.

Figure 4. Diversity of machine learning models

Each stand-alone model gives its own independent verdict about the likelihood that a potential threat is malware. The diversity, in addition to providing a robust and multi-faceted look at potential threats, offers stronger protection against attackers finding some underlying weakness in any single algorithm or feature set.

Lesson: Use stacked ensemble models

Another effective approach weve found to add resilience against adversarial attacks is to use ensemble models. While individual models provide a prediction scoped to a particular area of expertise, we can treat those individual predictions as features to additional ensemble machine learning models, combining the results from our diverse set of base classifiers to create even stronger predictions that are more resilient to attacks.

In particular, weve found that logistic stacking, where we include the individual probability scores from each base classifier in the ensemble feature set provides increased effectiveness of malware prediction.

Figure 5. Ensemble machine learning model with individual model probabilities as feature inputs

As discussed in detail in our Black Hat talk, experimental verification and real-world performance shows this approach helps us resist adversarial attacks. In June, the ensemble models represented nearly 12% of our total malware blocks from cloud protection, which translates into tens of thousands of computers protected by these new models every day.

Figure 6. Blocks by ensemble models vs. other cloud blocks

Case study: Ensemble models vs. regional banking Trojan

“The idea of ensemble learning is to build a prediction model by combining the strengths of a collection of simpler base models.”
— Trevor Hastie, Robert Tibshirani, Jerome Friedman

One of the key advantages of ensemble models is the ability to make a high-fidelity prediction from a series of lower-fidelity inputs. This can sometimes seem a little spooky and counter-intuitive to researchers, but uses cases weve studied show this approach can catch malware that the singular models cannot. Thats what happened in early June when a new banking trojan (detected by Windows Defender ATP as TrojanDownloader:VBS/Bancos) targeting users in Brazil was unleashed.

The attack

The attack started with spam e-mail sent to users in Brazil, directing them to download an important document with a name like Doc062108.zip inside of which was a document that is really a highly obfuscated .vbs script.

Figure 7. Initial infection chain

Figure 8. Obfuscated malicious .vbs script

While the script contains several Base64-encoded Brazilian poems, its true purpose is to:

  • Check to make sure its running on a machine in Brazil
  • Check with its command-and-control server to see if the computer has already been infected
  • Download other malicious components, including a Google Chrome extension
  • Modify the shortcut to Google Chrome to run a different malicious .vbs file

Now whenever the user launches Chrome, this new .vbs malware instead runs.

Figure 9. Modified shortcut to Google Chrome

This new .vbs file runs a .bat file that:

  • Kills any running instances of Google Chrome
  • Copies the malicious Chrome extension into %UserProfile%\Chrome
  • Launches Google Chrome with the load-extension= parameter pointing to the malicious extension

Figure 10. Malicious .bat file that loads the malicious Chrome extension

With the .bat files work done, the users Chrome instance is now running the malicious extension.

Figure 11. The installed Chrome extension

The extension itself runs malicious JavaScript (.js) files on every web page visited.

Figure 12. Inside the malicious Chrome extension

The .js files are highly obfuscated to avoid detection:

Figure 13. Obfuscated .js file

Decoding the hex at the start of the script, we can start to see some clues that this is a banking trojan:

Figure 14. Clues in script show its true intention

The .js files detect whether the website visited is a Brazilian banking site. If it is, the POST to the site is intercepted and sent to the attackers C&C to gather the users login credentials, credit card info, and other info before being passed on to the actual banking site. This activity is happening behind the scenes; to the user, theyre just going about their normal routine with their bank.

Ensemble models and the malicious JavaScript

As the attack got under way, our cloud protection service received thousands of queries about the malicious .js files, triggered by a client-side ML model that considered these files suspicious. The files were highly polymorphic, with every potential victim receiving a unique, slightly altered version of the threat:
Figure 15. Polymorphic malware

The interesting part of the story are these malicious JavaScript files. How did our ML models perform detecting these highly obfuscated scripts as malware? Lets look at one of instances. At the time of the query, we received metadata about the file. Heres a snippet:

Report time 2018-06-14 01:16:03Z
SHA-256 1f47ec030da1b7943840661e32d0cb7a59d822e400063cd17dc5afa302ab6a52
Client file type model SUSPICIOUS
File name vNSAml.js
File size 28074
Extension .js
Is PE file FALSE
File age 0
File prevalence 0
Path C:\Users\<user>\Chrome\1.9.6\vNSAml.js
Process name xcopy.exe

Figure 16 File metadata sent during query to cloud protection service

Based on the process name, this query was sent when the .bat file copied the .js files into the %UserProfile%\Chrome directory.

Individual metadata-based classifiers evaluated the metadata and provided their probability scores. Ensemble models then used these probabilities, along with other features, to reach their own probability scores:

Model Probability that file is malware
Fuzzy hash 1 0.01
Fuzzy hash 2 0.06
ResearcherExpertise 0.64
Ensemble 1 0.85
Ensemble 2 0.91

Figure 17. Probability scores by individual classifiers

In this case, the second ensemble model had a strong enough score for the cloud to issue a blocking decision. Even though none of the individual classifiers in this case had a particularly strong score, the ensemble model had learned from training on millions of clean and malicious files that this combination of scores, in conjunction with a few other non-ML based features, indicated the file had a very strong likelihood of being malware.

Figure 18. Ensemble models issue a blocking decision

As the queries on the malicious .js files rolled in, the cloud issued blocking decisions within a few hundred milliseconds using the ensemble models strong probability score, enabling Windows Defender ATPs antivirus capabilities to prevent the malicious .js from running and remove it. Here is a map overlay of the actual ensemble-based blocks of the malicious JavaScript files at the time:

Figure 19. Blocks by ensemble model of malicious JavaScript used in the attack

Ensemble ML models enabled Windows Defender ATPs next-gen protection to defend thousands of customers in Brazil targeted by the unscrupulous attackers from having a potentially bad day, while ensuring the frustrated malware authors didnt hit the big pay day they were hoping for. Bom dia.

 

Further reading on machine learning and artificial intelligence in Windows Defender ATP

Indicators of compromise (IoCs)

  • Doc062018.zip (SHA-256: 93f488e4bb25977443ff34b593652bea06e7914564af5721727b1acdd453ced9)
  • Doc062018-2.vbs (SHA-256: 7b1b7b239f2d692d5f7f1bffa5626e8408f318b545cd2ae30f44483377a30f81)
  • zobXhz.js 1f47(SHA-256: ec030da1b7943840661e32d0cb7a59d822e400063cd17dc5afa302ab6a52)

 

 

 

Randy Treit, Holly Stewart, Jugal Parikh
Windows Defender Research
with special thanks to Allan Sepillo and Samuel Wakasugui

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Categories: cybersecurity Tags:

Attack inception: Compromised supply chain within a supply chain poses new risks

A new software supply chain attack unearthed by Windows Defender Advanced Threat Protection (Windows Defender ATP) emerged as an unusual multi-tier case. Unknown attackers compromised the shared infrastructure in place between the vendor of a PDF editor application and one of its software vendor partners, making the apps legitimate installer the unsuspecting carrier of a malicious payload. The attack seemed like just another example of how cybercriminals can sneak in malware using everyday normal processes.

The plot twist: The app vendors systems were unaffected. The compromise was traceable instead to a second software vendor that hosted additional packages used by the app during installation. This turned out be an interesting and unique case of an attack involving “the supply chain of the supply chain”.

The attackers monetized the campaign using cryptocurrency miners going as far as using two variants, for good measure adding to an expanding list of malware attacks that install coin miners.

We estimate based on evidence from Windows Defender ATP that the compromise was active between January and March 2018 but was very limited in nature. Windows Defender ATP detected suspicious activity on a handful of targeted computers; Automated investigation automatically resolved the attack on these machines.

While the impact is limited, the attack highlighted two threat trends: (1) the escalating frequency of attacks that use software supply chains as threat vector, and (2) the increasing use of cryptocurrency miners as primary means for monetizing malware campaigns.

This new supply chain incident did not appear to involve nation-state attackers or sophisticated adversaries but appears to be instigated by petty cybercriminals trying to profit from coin mining using hijacked computing resources. This is evidence that software supply chains are becoming a risky territory and a point-of-entry preferred even by common cybercriminals.

Hunting down the software supply chain compromise

As with most software supply chain compromises, this new attack was carried out silently. It was one of numerous attacks detected and automatically remediated by Windows Defender ATP on a typical day.

While customers were immediately protected, our threat hunting team began an in-depth investigation when similar infection patterns started emerging across different sets of machines: Antivirus capabilities in Windows Defender ATP was detecting and blocking a coin mining process masquerading as pagefile.sys, which was being launched by a service named xbox-service.exe. Windows Defender ATP’s alert timeline showed that xbox-service.exe was installed by an installer package that was automatically downloaded from a suspicious remote server.

Figure 1. Windows Defender ATP alert for the coin miner used in this incident

A machine compromised with coin miner malware is relatively easy to remediate. However, investigating and finding the root cause of the coin miner infection without an advanced endpoint detection and response (EDR) solution like Windows Defender ATP is challenging; tracing the infection requires a rich timeline of events. In this case, Advanced hunting capabilities in Windows Defender ATP can answer three basic questions:

  • What created xbox-service.exe and pagefile.sys files on the host?
  • Why is xbox-service.exe being launched as a service with high privileges?
  • What network and process activities were seen just before xbox-service.exe was launched?

Answering these questions is painless with Windows Defender ATP. Looking at the timeline of multiple machines, our threat hunting team was able to confirm that an offending installer package (MSI) was downloaded and written onto devices through a certain PDF editor app (an alternative app to Adobe Acrobat Reader).

The malicious MSI file was installed silently as part of a set of font packages; it was mixed in with other legitimate MSI files downloaded by the app during installation. All the MSI files were clean and digitally signed by the same legitimate company except for the one malicious file. Clearly, something in the download and installation chain was subverted at the source, an indication of software supply chain attack.

Figure 2. Windows Defender ATP answers who, when, what (xbox-service.exe created right after MSI installation)

As observed in previous supply chain incidents, hiding malicious code inside an installer or updater program gives attackers the immediate benefit of having full elevated privileges (SYSTEM) on a machine. This gives malicious code the permissions to make system changes like copying files to the system folder, adding a service, and running coin mining code.

Confident with the results of our investigation, we reported findings to the vendor distributing the PDF editor app. They were unaware of the issue and immediately started investigating on their end.

Working with the app vendor, we discovered that the vendor itself was not compromised. Instead, the app vendor itself was the victim of a supply chain attack traceable to their dependency on a second software vendor that was responsible for creating and distributing the additional font packages used by the app. The app vendor promptly notified their partner vendor, who was able to identify and remediate the issue and quickly interrupted the attack.

Multi-tier software supply chain attack

The goal of the attackers was to install a cryptocurrency miner on victim machines. They used the PDF editor app to download and deliver the malicious payload. To compromise the software distribution chain, however, they targeted one of the app vendors software partners, which provided and hosted additional font packages downloaded during the apps installation.

Figure 3. Diagram of the software distribution infrastructure of the two vendors involved in this software supply chain attack

This software supply chain attack shows how cybercriminals are increasingly using methods typically associated with sophisticated cyberattacks. The attack required a certain level of reconnaissance: the attackers had to understand how the normal installation worked. They eventually found an unspecified weakness in the interactions between the app vendor and partner vendor that created an opportunity.

The attackers figured out a way to hijack the installation chain of the MSI font packages by exploiting the weakness they found in the infrastructure. Thus, even if the app vendor was not compromised and was completely unaware of the situation, the app became the unexpected carrier of the malicious payload because the attackers were able to redirect downloads.

At a high level, heres an explanation of the multi-tier attack:

  1. Attackers recreated the software partners infrastructure on a replica server that the attackers owned and controlled. They copied and hosted all MSI files, including font package, all clean and digitally signed, in the replica sever.
  2. The attackers decompiled and modified one MSI file, an Asian fonts pack, to add the malicious payload with the coin mining code. With this package tampered with, it is no longer trusted and signed.
  3. Using an unspecified weakness (which does not appear to be MITM or DNS hijack), the attackers were able to influence the download parameters used by the app. The parameters included a new download link that pointed to the attacker server.
  4. As a result, for a limited period, the link used by the app to download MSI font packages pointed to a domain name registered with a Ukrainian registrar in 2015 and pointing to a server hosted on a popular cloud platform provider. The app installer from the app vendor, still legitimate and not compromised, followed the hijacked links to the attackers replica server instead of the software partners server.

While the attack was active, when the app reached out to the software partners server during installation, it was redirected to download the malicious MSI font package from the attackers replica server. Thus, users who downloaded and installed the app also eventually installed the coin miner malware. After, when the device restarts, the malicious MSI file is replaced with the original legitimate one, so victims may not immediately realize the compromise happened. Additionally, the update process was not compromised, so the app could properly update itself.

Windows Defender ATP customers were immediately alerted of the suspicious installation activity carried out by the malicious MSI installer and by the coin miner binary, and the threat was automatically remediated.

Figure 4. Windows Defender ATP alert process tree for download and installation of MSI font packages: all legitimate, except for one

Since the compromise involved a second-tier software partner vendor, the attack could potentially expand to customers of other app vendors that share the same software partner. Based on PDF application names hardcoded by the attackers in the poisoned MSI file, we have identified at least six additional app vendors that may be at risk of being redirected to download installation packages from the attackers server. While we were not able to find evidence that these other vendors distributed the malicious MSI, the attackers were clearly operating with a broader distribution plot in mind.

Another coin miner malware campaign

The poisoned MSI file contained malicious code in a single DLL file that added a service designed to run a coin mining process. The said malware, detected as Trojan:Win64/CoinMiner, hid behind the name xbox-service.exe. When run, this malware consumed affected machines computing resources to mine Monero coins.

Figure 5. Malicious DLL payload extracted from the MSI installer

Another interesting aspect of the DLL payload is that during the malware installation stage, it tries to modify the Windows hosts file so that the infected machine cant communicate with the update servers of certain PDF apps and security software. This is an attempt to prevent remote cleaning and remediation of affected machines.

Figure 6. Preventing further download of updates from certain PDF app vendors

Inside the DLL, we also found some traces of an alternative form of coin mining: browser scripts. Its unclear if this code was the attackers potential secondary plan or simply a work in progress to add one more way to maximize coin mining opportunities. The DLL contained strings and code that may be used to launch a browser to connect to the popular Coinhive library to mine Monero coins.

Figure 7. Browser-based coin mining script

Software supply chain attacks: A growing industry problem

In early 2017, we discovered operation WilySupply, an attack that compromised a text editors software updater to install a backdoor on targeted organizations in the financial and IT sectors. Several weeks later, another supply chain attack made headlines by initiating a global ransomware outbreak. We confirmed speculations that the update process for a tax accounting software popular in Ukraine was the initial infection vector for the Petya ransomware. Later that same year, a backdoored version of CCleaner, a popular freeware tool, was delivered from a compromised infrastructure. Then, in early 2018, we uncovered and stopped a Dofoil outbreak that poisoned a popular signed peer-to-peer application to distribute a coin miner.

These are just some of many similar cases of supply chain attacks observed in 2017 and 2018. We predict, as many other security researchers do, that this worrisome upward trend will continue.

Figure 8. Software supply chain attacks trends (source: RSA Conference 2018 presentation “The Unexpected Attack Vector: Software Updaters“)

The growing prevalence of supply chain attacks may be partly attributed to hardened modern platforms like Windows 10 and the disappearance of traditional infection vectors like browser exploits. Attackers are constantly looking for the weakest link; with zero-day exploits becoming too expensive to buy or create (exploit kits are at their historically lowest point), attackers search for cheaper alternative entry points like software supply chains compromise. Benefiting from unsafe code practices, unsecure protocols, or unprotected server infrastructure of software vendors to facilitate these attacks.

The benefit for attackers is clear: Supply chains can offer a big base of potential victims and can result in big returns. Its been observed targeting a wide range of software and impacting organizations in different sectors. Its an industry-wide problem that requires attention from multiple stakeholders – software developers and vendors who write the code, system admins who manage software installations, and the information security community who find these attacks and create solutions to protect against them, among others.

For further reading, including a list of notable supply chain attacks, check out our RSA Conference 2018 presentation on the topic of software supply chain attack trends: The Unexpected Attack Vector: Software Updaters.

Recommendations for software vendors and developers

Software vendors and developers need to ensure they produce secure as well as useful software and services. To do that, we recommend:

  • Maintain a highly secure build and update infrastructure.

    • Immediately apply security patches for OS and software.
    • Implement mandatory integrity controls to ensure only trusted tools run.
    • Require multi-factor authentication for admins.

  • Build secure software updaters as part of the software development lifecycle.

    • Require SSL for update channels and implement certificate pinning.
    • Sign everything, including configuration files, scripts, XML files, and packages.
    • Check for digital signatures, and dont let the software updater accept generic input and commands.

  • Develop an incident response process for supply chain attacks.

    • Disclose supply chain incidents and notify customers with accurate and timely information.

Defending corporate networks against supply chain attacks

Software supply chain attacks raise new challenges in security given that they take advantage of common everyday tasks like software installation and update. Given the increasing prevalence of these types of attacks, organizations should investigate the following security solutions:

  • Adopt a walled garden ecosystem for devices, especially for critical systems.Windows 10 in S mode is designed to allow only apps installed from the Microsoft Store, ensuring Microsoft-verified security
  • Deploy strong code integrity policies.Application control can be used to restrict the applications that users are allowed to run. It also restricts the code that runs in the system core (kernel) and can block unsigned scripts and other forms of untrusted code for customers who cant fully adopt Windows 10 in S mode.
  • Use endpoint detection and response (EDR) solutions.Endpoint detection and response capabilities in Windows Defender ATP can automatically detect and remediate suspicious activities and other post-breach actions, so even when entry vector is stealthy like for software supply chain, Windows Defender ATP can help to detect and contain such incidents sooner.

In supply chain attacks, the actual compromise happens outside the network, but organizations can detect and block malware that arrive through this method. The built-in security technologies in Windows Defender Advanced Threat Protection (Windows Defender ATP) work together to create a unified endpoint security platform. For example, as demonstrated in this investigation, antivirus capabilities detected the coin mining payload. The detection was surfaced on Windows Defender ATP, where automated investigation resolved the attack, protecting customers. The rich alert timeline and advanced hunting capabilities in Windows Defender ATP showed the extent of the software supply chain attack. Through this unified platform, Windows Defender ATP delivers attack surface reduction, next-generation protection, endpoint detection and response, automated investigation and response, and advanced hunting.

 

 

Elia Florio
with Lior Ben Porat
Windows Defender ATP Research team

 

 

Indicators of compromise (IOCs)

Malicious MSI font packages:
– a69a40e9f57f029c056d817fe5ce2b3a1099235ecbb0bcc33207c9cff5e8ffd0
– ace295558f5b7f48f40e3f21a97186eb6bea39669abcfa72d617aa355fa5941c
– 23c5e9fd621c7999727ce09fd152a2773bc350848aedba9c930f4ae2342e7d09
– 69570c69086e335f4b4b013216aab7729a9bad42a6ce3baecf2a872d18d23038

Malicious DLLs embedded in MSI font packages:
– b306264d6fc9ee22f3027fa287b5186cf34e7fb590d678ee05d1d0cff337ccbf

Coin miner malware:
– fcf64fc09fae0b0e1c01945176fce222be216844ede0e477b4053c9456ff023e (xbox-service.exe)
– 1d596d441e5046c87f2797e47aaa1b6e1ac0eabb63e119f7ffb32695c20c952b (pagefile.sys)

Software supply chain download server:
– hxxp://vps11240[.]hyperhost[.]name/escape/[some_font_package].msi (IP: 91[.]235 [.]129 [.]133)

Command-and-control/coin mining:
– hxxp://data28[.]somee [.]com/data32[.]zip
– hxxp://carma666[.]byethost12 [.]com/32[.]html

 

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

March-April 2018 test results: More insights into industry AV tests

In a previous post, in the spirit of our commitment to delivering industry-leading protection, customer choice, and transparency on the quality of our solutions, we shared insights and context into the results of AV-TESTs January-February 2018 test cycle. We released a transparency report to help our customers and the broader security community to stay informed and understand independent test results better.

In the continued spirit of these principles, wed like to share Windows Defender AVs scores in the March-April 2018 test. In this new iteration of the transparency report, we continue to investigate the relationship of independent test results and the real-world protection of antivirus solutions. We hope that you find the report insightful.

Download the complete transparency report on March-April 2018 AV-TEST results

 

Below is a summary of the transparency report:

Protection: Windows Defender AV achieved an overall Protection score of 5.5/6.0, missing 2 out of 5,680 malware samples (0.035% miss rate). With the latest results, Windows Defender AV has achieved 100% on 9 of the 12 most recent tests (combined “Real World” and “Prevalent malware”).
Usability (false positives):Windows Defender AV maintained its previous score of 5.5/6.0. Based on telemetry, most samples that Windows Defender AV incorrectly classified as malware (false positive) had very low prevalence and are not commonly used in business context. This means that it is unlikely for these false positives to affect enterprise customers.
Performance: Windows Defender AV maintained its previous score of 5.5/6.0 and continued to outperform the industry in most areas. These results reflect the investments we made in optimizing Windows Defender AV performance for high-frequency actions.

 

The report aims to help customers evaluate the extent to which test results are reflective of the quality of protection in the real world. At the same time, insights from the report continue to drive further improvements in the intelligent security services that Microsoft provides for customers.

Windows Defender AV and the rest of the built-in security technologies in Windows Defender Advanced Threat Protection (Windows Defender ATP) work together to create a unified endpoint security platform. In real customer environments, this unified security platform provides intelligent protection, detection, investigation, and response capabilities that are not currently reflected in independent tests. We tested the two malware samples that Windows Defender AV missed in the March-April 2018 test and proved that for both missed samples, at least three other components of Windows Defender ATP would detect or block the malware in a true attack scenario. You can find these details and more in the transparency report.

Download the complete transparency report on March-April 2018 AV-TEST results

 

The Windows Defender ATP security platform incorporates attack surface reduction, next-generation protection, endpoint detection and response, and advanced hunting capabilities. To see these capabilities for yourself, sign up for a 90-day trial of Windows Defender ATP, or enable Preview features on existing tenants.

 

 

 

Zaid Arafeh

Senior Program Manager, Windows Defender Research team

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Hawkeye Keylogger – Reborn v8: An in-depth campaign analysis

Much of cybercrime today is fueled by underground markets where malware and cybercriminal services are available for purchase. These markets in the deep web commoditize malware operations. Even novice cybercriminals can buy malware toolkits and other services they might need for malware campaigns: encryption, hosting, antimalware evasion, spamming, and many others.

Hawkeye Keylogger (also known as iSpy Keylogger) is an info-stealing malware thats being sold as malware-as-a-service. Over the years, the malware authors behind Hawkeye have improved the malware service, adding new capabilities and techniques. It was last used in a high-volume campaign in 2016.

This year marked the resurgence of Hawkeye. In April, malware authors started peddling a new version of the malware that they called Hawkeye Keylogger – Reborn v8. Not long after, on April 30, Office 365 Advanced Threat Protection (Office 365 ATP) detected a high-volume campaign that distributed the latest variants of this keylogger.

At the onset, Office 365 ATP blocked the email campaign and protected customers, 52% of whom are in the software and tech sector. Companies in the banking (11%), energy (8%), chemical (5%), and automotive (5%) industries are also among the top targets

Figure 1. Top industries targeted by the April 2018 Hawkeye campaign

Office 365 ATP uses intelligent systems that inspect attachments and links for malicious content to protect customers against threats like Hawkeye in real time. These automated systems include a robust detonation platform, heuristics, and machine learning models. Office 365 ATP uses intelligence from various sensors, including multiple capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP).

Windows Defender AV (a component of Windows Defender ATP) detected and blocked the malicious attachments used in the campaign in at least 40 countries. United Arab Emirates accounted for 19% of these file encounters, while the Netherlands (15%), the US (11%), South Africa (6%) and the UK (5%) make the rest of the top 5 countries that saw the lure documents used in the campaign. A combination of generic and heuristic protections in Windows Defender AV (TrojanDownloader:O97M/Donoff, Trojan:Win32/Tiggre!rfn, Trojan:Win32/Bluteal!rfn, VirTool:MSIL/NetInject.A) ensured these threats are blocked in customer environments.

Figure 2. Top countries that encountered malicious documents used in the Hawkeye campaign

As part of our job to protect customers from malware attacks, Office 365 ATP researchers monitor malware campaigns like Hawkeye and other developments in the cybercriminal landscape. Our in-depth investigation into malware campaigns like Hawkeye and many others adds to the vast threat intelligence we get from the Microsoft Intelligent Security Graph, which enables us to continuously raise the bar in security. Through the Intelligent Security Graph, security technologies in Microsoft 365 share signals and detections, allowing these technologies to automatically update protection and detection mechanisms, as well as orchestrate remediation across Microsoft 365.

Figure 3. Microsoft 365 threat protection against Hawkeye

Campaign overview

Despite its name, Hawkeye Keylogger – Reborn v8 is more than a common keylogger. Over time, its authors have integrated various modules that provide advanced functionalities like stealth and detection evasion, as well as credential theft and more.

Malware services like Hawkeye are advertised and sold in the deep web, which requires anonymity networks like Tor to access, etc. Interestingly, the Hawkeye authors advertised their malware and even published tutorial videos on a website on the surface web (that has since been taken down). Even more interesting, based on underground forums, it appears the malware authors have employed intermediary resellers, an example of how cybercriminal underground business models expand and evolve.

Our investigation into the April 2018 Hawkeye campaign shows that the cybercriminals have been preparing for the operation since February, when they registered the domains they later used in the campaign.

Typical of malware campaigns, the cybercriminals undertook the following steps:

  • Built malware samples and malware configuration files using a malware builder they acquired from the underground
  • Built weaponized documents to be used a social engineering lure (possibly by using another tool bought in the underground)
  • Packed or obfuscated the samples (using a customized open-source packer)
  • Registered domains for delivery of malware
  • Launched a spam campaign (possibly using a paid spam service) to distribute the malware

Like other malware toolkits, Hawkeye comes with an admin panel that cybercriminals use to monitor and control the attack.

Figure 4: Hawkeyes admin panel

Interestingly, some of the methods used in this Hawkeye campaign are consistent with previous attacks. This suggests that the cybercriminals behind this campaign may be the same group responsible for malware operations that delivered the remote access tool (RAT) Remcos and the info-stealing bot malware Loki. The following methods were used in these campaigns:

  • Multiple documents that create a complicated, multi-stage delivery chain
  • Redirections using shortened bit.ly links
  • Use of malicious macro, VBScript, and PowerShell scripts to run the malware; the Remcos campaign employed an exploit for CVE-2017-0199 but used the same domains
  • Consistent obfuscation technique across multiple samples

Point of entry

In late April, Office 365 ATP analysts spotted a new spam campaign with the subject line RFQ-GHFD456 ADCO 5647 deadline 7th May carrying a Word document attachment named Scan Copy 001.doc. While the attachments file name extension was .doc, it was in fact a malicious Office Open XML format document, which usually uses a .docx file name extension.

In total, the campaign used four different subject lines and five attachments.

Figure 5: Sample emails used in the Hawkeye campaign

Because the attachment contains malicious code, Microsoft Word opens with a security warning. The document uses a common social engineering lure: it displays a fake message and an instruction to Enable editing and Enable content.

Figure 6: The malicious document with social engineering lure

The document contains an embedded frame that connects to a remote location using a shortened URL.

Figure 7: frame in settings.rels.xml on the document

The frame loads an .rtf file from hxxp://bit[.]ly/Loadingwaitplez, which redirects to hxxp://stevemike-fireforce[.]info/work/doc/10.doc.

Figure 8: RTF loaded as a frame inside malicious document

The RTF has an embedded malicious .xlsx file with macro as an OLE object, which in turn contains a stream named PACKAGE that contains the .xlsx contents.

The macro script is mostly obfuscated, but the URL to the malware payload is notably in plaintext.

Figure 9: Obfuscated macro entry point

De-obfuscating the entire script makes its intention clear. The first section uses PowerShell and the System.Net.WebClient object to download the malware to the path C:\Users\Public\svchost32.exe and execute it.

The macro script then terminates both winword.exe and excel.exe. In specific scenarios where Microsoft Word overrides default settings and is running with administrator privileges, the macro can delete Windows Defender AVs malware definitions. It then changes the registry to disable Microsoft Offices security warnings and safety features.

In summary, the campaigns delivery comprises of multiple layers of components that aim to evade detection and possibly complicate analysis by researchers.

Figure 10: The campaigns delivery stages

The downloaded payload, svchost32.exe, is a .NET assembly named Millionare that is obfuscated using a custom version of ConfuserEx, a well-known open-source .NET obfuscator.

Figure 11: Obfuscated .NET assembly Millionare showing some of the scrambled names

The obfuscation modifies the .NET assemblys metadata such that all the class and variable names are non-meaningful and scrambled names in Unicode. This obfuscation causes some analysis tools like .NET Reflector to show some namespaces or classes names as blank, or in some cases, display parts of the code backwards.

Figure 12: .NET Reflector presenting the code backwards due to obfuscation

Finally, the .NET binary loads an unpacked .NET assembly, which includes DLL files embedded as resources in the portable executable (PE).

Figure 13: Loading the unpacked .NET assembly during run-time

Malware loader

The DLL that initiates the malicious behavior is embedded as a resource in the unpacked .NET assembly. It is loaded in memory using process hollowing, 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.

Figure 14: In-memory unpacking of the malware using process hollowing.

Unlike previous Hawkeye variants (v7), which loaded the main payload into its own process, the new Hawkeye malware injects its code into MSBuild.exe, RegAsm.exe, and VBC.exe, which are signed executables that ship with .NET framework. This is an attempt to masquerade as a legitimate process.

Figure 15: Obfuscated calls using .NET reflection to perform process hollowing injection routine that injects the malwares main payload into RegAsm.exe

Additionally, in the previous version, the process hollowing routine was written in C. In the new version, this routine is completely rewritten as a managed .NET that calls the native Windows API.

Figure 16: Process hollowing routine implemented in .NET using native API function calls

Malware functionalities

The new Hawkeye variants created by the latest version of the malware toolkit have multiple sophisticated functions for information theft and evading detection and analysis.

Information theft

The main keylogger functionality is implemented using hooks that monitor key presses, as well as mouse clicks and window context, along with clipboard hooks and screenshot capability.

It has specific modules for extracting and stealing credentials from the following applications:

  • Beyluxe Messenger
  • Core FTP
  • FileZilla
  • Minecraft (replaced the RuneScape module in previous version)

Like many other malware campaigns, it uses the legitimate BrowserPassView and MailPassView tools to dump credentials from the browser and email client. It also has modules for taking screenshots of the desktop, as well as the webcam, if it exists.

Notably, the malware has a mechanism to visit certain URLs for click-based monetization.

Stealth and anti-analysis

On top of the processes hollowing technique, this malware uses other methods for stealth, including alternate data streams that remove mark of the web (MOTW) from the malwares downloaded files.

This malware can be configured to delay execution by any number of seconds, a technique used mainly to avoid detection by various sandboxes.
It prevents antivirus software from running using an interesting technique. It adds keys to the registry location HKLM\Software\Windows NT\Current Version\Image File Execution Options and sets the Debugger value for certain processes to rundll32.exe, which prevents execution. It targets the following processes related to antivirus and other security software:

  • AvastSvc.exe
  • AvastUI.exe
  • avcenter.exe
  • avconfig.exe
  • avgcsrvx.exe
  • avgidsagent.exe
  • avgnt.exe
  • avgrsx.exe
  • avguard.exe
  • avgui.exe
  • avgwdsvc.exe
  • avp.exe
  • avscan.exe
  • bdagent.exe
  • ccuac.exe
  • ComboFix.exe
  • egui.exe
  • hijackthis.exe
  • instup.exe
  • keyscrambler.exe
  • mbam.exe
  • mbamgui.exe
  • mbampt.exe
  • mbamscheduler.exe
  • mbamservice.exe
  • MpCmdRun.exe
  • MSASCui.exe
  • MsMpEng.exe
  • msseces.exe
  • rstrui.exe
  • spybotsd.exe
  • wireshark.exe
  • zlclient.exe

Further, it blocks access to certain domains that are usually associated with antivirus or security updates. It does this by modifying the HOSTS file. The list of domains to be blocked is determined by the attacker using a config file.

This malware protects its own processes. It blocks the command prompt, registry editor, and task manager. It does this by modifying registry keys for local group policy administrative templates. It also constantly checks active windows and renders action buttons unusable if the window title matches ProcessHacker, Process Explorer, or Taskmgr.

Meanwhile, it prevents other malware from infecting the machine. It repeatedly scans and removes any new values to certain registry keys, stops associated processes, and deletes related files.

Hawkeye attempts to avoid automated analysis. The delay in execution is designed to defeat automated sandbox analysis that allots only a certain time for malware execution and analysis. It likewise attempts to evade manual analysis by monitoring windows and exiting when it finds the following analysis tools:

  • Sandboxie
  • Winsock Packet Editor Pro
  • Wireshark

Defending mailboxes, endpoints, and networks against persistent malware campaigns

Hawkeye illustrates the continuous evolution of malware in a threat landscape fueled by the cybercriminal underground. Malware services make malware accessible to even unsophisticated operators, while simultaneously making malware more durable with advanced techniques like in-memory unpacking and abuse of .NETs CLR engine for stealth. In this blog we covered the capabilities of its latest version, Hawkeye Keylogger – Reborn v8, highlighting some of the enhancements from the previous version. Given its history, Hawkeye is likely to release a new version in the future.

Organizations should continue educating their employees about spotting and preventing social engineering attacks. After all, Hawkeyes complicated infection chain begins with a social engineering email and lure document. A security-aware workforce will go a long way in securing networks against attacks.

More importantly, securing mailboxes, endpoints, and networks using advanced threat protection technologies can prevent attacks like Hawkeye, other malware operations, and sophisticated cyberattacks.

Our in-depth analysis of the latest version and our insight into the cybercriminal operation that drives this development allow us to proactively build robust protections against both known and unknown threats.

Office 365 Advanced Threat Protection (Office 365 ATP) protects mailboxes as well as files, online storage, and applications from malware campaigns like Hawkeye. It uses a robust detonation platform, heuristics, and machine learning to inspect attachments and links for malicious content in real-time, ensuring that emails that carry Hawkeye and other threats dont reach mailboxes and devices. Learn how to add Office 365 ATP to existing Exchange or Office 365 plans.

Windows Defender Antivirus (Windows Defender AV) provides an additional layer of protection by detecting malware delivered through email, as well as other infection vectors. Using local and cloud-based machine learning, Windows Defender AVs next-gen protection can block even new and unknown threats on Windows 10 and Windows 10 in S mode.

Additionally, endpoint detection and response (EDR) capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP) expose sophisticated and evasive malicious behavior, such as those used by Hawkeye. Sign up for free Windows Defender ATP trial.

Windows Defender ATPs rich detection libraries are powered by machine learning and allows security operations teams to detect and respond to anomalous attacks in the network. For example, machine learning detection algorithms surface the following alert when Hawkeye uses a malicious PowerShell to download the payload:

Figure 16: Windows Defender ATP alert for Hawkeyes malicious PowerShell component

Windows Defender ATP also has behavior-based machine learning algorithms that detect the payload itself:

Figure 17: Windows Defender ATP alert for Hawkeyes payload

These security technologies are part of the advanced threat protection solutions in Microsoft 365. Enhanced signal sharing across services in Windows, Office 365, and Enterprise Mobility + Security through the Microsoft Intelligent Security Graph enables the automatic update of protections and orchestration of remediation across Microsoft 365.

 

 

Office 365 ATP Research

 

 

Indicators of Compromise (Ioc)

Email subject lines

  • {EXT} NEW ORDER ENQUIRY #65563879884210#
  • B/L COPY FOR SHIPMENT
  • Betreff: URGENT ENQ FOR Equipment
  • RFQ-GHFD456 ADCO 5647 deadline 7th May

Attachment file names

  • Betreff URGENT ENQ FOR Equipment.doc
  • BILL OF LADING.doc
  • NEW ORDER ENQUIRY #65563879884210#.doc
  • Scan Copy 001.doc
  • Swift Copy.doc

Domains

  • lokipanelhostingpanel[.]gq
  • stellarball[.]com
  • stemtopx[.]com
  • stevemike-fireforce[.]info

Shortened redirector links

  • hxxp://bit[.]ly/ASD8239ASdmkWi38AS (was also used in a Remcos campaign)
  • hxxp://bit[.l]y/loadingpleaswaitrr
  • hxxp://bit[.l]y/Loadingwaitplez

Files (SHA-256)

  • d97f1248061353b15d460eb1a4740d0d61d3f2fcb41aa86ca6b1d0ff6990210a – .eml
  • 23475b23275e1722f545c4403e4aeddf528426fd242e1e5e17726adb67a494e6 – .eml
  • 02070ca81e0415a8df4b468a6f96298460e8b1ab157a8560dcc120b984ba723b – .eml
  • 79712cc97a19ae7e7e2a4b259e1a098a8dd4bb066d409631fb453b5203c1e9fe – .eml
  • 452cc04c8fc7197d50b2333ecc6111b07827051be75eb4380d9f1811fa94cbc2 – .eml
  • 95511672dce0bd95e882d7c851447f16a3488fd19c380c82a30927bac875672a – .eml
  • 1b778e81ee303688c32117c6663494616cec4db13d0dee7694031d77f0487f39 – .eml
  • 12e9b955d76fd0e769335da2487db2e273e9af55203af5421fc6220f3b1f695e – .eml
  • 12f138e5e511f9c75e14b76e0ee1f3c748e842dfb200ac1bfa43d81058a25a28 – .eml
  • 9dfbd57361c36d5e4bda9d442371fbaa6c32ae0e746ebaf59d4ec34d0c429221 – .docx (stage 1)
  • f1b58fd2bc8695effcabe8df9389eaa8c1f51cf4ec38737e4fbc777874b6e752 – .rtf (stage 2)
  • 5ad6cf87dd42622115f33b53523d0a659308abbbe3b48c7400cc51fd081bf4dd – .doc
  • 7db8d0ff64709d864102c7d29a3803a1099851642374a473e492a3bc2f2a7bae – .rtf
  • 01538c304e4ed77239fc4e31fb14c47604a768a7f9a2a0e7368693255b408420 – .rtf
  • d7ea3b7497f00eec39f8950a7f7cf7c340cf9bf0f8c404e9e677e7bf31ffe7be – .vbs
  • ccce59e6335c8cc6adf973406af1edb7dea5d8ded4a956984dff4ae587bcf0a8 – .exe (packed)
  • c73c58933a027725d42a38e92ad9fd3c9bbb1f8a23b3f97a0dd91e49c38a2a43 – .exe (unpacked)

Categories: cybersecurity Tags:

Taking apart a double zero-day sample discovered in joint hunt with ESET

In late March 2018, I analyzed an interesting PDF sample found by ESET senior malware researcher Anton Cherpanov. The sample was initially reported to Microsoft as a potential exploit for an unknown Windows kernel vulnerability. During my investigation in parallel with ESET researchers, I was surprised to discover two new zero-day exploits in the same PDF. One exploit affected Adobe Acrobat and Reader, while the other exploit affected older platforms, Windows 7 and Windows Server 2008. Microsoft and Adobe have since released corresponding security updates:

The first exploit attacks the Adobe JavaScript engine to run shellcode in the context of that module. The second exploit, which does not affect modern platforms like Windows 10, allows the shellcode to escape Adobe Reader sandbox and run with elevated privileges from Windows kernel memory. ESET provided an analysis of the exploitation routines in the sample PDF.

Although the PDF sample was found in VirusTotal, we have not observed actual attacks perpetrated using these exploits. The exploit was in early development stage, given the fact that the PDF itself did not deliver a malicious payload and appeared to be proof-of-concept (PoC) code.

Finding and neutralizing a double zero-day exploit before an attacker had a chance to use it was an amazing result of the great collaboration between ESET, Microsoft, and Adobe security researchers.

Heres some more information about the exploit process. This analysis is based on a sample we found after additional hunting (SHA-256: 4b672deae5c1231ea20ea70b0bf091164ef0b939e2cf4d142d31916a169e8e01).

Exploit overview

The Adobe Acrobat and Reader exploit is incorporated in a PDF document as a malicious JPEG 2000 stream containing the JavaScript exploit code. The following diagram provides an overview of the exploit process.

Figure 1. Overview of the exploit process

As shown in the diagram, the exploit process takes place in several stages:

  1. JavaScript lays out heap spray memory.
  2. Malicious JPEG 2000 stream triggers an out-of-bounds access operation.
  3. The access operation is called upon out-of-bounds memory laid out by the heap spray.
  4. The access operation corrupts the virtual function table (vftable).
  5. The corrupted vftable transfers execution to a return-oriented programming (ROP) chain.
  6. The ROP chain transfers execution to the main shellcode.
  7. The main elevation-of-privilege (EoP) module loads through reflective DLL loading.
  8. The main PE module launches the loaded Win32k EoP exploit.
  9. When the EoP exploit succeeds, it drops a .vbs file in the Startup folder. The .vbs file appears to be proof-of-concept malware designed to download additional payloads.

Malicious JPEG 2000 stream

The malicious JPEG 2000 stream is embedded with the following malicious tags.

Figure 2. Malicious JPEG 2000 stream

The following image shows the CMAP and PCLR tags with malicious values. The length of CMAP array (0xfd) is smaller than the index value (0xff) referenced in PCLR tagsthis results in the exploitation of the out-of-bounds memory free vulnerability.

Figure 3. Out-of-bounds index of CMAP array

Combined with heap-spray technique used in the JavaScript, the out-of-bounds exploit leads to corruption of the vftable.

Figure 4. vftable corruption with ROP chain to code execution

The shellcode and portable executable (PE) module is encoded in JavaScript.

Figure 5 Shellcode in JavaScript

Reflective DLL loading

The shellcode (pseudocode shown below) loads the main PE module through reflective DLL loading, a common technique seen in advanced attacks to attempt staying undetected in memory. On Windows 10, the reflective DLL loading technique is exposed by Windows Defender Advanced Threat Protection (Windows Defender ATP).

The shellcode searches for the start of the PE record and parses PE sections, copying them to the newly allocated memory area. It then passes control to an entry point in the PE module.

Figure 6. Copying PE sections to allocated memory

Figure 7. Passing control to an entry point in the loaded DLL

Main Win32k EoP exploit

The main Win32k elevation-of-privilege (EoP) exploit runs from the loaded PE module. It appears to target machines running Windows 7 SP1 and takes advantage of the previously unreported CVE-2018-8120 vulnerability, which is not present on Windows 10 and newer products. The exploit uses a NULL page to pass malicious records and copy arbitrary data to an arbitrary kernel location. The NULL page dereference exploitation technique is also mitigated by default for x64 platforms running Windows 8 or later.

Figure 8. EoP exploit flow

Heres how the main exploit proceeds:

  1. The exploit calls NtAllocateVirtualMemory following sgdt instructions to allocate a fake data structure at the NULL page.
  2. It passes a malformed MEINFOEX structure to the SetImeInfoEx Win32k kernel function.
  3. SetImeInfoEx picks up the fake data structure allocated at the NULL page.
  4. The exploit uses the fake data structure to copy malicious instructions to +0x1a0 on the Global Descriptor Table (GDT).
  5. It calls an FWORD instruction to call into the fake GDT entry instructions.
  6. The exploit successfully calls instructions in the fake GDT entry.
  7. The instructions run shellcode allocated in user mode from kernel mode memory space.
  8. The exploit modifies the EPROCESS.Token of the shellcode process to grant SYSTEM privileges.

On Windows 10, the EPROCESS.Token modification behavior would be surfaced by Windows Defender ATP.

The malformed IMEINFOEX structure in combination with fake data at the NULL page triggers corruption of the GDT entry as shown below.

Figure 9. Corrupted GDT entry

The corrupted GDT has actual instructions that run through call gate through a call FWORD instruction.

Figure 10. Patched GDT entry instructions

After returning from these instructions, the extended instruction pointer (EIP) returns to the caller code in user space with kernel privileges. The succeeding code elevates privileges of the current process by modifying the process token to SYSTEM.

Figure 11. Replacing process token pointer

Persistence

After privilege escalation, the exploit code drops the .vbs, a proof-of-concept malware, into the local Startup folder.

Figure 12. Code that drops the .vbs file to the Startup folder

Recommended defenses

To protect against attacks leveraging the exploits found in the PDF:

While we have not seen attacks distributing the PDF, Office 365 Advanced Threat Protection (Office 365 ATP) would block emails that carry malformed PDF and other malicious attachments. Office 365 ATP uses a robust detonation platform, heuristics, and machine learning to inspect attachments and links for malicious content in real-time.

Windows 10 users are not impacted by the dual exploits, thanks to platform hardening and exploit mitigations. For attacks against Windows 10, Windows Defender Advanced Threat Protection (Windows Defender ATP) would surface kernel attacks with similar exploitation techniques that use process token modification to elevate privileges, as shown below (sample process privilege escalation alert).

Figure 13. Sample Windows Defender ATP alert for process token modification

With Advanced hunting in Windows Defender ATP, customers can hunt for related exploit activity using the following query we added to the Github repository:

Figure 14. Advanced hunting query

Windows Defender ATP provides complete endpoint protection platform (EPP) and endpoint detection response (EDR) solutions for Windows 10, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. Additional support for devices running Windows 7 and Windows 8.1 is currently in preview. Additionally, Windows Defender ATP can surface threats on macOS, Linux, and Android devices via security partners.

Windows Defender ATP integrates with other technologies in Windows, Office 365, and Enterprise Mobility + Security platforms to automatically update protection and detection and orchestrate remediation across Microsoft 365.

To experience the power of Windows Defender ATP for yourself, sign up for a free trial now.

Indicators of compromise

SHA-256: dd4e4492fecb2f3fe2553e2bcedd44d17ba9bfbd6b8182369f615ae0bd520933
SHA-1: 297aef049b8c6255f4461affdcfc70e2177a71a9
File type: PE
Description: Win32k exploit

SHA-256: 4b672deae5c1231ea20ea70b0bf091164ef0b939e2cf4d142d31916a169e8e01
SHA-1: 0d3f335ccca4575593054446f5f219eba6cd93fe
File type: PDF
Description: Test exploit

SHA-256: 0608c0d26bdf38e064ab3a4c5c66ff94e4907ccaf98281a104fd99175cdf54a8
SHA-1: c82cfead292eeca601d3cf82c8c5340cb579d1c6
File type: PDF
Description: PDF exploit testing sample (Win32k part missing)

SHA-256: d2b7065f7604039d70ec393b4c84751b48902fe33d021886a3a96805cede6475
SHA-1: edeb1de93dce5bb84752276074a57937d86f2cf7
File type: JavaScript
Description: JavaScript embedded in 0608c0d26bdf38e064ab3a4c5c66ff94e4907ccaf98281a104fd99175cdf54a8

 

 

Matt Oh
Windows Defender ATP Research

 

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

 

Building Zero Trust networks with Microsoft 365

The traditional perimeter-based network defense is obsolete. Perimeter-based networks operate on the assumption that all systems within a network can be trusted. However, todays increasingly mobile workforce, the migration towards public cloud services, and the adoption of Bring Your Own Device (BYOD) model make perimeter security controls irrelevant. Networks that fail to evolve from traditional defenses are vulnerable to breaches: an attacker can compromise a single endpoint within the trusted boundary and then quickly expand foothold across the entire network.

In 2013, a massive credit card data breach hit Target and exposed the credit card information of over 40 million customers. Attackers used malware-laced emails to steal credentials from contractors that had remote access to Targets network. They then used the stolen credentials to gain access to the network, effectively evading the perimeter defense mechanisms that Target had in place. Once inside the network, the attackers installed malware on payment systems used in Target stores across the US and stole customer credit card information.

Zero Trust networks eliminate the concept of trust based on network location within a perimeter. Instead, Zero Trust architectures leverage device and user trust claims to gate access to organizational data and resources. A general Zero Trust network model (Figure 1) typically comprises the following:

  • Identity provider to keep track of users and user-related information
  • Device directory to maintain a list of devices that have access to corporate resources, along with their corresponding device information (e.g., type of device, integrity etc.)
  • Policy evaluation service to determine if a user or device conforms to the policy set forth by security admins
  • Access proxy that utilizes the above signals to grant or deny access to an organizational resource

Figure 1. Basic components of a general Zero Trust network model

Gating access to resources using dynamic trust decisions allows an enterprise to enable access to certain assets from any device while restricting access to high-value assets on enterprise-managed and compliant devices. In targeted and data breach attacks, attackers can compromise a single device within an organization, and then use the “hopping” method to move laterally across the network using stolen credentials. A solution based on Zero Trust network, configured with the right policies around user and device trust, can help prevent stolen network credentials from being used to gain access to a network.

Zero Trust is the next evolution in network security. The state of cyberattacks drives organizations to take the assume breach mindset, but this approach should not be limiting. Zero Trust networks protect corporate data and resources while ensuring that organizations can build a modern workplace using technologies that empower employees to be productive anytime, anywhere, any which way.

Zero Trust networking based on Azure AD conditional access

Today, employees access their organization’s resources from anywhere using a variety of devices and apps. Access control policies that focus only on who can access a resource is not sufficient. To master the balance between security and productivity, security admins also need to factor in how a resource is being accessed.

Microsoft has a story and strategy around Zero Trust networking. Azure Active Directory conditional access is the foundational building block of how customers can implement a Zero Trust network approach. Conditional access and Azure Active Directory Identity Protection make dynamic access control decisions based on user, device, location, and session risk for every resource request. They combine (1) attested runtime signals about the security state of a Windows device and (2) the trustworthiness of the user session and identity to arrive at the strongest possible security posture.

Conditional access provides a set of policies that can be configured to control the circumstances in which users can access corporate resources. Considerations for access include user role, group membership, device health and compliance, mobile applications, location, and sign-in risk. These considerations are used to decide whether to (1) allow access, (2) deny access, or (3) control access with additional authentication challenges (e.g., multi-factor authentication), Terms of Use, or access restrictions. Conditional access works robustly with any application configured for access with Azure Active Directory.

Figure 2. Microsofts high-level approach to realizing Zero Trust networks using conditional access.

To accomplish the Zero Trust model, Microsoft integrates several components and capabilities in Microsoft 365: Windows Defender Advanced Threat Protection, Azure Active Directory, Windows Defender System Guard, and Microsoft Intune.

Windows Defender Advanced Threat Protection

Windows Defender Advanced Threat Protection (ATP) is an endpoint protection platform (EPP) and endpoint detection response (EDR) technology that provides intelligence-driven protection, post-breach detection, investigation, and automatic response capabilities. It combines built-in behavioral sensors, machine learning, and security analytics to continuously monitor the state of devices and take remedial actions if necessary. One of the unique ways Windows Defender ATP mitigates breaches is by automatically isolating compromised machines and users from further cloud resource access.

For example, attackers use the Pass-the-Hash (PtH) and the Pass the ticket for Kerberos techniques to directly extract hashed user credentials from a compromised device. The hashed credentials can then be used to make lateral movement, allowing attackers to leapfrog from one system to another, or even escalate privileges. While Windows Defender Credential Guard prevents these attacks by protecting NTLM hashes and domain credentials, security admins still want to know that such an attack occurred.

Windows Defender ATP exposes attacks like these and generates a risk level for compromised devices. In the context of conditional access, Windows Defender ATP assigns a machine risk level, which is later used to determine whether the client device should get a token required to access corporate resources. Windows Defender ATP uses a broad range of security capabilities and signals, including:

Windows Defender System Guard runtime attestation

Windows Defender System Guard protects and maintains the integrity of a system as it boots up and continues running. In the assume breach mentality, its important for security admins to have the ability to remotely attest the security state of a device. With the Windows 10 April 2018 Update, Windows Defender System Guard runtime attestation contributes to establishing device integrity. It makes hardware-rooted boot-time and runtime assertions about the health of the device. These measurements are consumed by Windows Defender ATP and contribute to the machine risk level assigned to the device.

The single most important goal of Windows Defender System Guard is to validate that the system integrity has not been violated. This hardware-backed high-integrity trusted framework enables customers to request a signed report that can attest (within guarantees specified by the security promises) that no tampering of the devices security state has taken place. Windows Defender ATP customers can view the security state of all their devices using the Windows Defender ATP portal, allowing detection and remediation of any security violation.

Windows Defender System Guard runtime attestation leverages the hardware-rooted security technologies in virtualization-based security (VBS) to detect attacks. On virtual secure mode-enabled devices, Windows Defender System Guard runtime attestation runs in an isolated environment, making it resistant to even a kernel-level adversary.

Windows Defender System Guard runtime attestation continually asserts system security posture at runtime. These assertions are directed at capturing violations of Windows security promises, such as disabling process protection.

Azure Active Directory

Azure Active Directory is a cloud identity and access management solution that businesses use to manage access to applications and protect user identities both in the cloud and on-premises. In addition to its directory and identity management capabilities, as an access control engine Azure AD delivers:

  • Single sign-on experience: Every user has a single identity to access resources across the enterprise to ensure higher productivity. Users can use the same work or school account for single sign-on to cloud services and on-premises web applications. Multi-factor authentication helps provide an additional level of validation of the user.
  • Automatic provisioning of application access: Users access to applications can be automatically provisioned or de-provisioned based on their group memberships, geo-location, and employment status.

As an access management engine, Azure AD makes a well-informed decision about granting access to organizational resources using information about:

  • Group and user permissions
  • App being accessed
  • Device used to sign in (e.g., device compliance info from Intune)
  • Operating system of the device being used to sign in
  • Location or IP ranges of sign-in
  • Client app used to sign in
  • Time of sign-in
  • Sign-in risk, which represents the probability that a given sign-in isnt authorized by the identity owner (calculated by Azure AD Identity Protections multiple machine learning or heuristic detections)
  • User risk, which represents the probability that a bad actor has compromised a given user (calculated by Azure AD Identity Protections advanced machine learning that leverages numerous internal and external sources for label data to continually improve)
  • More factors that we will continually add to this list

Conditional access policies are evaluated in real-time and enforced when a user attempts to access any Azure AD-connected application, for example, SaaS apps, custom apps running in the cloud, or on-premises web apps. When suspicious activity is discovered, Azure AD helps take remediation actions, such as block high-risk users, reset user passwords if credentials are compromised, enforce Terms of Use, and others.

The decision to grant access to a corporate application is given to client devices in the form of an access token. This decision is centered around compliance with the Azure AD conditional access policy. If a request meets the requirements, a token is granted to a client. The policy may require that the request provides limited access (e.g., no download allowed) or even be passed through Microsoft Cloud App Security for in-session monitoring.

Microsoft Intune

Microsoft Intune is used to manage mobile devices, PCs, and applications in an organization. Microsoft Intune and Azure have management and visibility of assets and data valuable to the organization, and have the capability to automatically infer trust requirements based on constructs such as Azure Information Protection, Asset Tagging, or Microsoft Cloud App Security.

Microsoft Intune is responsible for the enrollment, registration, and management of client devices. It supports a wide array of device types: mobile devices (Android and iOS), laptops (Windows and macOS), and employees BYOD devices. Intune combines the machine risk level provided by Windows Defender ATP with other compliance signals to determine the compliance status (isCompliant) of the device. Azure AD leverages this compliance status to block or allow access to corporate resources. Conditional access policies can be configured in Intune in two ways:

  • App-based: Only managed applications can access corporate resources
  • Device-based: Only managed and compliant devices can access corporate resources

More on how to configure risk-based conditional access compliance check in Intune.

Conditional access at work

The value of conditional access can be best demonstrated with an example. (Note: The names used in this section are fictitious, but the example illustrates how conditional access can protect corporate data and resources in different scenarios.)

SurelyMoney is one of the most prestigious financial institutions in the world, helping over a million customers carry out their business transactions seamlessly. The company uses Microsoft 365 E5 suite, and their security enterprise admins have enforced conditional access.

An attacker seeks to steal information about the companys customers and the details of their business transactions. The attacker sends seemingly innocuous e-mails with malware attachments to employees. One employee unwittingly opens the attachment on a corporate device, compromising the device. The attacker can now harvest the employees user credentials and try to access a corporate application.

Windows Defender ATP, which continuously monitors the state of the device, detects the breach and flags the device as compromised. This device information is relayed to Azure AD and Intune, which then denies the access to the application from that device. The compromised device and user credentials are blocked from further access to corporate resources. Once the device is auto-remediated by Windows Defender ATP, access is re-granted for the user on the remediated device.

This illustrates how conditional access and Windows Defender ATP work together to help prevent the lateral movement of malware, provide attack isolation, and ensure protection of corporate resources.

Azure AD applications such as Office 365, Exchange Online, SPO, and others

The executives at SurelyMoney store a lot of high-value confidential documents in Microsoft SharePoint, an Office 365 application. Using a compromised device, the attacker tries to steal these documents. However, conditional access tight coupling with O365 applications prevents this from taking place.

Office 365 applications like Microsoft Word, Microsoft PowerPoint, and Microsoft Excel allow an organizations employees to collaborate and get work done. Different users can have different permissions, depending on the sensitivity or nature of their work, the group they belong to, and other factors. Conditional access facilitates access management in these applications as they are deeply integrated with the conditional access evaluation. Through conditional access, security admins can implement custom policies, enabling the applications to grant partial or full access to requested resources.

Figure 3. Zero Trust network model for Azure AD applications

Line of business applications

SurelyMoney has a custom transaction-tracking application connected to Azure AD. This application keeps records of all transactions carried out by customers. The attacker tries to gain access to this application using the harvested user credentials. However, conditional access prevents this breach from happening.

Every organization has mission-critical and business-specific applications that are tied directly to the success and efficiency of employees. These typically include custom applications related to e-commerce systems, knowledge tracking systems, document management systems, etc. Azure AD will not grant an access token for these applications if they fail to meet the required compliance and risk policy, relying on a binary decision on whether access to resources should be granted or denied.

Figure 4. Zero Trust network model expanded for line of business apps

On-premises web applications

Employees today want to be productive anywhere, any time, and from any device. They want to work on their own devices, whether they be tablets, phones, or laptops. And they expect to be able to access their corporate on-premises applications. Azure AD Application Proxy allows remote access to external applications as a service, enabling conditional access from managed or unmanaged devices.

SurelyMoney has built their own version of a code-signing application, which is a legacy tenant application. It turns out that the user of the compromised device belongs to the code-signing team. The requests to the on-premises legacy application are routed through the Azure AD Application Proxy. The attacker tries to make use of the compromised user credentials to access this application, but conditional access foils this attempt.

Without conditional access, the attacker would be able to create any malicious application he wants, code-sign it, and deploy it through Intune. These apps would then be pushed to every device enrolled in Intune, and the hacker would be able to gain an unprecedented amount of sensitive information. Attacks like these have been observed before, and it is in an enterprises best interests to prevent this from happening.

Figure 5. Zero Trust network model for on-premises web applications

Continuous innovation

At present, conditional access works seamlessly with web applications. Zero Trust, in the strictest sense, requires all network requests to flow through the access control proxy and for all evaluations to be based on the device and user trust model. These network requests can include various legacy communication protocols and access methods like FTP, RDP, SMB, and others.

By leveraging device and user trust claims to gate access to organizational resources, conditional access provides comprehensive but flexible policies that secure corporate data while ensuring user productivity. We will continue to innovate to protect the modern workplace, where user productivity continues to expand beyond the perimeters of the corporate network.

 

 

Sumesh Kumar, Ashwin Baliga, Himanshu Soni, Jairo Cadena
Enterprise & Security

Machine learning vs. social engineering

Machine learning is a key driver in the constant evolution of security technologies at Microsoft. Machine learning allows Microsoft 365 to scale next-gen protection capabilities and enhance cloud-based, real-time blocking of new and unknown threats. Just in the last few months, machine learning has helped us to protect hundreds of thousands of customers against ransomware, banking Trojan, and coin miner malware outbreaks.

But how does machine learning stack up against social engineering attacks?

Social engineering gives cybercriminals a way to get into systems and slip through defenses. Security investments, including the integration of advanced threat protection services in Windows, Office 365, and Enterprise Mobility + Security into Microsoft 365, have significantly raised the cost of attacks. The hardening of Windows 10 and Windows 10 in S mode, the advancement of browser security in Microsoft Edge, and the integrated stack of endpoint protection platform (EPP) and endpoint detection and response (EDR) capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP) further raise the bar in security. Attackers intent on overcoming these defenses to compromise devices are increasingly reliant on social engineering, banking on the susceptibility of users to open the gate to their devices.

Modern social engineering attacks use non-portable executable (PE) files like malicious scripts and macro-laced documents, typically in combination with social engineering lures. Every month, Windows Defender AV detects non-PE threats on over 10 million machines. These threats may be delivered as email attachments, through drive-by web downloads, removable drives, browser exploits, etc. The most common non-PE threat file types are JavaScript and VBScript.

Figure 1. Ten most prevalent non-PE threat file types encountered by Windows Defender AV

Non-PE threats are typically used as intermediary downloaders designed to deliver more dangerous executable malware payloads. Due to their flexibility, non-PE files are also used in various stages of the attack chain, including lateral movement and establishing fileless persistence. Machine learning allows us to scale protection against these threats in real-time, often protecting the first victim (patient zero).

Catching social engineering campaigns big and small

In mid-May, a small-scale, targeted spam campaign started distributing spear phishing emails that spoofed a landscaping business in Calgary, Canada. The attack was observed targeting less than 100 machines, mostly located in Canada. The spear phishing emails asked target victims to review an attached PDF document.

When opened, the PDF document presents itself as a secure document that requires action a very common social engineering technique used in enterprise phishing attacks. To view the supposed secure document, the target victim is instructed to click a link within the PDF, which opens a malicious website with a sign-in screen that asks for enterprise credentials.

Phished credentials can then be used for further attacks, including CEO fraud, additional spam campaigns, or remote access to the network for data theft or ransomware. Our machine learning blocked the PDF file as malware (Trojan:Script/Cloxer.A!cl) from the get-go, helping prevent the attack from succeeding.

Figure 2. Phishing email campaign with PDF attachment

Beyond targeted credential phishing attacks, we commonly see large-scale malware campaigns that use emails with archive attachments containing malicious VBScript or JavaScript files. These emails typically masquerade as an outstanding invoice, package delivery, or parking ticket, and instruct targets of the attack to refer to the attachment for more details. If the target opens the archive and runs the script, the malware typically downloads and runs further threats like ransomware or coin miners.

Figure 3. Typical social engineering email campaign with an archive attachment containing a malicious script

Malware campaigns like these, whether limited and targeted or large-scale and random, occur frequently. Attackers go to great lengths to avoid detection by heavily obfuscating code and modifying their attack code for each spam wave. Traditional methods of manually writing signatures identifying patterns in malware cannot effectively stop these attacks. The power of machine learning is that it is scalable and can be powerful enough to detect noisy, massive campaigns, but also specific enough to detect targeted attacks with very few signals. This flexibility means that we can stop a wide range of modern attacks automatically at the onset.

Machine learning models zero in on non-executable file types

To fight social engineering attacks, we build and train specialized machine learning models that are designed for specific file types.

Building high-quality specialized models requires good features for describing each file. For each file type, the full contents of hundreds of thousands of files are analyzed using large-scale distributed computing. Using machine learning, the best features that describe the content of each file type are selected. These features are deployed to the Windows Defender AV client to assist in describing the content of each file to machine learning models.

In addition to these ML-learned features, the models leverage expert researcher-created features and other useful file metadata to describe content. Because these ML models are trained for specific file types, they can zone in on the metadata of these file types.

Figure 4. Specialized file type-specific client ML models are paired with heavier cloud ML models to classify and protect against malicious script files in real-time

When the Windows Defender AV client encounters an unknown file, lightweight local ML models search for suspicious characteristics in the files features. Metadata for suspicious files are sent to the cloud protection service, where an array of bigger ML classifiers evaluate the file in real-time.

In both the client and the cloud, specialized file-type ML classifiers add to generic ML models to create multiple layers of classifiers that detect a wide range of malicious behavior. In the backend, deep-learning neural network models identify malicious scripts based on their full file content and behavior during detonation in a controlled sandbox. If a file is determined malicious, it is not allowed to run, preventing infection at the onset.

File type-specific ML classifiers are part of metadata-based ML models in the Windows Defender AV cloud protection service, which can make a verdict on suspicious files within a fraction of a second.

Figure 5. Layered machine learning models in Windows Defender ATP

File type-specific ML classifiers are also leveraged by ensemble models that learn and combine results from the whole array of cloud classifiers. This produces a comprehensive cloud-based machine learning stack that can protect against script-based attacks, including zero-day malware and highly targeted attacks. For example, the targeted phishing attack in mid-May was caught by a specialized PDF client-side machine learning model, as well as several cloud-based machine learning models, protecting customers in real-time.

Microsoft 365 threat protection powered by artificial intelligence and data sharing

Social engineering attacks that use non-portable executable (PE) threats are pervasive in todays threat landscape; the impact of combating these threats through machine learning is far-reaching.

Windows Defender AV combines local machine learning models, behavior-based detection algorithms, generics, and heuristics with a detonation system and powerful ML models in the cloud to provide real-time protection against polymorphic malware. Expert input from researchers, advanced technologies like Antimalware Scan Interface (AMSI), and rich intelligence from the Microsoft Intelligent Security Graph continue to enhance next-generation endpoint protection platform (EPP) capabilities in Windows Defender Advanced Threat Protection.

In addition to antivirus, components of Windows Defender ATPs interconnected security technologies defend against the multiple elements of social engineering attacks. Windows Defender SmartScreen in Microsoft Edge (also now available as a Google Chrome extension) blocks access to malicious URLs, such as those found in social engineering emails and documents. Network protection blocks malicious network communications, including those made by malicious scripts to download payloads. Attack surface reduction rules in Windows Defender Exploit Guard block Office-, script-, and email-based threats used in social engineering attacks. On the other hand, Windows Defender Application Control can block the installation of untrusted applications, including malware payloads of intermediary downloaders. These security solutions protect Windows 10 and Windows 10 in S mode from social engineering attacks.

Further, Windows Defender ATP endpoint detection and response (EDR) uses the power of machine learning and AMSI to unearth script-based attacks that live off the land. Windows Defender ATP allows security operations teams to detect and mitigate breaches and cyberattacks using advanced analytics and a rich detection library. With the April 2018 Update, automated investigation and advance hunting capabilities further enhance Windows Defender ATP. Sign up for a free trial.

Machine learning also powers Office 365 Advanced Threat Protection to detect non-PE attachments in social engineering spam campaigns that distribute malware or steal user credentials. This enhances the Office 365 ATP comprehensive and multi-layered solution to protect mailboxes, files, online storage, and applications against threats.

These and other technologies power Microsoft 365 threat protection to defend the modern workplace. In Windows 10 April 2018 Update, we enhanced signal sharing across advanced threat protection services in Windows, Office 365, and Enterprise Mobility + Security through the Microsoft Intelligent Security Graph. This integration enables these technologies to automatically update protection and detection and orchestrate remediation across Microsoft 365.

 

Gregory Ellison and Geoff McDonald
Windows Defender Research

 

 

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Virtualization-based security (VBS) memory enclaves: Data protection through isolation

The escalating sophistication of cyberattacks is marked by the increased use of kernel-level exploits that attempt to run malware with the highest privileges and evade security solutions and software sandboxes. Kernel exploits famously gave the WannaCry and Petya ransomware remote code execution capability, resulting in widescale global outbreaks.

Windows 10 remained resilient to these attacks, with Microsoft constantly raising the bar in platform security to stay ahead of threat actors. Virtualization-based security (VBS) hardens Windows 10 against attacks by using the Windows hypervisor to create an environment that isolates a secure region of memory known as secure memory enclaves.

Figure 1. VBS secure memory enclaves

An enclave is an isolated region of memory within the address space of a user-mode process. This region of memory is controlled entirely by the Windows hypervisor. The hypervisor creates a logical separation between the normal world and secure world, designated by Virtual Trust Levels, VTL0 and VT1, respectively. VBS secure memory enclaves create a means for secure, attestable computation in an otherwise untrusted environment.

VBS enclaves in Microsoft SQL Server

A key technology that will leverage VBS secure memory enclaves is Microsoft SQL Server. The upcoming SQL Server secure enclave feature ensures that sensitive data stored in an SQL Server database is only decrypted and processed inside an enclave. SQL Servers use of secure enclaves allows the processing of sensitive data without exposing the data to database administrators or malware. This reduces the risk of unauthorized access and achieves separation between those who own the data (and can view it) and those who manage the data (but should have no access). To learn more about the use of secure enclaves in SQL Server, see the blog post Enabling confidential computing with Always Encrypted using enclaves.

Data protection

One of the major benefits of secure memory enclaves is data protection. Data resident in an enclave is only accessible by code running inside that enclave. This means that there is a security boundary between VTL0 and VTL1. If a process tries to read memory that is within the secure memory enclave, an invalid access exception is thrown. This happens even when a kernel-mode debugger is attached to the normal process the debugger will fail when trying to step into the enclave.

Code integrity

Code integrity is another major benefit provided by enclaves. Code loaded into an enclave is securely signed with a key; therefore, guarantees can be made about the integrity of code running within a secure memory enclave. The code running inside an enclave is incredibly restricted, but a secure memory enclave can still perform meaningful work. This includes performing computations on data that is encrypted outside the enclave but can be decrypted and evaluated in plaintext inside the enclave, without exposing the plaintext to anything other than the enclave itself. A great example of why this is useful in a multi-tenant cloud computing scenario is described in the Azure confidential computing blog post. This move allowed us to continually make significant innovations in platform security.

Attestation

Attestation is also a critical aspect of secure memory enclaves. Sensitive information, such as plaintext data or encryption keys, must only be sent to the intended enclave that must be trusted. VBS enclaves can be put into debug mode for testing but lose memory isolation. This is great for testing, but in production this impacts the security guarantees of the enclave. To ensure that a production secure enclave is never in debug mode, an attestation report is generated to state what mode the enclave is in (among various other configuration and identity parameters). This report is then verified by a trust relationship between the consumer and producer of the report.

To establish this trust, VBS enclaves can expose an enclave attestation report that is fully signed by the VBS-unique key. This can prove the relationship between the enclave and host, as well as the exact configuration of the enclave. This attestation report can be used to establish a secure channel of communication between two enclaves. In Windows this is possible simply by exchanging the report. For remote scenarios, an attestation service can use this report to establish a trust relationship between a remote enclave and a client application.

One feature that relies on secure memory enclave attestation is Windows Defender System Guard runtime attestation, which allows users to measure and attest to all interactions from the enclave to other capabilities, including areas of runtime and boot integrity.

Figure 2. Windows Defender System Guard runtime attestation

Elevating data security

There are many secure memory enclave technologies in the industry today. Each have pros and cons in capabilities. The benefit of using a VBS secure memory enclave is that there are no special hardware requirements, only that the processor supports hypervisor virtualization extensions:

Additionally, VBS enclaves do not have the same memory constraints as a hardware-based enclave, which are usually quite limited.

VBS secure memory enclaves provide hardware-rooted virtualization-based data protection and code integrity. They are leveraged for new data security capabilities, as demonstrated by Azure confidential computing and the Always Encrypted feature of Microsoft SQL Server. These are examples of the rapid innovation happening all throughout Microsoft to elevate security. This isnt the last youll hear of secure memory enclaves. As Microsoft security technologies continue to advance, we can expect secure memory enclaves to stand out in many more protection scenarios.

 

 

Maxwell Renke, Program manager, Windows

Chris Riggs, Principal Program Manager, Microsoft Offensive Security Research

 

Adding transparency and context into industry AV test results

 

Corporate Vice President Brad Anderson recently shared his insights on how Windows Defender Advanced Threat Protection (Windows Defender ATP) evolved to achieve important quality milestones. Our Windows Defender ATP team is committed to delivering industry-leading protection, customer choice, and transparency on the quality of our solutions. In the continued spirit of these principles, we want to share the results of the January-February 2018 test conducted by independent antivirus tester AV-TEST and provide a transparency report that augments the test findings with contextual information to help our customers make informed decisions about Windows Defender ATP adoption.

Download the complete transparency report on January-February 2018 test results

 

At a high-level, the transparency report shows:

Protection: Windows Defender Antivirus (Windows Defender AV) achieved a perfect score in Protection, maintaining consistently high scores in this category.
Usability (false positives): Windows Defender AV achieved an improved Usability score of 5.5/6.0. Per our telemetry, samples that Windows Defender AV incorrectly classified (false positive) had very low prevalence and are not commonly used in business context.
Performance: Windows Defender AV improved this cycle, achieving a 5.5/6.0 Performance score and outperforming the industry in almost all areas. These results reflect the investments we put in optimizing Windows Defender AV performance for high-frequency actions (e.g., application run).

 

While independent tests can help assess a security solutions capabilities and protections, it is important to understand that antivirus tests are only one part of a complete quality assessment. To truly understand the protection quality of an endpoint protection platform (EPP) and endpoint detection and response (EDR) solution like Windows Defender ATP, its entire set of capabilities must be evaluated.

For instance, while Windows Defender ATPs antivirus capability achieved a perfect overall Protection score in the January-February 2018 tests and only missed two out of thousands of samples tested, it performed even better than the results suggest. The Windows Defender Security Intelligence team tested the two missed samples against the entire Windows Defender ATP stack to assess these samples ability to infect machines in real-world enterprise environments. The team was able to confirm that the two missed samples were detected and mitigated by other components of the Windows Defender ATP stack.

 

As threats become more sophisticated, Microsoft and other security platform vendors continue evolving their product capabilities to detect threats across different attack stages. We hope to see independent testers evolve their methodologies as well. Our customers need greater transparency and optics into what an end-to-end solution can accomplish in terms of total preventive protection, including the quality of individual components like antivirus. Microsoft is highly engaged in working with several independent testers to evolve security testing to focus on end-to-end security stack testing.

Meanwhile, we continue to focus on improving our next-generation antivirus solution while at the same time delivering new innovative capabilities like attack surface reduction and hardware-based isolation, just to name a few. In the Windows 10 April 2018 Update, you can experience these new and improved capabilities in Windows Defender ATP, which provides a complete endpoint protection platform (EPP) and endpoint detection and response (EDR) solution. To see these capabilities for yourself sign up for a 90-day trial of Windows Defender ATP today, or enable Preview features on existing tenants.

 

 

Zaid Arafeh

Senior Program Manager, Windows Defender Research team

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Want better apps? You need a (agile security) hero!

If weve learned anything from the rise of Marvel Cinematic Universe, its that good things tend to happen when heroes intervene. For securing new applications, this metaphor is a useful one because security isnt always top-of-mind for scrum teams, nor is it always conducive to meeting aggressive deadlines. But in the world of software security these heroes are critical because they are risk-aware, highly skilled developers who understand software design, robust development, and the importance of architecting for resiliency.

During my session at IANS Los Angeles Information Security Forum this week about driving security into DevSecOps, I was reminded how difficult it is for company leaders who are strapped for time and resources to find, train, and integrate these heroes. While I covered topics like how to measure the maturity of a DevSecOps program, and ways to incentivize the development team to work with security, the conversation often came back to finding good people and getting them integrated into existing team processes.

Meanwhile more organizations are moving to a full continuous integration/continuous deployment (CI/CD) model for faster software development as consumer demands evolve faster than ever and expectations rise alongside the rapid deployment of new enhancements and features in the market place. While this model can help improve the speed of new technology to market, the core of its success or failure is how well scrum teams collaborate to address complex design and implementation problems. Communication is another critical component, and can be the difference between a successful launch and an insurmountable gating factor, such as needing to punch a new hole in the firewall to get a service to run. The bottom line is nobody wins when security is compromised to standup a new release.

Scrum teams need a security master to facilitate this communication. But this individual isnt a scrum dictator sent to hijack control. They should be a facilitator who works with the scrum team and product owner to drive security into the development process. This is where these individuals really start to attain hero status because they arent just defining a critical set of security requirements, they are relationship builders fostering new collaborations.

A collaborative DevSecOps security hero guides the team through general security requirements, features, functions, and architectures in an appropriate fashion and cadence that can easily be integrated into existing processes. Its important for this scope of work to be well defined and present to meet the teams Definition of Done (DoD). Specific requirements defined by individual user stories in the working code spring help speed the process by ensuring security is represented properly in the DoD. These user stories are important artifacts that can be utilized by the entire scrum team for better alignment, and ensure there are no lengthy gating gotchas at the end of the process.

For example, a common vulnerability in modern applications revolves around the improper use, or lack of use, of cryptography with encrypting sensitive data. A general requirement could be written to protect data entered in a form cryptographically that ties back to a user story about a phase-locked loop (PLL). Once the data is encrypted it can be sent to a server team with agile security experts. By writing these agile security requirements and by addressing them systematically at all levels of the development process, teams can layer in security to existing user stories more quickly, resulting in apps services, or products with less vulnerabilities.

So where do scrum teams find these heroes? The right person might be closer than you think. Often you dont need to hire an outsider or pilfer resources from the security operations center. Instead, you can evaluate in-house developers with an affinity for security, a code expert in the reverse engineering team, or anyone in the release pipeline really who is interested, engaged, and shows the acumen to be a part of what the organization is looking to accomplish. The key is once youve identified and selected this individual that you nurture them. Provide additional security training, allow them the requisite time to fully understand the current processes in play, and ensure their annual business goals reflect their security work. Remember if someone is only rewarded for speed, security will take a back seat and your apps, services, and products will suffer.

Every organization has unique challenges, so start with one team and learn what works and what doesnt work before making broad, sweeping changes. Once the process is clicking, and new security requirements are flowing into your applications, you can radiate out the agile security hero model to your other internal, and even external (sourced via a third party) teams. Implementing this model doesnt mean your code will be perfectly secure. But having a security minded advocate in the scrum makes it a lot easier to incorporate secure measures and features into new releases.

Categories: cybersecurity Tags:

Enhancing Office 365 Advanced Threat Protection with detonation-based heuristics and machine learning

Email, coupled with reliable social engineering techniques, continues to be one of the primary entry points for credential phishing, targeted attacks, and commodity malware like ransomware and, increasingly in the last few months, cryptocurrency miners.

Office 365 Advanced Threat Protection (ATP) uses a comprehensive and multi-layered solution to protect mailboxes, files, online storage, and applications against a wide range of threats. Machine learning technologies, powered by expert input from security researchers, automated systems, and threat intelligence, enable us to build and scale defenses that protect customers against threats in real-time.

Modern email attacks combine sophisticated social engineering techniques with malicious links or non-portable executable (PE) attachments like HTML or document files to distribute malware or steal user credentials. Attackers use non-PE file formats because these can be easily modified, obfuscated, and made polymorphic. These file types allow attackers to constantly tweak email campaigns to try slipping past security defenses. Every month, Office 365 ATP blocks more than 500,000 email messages that use malicious HTML and document files that open a website with malicious content.

Figure 1. Typical email attack chain

Detonation-based heuristics and machine learning

Attackers employ several techniques to evade file-based detection of attachments and blocking of malicious URLs. These techniques include multiple redirections, large dynamic and obfuscated scripts, HTML for tag manipulation, and others.

Office 365 ATP protects customers from unknown email threats in real-time by using intelligent systems that inspect attachments and links for malicious content. These automated systems include a robust detonation platform, heuristics, and machine learning models.

Detonation in controlled environments exposes thousands of signals about a file, including behaviors like dropped and downloaded files, registry manipulation for persistence and storing stolen information, outbound network connections, etc. The volume of detonated threats translate to millions of signals that need to be inspected. To scale protection, we employ machine learning technologies to sort through this massive amount of information and determine a verdict for analyzed files.

Machine learning models examine detonation artifacts along with various signals from the following:

  • Static code analysis
  • File structure anomaly
  • Phish brand impersonation
  • Threat intelligence
  • Anomaly-based heuristic detections from security researchers

Figure 2. Classifying unknown threats using detonation, heuristics, and machine learning

Our machine learning models are trained to find malicious content using hundreds of thousands of samples. These models use raw signals as features with small modifications to allow for grouping signals even when they occur in slightly different contexts. To further enhance detection, some models are built using three-gram models that use raw signals sorted by timestamps recorded during detonation. The three-gram models tend to be more sparse than raw signals, but they can act as mini-signatures that can then be scored. These types of models fill in some of the gaps, resulting in better coverage, with little impact to false positives.

Machine learning can capture and expose even uncommon threat behavior by using several technologies and dynamic featurization. Features like image similarity matching, domain reputation, web content extraction, and others enable machine learning to effectively separate malicious or suspicious behavior from the benign.

Figure 3. Machine learning expands on traditional detection capabilities

Over time, as our systems automatically process and make a verdict on millions of threats, these machine learning models will continue to improve. In the succeeding sections, well describe some interesting malware and phishing campaigns detected recently by Office 365 ATP machine learning models.

Phishing campaigns: Online banking credentials

One of the most common types of phishing attacks use HTML and document files to steal online banking credentials. Gaining access to online bank accounts is one of the easiest ways that attackers can profit from illicit activities.

The email messages typically mimic official correspondence from banks. Phishers have become very good at crafting phishing emails. They can target global banks but also localize email content for local banks.
The HTML or document attachment are designed to look like legitimate sign-in pages or forms. Online banking credentials and other sensitive information entered into these files or websites are sent to attackers. Office 365s machine learning models detect this behavior, among other signals, to determine that such attachments are malicious and block offending email messages.

Figure 4. Sample HTML files that mimic online banking sign in pages. (Click to enlarge)

Phishing campaigns: Cloud storage accounts

Another popular example of phishing campaigns uses HTML or document attachments to steal cloud storage or email account details. The email messages imply that the recipient has received a document hosted in a cloud storage service. In order to supposedly open the said document, the recipient has to enter the cloud storage or email user name and password.

This type of phishing is very rampant because gaining access to either email or cloud storage opens a lot of opportunities for attackers to access sensitive documents or compromise the victims other accounts.

Figure 5. Sample HTML files that pose as cloud storage sign in pages. (Click to enlarge)

Tax-themed phishing and malware attacks

Tax-themed social engineering attacks circulate year-round as cybercriminals take advantage of the different country and region tax schedules. These campaigns use various messages related to tax filing to convincer users to click a link or open an attachment. The social engineering messages may say the recipient is eligible for tax refund, confirm that tax payment has been completed, or declare that payments are overdue, among others.

For example, one campaign intercepted by Office 365 ATP using machine learning implied that the recipient has not completed tax filing and is due for penalty. The campaign targeted taxpayers in Colombia, where tax filing ended in October. The email message aimed to alarm taxpayers by suggesting that they have not filed their taxes.

Figure 6. Tax-themed email campaign targeting taxpayers in Colombia. The subject line translates to: You have been fined for not filing your income tax returns

The attachment is a .rar file containing an HTML file. The HTML file contains the logo of Direccin de Impuestos y Aduanas Nacionales (DIAN), the Colombianes tax and customs organization, and a link to download a file.

Figure 7. Social engineering document with a malicious link

The link points to a shortened URL hxxps://bit[.]ly/2IuYkcv that redirects to hxxp://dianmuiscaingreso[.]com/css/sanci%C3%B3n%20declaracion%20de%20renta.doc, which downloads a malicious document.

Figure 8: Malicious URL information

The malicious document carries a downloader macro code. When opened, Microsoft Word issues a security warning. In the document are instructions to Enable content, which executes the embedded malicious VBA code.

Figure 9: Malicious document with malicious macro code

If the victim falls for this social engineering attack, the macro code downloads and executes a file from hxxp://dianmuiscaingreso.com/css/w.jpg. The downloaded executable file (despite the file name) is a file injector and password-stealing malware detected by Windows Defender AV as Trojan:Win32/Tiggre!rfn.

Because Office 365 ATP machine learning detects the malicious attachment and blocks the email, the rest of the attack chain is stopped, protecting customers at the onset.

Artificial intelligence in Office 365 ATP

As threats rapidly evolve and become increasingly complex, we continuously invest in expanding capabilities in Office 365 Advanced Threat Protection to secure mailboxes from attacks. Using artificial intelligence and machine learning, Office 365 ATP can constantly scale coverage for unknown and emerging threats in-real time.

Office 365 ATPs machine learning models leverage Microsofts wide network of threat intelligence, as well as seasoned threat experts who have deep understanding of malware, cyberattacks, and attacker motivation, to combat a wide range of attacks.

This enhanced protection from Office 365 ATP contributes to and enriches the integrated Microsoft 365 threat protection, which provides intelligent, integrated, and secure solution for the modern workplace. Microsoft 365 combines the benefits and security technologies of Office 365, Windows, and Enterprise Mobility Suite (EMS) platforms.

Office 365 ATP also shares threat signals to the Microsoft Intelligent Security Graph, which uses advanced analytics to link threat intelligence and security signals across Office 365, the Windows Defender ATP stack of defenses, and other sensors. For example, when a malicious file is detected by Office 365 ATP, that threat can also be blocked on endpoints protected by Windows Defender ATP and vice versa. Connecting security data and systems allows Microsoft security technologies like Office 365 ATP to continuously improve threat protection, detection, and response.

 

 

Office 365 Threat Research

Building a world without passwords

Nobody likes passwords. They are inconvenient, insecure, and expensive. In fact, we dislike them so much that weve been busy at work trying to create a world without them a world without passwords.

In this blog, we will provide a brief insight into how we at Microsoft have been thinking about solving this problem along with details on solutions that you can try out today.

Password-less

When we think about creating a world without passwords, we want to deliver on two key promises:

  1. User promise: End-users should never have to deal with passwords in their day-to-day lives.
  2. Security promise: User credentials cannot be cracked, breached, or phished.

Passwords have been a big part of our digital lives, and to fully get rid of them, not only do we need to address all that is bad with them, we also need to acknowledge all that is good: they are familiar, portable, and easy to provision.

 

Figure 1. Passwords – Pros vs cons

At its core, our fundamental philosophy is simple: devalue the password, and replace it with something that eradicates its use for the end user and drains its value for an attacker.

Passwords have been a big part of our digital lives. To fully get rid of them, not only do we need to address all that is bad with them, we also need to acknowledge all that is good; they are familiar, portable, and can be used almost everywhere.

So how are we going about it? Well, we break this up into discrete buckets:

Figure 2: Password-less strategy

  1. Develop password-replacement offerings, i.e., replace passwords with a new set of alternatives that address the shortcomings of passwords while embracing their positive attributes.
  2. Reduce user visible password-surface area, i.e., upgrade all experiences related to the entire life-cycle of a users identity (including provisioning of an account, setting up a brand-new device, using the account/device to access apps and websites, recovery, etc.) and ensure these work with password-replacements (#1).
  3. Simulate a password-less world, i.e., enable end users and IT admins to simulate and transition into a password-less world with confidence.
  4. Eliminate passwords from the identity directory, i.e., the final frontier delete passwords from the identity directory.

For more details, watch Microsofts Guide for going password-less.

Heres a quick overview of some of the solutions that you can try out today and how they map to the strategy above.

Password-replacement offerings

Windows Hello

Heres a video that provides a quick overview of Windows Hello, how it is more secure than passwords, and some of newest enhancements.

Windows Hello is being used by over 47 million users worldwide. More than 5,000 businesses have deployed Windows Hello for Business, with adoption on over one million commercial devices.

For more details, refer to www.aka.ms/whfb

Windows Hello is an excellent replacement for passwords on personal PCs. That said, we acknowledge that there are many scenarios that involve shared PCs used by transient users and that provisioning Windows Hello is not ideal. To that end, we have been working hard on lighting up a series of portable credentials that are more suitable for such shared PC scenarios.

Microsoft Authenticator app

The Microsoft Authenticator app enables users to authenticate to their Microsoft account using their mobile phone. It is built on similar secure technology that Windows Hello uses, and packages it into an simple app on your mobile device.

Heres a video that provides a quick overview of Microsoft Authenticator App.

To download the app and learn more, please go to Microsoft Authenticator

Windows Hello and our mobile Authenticator app are both great alternatives to passwords. To create a world without password, we need an interoperable solution that works across all industry platforms and browsers.

Windows Hello and FIDO2 security keys

Microsoft has been aligned with the Fast Identity Online (FIDO) working group from the start. The alliance represents 250 organizations from various industries on a joint mission to replace passwords with an easy-to-use strong credential. With the recent ratification of FIDO2 security keys by the FIDO working group, were updating Windows Hello to enable secure authentication for many new scenarios.

For more details, please check out our latest blog, Windows Hello and FIDO2 Security Keys enable secure and easy authentication for shared devices.

Whats new in the Windows 10 April 2018 Update?

Among many new and exciting features in the Windows 10 April 2018 Update, we set out with the goal to deliver an end-to-end product experience that’s password-less ready. With Windows 10 in S mode, we are enabling our cloud users (Managed Service Account or Azure Active Directory) to be able to go through the entire life-cycle of using their Windows 10 PC with S mode enabled without ever having to enter their passwords. Thats right. Heres how you can try it out.

Windows 10 in S mode Password-less!

  1. Set up your Authenticator App

    1. Install the Microsoft Authenticator app on your mobile device.
    2. Set it up with your Managed Service Account (MSA) and/or Azure Active Directory (Azure AD) account

Note: Upgrade your default way of authenticating from using password to the Microsoft Authenticator app by clicking the Use the Microsoft Authenticator app instead on the login page.

Figure 3: Select Microsoft Authenticator as default sign-in option

  1. Set up your Windows 10 PC with S mode enabled

    1. Install the Windows 10 April 2018 Update with S mode enabled
    2. Proceed through OOBE and set up your account
    3. Use the Microsoft Authenticator app to sign-in to your account. No passwords required!

Note: If you are prompted for a password on this screen, click the Use the Microsoft Authenticator app instead link.

Figure 4: Windows 10 S OOBE with Microsoft Authenticator app

  1. Set up Windows Hello

Figure 5: Windows Hello provisioning

  1. Thats it! Your Windows10 PC is password-less! Just use your device like you normally do.

    1. Access/SSO to your apps and websites will continue to work. No passwords required!

Figure 6: Access apps and websites seamlessly

    1. You will notice that youll be required to use Windows Hello (PIN, Face, Fingerprint) for sign-in/unlocking your PC. No passwords!

Figure 7: No passwords under Sign in options for Windows

    1. The password credential provider will no longer enumerate for Windows scenarios.

In summary, you will be able to set up a brand-new device, provision Windows Hello, log in, lock/unlock, use your favorite apps and websites without ever having to enter a password!

Security Keys for Windows Hello (Private preview for Azure AD-joined shared PCs)

FIDO2 Security keys allow you to carry your credential with you and safely authenticate to an Azure AD-joined Windows 10 shared PC thats part of your organization. A user can walk up to any device belonging to the organization and authenticate in a secure way no need to enter a username and password or set-up Windows Hello beforehand.

See how it works in this video:

The Windows Hello FIDO2 Security Key feature is now in limited preview. Please let us know if you would like to be added to the waitlist.

While we still have a way to go before we can claim victory, with the incredible lineup of products and features in our portfolio along with those in the works, we are confident that we will get there soon. Please send us your comments, questions, and feedback at pwdless@microsoft.com.

 

Karanbir Singh
Principal Program Manager, Enterprise & Security

Teaming up in the war on tech support scams

(Editors note: Erik Wahlstrom spoke about the far-reaching impact of tech support scams and the need for industry-wide cooperation in his RSA Conference 2018 talk Tech Scams: Its Time to Release the Hounds.)

 

Social engineering attacks like tech support scams are so common because theyre so effective. Cybercriminals want to bilk users money. They can spend a great deal of time and energy attacking the security of a devicebrute-force passwords, develop custom and sophisticated malware, and hunt down vulnerabilities to exploit. Or they can save themselves the trouble and convince users to freely give up access to their devices and sensitive information.

Microsoft has built the most secure version of its platform in Windows 10. Core OS technologies like virtualization-based security, kernel-based mitigations, and the Windows Defender ATP stack of security defenses make it much more difficult for exploits, malware, and other threats to infect devices. Every day, machine learning and artificial intelligence in Windows Defender ATP protect millions of devices from malware outbreaks and cyberattacks. In many cases, customers may not even know they were protected. Windows 10 S, a special configuration of Windows 10, takes this even further by only running apps from the Microsoft Store, effectively preventing the vast majority of attacks.

Protect yourself from tech support scams

  • Note that Microsoft does not send unsolicited email messages or make unsolicited phone calls to request for personal or financial information, or fix your computer.
  • 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.
  • Dont call the number in pop-ups. Microsofts error and warning messages never include a phone number.

The Windows 10 security stack greatly increases the cost for attackers. Many cybercriminals instead choose to target the humans in front of the PCs. It can sometimes be easier to convince users to willingly share their passwords, account info, or to install hazardous apps onto their device than to develop malware and steal info unnoticed.

Scammers continue to capitalize on the proven effectiveness of social engineering to perpetrate tech support scams. These scams are designed to trick users into believing their devices are compromised or broken. They do this to scare or coerce victims into purchasing unnecessary support services.

To help protect customers from scammers, we continue to enhance antivirus, email, URL blocking, and browser security solutions. However, given the scale and complexity of tech support scams, how can the security industry at large work together to deal a major blow to this enduring threat?

Still a growing global problem

In 2017, Microsoft Customer Support Services received 153,000 reports from customers who encountered or fell victim to tech support scams, a 24% growth from the previous year. These reports came from 183 countries, indicating a global problem.

Approximately 15% of these customers lost money in the scam, costing them on average between $200 and $400. In some cases, victims pay a lot more. In December 2017, Microsoft received a report of a scammer emptying a bank account of 89,000 during a tech support scam in the Netherlands.

Tech support scams reported to Microsoft

In a 2016 survey sponsored by Microsoft, two in three respondents reported experiencing some form of tech support scam in the previous 12 months, with nearly one in ten losing money.

However, as with many social engineering attacks, its tricky to put an absolute number to the problem. The figures above represent reports to Microsoft. The problem is so much bigger, given that tech support scams target customers of various other devices, platforms, or software.

An organized cybercriminal enterprise

Tech support scams come in several forms, but they share a common attack plan:

Scammers initiate these social engineering attacks in many ways, including:

  • Scam websites that use various tactics including browser dialog traps, fake antivirus detecting fake threats, and fake full-screen error messages. Scammers lead potential victims to these websites through ads, search results, typosquatting and other fraudulent mechanisms.
  • Email campaigns that use phishing-like techniques to trick recipients into clicking URLs or opening malicious attachments
  • Malware thats installed on computers to make system changes and display fake error messages
  • Unsolicited phone calls (also known as cold calls), which are telemarketing calls from scammers that pretend to be from a vendors support team

The complete attack chain shows that these attacks lead to the same goal of getting customers in contact with a call center. Once connected, a fake technician (an experienced scammer) convinces the victim of a problem with their device. They often scare victims with urgent problems requiring immediate action. They instruct victims to install remote administration tools (RATs), which provide the scammers access to and control over the device.

tech support scams attack chain

From this point on, scammers can make changes to the device or point out common non-critical errors, and present these as problems. For example, scammers are known to use Event Viewer to show errors or netstat to show connections to foreign IP addresses. The scammers then attempt to make the sale. With control of the device, scammers can make a compelling case about errors in the device and pressure the victim to pay.

An industry-wide problem requires industry-wide action

The tech support scam problem is far-reaching. Its impact spans various platforms, devices, software, services. Examples include:

  • Tech support scams targeting specific platforms like Windows, macOS, iOS, and Android
  • Tech support scam websites that imply a formal relationship or some sort of approval by well-known vendors
  • Fake malware detection from programs or websites that mimic various antivirus solutions
  • Customized tech support scams that tailor messages and techniques based on geography, OS, browser, or ISP

As in many forms of social engineering attacks, customer education is key. There are tell-tale signs: normal error and warning messages should not have phone numbers, most vendors dont make unsolicited phone calls to fix a device, etc. To help protect and educate Microsoft customers, we have published blogs, websites, videos, and social media campaigns on the latest tech support scam trends and tactics. We have also empowered customers to report tech support scams.

Beyond customer education, the scale and complexity of tech support scams require cooperation and broad partnerships across the industry. The Microsoft Digital Crimes Unit (DCU) works with law enforcement and other agencies to crack down on scammers.

We have further built partnerships across the ecosystem to make a significant dent on this issue:

  • Web hosting providers, which can take down verified tech support scam websites
  • Telecom networks, which can block tech support scam phone numbers
  • Browser developers, who can continuously thwart tech support scam tactics and block tech support scam websites
  • Antivirus solutions, which can detect tech support scam malware
  • Financial networks, who can help protects customers from fraudulent transactions
  • Law enforcement agencies, who can go after the crooks

We seek to continue expanding and enriching these partnerships. While we continue to help protect customers through a hardened platform and increasingly better security solutions, we believe its high time for the industry to come together and put an end to the tech support scam problem. Together, we can make our customers lives easier and safer.

 

 

Erik Wahlstrom
Windows Defender Research Project Manager

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Introducing Windows Defender System Guard runtime attestation

At Microsoft, we want users to be in control of their devices, including knowing the security health of these devices. If important security features should fail, users should be aware. Windows Defender System Guard runtime attestation, a new Windows platform security technology, fills this need.

In Windows 10 Fall Creators Update, we reorganized all system integrity features into Windows Defender System Guard. This move allowed us to continually make significant innovations in platform security. Windows Defender System Guard runtime attestation, which is built into the core Windows operating system, will soon be delivered in all editions of Windows. Windows Defender System Guard runtime attestation, like Credential Guard, takes advantage of the same hardware-rooted security technologies in virtualization-based security (VBS) to mitigate attacks in software.

Security technologies are targeted by exploits that attempt to run in the same domain of trust. For example, privileged processes are designed to provide a certain degree of isolation (at least in respect to code and data) from regular user-mode processes. The NT kernel determines whether a process is protected based on certain values held in the executive process object. Tampering with these values via a kernel exploit or with a driver (e.g., Mimikatz) can effectively disable process protection. Moving the security decision related to tampering to a separate domain of trust increases complexity for attackers.

Runtime attestation can help in many scenarios, including:

  • Providing supplementary signals for endpoint detection and response (EDR) and antivirus vendors (including full integration with the Windows Defender Advanced Threat Protection stack)
  • Detecting artifacts of kernel tampering, rootkits, and exploits
  • Protected game anti-cheat scenarios (for example, detection of process-protection bypasses that can lead to game-state modification)
  • Sensitive transactions (banking apps, trading platforms)
  • Conditional access (enabling and enhancing device security-based access policies)

With the next update to Windows 10, we are implementing the first phase of Windows Defender System Guard runtime attestation, laying the groundwork for future innovation in this area. This includes developing new OS features to support efforts to move towards a future where violations of security promises are observable and effectively communicated in the event of a full system compromise, such as through a kernel-level exploit.

Attestation and establishing trust

To introduce Windows Defender System Guard runtime attestation on a technical level, its best to begin at the most visible layer: a client API that will eventually be exposed to a relying party. (Note: We share details of the general design as its currently architected; final implementation may differ.)

We are working towards providing an API that relying parties can use to attest to the state of the device at a point in time. The API returns a runtime report that details the claims that Windows Defender System Guard runtime attestation makes about the security posture of the system. These claims include assertions, which are runtime measurements of sensitive system properties.

For the runtime report to have any significant meaning, it must be generated in a fashion that provides reasonable resistance against tampering. This gives rise to the following basic component requirements:

  1. Runtime report generation must be isolated from an attacker
  2. This isolation must be attestable
  3. The runtime report must be cryptographically signed in a manner that is irreproducible outside the isolated environment

Enter VBS enclaves. Were not going to describe these enclaves in-depth here, but its prudent to give some context. On a device with virtual secure mode (VSM) enabled, virtualization extensions of the underlying Instruction Set Architecture (ISA) are employed to logically divide the system into two (theoretically, more) separate worlds: the normal world running the NT kernel that were all familiar with and a separate secure world running a Secure Kernel (SK). We call these two logical levels of separation Virtual Trust Levels (VTLs), in this case NT being VTL-0 and SK being VTL-1.

VBS enclaves enable what can be thought of as a siloed part of a normal world VTL-0 user-mode process. All code and data in this silo live in VTL-1. Transactions in and out of an enclave are done via a well-defined API backed by VSL calls (the mechanism that NT and SK use to communicate). The result of this intricacy is that, as of Windows Fall Creators Update (1709), it is possible to execute code and hold data within an enclave such that the entire VTL-0 normal world both user-mode and kernel-mode cannot directly act upon the siloed code and data while executing and held within the enclave (in VTL-1).

From the VBS enclave, the runtime attestation component can observe and attest to a set of security properties contained in a report. For example, an app could ask Windows Defender System Guard to measure the security of the system from the hardware-backed enclave and return a report. The details in this report can be used by the app to decide whether it performs a sensitive financial transaction or display personal information.

VBS enclaves can also expose an enclave attestation report signed by a VBS-specific signing key. If Windows Defender System Guard can obtain proof that the host system is running with VSM active, it can use this proof together with a signed session report to ensure that the particular enclave is running.

As for the signature of the runtime report itself, an asymmetrical public-private key pair is generated within the enclave. The public key is signed by the Windows Defender System Guard attestation service backend to create a session certificate. In addition, the Windows Defender System Guard attestation service backend produces a signed session report containing details about the machine. These details include boot security properties, including whether the machine booted with Secure boot enabled, to ensure that the core operating system has not been jailbroken or tampered with. Finally, runtime reports are signed locally by the paired private key, which never leaves the enclave. The runtime and session reports can be verified by relying parties with little effort by verifying the report signatures against the session certificate and then ensuring that the certificate is validly signed, rooted in the relevant Microsoft CA.

Establishing the trust necessary to guarantee that the runtime report is authentic, therefore, requires the following:

  • Attesting to the boot state of the machine: the OS, hypervisor, and Secure Kernel (SK) binaries must be signed by Microsoft and configured according to a secure policy
  • Binding trust between the TPM and the health of the hypervisor to allow trust in the Measured Boot Log
  • Extracting the VSM IDKs from the Measured Boot Log and using these to verify the VBS enclave signature
  • Backend verification of the above and signing of the public component of an ephemeral key-pair generated within the enclave with a trusted CA to issue a session certificate
  • Signing of the runtime report with the ephemeral private key

Networking calls between the enclave and the Windows Defender System Guard attestation service are made from VTL-0. However, the design of the attestation protocol ensures that it is resilient against tampering even over untrusted transport mechanisms.

Numerous underlying technologies are required before the chain of trust described above can be sufficiently established. To inform a relying party to the level of trust in the runtime report that they can expect on any particular configuration, a security level is assigned to each Windows Defender System Guard attestation service-signed session report. The security level reflects the underlying technologies enabled on the platform and attributes a level of trust based on the capabilities of the platform. We are mapping the enablement of various security technologies to security levels, and we will share this when the API is published for third-party use. The highest level of trust is likely to require the following features, at the very least:

  • VBS-capable hardware + OEM configuration
  • Dynamic root-of-trust measurements at boot
  • Secure boot to verify hypervisor, NT, SK images
  • Secure policy ensuring:

    • Hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI)
    • Test-signing is disabled
    • Kernel debugging is disabled

Measurement

Now that we have explained the trusted report component, let us discuss the contents of the runtime report.

The security level exposed in the session report is an important and interesting metric in and of itself. However, Windows Defender System Guard can provide so much more specifically in respect to runtime measurement of system security posture.

We call this runtime measurement component the assertion engine. The idea is to continually measure assert system integrity at runtime, with the security level attesting to security posture at boot.

Some caveats:

  • The assertion engine was designed with the ideal system configuration in mind (i.e., a system configuration with the highest security level)

    • Business needs require Windows Defender System Guard runtime attestation to function on systems even with the lowest security level; Windows Defender System Guard runtime attestation makes no guarantees in this scenario and can act as a signal for other security products on non-locked down editions of Windows

  • When running the ideal configuration, non-ROP kernel-mode code execution is difficult due to hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI); in this scenario:

    • Data corruption attacks are more likely
    • It can be assumed that it’s difficult to tamper with any required kernel-mode agents in non-racing scenarios
    • The runtime assertions are therefore targeted at attacks that can reasonably be performed under the most restrictive attack conditions

  • We are working to limitations of (current) operating system design

    • We have a deep partnership with other teams in Microsoft and we are work in tandem to improve System Guard runtime attestation and core kernel security features. In the current version of the OS, we rely on NT kernel thread management and the Secure Kernel primitives provided to us.

Windows Defender System Guard runtime attestation architecture

High-level overview of Windows Defender System Guard runtime attestation architecture

Architecturally, the solution is collectively referred to as the Windows Defender System Guard runtime monitor and consists of the following client-side components:

  • The VTL-1 assertion engine itself
  • A VTL-0 kernel-mode agent
  • A VTL-0 process we call the broker to host the assertion engine

To rapidly respond to threats, we opted for a dynamic scripting approach that will allow us to frequently release updates going forward. We chose an open-source library that met our requirements for maturity, footprint, and performance. This scripting component forms the core of the assertion engine that executes in VTL-1 (if available).

Running arbitrary logic in this engine wouldnt be very useful if it couldnt interact with the system in any way. For the engine to perform useful work, we provide native helpers in the form of assists. These assists are executed in VTL-0 either by the broker service or by a Kernel-mode agent.

In the next update to Windows, assertion logic is delivered in-band (within the signed engine DLL itself). At some point in the future, these scripts will be delivered out-of-band. This is a core part of the design. It enables us to immediately respond to security events (for example, the discovery of new attack invariants) without the need for delivering a component update via servicing. Apps and services can take advantage of this attestation technology to ensure that the system is free from tampering and that critical processes are running as expected. This hardware-rooted proof-of-health can then be used to identify compromised machines or gate access to critical cloud services. Runtime attestation serves as a platform for a wide variety of advanced security applications.

We believe that we can significantly raise the bar for security on locked-down platforms with modern hardware and appropriate security policies. In a world where direct privileged code-execution is difficult, we think that attacks will increasingly leverage data corruption. Transient changes are also a challenge in the current model. However, future innovations will make achieving persistence harder, making transient malicious changes more difficult. The idea is to continually elevate defense across the entire Windows 10 security stack, thereby pushing attackers into a corner where system changes affecting security posture are detectable. One can think of runtime attestation as being more about detecting minute symptoms that can indicate an attack rather than looking for flashing signals.

We are very excited about this technology because of its potential for making significant leaps in platform security. Theres a lot more about Windows Defender System Guard runtime attestation that we did not cover in this blog, for example, the detailed design itself and where we see this technology going. Stay tuned.

 

 

David Kaplan (@depletionmode), Windows Defender ATP Research Team
Adam Zabrocki (@Adam_pi3), Windows Offensive Security Research Team
Rafael Goncalves, Enterprise & Security

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Hunting down Dofoil with Windows Defender ATP

Dofoil is a sophisticated threat that attempted to install coin miner malware on hundreds of thousands of computers in March, 2018. In previous blog posts we detailed how behavior monitoring and machine learning in Windows Defender AV protected customers from a massive Dofoil outbreak that we traced back to a software update poisoning campaign several weeks prior. Notably, customers of Windows 10 S, a special Windows 10 configuration that provides streamlined Microsoft-verified security, were not affected by the Dofoil outbreak.

In this blog post, we will expound on Dofoils anti-debugging and anti-analysis tactics, and demonstrate how the rich detection libraries of Windows Defender Advanced Threat Protection and Windows Defender Exploit Guard can help during investigation.

We found that Dofoil was designed to be elusive to analysis. It checks its environment and stops running in virtual machine environments. It also checks for various analysis tools and kills them right away. This can make malware analysis and assessment challenging.

The following diagram shows the multi-stage malware execution process, which includes checks for traits of analysis environments during some stages.

Figure 1. Dofoil multi-stage shellcode and payload execution flow

The table below describes the purpose of each stage. The first five stages have at least one or two different techniques that can deter dynamic or static malware analysis.

STAGES DESCRIPTION
1. Obfuscated wrapper code Anti-heuristics

Anti-emulation

2. Bootstrap module Performs self-process hollowing to load the next module
3. Anti-debugging module Performs anti-debugging operation
4. Trojan downloader module Performs system environment checks

Performs anti-VM operation

Injects itself to explorer.exe through process hollowing

5. Trojan downloader module in explorer.exe Contacts C&C server to download trojan and run it using process hollowing technique
6. Payload downloader module in explorer.exe Contacts C&C server to download the main payload
7. Trojan module Steals credentials from various application settings and sends stolen into to the C&C server over HTTP channel
8. CoinMiner.D Mines digital currencies

Table 1. Dofoil’s multi-stage modules

Initial stages

The first three stages (i.e., obfuscated wrapper code, bootstrap module, anti-debugging module) use the following techniques to avoid analysis and identification.

ANTI-ANALYSIS TECHNIQUES DESCRIPTION
Benign code insertion Inserts a huge benign code block to confuse heuristics and manual inspection
Anti-emulation Enumerates an arbitrary registry key (HKEY_CLASSES_ROOT\Interface\{3050F557-98B5-11CF-BB82-00AA00BDCE0B}) and compares the data with an expected value (DispHTMLCurrentStyle) to check if the malware runs inside an emulator
Self-process hollowing Uses the process hollowing technique on the current process, making analysis extra difficult due to the altered code mapping
Debugger checks Checks for debuggers, and modifies code to crash. This can add additional layer of confusion to researchers, who are bound to investigate the cause of the crashes. It checks for the PEB.BeingDebugged and PEB.NtGlobalFlag fields in the PEB structure. For example, PEB.BeingDebugged is set to 1 and PEB.NtGlobalFlag is set to FLG_HEAP_ENABLE_TAIL_CHECK|FLG_HEAP_ENABLE_FREE_CHECK| FLG_HEAP_VALIDATE_PARAMETERS when a debugger is attached to the process.

Table 2. Anti-analysis techniques

The first stage contains some benign-looking code before the actual malicious code. This can give the executable a harmless appearance. It can also make the emulation of the code difficult because emulating various API calls that are not present in many malware codes can be challenging.

The first-stage code also performs a registry key enumeration to make sure it has the expected value. When all checks are passed, it decodes the second-stage shellcode and runs it on the allocated memory. This shellcode un-maps the original main modules memory, and then decodes the third-stage shellcode into that memory this is known as a self-process hollowing technique.

Figure 2. Self-modification based on PEB.BeingDebugged value

Windows Defender ATPs process tree can help with investigation by exposing these anti-debugging techniques.

Figure 3. Windows Defender ATP process tree showing anti-debugging techniques

Trojan downloader module

The trojan downloader module performs various environment checks, including virtual environment and analysis tool checks, before downloading the payload.

ANTI-ANALYSIS TECHNIQUES DESCRIPTION
Check module name Checks if the main executable name contains the string “sample”
Check volume serial Checks if current volume serial number is 0xCD1A40 or 0x70144646
Check modules Checks the presence of DLLs related to debuggers
Check disk-related registry keys Checks the value of the registry key HKLM\System\CurrentControlSet\Services\Disk\Enum against well-known disk name patterns for virtual machines (qemu, virtual, vmware, xen, ffffcce24)
Process check Checks running processes and kills those with processes names associated with analysis tools (procexp.exe, procexp64.exe, procmon.exe, procmon64.exe, tcpview.exe, wireshark.exe, processhacker.exe, ollydbg.exe, idaq.exe, x32dbg.exe)
Windows class name check Checks the current Windows class names and exits when some well-known names are found (Autoruns, PROCEXPL, PROCMON_WINDOW_CLASS, TCPViewClass, ProcessHacker, OllyDbg, WinDbgFrameClass)

Table 3. Anti-analysis techniqueof Dofoil’s trojan downloader module

The list of target process names and Windows class names exist in custom checksum form. The checksum algorithm looks like the following:

Figure 4. Shift and XOR custom checksum algorithm

The purpose of this checksum is to prevent malware researchers from quickly figuring out what analysis tools it detects, making analysis more time-consuming.

STRING CHECKSUM
Autoruns 0x0E5C1C5D
PROCEXPL 0x1D421B41
PROCMON_WINDOW_CLASS 0x4B0C105A
TCPViewClass 0x1D4F5C43
ProcessHacker 0x571A415E
OllyDbg 0x4108161D
WinDbgFrameClass 0x054E1905
procexp.exe 0x19195C02
procexp64.exe 0x1C0E041D
procmon.exe 0x06185D0B
procmon64.exe 0x1D07120A
tcpview.exe 0x060B5118
wireshark.exe 0x550E1E0D
processhacker.exe 0x51565C47
ollydbg.exe 0x04114C14
x32dbg.exe 0x5F4E5C04
idaq.exe 0x14585A12

Table 4. String checksum table used for process names and Windows class names

Process hollowing

Dofoil heavily uses the process hollowing technique. Its main target for process hollowing is explorer.exe. The Dofoil shellcode launches a new instance of explorer.exe, allocates shellcode in heap region, and then modifies the entry point code to jump into the shellcode. This way, the malware avoids using CreateRemoteThread API, but can still achieve code injection.

Figure 5. Modification of explorer.exe entry point code

Windows Defender ATP can detect the process hollowing behavior with advanced memory signals. The following process tree shows that the malware injects itself into explorer.exe using the process hollowing technique.

Figure 6. Windows Defender ATP alert process tree showing the first process hollowing

When the shellcode downloads another layer of payload, it spawns another explorer.exe to inject the payload into using process hollowing. Windows Defender ATP can save analysis time on these cases by pinpointing the malicious actions, eliminating the need for guessing what these newly spawned Windows system processes are doing.

Figure 7. Windows Defender ATP alert process tree showing the second process hollowing

The process hollowing behavior can be detected through Exploit protection in Windows Defender Exploit Guard. This can be done by enabling the Export Address Filter (EAF) mitigation against explorer.exe. The detection happens when the shellcode goes through the export addresses of the modules to find the export address of the LoadLibraryA and GetProcAddress functions.

Figure 8. Export Address Filter (EAF) event exposed in Event viewer

Windows Defender Exploit Guard events are also exposed in the Windows Defender ATP portal:

Figure 9. Windows Defender ATP view of the Windows Defender Exploit Guard event

Adding Windows Defender Exploit Guard EAF audit/block policy to common system processes like explorer.exe, cmd.exe, or verclsid.exe can be useful in finding and blocking process hollowing or process injection techniques commonly used by malware. This policy can impact third-party apps that may behave like shellcode, so we recommend testing Windows Defender Exploit Guard with audit mode enabled before enforcement.

Command-and-control (C&C) and NameCoin domains

Dofoils C&C connection is very cautious. The trojan code first tries to connect to well-known web pages and verifies that the malware has proper and real Internet connection, not simulated as in test environments. After it makes sure it has a real Internet connection, the malware makes HTTP connections to the actual C&C servers.

Figure 10. Access to known servers to confirm Internet connectivity

The malware uses NameCoin domain name servers. NameCoin is a decentralized name server system that provides extra privacy backed by blockchain technology. Except for the fact that the DNS client needs to use specific sets of NameCoin DNS servers, the overall operation is very similar to a normal DNS query. Because NameCoin uses blockchain technology, you can query the history of the domain name changes through blocks.

Figure 11. Malicious hostname DNS entry changes over time (https://namecha.in/name/d/vrubl)

Windows Defender ATP can provide visibility into the malwares network activities. The following alert process tree shows the malwares .bit domain resolution activity and, after that, the connections to the resolved C&C servers. You can also view other activities from the executable, for example, its connections to other servers using SMTP ports.

Figure 12. Windows Defender ATP alert process tree showing C&C server connection through NameCoin server name resolution

The Windows Defender ATP advanced hunting feature, which is currently in preview, can be used to hunt down more malware samples that possibly abuse NameCoin servers. For example, the following query will let you view recent connections observed in the network. This can lead to extra insights on other threats that use the same NameCoin servers.

Figure 13. Advanced hunting for other threats using the same NameCoin servers

The purpose of using NameCoin is to prevent easy sinkholing of the domains. Because there are no central authorities on the NameCoin domain name records, it is not possible for the authorities to change the domain record. Also, malware abusing NameCoin servers use massive numbers of NameCoin DNS servers to make full shutdown of those servers very difficult.

Conclusion

Dofoil is a very evasive malware. It has various system environment checks and tests Internet connectivity to make sure it runs on real machines, not in analysis environments or virtual machines. This can make the analysis time-consuming and can mislead malware analysis systems.

In attacks like the Dofoil outbreak, Windows Defender Advanced Threat Protection (Windows Defender ATP) can help network defenders analyze the timeline from the victim machine and get rich information on process execution flow, C&C connections, and process hollowing activities. Windows Defender ATP can be used as an analysis platform with fine-tuned visibility into system activities when set up in a lab environment. This can save time and resource during malware investigation.

In addition, Windows Defender Exploit Guard can be useful in finding malicious shellcodes that traverse export address tables. Windows Defender Exploit Guard can be an excellent tool for finding and blocking malware and exploit activities.

Windows Defender Exploit Guard events are surfaced in the Windows Defender ATP portal, which integrates protections from other Microsoft solutions, including Windows Defender AV and Windows Defender Application Guard. This integrated security management experience makes Windows Defender ATP a comprehensive solution for detecting and responding to a wide range of malicious activities across the network.

Windows 10 S, a special configuration of Windows 10, locks down devices against Dofoil and other attacks by working exclusively with apps from the Microsoft Store and using Microsoft Edge as the default browser. This streamlined, Microsoft-verified platform seals common malware entry points.

To test how Windows Defender ATP can help your organization detect, investigate, and respond to advanced attacks, sign up for a free trial.

 

 

Matt Oh, Stefan Sellmer, Jonathan Bar Or, Mark Wodrich
Windows Defender ATP Research

 

 

Indicators of compromise (IoCs)

TrojanDownloader:Win32/Dofoil.AB:

d191ee5b20ec95fe65d6708cbb01a6ce72374b309c9bfb7462206a0c7e039f4d

eaa63f6b500afedcaeb8d5b18a08fd6c7d95695ea7961834b974e2a653a42212

cded7aedca6b54a6d4273153864a25ccad35cba5cafeaec828a6ad5670a5973a

Trojan:Win32/Dofoil.AB:

070243ad7fb4b3c241741e564039c80ca65bfdf15daa4add70d5c5a3ed79cd5c

5f3efdc65551edb0122ab2c40738c48b677b1058f7dfcdb86b05af42a2d8299C

28ce9763a808c4a7509e9bf92d9ca80212a241dfa1aecd82caedf1f101eac692

5d7875abbbf104f665a0ee909c372e1319c5157dfc171e64ac2bc8b71766537f

Trojan:Win32/CoinMiner.D

2b83c69cf32c5f8f43ec2895ec9ac730bf73e1b2f37e44a3cf8ce814fb51f12

C&C URLs:

hxxp://levashov.bit/15022018/

hxxp://vrubl.bit/15022018/

C&C server:

vinik.bit

Related .bit domains (updated in same block as C&C server):

henkel.bit

makron.bit

makronwin.bit

NameCoin servers used by Dofoil:

139.59.208.246

130.255.73.90

31.3.135.232

52.174.55.168

185.121.177.177

185.121.177.53

62.113.203.55

144.76.133.38

169.239.202.202

5.135.183.146

142.0.68.13

103.253.12.18

62.112.8.85

69.164.196.21

107.150.40.234

162.211.64.20

217.12.210.54

89.18.27.34

193.183.98.154

51.255.167.0

91.121.155.13

87.98.175.85

185.97.7.7

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

 

 

Why Windows Defender Antivirus is the most deployed in the enterprise

Statistics about the success and sophistication of malware can be daunting. The following figure is no different: Approximately 96% of all malware is polymorphic meaning that it is only experienced by a single user and device before it is replaced with yet another malware variant. This is because in most cases malware is caught nearly as fast as its created, so malware creators continually evolve to try and stay ahead. Data like this hammer home how important it is to have security solutions in place that are as agile and innovative as the attacks.

The type of security solution needed has a complex job: It must protect users from hundreds of thousands of new threats every day and then it must learn and grow to stay ahead of the next wave of attacks. The solution cannot just react to the latest threats; it must be able to predict and prevent malware infections.

Over the last year, weve talked about how were investing in new innovations to address this challenging threat landscape, what weve delivered, and how it will change the dynamics. Today, I want to share the results of our new antivirus capabilities in Windows Defender Advanced Threat Protection (ATP) which are genuinely incredible because they will directly benefit the work you are doing.

Currently, our antivirus capabilities on Windows 10 are repeatedly earning top scores on independent tests, often outperforming the competition. This performance is the result of a complete redesign of our security solution.

Whats more, this same technology is available for our Windows 7 customers as well, so that they can remain secure during their transition to Windows 10.

It started back in 2015

Weve been working to make our antivirus capabilities increasingly more effective, and in 2015 our results in two major independent tests (AV-Comparatives and AV-TEST) began to improve dramatically. As you can see in the chart below, beginning in March 2015 our scores on AV-TEST began to rise rapidly, and, over the course of the next five months, we moved from scores averaging 85% on their Prevalence Test to (or near) 100%. Since then, weve maintained those types of scores consistently. Our scores on AV-Comparatives experienced a very similar spike, trajectory, and results.

In December 2017, we reached another milestone on AV-TEST, where we achieved a perfect score across both the Prevalence and Real-World based tests. Previously we had only scored a perfect 100% on one of the two tests for a given month. The following chart from the AV-TEST site shows our scores from November and December 2017 on Windows 7. These same scores are also applicable to Windows 10, which shares the same technology (and more).

For AV-Comparatives, we recently achieved another important quality milestone: For five consecutive months we detected all malware samples. Our previous best was four consecutive months. The AV-Comparatives chart below shows our February 2018 results where we scored a perfect 100% block rate.

While independent antivirus tests are one indicator of a security solutions capabilities and protections, its important to understand that this is only one part of a complete quality assessment.

For example, in the case of Windows Defender ATP (which integrates our antivirus capabilities and the whole Windows security stack), our customers have a much larger set of protection features none of which are factored into the tests. These features provide additional layers of protection that help prevent malware from getting onto devices in the first place. These features include the following:

If organizations like AV-Comparatives and AV-TEST performed complete security stack tests (i.e., testing against the complete endpoint protection solution) the results would often tell a very different story. For example, in November, we scored a 98.9% based on a single file miss on the Real-World test. The good news, however, is that we would have scored 100% if either Windows Defender Application Guard or Application Control was enabled.

How did we achieve these results?

The short answer is that we completely redesigned our antivirus solutions for both Windows 7 and Windows 10 from the ground up.

To do this, we moved away from using a static signature-based engine that couldnt scale due to its dependence on constant input from researchers. Weve now moved to a model that uses predictive technologies, machine learning, applied science, and artificial intelligence to detect and stop malware at first sight. We described the use of these technologies in our recent posts on Emotet and BadRabbit, as well as the recent Dofoil outbreak. These are the types of approaches that can be very successful against the ongoing avalanche of malware threats.

Because of these changes, our antivirus solution can now block malware using local and cloud-based machine learning models, combined with behavior, heuristic, and generic-based detections on the client. We can block nearly all of it at first sight and in milliseconds!

This is incredible.

Weve also designed our antivirus solution to work in both online and offline scenarios. When connected to the cloud, its fed real-time intelligence from the Intelligent Security Graph. For offline scenarios, the latest dynamic intelligence from the Graph is provisioned to the endpoint regularly throughout the day.

Weve also built our solution to defend against the new wave of fileless attacks, like Petya and WannaCry. To read more about how we protect against these attacks, check out the blog post Now you see me: Exposing fileless malware.

What this means to you

Each of these milestones is great, but the thing that makes us the most excited here at Microsoft is very simple: Customer adoption.

Right now, we are seeing big growth in enterprise environments our across all of our platforms:

  • 18% of Windows 7 and Windows 8 devices are using our antivirus solution
  • Over 50% of Windows 10 devices are using our antivirus solution

These are awesome numbers and proof that customers trust Windows security. What we are seeing is that as organizations are moving to Windows 10 they are also moving to our antivirus as their preferred solution. With our antivirus solution being used on more than 50% percent of the Windows 10 PCs deployed in commercial organizations, it is now the most commonly used antivirus solution in commercial organizations on that platform. This usage is in commercial customers of all sizes from small and medium-sized businesses to the largest enterprise organizations.

Over the past couple of months Ive shared this data with multiple customers, and often Im asked why weve seen such a positive increase. The answer is simple:

  1. Our antivirus capabilities are a fantastic solution! The test results above really speak for themselves. With five months of top scores that beat some of our biggest competitors, you can be confident that our solution can protect you from the most advanced threats.
  2. Our solution is both easier and operationally cheaper to maintain than others. Most enterprise customers use Config Manager for PC management of Windows 7 and Windows 10 security features, including antivirus. With Windows 10, the antivirus capabilities are built directly into the operating system and theres nothing to deploy. Windows 7 didnt include antivirus capabilities by default, but it can be deployed and configured in Config Manager. Now organizations do not have to maintain two infrastructures one for PC management and another for antivirus. Several years ago, our Microsoft IT department retired the separate global infrastructure that was used to manage Microsofts antivirus solution and now you can too! With our solution theres less to maintain and secure.
  3. Our solution enables IT to be more agile. On Windows 10 theres no agent security is built into the platform. When a new update of Windows 10 is released, you dont need to wait for a 3rd party to certify and support it; instead, you have full support and compatibility on day one. This means that new releases of Windows and all the latest security technologies can be deployed faster. This allows you to get current, stay current, and be more secure.
  4. Our solution offers a better user experience. Its designed to work behind the scenes in a way that is unobtrusive to end users and minimizes power consumption. This means longer battery life and everyone wants more battery life!

While weve made excellent progress with our antivirus solution, Im even more excited about the protection and management capabilities we will deliver to our customers in the near future. In the meantime, one of the best ways to evaluate our antivirus capabilities is when you run it with Windows Defender ATP. With Windows Defender ATP, the power of the Windows security stack provides preventative protection, detects attacks and zero-day exploits, and gives you centralized management for your end-to-end security lifecycle.

Sign up to try Windows Defender ATP for yourself!

 

Invisible resource thieves: The increasing threat of cryptocurrency miners

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

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

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

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

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

In enterprise environments, Windows Defender ATP provides the next-gen security features, behavioral analysis, and cloud-powered machine learning to help protect against the increasing threats of coin miners: Trojanized miners, mining scripts hosted in websites, and even legitimate but unauthorized coin mining applications.

Coin mining malware

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

Figure 1. Volume of unique computers that encountered trojanized coin miners

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

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

Infection vectors

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

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

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

Persistence mechanisms

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

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

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

Spreading capabilities and other behaviors

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

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

Browser-based coin miners (cryptojacking)

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

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

Figure 2. A sample coin mining script hidden in multiple layers of iframes in compromised websites

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

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

Unauthorized use of legitimate coin miners

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

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

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

Figure 4. Volume of unique computers in enterprise environments with PUA protection enabled that encountered unauthorized coin miners

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

Apart from coin mining programs, potentially unwanted applications include:

  • Programs that install other unrelated programs during installation, especially if those other programs are also potentially unwanted applications
  • Programs that hijack web browsing experience by injecting ads to pages
  • Driver and registry optimizers that detect issues, request payment to fix the errors, and remain on the computer
  • Programs that run in the background and are used for market research

PUA protection is enabled by default in System Center Configuration Manager. Security administrators can also enable and configure the PUA protection feature using PowerShell cmdlets or Microsoft Intune.

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

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

Figure 5. Breakdown of potentially unwanted applications

Protecting corporate networks from cryptocurrency miners

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

Windows Defender AV uses multiple layers of protection to detect new and emerging threats. Non-malicious but unauthorized miners can be blocked using the PUA protection feature in Windows Defender AV. Enterprises can also use Windows Defender Application Control to set code integrity policies that prevent employees from installing malicious and unauthorized applications.

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

Coin mining malware with more sophisticated behaviors or arrival methods like DDE exploit and malicious scripts launched from email or Office apps can be mitigated using Windows Defender Exploit Guard, particularly its Attack surface reduction and Exploit protection features.

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

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

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

Figure 6. Windows Defender EDR detection for coin mining malware

Windows Defender EDR integrates detections from Windows Defender AV, Windows Defender Exploit Guard, and other Microsoft security products, providing seamless security management that can allow security operations personnel to centrally detect and respond to cryptocurrency miners and other threats in the network.

 

Alden Pornasdoro, Michael Johnson, and Eric Avena
Windows Defender Research

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

FinFisher exposed: A researcher’s tale of defeating traps, tricks, and complex virtual machines

Office 365 Advanced Threat Protection (Office 365 ATP) blocked many notable zero-day exploits in 2017. In our analysis, one activity group stood out: NEODYMIUM. This threat actor is remarkable for two reasons:

  • Its access to sophisticated zero-day exploits for Microsoft and Adobe software
  • Its use of an advanced piece of government-grade surveillance spyware FinFisher, also known as FinSpy and detected by Microsoft security products as Wingbird

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

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

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

Figure 1. Generic Windows Defender ATP detections trigger alerts on FinFisher behavior

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

Spaghetti and junk codes make common analyst tools ineffective

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

Figure 2. The spaghetti code in FinFisher dropper

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

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

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

Stage 0: Dropper with custom virtual machine

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

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

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

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

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

  1. Logical opcodes, which implement bit-logic operators (OR, AND, NOT, XOR) and mathematical operators
  2. Conditional branching opcodes, which implement a code branch based on conditions (equals to JC, JE, JZ, other similar branching opcodes)
  3. Load/Store opcodes, which write to or read from particular addresses of the virtual address space of the process
  4. Specialized opcodes for various purposes, like execute specialized machine instruction that are not virtualized

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

INDEX

MNEMONIC

DESCRIPTION

0x0

EXEC

Execute machine code

0x1

JG

Jump if greater/Jump if not less or equal

0x2

WRITE

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

0x3

JNO

Jump if not overflow

0x4

JLE

Jump if less or equal (signed)

0x5

MOV

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

0x6

JO

Jump if overflow

0x7

PUSH

Push the internal VM value to the stack

0x8

ZERO

Reset the internal VM value to 0 (zero)

0x9

JP

Jump if parity even

0xA

WRITE

Write into an address

0xB

ADD

Add the value of a register to the internal VM value

0xC

JNS

Jump if not signed

0xD

JL

Jump if less (signed)

0xE

EXEC

Execute machine code and branch

0xF

JBE

Jump if below or equal or Jump if not above

0x10

SHL

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

0x11

JA

Jump if above/Jump if not below or equal

0x12

MOV

Move the internal VM value into a register

0x13

JZ

JMP if zero

0x14

ADD

Add an immediate value to the internal Vm descriptor

0x15

JB

Jump if below (unsigned)

0x16

JS

Jump if signed

0x17

EXEC

Execute machine code (same as opcode 0x0)

0x18

JGE

Jump if greater or equal/Jump if not less

0x19

DEREF

Write a register value into a dereferenced pointer

0x1A

JMP

Special obfuscated Jump if below opcode

0x1B

*

Resolve a pointer

0x1C

LOAD

Load a value into the internal VM descriptor

0x1D

JNE

Jump if not equal/Jump if not zero

0x1E

CALL

Call an external function or a function located in the dropper

0x1F

MOV

Move the value of a register into the VM descriptor

0x20

JNB

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

0x21

JNP

Jump if not parity/Jump if parity odd

 

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

Here is an approximate diagram of the opcode data structure:

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

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

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

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

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

Stage 1: Loader malware keeps sandbox and debuggers away

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

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

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

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

  1. The MD5 hash of the parent process image name is either D0C4DBFA1F3962AED583F6FCE666F8BC or 3CE30F5FED4C67053379518EACFCF879
  2. The parent processs full image path is equal to its own process path

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

Figure 7. FinFisher loader calling native Windows API to perform anti-debugging tricks

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

  1. Check that the malware is not executed under the root folder of a drive
  2. Check that the malware file is readable from an external source
  3. Check that the hash of base path is not 3D6D62AF1A7C8053DBC8E110A530C679
  4. Check that the full malware path contains only human readable characters (a-z, A-Z, and 0-9)
  5. Check that no node in the full path contains the MD5 string of the malware file
  6. Fingerprint the system and check the following registry values:

    1. HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid should not be “6ba1d002-21ed-4dbe-afb5-08cf8b81ca32”
    2. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId should not be “55274-649-6478953-23109”, “A22-00001”, or “47220”
    3. HARDWARE\Description\System\SystemBiosDate should not contain 01/02/03

  7. Check that the mutex WininetStartupMutex0 does not already exist
  8. Check that no DLL whose base name has hash value of 0xC9CEF3E4 is mapped into the malware address space

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

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

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

  1. The first call aims to destroy the debugger connection:
    ZwSetInformationThread(GetCurrentProcess(), ThreadHideFromDebugger, NULL, 0);
    NOTE: This call completely stops the execution of WinDbg and other debuggers
  2. The second call tries to detect the presence of a debugger:
    ZwQueryInformationProcess(CurProc, ProcessDebugPort, &debugPort, sizeof(ULONG_PTR))
    ZwQueryInformationProcess(CurProc, ProcessDebugObjectHandle, &debugObjHandle, sizeof(ULONG_PTR))
  3. The final call tries to destroy the possibility of adding software breakpoint:
    VirtualProtectEx(CurProc, &DbgBreakPoint, 1, PAGE_RWX, &oldProtect)
    DbgBreakPoint[0] = 0x90; // Place a NOP opcode instead the standard INT 3

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

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

Figure 8. The fake bitmap image embedded as resource

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

Figure 9. Heavens gate is still in use in 2017

Stage 2: A second multi-platform virtual machine

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

INDEX

MNEMONIC

DESCRIPTION

0x0

JMP

Special obfuscated conditional Jump (always taken or always ignored)

0x1

JMP

Jump to a function (same as opcode 0x10)

0x2

CALL

Call to the function pointed by the internal VM value

0x3

CALL

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

0x4

EXEC

Execute code and move to the next packet

0x5

JMP

Jump to an internal function

0x6

NOP

No operation, move to the next packet

0x7

CALL

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

0x8

LOAD

Load a value into the VM descriptor structure *

0x9

STORE

Store the internal VM value inside a register

0xA

WRITE

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

0xB

READ

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

0xC

LOAD

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

0xD

CMP

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

0xE

CMP

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

0xF

XCHG

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

0x10

SHL

Jump to a function (same as opcode 0x1)

 

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

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

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

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

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

FILE NAME STAGE DESCRIPTION
d3d9.dll Stage 4 Malware loader used for UAC environments with limited privileges; also protected by VM obfuscation
aepic.dll
sspisrv.dlluserenv.dll
Stage 4 Malware loader used in presence of administrative privileges; executed from (and injected into) a fake service; also protected by VM obfuscation
msvcr90.dll Stage 5 Malware payload injected into the explorer.exe or winlogon.exe process; also protected by VM obfuscation
<randomName>.cab Config Main configuration file; encrypted

 

setup.cab Unknown Last section of the setup executable; content still unknown
<randomName>.7z Plugin Malware plugin used to spy the victim network communications
wsecedit.rar Stage 6 Main malware executable

 

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

  1. Installation process under UAC

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

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

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

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

  1. Installation process with administrative privilege

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

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

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

Figure 10. Windows Defender ATP timeline can pinpoint the service DLL side-loading trick (in this example, using fltlib.dll).

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

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

Figure 11. The DLL side-loaded stage 4 malware mimicking a real export table to avoid detection

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

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

  • In the low-integrity case (under UAC) the installer simply injects the stage 5 malware into the bogus explorer.exe process started earlier and terminates
  • In the high-integrity case (with administrative privileges or after UAC bypass), the code searches for the process hosting the Plug and Play service (usually svchost.exe) loaded in memory and injects itself into it

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

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

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

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

The malware takes these steps:

  1. Check if the system master boot record (MBR) contains an infection marker (0xD289C989C089 8-bytes value at offset 0x2C), and, if so, terminate itself
  2. Check again if the process is attached to a debugger (using the techniques described previously)
  3. Read, decrypt, and map the stage 5 malware (written in the previous stage in msvcr90.dll)
  4. Open winlogon.exe process
  5. Load user32.dll system library and read the KernelCallbackTable pointer from its own process environment block (PEB) (Note: The KernelCallbackTable points to an array of graphic functions used by Win32 kernel subsystem module win32k.sys as call-back into user-mode.)
  6. Calculate the difference between this pointer and the User32 base address.
  7. Copy the stage 5 DLL into winlogon.exe
  8. Allocate a chunk of memory in winlogon.exe process and copy the same APC routine seen previously
  9. Read and save the original pointer of the __fnDWORD internal User32 routine (located at offset +0x10 of the KernelCallbackTable) and replace this pointer with the address of the APC stub routine

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

Stage 5: The final loader takes control

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

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

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

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

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

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

Defense against FinFisher

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

Windows 10 S devices are naturally protected against FinFisher and other threats thanks to the strong code integrity policies that dont allow unknown unsigned binaries to run (thus stopping FinFishers PE installer) or loaded (blocking FinFishers DLL persistence). On Windows 10, similar code integrity policies can be configured using Windows Defender Application Control.

Office 365 Advanced Threat Protection secures mailboxes from email campaigns that use zero-day exploits to deliver threats like FinFisher. Office 365 ATP blocks unsafe attachments, malicious links, and linked-to files using time-of-click protection. Using intel from this research, we have made Office 365 ATP more resistant to FinFishers anti-sandbox checks.

Generic detections, advanced behavioral analytics, and machine learning technologies in Windows Defender Advanced Threat Protection detect FinFishers malicious behavior throughout the attack kill chain and alert SecOps personnel. Windows Defender ATP also integrates with the Windows protection stack so that protections from Windows Defender AV and Windows Defender Exploit Guard are reported in Windows Defender ATP portal, enabling SecOps personnel to centrally manage security, and as well as promptly investigate and respond to hostile activity in the network.

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

 

Andrea Allievi, Office 365 ATP Research team
with Elia Florio, Windows Defender ATP Research team

 

Sample analyzed:

MD5: a7b990d5f57b244dd17e9a937a41e7f5
SHA-1: c217d48c4ac1555491348721cc7cfd1143fe0b16
SHA-256: b035ca2d174e5e4fd2d66fd3c8ce4ae5c1e75cf3290af872d1adb2658852afb8

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Categories: cybersecurity Tags: