Back in March 2019, Amnesty International published a report that uncovered a targeted attack against journalists and human rights activists in Egypt. The victims even received an e-mail from Google warning them that government-backed attackers attempted to steal their passwords.
According to the report, the attackers did not rely on traditional phishing methods or credential-stealing payloads, but rather utilized a stealthier and more efficient way of accessing the victims’ inboxes: a technique known as “OAuth Phishing”. By abusing third-party applications for popular mailing services such as Gmail or Outlook, the attackers manipulated victims into granting them full access to their e-mails.
Fig 1: Previous OAuth phishing campaign
Recently, we were able to find previously unknown or undisclosed malicious artifacts belonging to this operation. A new website we attributed to this malicious activity revealed that the attackers are going after their prey in more than one way, and might even be hiding in plain sight: developing mobile applications to monitor their targets, and hosting them on Google’s official Play Store.
After we notified Google about the involved applications, they quickly took them off of the Play Store and banned the associated developer.
Infrastructure: The Early Days
The full list of indicators belonging to this campaign and shared by Amnesty on GitHub showed multiple websites that used keywords such as “mail”, “secure”, or “verify”, possibly not to arouse any suspicions and to masquerade as legitimate mailing services.
By visualizing the information available about each of these websites, we saw clear connections between them: they were registered using NameCheap, had HTTPS certificates, and many of them resolved to the same IP addresses.
The addresses shared the same IPv4 range or netblock (185.125.228[.]0/22), which belongs to a Russian telecommunications company called MAROSNET.
Fig 2: Maltego visualization of campaign infrastructure
Naturally, the websites cannot be accessed nowadays, but by looking over public scans available for some of them we could see that in addition to being related to OAuth phishing, they hosted phishing pages that impersonated Outlook or Facebook and tried to steal log-in credentials for those services:
Fig 3: Outlook phishing page example
Interestingly enough, the above phishing page accessed a Github repository from an account called “Tarsotelvab” to retrieve a CSS file it uses. “Tarsotelvab” was mainly active in 2017, and had five repositories in total:
Fig 4: Tarsotelvab’s repository on GitHub
Another repository under this account that caught our attention included different CSS files belonging to Qatar Airways, AlJazeera, and a Qatari newspaper called AlArab. The files could have been part of a separate phishing campaign impersonating those websites, although we cannot say this for sure as we did not find such an attack.
What we can say for sure, however, is that the same infrastructure was utilized for both traditional and OAuth phishing attacks, and that it is still being used by the attackers nowadays.
Many newly registered and unrelated domains resolved to the same IP addresses that were associated with this malicious activity, and looking for relevant indicators was not an easy task. But searching for domains that followed the same naming conventions as the malicious ones, and had the words “mail” or “verify” in their addresses, helped filter the surrounding noise.
One of the domains we came across, maillogin[.]live, had an open directory with files uploaded during May and June, allowing us to download and view all of its back-end scripts:
Fig 5: Open directory on maillogin[.]live
In addition to the similar name and shared IP address, we were able to quickly confirm that maillogin[.]live is indeed connected to the previous activity, since the directories it included were observed in older domains, but also because some of the files referenced those domains.
By downloading the contents of this directory, we got our hands on many PHP scripts, API clients, SQL files and configuration files from the server. Looking into them revealed several aspects about the inner workings of this operation, the functionalities that were implemented on this server and possibly others, and lastly some information about the perpetrators behind it all.
For example, we realized that the attackers can control the operation by sending commands to one of the PHP scripts. The script allowed the attackers to query the data stored on the server, but it had self-destructing capabilities as well, such as removing an existing campaign or deleting all of the information collected from victims:
Fig 6: Campaign deletion functionality
To try and prevent any undesired access, the script would count the total number of requests it received. If that number exceeds 30, an e-mail is sent to the address “devd.logaana@gmail[.]com” alerting the attackers of the suspicious activity on the server and asking them to come take a look:
Fig 7: Anomalous activity alert functionality
There were multiple databases that the attackers created to store such statistics from the server, data stolen from victims, blacklisted User-Agents, and more. The credentials for each database were hardcoded into some of the scripts, and included usernames such as “drivebac_drivebk”, “mailveri_shorten” or “loginacc_ifish”:
Fig 8: Hard-coded database credentials
One of the databases even included a list of phishing URLs generated by the attackers, and each link mentioned the e-mail address of the victim it was sent to. This exposed the possible targets of those phishing attempts, which were mainly prominent journalists, human rights activists, and non-profit organizations members from Egypt.
Fig 9: Generated phishing URLs
In addition to exposing the victims, some of the files in the server helped us understand the full flow of the OAuth phishing attacks. Two configuration files of third-party applications belonging to the attackers referred to a script called “capture.php” that was hosted on drivebackup[.]co. Although this website is no longer accessible, a copy of the script existed on maillogin[.]live:
Fig 10: OAuth phishing configuration
The “capture.php” script was in charge of taking the victims to the third-party applications. After being granted the requested permissions, the applications will redirect back to this script, which will then log stolen information about the victims, and eventually redirect to Google.
Fig 11: OAuth phishing compromise flow
There were two new applications that we discovered, which requested permissions to view the victim’s basic information and e-mail address, but also to have unlimited access to their Google Drive:
Fig 12: Newly discovered OAuth Google applications
Clicking on the application name shows details about the developer, who has the same e-mail address that we observed in the back-end scripts:
Fig 13: Developer information
The application that was covered in Amnesty’s report accessed the Gmail inbox, but it seems the attackers are not satisfied with only viewing exchanged e-mails, and are trying to expand their scope to reach the victims’ personal files as well.
Other mailing services besides Gmail were also targeted, as we found another external application for Outlook called “Mail Sender”. The available information about “Mail Sender” shows that it was created back in January 2018:
Fig 14: OAuth Outlook application from 2018
The new applications exemplified how the attackers are investing efforts into coming up with new ways to track their targets on multiple platforms. But they also raised questions about the website they redirected to, which had no bad reputation or malicious affiliations before, and which we can no longer access, drivebackup[.]co.
The Archives of the Web
Back in 2018, drivebackup[.]co resolved to an IP address that was already associated with the OAuth phishing attacks: 185.125.130[.]195. It had subdomains such as “facebook.com.drivebackup[.]co”, which could have been used to host phishing pages:
Fig 15: Passive DNS records for 185.125.130[.]195
Google results for “drivebackup[.]co” show that it had an open directory when it was active, and one of the files it hosted was called “COPY_NUM_HN1515242134_OF_عربى.xlsx”. There is no back up for this file in Google’s cache, but even the result itself can give away many details.
Fig 16: Cached Google result for drivebackup[.]co
First off, the URL which the file was downloaded from, “/downloaded/devd.logaana @gmail[.]com”, mentions the same e-mail address again. The title of the document, “Sheet1 – Drive Auto Backup | V 1.0”, matches the name of the Google Drive application. And lastly, the number that appears in the filename, “1515242134”, is a UNIX timestamp of January 6th, 2018, and might be the date in which this file was created.
Not much else was known about drivebackup[.]co other than this, but that was when we discovered a connection to an Android application.
Tracking Your Every Move
An Android application that was submitted to VirusTotal during February communicated with drivebackup[.]co. This application has one detection only, and is called “v1.apk”:
Fig 17: Android application communicating with drivebackup[.]co
The sample has no icon, its build type is set to “debug”, and its internal version number is set to “1.0”. All of this can indicate that it is still in early testing phases.
Fig 18: Internal configuration of the application
When the application runs, it asks the user to enter an activation key, which is then sent to drivebackup[.]co. This can be a way to filter any undesired usage of the application, since the key has to be approved by the server.
Fig 19: Application’s interface
Once the key is approved, the application proceeds to implement its only functionality: collecting information about the user’s location. The device’s exact coordinates, the accuracy of those coordinates, local time and battery status are all uploaded to drivebackup[.]co as well:
Fig 20: Information collected by the application
This functionality by itself is not malicious, but combined with other characteristics of the application, it raises many red flags. Although the chosen package name for the application “com.location.operations.iroute” provides an accurate description of what it does, the displayed name tells a different story.
Fig 21: Application’s icon and name
The application calls itself “iLoud 200%”, the name of its MainActivity is “iLoud”, and it displays messages to the user saying that the “ringtone is now 100% louder”. The application masquerades as a service that increases the device’s volume, although it implements no such functionality.
Another warning sign was the service that collects the coordinates, which automatically runs when the device is started. If it is stopped for any reason, a broadcast is sent to another class, that is in charge of restarting this service and making sure it keeps running:
Fig 22: Service functionality
In addition to using a website we have seen in a malicious context, we realized this application is meant to monitor the location of the device it is installed on at all times, and to do so while hiding its true intentions. Therefore, it seems that it was created for a purpose that coincides with the surveillance motives behind the phishing activity, and that drivebackup[.]co is not the only connection between the two.
Hunting for related samples with the unique strings that appeared in the application led us to an older variant, which uses the package name “com.whatsapp” to look like a legitimate service. This variant did not communicate with drivebackup[.]co, and instead referred to the website that “v1.apk” was downloaded from: indexy[.]org.
Although “v1.apk” was submitted to VirusTotal during February, we could see that it was uploaded to indexy[.]org in January:
Fig 23: Application’s upload timestamp
An administration panel to manage this application exists on indexy[.]org as well, and the application is referred to as “I.Track” in the login page:
Fig 24: C&C web login panel
Many of the JS and CSS files that the panel needs are missing and cannot be loaded, since it imports most of its resources from drivebackup[.]co:
Fig 25: Source code artifacts point to drivebackup[.]co
Although we did not log in to this panel, the “styles” directory included the HTML templates of the pages available for the administrators after logging in:
Fig 26: Additional artifacts on indexy[.]org
Examining the names of the HTML pages can reveal what actions the administrators can perform using the panel: add targets, control existing ones, and track them all. One of the pages called “trackgroup.html” initializes a Google Map, adds the collected coordinates to it, and defines the default location which this map zooms in to:
Fig 27: Embedded initialization coordinates
Surprisingly, those coordinates point to an unnamed building in Cairo. While we do not know if it is associated with the developers of this application, this might be a default location that was chosen to zoom in on because it is close to the monitored coordinates on the map:
Fig 28: Google Maps view of the coordinates
Another interesting finding was in the “dist” directory under “styles”, which contains images that are provided by default from the AdminLTE bootstrap template. But there were two additional icons called “logo.png” and “logo_ifish.png” in this directory that mentioned the word “iFish”:
Fig 29: iFish logo under “dist” directory
The word “iFish” appeared before in one of the credential pairs used to access a database in maillogin[.]live, and might be referring to the internal name of the project:
Fig 30: Previous iFish connection
This was yet another connection that we could establish between the Android application and the phishing attacks based on the findings from indexy[.]org. As it turns out, this website had other ties to the world of mobile, besides the location-tracking applications.
The website indexy[.]org appeared in an unlikely location: an Android application called “IndexY” with more than 5000 downloads, found in Google’s official Play Store.
Fig 31: IndexY application on Google Play
IndexY offers a service that is similar to the known TrueCaller, allowing users to look up details about phone numbers or their owners. It promises a large database of more than 160 million phone numbers, but seems to be intended for a specific target audience according to its description: Arabic-speaking users.
“Index Masr” is mentioned in the package name, which means “Index Egypt”. In addition, the default country for IndexY users shows that the service is mainly aimed at Egyptians:
Fig 32: Embedded location configuration
The same variable name, “ws_link”, that was seen in the previous location-tracking application is used to set the website address IndexY communicates with:
Fig 33: Recurring “ws_link” variable name
When the application is installed, it receives access to the user’s contacts and call history. While this is considered sensitive data, it would make sense for an application of this nature to try and collect as many phone numbers as possible to enhance the service it offers.
But instead of only exporting phone numbers from the call history, the application logs the direction of each call (incoming, outgoing or missed), the date in which it was received and its duration:
Fig 34: Call information recorded by the application
Therefore, IndexY does not seem to be accessing this data just to improve the service it promises, and is actually exporting much more information than it needs to.
Styles Once More
There was other supporting evidence on indexy[.]org that confirmed our suspicions. Similarly to the previous case, there was an administration panel to manage this application. Once again, we were able to view the HTML templates for the pages the administrators get after they log in, using the “styles” directory:
Fig 35: Folder view of indexy[.]org
The directory included HTML pages that were uploaded during 2016, and two of them were even identical to the ones that were found and reused in the location-tracking panel.
The pages show that the administrators store and inspect the information they collect from the users. This involves lists of the number of users per country, detailed call logs, and even lists of calls that were made by users from one country to another:
Fig 36: Code to display collected information
Based on this, it seems that whoever is responsible for IndexY is abusing the access they have gained. They do not simply store the data that the application collects, but are rather analyzing it carefully, and even looking for suspicious activity within it, far beyond the scope of an innocent TrueCaller-like service.
While we considered the possibility that IndexY is not connected to the phishing attacks, the more we looked into both things the more probable it became that they belong to the same operation, and are motivated by the same purpose: surveillance of Egyptians.
Back to Egypt
We came across several clues during our investigation of the different components and layers that make up this attack, which could suggest it was coming from an Egyptian source or someone who invested much effort in planting false flags in an extremely sophisticated way. We will divide those findings into three categories:
First: Amnesty International IoCs
We already mentioned that the domains in Amnesty’s report shared similar characteristics, but only one of them (account-login[.]site) had a WHOIS record with details about the registrant. According to this record, the registrant was from Egypt:
Fig 37: WHOIS information: account-login[.]site
Moreover, the registrant’s name and organization mention MCIT, which might be an acronym for the Ministry of Communications and Information Technology in Egypt.
Another website from the IoC list, adminmail[.]online, had some interesting subdomains:
Fig 38: Subdomain records for adminmail[.]online
“el7arkaelsha3bea” and “el7rkaelsha3bea” are the English transliterations of the Arabic phrase “الحركة الشعبية“, which means “The Popular Movement”. A domain that mentions this phrase (el7rkaelsha3bea.ddns[.]net) also resolved to an IP address that is related to this attack. Looking up this phrase online led us to one result only, a Telegram channel with the same name:
Fig 39: Telegram group: “el7arkaelsha3bea”
The channel was created in March, and seems to be intended for activists looking to join “a social movement that is opposed to the regime in Egypt”. It has several links to a Facebook page calling for a second revolution, and asks new members to contact the admins and identify.
The channel itself might be used to track Egyptian dissidents, although we have no conclusive evidence of the real intentions behind it, nor can we confirm that it is related to the sub-domains we have observed, as they were inactive by the time we checked them.
Second: The Open Directory
Scripts that we downloaded from maillogin[.]live were heavily documented, and included comments that explained the purpose of almost each section or branch of the code:
Fig 40: Extensive code comments
The comments had many grammatical mistakes and misspelled words, and surprisingly they could even give away the origin of the attackers. In one of the comments, the word “Puffering” is used instead of “Buffering”. The two words would be phonetically similar to a native Arabic speaker, since the Arabic alphabet does not have a “P” sound.
This can be confirmed by another configuration file, which sets the default timezone in the server to be that of Cairo:
Fig 41: Predefined default time-zone in the code
Third: IndexY Developer
The latest version number of IndexY in Google’s Play Store was 11.08, but we were able to obtain 10 older variants that were published during 2018. The application did not always communicate with indexy[.]org, and it used arabindex[.]info or indexmasr[.]com instead in the previous generations. In addition, one of the versions mentions a fourth website in its “About” section: servegates[.]com.
Fig 42: Older IndexY application
All of the above websites resolved to the same IP address, and although it was not connected to MAROSNET or to the netblock that was constantly used in the phishing attacks, we could see for example that servergates[.]com hosted phishing URLs in the past:
Fig 43: Netblock previously used for phishing attacks
The WHOIS records of servegates[.]com and indexmasr[.]com show that they were both registered using the e-mail address eng.shenawy@hotmail[.]com, which supposedly belongs to an individual from Egypt:
Fig 44: WHOIS information: indexmasr[.]com
A website with the same WHOIS information (txtips[.]com) which publishes blog posts with technical tips, uses “shenno” as the author name:
Fig 45: Post published by “shenno” on a connected website
This name appeared in the source code of the IndexY application, and it was used as a tag for all the displayed log messages:
Fig 46: Previous connections to “shenno” observed in the IndexY application
“Shenno” can be a nickname or an abbreviation for the name in the WHOIS record, “Shennawy”. Although this might be a fake name, it led us to believe that whoever was in charge of registering the websites was the same person in charge of developing the IndexY application, and appears to be from Egypt.
Following up on the investigation first conducted by Amnesty International, we revealed new aspects of the attack that has been after Egypt’s civil society since at least 2018.
Whether it is phishing pages, legitimate-looking applications for Outlook and Gmail, and mobile applications to track a device’s communications or location, it is clear that the attackers are constantly coming up with creative and versatile methods to reach victims, spy on their accounts, and monitor their activity.
We discovered a list of victims that included handpicked political and social activists, high-profile journalists and members of non-profit organizations in Egypt.
The information we gathered from our investigation suggested that the perpetrators are Arabic speakers, and well familiar with the Egyptian ecosystem. Because the attack might be government-backed, it means that we are looking at what might be a surveillance operation of a country against its own citizens or of another government that screens some other attack using this noisy one.
Check Point’s SandBlast Mobile
SandBlast Mobile protects against the malicious applications detailed in this publication.
Check Point’s SandBlast Mobile is a market-leading mobile threat defense solution, providing the widest range of products to help you secure your mobile world.
To learn more about how you can protect yourself from mobile malware, please check out our SandBlast Mobile product page.
Indicators of Compromise