H.G. Wells once said: “Adapt or perish, now as ever, is nature’s inexorable imperative.” Although Wells was talking about the future of the human species when he said this, the quote can also be applied to malware. There is a constant and largely unseen battle being waged between malware authors and security vendors; attackers want to compromise your computer and get up to no good, while the security professionals want to stop malware authors from getting what they want. If malware authors just created malware and released it into the wild without continually adapting it, then security vendors would locate, analyze, block, and render the malware useless in no time at all. The attackers know this and understand that they must “adapt or perish.”
Symantec Security Response recently published an in-depth look at ransomware, discussing its evolution over time to become one of today’s most troublesome malware categories for Windows computers. Mobile devices have now become a prime target for ransomware and attackers use various tricks and tactics to try and remain undetected by the static analysis tools and static signature systems used by security vendors.
Android ransomware has come a long way since it first emerged in 2013 with the discovery of the device-locking malware (Android.Fakedefender). Less than a year later, the first file-encrypting Android ransomware appeared (Android.Simplocker), making it clear that mobile ransomware was becoming more advanced. That trend has continued to this day and, with malware authors realizing the huge number of potential victims out there, we can be sure this threat will continue to evolve.
The Android.Lockdroid and Android.Simplocker malware families can be used to demonstrate how ransomware authors continuously apply different methods to make sure their creations evolve. By looking at how these two malware families have adapted, this blog will show how ransomware authors have been adopting tricks from desktop-based threats in order to make detection and analysis more difficult.
Teaching a new dog old tricks
Icons – hiding in plain sight
In the past, even though variants were deliberately made to look different from a code and data perspective, some of the resource files, such as images and icons, were left unchanged. Then, a change started to set in and new variants began using different image files (some modified at the pixel level in order to generate different hashes). However, this step has proven ineffective as it is relatively easy to identify subtle differences in image files. Newer variants have taken things a step further, as they have quit storing images as .png files in the app package and have started using the data URI (uniform resource identifier) scheme to store images. The data URI scheme provides a way to include data in-line in web pages as if they were external resources. This allows the images to be stored inline as Base64-encoded data.
Figure 1. Images stored in-line using data URI
Stringing things along
By manipulating the data strings, Android ransomware can make itself look different when analyzed by scanning tools. To this end, Symantec has observed many tricks used by variants that span the range from simple to innovative, including the following:
1. Representing the strings in reverse
In static form, the strings are stored in reverse format. The correct version is constructed and used during runtime. This means that the actual strings are not apparent during static analysis; a trick used to try outsmarting rudimentary analysis tools.
Figure 2. Reversed strings
2. Simple Base64 encoding with junk character padding
This tactic involves the actual strings being either appended or prepended with a set of junk character sequences. The resultant string is then Base64-encoded and used in the malware’s code. During runtime, the process is done in reverse order to get the actual strings (the strings are first Base64-decoded and then the appended or prepended junk character sequence is removed to get the actual string).
Figure 3. Junk character padding and Base64-encoded string
Figure 4. Static strings – “What we see”
Figure 5. Runtime strings – “What we get”
3. Encrypting strings
Sometimes strings are AES-encrypted with a hardcoded encryption key. Encrypting the strings means that what static analysis tools see will be nonsensical. The strings will only make sense once the malware is running and the strings have been decrypted. This is again designed to make it more difficult to spot the real contents during a cursory analysis of the code.
Figure 6. AES utility with hardcoded encryption key
4. Fragmented strings and fragmented strings with Unicode
In order to avoid static analysis tools searching for certain strings, some variants break up strings using spaces and commas or other similar characters. Unicode may also be used; for example the word “Child’s” may be represented as “Child\u2019s” because \u2019 is Unicode for an apostrophe (‘). This only becomes apparent when the code is executed.
Figure 7. String fragmentation examples
The methods listed previously are not mutually exclusive and some variants use a combination of tactics. For example, malware may first pad the strings with junk characters, then use Base64 encoding, and then use AES encryption.
Anti-analysis tricks
Android ransomware also uses a variety of methods to attempt to slow down static analysis tools and frameworks, including the following:
1. Creating deliberate variable name ambiguity
This trick aims to produce class files with multiple fields that have the same name. This is accomplished by manipulating the field_id structure in the DEX (Dalvik Executable) file format by modifying the name_idx field value to point to the same string_id entry for all the variables. This creates a decompiled/disassembled output with the same name for all the manipulated variables, creating ambiguity for trivial static analyzers.
Figure 8. Manipulated field_id structure causes different fields to have the same name after disassembly
2. Spaghetti code with multiple function calls
This trick is borrowed from malware designed for Windows computers. As illustrated in Figure 9, multiple meaningless junk functions are invoked during the normal code flow to create a spaghetti structure. This is unnecessarily convoluted code that has lots of branching from one piece of code to another in an effort to slow down analysis.
Figure 9. Spaghetti code block
3. Using junk arithmetic null computations throughout the code
This trick is also borrowed from desktop malware and involves multiple junk arithmetic operations being performed, which are not used. These instructions are put there to increase the time it takes for static code analysis.
Figure 10. Code with junk arithmetic operations
Figure 11. Code without junk arithmetic operations
4. Dynamically loading the DEX file(s) and storing data in .apk resources
In more recent variants, the main payload code is stored as one or more encrypted DEX files inside the asset folder. During runtime, the asset file is decrypted and loaded dynamically using DexClassLoader. The payload is then executed.
Another trick involves storing URLs and other string data in the resources of the Android package file (.apk) and then accessing it using a code-data bridge (R.java) at runtime. By hiding certain data in .apk resources, the malware authors are attempting to sidestep analysis methods.
Never ending arms race
Malware authors’ attempts to outmaneuver security professionals by changing tactics and employing tricks like the ones described in this blog are sure to continue indefinitely. As long as there are profits to be made, cybercriminals will keep trying to outsmart whoever is standing in their way. Symantec is constantly watching for new evasion techniques and can quickly adapt and even pre-empt some moves made by the criminals behind these threats. Fortunately, H.G. Well’s quote “adapt or perish” also applies to security vendors and Symantec continues to work hard to keep users safe and stay one step ahead of bad guys.
Protection
Symantec recommends users to follow these best practices to stay protected from mobile ransomware:
- Refrain from downloading apps from unfamiliar sites and only install apps from trusted sources
- Pay close attention to the permissions that apps request
- Install a suitable mobile security app, such as Norton, in order to protect your device and data
- Keep your software up to date
- Make frequent backups of important data
Symantec and Norton products detect the threats discussed in this blog as: