What is cloaking in Android malware?

Cloaking is a technique used by some Android malware to evade detection and analysis by security solutions or users. On other words, its process of using multiple techniques to making certain in-app behaviors dependent on specific conditions in order to avoid the detection or witness of those behavior.

Why understanding clocking is important for malware analyzers

• Most of malwares show different behaviors when running in virtual machine. Therefore if you don’t know this point you probably missing a lot.
• Due to referrer cloaking the source of the app installation matters downloading from VT(Virus Total) can cause a much different experience than installing from an in-the-wild source.
• Malware developers expect you to look at their app during a relatively short time-window, during deep-dive investigations try to run the malware for at least 72 hours to see the full picture.

Universal Cloaking Techniques

Even across multiple platforms campaigns successfully utilizing cloaking usually include most of the following elements:

1. Setting up a C2 infrastructure to invoke specific behaviors based on network responses. Your C2 controller say to agent what and when to do some works
2. Gathering client-side data about the system resulting in a fingerprint that can be reproduceable across install attempts, generally results in a persistent device identifier either provided system or unique to the campaign itself
3. The unique device identifier is often accompanied by a one time installation ID allowing the camping to track number of attempts per persistent device identifier. For example if C2 controller sees a device installed the app more than four times in 24-hours is potential analyst not going target them.
4. Ensuring network requests aren’t coming from blocked ASN such as a cloud provider, VPN-provider, or a known AV vendor. Most of AV vendors register net-blocks and malware C2 controller can find them.
5. Server-side systems in place to block behaviors for certain device IDs.

Common Android Device Checks

• Checking the CameraInfo interface

  • Non emulators usually have a flash

  CameraInfo  |  Android Developers

• Registering a sensor event listener

  • Checking for light sensors
  • Checking for accelerometer

  SensorEventListener  |  Android Developers

• Checking the kernel version and build name

  • Automated analysis systems usually deploy kernel level hooks and are likely to have a custom build name or version number

• Reading the /proc/cpuinfo or /proc/tty/drivers

  • Checking for X86 —> ARM translation
  • Checking for GOLDFISH drivers common to Android Emulators

• Parsing of Android.OS.Build class

  Build  |  Android Developers

• Time Based

  • Malware developers knows our time is limited, therefore they wait for 24-houres or more to ensure you’re a real user