Last updated at Wed, 03 Jan 2024 19:39:54 GMT

It's all over the news once again: lawful interception malware discovered in the wild being used by government organizations for intelligence and surveillance activities. We saw it last year when the Chaos Computer Club unveiled a trojan being used by the federal government in Germany, WikiLeaks released a collection of related documents in the Spy Files, we read about an alleged offer from Gamma Group to provide the toolkit FinFisher to the Egyptian government, and we are reading once again now with the same one being delivered to human rights activists in Bahrain along with some spearphishing attacks.

We all are very aware of a rising market of Western companies developing and selling malware for the use of government organizations all around the world, but whenever one of these products is found in other geographical areas, the potential political and ethical implications tend to generate interest.

While I'm trying to provide context for the analysis below, it's not in the scope of this article to digress into the political context of the incident. We are security practitioners interested in technology and when dealing with malware, which in this case can be easily prone to abuses, we want to understand what they do, what's the spread and how we can respond.

The Incident

Several Bahrain activists located both in US and Bahrain started receiving emailswith suspicious attachments:

They promptly understood there was something shady with them and forwarded them to journalists from Bloomberg who provided the attachments to some researchers, ending up in a thorough analysis of the files.

The emails were sent by the following addresses:

  • melissa.aljazeera [at] gmail.com
  • freedombhrtoday [at] gmail.com
  • mkhalil1975 [at] gmail.com

With the following subjects:

  • Existence of a new dialogue - Al-Wefaq & Government authority
  • Torture reports on Nabeel Rajab
  • King Hamad planning
  • Breaking News from Bahrain – 5 Suspects Arrested

Each of these emails contained an archive, following are the ones identified so far:

  • _gpj.Arrested Suspects.rar
  • King hamad on official visit to .rar
  • Meeting Agenda.rar
  • Rajab.rar

Each of these archives contained several files, including Word documents, images as well as several Windows executables:

  • dialoge.exe (MD5: ee5b03b5990dc310b77aac1d32da68de)
  • gpj.1egami.exe (MD5: e82647e42868e0ff0b6357fcf0f6e95f)
  • gpj.stcepsuS detserrA.exe (MD5: b6d700a58965692e92dce5dbc4323391)
  • gpj.bajaR.exe (MD5: d1216d3fd238cd87d9a7e433b6892b98)
  • gpj.1bajaR.exe (MD5: ad6f72b851ebcf7bf7c8b1c551140c5f)

Quickly looking at binary similarities, it was instantly clear that they all belong to the same malware family. We also identified an additional sample from the same batch:

  • wefaq.exe (MD5: cf7b2e1485771967ece90d32f3076814)

A spokesman from Gamma Group, the company producing the trojan allegedly involved with these attacks, promptly responded to the press stating that FinFisher was never sold to Bahrain and that a copy might have been stolen and re-engineered for some unauthorized use. We're not able to confirm or deny this at the moment.

The Malware

For the sake of this analysis, we are going to use the file “gpj.1bajaR.exe”, but all of them showed similar behavior and communicated with the same backend infrastructure.

Following are the complete cryptographic hashes of the binary:

MD5: ad6f72b851ebcf7bf7c8b1c551140c5f

SHA1: 37275cfd9e185b979c15fb8681c4c8434f224ed9

SHA256: cc3b65a0f559fa5e6bf4e60eef3bffe8d568a93dbb850f78bdd3560f38218b5c

SHA512: 909b631a81a54b279eaa46b81973a95af18da4adfff51b3ecbc731f78cfe380e8863872eb0e8648 acf65f40560dd4684221f640058df0c4821839ab55b7b6597

Ssdeep: 24576:19E4gjTsw7ir1mLR4pzLgbN9z2iiYXDBaLznBn1F:AxjTsw7irkSOx7z6zB1F

The malware is already available on VirusTotal, which shows some decent Antivirus coverage:

https://www.virustotal.com/file/cc3b65a0f559fa5e6bf4e60eef3bffe8d568a93dbb850f78 bdd3560f38218b5c/analysis/

The binary is disguised as a JPG picture, in fact the file name contains the Unicode Right-to-Left Override character in front that whenever displayed in ANSI mode, it will look reversed making the disguise more realistic: in this case “exe.Rajab1.jpg”.

The first thing we did was of course give it a quick run in Cuckoo Sandbox, which was able to give some initial insights on the general behavior of the malware.

When executed, the original process proceeds creating the following directory (the name is randomized at every execution):

C:\DOCUME~1\User\LOCALS~1\Temp\TMP44D8C9F9

If the directory is successfully created, it drops a copy of itself in that same directory, which is also consequently launched.

This new process is actually the one installing the components used to retain access on the compromised machine.

It drops an additional file in the user's Temp directory:

C:\DOCUME~1\User\LOCALS~1\Temp\driverw.sys

Following are the hashes for this driver:

MD5: 0f8249a2593f38c6bf54b6f366c0cac6

SHA1: ff96eddce7a7663677b80a93fc542db8b06ef6f8

SHA256: 62bde3bac3782d36f9f2e56db097a4672e70463e11971fad5de060b191efb196

SHA512: 363fa00ce6d3eba1a3b2d313bb47df480d1b909074514e52950e1fbf364808c297991e1972f3934 6f42f2a52162d5329d1a663fa880527b3dfcc618652770909

Ssdeep: 192:cjQ/nPVCoovDy17/Zs15fHaqIlB6pJqwSmX:c0nPz/ZIPaqIl FSG

This same file was observed being consistently dropped by all the other payloads associated with these attacks.

Interestingly enough, it was already observed on VirusTotal in early May:

https://www.virustotal.com/file/62bde3bac3782d36f9f2e56db097a4672e70463e11971fad 5de060b191efb196/analysis/

The driver is also obfuscated but appears to be able to respond to device control IRPs, a deeper analysis is needed to understand its internal capabilities.

The process concludes its execution by creating the following directory (the name is randomized at every execution):

C:\Documents and Settings\User\Application Data\Microsoft\Installer{A69832D8-3F71-4241-7493-7551DB00C34C}

This directory is reported to be used for storing all the dumped data, logs and screenshots to be later communicated to the operators' C&C server.

In order to make the execution more realistic to the victim, it also drops an image which is also displayed:

The picture varies from one sample to another.

In this case a sandbox analysis was not enough as no network traffic was observed, therefore a deeper manual inspection was required.

As a matter of fact, the actual malware mechanics comes into play just after a first reboot following the compromise. At this point we can observe severe changes in the system and aggressive takeover of the system processes.

As already reported by CitizenLab in their analysis, winlogon.exe is the first process being injected with malicious code:

Process: winlogon.exe Pid: 612 Address: 0x1530000 Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 19, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x01530000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
0x01530010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......
0x01530020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01530030 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 ................

This process is used as a main container for the malware, from which it performs Process Hollowing. This is a common practice in malware development, consisting of spawning legitimate processes and, once loaded, replacing their original code with malicious code.

As a matter of fact, winlogon.exe starts an Internet Explorer instance with the “-nohome” options and performs the takeover:

Process: iexplore.exe Pid: 148 Address: 0x150000 Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 24, MemCommit: 1, PrivateMemory: 1, Protection: 6
0x00150000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
0x00150010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......
0x00150020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00150030 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 ................

The network communication is initiated from the context of the Internet Explorer process, which is often used as a convenient way to bypass local firewalls as it is/used to be a trusted application:

Offset(V) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
0x86335008 10.0.2.15:1036 77.69.140.194:443 148

The malware has a very noisy presence in the system, it installs inline user-mode hooks in the following functions in every running process:

ntdll.dll!NtDeviceIoControlFile
ntdll.dll!NtEnumerateKey
ntdll.dll!NtEnumerateValueKey
ntdll.dll!NtQueryDirectoryFile
ntdll.dll!NtQueryKey
ntdll.dll!NtQuerySystemInformation
kernel32.dll!CreateFileW
kernel32.dll!CreateProcessInternalW
kernel32.dll!MoveFileW
kernel32.dll!DeleteFileW
kernel32.dll!MoveFileExW
USER32.dll!PostMessageW
USER32.dll!GetMessageW
USER32.dll!PeekMessageW
USER32.dll!GetMessageA
USER32.dll!SendMessageW
USER32.dll!PeekMessageA
USER32.dll!PostMessageA
GDI32.dll!GetDeviceCaps
GDI32.dll!DeleteDC
GDI32.dll!CreateDCA
GDI32.dll!CreateDCW
GDI32.dll!DPtoLP
GDI32.dll!Escape
GDI32.dll!ResetDCW
GDI32.dll!EndPage
GDI32.dll!EndDoc
GDI32.dll!StartPage
GDI32.dll!ResetDCA
GDI32.dll!SetAbortProc
GDI32.dll!StartDocW
GDI32.dll!StartDocA
ADVAPI32.dll!OpenTraceA
ADVAPI32.dll!OpenTraceW

It also installs an IAT hook of the function ntdll.dll!CsrClientCallServer in winlogon.exe, which is most likely used to catch every new process registered to the CSRSS subsystem.

As also reported by CitizenLab, the samples seem indeed to belong to the FinFisher toolkit.

Following are some strings that can be found into winlogon.exe memory:

y:\lsvn_branches\finspyv4.01\finspyv2\src\libs\libgmp\mpn-tdiv_qr.c
y:\lsvn_branches\finspyv4.01\finspyv2\src\libs\libgmp\mpn-mul_fft.c
y:\lsvn_branches\finspyv4.01\finspyv2\src\target\bootkit_x32driver\objfre_w2k_x8 6\i386\bootkit_x32driver.pdb
finfisher
finfisher.lnk

We also analyzed the reported “demo” sample:

MD5: c488a8aaef0df577efdf1b501611ec20

SHA1: 5ea6ae50063da8354e8500d02d0621f643827346

SHA256: 81531ce5a248aead7cda76dd300f303dafe6f1b7a4c953ca4d7a9a27b5cd6cdf

SHA512: 0c5a41d45e8939a256c6d24f651619a110b246d5ff5dfa296f68c703ce259ea9420e96ea34c4248 c413e51e4eb5e3f75928318b6fd30251068b5a9f938dd47e0

Ssdeep: 49152:j4XNybwJDejvL6joq2 Sqlk/1jzuUze0uY5nU:EUbwJDc0N21qC9jzuUG

VirusTotal: https://www.virustotal.com/file/81531ce5a248aead7cda76dd300f303dafe6f1b7a4c953ca 4d7a9a27b5cd6cdf/analysis/

Despite some differences (the dropped driver is sensibly bigger compared to the one from Bahrain), the execution flow is exactly the same: similar aggressive presence on the system, same processes chain and same network traffic.

At this stage it's difficult to get a hold of the full functionalities of the malware. We believe that the agent remains silent whenever it doesn't have an active Internet connection and at this very moment we believe it first pulls an updated configuration file instructing it to not do anything at all, therefore all the surveillance plugins seem to be inactive and no file is dropped in “%AppData%\Microsoft\Installer{A69832D8-3F71-4241-7493-7551DB00C34C}\”.

According to CitizenLab's research and WikiLeaks cables, following should be the supported features:

  • Bypassing of 40 regularly tested Antivirus Systems
  • Covert Communication with Headquarters
  • Full Skype Monitoring (Calls, Chats, File Transfers, Video, Contact List)
  • Recording of common communication like Email, Chats and Voice-over-IP
  • Live Surveillance through Webcam and Microphone
  • Country Tracing of Target
  • Silent extracting of Files from Hard-Disk
  • Process-based Key-logger for faster analysis
  • Live Remote Forensics on Target System
  • Advanced Filters to record only important information
  • Supports most common Operating Systems (Windows, Mac OSX and Linux)

We believe that the Skype interception module is implemented tampering the circular sound buffer from Windows' DirectSound interface, you can find a similar implementation here.

Network Communication

All the samples from the Bahrain attacks try to contact the host located at 77.69.140.194, which belongs to Bahrain Manama Batelco (AS5416).

The malware tries to contact such IP address on multiple ports, either 22, 53, 80 or 443 and establish the communication channel on the first one successfully opened.

The traffic is heavily encrypted and it will require further analysis to dissect, but we were able to isolate some recurring patterns.

The first outgoing packet always starts with the following binary data:

0c 00 00 00 40 01 73 00

This packet, which varies in size and content, is believed to be reporting to the C&C some initial details on the compromised machines and perhaps some local configuration. The answer to this first request is believed to be an updated configuration for the trojan.

And all following packets appear to start with the following binary data:

5c 00 00 00 a0 02 72 00 0c 00 00 00 40 04 fe 00

The following Snort signatures should be consistent enough, but due to the small size of the patterns they could cause false positives:

alert tcp any any -> any any (msg:"FinFisher Malware Connection Initialization"; content:"|0c 00 00 00 40 01 73 00|"; offset:0; depth:8; sid:1000001; rev:1;)

alert tcp any any -> any any (msg:"FinFisher Malware Connection Handshake"; content:"|5c 00 00 00 a0 02 72 00 0c 00 00 00 40 04 fe 00|"; offset:0; depth:16; sid:1000002; rev:1;)

Fingerprinting the C&C

While probing the C&C servers, we noticed an unexpected behavior: all the services binded on the ports the malware tries to exchange binary data with, respond in an unusual way whenever performing any, even malformed, HTTP request.

For example, when connecting through telnet to 77.69.140.194:80 and sending “HEAD /”, the service responded the following way:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length:12

Odd indeed, but perfect for fingerprinting!

We made a cross-search of this pattern across HD's Internet survey research project Critical.IO, and were able to identify more servers with open services that responded in the exact same way:

Click on the map to get a larger view and browse through updated results.

Follow is the list of the IP addresses discovered:

  • 112.78.143.26 (Indonesia)
  • 121.215.253.151 (Australia)
  • 78.100.57.165 (Qatar)
  • 213.55.99.74 (Ethiopia)
  • 94.112.255.116 (Czech Republic)
  • 213.168.28.91 (Estonia)
  • 54.248.2.220 (USA)
  • 202.179.31.227 (Mongolia)
  • 80.95.253.44 (Czech Republic)
  • 81.198.83.44 (Latvia)
  • 86.97.255.50 (Dubai, UAE)

At the time of writing, only the Latvian sever is still successfully responding to our fingerprinting. All the others are instantly dropping the connection in the exact same way, most likely filtering off any payload that doesn't match a given header. This makes us believe that all those C&Cs might have been updated in front of recent leaks and publications on FinFisher, Bahrain included.

Please note: we are not able to determine whether they're actually being used by any government agency, if they are operated by local people or if they are completely unrelated at all: they are simply the results of an active fingerprinting of a unique behavior associated with what is believed to be the FinFisher infrastructure. Our guess is that part of the identified C&Cs are acting as proxies.

Conclusions

It's always interesting to get your hands on governmental malware: it's the subject of much discussion and given the high prices it's likely sold for, it's often very hard to get access to samples, so this has been a great project to work on.

What we found is disturbing though. The malware seems fairly complex and well protected/ obfuscated, but the infection chain is pretty weak and unsophisticated. The ability to fingerprint the C&C was frankly embarrassing, particularly for malware like this. Combined, these factors really don't support the suggestion that thieves refactored the malware for black market use.

That said, once any malware is used in the wild, it's typically only a matter of time before it gets used for nefarious purposes. The infosec community needs to pay attention and take malware exposureseriously. Take action to protect infrastructure and discourage the spread, production and purchase of malware. As we've seen countless times before, and will certainly see again, it's impossible to keep this kind of thing under control in the long term.

I'm sure there will be follow-ups on this case on different sides and people will spend more time on analyzing and debating the ins and outs of the malware. For my part, I'd like to end this post by sincerely thanking the guys from CitizenLab for their original research and Arturo Filastò, Fabio Pietrosanti, Jacob Appelbaum and Quequero for their cooperation in this analysis. Thanks guys!

Update #1

The guys at EmergingThreats helped us refine our Snort rules a little bit in order to lower the possibility of false positives.

Following are the updated signatures, use them to detect FinSpy in your local networks:

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"FinFisher Malware Connection Initialization"; flow:to_server,established; content:"|0c 00 00 00 40 01 73 00|"; depth:8; sid:1000001; rev:1; classtype:trojan-activity; reference:url,community.rapid7.com/community/infosec/blog/2012/08/08/finfisher;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"FinFisher Malware Connection Handshake"; flow:to_server,established; content:"|5c 00 00 00 a0 02 72 00 0c 00 00 00 40 04 fe 00|"; depth:16; sid:1000002; rev:1; classtype:trojan-activity; reference:url,community.rapid7.com/community/infosec/blog/2012/08/08/finfisher;)

Update #2

At the time of writing 8 out of the 12 servers are not responding anymore: all the ports originally used have been filtered or closed off after our analysis and the related news articles have been published.

Even the ones that were actively responding until yesterday, like Latvia and Bahrain, are now inaccessible. A very odd timing, isn't it?

In the last hours we read of many people questioning the validity of the "Hallo Steffi" pattern, saying that it could be completely unrelated to the FinFisher toolkit, as also Gamma's Muench stated to Bloomberg. Fair enough, we also mentioned in this same blog post that there is no way we can guarantee a direct connection between that string and the malware, we only reported an anomaly on the Bahraini infrastructure and the discovery of the same anomaly in other locations.

We believe that this unusual behavior could have actually been a deception technique adopted by the FinSpy Proxy to disguise the nature of the service, but that when they realized it was actively used for fingerprinting the C&C servers was promptly disabled to prevent further discoveries.

Every FinSpy sample is configured with a set of multiple ports that it can try to contact: it will start from the lower port (for example 20), attempt a connection 3 times and then move over to the next one.

When running the Bahraini FinSpy sample, especially now that the server is not responding, it attempts the following connections:

13:02:43.747370 IP 10.0.2.15.1035 > 77.69.140.194.22: tcp 0
13:03:05.968816 IP 10.0.2.15.1036 > 77.69.140.194.53: tcp 0
13:03:28.100628 IP 10.0.2.15.1037 > 77.69.140.194.80: tcp 0
13:03:50.332553 IP 10.0.2.15.1038 > 77.69.140.194.443: tcp 0
13:04:21.517231 IP 10.0.2.15.1039 > 77.69.140.194.4111: tcp 0

As you can see the last one is port 4111.

We believe this is the standard FinSpy port and that all the other ones are probably just forwarded to 4111. The FinSpy "demo" sample contacted port 3111 to tiger.gamma-international.de and ff-demo.blogdns.org, close enough.

Another interesting "coincidence" is that all the IP addresses that we observed responding with the "Hallo Steffi" banner also had/have port 4111 open, in fact if you check the only 4 servers currently up you can see:

Nmap scan report for bba44246.alshamil.net.ae (86.97.255.50)
Host is up (0.26s latency).
PORT     STATE    SERVICE
22/tcp   open     ssh
53/tcp   open     domain
443/tcp  open     https
4111/tcp open     xgrid

Nmap scan report for 94.112.255.116.static.b2b.upcbusiness.cz (94.112.255.116)
Host is up (0.044s latency).
PORT     STATE  SERVICE
22/tcp   open   ssh
53/tcp   open   domain
80/tcp   open   http
443/tcp  open   https
4111/tcp open   xgrid

Nmap scan report for 112.78.143.26
Host is up (0.26s latency).
PORT     STATE  SERVICE
22/tcp   open   ssh
53/tcp   open   domain
80/tcp   open   http
443/tcp  open   https
4111/tcp open   xgrid

Nmap scan report for 213.55.99.74
Host is up (0.16s latency).
PORT     STATE  SERVICE
22/tcp   open   ssh
53/tcp   open   domain
80/tcp   open   http
443/tcp  open   https
4111/tcp open   xgrid
9111/tcp open   DragonIDSConsole

The last one also shows port 9111, which we observed along with port 3111 being open fewer times as well.

Is it more convincing now?