Hacking with dex-oracle for Android Malware Deobfuscation

About a month or two ago, someone asked me to analyze some obfuscated Android malware. Recently, I finally had a chance to take a look. I ended up using dex-oracle along with some tricks to partially deobfuscate it. In this post, I’m going to explain the tricks and the overall process I used. This post will be useful if you deal with a lot of obfuscated Android apps.

The main problem was dex-oracle didn’t work “out of the box”. It took some “hacking” to make it work. Specifically, I modified an existing deobfuscation plugin to create two new plugins as well as slightly modify the app. It’s really hard to make completely generalized deobfuscation tools, or any kind of advanced tool, so you’ll need to know how it works in order to modify it to suit your needs.

The Sample

Here’s the SHA256:



$ shasum -a 256 xjmurla.gqscntaej.bfdiays.apk

d3becbee846560d0ffa4f3cda708d69a98dff92785b7412d763f810c51c0b091 xjmurla.gqscntaej.bfdiays.apk

High-Level Analysis

I like to start with a decompilation just to get a high level overview of the package structure. Here’s what the class list:

class list

Some class names have been ProGuard’ed (a, b, c, etc.) but some haven’t (Ceacbcbf). These unobfuscated classes are probably Android components (activity, service, broadcast receiver, etc.) which must be declared in the manifest. Thus, any tool which automatically renames them would also have to rename them in the manifest, which is hard. These may have been manually changed. The obfuscation is probably home-made and partially done by hand. This means it’s probably malicious because a legit developer would probably pull a commercial obfuscator off the shelf and just use that. They wouldn’t waste time changing their class names to something indecipherable like Aeabffdccdac.

The code is obfuscated. Below is a class which shows the obfuscation:

obfuscated method decompilation

You can’t see any strings or class names, which is really annoying. This looks like something Simplify can handle, but, spoilers, it fails miserably. That’s fine. I have many tricks up my sleeve. Let’s take a look at the Smali and see if anything jumps out.

String and Class Obfuscation

The first type of obfuscation which jumped out at me was an “indexed string lookup” type obfuscation.




const v2, 0x320fb26f

invoke-static {v2}, Lxjmurla/gqscntaej/bfdiays/f;->a(I)Ljava/lang/String;

move-result-object v2

This pattern is found hundreds of times in the code. It takes a number, passes it to f.a(int), and gets a string back. This is some basic “level 1” style encryption. There’s probably a big method somewhere which builds an array of strings that the number indexes into.

A second type of obfuscation hides class constants using an identical technique:




const v1, 0x19189b07

invoke-static {v1}, Lxjmurla/gqscntaej/bfdiays/g;->c(I)Ljava/lang/Class;

move-result-object v1

This code passes a number to g.c(int) and gets back a class object (const-class).

You may be thinking you’ll have to reverse engineer the lookup methods, and you’d be wrong. It’s cool and all to deep dive into the complex code and completely master it by writing a decryption routine. But honestly, fuck that. Speed is the name of the game, and I really don’t have time to fuck around with this malware author’s bullshit, retarded, home-made, amateur hour obfuscation. Instead of reversing everything, consider that these “lookup” methods are both static. It should be possible to just execute them with the same inputs from the code to get back the decrypted output. For example, in the case of string decryption, I should be able to execute f.a(0x320fb26f) and get back the decrypted string.

The question is, of course, how do you execute just the target method code? It’s an APK. How can you execute just the method you want with the inputs you want? How do you harness the target methods? There are two paths you can go by:

  1. Convert target DEX to a JAR using dex2jar or enjarify. Then, import the JAR into a Java app and call the decryption code from your Java app.
  2. Create a stub / driver app which takes command line arguments and can reflect methods in a DEX file. Then, execute the driver app + target DEX on an emulator.

As it happens, I’ve already created dex-oracle which does #2. I like #2 more than #1 because it doesn’t rely on decompilers which often introduce subtle logic bugs. However, I’ve used #1 a few times in a pinch, so it’s worth mentioning. I went about adding support for this type of obfuscation to dex-oracle. the plugins were added in Add indexed string + class lookups.

The way dex-oracle works is pretty simple. It contains a collection of plugins which define regular expressions which pull out key bits of information – method calls and arguments. Then, it constructs real method calls with the arguments you pull out and passes them to a driver which executes the original DEX file on an emulator. Finally, the plugin defines how the driver output should be used to modify the method.

For example, the regular expression could look for “a const number, a call to a static method which takes a number and returns a string, and moves the result to a register”. Then, the driver executes that method with the number and returns the decrypt string. Finally, the original string lookup code is replaced with just the decrypted string. You can read more about how it works in TetCon 2016 Android Deobfuscation Presentation.

dex-oracle Before Modification

Unfortunately, even with the new plugins, dex-oracle fails. To keep things simple, I disable all plugins except IndexStringLookup and I only process the d class from the picture example above.
































$ dex-oracle xjmurla.gqscntaej.bfdiays.apk --disable-plugins bitwiseantiskid,stringdecryptor,undexguard,unreflector,indexedclasslookup -i '/d'

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Invalid date/time in zip entry

Optimizing 11 methods over 23 Smali files.

[WARN] 2017-10-28 12:28:45: Unsuccessful status: failure for Error executing 'static java.lang.String xjmurla.gqscntaej.bfdiays.f.a(int)' with 'I:839889519'


at java.lang.reflect.Method.invokeNative(Native Method)

at java.lang.reflect.Method.invoke(Method.java:515)

at org.cf.oracle.Driver.invokeMethod(Driver.java:71)

at org.cf.oracle.Driver.main(Driver.java:131)

at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)

at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:243)

at dalvik.system.NativeStart.main(Native Method)

Caused by: java.lang.NullPointerException

at xjmurla.gqscntaej.bfdiays.f.a(SourceFile:528)

... 7 more


Optimizations: string_lookups=13

Invalid date/time in zip entry


Invalid date/time in zip entry

Time elapsed 1.954255 seconds

The Invalid date/time in zip entry stuff is just noise. Maybe they tried obfuscating the timestamp in the ZIP? I dunno.

What concerns me is the Unsuccessful status: failure for Error executing 'static java.lang.String xjmurla.gqscntaej.bfdiays.f.a(int)' with 'I:839889519'. The error tells me there’s a NullPointerException when it executes f.a(int). Looks like every time it tried to call that method, it failed. So, let’s look at f.a(int).












.method static a(I)Ljava/lang/String;

.registers 3

sget-object v0, Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;

const v1, 0x320fb1f0

sub-int v1, p0, v1

aget-object v0, v0, v1

return-object v0

.end method

The entire method is pretty small. Just subtracts the first argument from a big constant and uses that as an index into a string array, Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;. Well, let’s look out f;->k is initialized.









$ ag -Q 'Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;'


169: sput-object v0, Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;

245: sget-object v0, Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;

256: sget-object v0, Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;


72: sget-object v0, Lxjmurla/gqscntaej/bfdiays/f;->k:[Ljava/lang/String;

There’s only one sput-object and it’s in xjmurla/gqscntaej/bfdiays/Ceacabcbf.smali. By looking for this line in Ceacabcbf, we find private Ceacabcbf;->a()V. This is a big, long, complicated method which contains a HUGE string literal which is processed, chunked up, and stored in f;->k. Hmm, our NullPointerException is caused by this field not getting initialized. This means that Ceacabcbf;->a()V is not getting called during execution of the string decryption method. Well, when is it called?




$ ag -Q 'Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;->a()V'


1313: invoke-direct {p0}, Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;->a()V

Ahh, it’s only called in Ceacabcbf. Let’s find that.












.method public onCreate()V

.registers 1

invoke-super {p0}, Landroid/app/Application;->onCreate()V

sput-object p0, Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;->a:Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;

invoke-direct {p0}, Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;->a()V


.end method

It’s called in Ceacabcbf;->onCreate()V. This class is a subclass of Application. Without looking at the manifest, I’m pretty sure that when the app starts, this component is created, onCreate()V is called, the decrypted string array is built, and most importantly f;->k is initialized. Hmm, how can I make it so that dex-oracle calls this method when decrypting strings?

My first thought is to add a method call to Ceacabcbf;->a()V in f;-><clinit>. This ensures that when the string decryption class f is loaded, it initializes the decrypted string array. BUT, a()V is direct. WHAT TO DO?

Well, this is kind of dumb but it works sometimes. Just create a new public, static method called Ceacabcbf;->init_decrypt()V and copy the code from Ceacabcbf;->a()V. Then, add a line to call this method in f;-><clinit>:






















.method static constructor <clinit>()V

.registers 1

const/4 v0, 0x0

sput v0, Lxjmurla/gqscntaej/bfdiays/f;->a:I

sput v0, Lxjmurla/gqscntaej/bfdiays/f;->d:I

sput v0, Lxjmurla/gqscntaej/bfdiays/f;->e:I

sput v0, Lxjmurla/gqscntaej/bfdiays/f;->f:I

const/4 v0, 0x4

new-array v0, v0, [Ljava/lang/String;

sput-object v0, Lxjmurla/gqscntaej/bfdiays/f;->h:[Ljava/lang/String;

const-string v0, ""

sput-object v0, Lxjmurla/gqscntaej/bfdiays/f;->i:Ljava/lang/Object;


invoke-static {}, Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;->init_decrypt()V


.end method

dex-oracle After Modification

After making some changes which hopefully work, need rebuild the DEX from the modified Smali and try dex-oracle on it.






$ smali ass out -o xjmurla_mod1.dex

$ dex-oracle xjmurla_mod1.dex --disable-plugins bitwiseantiskid,stringdecryptor,undexguard,unreflector,indexedclasslookup -i '/d'

Optimizing 11 methods over 23 Smali files.

Optimizations: string_lookups=13

Time elapsed 2.034493 seconds

No errors. Let’s see the decompilation.




$ d2j-dex2jar.sh xjmurla_mod1_oracle.dex

dex2jar xjmurla_mod1_oracle.dex -> ./xjmurla_mod1_oracle-dex2jar.jar

$ jd xjmurla_mod1_oracle-dex2jar.jar

deobfuscated strings

Oh, hello there Mr. C&C domain! GET REKT BRO.

get rekt

Ok, but that still leaves the class deobfuscation. That’s still annoying, right? Well, to keep this post short, dex-oracle fails when deobbfuscating classes for the same reason as it originally failed for strings. The same Ceacabcbf;->a()V method needs to be called.

The same trick can be used – just call Ceacabcbf;->init_decrypt()V in g;-><clinit>. However, g doesn’t have a <clinit> so you’ll have to add one:







.method static constructor <clinit>()V

.registers 0

invoke-static {}, Lxjmurla/gqscntaej/bfdiays/Ceacabcbf;->init_decrypt()V


.end method

Now, rebuild and let dex-oracle do it’s thing:






$ smali ass out -o xjmurla_mod2.dex

$ dex-oracle xjmurla_mod2.dex -i '/d'

Optimizing 11 methods over 23 Smali files.

Optimizations: string_decrypts=0, class_lookups=13, string_lookups=13

Time elapsed 3.099335 seconds

Let’s see if the decompilation looks any different.




$ d2j-dex2jar.sh xjmurla_mod2_oracle.dex

dex2jar xjmurla_mod1_oracle.dex -> ./xjmurla_mod2_oracle-dex2jar.jar

$ jd xjmurla_mod1_oracle-dex2jar.jar

deobfuscated strings and classes

There’s not much difference for this method, but other methods have a lot more information, especially in the Smali where you can see lots of const-classes. There’s still one call to g.c(int) which isn’t deobfuscated. I found out that this is because the method call succeeds but returns null. Maybe that’s why it’s in a try-catch? Maybe it’s trying to load a class which doesn’t exist on every Android API version?

One final test: run it against the entire DEX file.





$ dex-oracle xjmurla_mod2.dex

Optimizing 125 methods over 23 Smali files.

Optimizations: string_decrypts=0, class_lookups=354, string_lookups=330

Time elapsed 3.306326 seconds

It worked. Cool. Now there are lots of strings! This should also make it a lot easier for Simplify to work because there’s less code to execute and fewer places to fail.


Hopefully after reading this you have better idea of how to bend dex-oracle to suit your needs. It’s pretty flexible and great when you can isolate the code you need to run to a single method. Sometimes you need to make changes to an Android app to help dex-oracle, but modifying Smali is relatively easy to modify and a lot of malware doesn’t bother doing anti-tampering checks.

from RedNaga Security http://ift.tt/2gLMz5s


ZNIU: First Android Malware to Exploit Dirty COW Vulnerability

By Jason Gu, Veo Zhang, and Seven Shen

We have disclosed this security issue to Google, who verified that they have protections in place against ZNIU courtesy of Google Play Protect.

The Linux vulnerability called Dirty COW (CVE-2016-5195) was first disclosed to the public in 2016. The vulnerability was discovered in upstream Linux platforms such as Redhat, and Android, which kernel is based on Linux. It was categorized as a serious privilege escalation flaw that allows an attacker to gain root access on the targeted system. Dirty COW attacks on Android has been silent since its discovery, perhaps because it took attackers some time to build a stable exploit for major devices. Almost a year later, Trend Micro researchers captured samples of ZNIU (detected as AndroidOS_ZNIU)—the first malware family to exploit the vulnerability on the Android platform.

The ZNIU malware was detected in more than 40 countries last month, with the majority of the victims found in China and India. We also detected the malware in the U.S., Japan, Canada, Germany, and Indonesia. As of this writing, we have detected more than 5,000 affected users. Our data also shows that more than 1,200 malicious apps that carry ZNIU were found in malicious websites with an existing rootkit that exploits Dirty COW, disguising themselves as pornography and game apps, among others.

Figure 1 porn app

Figure 1: Porn app where ZNIU hides

We worked on a Proof-of-Concept (PoC) for Dirty COW last year and found out that all versions of the Android OS were susceptible to exploitation, while ZNIU’s leveraging of Dirty COW only works on Android devices with ARM/X86 64-bit architecture. However, this recent exploit can bypass SELinux and plant a root backdoor, while the PoC can only modify the service code of the system.

We monitored six ZNIU rootkits, four of which were Dirty COW exploits. The other two were KingoRoot, a rooting app, and the Iovyroot exploit (CVE-2015-1805). ZNIU used KingoRoot and Iovyroot because they can root ARM 32-bit CPU devices, which the rootkit for Dirty COW cannot.

Infection Flow

The ZNIU malware often appears as a porn app downloaded from malicious websites, where users are tricked into clicking on a malicious URL that installs the malware-carrying app on their device. Once launched, ZNIU will communicate with its C&C server. If an update to its code is available, it retrieves it from the C&C server and loads it into the system. Simultaneously, the Dirty COW exploit will be used to provide local privilege escalation to overcome system restrictions and plant a backdoor for potential remote control attacks in the future.

Figure 2 ZNIU infection chain

Figure 2: ZNIU infection chain

After entering the main UI of the device, the malware will harvest the carrier information of the user. It then transacts with the carrier through an SMS-enabled payment service, allowing the malware operator to pose as the device owner. Through the victim’s mobile device, the operator behind ZNIU will collect money through the carrier’s payment service. In one of our samples, we saw in its code that payments were directed to a dummy company, which, based on network traffic, we were able to locate in a city in China censored in the picture below. When the SMS transaction is over, the malware will delete the messages from the device, leaving no sign of the transaction between the carrier and the malware operator. If the carrier is outside China, there will be no possible SMS transaction with the carrier, but the malware will still exploit the system to plant a backdoor.

Figure 3 Transaction request sent by the malware to the carrier

Figure 3: Transaction request sent by the malware to the carrier

Based on our analysis, the malware only appears to victimize users subscribed to China’s carriers. Moreover, even though the malware operator can set the amount higher to gain more money from the exploitation, every transaction amount is deliberately set in small amounts (20 RMB or 3 USD monthly) to avoid being noticed.

Figure 4 Screenshot of the SMS transactions

Figure 4: Screenshot of the SMS transactions

Since the Android OS is enforcing user interaction when it comes to granting permission for other apps to access the SMS feature of the device, ZNIU needs root privilege to make its scheme work. The malware also needs to plant a backdoor and remotely load additional malicious code later on to continue profiting from its victims.

A Closer Look at the ZNIU Rootkit

The ZNIU rootkit may be integrated into malicious apps through an independent broadcast receiver.

Figure 5 Snipper of ZNIU code

Figure 5: Snipper of ZNIU code activated on the network

The malware can easily inject the rootkit to a third party app without changing its other components. This practice is considered helpful for a massive malware distribution.

The malware operator encrypts and packs ZNIU’s malicious DEX codes for protection, which is an attempt to shield it from static reverse engineering. After further investigation, we found out that it uses the broadcast receiver to activate the exploit code once the user connects the device to a network or by simply plugging it into a power source. The malware then directly transmits and executes the malicious native codes.

Figure 6 ZNIU native codes

Figure 6: ZNIU native codes

The main logic of ZNIU’s native code works as follows:

1. Collect the model information of the device.

2. Fetch appropriate rootkits from the remote server.

3. Decrypt the exploits.

4. Trigger exploits one by one, check the result, and remove exploit files.

5. Report if the exploit succeeded or failed.

Figure 7 ZNIU network activity

Figure 7: ZNIU network activity

The URL of the remote exploit server, as well as the communication between client and server, were also discovered to be encrypted. But after using string decryption, details of the malicious exploit server were further explored, revealing that its domain and server host is located in China. The link of the malicious exploit server can be found in the appendix.

Figure 8 Backend exploit management server

Figure 8: The backend exploit management server

Once downloaded, the rootkit ‘exp*.ziu’ will be decompressed into ‘exp*.inf’ with the help of ZLIB.

Figure 9 ZLIB decompressing a ziu file

Figure 9: ZLIB decompressing a ziu file

All files needed by the rootkit are packed in one. inf file, with a filename that starts with ‘ulnz’ and contains several ELF or script files.

Figure 10 Structure of the inf file

Figure 10: Structure of the inf file

The ZNIU rootkit can arbitrarily write to vDSO (virtual dynamically linked shared object), which exports a set of kernel space functions to the user space so that applications perform better. The vDSO code runs in a kernel context, which does not have a SELinux limit.

ZNIU uses public exploit code to write shellcodes to vDSO and create a reverse shell. Then it patches the SELinux policy to disarm restrictions and plant a backdoor root shell.

Figure 11 Dirty COW patching vDSO code

Figure 11: Dirty COW patching vDSO code


Users should only install apps from the Google Play or trusted third-party app stores and use mobile security solutions such as Trend Micro™ Mobile Security to block threats that may leverage Dirty COW from app stores before they can be installed. Users can also check with their device manufacturer and/or phone carriers to get the patch for this vulnerability.

Trend Micro’s Mobile App Reputation Service (MARS) already covers Android and iOS threats using leading sandbox and machine learning technology. It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerability.

Enterprise users should also consider installing a solution like Trend Micro™ Mobile Security for Enterprise. This features device management, data protection, application management, compliance management, configuration provisioning, and other features so employers can balance privacy and security with the flexibility and added productivity of BYOD programs.

We are currently monitoring ZNIU’s activity, and we will update the blog entry for further findings and analyses. A list of Indicators of Compromise (IoCs) comprising related hashes (SHA256), package names, and app labels, can be found in this appendix.

With additional analysis by Jason Gu, Veo Zhang, and Seven Shen

Updated as of September 27, 2017, 2:30 AM PDT. Further observation revealed more than 300,000 malicious apps that carry the ZNIU malware in the wild, with more than 140,000 of those apps possessing unique labels. We also discovered that some of the samples’ app labels had confusing symbols and characters inserted in their names. This was deliberately done to avoid detection. The appendix for these additional samples can be found here.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

ZNIU: First Android Malware to Exploit Dirty COW Vulnerability

from TrendLabs Security Intelligence Blog http://ift.tt/2xCfwKJ

Google’s PixelBook: The Target Is Way Bigger Than You Think

The atmosphere around the Chrome Unboxed office this week is one of excitement, anticipation, a little confusion and an overall sense that Google is up to something with the upcoming PixelBook that is much, much bigger than what we have seen on the surface

There are so many thoughts as to why Google would be releasing such a high-dollar device and the opinions are as diverse and ingenious as they come. The fact still remains that until Oct. 4 only Google really knows the motive behind this game-changing Chrome device known simply as the Google PixelBook.

Why did Google drop the Chromebook nomenclature? Who knows, but in my opinion, I think Chromebook PixelBook sounds a bit redundant. There’s also the fact that this device could very well be the Chrome OS counterpart to similar PCs from other platforms. MacBook, Surface Book, etc: it’s kind of like a little club.

Again, Google will hopefully shed some light on all of this in San Francisco in two weeks. Until then, we have been gathering some very interesting evidence surrounding not only the PixelBook but what may be a much larger initiative by Google that will be championed by this new device.

My Theory

I call this a theory but I’ll be honest, between my gut, the mounting pile of puzzle pieces from the Chromium repository and recent moves from Google, I will go so far as to say that I am convinced this is what the search giant is up to.

First, there is the insanely large amount of storage that Google looks to be offering in the PixelBook. Robby and a number of our readers have made some really good arguments as to why the new Chromebook would have so much hard drive space. I’ll let you take a look and form whatever opinion you like.

Let’s not forget that, if we are correct, this new Chromebook we know as ‘Eve’ will be equipped with newer NVME SSD storage which is leaps and bounds faster than the traditional eMMC drives found in most Chrome devices.

But why?

Android Apps? Highly unlikely. The standard onboard storage on any given Chromebook is more than fast enough to read, write or anything else it needs to do for Android applications that were designed for much smaller devices.

Not to mention the sheer size of the storage. I barely flirt with 64GB of storage on my phone. Why on Earth would I need 512GB on my Chromebook when it isn’t normally my go-to device for things like Snapchat or Instagram?

Just saying: it doesn’t really feel like a legitimate reason.

Then there is the rumored price of the PixelBook. If the reports were correct (I saw the ad for myself on my own Chromebook and the number was real), the top-tier PixelBook will come in just under $1800. That’s a lot of cheese, even for a Pixel-branded Chromebook. Then again, this isn’t the same breed of a device as the 2015 Chromebook Pixel and Google’s interests have expanded exponentially in the computer market as of late.

Yes, it’s a lot of money. No, it won’t be a device your average consumer is going to go pick up on a whim. On the flip side of that, many – and I mean many – have scoffed at the price while I have countless friends and acquaintances who have dropped 2-3 grand on a MacBook without thinking twice.

The fact is if you want this device and it’s capable of doing what you need it to do, you’ll buy it. If not, there are plenty of great Chromebooks out there to choose from that will cost you less than $500.

With all that being said, I will cut to the chase and share my thoughts on who I think Google is really targeting with the new PixelBook. From there, we will work our way back and try to fill in some of the blanks.


Now I know this may sound like a simple answer – and believe me there is much more to this than I can comprehend – but over the last couple of weeks, I have stumbled upon more and more signs pointing to the fact that Google has set their sights on the corporate sector.

First, let’s talk VM or virtual machines. Late last month, Google announced the rebranding of the Chrome Management Console to Chrome Enterprises. This was much more than a logistical change in names, however. Along with the upgrade, Google brought some new tools to the table for companies to better adopt Chrome OS while still leveraging the power of their current infrastructure.

This is where virtual machines come in. Companies like VMWare are giving enterprises the capability to access corporate software via virtual environments on the Chrome OS desktop. This is nothing new. VMWare has offered these services for some time but now it has become an integrated part of the Chrome Enterprise platform.

VM Extensions

VM extensions are essentially tools that allow users to access, deploy, configure and install software across multiple virtual machines. One of the biggest uses of these extensions is in the Microsoft Azure container-based, cloud platform developed for – you guessed it – enterprises.

Why does this matter?

Recently, I stumbled upon the addition of VM extensions to one of the devices being developed in the Chromium repository. After a few hours of digging, I found that this device was the first Chromebook to have this “feature” turned on.

Here are the details:

Eve: turn on VM extensions

Stop disabling VM extensions on Eve. VMs will be used to host containers soon.

That’s right, ‘Eve’ or as we are convinced, the Google PixelBook. Whatever Google is planning, it appears that the PixelBook will have the ability to run VM extension making it a host or administrative device for any number of other devices.

Did you notice the commit about mentioned “containers?” Well, this plays a large part in the hypothesis of where Google is headed.

Chrome OS isn’t new to the container game. The long-awaited Android on Chromebooks movement works on this very principle.  I am completely inept when it comes to explaining how the container environment works, but if you’d like to learn a little more about, here’s a handy little PDF that breaks down the details.

Running Android in a container on Chrome OS.

To dumb it down, whatever application, software or program that is being implemented is packaged independently to run on top or alongside the native OS and that package is encapsulated in a container. This allows the program to run using the OS’s resources and structure while keeping it isolated from the core of the OS.

With enough development, the container method could potentially allow full desktop work environments to run “natively” on top of Chrome OS in the same way Android does now.

All of this lines up with what Google is already doing with Chrome Enterprise. Virtual desktops, headless software, cloud computing and even Linux workstations may soon be accessible from Chrome devices.

Speaking of workstations, it’s no secret the Googler’s use a multitude of devices including MacBooks and Linux desktops for development and other tasks. While a Chromebook is capable of running a Linux environment via the hacky, dual-boot method, they weren’t designed with that particular task in mind. So Google and many other companies default to actual Linux stations for development and hosting platforms.

With the abilities of containers on board, a device like the PixelBook would be more than capable of being a well-rounded development computer or even be used as the host for a whole network of computing systems.

I would propose that what Microsoft Azure is already doing, Google is looking to take a bite out of. The PixelBook could be the poster-child of this movement.

The plot thickened even more when I unearthed some work being done on Chromebook ‘Eve’ that involved support for Microsoft-specific HID (human interface device) tools. From my limited understanding, it appears that the new Chromebook will have built-in support for Microsoft’s protocols for things like palm rejection on touchpads and touchscreens.

If the Chrome device isn’t running, emulating or “containerizing” some form of Windows or Microsoft software, why the need for this support?

I took a closer look at the owner of the commit, Dmitry Torokhov, and found that he has been a software engineer for the Chrome OS team since 2014. Prior to that, he spent almost 6 years working on Virtual devices for none other than VMWare.

Coincidence? I don’t believe in them, but your guess is as good as mine.

Then there was a little news story going around about Google offering to send Chromebooks to Microsoft Azure partners to give them an opportunity to talk about what they have to offer to the Virtual Machine market.

All of this brings us full-circle and might answer the question about the large amount of storage on the PixelBook. A developer’s device needs drive space. A hosting computer has to have room for stuff. The more, the better.

Clearly, Google is positioning itself in multiple aspects to make its move on the enterprise market. Now, I think all of the pieces are in place and much as they did with the education sector, they are poised to have a major impact on the antiquated business arena.

The PixelBook has the potential to be the perfect device for this kind of move. Yes, as a consumer device it’s pricey. But, as an high-end, developer’s laptop it should have all the computing power a large infrastructure needs while still being cheaper than many of its Windows, Mac or Linux competitors.

The rabbit-hole continues to go deeper and deeper as we dig up details on Google’s new device and their future plans for Chrome OS. Check back tomorrow as we go more in-depth sharing our perspective on what the end-game may be.

What do you think? Could Google be looking to conquer the corporate world or is the PixelBook really just another “because we can” kind of device?

Shop Chromebooks On Amazon

from Chrome Unboxed – The Latest Chrome OS News http://ift.tt/2xBxblS

Red Alert 2.0: New Android Banking Trojan for Sale on Hacking Forums

The Recent discoveries of dangerous variants of the Android banking Trojan families, including




, and


, present a significant threat to online users who may have their login credentials and valuable personal data stolen.

Security researchers from SfyLabs have now


a new Android banking Trojan that is being rented on many dark websites for $500 per month, SfyLabs’ researcher Han Sahin told The Hacker News.


Red Alert 2.0

, the Android banking malware has been fully written from scratch, unlike other banking trojans, such as


and ExoBot, which were evolved from the leaked source code of older trojans.

The Red Alert banking malware has been distributed via many online hacking forums since last few months, and its creators have continuously been updating the malware to add new functionalities in an effort to make it a dangerous threat to potential victims.

Malware Blocks Incoming Calls from Banks

Like most other Android banking trojans, Red Alert has a large number of capabilities such as stealing login credentials, hijacking SMS messages, displaying an overlay on the top of legitimate apps, contact list harvesting, among others.

Besides this, Red Alert actors have also added an interesting functionality to its malware, like blocking and logging all incoming calls associated with banks and financial associations.

This would potentially allow the Red Alert malware to prevent warnings of a compromised account to be received by the victims from their associated banks.

Malware Uses Twitter As Backup C&C Infrastructure

Another most interesting thing about Red Alert 2.0 is that it uses Twitter to prevent losing bots when its command and control server is knocked offline.

“When the bot fails to connect to the hardcoded C2 it will retrieve a new C2 from a Twitter account,” SfyLabs researchers said in a blog post. 

“This is something we have seen in the desktop banking malware world before, but the first time we see it happening in an Android banking trojan.”

The Red Alert 2.0 is currently targeting victims from more than 60 banks and social media apps across the world and works on Android 6.0 (Marshmallow) and previous versions.

Here’s How the Red Alert 2.0 Trojan Works:

Once installed on victim’s phone via the third-party app store, the malware waits for the victim to open a banking or social media app, whose interface it can simulate, and once detected, the Trojan immediately overlays the original app with a fake user interface.

The fake interface then informs the victim that there is an error while logging the user in and requests the user to re-authenticate his/her account.

As soon as the user enters the credentials into the fake user interface, Red Alert records them and sends them to the attacker-controlled command and control (C&C) server to be used by the attackers to hijack the account.

In case of banking apps, the recorded information is being used by attackers to initiate fraudulent transactions and drain the victim’s bank account.

Since Red Alert 2.0 can also intercept SMS text messages received by the infected smartphone, the trojan could work around two-factor authentication techniques that otherwise are designed to throttle such attacks.

Ways to Protect Yourself Against Such Android Banking Trojans

The easiest way to prevent yourself from being a victim of one such

mobile banking Trojan

is to avoid downloading apps via third-party app stores or links provided in SMS messages or emails.

Just to be on the safer side, go to Settings → Security and make sure “Unknown sources” option is turned off on your Android device that blocks installation of apps from unknown sources.

Most importantly, verify app permissions before installing any app, even from official Google Play Store, and if you find any application asking more than what it is meant for, just do not install it.

It is always a good idea to install an anti-virus app from a reputed vendor that can detect and block such Trojan before it can infect your device.

Also, always keep your system and apps up-to-date.

from THN : The Hacker News http://ift.tt/2yaPuLO

Yet Another Android Malware Infects Over 4.2 Million Google Play Store Users

Even after so many efforts by Google, malicious apps somehow managed to fool its Play Store’s anti-malware protections and infect people with malicious software.

The same happened once again when at least 50 apps managed to make its way onto Google Play Store and were successfully downloaded as many as 4.2 million times—one of the biggest malware outbreaks.

Security firm Check Point on Thursday published a

blog post

revealing at least 50 Android apps that were free to download on official Play Store and were downloaded between 1 million and 4.2 million times before Google removed them.

These Android apps come with hidden malware payload that secretly registers victims for paid online services, sends fraudulent premium text messages from victims’ smartphones and leaves them to pay the bill—all without the knowledge or permission of users.



by Check Point researchers because it was found in the Lovely Wallpaper app, the malware comes hidden in free wallpaper, video or photo editing apps. It’s a new variant of malware that Mcafee


earlier this year on the Play Store.

But what makes ExpensiveWall malware different from its other variants is that it makes use of an advanced obfuscation technique called “packed,” which compresses malicious code and encrypts it to evade Google Play Store’s built-in anti-malware protections.

The researchers notified Google of the malicious apps on August 7, and the software giant quickly removed all of them, but within few days, the malware re-emerged on the Play Store and infected over 5,000 devices before it was removed four days later, Check Point said.

Here’s How ExpensiveWall Malware Works:

Once an app with ExpensiveWall—which researchers think came from a software development kit called GTK—is downloaded on a victim’s device, the malicious app asks for user’s permission to access the Internet, and send and receive SMS messages.

The internet access is used by the malware to connect the victim’s device to the attacker’s command and control server, where it sends information on the infected handset, including its location alongside unique hardware identifiers, such as MAC and IP addresses, IMSI and IMEI numbers.

The C&C server then sends the malware a URL, which it opens in an embedded WebView window to download JavaScript code that begins to clock up bills for the victim by sending fraudulent premium SMS messages without their knowledge, and uses the victim’s phone number to register for paid services.

However, according to the Check Point researchers, it is still unclear how much revenue was generated via ExpensiveWall’s premium SMS scam.

Google’s Play Store—Home for Malware

Android malware continues to evolve with more sophisticated and never-seen-before capabilities with every passing day, and spotting them on Google Play Store has become quite a common thing.

Last month, over

500 Android apps with spyware capabilities

were found on Play Store, which had been downloaded more than 100 million times.

In July,

Lipizzan spyware apps

were spotted on Play Store that can steal a whole lot of information on users, including text messages, emails, voice calls, photos, location data, and other files, and spy on them.

In June, more than

800 Xavier-laden apps

were discovered on Google Play that had been downloaded millions of times, and the same month researchers found first

code injecting rooting malware

making rounds on Google Play Store.

A month prior to it, researchers spotted 41 apps on Play Store hidden with the

Judy Malware

that infected 36.5 million Android devices with malicious ad-click software.

In April, over

40 apps with hidden FalseGuide

malware were spotted on Play Store that made 2 Million Android users victims.

Earlier this year, researchers also discovered a new variant of the

HummingBad malware

, dubbed


, hidden in more than 20 apps on Google Play Store, which were downloaded by over 12 Million users.

How to Protect Your Android From Such Malware Apps

Even after Google removed all the malware-tainted apps from its official Play Store marketplace, your smartphones will remain infected with the ExpensiveWall malware until you explicitly uninstall the malicious apps, if you have downloaded any.

Google has recently provided a security feature known as

Play Protect

that uses machine learning and app usage analysis to automatically remove malicious apps from the affected smartphones to prevent further harm.

However, according to the Check Point researchers, many phones run an older version of Android that does not support the feature, leaving a wide audience open to malware attacks.

You are strongly advised to always keep a good antivirus app on your device that can detect and block any malicious app before it can infect your device, and always keep your device and all apps up-to-date.

from The Hacker News http://ift.tt/2ybfmbb

Does your mobile anti-virus app protect or infect you? The truth behind DU Antivirus Security

With mobile attacks representing nearly 20% of all cyberattacks in the Americas during the first half of 2017, users are constantly warned to be aware of security risks affecting their data and privacy, and install security software to protect their device. But what happens when antivirus solutions can’t be trusted, and actually compromise users’ privacy?

Check Point mobile threat researchers recently discovered a free mobile anti-virus app developed by the DU group, a developer of Android apps, which collects user data without the device owners’ consent. The app, called DU Antivirus Security, was distributed over Google Play, Google’s official app store, and downloaded between 10 and 50 million times, according to Google Play data.

Figure 1: The DU Antivirus Security app on Google Play

According to Check Point’s research, when the app runs for the first time, the DU Antivirus Security app collects information from the device, such as unique identifiers, contact list, call logs, and potentially the location of the device. This information is then encrypted and sent to a remote server. The customer information is later used by another app offered by the DU group, called “Caller ID & Call Block – DU Caller,” which provides users with information about incoming phone calls.

While users trusted DU Antivirus Security to protect private information, it did the exact opposite. It collected the personal information of its users without permission and used that private information for commercial purposes. Information about your personal calls, who you’re speaking with and for how long, was logged and later used.

Check Point reported the illegal use of the users’ private information to Google on August 21, 2017, and the app was removed from Google Play on August 24, 2017. A new version that doesn’t include the harmful code was uploaded to the Play store on August 28, 2017. Version number 3.1.5 of DU Antivirus Security is the latest version number found to include this privacy-leaking code, but older versions might still include it.

In addition to DU Antivirus Security, Check Point researchers detected the same code in 30 other apps, 12 of which were found on Google Play, and subsequently removed. These apps probably implemented the code as an external library, and transmitted the stolen data to the same remote server used by DU Caller. All in all, the illicit code affected between 24 and 89 million users who installed these apps, according to Google Play data.

Users who installed the DU Antivirus Security or any of the other apps should verify they are upgrading to the latest version that does not include this code.

Since anti-virus apps have a legitimate reason to request unusually extensive permissions, they are the perfect cover for fraudsters looking to abuse these permissions. In some cases, mobile anti-virus apps are even used as a decoy for delivering malware. Users should be aware of these suspicious anti-virus solutions, and use only mobile threat protection from reputable vendors that are proven to be capable of safeguarding mobile devices and the data stored in them.

Technical Details:

DU Antivirus Security steals the information from the user’s device when the app is first run. The stolen information is then sent to the server caller.work, which is not registered to DU apps. However, this domain has two subdomains which indicate it is indeed connected to the DU caller app. First, the subdomain http://reg.caller.work/ is a PHP webpage, which specifies its hostname: us02-Du_caller02.usaws02, and contains the name of the DU caller app.

See Check Point Research for the complete technical report.

In addition, the sub domain vfun.caller.work is hosted on IP, a private server which also hosts the domain dailypush.news. This domain is registered to zhanliangliu@gmail.com, a Baidu employee, who used the same email address to post about parsing phone numbers (http://ift.tt/2yjVHpw). Since the DU apps are part of the Baidu group, and the post deals with a functionality related to the caller app, this indicates a connection between the stolen information and the caller app.

Figure 2: Connections between DU Antivirus Security app and Caller app

The DU caller app already came under fire for an ambiguous privacy policy, which displays different terms on separate pages, and of executing its activity regardless of whether it received the user’s consent. Last year, Cheetah Mobile’s Anti-Virus faced similar accusations after providing a service which may violate privacy regulations.


The post Does your mobile anti-virus app protect or infect you? The truth behind DU Antivirus Security appeared first on Check Point Blog.

from Check Point Blog http://ift.tt/2yjVFxU

ExpensiveWall: A dangerous ‘packed’ malware on Google Play that will hit your wallet

Check Point’s mobile threat research team identified a new variant of an Android malware that sends fraudulent premium SMS messages and charges users’ accounts for fake services without their knowledge. According to Google Play data, the malware infected at least 50 apps and was downloaded between 1 million and 4.2 million times before the affected apps were removed.

The new strain of malware is dubbed ‘ExpensiveWall,’ after one of the apps it uses to infect devices, ‘Lovely Wallpaper.’ ExpensiveWall is a new variant of a malware found earlier this year on Google Play. Downloads of the entire malware family reached between 5.9 million and 21.1 million.

What makes ExpensiveWall different than its other family members is that it is ‘packed’ – an advanced obfuscation technique used by malware developers to encrypt malicious code – allowing it to evade Google Play’s built-in anti-malware protections.

Learn how SandBlast Mobile protects against malware like ExpensiveWall.

Check Point notified Google about ExpensiveWall on August 7, 2017, and Google promptly removed the reported samples from its store. However, even after the affected Apps were removed, within days another sample infiltrated Google Play, infecting more than 5,000 devices before it was removed four days later.

Figure 1: One of the malicious apps containing ExpensiveWall.

It’s important to point out that any infected app installed before it was removed from the App store, still remains installed on users’ devices. Users who downloaded these apps are therefore still at risk and should manually remove them from their devices.

What does ExpensiveWall do?

The malware registers victims to premium services without their knowledge and sends fraudulent premium SMS messages, charging their accounts for fake services.

Why is ExpensiveWall dangerous?

While ExpensiveWall is currently designed only to generate profit from its victims, a similar malware could be easily modified to use the same infrastructure in order to capture pictures, record audio, and even steal sensitive data and send the data to a command and control (C&C) server. Since the malware is capable of operating silently, all of this illicit activity takes place without the victim’s knowledge, turning it into the ultimate spying tool.

How does ExpensiveWall work?

Once ExpensiveWall is downloaded, it requests several common permissions, including internet access – which allows the app to connect to its C&C server – and SMS permissions – which enable it to send premium SMS messages and register users for other paid services all without the users knowledge.

While these permissions are harmful within the context of a malware, many apps request the same permissions for legitimate purposes. Most users grant these permissions without thinking, especially when installing an app from a trustworthy source such as Google Play.

ExpensiveWall contains an interface that connects between in-app actions and the JavaScript code, which runs on a web interface called WebView, meaning JavaScript running inside the WebView can trigger in-app activities. After it is installed and granted the necessary permissions, ExpensiveWall sends data about the infected device to its C&C server, including its location and unique identifiers, such as MAC and IP addresses, IMSI, and IMEI.


Figure 2: Clicking functionality used by the ExpensiveWall malware.

Each time the device is switched on, or experiences a connectivity change, the app connects to its C&C server and receives a URL, which it opens in an embedded WebView. This page contains a malicious JavaScript code that can invoke in-app functions using JavascriptInterface, like subscribing them to premium services and sending SMS messages. The malware initiates the JavaScript code by silently clicking on the links in the webpage, in the same way it clicks on ads in other occasions.

Subscribing victims to paid services

The malware obtains the device’s phone number and uses it to subscribe the user to different paid services, such as the example below:

Figure 3: Code used to obtain phone number.


Figure 4: A premium service the malware subscribes the user to.

Sending premium SMS messages

In some cases, the SMS activity takes place without giving the user any notice. In other cases, the malware presents the user with a button called “Continue,” and once the user clicks the button, the malware sends a premium SMS on his behalf. Below is an example of the HTML code containing the embedded JavaScript:

Figure 5: embedded JavaScript responsible for sending SMS messages.

ExpensiveWall on Google Play

The malicious activities did not go unnoticed by the users, as one notes below:

Figure 6: User’s comments on an ExpensiveWall app.


As seen in the image above, many users suspected that ExpensiveWall was a malicious app. The comments indicate that the app is promoted on several social networks including Instagram, which might explain how it came to be downloaded so many times.

See Check Point Research for the complete technical report.

After analyzing different samples of the malware, Check Point mobile threat researchers believe ExpensiveWall is spread to different apps as an SDK called “gtk,” which developers embed in their own apps. Three versions of apps containing the malicious code exist. The first is the unpacked version, which was discovered earlier this year. The second is the packed version, which is being discussed here, and the third contains the code but does not actively use it.

Users and organizations should be awre that any malware attack is a severe breach of their mobile network, even if it starts out as a seemingly harmless adware. ExpensiveWall is yet another example of the immediate need to protect all mobile devices against advanced threats.

How to stay protected
Cutting-edge malware such as ExpensiveWall requires advanced protections, capable of identifying and
blocking zero-day malware by using both static and dynamic app analysis. Only by examining the
malware within context of its operation on a device can successful strategies to block it be created.
Users and enterprises should treat their mobile devices just like any other part of their network, and
protect them with the best cybersecurity solutions available.

Check Point customers are protected by SandBlast Mobile, and on the network front by Check Point
Anti-Bot blade, which provides protection against this threat with the signature:

The post ExpensiveWall: A dangerous ‘packed’ malware on Google Play that will hit your wallet appeared first on Check Point Blog.

from Check Point Blog http://ift.tt/2wIxFnX