This post describes our work analyzing several samples which appear to be mobile variants of the FinFisher Toolkit, and ongoing scanning we are performing that has identified more apparent FinFisher command and control servers.
Earlier this year, Bahraini Human Rights activists were targeted by an email campaign that delivered a sophisticated Trojan. In From Bahrain with Love: FinFisher’s Spy Kit Exposed? we characterized the malware, and suggested that it appeared to be FinSpy, part of the FinFisher commercial surveillance toolkit. Vernon Silver concurrently reported our findings in Bloomberg, providing background on the attack and the analysis, and highlighting links to FinFisher’s parent company, Gamma International.
After these initial reports, Rapid7, a Boston-based security company, produced a follow-up analysis that identified apparent FinFisher Command and Control (C&C) servers on five continents. After the release of the Rapid7 report, Gamma International representatives spoke with Bloomberg and The New York Times’ Bits Blog, and denied that the servers found in 10 countries were instances of their products.
Following these analyses, we were contacted by both the security and activist communities with potentially interesting samples. From these, we identified several apparent mobile Trojans for the iOS, Android, BlackBerry, Windows Mobile and Symbian platforms. Based on our analysis, we found these tools to be consistent in functionality with claims made in the documentation for the FinSpy Mobile product, a component of the FinFisher toolkit. Several samples appear to be either demo versions or “unpackaged” versions ready to be customized, while others appear to be samples in active use.
Promotional literature describes this product as providing:
- Recording of common communications like Voice Calls, SMS/MMS and Emails
- Live Surveillance through silent calls
- File Download (Contacts, Calendar, Pictures, Files)
- Country Tracing of Target (GPS and Cell ID)
- Full Recording of all BlackBerry Messenger communications
- Covert Communications with Headquarters
In addition to analysis of these samples, we are conducting an ongoing scan for FinFisher C&C servers, and have identified potential servers in the following countries: Bahrain, Brunei, the Czech Republic, Ethiopia, Indonesia, Mongolia, Singapore, the Netherlands, Turkmenistan, and the United Arab Emirates (UAE).
It was developed for Arm7, built against iOS SDK 5.1 on OSX 10.7.3 and it appears that it will run on iPhone 4, 4S, iPad 1, 2, 3, and iPod touch 3, 4 on iOS 4.0 and up.
The bundle is called “install_manager.app” and the contents of it are:
Investigation of the Mach-0 binary ‘install_manager’ reveals the text “FinSpy”:
Further references to “FinSpy” were identified in the binary:
Additionally, it appears that a developer’s certificate belonging to Martin Muench, who is described in The New York Times as Managing Director of Gamma International GmbH and head of the FinFisher product portfolio, is used:
An ad-hoc distribution profile is present: “testapp”:
Will expire on 02.04.2013.
The profile matches the bundle ID (home.install-manager).
The profile was signed by 3 certificates.
The profile may be used by one developer:
Developer Certificate “iPhone Distribution: Martin Muench”.
This certificate was used to sign the bundle.
The code signature contains 3 certificates:
Will expire on 09.02.2035.
Your keychain contains this root certificate.
Certificate “Apple Worldwide Developer Relations Certification Authority”:
Will expire on 14.02.2016.
Certificate “iPhone Distribution: Martin Muench”:
Will expire on 03.04.2013.
SHA1 fingerprint: “1F921F276754ED8441D99FB0222A096A0B6E5C65”.
The Application has been provisioned to run on the following devices, represented here by their Unique Device Identifiers (UDID):
The file is hidden using Spring Board options, and on execution the sample writes out logind.app to /System/Library/CoreServices. ‘logind’ exists on OSX but not normally on iOS.
It then installs: /System/Library/LaunchDaemons/com.apple.logind.plist
This creates persistence on reboot. It launches the logind process, then deletes install_manager.app.
On reboot it runs early in the boot process with ID 47:
This then drops SyncData.app. This application is signed, and the provisioning stipulates:
“Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements.”
This application appears to provide functionality for call logging:
Exfiltration of contacts:
Target location enumeration:
As well as arbitrary data exfiltration, SMS interception and more.
SyncData.app exfiltrates base64 encoded data about the device (including the IMEI, IMSI etc) to a remote cellular number.
The ‘logind’ process attempts to talk to a remote command and control server, the configuration information for which appears to be stored in base64 encoded form in “SyncData.app/84C.dat”.
The _CodeSignature/CodeResources file suggests that install manager drops logind.app, SyncData.app and Trampoline.app (Trampoline.app has not been examined).
The Android samples identified come in the form of APKs.
The application appears to install itself as “Android Services”:
It requests the following permissions:
The first 200 files in the apk are named “assets/Configurations/dummsX.dat”, where X is a number from 0-199. The files are 0 bytes in length. The file header entries in the compressed file are normal, but the directory header entries contain configuration information.
The code in the my.api.Extractor.getConfiguration() method opens up the APK file and searches for directory entry headers (PK\x01\x02) then copies 6 bytes from the entry starting at offset 36. These are the “internal file attributes” and “external file attributes” fields. The code grabs these sequences until it hits a 0 value.This creates a base64 encoded string.
The app decodes this string and stores it in a file named 84c.dat (similar to the iOS sample discussed earlier).
Here’s the output from one of the samples:
The Base64 decoded hexdump is:
Note that the hostnames demo-de.gamma-international.de and ff-demo.blogdns.org are suggestive of a demo or pre-customisation version of the FinSpy Mobile tool and are similar to domains identified in our previous report.
We identified samples structurally similar to this sample that spoke to servers in the United Kingdom and the Czech Republic:
Command and Control: 22.214.171.124
Country: United Kingdom
Company: PlusNet Technologies
Command and Control: 126.96.36.199
Country: Czech Republic
Company: T-Systems Czech Republic
Note that the Czech sample speaks to the same command and control server previously identified by Rapid7.
Samples for Nokia’s Symbian platform were identified:
The first sample (“Symbian.sisx”) identifies itself as “System Update” and appears to have been built on the 29th of May 2012, at 14:20:57 UTC.
The certificate is registered to a email@example.com. WHOIS information indicates that www.cyanengineeringservices.com was anonymously registered (date of first registration: 07-Mar-07) with GoDaddy using Domains By Proxy. Although it includes an attractive front page that states “Mobile Software Development” for “Windows Mobile, iPhone, Android, Symbian and Blackberry,” all links (e.g. “Products” “About Us” or “Contacts”) lead to an “under construction” blank page.
The sample contains the following components:
The file “c:\sys\bin\updater.exe” provides the main implant functionality. This requests the following capabilities1:
Of special note is the use of TrustedUI. As mentioned in the security section of the Nokia developer notes for Symbian:
“Trusted UI dialogs are rare. They must be used only when confidentiality and security are critical: for instance for password dialogs. Normal access to the user interface and the screen does not require this.”
The second sample (“mysym.sisx”) identifies itself as “Installation File” and appears to be signed by the “Symbian CA I” for “Cyan Engineering Services SAL (offshore),” unlike the previous sample, which was registered to firstname.lastname@example.org.
We identified “Cyan Engineering Services SAL (offshore)” as also listed as the registrant on the parked domain www.it-intrusion.com, (Created: 08-Dec-11, also with GoDaddy). However, it-intrusion.com does not have a protected registrant. The registrant is listed2 as a company based in Beirut, Lebanon:
Broadway Center, 7th Floor
Hamra Street – Chouran 1102-2050
Beirut, Beirut 00000
Domain Domain Name: IT-INTRUSION.COM
Administrative Contact: Debs, Johnny
The registrant information for Cyan Engineering Services SAL also connects to Gamma: the name “Johnny Debs” is associated with Gamma International: a Johnny Debs was listed as representing Gamma at the October 2011 Milpol in Paris, and the name occurs elsewhere in discussions of FinFisher.
Examination of this sample reveals the domain demo-01.gamma-international.de potentially indicating a demo or pre-customisation copy.
The phone number +60123839897 also shows up in the sample. It has a Malaysian country code.
The identified samples contained the following files:
The .cod files are signed by RIM’s RBB, RCR, and RRT keys. RBB stands for “RIM BlackBerry Apps API,” which allows manipulation of BlackBerry apps, RCR stands for “RIM Crypto API,” which allows access to crypto libraries, and RRT stands for “RIM Runtime API,” which allows access to other phone functionality such as sending SMS messages.
The signature process is described in RIM’s documentation [pdf] about the Blackberry Signing Authority. First, a developer registers a public key with the Blackberry Signing Authority. In order to obtain a signed application, the developer submits a signature request (including his identity and a hash of the binary) signed with his private key to the Signing Authority. The Signing Authority verifies that the signer is authorized to make requests, and, if so, replies with a copy of the hash signed with the relevant RIM private key. The developer then appends the signature to his binary.
The .jad file contains the following hashes for the .cod files:
RIM-COD-SHA1: 0f 3b d8 d1 84 da 35 4e 10 94 89 c0 d6 08 70 ad 5e 7a f3 e0
The .jad file also contains a blob of base64 encoded data with the key “RIM-COD-Config.” This data contains the URL of the command & control server, TCP ports, phone numbers to exfiltrate data to via SMS, identifiers for the Trojan and target, active modules, and various other configuration parameters.
Decoding this reveals the following servers and phone numbers:
+6281310xxxxx4 – Indonesia
+49456xxxxx6 – Germany
Upon installation, the user is presented with the following screen:
As evidenced by the above screenshot, the app is listed as:
Common Communication Update DSCH/USCH V32
Directly after installing, the application requests enhanced permissions:
The following screen pops up showing the requested permissions:
Scrolling down reveals:
After the user accepts these permissions, the sample attempts to connect to both Internet-based and SMS-based command & control servers. Another sample we analyzed appeared to write a debug log to the device’s filesystem. The following information was observed written to the log regarding communication with command & control services.
We decompiled the Blackberry sample. We provide a high-level overview of the more interesting classes that we successfully decompiled:
These appeared to contain a database comprising the following GSM APNs. The significance of this database is that it only includes a small set of countries and providers:
Indonesia: indosatgprs, AXIS, telkomsel, www.xlgprs.net, 3gprs
Brazil: claro.com.br, wapgprs.oi.com.br, tim.br
This appears to do the main app installation, as well as uninstallation. Installation includes negotiating for enhanced permissions, base64-decoding the “RIM-COD-Config” configuration, and setting up and installing the Configuration. If the configuration contains a “removal date,” then automatic removal is scheduled for this time. Installation also involves instantiating “listener” modules, as specified below:
This appears to listen for changes to the address book. It implements the net.rim.blackberry.api.pim.PIMListListener interface.
This module logs and manipulates phone events, and appears to enable “remote listening” functionality, where the FinSpy Master can silently call an infected phone to listen to conversation in its vicinity (this is referred to as a SpyCall in the code). The module has a facility to hide incoming calls by manipulating the UI, cancelling buzzer and vibration alerts, and toggling the backlight. Upon instantiation, the module calls “*43#” to enable call waiting. If a remote listening call from the master is active, then legitimate incoming calls will trigger call waiting. The module detects these legitimate incoming calls, and places the SpyCall call on call waiting, presenting the legitimate incoming call to the user.
This appears to record sent and received email messages.
net.rmi.device.api.fsmbb.core.listener.MessengerObserver (Module #68)
This seems to record BBM messages. It appears to do this by periodically checking the path “file:///store/home/user/im/BlackBerry Messenger/”
This module implements:
Contrary to its name, OutboundMessageListener allows listening for both incoming and outgoing SMS messages. This module also checks for incoming SMS commands from the FinSpy Master. These commands can include an “emergency configuration” update, that can include new addresses and phone numbers for the FinSpy Master.
net.rmi.device.api.fsmbb.core.listener.WAObserver (Module #82)
This appears to monitor WhatsApp, the popular proprietary cross-platform messaging application. It locates the WhatsApp process ID by searching for module names that contain the string “WhatsApp.”
At some point, the module calls getForegroundProcessId to see if the WhatsApp process ID is in the foreground. If so, it seems to take a screenshot of the WhatsApp application, via Display.Screenshot. It appears that this screenshot is checked via “.equals” to see if there is any new information on the WhatsApp screen. If there is new information, the screenshot is then JPEG encoded via JPEGEncodedImage.encode.
Appears to contain the mechanics of communication with the command & control server, including the plaintext TLV-based wire protocol.
The Windows Mobile samples we identified are:
All the samples appeared similar, most likely belonging to the same branch release. The relevant parts of the binary are stored in five different resources:
- The first resource contains an OMA Client Provisioning XML file, which is used to store root certificates for running privileged/unprivileged code on the device. In this case it only contained some default example values shipped with Microsoft Windows Mobile SDK.
- The second resource contains the actual dropped payload which contains all the Trojan functionalities.
- The third resource contains a binary configuration file.
- The fourth and fifth resources contain two additional DLL files which are dropped along with the payload.
The main implant is dropped as “services.exe” with the libraries dropped as mapiwinarm.dll and mswservice.dll.
The payload has the following attributes:
File size: 186640 bytes
This is a multi-threaded and modular engine which is able to run and coordinate a series of events providing interception and monitoring capabilities. When the application starts, a core initialization function is invoked, responsible for preparing execution and launching the main thread.
The main thread consequently runs a set of core components on multiple threads:
- Routines responsible for handling the “heartbeat” notifications.
- Routines which control the execution of the Trojan and its components while monitoring the status of the device.
- A routine which can be used to “wake up” the device.
- A component which handles emergency SMS communications.
- A routine that initializes the use of the Radio Interface Layer.
- A core component that manages a set of surveillance modules.
The Trojan utilises a “Heartbeat Manager”, which is a set of functions and routines that, depending on the status of the device or monitored events, communicates notifications back to the command and control server.
These beacons are sent according the following events:
- First beacon.
- A specified time interval elapsing.
- The device has low memory.
- The device has low battery.
- The device changed physical location.
- The Trojan has recorded data available.
- The device has connected to a cellular network.
- The device has a data link available.
- The device connects to a WiFi network.
- An incoming / outgoing call starts.
- The Mobile Country Code (MCC) or Mobile Network Code (MNC) ID changed.
- The Trojan is being uninstalled.
- The SIM changes.
Notifications are sent via SMS, 3G and WiFi, according to availability. Consistent with other platforms, the windows mobile version appears to use base64 encoding for all communications.
In response to such notifications, the implant is able to receive and process commands such as:
KEEP_CONNECTION_ALIVE_CMD IGNORED b/c it’s an SMS answer
The command and control server is defined in the configuration file found in the third resource of the dropper. In this sample, the sample connected to the domain: demo-04.gamma-international.de
This suggests that such sample is either a demo version or “unpackaged” version ready to be customized.
Together with a DNS or IP command and control server, each sample appears to be provided with two phone numbers which are used for SMS notifications.
The core surveillance and offensive capabilities of the Trojan are implemented through the use of several different modules. These modules are initialized by a routine we called ModulesManager, which loads and launches them in separate threads:
There are multiple modules available, including:
- AddressBook: Providing exfiltration of details from contacts stored in the local address book.
- CallInterception: Used to intercept voice calls, record them and store them for later transmission.
- PhoneCallLog: Exfiltrates information on all performed, received and missed calls stored in a local log file.
- SMS: Records all incoming and outgoing SMS messages and stores them for later transmission.
- Tracking: Tracks the GPS locations of the device.
In order to manipulate phone calls, the Trojan makes use of the functions provided by RIL.dll, the Radio Interface Layer.
Some of the functions imported and used can be observed below:
In order to exfiltrate call logs, the Trojan uses functions provided by the Windows Mobile Phone Library.
Using PhoneOpenCallLog() and PhoneGetCallLogEntry(), the implant is able to retrieve the following struct for each call being registered by the system:
} CALLLOGENTRY, * PCALLLOGENTRY;
This contains timestamps, numbers, names and other data associated with a call.
The physical tracking of the device uses the GPS Intermediate Driver functions available on the Windows Mobile/CE platform:
After a successful GPSOpenDevice() call, it invokes GPSGetPosition() which gives access to a GPS_POSITION struct containing the following information:
} GPS_POSITION, *PGPS_POSITION;
This provides the latitude and longitude of the current location of the device.
Command and Control Server Scanning Results
Following up on our earlier analysis, we scanned IP addresses in several countries looking for FinSpy command & control servers. At a high level, our scans probed IP addresses in each country, and attempted to perform the handshake distinctive to the FinSpy command and control protocol. If a server responded to the handshake, we marked it as a FinSpy node. We expect to release our scanning tools with a more complete description of methodology in a follow-up blog post.
Our scanning yielded two key findings. First, we have identified several more countries where FinSpy Command and Control servers were operating. Scanning has thus far revealed two servers in Brunei, one in Turkmenistan’s Ministry of Communications, two in Singapore, one in the Netherlands, a new server in Indonesia, and a new server in Bahrain.
Second, we have been able to partially replicate the conclusions of an analysis by Rapid7, which reported finding FinSpy command & control servers in ten countries: Indonesia, Australia, Qatar, Ethiopia, Czech Republic, Estonia, USA, Mongolia, Latvia, and the UAE. We were able to confirm the presence of FinSpy on all of the servers reported by Rapid7 that were still available to be scanned. We confirmed FinSpy servers in Indonesia, Ethiopia, USA, Mongolia, and the UAE. The remaining servers were down at scanning time. We also noted that the server in the USA appeared to be an IP-layer proxy (e.g., in the style of Network Address Translation)3.
Rapid7’s work exploited a temporary anomaly in FinSpy command & control servers. Researchers at Rapid7 noticed that the command & control server in Bahrain responded to HTTP requests with the string “Hallo Steffi.” This behavior did not seem to be active on Bahrain’s server prior to the release of our analysis. Rapid7 looked at historical scanning information, and noticed that servers in ten other countries had responded to HTTP requests with “Hallo Steffi” at various times over the previous month. While the meaning of this string and the reason for the temporary anomaly are unknown, a possible explanation is that this was a testing deployment of a server update, and the “Hallo Steffi” message indicated successful receipt of the update. After the publication of Rapid7’s analysis, the behavior began to disappear from FinSpy servers.
Details of Observed Servers
Table 1: New Servers
|Singapore||188.8.131.52||21, 53, 443, 4111||HostSG|
|Singapore||184.108.40.206||21, 53, 80, 443, 4111||M1 CONNECT PTE. LTD.|
|Bahrain||220.127.116.11||22, 53, 80, 443, 4111||Batelco|
|Turkmenistan||18.104.22.168||22, 53, 80, 443, 4111, 9111||Ministry of Communications|
|Brunei||22.214.171.124||4111, 9111||Telekom Brunei|
|Indonesia||126.96.36.199||22, 53, 80, 443, 9111||Biznet ISP|
|Netherlands||188.8.131.52||80, 1111||Tilaa VPS Hosting|
Table 2: Confirmed Rapid7 Servers
|Indonesia||184.108.40.206||22, 25, 53, 80, 443, 4111||Biznet ISP|
|Ethiopia||220.127.116.11||22, 53, 80, 443, 4111, 9111||Ethio Telecom|
|Mongolia||18.104.22.168||53, 80, 443||Mongolia Telecom|
|UAE||22.214.171.124||21, 22, 53, 443, 4111||Emirates Telecommunications Corporation|
It is interesting to note that the USA server on EC2 appeared to be an IP-layer proxy. This judgment was made on the basis of response time comparisons4.
Conclusions + Recommendations
The analysis we have provided here is a continuation of our efforts to analyze what appear to be parts of the FinFisher product portfolio. We found evidence of the functionality that was specified in the FinFisher promotional materials. The tools and company names (e.g. Cyan Engineering Services SAL) found in their certificates also suggest interesting avenues for future research.
These tools provide substantial surveillance functionality; however, we’d like to highlight that, without exploitation of the underlying platforms, all of the samples we’ve described require some form of interaction to install. As with the previously analyzed FinSpy tool this might involve some form of socially engineered e-mail or other delivery, prompting unsuspecting users to execute the program. Or, it might involve covert or coercive physical installation of the tool, or use of a user’s credentials to perform a third-party installation.
We recommend that all users run Anti-Virus software, promptly apply (legitimate) updates when they become available, use screen locks, passwords and device encryption (when available). Do not run untrusted applications and do not allow third parties access to mobile devices.
As part of our ongoing research, we have notified vendors, as well as members of the AV community.
The server was serving FinSpy on port 80, and SSH on port 22. We measured the SYN/ACK RTT on both ports and compared. The results for port 80:
HPING 126.96.36.199 (wlan0 188.8.131.52): S set, 40 headers + 0 data bytes
len=44 ip=184.108.40.206 ttl=24 DF id=0 sport=80 flags=SA seq=0 win=5840 rtt=1510.2 ms
len=44 ip=220.127.116.11 ttl=23 DF id=0 sport=80 flags=SA seq=1 win=5840 rtt=740.4 ms
len=44 ip=18.104.22.168 ttl=25 DF id=0 sport=80 flags=SA seq=2 win=5840 rtt=753.4 ms
len=44 ip=22.214.171.124 ttl=24 DF id=0 sport=80 flags=SA seq=3 win=5840 rtt=1001.6 ms
The results for port 22:
HPING 126.96.36.199 (wlan0 188.8.131.52): S set, 40 headers + 0 data bytes
len=44 ip=184.108.40.206 ttl=49 DF id=0 sport=22 flags=SA seq=0 win=5840 rtt=125.7 ms
len=44 ip=220.127.116.11 ttl=49 DF id=0 sport=22 flags=SA seq=1 win=5840 rtt=124.3 ms
len=44 ip=18.104.22.168 ttl=49 DF id=0 sport=22 flags=SA seq=2 win=5840 rtt=123.3 ms
len=44 ip=22.214.171.124 ttl=50 DF id=0 sport=22 flags=SA seq=3 win=5840 rtt=127.2 ms
The comparison reveals that port 80 TCP traffic was likely being proxied to a different computer.
This is a Morgan Marquis-Boire and Bill Marczak production.
Windows mobile sample analysis by Claudio Guarnieri.
Thanks to Pepi Zawodsky for OSX expertise and assistance.
Thanks to Jon Larimer and Sebastian Porst for Android expertise.