Clever Smartphone Malware Concealment Technique

This is clever:

Malicious apps hosted in the Google Play market are trying a clever trick to avoid detection—they monitor the motion-sensor input of an infected device before installing a powerful banking trojan to make sure it doesn’t load on emulators researchers use to detect attacks.

The thinking behind the monitoring is that sensors in real end-user devices will record motion as people use them. By contrast, emulators used by security researchers—and possibly Google employees screening apps submitted to Play—are less likely to use sensors. Two Google Play apps recently caught dropping the Anubis banking malware on infected devices would activate the payload only when motion was detected first. Otherwise, the trojan would remain dormant.

Tags: concealment, Google, malware, phones

Posted on January 21, 2019 at 6:47 AM • 20 Comments

Comments

Xavier • January 21, 2019 7:32 AM

Looks like the trick VW and other used to defeat the emission testing.

Clive Robinson • January 21, 2019 8:09 AM

It’s kind of a follow on from research to detect what the user is entering on the touch screen. Only a whole lot easier to do.

I suspect any “signs of life” sensor can be used in a similar way, thus this is another step in the arms escalation race between malware developers and researchers.

If on reading this you think “Doh that’s so simple…” that’s the real point of the “thinking hinky” behind it, “It’s so obvious that nobody thought to do it before…”

Mailman • January 21, 2019 8:37 AM

This will force security researchers to add a whole bunch of realism to their testing machines. Add life into the motion sensor, but also realistic variations of the battery level, phone call history, text message history, and so on

Wael • January 21, 2019 9:36 AM

This’s an example of a method that defected from defense to offense. In some sensitive mobile applications that handle PII, for example, the application checks for a few things (among others) before it collects / handles PII or other sensitive material:

Device is not in Debug mode / tethered to a debugger
Device is not rooted / jailbroken (although that’s sometimes bypass-able)
Application is not running on an emulator

It’s expected the offense side will do everything to avoid detection, in this case by making sure the malware feature checks for the last item on the list before it reveals it’s malicious intent. Clever, but hardly innovative, imho. Testing needs to happen on an emulator and on the real device. Also, the emulator needs to be able to mimic the real device as closely as possible, which makes the job of the defense team more difficult!

The discovery of this tactic may imply (not sure, haven’t read the whole thing) that it was uncovered during dynamic analysis of the application, so better static analysis that looks at the binary for unusual constructs needs to be improved, AI/ML or otherwise.

Impossibly Stupid • January 21, 2019 9:50 AM

There are so many derivatives and proxies of activity that can be measured that it’s an impossible game to win (e.g., turn on only after being installed for over an hour and used in 3 different locations over 10 miles apart). Instead of a continued arms race, I’d rather have the ability to turn off all the sensor monitoring done by a device. Smart phones have rapidly become a very dumb idea.

me • January 21, 2019 10:51 AM

same happens for pc:
-check if documents directory is empty or there is actual user data
-check for mouse move
-check for debuggers…

i’d say that all this is typical
what i would call clever is the use of undocumented intel instructions that probably does not exist in emulator or virtual machines

the most funny thing is that if you use Qubes OS everything is virtualized and a virus might refuse to run exactly because of that!
because he knows that it’s a vm and think that it’s a malware analyst vm.

Andy • January 21, 2019 12:29 PM

Author was a gmail.com account. What is Google doing to catch the thief?

Macaroni • January 21, 2019 2:19 PM

Reegarding migration from offense to defense.

IMO banks and others bring this problem on themselves becuase they use “safety” as an excuse to invade privacy. My own bank is a case in point. It wants my GPS location, my phones serial number, and IMEI yet it refuses to enable any type of two factor identification. I simply cannot take a banks claims to security seriously if it does not support a yubikey.

Jan-Willem • January 21, 2019 3:30 PM

Yes, it is clever. But we have to realize that always people (and hence criminals) try to move around an obstacle. When the car industry introduced the kill switch or immobilizer (I don’t know the exact English word for it – I mean the technique that a car can’t start without the proper key, just by connecting some cables), this led to an increase in breaking in houses to get the keys.

maus • January 21, 2019 3:38 PM

“IMO banks and others bring this problem on themselves becuase they use “safety” as an excuse to invade privacy. My own bank is a case in point. It wants my GPS location, my phones serial number, and IMEI yet it refuses to enable any type of two factor identification. I simply cannot take a banks claims to security seriously if it does not support a yubikey.”

Invade privacy to what end (that does not serve security ends) and does not support any multifactor, or specifically everything but a yubikey?

Givon Zirkind • January 22, 2019 6:40 AM

I recently re-read a statement, that hackers aren’t the geniuses that people think. They do possess traits. One is tenacity and the willingness to do mundane repetitive tasks to acheive their goal.

IMHO, the simplicity of this attack demonstrates that. Not overly, technically complicated. A cute trick. Which takes some technical know-how to apply.

And, genius is in simplicity. 🙂

RealFakeNews • January 22, 2019 10:46 AM

Didn’t we see this before with malware/viruses, looking for handset motion to detect emulators??

65535 • January 22, 2019 8:17 PM

@ Andy

“Author was a gmail.com account. What is Google doing to catch the thief?” –Andy

Good question.

I also note the Anibus Banking Trojan avoided VirusTotal detection by Giggle.

“The downloaders themselves are rather stealthy, and VirusTotal missed all but one of the samples. The one that was found had zero detections by antivirus engines…Figure 2: No detection rates on malicious downloaders…To circumvent ever-evolving app store defenses, mobile malware distributors rely on a strategy from the PC malware realms: Instead of uploading the actual malware to the store, which can result in sampling and detection at a very early stage in the distribution chain, they upload a downloader that may seem rather innocuous compared to actual malware…the malicious downloader, the app fetches BankBot Anubis from one of its C&C servers. The BankBot Anubis malware then masquerades as an app called “Google Protect” and prompts the user to grant it accessibility rights…Why ask for accessibility? BankBot Anubis uses Android’s Accessibility services to perform keylogging as a way to obtain the infected user’s credentials when he or she accesses a targeted mobile banking app…X-Force estimated the magnitude of campaigns on Google Play by the number of downloads, as well as the number and variety of payloads found. In one case, the researchers fetched more than 1,000 new samples of BankBot Anubis from just one C&C server. Each sample has a different MD5 signature, few of which were documented by any antivirus engine when tested against VirusTotal…”-SecurityIntelligence or IBM X-Force

[screen shot of VirusTotal 0 infections out of 62 AVs]

And

“…results of infection campaigns, mobile malware operators consider official app stores to be the holy grail. Getting a malicious app into an official store [Giggle] yields greater exposure to more potential victims, a cheap distribution channel and user trust.”- SecurityIntelligence or IBM X-Force

https://securityintelligence.com/anubis-strikes-again-mobile-malware-continues-to-plague-users-in-official-app-stores/

Hum, it makes you wonder if Giggle’s VirusTotal is providing a false sense of security to its users… not to mention Giggle’s app store.

The motion detection use – detector module is clever – although as mentioned malware that detects mouse movements on pc boxes is about the same [a human is there]. It is not a totally new idea yet still clever.

Clive Robinson • January 23, 2019 5:46 AM

@ 65535, ALL,

The motion detection use – detector module is clever – although as mentioned malware that detects mouse movements on pc boxes is about the same [a human is there]. It is not a totally new idea yet still clever.

And one ripe for future development…

Look at it this way, humans find it hard to be repetative in their fine control muscle movments. Machines on the otherhand find it very difficult to be that random.

I can thus see a “filter” war developing between black hats and white hats, and to be honest I think on balance the black hats have it on anything less than a complex mechanical device…

Oh and if they also tie it in to the GPS as well the white hats will have a bit of a problem. Thus will have to come up with a new “Test lab” methodology, which could be expensive.

And yes before people ask I have thought out a simplish filter for the black hat side based on three simple integrating circuits with slow medium and fast time constants followed by “a little spice”.

Clive Robinson • January 23, 2019 6:31 AM

@ ALL,

Speaking of “Clever Smartphone Malware Concealment Technique” there is another method that’s a little more general than just “Snartphones”.

For some reason even though it was written five years ago not only is this still current, it pops up from time to time as a discussion subject on other blogs etc.

Basically that little flash memory card you put in just about all smart devices (especially the Android ones) contain realy poor quality Flash chips and to hide that fact a quite fast running microcontroller chip to hide the defects with clever algorithms.

Well those microcontrolers can frequently be “reprogrammed” without much difficulty…

Which gives an interesting array of possibilities, like for instance a MiTM attack base for putting in persistant malware at boot time in the likes of Raspberry Pi’s and similar that boot from memory cards. Hidden encrypted volumes on the flash device, and quite a few other tricks I can think of that are just plain nasty 😉

Any way it’s a relatively short and easy read with some nice photos,

https://www.bunniestudios.com/blog/?p=3554

Maxwell's Daemon • January 23, 2019 1:44 PM

One minor nit: You do have the option under Developer Options to use a selectable location simulator. If you go further, root for instance, there are other interesting applications to go further than that. Still, simple exclusion from trojan installation when those are detected should still present a large number of devices suitable for exploitation.

[My bank constantly complains about having the developer options enabled. As if I’m going to remove that level of control over device capabilities (exploitation surface)!]

A Nonny Bunny • January 26, 2019 2:41 PM

@Clive Robinson

Look at it this way, humans find it hard to be repetative in their fine control muscle movments. Machines on the otherhand find it very difficult to be that random.

If you have a statistical model that allows you decide whether behaviour is random enough to be human, then you have a statistical model that can inform a machine to be random enough to pass that same test.

Clive Robinson • January 26, 2019 8:04 PM

@ A Nonny Bunny,

If you have a statistical model that allows you decide whether behaviour is random enough to be human, then you have a statistical model that can inform a machine to be random enough to pass that same test.

In theory that is true…

But in practice it does not help you build a machine that can behave that way in a lab. For one reason, it would have to get up and leave the lab to get a sufficient delta on GPS points, likewise the accelerometers as in those used in inertial navigation would give away that the phone was being used in a test jig in a lab.

It’s why these tricks are like the electronic warefare game. First you have ECM, then the otherside develops ECCM, then back the ball goes and we get ECCCM… One side “pings” the other side “pongs” and back and forth it goes like a 1970’s TV Game until beyoned cost effective.

The problem in this case is the malware writers have only a one time fairly low cost software investment on each iteration. The malware investigating lab on the other hand has a rapidly mounting expensive mechanical device cost. Thus the odds of the malware investigating lab winning this particular war are not favourable.

Your view on this may differ but then your POV is probably different to mine. For my sins I’ve worked on and off since the late 1970’s with robots, industrial control systems and bomb disposal “wheelbarrows”, and have had to “think hinky” with such systems such as IED devices that could not be “defused” just “maybe disrupted” with a well placed shaped charge etc. Thankfully most improvised explosive device builders are not technically sophisticated (or have not been so far) and usually lack access to a reasonable work/machine shop. But I guess you could say the real experts are those that design anti-tamper and similar systems for nuke ‘physics packages”.

JG4 • January 27, 2019 9:34 AM

@Clive – The lab environment could play back GPS signals recorded previously. Or synthesize them de novo. It gets easier all the time. When we were kids, this would have been science fiction:

RF TRANS NPN 2.6V 85GHZ 4TSFP $0.48
https://www.digikey.com/product-detail/en/infineon-technologies/BFP840FESDH6327XTSA1/BFP840FESDH6327XTSA1CT-ND

Speaking of IEDs, Guy Fawkes must have repurposed the urine from tens of thousands of people in his attempt to piss on government.

Clive Robinson • January 27, 2019 2:55 PM

@ JG4,

Speaking of IEDs, Guy Fawkes must have repurposed the urine from tens of thousands of people in his attempt to piss on government.

Yes, I know they say “thar be gold in dem der hills” but urine is a rather useful agent in all sorts of industrial processes…

Take a thin sheet of lead and roll it up to form a loose role. Put it in a potery pot and fill with urine and wait… After some weeks remove the now very white role of lead and scrape the white off. Wash, dry and grind the white powder and sell it to paint makers to make “brilliant white gloss” paint. Which is fine unless your little rug rat chews it or you decide to take the paint of with a blow torch and scraper…

Mind you have you ever tried procesing “sour urine” for making gun powder? It’s not that difficult but it smells horribly when you do for months… Oh and as with all human waste product there is a small but very real probability of sepsis which can kill you in hours so wear cloves and other IPE.

Two basic ways “midden in a bag” and “manure in a barrel”.

The compost method is easyist but does not give as high a yield, but it’s also the way you make fertilizing compost for your garden when growing the likes of tomatoes and other nitrate wanting veg (see crop rotation).

Basically you start a compost heap with the vegetable waste from kitchen and garden. You simply pee on it every so often depending on the weather. To much pee can poison the bacteria that do the composting process. Any way after a year to 18months you go to the “wash stage” which is common to both bag and barrel methods.

For the barrel method Get a 50-100 gallon drum and fill with fresh herbivour crap, stable mucking out is best because the horse has probably peed on it as well. Add urine and water to the mix and after a good stirring just let it sit around for around ten months topping it of with more urine and giving it a stirring as required.

The wash process is to remove the sold matter from the required in solution nitrate. Basically add a lot of water to either sirring it up every hour or so for a day or so. Drain off the liquid to let dry off and crystallize or go to the next process. Put the sived and filtered out muck on the garden as it still has fertilizer properties.

Take the drawn off wash liquid and add in a lot of “wood ash” also known as “potash” when you make it. This converts one type of nitrate (calcium) to a more usefull nitrate (potasium). It’s exactly the same process as you use to get the “boil liquid” when making soap the very old way with animal fat that had started to turn rancid so was no good for frying or baking (use it or loose it).

Filter and crystallize out the nitrate. This can be used for making black powder or for making nitrate salt “meat cure” for charcuterie etc (guess what the corns are in real coned beef, and the curing salt for bacon and salami 😉

The usuall mix for sulfur free blackpowder is 4 measures of nitrate, to one measure of charcoal. You need to grind them quite finely especially the charcoal BEFOR mixing them together. There is a warning about sulfur free black powder that can cause it to be more explosive than normal due to Carbon monoxide production. Apparently the sulfur acts like an “anti-knock” or “pinking” agent the same as lead did in petrol.

Schneier on Security

Clever Smartphone Malware Concealment Technique

Comments

Leave a comment Cancel reply