Mobile T1616 Call Control Guide

Android malware that can make, answer, forward or block phone calls lets attackers listen in, cut victims off from their bank, and steer fraud calls without the user seeing anything. MITRE ATT&CK for Mobile tracks this as T1616 Call Control, spanning the Collection, Impact and Command and Control tactics. This guide covers the Android permissions behind the technique, what real malware families have done with it, how to detect it through permission review, app vetting and forensics, and how to cut it off with MDM policy and Google Play's call log restrictions. It is for mobile security engineers, SOC analysts and fraud teams in banks and contact centres. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

Android only in ATT&CK. ATT&CK v20 lists T1616 for Android; no iOS procedure is recorded.
Permissions are the tell. CALL_PHONE, ANSWER_PHONE_CALLS, PROCESS_OUTGOING_CALLS and WRITE_CALL_LOG in an app that is not a dialer deserve scrutiny.
Banking fraud is the main use. Fakecalls intercepts calls to banks and plays a fake call screen; Crocodilus can enable call forwarding; Drinik silently blocks incoming calls.
The default dialer role is the prize. ATT&CK's only listed mitigation is user guidance: do not grant call permissions freely and do not change the default call handler to an unknown app.
Call-back verification breaks if the phone is owned. Banks that call the customer, or ask the customer to call them, must assume the call may be intercepted on an infected device.

What T1616 is

ATT&CK describes Call Control as adversaries making, forwarding or blocking phone calls without user authorisation, for audio surveillance, blocking or forwarding the owner's calls, or command and control. The technique page lists the Android permissions that allow programmatic call control. Descriptions below are from the Android Manifest.permission reference.

Permission	What it allows	Abuse noted by ATT&CK
`ANSWER_PHONE_CALLS`	Allows the app to answer an incoming phone call	Silent answering for audio surveillance (CarbonSteal)
`CALL_PHONE`	Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call	Requested by GodFather, DocSwap and VajraSpy; Anubis, Escobar and AndroRAT can place calls
`PROCESS_OUTGOING_CALLS`	Lets an app see the number being dialled, with the option to redirect or abort the call (per ATT&CK)	Redirecting a call to the bank to an attacker number
`MANAGE_OWN_CALLS`	Allows a calling application which manages its own calls through the self-managed `ConnectionService` APIs	Building a calling app that sits alongside the system dialer
`BIND_TELECOM_CONNECTION_SERVICE`	Must be required by a `ConnectionService`, to ensure that only the system can bind to it	Needed when malware implements a `ConnectionService`
`WRITE_CALL_LOG`	Write access to the device call log	Hiding malicious calls by editing the log

ATT&CK also notes that an app can open the dialer with a number pre-filled using Intent.ACTION_DIAL, which needs no permission but requires the user, or input injection (T1516), to start the call.

Platform scope

ATT&CK v20 lists Android as the only platform. iOS apps are sandboxed and Apple states that cross-app access happens only through services iOS explicitly provides; ATT&CK records no iOS call control procedure. Monokle shows the reverse use of calls: ATT&CK records it being controlled by phone calls from a set of "control phones", so call control is also a C2 channel, not only a collection technique.

Real cases from ATT&CK procedure examples

Software	Behaviour recorded by ATT&CK	Goal
BRATA (S1094)	Hides incoming calls by setting ring volume to 0 and showing a blank screen overlay	Stop the bank reaching the victim during fraud
Crocodilus (S9004)	Can enable call forwarding	Divert calls, including verification calls
Drinik (S1054)	Uses the Android `CallScreeningService` to silently block incoming calls	Block bank call-backs (Drinik targeted customers of about 27 Indian banks in 2021)
Fakecalls (S1080)	Intercepts and imitates phone conversations by breaking the connection and showing a fake call screen; can make outgoing and spoof incoming calls	Victim believes they are speaking to their bank (masquerades as South Korean banking apps)
CarbonSteal (S0529)	Silently accepts an incoming phone call	Audio surveillance
Monokle (S0407)	Controlled via calls from "control phones"	Command and control
TangleBot (S1069)	Makes and blocks phone calls	Fraud and disruption

The banking cases show why this technique matters to fraud teams: it defeats the out-of-band phone call that many banks rely on to confirm a risky transaction. See the Android Banking Trojans Guide and, for social engineering by phone more generally, the Callback Phishing (TOAD) Guide.

Prevention

Google Play policy as a control

Google Play treats the Call Log permission group (READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS) as restricted. An app must be actively registered as the default SMS, Phone or Assistant handler before prompting for these permissions and must stop using them when it is no longer the default. Developers must file a Permissions Declaration Form, and listed exceptions include caller ID and spam detection, proxy calls and call-based authentication in banking apps. Google's policy page also states that account verification via phone call will no longer be a permitted use of READ_CALL_LOG from 27 January 2027. The practical effect: Play-distributed apps rarely hold these permissions without being the dialer, so sideloaded apps are where call control malware lives.

MDM and user controls

Control	How	Effect
Block installs from unknown sources	MDM restriction on managed devices	Removes the main delivery route for apps that request call permissions outside Play policy
Deny or audit dangerous call permissions	Android Enterprise permission policy and `getPermissionGrantState()` checks	Prevents silent grants of `CALL_PHONE` or `ANSWER_PHONE_CALLS` to non-approved apps
Fix the default dialer	Approved dialer app on managed devices; user guidance on BYOD	ATT&CK M1011 User Guidance: do not change the default call handler to unrecognised apps
Restrict accessibility	Allowlist accessibility services	Stops input injection being used to start calls through the dialer
Keep Play Protect on	Compliance rule	Scans installed apps for known malware

Detection

ATT&CK's detection strategy DET0703 correlates three evidence types:

Application permission: managed device or vetting review finds call permissions granted to a package that is not the approved dialer, VoIP client or caller ID app.
OS API execution: dynamic analysis sees the app call TelecomManager methods such as placeCall(), answerCall() or endCall(), or ConnectionService operations, with no matching user interaction in the call UI.
File modification: forensic or dynamic analysis shows the app inserting, updating or deleting records in the CallLog.Calls content provider right after a call control action, a sign of log tampering.

Forensic checks on a suspect device

Compare the device call log with carrier records for the period of suspected fraud; missing or altered entries suggest WRITE_CALL_LOG abuse.
Check which app holds the default phone and call screening roles.
Check carrier-side call forwarding settings, since forwarding enabled through the device persists until removed.
Run an acquisition with the Mobile Verification Toolkit (MVT) or a commercial tool and preserve the app package for analysis. See the Mobile Forensics Guide.

How to implement

Inventory call-capable apps. Pull permission grant state for the six call permissions across managed Android devices and build an approved list (dialer, softphone, contact centre client).
Audit before enforcing. Report non-approved grants for two weeks to find legitimate business apps you missed.
Enforce. Deny those permissions to non-approved apps through managed permission policy and block unknown sources.
Feed MTD and vetting. Add call permissions plus accessibility or overlay rights as a high-risk combination in app vetting.
Update fraud processes. Tell the fraud team that a verification call can be intercepted; add an in-app or branch confirmation path for high-value changes.
Roll back safely. If an approved app breaks, re-grant the specific permission to that package rather than relaxing the whole policy.

Decision guidance

Fully managed phones: enforce permission policy and a fixed dialer. Little business reason exists for other apps to place calls.
BYOD: you cannot control personal apps. Use MTD risk scoring and user guidance, and protect sensitive processes on the service side.
Banks and contact centres: treat a phone call as one signal, not proof of identity, when the customer's device may be compromised. See Caller Authentication in Contact Centres.

Metrics that show it is working

Non-approved apps holding any call permission on managed devices (target: zero).
Managed devices with unknown sources allowed (target: zero).
Fraud cases where a bank call-back was blocked, forwarded or spoofed, tracked over time.
Time from a call permission alert to device quarantine.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK for Mobile	T1616 Call Control; DET0703; M1011 User Guidance	Technique, detection strategy and listed mitigation
NIST CSF 2.0	PR.PS-05, DE.CM-09	Preventing unauthorised software; monitoring runtime environments
NIST SP 800-53 Rev 5	AC-19, CM-11, AC-6	Mobile device access control, user-installed software, least privilege
ISO/IEC 27001:2022 Annex A	A.8.1, A.8.7	User endpoint devices, protection against malware
OWASP MASVS	MASVS-PLATFORM	Apps requesting only the platform permissions they need

Common failure patterns

Trusting the call-back: fraud teams treat a successful call to the registered number as proof, when malware can block, forward or fake the call.
Ignoring the default handler: no one checks which app holds the phone role, so a malicious dialer goes unnoticed.
Call log treated as evidence: investigators rely on the on-device call log, which malware with WRITE_CALL_LOG can edit; carrier records are the reference.
Sideloading allowed for convenience: Play's call log restrictions do nothing for apps installed from outside the store.

Practitioner checklist

List approved call-capable apps for managed Android devices.
Audit and then deny call permissions to everything else.
Block unknown sources and keep Play Protect on.
Check default phone and call screening role holders in compliance checks.
Flag call permissions combined with accessibility or overlay access in app vetting.
Use carrier records, not the device log, when investigating call fraud.
Give fraud teams a non-phone confirmation path for high-value changes.

Mobile T1616 Call Control: Detecting Malicious Call Handling on Android