AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device - Palo Alto Networks BlogPalo Alto Networks Blog AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device
We've discovered a new family of iOS malware that successfully infected non-jailbroken devices we've named "AceDeceiver".
What makes AceDeceiver different from previous iOS malware is that instead of abusing enterprise certificates as some iOS malware has over the past two years, AceDeceiver manages to install itself without any enterprise certificate at all. It does so by exploiting design flaws in Apple's DRM mechanism, and even as Apple has removed AceDeceiver from App Store, it may still spread thanks to a novel attack vector.
AceDeceiver is the first iOS malware we've seen that abuses certain design flaws in Apple's DRM protection mechanism — namely FairPlay — to install malicious apps on iOS devices regardless of whether they are jailbroken. This technique is called "FairPlay Man-In-The-Middle (MITM)" and has been used since 2013 to spread pirated iOS apps, but this is the first time we've seen it used to spread malware. (The FairPlay MITM attack technique was also presented at the USENIX Security Symposium in 2014; however, attacks using this technique are still occurring successfully.)
Apple allows users purchase and download iOS apps from their App Store through the iTunes client running in their computer. They then can use the computers to install the apps onto their iOS devices. iOS devices will request an authorization code for each app installed to prove the app was actually purchased. In the FairPlay MITM attack, attackers purchase an app from App Store then intercept and save the authorization code. They then developed PC software that simulates the iTunes client behaviors, and tricks iOS devices to believe the app was purchased by victim. Therefore, the user can install apps they never actually paid for, and the creator of the software can install potentially malicious apps without the user's knowledge.
Figure 1 FairPlay MITM attack procedures
Three different iOS apps in the AceDeceiver family were uploaded to the official App Store between July 2015 and February 2016, and all of them claimed to be wallpaper apps. These apps successfully bypassed Apple's code review at least seven times (including the first time each was uploaded and then four rounds of code updates, which require an additional review by Apple for each instance) using a method similar to that used by ZergHelper, where the app tailors its behavior based on the physical geographic region in which it's being executed. In this case, AceDeceiver only displays malicious behaviors when a user is located in China, but that would be easy for the attacker to change in any time. Apple removed these three apps from the App Store after we reported them in late February 2016. However, the attack is still viable because the FairPlay MITM attack only requires these apps to have been available in the App Store once. As long as an attacker could get a copy of authorization from Apple, the attack doesn't require current App Store availability to spread those apps.
To carry out the attack, the author created a Windows client called "爱思助手 (Aisi Helper)" to perform the FairPlay MITM attack. Aisi Helper purports to be software that provides services for iOS devices such as system re-installation, jailbreaking, system backup, device management and system cleaning. But what it's also doing is surreptitiously installing the malicious apps on any iOS device that is connected to the PC on which Aisi Helper is installed. (Of note, only the most recent app is installed on the iOS device(s) at the time of infection, not all three at the same time.) These malicious iOS apps provide a connection to a third party app store controlled by the author for user to download iOS apps or games. It encourages users to input their Apple IDs and passwords for more features, and provided these credentials will be uploaded to AceDeceiver's C2 server after being encrypted. We also identified some earlier versions of AceDeceiver that had enterprise certificates dated March 2015.
As of this writing, it looks as though AceDeceiver only affects users in mainland China. The bigger issue, however, is that AceDeceiver is evidence of another relatively easy way for malware to infect non-jailbroken iOS devices. As a result, it's likely we'll see this start to affect more regions around the world, whether by these attackers or others who copy the attack technique. In addition, the new attack technique is more dangerous than previous ones for the following reasons:
- It doesn't require an enterprise certificate, hence this kind of malware is not under MDM solutions' control, and its execution doesn't need user's confirmation of trusting anymore.
- It hasn't been patched and even when it is, it's likely the attack would still work on older versions of iOS systems.
- Even though these apps have been removed from the App Store, that doesn't affect the attack. Attackers do not need the malicious apps to be always available in App Store for them to spread – they only require the apps ever available in App Store once, and require the user to install the client to his or her PC. However, ZergHelper and AceDeceiver have shown how easy it can be to bypass Apple's code review process and get malicious apps into the App Store.
- The attack doesn't require victims to manually install the malicious apps; instead, it does that for them. That's why they can be only available in a few regions' App Store without affecting the success of the attack. This also makes them much harder to be discovered by Apple or by security firms researching iOS vulnerabilities.
- While the attack requires a user's PC to be infected by malware first, after that, the infection of iOS devices is completed in the background without the user's awareness. The only indication is that the new malicious app does appear as an icon in the user's home screen, so the user may notice a new app he or she won't recall downloading.
Our analysis of AceDeceiver leads us to believe FairPlay MITM attack will become another popular attack vector for non-jailbroken iOS devices – and thus a threat to Apple device users worldwide. Palo Alto Networks has released IPS signatures (38914, 38915) and has updated URL filtering and Threat Prevention to protect customers from the AceDeceiver Trojan as well as the FairPlay MITM attack technique.
In the rest of this blog we will take a detailed look at AceDeceiver's method of spreading, attacking, and implementation. We will also cover how the FairPlay MITM attack works and discuss the security flaws in Apple's DRM technology.
Timeline of the Threat
Jan 2013: FairPlay MITM attack has been used in the wild to spread pirated iOS apps.
Aug 2014: Researchers published paper to describe FairPlay MITM attack in the 23rd USENIX Security Symposium
Mar 26, 2015: AceDeceiver's enterprise certificate signed iOS apps added password stealing functionality. These apps were embedded into Aisi Helper Windows clients.
Jul 10, 2015: AceDeceiver's iOS app "爱思助手" was available in HK and NZ App Store
Jul 24, 2015: Aisi Helper Windows client updated to embed its App Store version iOS app
Nov 7, 2015: AceDeceiver's iOS app "AS Wallpaper" was available in US App Store
Jan 30, 2016: AceDeceiver's iOS app "i4picture" was available in US and UK App Store
Feb 21, 2016: Palo Alto Networks published report on ZergHelper
Feb 24, 2016: Palo Alto Networks reported the AceDeceiver issue to Apple
Feb 25, 2016: AceDeceiver apps were removed from App Store
Feb 26, 2016: Palo Alto Networks reported the FairPlay MITM attack issue in AceDeceiver to Apple
Background of AceDeceiver
The AceDeceiver Trojan exists in a product named "爱思助手 (Aisi Helper)" that was developed by a company located in Shenzhen, China. AceDeceiver's C2 server also shares the same domain name with the product's official website, www.i4[.]cn. The Trojan also used third-level URLs in this domain for downloading and updating.
Figure 2 Official website of Aisi Helper
Aisi Helper is a software program for Windows systems that claims to provide services for iOS devices such as system re-installation, jailbreaking, system backup, device management, system cleaning. When installed on a user's iOS device that is located in mainland China, it also provides access to a third-party App Store controlled by the attackers that could be used to install additional iOS apps or games to either jailbroken or non-jailbroken devices. Most of the iOS apps they provided appear to be pirated versions. Interestingly, according to ITJuzi, a Chinese business profiling website, Aisi Helper was initially released in January 2014 and at the time did not exhibit any malicious functionality. As of December 2014, it had accumulated over 15 million users and had over 6.6 million monthly active users. The malicious functionality doesn't appear to have been added until 2015.
When a user accesses the official website from a computer, it prompts the user to install Aisi Helper's PC client, regardless of the actual operating system running on the computer. Once installed, the PC client will automatically install the most recent malicious iOS app to any connected iOS device. However, if a user accesses the website from an iPhone or an iPad, the browser will be redirected to the site's mobile version (m.i4[.]cn) and an enterprise certificate signed version of its iOS client will be recommended. During our investigation in February 2016, all Aisi Helper Windows or iOS clients downloaded from the official website contained the AceDeceiver Trojan.
Given what we now know about the functionality of AceDeceiver, the website's legal announcement seems a bit suspicious. Section 7 says that "our website is not responsible for any personal data leakage, loss, theft, modification, etc. that happens as a result of a hacker's attack, computer virus intrusion, or other attack …"
Figure 3 The product claims it doesn't responsible for personal data leakage or loss
AceDeceiver Landed in the App Store Many Times
We found three iOS apps in the AceDeceiver family that successfully landed in the official App Store. The first app was released to the public on July 10, 2015, the second on November 7, 2015, and the third on January 30, 2016. All of them were designed to appear as legitimate wallpaper apps and each has a different name in the App Store, a different bundle identifier, and uses different developer accounts.
Figure 4 The third malicious app of the AceDeceiver family in the App Store
Name in App Store Versions Bundle ID Release Date Stores Developer 壁纸助手 6.0.x com.aisi.aisiring 2015-07-10 HK, NZ fangwen huang AS Wallpaper 7.0.x com.aswallpaper.mito 2015-11-07 US Yuzu He i4picture 7.1.x com.i4.picture 2016-01-30 US, UK liu xiaolong Table 1 Information of the three AceDeceiver apps in App Store
Normally, Apple does a code review on all apps the first time they are submitted for inclusion in the App Store. After being released, if the developer wants to make an update to the existing iOS app, Apple requires another round of code review for the newer version. To date, we've found that all of these apps were updated after they were accepted by the App Store. Which means, AceDeceiver successfully bypassed Apple's code review seven times.
Figure 5 User interface for users outside of China
When these apps are launched, before they show the first screen of the user interface, they will access the URL tool.verify.i4[.]cn/toolCheck.xhtml, which is AceDeceiver's C2 server. If the URL returns "0", the whole user interface of the attacker's third party app store will be shown. However, if the URL returns "1" or anything else but 0, the user will just be shown a wallpaper app interface, as seen in Figure 5.
Figure 6 iOS apps access C2 to determine which user interface to show
Figure 7 iOS app initial beacon to the C2
When we analyzed these apps in February, this C2 would only return "0" if the device had an IP address from mainland China. If that wasn't part of how the apps evaded Apple's code review, it's also possible the attacker set the server to always return "1" when they knew the apps were under review, so that no matter where Apple's reviewers are located they would always just get some beautiful-looking picture in a wallpaper app user interface.
In addition to the location trick, AceDeceiver also made some more effort to ensure it wouldn't be discovered.
First, the attacker chose to only submit these apps to a App Stores in select regions. Apple provides App Store services for 155 different regions around the world. Users usually can only choose to download from their local App Store, and they can't install apps that aren't available in their region. The aforementioned ZergHelper's author chose to submit it for all 155 regions, but AceDeceiver's did not. For example, the third app, "i4picture", was only available in the App Store for the United States and United Kingdom when we investigated it. Because of this distribution strategy, the author likely guessed that Apple would not review the app from China. It also significantly reduced the chance that the app would be discovered by security researchers, because if anyone downloaded this from the App Store, they're generally located in a region where the malicious functions won't take place.
Second, besides different user interfaces based on IP address, according to our testing, AceDeceiver will remember a device through the information it has collected. These apps will upload a device's unique ID to the C2 server. If a device is ever used from outside of China, even if it later changed back to a mainland Chinese IP address, the malicious functionalities will still be hidden.
Third, these apps will also show different names in different situations. For example, the version 6.0.4 used the same trick as ZergHelper in that, in the App Store's webpage, its name was "壁纸助手(Wallpaper Helper)"; while in iOS devices its name will become "爱思助手(Aisi Helper)". We found these name differences by checking the IPA file's iTunesMetadata.plist. Later, in version 7.1.2, the app has the name "爱思助手(Aisi Helper)" for iOS devices that use short-form Chinese language settings, while for all other devices its name was just "i4picture".
Figure 8 Different names in iOS devices and in App Store pages
Figure 9 Different names in devices using different languages
The FairPlay Man-In-The-Middle Attack
When we were investigating AceDeceiver, the strangest part was that this malware's apps were not available in App Store for mainland China and yet its malicious functionalities only target users in that region. This helped us to discover its exploitation of FairPlay MITM attack. Through the attack, these apps could be installed on iOS devices in a way not needing the App Store.
Figure 10 Authorize a computer in iTunes
FairPlay is a digital rights management (DRM) technology created by Apple many years ago to protect songs for use via iTunes and on iPods. Based on the DRM, Apple users can download iOS apps to their PCs or Macs through iTunes software, and then install these apps from their computers to their devices. Before the installation, users have to "authorize the computer" with the same Apple ID used to buy those apps. Apple restricted each Apple ID to only be used to authorize at most five computers. This process is what the attackers figured out how to abuse.
During an app's installation, a key step in the authorization procedures is that the connected iPhone or iPad will send afsync.rq and afsync.rq.sig files to the computer, and the iTunes software on the computer should send correct afsync.rs and afsync.rs.sig files as response back to the iOS device. Only if the responded afsync.rs are correct can the iOS device install the app and decrypt its DRM protection (The real protocol is more complex than our description here; we have simplified it for sake of argument.)
Figure 11 Normal authorization procedures during app installation
However, this procedure has some design flaws.
First, Apple only restricts the computer that should be authorized by the Apple ID that was used to purchase the iOS apps. There isn't any limitation about how many iOS devices those apps can be installed on.
Second, Apple allows the Apple ID being used to purchase apps to differ from the Apple ID that is actually used by the iOS devices.
Third, the DRM protecting apps' installer files (IPA files) will always be the same no matter which computers it will be downloaded to, and no matter which Apple ID was used to purchase them.
Overall, the problem is this: the FairPlay DRM protection is only relevant with the app itself, but is irrelevant respective to Apple ID, and is irrelevant respective to iOS device. Apple designed the protection mechanism in such a way that its security relies on computer authorization and physical connection between the computer and the device in question.
These design flaws allowed the FairPlay MITM attack. In such an attack, the attacker can authorize a computer, then purchase an iOS app from App Store (in any region) so that they could generate the correct afsync.rs response. Then, the attacker can deploy this afsync.rs as a service on the C2 server. Now, they can create client software for PC or for Mac. The client software simulates iTunes's functionalities that it connects with the iOS device and installs the iOS app. When the client received the afsync.rq from the iOS device, it could upload the file to C2 server, then get a correct afsync.rs response from C2 server, and send this response to iOS device.
By deploying authorized computer in the C2 server, and using a client software as agent in the middle, the attacker can distribute that purchased iOS app to unlimited iOS devices.
Figure 12 Authorization procedures in a FairPlay MITM attack
It's not easy to implement FairPlay MITM attacks considering that the attacker needs to reverse the iTunes client to know the proprietary protocols/algorithms employed by Apple. Even so, in January 2013, some media reported that this attack technique had been used in the wild to distribute pirated iOS apps. In August 2014, Tielei Wang and others from Georgia Institute of Technology published a paper, "On the Feasibility of Large-Scale Infections of iOS Devices," and presented at the 23rd USENIX Security Symposium. The paper described the attack in detail, demonstrated the attack by a proof-of-concept experiment, and evaluated how this attack approach could be used in a wide range.
Three years since the January 2013 reporting, as we're analyzing AceDeceiver, we have realized Apple still hasn't fixed this complex problem. What's more, iOS devices in current and older versions may still be vulnerable the same attack.
How AceDeceiver Used FairPlay MITM Attack
In our investigation, which covered Aisi Helper Windows client's version 5.38 to the newest available version (6.15), we found the clients to contain App Store versions of AceDeceiver iOS IPA file under path "files/i4/60.ipa". According to the updating logs on the official Aisi Helper website, version 5.38 was released July 24, 2015. That is just 14 days after the first of the three questionable iOS apps was available in App Store. Some more versions of the Windows client also contained a "files/i4/i4.ipa" which indicates enterprise certificates signed AceDeceiver iOS apps.
After installed the Windows client, when users connect iOS devices to their their PCs and launched the client, the embedded AceDeceiver app will be automatically installed on the devices using the FairPlay MITM attack. This does not require user confirmation. In its user interface, a progress bar will be shown with a message "Installing Aisi Helper…" but there isn't any option to stop it or cancel it.
Figure 13 Aisi Helper Windows client automatically instalsl the Trojan app
Our analysis below is based on the version 6.12 of the Windows client. The installer was downloaded from http://d.app6.i4[.]cn/i4tools/v6/i4tools_v6.12_Setup.exe in Feb 24, 2016. Its SHA-256 value is ad313d8e65e72a790332280701bc2c2d68a12efbeba1b97ce3dde62abbb81c97.
After the Windows client is installed, in its i4Tools.exe file, function sub_4A9530 is responsible for implementing the installation and exploitation. It invokes function sub_4A8CE0 to install the IPA file, and then invokes function auth to perform FairPlay MITM.
Function sub_4A8CE0 reads the IPA file stored in \files\i4\60.ipa, and then invokes am_install_app. The am_install_app function is implemented in i4m.dll file. It communicates with the com.apple.mobile.installation_proxy service to install the IPA file on the iOS device. This is a very classic method.
Figure 14 Install the IPA file to iOS device
Then, sub_4A9530 will invoke function auth which is also implemented in i4m.dll.
Figure 15 Invoke function auth with C2 URL for FairPlay MITM
The function auth implements the FairPlay MITM attack. It receives /AirFair/sync/afsync.rq from the connected iOS device, sends the file to C2 server auth3.i4[.]cn by HTTP POST (implemented in function sub_10005DB0), receives the afsync.rs from C2 server, and then sends this response back to the iOS device's /AirFair/sync/afsync.rs.
Figure 16 Auth function read afsync.rq file
Figure 17 Send the afsync.rq to C2 server via libcurl
Figure 18 Traffic of sending afsync.rq file
Figure 19 Copy the afsync.rs back to iOS
Stealing Apple IDs and Passwords
The iOS apps of AceDeceiver mainly act as a third party app store if users access them from China. Note that some of the apps or games they provide in the store are also installed through a FairPlay MITM attack. In addition, these apps strongly suggest users input their Apple ID with password so that users could "directly install free apps from the App Store, execute in-app purchase, and login to Game Center."
In the interface to input the Apple ID and password, AceDeciver provided buttons for "Instructions" and "Disclaimer". In all these documents, they claimed they will never send the passwords to their server, but will just store them in the local device after encryption. However, we can demonstrate that this is not true. Of note, the last section of the Disclaimer also indicates that if there's any abnormal activity related to a user's Apple ID, Aisi Helper doesn't take any responsibility for it.
Figure 20 iOS apps' interfaces of installing apps and input Apple ID
Figure 21 Instruction and Disclaimer of Inputing Apple ID
In fact, we discovered all versions of AceDeceiver will upload the Apple ID and password to the C2 server. In these iOS apps, after a user inputs any Apple ID with password, the app will invoke the [LoginEntity getLoginAppleId:withPassword:block:] method to get the Apple ID and the password from interface, then invoke [UserInfo initAppleId:WithPassword]. In this method, the Apple ID and password will be encrypted by RC4 algorithm with a fixed key. The key value is itself pretty interesting:
Figure 22 Apple ID and password are encrypted by RC4 algorithm
After encrypting, the Apple ID and password will be encoded by Base64 following by URL encoding, and then be set as properties appleId_RC4 and password_RC4 of an LoginEntity instance. Now [LoginEntity getLoginInfo] will be invoked. In this method, the encrypted Apple ID and password will be sent back to AceDeceiver's C2 server by URL "http://buy.app.i4[.]cn".
Figure 23 The encrypted Apple ID and password are sent to C2 server
During analysis, we input an invalid Apple ID: username "example@example.com" with the password "example123". Through network traffic we can see below this credential was sent to and was received by the server (since it responded HTTP 200).
Figure 24 Traffic of uploading Apple ID and password
Mitigate the Risk
All three Trojan apps of AceDeceiver were removed by Apple from App Store as of late February 2016. But even with their removal, the Aisi Helper Windows client can still install these apps to non-jailbroken iOS devices using a FairPlay MITM attack. We also reported older enterprise certificates signed versions of AceDeceiver apps to Apple. All of those known abused enterprise certificates have also since been revoked.
We suggest users who installed Aisi Helper's Windows client or iOS apps after March 2015 to remove these software and apps immediately, as well as change their Apple ID passwords. We also suggest all iOS users to enable two-factor authentication for their Apple IDs.
For enterprises, we suggest to check whether there's any iOS app installed to managed Apple devices by these bundle identifiers:
- aisi.aisiring
- aswallpaper.mito
- i4.picture
Since AceDeceiver also spreads via enterprise certificates, we suggest that enterprises check for unknown or abnormal provision profiles as well.
Until now all known malicious traffic comes from or goes to subdomains under i4[.]cn. Enterprises could also check traffic by this domain to identify potential traffic of AceDeceiver.
Conclusion
AceDeceiver shows yet another way attackers are getting around Apple's security measures to install malicious apps, particularly on non-jailbroken devices. Mobile is a huge growth area for malicious attackers and while Android devices have gotten the most attention for a few years now, attackers are turning increasingly to iOS devices because they are so widely popular. As of this writing, AceDeceiver is only targeting iOS devices in mainland China, but attackers could easily expand this attack to other regions around the world. And as we've already noted, the attack technique they're exploiting will not be easy for Apple to fix.
Palo Alto Networks has released a IPS signature (38915) to block AceDeceiver family's C2 traffic. The related C2 URLs are also marked as malicious by URL filtering and Threat Prevention. Palo Alto Networks WildFire recognizes all Windows clients of Aisi Helper as malicious.
Palo Alto Networks has also released another IPS signature (38914) to cover the FairPlay MITM attack.
Acknowledgements
We greatly thank Jen Miller-Osborn and Chad Berndtson from Palo Alto Networks for their assistance in developing this report. We also would like to thank Yi Ren, Tyler Halfpop, Yuchen Zhou and Rongbo Shao from Palo Alto Networks for their works to protect our customers from the threat.
IOCs
Trojan.Win32.AceDeceiver
ad313d8e65e72a790332280701bc2c2d68a12efbeba1b97ce3dde62abbb81c97 i4Tools_v6.12_setup.exe
9231166a2114f6b1c2d6cd6a57b5836e919ee5739d8868f07425d3c22697894e i4Tools.exe
78a2cdade1b0715e4f3f372e86724ee10e241ad8821c6b8caa3e84fd7e78ba7e i4m.dll
Trojan.iOS.AceDeceiver (App Store version, FairPlay DRM protected)
5894742146c02ba8af5390c91e4f0d2e5ad6cfaa2b916945ebb4fad633b054e3 601.ipa
ba07f252801120b081c45a173fb1a205fea763ed827f05fb9beb5150ae297ccb 60.ipa
f7e50fdc4f20f0d25771a694eb3f3643c1842e3b14f06aaa5e8d9dab1c1851e9 60.ipa
ca115f8a3751e4c0fc36b001e3c74d3ac167360a4a44fd1b373b25487de05820 60.ipa
3e02b30a6a920a5bdc139270b1e731a4a8d7ab313e9c8d9af9fec611710b4d09 60.ipa
006c539fa6251e1d2142631c52d7c112bf5027335696eacd64794b8cf357d6d5 60.ipa
fbc26c14a3ff609332644f5d9702f07ace024961b7aa2c531df2715911b1c57d bf03_710.ipa
Trojan.iOS.AceDeceiver (App Store version, FairPlay DRM stripped)
bc82efce99f149441a2fd730a961a0f7da58dd6c9c3b45597f5571f227a52309 com.i4.picture.ipa
ad7cfc29b0a9b6ade878d01084c68d0bbcde699e142652b00132317c04bcf730 aisiweb
Trojan.iOS.AceDeceiver (enterprise certificate signed versions)
0a8e29bd8fe0f5d4d6a8677454b1d01e97478dc4bc3666eaab6bbbf2f2e759bc
1b6cf5abe2bd3d5bb84da8debd5ec563393d30995ce4afc6142dc3381ac69902
352d1af3a5cef417dda688be2dd35c3f59841ea56c393a07f95a0bc5ab576448
5bc7ceb48ca4951997d50425d5b34484505e4444a3e172ab846b2595104b7138
5bebcacfb5c541bd6ba7530aeb2971c20adb1beddb244e4367d40cd87bfc826d
63e3cc1d00abef8ad6c2029e7f9a4831ec4c48682979a7385a940fb73cfc03a6
821f93bae8c067af71626ca84cdc20226df61c4c371e5eb6423d9439c8b8c25d
86b8065d40c24e3702ed848ec28650b074a577f677375c094ed61a2efffce11b
9a4a40625efcc6f4de419db0bec9fbdfdc379918a95fba572ee56cffc13cd074
a504d47fdfa630bc1c474cdbdaf0dd82a46a08e5d662ecc1bffc57f3c409690e
baa255dd7a0e52edf6e4f3082a6840800898969a3d17f2bcb6a88d0a94c5b795
bc5e3be07e65f25479cee7de8615b386c489c1253659ed7ca5526f86f5116374
c41e3abd97e16b3d9514583eef613105006d69dffb2231badfd500d29eb113bc
d879c6d96463b81e4f2085a565418c99b559a8803ca449442464a2b6cd728d97
f6cabdc408e12912c07097c9956ceda2f7033e88c2ca59d7618b9256d3724f5c
C2 Domains
- tool.verify.i4[.]cn
- auth3.i4[.]cn
- buy.app.i4[.]cn
~KLM\ All we have to decide is what to do with the time given to us //
Posted by: David Smith <david.smith.14916@gmail.com>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (2) |
