Top pick: build your list from abuse.ch MalwareBazaar sample records combined with passive DNS and your own sandbox captures. A static paste of "Joker IOC URLs" copied from a forum decays within weeks, because the Joker family (also tracked as Bread) rotates delivery hosts and gate endpoints as a matter of routine. The criteria applied here: every indicator must trace back to a sample hash, the list must be refreshed on a defined schedule, each entry needs a confidence label, the export must fit STIX or CSV ingestion, and the license must permit commercial blocking. Everything below is judged against those five points.
What a Joker IOC URL list actually contains
Joker is an Android trojan first documented for premium SMS fraud and later for SMS and contact exfiltration. Its infrastructure footprint is small compared with desktop ransomware, so the URL list is usually short and heavily weighted toward three roles: dropper download paths, command-and-control gate endpoints that receive device and subscription data, and redirector hosts used during the Play Store review evasion phase.
A usable list pairs URLs with non-URL indicators that survive infrastructure churn:
- Package names and certificate SHA-256 fingerprints for the repackaged apps
- Sample SHA-256 hashes so analysts can pull the binary and re-derive network IOCs
- DGA or fast-flux patterns where the host changes but the path structure does not
- First-seen and last-seen dates on every domain
If a feed gives you only bare domains with no hash attribution, you cannot tell whether the host is still malicious or has been re-registered by an unrelated party. That matters more for Joker than for most families, because a large share of its historical hosts are cheap shared infrastructure that gets recycled.
Option 1: abuse.ch MalwareBazaar and ThreatFox (top pick)
abuse.ch runs community platforms that publish malware samples and indicators, and Android banking and SMS-fraud families appear in those datasets alongside desktop malware. The strength is hash-level traceability: you start from a sample record and pivot outward.
- Pros: sample hashes anchor every indicator, community submissions are timestamped, exports are machine-readable, and the platforms are widely used so your SIEM team will recognize the format.
- Cons: coverage of Android-specific C2 is thinner than for Windows malware, and volunteer submissions vary in quality, so you must dedupe and re-verify.
Use it when: you need a defensible starting corpus that a SOC analyst can audit. Pull the sample set, then run the binaries through your own analysis to extract the live URLs rather than trusting any single upstream label.
Option 2: Commercial mobile threat intel feeds
Vendors that specialize in mobile fraud publish periodic research on Joker campaigns, and several sell structured feeds with confidence scores attached. Kaspersky, Trend Micro, and the mobile-fraud specialists that serve banks are the usual sources.
- Pros: analysts have already done the dynamic analysis, indicators arrive with context and campaign naming, and you get support when a detection fires.
- Cons: cost, contract terms that may restrict redistribution inside your own product, and a publication lag that lets a short-lived campaign finish before the feed updates.
Use it when: you run a fraud or mobile-risk team and need campaign context, not just a blocklist. Read the redistribution clause before you push feed indicators into a customer-facing product.
Option 3: MITRE ATT&CK Mobile and government advisories
MITRE ATT&CK maintains a mobile matrix that documents adversary techniques on Android and iOS, and national cyber agencies publish advisories that occasionally include mobile malware indicators. These are context sources, not URL feeds.
- Pros: authoritative technique mapping, stable identifiers you can use in detection engineering, no licensing friction.
- Cons: almost never contains the live URL you need, updates on a slow cadence, and advisories are written for a general audience.
Use it when: you are writing detection logic and need to describe behavior (dynamic code loading, SMS interception, notification suppression) that outlives any single domain.
Option 4: Build your own from dynamic analysis
This is the only method that produces a list current enough to matter for a live Joker sample. The workflow: acquire the APK, run it in an instrumented emulator, intercept traffic through a proxy, and record every host the app contacts during install, first launch, and a simulated SMS event.
- Static pass with a mobile analysis framework to pull strings, embedded endpoints, and certificate details.
- Dynamic pass with TLS interception and hooking to catch endpoints resolved at runtime after code is decrypted.
- Passive DNS enrichment to find sibling hosts on the same registrant or name server cluster.
- Re-check each host after 7 and 30 days and drop anything that has gone dark or changed hands.
- Pros: freshest possible data, full confidence in provenance, tailored to the campaigns actually hitting your users.
- Cons: needs reverse-engineering skill and lab capacity, and each sample costs analyst hours.
Use it when: you have a malware analysis function or a retainer with one. For everyone else, option 1 plus option 2 covers the gap.
How to judge a list before you deploy it
- Attribution: can each URL be tied to a hash or a campaign report? Untraceable entries are noise.
- Age: anything first seen more than 90 days ago in a fast-rotating family should be re-verified, not blocked blindly.
- Confidence: a single field separating confirmed C2 from "possibly related" saves you from false positives.
- Hosting context: never block an entire CDN or cloud region because one Joker gate sat there. Block the path or the full host, not the provider.
- Legal terms: confirm the feed license allows the use you have in mind, including internal redistribution to clients.
Operational notes and common mistakes
Blocking at the DNS layer catches most Joker C2 because the app resolves a hostname before posting data, but it does nothing for apps that hardcode IPs. Pair DNS blocking with on-device detection: flag sideloaded packages requesting SMS permissions, flag apps that register broadcast receivers for incoming messages, and watch for notification-listener access that coincides with a premium SMS charge.
Two failure modes show up again and again. First, treating a historical URL list as permanent: hosts get cleaned, parked, or resold, and stale blocks generate helpdesk tickets. Second, ignoring the non-URL indicators: package name and certificate fingerprint detections in a mobile threat defense product catch repackaged variants before they ever resolve a domain.
Recommendation by use case
- SOC with SIEM ingestion: abuse.ch sample hashes plus a monthly re-verification job, exported as STIX.
- Bank or fintech fraud team: a commercial mobile feed for campaign context, backed by your own sandbox work on samples pulled from customer reports.
- Detection engineering: MITRE ATT&CK Mobile for technique coverage, with URLs treated as volatile and behavior rules as the durable layer.
- Solo researcher: dynamic analysis of a handful of current samples, published with hashes attached so others can reproduce your work.