FinSpy spyware analysis

We have collaborated with Amnesty International for whom we have analyzed a new variant of the FinSpy spyware.

Executive summary

By analyzing the sample we found what we suspect to be a new version of the FinFisher’s malware FinSpy for Android.

Even though the malware behavior and capabilities seem to be the same as what it has already been described in the past, this version goes a step further to hide the malware configuration and its capabilities.

This new version we named DexDen has very likely been released between May 2017 and October 2019.

Command and control server associated to the malware configuration is still alive by the time we wrote this report.

In terms of capabilities, the sample we have analyzed is meant to exfiltrate SIM card information, SMS log, call log, calendar events, address book, messages and files from 12 popular messenger applications and to track victim’s location.

This report provides details on how strings are obfuscated, how the communication protocol has evolved and how the extraction of three technical aspects of the malware can give insights on the malware code-base evolution.

Overview

This report focuses on the analysis of the sample described below.

For this analysis we use the following tools:

• Aether to analyze CFG
• Javalang to parse the Java code
• Smalisca to analyze the Smali code
• Yara to detect FinSpy variants
• FinSpy tools to parse the FinSpy configuration

We share the following assets on our GitHub repository:

• java_parser.py to extract obfuscated from Java code
• string_decoder.py to decode obfuscated strings
• table.ods containing TLV types and decoded strings
• FinSpy.yar Yara rules detecting FinSpy variants

Tiny tools#

Yara rules#

rule FinSpy_ConfigInAPK : android apkhideconfig finspy
{
	meta:
		description = "Detect FinFisher FinSpy configuration in APK file. Probably the original FinSpy version."
		date = "2020/08/05"
		reference = "https://github.com/devio/FinSpy-Tools"
		author = "Esther Onfroy a.k.a U+039b - *@0x39b.fr (https://twitter.com/u039b)"

	strings:
		$re = /\x50\x4B\x01\x02[\x00-\xff]{32}[A-Za-z0-9+\/]{6}/

	condition:
		uint32(0) == 0x04034b50 and $re and (#re > 50)
}

rule FinSpy_DexDen : android dexhideconfig finspy
{
	meta:
		description = "Detect FinFisher FinSpy configuration in DEX file. Probably a newer FinSpy variant."
		date = "2020/08/05"
		author = "Esther Onfroy a.k.a U+039b - *@0x39b.fr (https://twitter.com/u039b)"

	strings:
		$config_1 = { 90 5b fe 00 }
		$config_2 = { 70 37 80 00 }
		$config_3 = { 40 38 80 00 }
		$config_4 = { a0 33 84 }
		$config_5 = { 90 79 84 00 }

	condition:
		uint16(0) == 0x6564 and
		#config_1 >= 2 and 
		#config_2 >= 2 and 
		#config_3 >= 2 and 
		#config_4 >= 2 and 
		#config_5 >= 2
}

rule FinSpy_TippyTime: finspyTT
{
	meta:
		description = "Detect FinFisher FinSpy 'TippyTime' variant."
		date = "2020/08/05"
		author = "Esther Onfroy a.k.a U+039b - *@0x39b.fr (https://twitter.com/u039b)"
	strings:
		$config_1 = { 90 5b fe 00 }
		$config_2 = { 70 37 80 00 }
		$config_3 = { 40 38 80 00 }
		$config_4 = { a0 33 84 }
		$config_5 = { 90 79 84 00 }
		$timestamp = { 95 E9 D1 5B }

	condition:
		uint16(0) == 0x6564 and
		$timestamp and
		$config_1 and 
		$config_2 and 
		$config_3 and 
		$config_4 and 
		$config_5
}

rule FinSpy_TippyPad: finspyTP
{
	meta:
		description = "Detect FinFisher FinSpy 'TippyPad' variant."
		date = "2020/08/05"
		author = "Esther Onfroy a.k.a U+039b - *@0x39b.fr (https://twitter.com/u039b)"
	strings:
		$pad_1 = "0123456789abcdef"
		$pad_2 = "fedcba9876543210"

	condition:
		uint16(0) == 0x6564 and
		#pad_1 > 50 and
		#pad_2 > 50
}

Script to plot CFG#

import networkx as nx
from androguard.misc import AnalyzeAPK
from graphviz import Digraph as dg

apk = '<path to you APK>'
a, d, dx = AnalyzeAPK(apk)
call_graph = dx.get_call_graph()
graph = nx.empty_graph()


def clean_name(name):
    return name[0:name.rfind(')')+1]


graphs = {
    'audio': [
        {
            'class': 'Landroid/media/AudioRecord',
            'method': 'startRecording'
        },
        {
            'class': 'Landroid/media/AudioManager',
            'method': 'setMicrophoneMute'
        },
    ],
    'read_sms_configuration': [
        {
            'class': 'Landroid/telephony/SmsMessage',
            'method': 'getPdu'
        },
        {
            'class': 'Landroid/telephony/SmsMessage',
            'method': 'getMessageBody'
        },
        {
            'class': 'Landroid/telephony/SmsMessage',
            'method': 'getUserData'
        },
        {
            'class': 'Lorg/xmlpush/v3/q/c',
            'method': '<init>'
        },
        {
            'class': 'Lorg/xmlpush/v3/q/c',
            'method': 'a',
            'starts_with': 'Lorg/xmlpush/v3/q/c;->a([Ljava'
        },
    ],
}

for g in graphs:
    fg = dg(engine='dot',
            format='png',
            graph_attr={'overlap': 'orthoxy',
                        'diredgeconstraints': 'true',
                        'splines': 'ortho'},
            node_attr={'shape': 'box',
                       'style': 'filled',
                       'fontcolor': '#212529',
                       'fontsize': '10',
                       'fontname': 'sans-serif'})

    methods = []
    for search in graphs[g]:
        for m in dx.find_methods(methodname=search['method'], classname=search['class']):
            if 'starts_with' in search:
                cm = clean_name(str(m.get_method()))
                if cm.startswith(search['starts_with']):
                    methods.append(m)
            else:
                methods.append(m)

    for m in methods:
        fg.node(clean_name(str(m.get_method())), color='#985e6d', fontcolor='white')
        ancestors = nx.ancestors(call_graph, m.get_method())
        ancestors.add(m.get_method())
        graph = call_graph.subgraph(ancestors)
        for n, d in graph.in_degree():
            if d == 0:
                fg.node(clean_name(str(n)), color='#494e6b', fontcolor='white')
        for u, v in graph.edges:
            fg.edge(clean_name(str(u)), clean_name(str(v)))

    fg.render(g)

A suspected new FinSpy version

FinSpy capabilities and technical aspects are widely documented online. In this section we focus on what we suspect to be clues of a new version of FinSpy for Android.

To do so, we investigate on the following parameters:

• location of the FinSpy configuration
• string obfuscation
• local socket address generation
• unknown TLV types

Configuration storage#

As far as we know, FinSpy stores its configuration into APK metadata. It was well documented and extraction tools are available online:

• https://github.com/devio/FinSpy-Tools
• https://github.com/SpiderLabs/malware-analysis/blob/master/Ruby/FinSpy/

The sample we investigate on shows that the FinSpy configuration is stored into the DEX file.

Even if existing extraction tools failed to extract the configuration from the DEX, parsing tools succeeded to parse it. The structure of the configuration remains the same, only its storage location has changed.

We name this FinSpy variant DexDen.

String obfuscation#

As far as we know, FinSpy strings defined in its code are not obfuscated. The sample we analyze is different, all Java strings are obfuscated. Each Java class using strings implements the following 2 Java methods:

• String OOOoOoiIoIIiO0o01I1I00(final int index) returning the obfuscated string as bytes at the given index.
• byte[] i1IlIil011Iiil(final byte[] array, final byte[] array2) decoding an obfuscated string.

Strings are decoded by XORing of the obfuscated one with one of the two pads. The pad is selected according to the index mod 2. Pads are the same for all Java classes using strings:

• 0123456789abcdef
• fedcba9876543210

We have developed a Python script parsing the entire Java code to retrieve obfuscated strings java_parser.py and one to decode them string_decoder.py.

We denote this kind of string obfuscation TippyPad for short.

Local socket address generation#

FinSpy uses Unix socket to communicate between threads. The local socket address is generated by hashing the values of the following system properties:

• ro.product.model
• ro.product.brand
• ro.product.name
• ro.product.device
• ro.product.manufacturer
• ro.build.fingerprint

An utility method meant to encode data and generate local socket address uses the timestamp 1540483477 corresponding to Thu 25 October 2018 16:04:37 UTC. Java method generating local socket address is listed below.

We denote this kind of address generation TippyTime for short.

Unknown TLV types#

After leaks about FinFisher and FinSpy, community has reversed the different TLV values used in data marshaling/unmarshaling to ensure a common data format between C2s and implants. These values are available online: https://github.com/devio/FinSpy-Tools/blob/master/Android/finspyCfgParse.py

The FinSpy version we analyze seems to be using unknown TLV values. To get some meaning about the different unknown TLV values, we reversed existing values. We were able to detect semantic groups based on the binary representation of these values.

The Python script we developed recovers groups based on existing values. Then parses the sample Smali code to extract unknown TLV values. We used a patched version of Smalisca to do so. We have extracted the following suspected unknown TLV values. The entire list of TLV and groups is available in the GitHub repository.

To determine the group the TLV value belongs to just mask that value with 0xFFFFF800.

Conclusion#

Our analysis based on 3 different parameters: configuration location, string obfuscation and local socket address generation tends to demonstrate that the sample we have analyzed is (as far as we know) the only known FinSpy for Android sample storing its configuration directly into the DEX file (DexDen). Reports FinSpy Dokumentation yaraby Thorsten Schröder & Linus Neumann - CCC (Jan. 2020), AccessNow: FinFisher changes tactics to hooks critics (May 2018) and Hacking FinSpy by Sophos (2015) explain how the FinSpy configuration is stored in the APK file metadata. A retro-hunt on VT has found 0 samples (our sample excluded) storing the configuration the DEX. Changing the configuration location is a strong structural change indicating a suspected new version of FinSpy for Android.

A trend emerges when we focus on how the local socket address is generated and how strings are obfuscated. Old samples do not use a “magic” timestamp (TippyTime) in the generation algorithm nor pad-obfuscated strings (TippyPad). By analyzing briefly samples shared by CCC, we observed that since 2017, FinSpy seems to use TippyTime. However, only one sample use TippyPad string obfuscation.

Regarding unknown or undocumented TLV types, we have no clue indicating they are new or not since we have not analyzed other samples in deep and no unknown TLV types have ever been reported.

Sample behavioral analysis

The sample we analyze is heavily obfuscated:

• strings are encoded at the class level;
• Java methods are obfuscated (shortened);
• control flow graph is broken by the heavy use of threads and IPC;
• dummy calls are inserted between almost all the “useful” ones.

To analyze the sample, we firstly do a fast behavioral recon with Aether by extracting control flow graphs in which:

• sinks are Java methods of interest;
• sources are detected entry-points (i.e. services, threads, activities, …).

Secondly we extract TLV types involved in the different control flow graphs and then correlate the meaning of TLV with the meaning of actions done on the OS.

Configuration parsing#

As we have seen before FinSpy stores its configuration into the DEX file. Thus, the first step for it is to locate the DEX file. On Android, the Java method android.content.Context.getPackageCodePath() returns the location of the APK which contains the original DEX (not the optimized one). Once located, the DEX file is copied at a randomly generated path into the cache directory. Once copied, the DEX loaded (or self-loaded since it is loaded by itself) using the Java method dalvik.system.DexClassLoader.loadClass().

Finally, FinSpy parses its configuration stored into the loaded DEX using a large switch-case statement.

The configuration stored into the current sample looks like:

• TlvTypeMobileTargetID = “WIFI”
• TlvTypeMobileTargetHeartbeatInterval = 120
• TlvTypeMobileTargetPositioning = b’\x82\x87\x86\x81\x83'
• TlvTypeConfigTargetProxy = “[redacted]”
• TlvTypeConfigTargetProxy = “[redacted]”
• TlvTypeConfigTargetPort = [redacted]
• TlvTypeConfigSMSPhoneNumber = “[redacted]”
• TlvTypeMobileTrojanID = “WIFI”
• TlvTypeMobileTrojanUID = b’\xfc\x14\xb0\r'
• TlvTypeUserID = 1000
• TlvTypeTrojanMaxInfections = 9
• TlvTypeConfigMobileAutoRemovalDateTime = Thu Jan 1 01:00:00 1970
• TlvTypeConfigAutoRemovalIfNoProxy = 168
• TlvTypeMobileTargetHeartbeatEvents = 173
• TlvTypeMobileTargetHeartbeatRestrictions = b’\xd0\x00'
• TlvTypeMobileTrackingDistance = 1000
• TlvTypeMobileTrackingTimeInterval = 300
• TlvTypeInstalledModules =
  • Logging: Off
  • Spy Call: Off
  • Call Interception: Off
  • SMS: On
  • Address Book: On
  • Tracking: On
  • Phone Logs: On

Note: Trojan UID is the AES sub-key used to encrypt/decrypt payloads exchange with the C2.

Emergency reconfiguration#

FinSpy can be reconfigured by SMS, the Java method org.xmlpush.v3.q.c.a() is dedicated to that. FinSpy uses a lot of threads, probably not for performance purposes but to circumvent automatic reverse engineering of CFG. The following CFG shows the break in the CFG.

When an SMS corresponding to TlvTypeMobileTargetEmergencyConfig is received, FinSpy reconfigures itself by parsing the SMS payload. The following attributes can be reconfigured:

• TlvTypeConfigTargetPort: port for C2 proxy
• TlvTypeConfigSMSPhoneNumber: phone number for SMS based C2 communications
• TlvTypeMobileTrojanID: unknown purpose
• TlvTypeMobileTrojanUID: AES sub-key
• TlvTypeUserID: unknown purpose
• TlvTypeTrojanMaxInfections: unknown purpose
• TlvTypeConfigMobileAutoRemovalDateTime: implant self-destruct past this date
• TlvTypeConfigAutoRemovalIfNoProxy: implant self-destruct if C2 proxy is unavailable
• TlvTypeMobileTargetHeartbeatRestrictions: conditions to avoid callbacks
• TlvTypeMobileTargetHeartbeatEvents: events to trigger callbacks to the C2
• TlvTypeMobileTargetLocationChangedRange: trigger updates based on location changes
• TlvTypeInstalledModules: list of implant features and their configuration (SMS log, call log, etc.)
• and other unknown parameters

Privilege escalation#

FinSpy needs super user privileges to do things like access data of other applications. When started, the implant checks if su is available and then check if the user id is 0. We found no evidence of vulnerability exploitation (DirtyCow or SELinux abuse) like the ones mentioned in other publicly available reports. We did not find ELF hidden into the APK, DEX or into natives libraries packaged in the APK.

Either we have missed something or this sample is tailored to be implanted after exploitation.

Communication with C2#

The implant can use both SMS and HTTP requests to send collected data to the command and control server. Both SMS and HTTP communications use the same marshaling schema based on TLV types describing data. Payload are encrypted before being sent. The encryption mechanism is the same as the one described in AccessNow: FinFisher changes tactics to hooks critics.

Self-destruction capability#

Since FinSpy has the ability to remove itself, it generates a shell script /system/etc/xrebuild.sh listed below.

#!/system/bin/sh
mount -o rw,remount /system
am force-stop <package name>
dd if=/dev/zero of=<apk path> bs=1024 count=8192
find <path> | while read line; do dd if=/dev/zero of=$line bs=1024 count=8192; done

Then it makes the script executable and reboots the device.

The script writes zeros over the APK file and does the same for all files located into the application data directory. FinSpy can be configured to remove itself at a given date and time, when the C2 is not reachable for a given amount of time or when the implant receive a specific command. By filling all files with zeros, FinSpy prevents forensic investigation. The script generation takes in account the fact that the implant can be a system application or a regular application.

Data collection#

Java class org.xmlpush.v3.Services registers the following content observers on:

• changes on phone contact list
• changes on SIM contact list
• changes on SMS log
• changes on calendar

Java class org.xmlpush.v3.eventbased.ReceiverService listens to the following events:

• new outgoing phone call
• new data SMS received
• SIM card has been changed

Numerous threads are started to periodically check device location and messenger applications files. Every time a change occurs on observed data or an event occurs, FinSpy collects data related to that change/event and sends it to the C2 either over HTTP or SMS.

Data collected and sent by default#

The FinSpy code shows that all payloads sent to C2s contain at least:

• trojan UID
• phone number
• timezone
• current date and time
• mobile operator name
• country code based on mobile network
• location area code
• mobile cell ID

Messenger applications data exfiltration#

FinSpy is designed to exfiltrate contacts, messages, groups, location and files of the following applications:

• com.viber.voip
• jp.naver.line.android
• com.skype.raider
• com.facebook.orca
• com.futurebits.instamessage.free
• jp.naver.line.android
• com.viber.voip
• com.skype.raider
• com.futurebits.instamessage.free
• com.bbm
• ch.threema.app
• org.telegram.messenger

FinSpy looks at the content of each application data directory (i.e. /data/data/com.futurebits.instamessage.free/). This capability has already been documented in many public reports.

Call log exfiltration#

FinSpy exfiltrates the following information each time a call is placed:

• caller’s phone number
• callee’s phone number
• caller’s name
• callee’s name
• call duration is seconds

SMS log exfiltration#

FinSpy exfiltrates the following information each time a SMS received:

• date and time
• sender’s phone number
• recipient’s phone number
• SMS content

Calendar events exfiltration#

FinSpy exfiltrates the following information each time a new event is added/edited:

• attendees’ names
• attendees’ emails
• event title
• event description
• event location
• event start and end date

Address book exfiltration#

FinSpy exfiltrates the following information each time a modification is done on the address book:

• work phone number
• mobile phone number
• home phone number
• all other available phone numbers
• display name
• location
• email addresses
• postal addresses

FinSpy collects contacts stored in the phone memory and in the SIM card.

SIM information exfiltration#

Each time the SIM card is changed, FinSpy sends the following data to the C2:

• phone number
• SIM serial number
• IMEI
• IMSI
• network operator name

Location tracking#

FinSpy periodically collects and sends the device location. It collects both GPS based location and network based location by using cells.