Recently, the SlowMist security team received multiple reports that users’ assets were stolen. After verification, all the related incidents involved the leakage of private keys. Some affected users had downloaded and used the FomoPeek 1.1–1.2 App versions.
Together with the OKX Security team, we jointly analyzed and confirmed that FomoPeek 1.1 and 1.2 implanted two malicious modules, apptrace and libapptracecore, which have the capabilities of remote configuration, kernel vulnerability exploitation, sandbox escape, Keychain decryption, and cross-app data collection.
Dynamic verification shows that the app retrieves encrypted C2 addresses from Bitbucket, reports device information to api-a95f0ed200f.assisaint[.]com, and receives remote configurations. During testing, the C2 returned exploit_enabled as false. To verify the subsequent execution chain, in an isolated environment we used Hook to modify relevant switches after the client decrypted them to true. We then obtained a collection manifest targeting 19 wallets and note applications, and captured the full request for packaging and uploading the Apple Notes container.
By hooking the client-side encryption function, we decrypted the requests and responses of this channel. The configuration returned by the server proves that attackers can remotely initiate exploitation, adjust the execution cycle, and control its periodic repetition via the server.
We performed reverse engineering and sample tracing based on historical version IPAs obtained from official App Store channels. The results showed that version 1.0 did not contain the aforementioned malicious module; version 1.1 (build 105) was first implanted on September 9, 2026; version 1.2 (build 110) was released on September 12 and used the same code; and version 1.3 (build 111) removed both frameworks entirely on September 17. Therefore, the affected App versions are clearly 1.1 and 1.2, and the malicious module was distributed through official App Store versions, not through third-party re-signing or sideloading.
The framework declares at the code level that the system version coverage is iOS 12.0–18.7.2 and iOS 26.0–26.1, indicating that its attack targets are not limited to low-version systems or old devices.
MistEye Response
MistEye is a Web3 threat intelligence and dynamic security monitoring system independently developed by SlowMist. It integrates security monitoring and intelligence aggregation capabilities to provide users with real-time risk warnings and asset protection.
MistEye immediately synchronized the risk information with the customer's alert channel via intelligence push notifications.
I. Background
1.1 From User Feedback to Sample Tracing
Some users whose assets were stolen had installed and used FomoPeek before the incident. To verify the connection between this and the private key leak, we obtained historical version IPAs of the application from official App Store channels and conducted a version-by-version analysis of the package structure, loading dependencies, signature attribution, and binary content.
1.2 An App That Looks Completely Legitimate
Based on publicly available information, FomoPeek possesses all the features a normal project should have:
The app is listed normally on the App Store, has an official website and social media accounts, and is positioned as a "read-only on-chain monitoring and alerting tool," without connecting to wallets or requiring users to memorize words. Therefore, it is difficult for either the review panel or the user to associate it with kernel vulnerability exploitation based solely on its appearance.
1.3 Dissemination Path: KOL Invitation Code and Real Device Retention for 5–7 Minutes
Publicly available promotional information shows that FomoPeek primarily spreads through cryptocurrency KOLs and related communities. Users need to download and register from the App Store using an invitation code, set a "security code," add a monitoring wallet, and operate on a real device for several minutes. After verification, they can receive 5-7 USDT. Some promotional content also specifically emphasizes that "each iPhone has only one chance," "multiple accounts on the same device are invalid," and "must use a real device and stay on it for 5-7 minutes."
This requirement is noteworthy. The sample integrates an exploit strategy called CicutaVirosaStrategy, whose publicly available exploit, cicuta_virosa, requires more than two minutes to run per cycle. Therefore, the promotion rule of "must be a real device, cloud phones are invalid, and it needs to run for several minutes" matches the technical characteristics of a kernel exploit chain requiring continuous operation on a real device for a period of time. However, this promotion rule can only serve as supplementary clues and cannot be used alone to determine its malicious intent.
In mid-September, user warnings appeared on public social media platforms. On September 16, 2026 at 17:11 UTC, user Jin Hui (@GXingPing) posted that his FomoPeek software had been stolen after downloading it, and warned users to uninstall the software as soon as possible.
Even before users began reporting their assets being stolen, the ability to extract iOS data related to such incidents had already been publicly warned. On March 25, 2026, SlowMist's Chief Information Security Officer, @im23pds, issued a security alert: the DarkSword attack tool had been leaked and could extract and transmit forensic-grade data from iOS devices via HTTP interfaces. Attackers could also combine this with social engineering or watering hole attacks to lure targets to websites or pages that had been implanted with malicious code, thereby stealing data from iPhones and iPads and uploading it to servers controlled by the attackers.
1.4 Anomalies in Subject and Timeline
Public information shows that the seller registered with Apple is Porter Manufacturing, L.L.C., and the developer is listed as WhaleScanv, which currently only has one app, FomoPeek, under its name.
Since publicly available information is insufficient to confirm the actual operating entity behind this seller, this article will not further attribute its identity or its relationship with companies of the same name. However, judging from the timing of domain registration, privacy policies, application release, and malicious module implantation, the relevant web identity and distribution infrastructure were all established in a relatively short period of time.
The following timeline warrants attention:
From domain registration to app launch, it took only about 10 days, and the privacy policy's "effective date" was two days earlier than the domain registration date. The entire web identity and distribution chain was built intensively from the end of August to the beginning of September.
1.5 Conflict between the privacy label and its own privacy policy
The App Store page displays "No data collected" in the "App Privacy" section, but FomoPeek's official website privacy policy clearly lists the types of data it processes, including: X-Device-Id (device identifier), APNs push tokens, email addresses, passwords (bcrypt hashes), nicknames, two-factor authentication codes (bcrypt hashes), as well as public wallet addresses, tags, thresholds, and event preferences added by users.
Even without considering kernel vulnerability exploits, the "uncollected data" reported to Apple contradicts the scope of data collection outlined in its privacy policy.
II. Version Timeline and Poisoning Scope
We found two frameworks unrelated to business functionality within packages 1.1 and 1.2:
Version comparison shows that versions 1.1 and 1.2 carry the same malicious module, with identical code and data segments; version 1.3 removes both frameworks entirely, reducing the IPA size from 10.47 MB to 1.81 MB.
The main program and both frameworks use the same Apple signing body, and the original IPA also retains FairPlay encrypted metadata, indicating that the malicious module belongs to the official package content submitted by the developer to the App Store, rather than a third-party re-signed or sideloaded product.
III. Malicious Module Analysis
3.1 Two business-independent frameworks
The two modules have a clear division of labor: apptrace is responsible for C2 communication, while libapptracecore is responsible for kernel attacks and data collection.
The namespace distribution of libapptracecore illustrates its nature: it is not a component for instrumentation, statistics, or anti-debugging, but rather a complete toolchain from exploitation to kernel access, permissions and sandboxing, keychain, and acquisition. apptrace handles all communication with the external control terminal, and the two together form a "communication + attack" implant.
3.2 Loads upon startup; the main program contains no call traces.
The main program's Mach-O load command references two frameworks with LC_LOAD_DYLIB (non-weak):
@rpath/apptrace.framework/apptrace
@rpath/libapptracecore.framework/libapptracecore
This means that regardless of whether the business logic calls it or not, both will be loaded into the same process by dyld when the App starts.
On the other hand, the main program side indeed does not contain any explicit call traces: all 1,048 imported symbols in the symbol table come from system libraries, and the ObjC class references only contain system classes. Apart from the two loading paths mentioned above, no class names or method names of the framework can be found. The framework itself does not have ObjC's +load / +initialize. A three-level call tracing of the 34 C++ static initialization functions (__mod_init_func) also did not reach the exploitation and collection code.
Therefore, at the static level, it can be confirmed that the module is forcibly loaded into the process when the app starts, and the capability code is complete; the actual triggering time and execution evidence need to be verified dynamically on a real device.
3.3 Kernel Attack Framework: 8 Exploitation Schemes and Automatic Version Matching
libapptracecore implements 8 exploit strategy classes, all of which inherit from exploit::IExploitStrategy / KernelMachTaskExploitStrategyBase, and each strategy has a built-in determination of "whether the current device is supported":
The eight strategy version windows are linked end-to-end, with code declarations covering iOS 12.0–18.7.2 and iOS 26.0–26.1. The framework will determine the availability of a strategy based on the system version and device model, and distinguish between three outcomes: successful exploitation, failed exploitation, and unsupported device.
The built-in device list also includes models from 2023 to 2025 such as iPhone 16, 1/16, 2, iPhone 17, 1–17, 5, iPad 15, 3–15, 6, and iPad 16, 1–16, 6, indicating that the target devices are not older devices.
3.4 Kernel Read/Write and Privilege Escalation
Kernel task ports: Creating safe tfp0, testing new tfp0 port, Updated port for tfp0!, failed to allocate new tfp0 port
内核读写原语：kread (found kread_sem_index / error on kread)、kwrite、mach_vm_read_overwrite / mach_vm_write / mach_vm_allocate
利用面：IOSurfaceRootUserClient、IOSurfaceClient、IOAccelCommandQueue2、IOAccelSharedUserClient2
Protection bypass: HSP4 patch exists. Applied HSP4 patch. (PPL bypass)
The structural offsets originate from the kernel::OffsetProvider iOS12 / 13 / 14 / 15 / 15_2 static table, as well as the runtime offset calculation branch for iOS 16 and above (with dedicated handling for 16, 18, and 26 internally).
提权：permissions::KernelUcredStealer、permissions::RORestrictedUcredPatcher、permissions::RO2RestrictedUcredPatcher（含 WeirdCsTrick / WeirdCredTrick）
3.5 Sandbox Escape and Keychain Decryption
The sandboxing is handled by permissions::SandboxExtPatcher, with the target permission string being com.apple.app-sandbox.read-write. Once the sandbox is broken, the process can read paths outside the application container.
The keychain section is the most directly hazardous part of the entire system.
System service interaction: AppleKeyStore client initialization (Initialized AppleKeyStore client, Device failed to start AppleKeyStore client with err ...), keyBag, pkcs8ShroudedKeyBag
Database parsing: keychain::KeychainV3, KeychainV9, KeychainV11, corresponding to different keychain database formats for different iOS versions.
Serialization structures: SecDbKeychainSerializedAKSWrappedKey, SecDbKeychainSerializedItemV7, SecDbKeychainSerializedMetadata, SecDbKeychainSerializedSecretData
解密与导出：keychain::GetRawKeychain、parsing::DecryptSFA、keychain::AgentKeyUnwrapper、acquisition::server::RawKeychainDecryptDataWriter
3.6 C2 Channel Bitbucket Dead Mailbox Encrypted Reporting
After running the affected version on an isolated device (disguised as an iPhone 16 / iOS 26.1), we captured two requests that were completely unrelated to our business and fully decrypted their contents.
① Dead Mailbox: Retrieves an encrypted list of C2 addresses from a public code hosting site.
GET hxxps://bitbucket[.]org/discordseven/text/raw/main/xxhVOn
This repository (bitbucket[.]org/discordseven/text) is a public repository. The README and .gitignore files are Bitbucket's default templates and are used only for appearance purposes. The repository was created on August 4, 2026, and the submitter's email address is discdseven@outlook.com. The xxhVOn file contains an encrypted list of C2 addresses.
The file is 48 bytes of AES-CBC ciphertext.
After startup, the client decrypts the data using the embedded key, obtaining a list of C2 addresses: ["hxxps://api-a95f0ed200f.assisaint[.]com"].
The file has been modified three times in history: 2026-08-04 (64 bytes), 2026-08-06 (48 bytes), and 2026-09-13 (48 bytes, i.e., the day after 1.2 was released).
Attackers can change the C2 addresses of all victims simply by editing this one public file, without having to release a new version of the app.
② C2 Reporting: Encrypted device information and remote commands
The C2 domain assisaint[.]com was registered on 2026-09-12 (the same day that version 1.2 was launched), with Cloudflare as the registrar, and the origin server is hidden in the front-end configuration; another subdomain in the same domain, bp-a95010ced.assisaint[.]com (a 90-day certificate issued by TrustAsia), can also be seen in the CT logs.
③ Decryption result
The client uses CommonCrypto's CCCrypt (alg = kCCAlgorithmAES(0), options = kCCOptionPKCS7Padding(1), i.e., AES-CBC + PKCS7) to encrypt the message body. By hooking this function, we obtain the session key and decrypt the two-way plaintext:
The request body `params`, after decryption, contains device information to be reported:
{"app_version":"1.0.5","app_pac":"com.fomopeek.app","app_uuid":"7A5475A0007346BCB6EDB30E43315999","timestamp":1789806193645,"machine":"iPhone 16","ios_version":"26.1"}
The response data, after decryption, becomes a remote command:
{"version":"1.0.0","min_close_exploit_version":"","exploit_enabled":false,"exploit_repeat_enabled":false,"exploit_test":false,"app_log_report_enabled":false,"exploit_repeat_interval":86400}
Dynamic verification confirms that all dead mail and C2 requests are issued by apptrace (multipart boundary prefix is ---AppTraceBoundary), while exploitation policies, kernel read/write, keychain decryption, and port 40000 services are all located in libapptracecore.
It should be noted that in this run and the packet capture at 08:23 on 2026-09-19, exploit_enabled was false; however, the existence of this switch and its periodic parameters indicates that attackers can enable exploitation, adjust the execution cycle, or forcibly disable it at any time through server-side responses without updating the app. Meanwhile, the test virtual device's self-reported profile (iPhone 16 / iOS 26.1) falls precisely within the coverage area of DarkSwordStrategy (16.7–18.7.2 and 26.0–26.1) described in Section 3.3.
3.7 Remote Data Acquisition Targets: 19 Wallet and Notes Applications
To verify what happens when the switch is turned on, we used Frida to rewrite exploit_enabled / exploit_repeat_enabled / exploit_test in the response to true in the decryption callback, and then observed the client behavior.
When the client retrieves the configuration again, in addition to the on/off status, it also receives a list of collection targets (`collect_configs`) – this directly reveals the intent of this operation:
The collect_configs issued by C2 contains 19 collection targets, almost all of which are wallet apps, including Gate Web3, SafePal, OKX Wallet, MetaMask, Trust Wallet, imToken, TokenPocket, TronLink, etc.
The data collection paths are concentrated in the keystore, SQLite, MMKV, React Native local storage, and the Keychain access group, and include the entire Apple Notes container group.com.apple.notes. These configurations indicate that the attack targets wallet key materials and other sensitive information saved by the user, and that the scope of collection can be dynamically adjusted by the server.
At this point, the malicious module's attack capabilities and the targeted data collection information issued by C2 form a complete chain of evidence.
3.8 External transmission link: POST /api/upload/zip
After triggering the data collection, we captured a multipart request sent to /api/upload/zip. The params field contains AES-CBC encrypted file metadata, while the file field contains an unencrypted ZIP archive.
The decrypted metadata shows that the upload target was group.com.apple.notes, the archive size was 46,092 bytes, and it included the file MD5, device UUID, destination path, and timestamp. The restored ZIP file contains NoteStore.sqlite, WAL files, and related configuration files, consistent with the structure of Apple Notes containers.
This confirms that the sample reads the target container according to the list issued by C2, packages the results and temporarily stores them in its own sandbox, and then uploads them to /api/upload/zip.
We reconstructed the archive itself from this message; the archive content is the Apple Notes container.
group.com.apple.notes/NoteStore.sqlite 307,200
group.com.apple.notes/NoteStore.sqlite-shm 32,768
group.com.apple.notes/.com.apple.mobile_container_manager.metadata.plist 577
group.com.apple.notes/Library/Preferences/group.com.apple.notes.plist 127
group.com.apple.notes/NoteStore.sqlite-wal / com.apple.notes.databaseopen.lock
At this point, we have verified the target container reading, file packaging, and data upload process in the isolated test environment. Combining the kernel exploitation, privilege escalation, and sandbox escape code within the framework, we can reconstruct its design chain: remote configuration distribution → kernel exploitation and privilege escalation → target data collection → packaging and upload.
3.9 Other C2 endpoints: Application inventory and execution postback
In addition to configuring the endpoints for data distribution and transmission, we also identified two supporting endpoints that together constitute a complete C2 protocol of "reconnaissance → issuing commands → data collection → data transmission".
① /api/device/apps: Report a list of installed applications
The `params` section of this request, after being decrypted using the same KEY/IV, contains a list of bundle IDs for all 135 applications on the device.
{"app_uuid":"7A5475A0007346BCB6EDB30E43315999",
"apps"：["com.apple.Home.HomeControlService","com.apple.CarCamera","com.debank.rabby-mobile-regression","com.apple.ScreenSharingViewService","com.okx.wallet", … 共 135 项 …]}
The purpose of this list is straightforward: the server uses it to determine which wallets are installed on the device, and then decides which `collect_configs` to send.
② /api/device/report: Execution result feedback and subsequent instructions
③ Summary of confirmed C2 endpoints
3.10 Characteristics of C2 Domain Registration and Deployment
The conclusions of the infrastructure survey of the C2 domain itself are as follows:
The domain name was registered relatively recently and employs privacy protection for registration information, Cloudflare reverse proxy, and rapid certificate deployment, which are common characteristics of short-lived attack infrastructure. The domain registration date coincides with the launch date of FomoPeek 1.2, which can serve as a temporal clue; however, the publicly available information is insufficient to determine the origin site location or the attacker's affiliation.
When checking the public infrastructure of this domain name, it can be seen that one of the subdomains hosts a management interface called Collect, whose front-end routes show entries related to devices, applications, and keys (/machineApp, /machineApp/needBlast, /machineApp/walletAddress, /machineAppKeys, /machineStat, /mnemonic, /partner/account, /partner/home, /partner/machine/detail, etc.):
This indicates that the domain name does not carry a regular business API, but rather an operations-side interface that is associated with device data collection and key-related data; its specific functions and fields will not be elaborated upon in this article.
IV. Attack Chain Review
Module loading: When the app starts, apptrace and libapptracecore are forcibly loaded;
Obtain C2: Retrieve the ciphertext from Bitbucket and decrypt it to obtain the C2 address;
Equipment reconnaissance: Report equipment information and a list of installed applications;
Configuration distribution: Obtain the vulnerability exploitation switch, execution cycle, and data collection targets;
Exploitation and Privilege Escalation: Select a matching kernel exploit strategy to gain unauthorized read capabilities and break through the sandbox;
Data collection and transmission: Read the target App's data and Keychain, package them, and upload them to /api/upload/zip.
V. MistTrack On-Chain Analysis
Through tracking and analysis of the collected on-chain data, it was found that the attackers stole funds across multiple chains (TRON, Ethereum, and other EVM-compatible chains). This section only analyzes the primary hacker address (0x6d37f2C5e8F8546b648D317295565dA95975f4BB).
According to MistTrack data, the address has earned a total of 579,984.34 USDT and has been active since September 15.
Its financial activities cover multiple chains including Ethereum, BNB Chain, and Arbitrum, and funds are still flowing in as of the time of writing. Current balances are as follows:
Most of the funds in this address are aggregated to the Ethereum network, while the remaining funds on the chain are mainly converted into USDT through cross-chain/exchange platforms such as OKX DEX, Meson.fi, Relay.link, and Mayan Finance before being transferred to Ethereum.
Subsequently, the address transferred the collected USDT in batches to the following downstream addresses:
（1）0x0A571f0Fa18D7EB9abcc1e98a0Bb9bC15534BbAe
The address currently has a balance of 24,352 USDT. It's worth noting that this address was already active on May 23rd, earlier than the main attack window of this incident.
It interacts with FixedFloat, cce.cash, OKX, etc.
In addition, a large sum of 111,458 USDT was transferred out to address 0x4c73d7e8ef0e61129403e219debc597fd43aa0ec and then transferred into USDT0: UsdtOFT for cross-chain processing.
The cross-link receiving address was the TRON address TF2hm96RC2Aqon9FeQjGidofoC2J1zM8v1. This address received a total of 2,123,570.8821 USDT, which was subsequently distributed through multiple addresses and transferred to what appears to be an OTC platform.
（2）0x0DF6aC2e2856114228756947d1b1d9Ff63eA3e68
This address has received a total of 159,000 USDT:
All funds will be transferred to FixedFloat:
(3) 0x2d53113c89c83c520c17b8bbcdc22aa0518a38be
This address has received a total of 47,028 USDT.
Of the total, 10,000 USDT was transferred to KuCoin, and the remaining 37,028 USDT was transferred to FixedFloat.
（4）0x111faeb95cd0786593433bcc762dc5c1debf541c
This address has received a total of 227,154 USDT.
215,000 USDT transferred to FixedFloat, 10,000 USDT transferred to cce.cash:
The remaining 2,154 USDT was exchanged for 6,432.54 TRX via Bridgers Swap and cross-chained to the TRON address TUi5qPcjDuqbmwfunMbzwkpLNhaqRpqcJg. Most of the TRX was eventually transferred to FixedFloat. It's worth noting that a significant portion of the funds in address TUi5q originated from cce.cash.
We will continue to monitor the fund activity of the above addresses. If you have ever installed FomoPeek and have recently experienced asset theft, you can submit the stolen address and the hacker's address to the following link: https://aml.slowmist.com/cn/recovery-funds.html.
VI. Threat Indicators (IOCs)
URL :
hxxps://api-a95f0ed200f.assisaint.com/api/device/config
hxxps://bp-a95010ced.assisaint.com
hxxps://admin-e433360cb0e.assisaint.com
hxxps://customer-c1cb36b5.assisaint.com
hxxps://bitbucket.org/discordseven/text/raw/main/xxhVOn
Domain:
assisaint[.]com
api-a95f0ed200f[.]assisaint.com
bp-a95010ced[.]assisaint.com
admin-e433360cb0e[.]assisaint.com
customer-c1cb36b5[.]assisaint.com
File:
FomoPeek-1.1-891048157.ipa
MD5: fce99b45709a6f8e241175be0c121874
SHA-256: d6b6407b4c97697fdde174cbc190b6433315470f58df6b483ac5b806f35e20f9
FomoPeek-1.1.ipa
MD5: f5bdaed5953033ac8c3256f2933b9a81
SHA-256: ca5dfd0fa7a16f26f5b369516f5b8bcac1d5a6fe01a8511a5ededf4cd2c0d042
FomoPeek-1.2.ipa
MD5: 38a8a5ddecd9a5626b42dae593ac28f6
SHA-256: 48f9d5623af1518e774d57c41e6e0b915a7e9f896909bf596a9b27de5022911e
apptrace
MD5: 645b9053390246995c2cb7a9b9eddf40
SHA-256: 764663ff5c8bd1bdf33bbd1ec352ce262a4fe79695456f2612dc27c35840ab9d
libapptracecore
MD5: 03d67a68b5e8507dbbe36f2a4b41aca0
SHA-256: f0b3be01e8597f7f35ca36c009f68e7004527fe4a01d4349a01e211ca16de1e2
VII. Recommendations for Investigation and Handling
7.1 User side
If your device has FomoPeek version 1.1 or 1.2 installed, please note: Uninstalling or upgrading to 1.3 does not mean that the device is secure. Once the framework is successfully exploited, the data it reads has already left the device.
1. Stop using the application immediately and do not reinstall it;
2. Create a new wallet, generate a new mnemonic phrase, and transfer assets on a secure device that has not had the application installed before; old mnemonic phrases and private keys are considered to have been leaked and are prohibited from being reused.
3. Investigate abnormal transfer and authorization records for each chain account one by one, and revoke authorizations that are no longer in use;
4. Change the password and login credentials used on this device and enable two-factor authentication;
5. Check if the device has a configuration profile/MDM installed, or if it has been side-loaded or jailbroken; if necessary, wipe the device and reinstall the system.
6. Retain the device and relevant evidence (App version, installation time, abnormal transaction records) for further verification;
7. If you discover any unusual asset activity, please contact the relevant platform's official customer service immediately.
7.2 Platform and Ecosystem Side
1. Incorporate file hashes, class names, key strings, and network features into the sample library, EDR, and traffic detection rules;
2. Issue targeted risk warnings to users who have installed FomoPeek 1.1 or 1.2, and handle the matter as a credential breach incident;
3. Block assisaint[.]com and its subdomains, bitbucket[.]org/discordseven/*;
4. Starting from September 9, 2026, retrieve access records for the Bitbucket dead mailbox. Starting from September 12, retrieve DNS, proxy, EDR, VPN, and mobile device logs related to *.assisaint[.]com. If the log retention period allows, further trace back to August 4 to investigate access to this Bitbucket repository and historical C2 configurations.
VIII. Summary
Through static analysis and dynamic verification, we confirmed that FomoPeek 1.1 and 1.2 have implanted two malicious modules, `apptrace` and `libapptracecore`, which have the capabilities of remote configuration, kernel vulnerability exploitation, sandbox escape, Keychain decryption, and cross-application data collection.
After triggering the relevant functions in the isolated environment, the sample obtained a collection list of 19 wallets and note-taking applications from C2, and uploaded the Apple Notes container to `/api/upload/zip`, verifying the complete technical chain from remote configuration, unauthorized reading to data transmission.
The aforementioned module was not found in FomoPeek 1.0, was first implemented in version 1.1, continued to be used in version 1.2, and was completely removed in version 1.3. For users who have used version 1.1 or 1.2, simply uninstalling or upgrading the application cannot eliminate the risk of historical data leaks. It is recommended to treat related mnemonic phrases, private keys, and sensitive credentials as if they have been leaked.
Frequently Asked Questions (Q&A)
Q1: When did this incident occur?
The currently confirmed risk window is from September 9 to September 17, 2026.
FomoPeek 1.0 was first released on August 29, and no malicious modules were found at that time. Version 1.1, released on September 9, first injected apptrace and libapptracecore, and version 1.2, released on September 12, continued to carry the same set of malicious code. It was not until version 1.3 was released on September 17 that these two frameworks were completely removed.
On September 16, warnings appeared on public social media platforms about users experiencing asset theft after installing FomoPeek. Since complete installation and theft times are not available for all victims, it is currently impossible to determine the exact time of the earliest actual attack.
Q2: Which versions are affected?
In terms of app versions, FomoPeek 1.1 and 1.2 are clearly affected.
1.0: No malicious modules found;
1.1: Initial implantation of a malicious module;
1.2: Continue to carry the same set of malicious modules;
1.3: The relevant framework has been completely removed.
Judging from the iOS coverage declared in the attack framework code, it has 8 built-in exploitation strategies, covering iOS 12.0–18.7.2 and iOS 26.0–26.1, and will select the corresponding exploitation strategy according to the device model and system version.
It's important to note that FomoPeek lists iOS 16.0+ as the system requirement on its App Store page. Therefore, the "theoretical coverage of the attack framework" and "the actual range of devices that FomoPeek can be installed on through the App Store" are not entirely the same concepts.
Q3: Through what avenues might an attack occur?
In this FomoPeek incident, the confirmed entry point for propagation is the official App Store version itself, not third-party re-signed, enterprise-signed, or side-loaded installation packages. The malicious framework uses the same Apple signing entity as the main program, and the original IPA also retains FairPlay encrypted metadata.
FomoPeek primarily attracts users to install the app through crypto KOLs, communities, referral codes, and small USDT rewards, while requiring users to run it on a real device for several minutes.
However, from the perspective of the attack techniques themselves, this type of iOS kernel exploit is not necessarily limited to a single app. Theoretically, similar capabilities can also be triggered through: malicious or compromised apps, supply chain components, phishing pages, compromised websites, and watering hole pages targeted at specific groups of people.
The previously mentioned public warnings about DarkSword also pointed out that attackers may combine social engineering or watering hole attacks to lure targets to websites or pages with implanted malicious code, thereby further stealing data from iPhones and iPads.
Therefore, do not simply assume that "from the App Store" or "from a website you frequently visit" is absolutely safe.
Q4: What is a "watering hole attack"?
The idea behind a "watering hole attack" is not to directly find every victim, but to first find places that the target group frequently visits and trusts.
For example, if an attacker wants to target a group of cryptocurrency professionals, they might first analyze which industry websites, tool sites, communities, project websites, or event pages these people frequently visit, and then look for targets among them that can be compromised or have malicious code implanted.
Once these legitimate websites are compromised, victims could easily fall into the attack chain simply by accessing them as usual.
The name comes from the "waterhole" in nature: predators do not need to chase every prey, but only need to wait at the place where the animal often drinks water.
For mobile devices, this "puddle" can also be understood as a broader trusted entry point: it could be a familiar website, a long-used app, a third-party SDK, a community link, or even a normal application update.
Q5: Are similar risks only present in FomoPeek?
no.
What's more noteworthy about FomoPeek isn't just whether a particular wallet user has installed the app, but that it demonstrates once again that attack entry points can be hidden in seemingly normal apps, even those from official app stores.
Among publicly available cases, ComeCome (拜托拜托) provides another noteworthy example. Public analysis shows that this is a food delivery app targeting Chinese users in Dubai and other regions. Its version 2.9.3 was found to contain a hidden component called DKStatistics, which has the ability to bypass the iOS sandbox and access data from wallet apps, WhatsApp, and Apple Notes; the public page also discloses related on-chain fund flows. It should be noted that the website also clearly distinguishes between "publicly verifiable technology and on-chain facts" and "inability to directly attribute to an actual attacker."
These cases serve as a reminder:
A "watering hole" doesn't necessarily look like a dangerous website. It could be a website you open every day, a tool, a food delivery app, a community link, or even software downloaded from an official store.
Traditionally speaking, FomoPeek and ComeCome are closer to app-based or trusted-channel-based malware attacks than classic web-based watering holes; however, their underlying attack strategies are very similar—first, they enter the target group's trusted and frequently used entry points, and then wait for the target to actively enter the attack environment.
Therefore, it's not just one FomoPeek that we really need to be wary of. Watering puddles can exist anywhere that a target group has long trusted.
ComeCome's public case studies can be found at: https://comecome.icu/
About MistEye
MistEye is a Web3 threat intelligence and dynamic security monitoring platform independently developed by SlowMist. It provides malicious activity detection and supply chain risk warning capabilities from the open-source package ecosystem through API.
All malicious packages and IOCs involved in this operation have been integrated into the MistEye threat detection engine. Developers can use the API to automatically detect project dependencies, quickly determine whether they contain known malicious packages, and obtain handling suggestions.
📖 API Documentation: https://app.misteye.io/api-docs
🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan A lightweight CLI tool that scans project dependencies and globally installed packages for known malicious packages with a single command. Supports the npm / PyPI / Cargo / Go / RubyGems ecosystem.
🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skillsAI A coding assistant security skills package that automatically triggers MistEye security checks before dependency installation and URL access.
🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-Guard A DNS security tool that detects malicious domains and risky access, and identifies phishing, C2, and other network threats.
This article was written by the SlowMist Threat Intelligence Team in conjunction with the MistEye Threat Intelligence System and SlowMist Agent AI-driven analysis. Please feel free to contact us with any questions or feedback.