APT & Targeted Attacks
StrongPity APT Group Deploys Android Malware for the First Time
We recently conducted an investigation into a malicious Android malware sample, which we believe can be attributed to the StrongPity APT group, that was posted on the Syrian e-Gov website. To the best of our knowledge, this is the first time that the group has been publicly observed using malicious Android applications as part of its attacks.
We recently conducted an investigation into a malicious Android malware sample, which we believe can be attributed to the StrongPity APT group, that was posted on the Syrian e-Gov website. To the best of our knowledge, this is the first time that the group has been publicly observed using malicious Android applications as part of its attacks.
We first learned about the sample from a thread shared on the MalwareHunterTeam Twitter. Based on the discussion thread, we learned that the shared sample is a trojanized version of the Syrian e-gov Android application that would steal contact lists and collect files with specific file extensions from its victim's device.
One response from the thread pointed out that the malicious APK was likely distributed using a "watering-hole"-like technique: the attacker allegedly had compromised the official Syrian E-Gov website and replaced the official Android application file with a trojanized version of the original app. Due to the suspicious nature of this activity, we decided to investigate further.
This blog entry will discuss the group’s attack tactics, techniques, and procedures (TTPs) in relation to the Android malware and why these activities can be attributed to this threat actor. Furthermore, we will also dive into the threat actor’s development progress and identify several other malicious Android malware samples produced by StrongPity. Finally, we will briefly discuss related malware variants, including the second version of the Android trojan, which appears to be a work in progress and includes several testing features.
Initial investigation
The first thing we did was check the URL where the malicious APK file was hosted (https://egov[.]sy/mobile/egov[.]apk). The version of the application that is downloadable from the site at the time of writing is a clean version of the Syrian e-gov Android application that is different from the malicious application previously discussed on Twitter. This means that, at one point, the malicious version of the application was deleted from the site.
At least six other samples with the same application name ("بوابتي") and matching package names (com.egov.app.*) can be identified on VirusTotal. We verified all of these samples and concluded that all of them are benign. These benign versions of the application were created during the period from February 2020 until March 2021. We believe all of them are official apps from the Syrian E-Gov website.
The malicious sample, mentioned in the Twitter thread, is available on VirusTotal and as of the time of writing, has several positive detections. Although some antivirus vendors detect the identified malicious sample as Bahamut, we doubted the accuracy of this attribution to the Bahamut APT group. Further investigation revealed several artifacts that could possibly link the malicious sample to the StrongPity APT group.
Analysis of the malicious sample
The malicious version of the application (fd1aac87399ad22234c503d8adb2ae9f0d950b6edf4456b1515a30100b5656a7) was created on May 2021(The timestamps within the file point to 2021-05-03 as the creation date, while the file was uploaded to VirusTotal on May 24, 2021). This application is signed with a different certificate and was produced by repackaging the original app from the Syrian government. All of the original applications, on the other hand, are signed with another certificate.
The malicious application has the AndroidManifest.xml modified to include references to additional classes and request additional permissions on the device (seen in Figure 3).
Overview of the inserted code
The threat actor added the following classes to this application; some of these classes (com.egov.app.NetworkStatusService, com.egov.app.Receiver) are referenced in the modified AndroidManifest.xml.
Figure 3 shows that many of the other classes have randomly generated class and method names. This naming pattern was likely produced by a software obfuscation tool.
Two major additional components were added to the malicious version of the application: a service and a receiver. The receiver starts the malicious service. The malicious service is declared as an Android Service, which is an application component that can perform long-running tasks in the background.
This malicious service is declared with the class name "com.egov.app.NetworkStatusService", and is started by the Receiver class.
Our analysis of the Receiver configuration and code found multiple methods for starting the malicious NetworkStatusService service.
- The service is started when the device connectivity is changed. The djdeeu class registers a broadcast receiver for CONNECTIVITY_CHANGE.
- The service can be started from launcher activity or other registered receivers.
- The service can be started using the "Alarm" mechanism.
Once the malicious NetworkStatusService service is started, it executes its malicious functionality via a set of message handlers, which are responsible for handling specific messages.
The sample uses the "Handler" mechanism to dispatch messages that trigger malicious behavior. A custom enum structure is used to define the message types.
It defines seven message types, shown in Figure 4.
Each of the messages trigger a different behavior through the handler. The following is a quick summary of the purpose and behavior of each specific message:
When this message is received, a periodic task for heartbeat message is set.
When this message is received, a periodic task for sync message is set.
This message triggers the heartbeat function, which sends a request to the command-and-control (C&C) server and receives a response with an encrypted payload.
The encrypted payload is first saved into the directory <DIR>/.android/water.zip, after which the file water.zip is decrypted and the decrypted payload written to <DIR>/.android/e.zip.
Next, the file e.zip is decompressed into <DIR>/.android and the file with the name "config.properties" is accessed.
Finally, this file is read and parsed. These properties are extracted and written as configuration settings to local shared preference, allowing the malware to change its behavior according to the configuration.
Sync is a repeated behavior. It uploads files, which were collected on infected devices, with a periodicity of 3000 seconds.
The handler for MSG_SYNC executes the following functionality:
First, it enumerates all files under <DIR>/.android/.lib2. It then creates a zip file with the name <uniqueId>.zip (note that the unique ID is not a real device ID, the malware just calculates a custom unique ID based on the device ID value), and writes the files into the compressed file.
Finally, it upload the zip file to the C&C server and deletes all files under <DIR>/.android/.lib2, as well as the compressed file <uniqueId>.zip.
The handler for this message collects data from the victim’s device. First, it collects contact information, followed by information regarding available Wi-Fi networks.
It then searches through the device files and harvests all files that match pre-defined file extensions:
- .asc
- .dgs
- .doc
- .docx
- .edf
- .gpg
- .jpeg
- .jpg
- .key
- .m2r
- .meo
- .pgp
- .pir
- .pkr
- .pub
- .rjv
- .rms
- .sem
- .sit
- .skr
- .sys
- .xls
- .xlsx
When this message is received, a periodic task for the “collect message” handler is set.
This message sends all the mentioned messages one by one.
Modular Functionality of the backdoor
This sample uses highly modular components to create a flexible architecture for component loading and unloading. The functions onCreate and onDestroy show a common approach to loading and unloading a component.
The following are the components were used in the sample:
- pekmek(Crypto Manager): Uses AES to decrypt and encrypt files and strings.
- ltymcr(Helper Class): Contains many utility functions, such as a function to calculate unique id, parse config file, write/read shared preference, and define encryption keys.
- sadwoo: A component used as PowerWakeLock.
- phkyxc: A component used as WifiWakeLock.
- tfsdne: This is a wrapper used for C&C communication such as heartbeat and sync.
- itxdrx(Net Manager): A component responsible for handling HTTP protocol communication.
- nhnhpi: The component responsible for managing the C&C server.
This component includes definition of an initial C&C server. The initial value can be overridden. The StrongPity backdoor has the ability to update (including deleting and adding) its C&C server address via configuration updates from the "heartbeat" command.
Investigation and attribution
When we learned how the threat actor repackages benign applications into trojanized variants, we decided to search for similar samples on VirusTotal. We searched for other applications that were repackaged in a similar method and included similar malicious components.
We found several other samples that were produced by the same threat actor. We determined these samples to be similar because all of them (except for the last sample) were also repackaged from normal applications and had similar malicious code inserted.
Date of submission |
SHA256 |
Identified C&C servers |
Additional Details |
August 2, 2019 |
374d92f553c28e9dad1aa7f5d334a07dede1e5ad19c3766efde74290d0c49afb |
upeg-system-app[.]com |
Likely repacked from Kingoroot. |
June 8, 2020 |
be9214a5804632004f7fd5b90fbac3e23f44bb7f0a252b8277dd7e9d8b8a52f3 |
networktopologymaps[.]com |
Likely repacked from Snaptube, though It is not the same as 596257ef017b02ba6961869d78a2317500a45f00c76682a22bbdbd3391857b5d. |
June 8, 2020 |
a9378a5469319faffc48f3aa70f5b352d5acb7d361c5177a9aac90d9c58bb628 |
networktopologymaps[.]com |
Likely repacked from net[.]cybertik[.]wifi (the original app could be downloaded from the Yemeni website, cybertik[.]net). |
June 13, 2021 |
596257ef017b02ba6961869d78a2317500a45f00c76682a22bbdbd3391857b5d |
upeg-system-app[.]com |
Likely repacked from Snaptube. |
January 1, 2021 |
75dc2829abb951ff970debfba9f66d4d7c6b7c48a823a911dd5874f74ac63d7b |
upn-sec3-msd[.]com |
This is likely a testing sample because it provides buttons to test functions. This sample also contains some new features that we haven’t seen in other samples. This shows that the actor is actively involved in the development of APK versions of the backdoor. |
Table 1. Similar malicious samples found on VirusTotal
The sample 75dc2829abb951ff970debfba9f66d4d7c6b7c48a823a911dd5874f74ac63d7b serves as the key attribution factor and is the main link to the StrongPity threat actor, because it communicates with a C&C server that was previously identified by several research teams as infrastructure used by the group.
Tools, tactics, and procedures on Windows
There are no known public reports of StrongPity using malicious Android applications in their attacks at the time of writing. In order to strengthen our confidence in the accuracy of our attribution to StrongPity, we decided to further examine some of their samples that were used to target Microsoft Windows platforms and see if we could identify similar tools, tactics, and procedures (TTPs) in their actions.
Just as we have seen with the Android apps, the StrongPity group favors repacking benign installers to produce trojanized versions of these applications. Likewise, the main function of these backdoors is to search, harvest, and exfiltrate files from the victim’s computers.
Take, for example, the following sample: 48f67be806b4e823280f03ee5512ffd58deb6f37ecc80842265d4e8d2ca30055. The sample first drops a file called "TrustedInstaller.exe" to <DIR>/AppData/Local/Temp and then executes it. This dropped file is a clean WinRAR installer.
It then creates <DIR>/AppData/Local/Temp/lang_be29c9f3-83we to drop malicious files and execute them.
If we examine another StrongPity sample (12818a96211b7c47863b109be63e951075cf6a41652464a584dd2f26010f7535), the logic is similar — it drops a normal installer into the Temp directory and creates a directory for dropped malicious files.
Here are three notable similarities between the Windows sample and the Android sample:
1. They all disguised as normal apps by utilizing the original clean applications — the Android sample repacks the original one into a trojanized version, while the Windows sample uses a trojanized installer packed with the original program.
2. Both collect and exfiltrate files from the infected device.
3. Both are highly modular. The Windows sample has a standalone Exfiltration and File Search module, a feature that could also be seen in the latest test Android sample.
Possible connections to StrongPity
We found several clues that link the malicious Android samples with the StrongPity threat actor.
The sample 74582c3d920332117541a9bbc6b8995fbe7e1aff communicates with the URL https://www.upn-sec3-msd[.]com/ProxyServer/service/. The domain name “upn-sec3-msd[.]com” was mentioned in another StrongPity report.
The domain naming pattern and domain acquisition techniques are quite similar. For example, the domain names used by StrongPity in 2020 have a domain naming pattern similar to the domains used by the identified Android samples.
One of the domain names, networktopologymaps[.]com, was likely bought when registration at Gandi expired. The domain was acquired via the Porkbun network registrar.
This is similar to the domain hostoperationsystems[.]com, which was previously mentioned in the Talos report. This domain was also acquired via Porkbun and features a comparable domain naming pattern.
Another notable point of correlation to StrongPity is the list of file extensions, which we have seen in Android samples. A similar list of the file extensions for the files is presented in variants of the trojan for Windows systems. For example, one of the samples that we had examined earlier, gathers files with the following extensions:
- .7z
- .asc
- .dgs
- .doc
- .docx
- .gpg
- .pgp
- .ppt
- .pptx
- .rar
- .rjv
- .rms
- .rtf
- .sft
- .tc
- .txt
- .xls
- .xlsx
As we previously mentioned, there are no public reports of the StrongPity threat actor using malicious Android applications in the attack. However, we examined the trojan code-embedding techniques as well as the trojan functionality of the malicious code written by the same threat actor for Windows platforms, and we have identified some similar patterns. This leads us to believe that these could belong to the same threat actor.
StrongPity actively develops new malicious android apps
We believe that the StrongPity Threat actor is actively developing backdoors for Android. Based on the test sample that we have identified, we can see that the threat actor attempts several techniques to lure potential victims: repackaged applications, compromised websites, and fake variants of popular applications.
Based on the additional functionalities that we identified in the fake Samsung security service application (75dc2829abb951ff970debfba9f66d4d7c6b7c48a823a911dd5874f74ac63d7b), we think that among the APK files that we had identified, the repackaged applications are bundled with the first version of the Android trojan, while the fake application could be a work in progress for the next version of the tool.
In the second version, we observed the threat actor developed and included some additional components and as well as added support for more message types.
The following table shows the types that the threat actor has defined.
Message type |
Details |
MSG_ADD_MODULE |
Add a new module |
MSG_GET_MODULE |
Get the module instance |
MSG_DEL_MODULE |
Delete module file under <DIR>/.android/.li/<module name> |
MSG_DEL_APK |
Delete the APK file under the download directory |
MSG_START_MODULES |
|
Table 2. Message types defined by the threat actor
In this version, MSG_COLLECT is no longer present — we think they replaced it with MSG_START_MODULES, a message used to read all module names from the shared preference, and start/initialize them one by one.
We were not able to get access to these modules, but based on some of the code functionality that we observed, we believe that these modules are designed to collect data from the victim’s devices and write the collected data into a local SQLite db data file. However, we were not able to find any of these modules in the wild.
There are also several other key differences between version 1 and version 2 of the trojan:
- The message Handler for heartbeat message in version 2 is now split into two messages: heartbeat and taken_config. Either of these messages can receive a response from the C&C server and decrypt the response to update the local configuration, similarly to the version 1.
- Version 2 uses different AES encryption keys: key("aaaanothingimpossiblebbb"), and AES IV("aaaanothingimpos")
- ScreenReceiver class is added to the second version of the trojan. The purpose of this Receiver is to start the malicious service via Screen_On and Screen_Off events.
- Version 2 has an ability to execute “su” command, if the device is rooted. The main usage of the root privilege here is that it could grant permissions silently. Such permissions include accessibility, notification and other. However, we did not find any evidence that the sample would attempt to root the device.
- Two components were added in version 2 for accessibility and notification.
- Version 2 uses SQLite to store collected data. Furthermore, it no longer uses ZIP.
- In Version 2, the extra modules used in “MSG_START_MODULES” are downloaded from the C&C server via either the heartbeat or taken_config message. It’s possible that these modules are decompressed as part of the response into <DIR>/.android/.li and consequentially executed.
Conclusion
This investigation has provided evidence to attribute the Android malware sample, which was posted on the Syrian e-Gov website, to the StrongPity threat group. We were also able to identify additional Android trojan files and correlate these malicious Android applications with existing public reports based on their similarities to the threat actor’s TTPs and network infrastructure they used.
Although there are no previously known malicious Android applications attributed to the StrongPity group, we strongly believe that the threat actor is in the process of actively developing new malicious components that can be used to target Android platforms.
We believe that the threat actor is exploring multiple ways of delivering the applications to potential victims, such as using fake apps and using compromised websites as watering holes to trick users into installing malicious applications. Typically, these websites would require its users to download the applications directly onto their devices. In order to do so, these users would be required to enable installation of the applications from “unknown sources” on their devices. This bypasses the “trust-chain” of the Android ecosystem and makes it easier for an attacker to deliver additional malicious components.
Indicators of Compromise (IOCs)
SHA256 |
Description |
Detection |
fd1aac87399ad22234c503d8adb2ae9f0d950b6edf4456b1515a30100b5656a7
|
The trojanized version of the Syria eGov Application |
AndroidOS_StrongPity.HRX |
374d92f553c28e9dad1aa7f5d334a07dede1e5ad19c3766efde74290d0c49afb |
Sample repackaged from Kingoroot |
AndroidOS_StrongPity.HRX |
a9378a5469319faffc48f3aa70f5b352d5acb7d361c5177a9aac90d9c58bb628
|
Sample repackaged from net.cybertik.wifi |
AndroidOS_StrongPity.HRX |
be9214a5804632004f7fd5b90fbac3e23f44bb7f0a252b8277dd7e9d8b8a52f3 |
Repackaged from Snaptube |
AndroidOS_StrongPity.HRX |
596257ef017b02ba6961869d78a2317500a45f00c76682a22bbdbd3391857b5d |
Repackaged from Snaptube |
AndroidOS_StrongPity.HRX |
75dc2829abb951ff970debfba9f66d4d7c6b7c48a823a911dd5874f74ac63d7b
|
Fake Samsung Security Service sample |
AndroidOS_StrongPity.HRX |
Network C&C Infrastructure
SHA256 |
Domain |
Detection |
fd1aac87399ad22234c503d8adb2ae9f0d950b6edf4456b1515a30100b5656a7 |
Internetwideband[.]com |
AndroidOS_StrongPity.HRX |
374d92f553c28e9dad1aa7f5d334a07dede1e5ad19c3766efde74290d0c49afb |
upeg-system-app[.]com |
AndroidOS_StrongPity.HRX |
a9378a5469319faffc48f3aa70f5b352d5acb7d361c5177a9aac90d9c58bb628
|
networktopologymaps[.]com |
AndroidOS_StrongPity.HRX |
be9214a5804632004f7fd5b90fbac3e23f44bb7f0a252b8277dd7e9d8b8a52f3 |
networktopologymaps[.]com |
AndroidOS_StrongPity.HRX |
596257ef017b02ba6961869d78a2317500a45f00c76682a22bbdbd3391857b5d |
upeg-system-app[.]com |
AndroidOS_StrongPity.HRX |
75dc2829abb951ff970debfba9f66d4d7c6b7c48a823a911dd5874f74ac63d7b
|
upn-sec3-msd[.]com |
AndroidOS_StrongPity.HRX |