FakeWallet Cluster: 26 Malicious iOS Apps Hijacking Seed Phrases
Just caught the Kaspersky report regarding the 26 malicious applications infiltrating the App Store. It’s a classic case of social engineering bypassing technical controls. These apps don't just steal data locally; they perform an in-app redirection to a browser page designed to mirror the App Store interface to distribute a trojanized wallet.
From a defensive standpoint, relying solely on App Store vetting is dead. We need to look at the runtime behavior. The redirection is the key IOC here. If you have MDM logs, you might catch the SFSafariViewController or openURL calls to non-Apple domains immediately upon launch.
I've whipped up a quick Python script to simulate checking an IPA's Info.plist for suspicious URL schemes, though static analysis is tough since the redirection is often logic-based.
import plistlib
import sys
def check_url_schemes(plist_path):
with open(plist_path, 'rb') as f:
plist = plistlib.load(f)
url_types = plist.get('CFBundleURLTypes', [])
print(f"[*] Analyzing URL schemes for {plist.get('CFBundleDisplayName')}...")
for url_type in url_types:
schemes = url_type.get('CFBundleURLSchemes', [])
for scheme in schemes:
if scheme not in ['http', 'https', 'itms', 'itms-apps']:
print(f"[!] Custom scheme detected: {scheme}")
if __name__ == "__main__":
check_url_schemes(sys.argv[1])
Has anyone successfully blocked these using network policies, or is user education the only viable defense until Apple patches the review process?
Solid snippet. We've been seeing similar TTPs on the Android side with 'Clipper' malware, but the redirection to a fake App Store page is a new level of slick. From a SOC perspective, standard EDR on mobile is still spotty. We're relying on network telemetry. If you see a device hitting a known sinkhole or a domain matching the regex .*app-store-download.* but the IP isn't Apple's ASN, block it immediately.
The social engineering aspect is terrifying. The users think they are safe because 'it's on the App Store.' The script helps with static analysis, but what about runtime? I've been recommending we use Mobile Device Management (MDM) profiles to restrict SFSafariViewController to specific whitelisted domains for high-risk apps (finance/crypto), though enforcing that across a BYOD environment is a nightmare.
Apple's review process needs a serious overhaul. Just blocking via network traffic is a game of whack-a-mole since they likely rotate domains faster than we can block them. I'd advise checking the developer certificates. If an app is signed by a cert that was used to sign 20 different 'wallet' apps in the last week, that's a massive red flag. We should automate that lookup.
The redirection tactic is insidious, but we can often catch the destination URLs statically by scanning the IPA. I recommend grepping the binary and Info.plist files for custom URL schemes or non-Apple domains.
import sys, re, zipfile
with zipfile.ZipFile(sys.argv[1]) as z:
for name in z.namelist():
if '.plist' in name:
data = z.read(name).decode('utf-8', errors='ignore')
for url in re.findall(r'https?://[^\s<>\"]+', data):
print(f"Found URL in {name}: {url}")
This helps identify the specific phishing domains used in the in-app browser redirection quickly.
Spot on about the redirections being the key. Since the fake store UI is often hosted on rapid DNS flux infrastructure, we've been tracking the TLS JA3 fingerprints associated with these landing pages. If you use Zeek or similar, you can hunt for anomalies where an iOS app triggers a TLS handshake to a non-Apple domain using a browser-like JA3. Example Zeek script logic:
zeek event ssl_established(c: connection) { if (c$id$orig_h in ios_subnets && c$ssl$ja3 == /browser_fingerprint/ && !c$ssl$server_name =~ /.apple.com/) { print fmt("Suspicious redirect: %s", c$ssl$server_name); } }
Telemetry over blocking for this one.
Building on the static analysis, once you identify the malicious Team ID, immediate containment is possible via MDM. We push a configuration profile to restrict the launch of apps signed by that specific developer identifier. It acts as a fleet-wide kill switch while waiting for Apple's revocation.
restrictedApps
identifierType
teamID
identifier
INSERTTEAMID
This stops the bleeding faster than relying solely on endpoint detection.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access