{
	"id": "3ebe882c-6379-40d2-9d3b-5d37259942c3",
	"created_at": "2026-04-06T00:09:24.378259Z",
	"updated_at": "2026-04-10T03:24:15.713844Z",
	"deleted_at": null,
	"sha1_hash": "72e5fa27a19c9c2083bf8d530d81524ba2bac44d",
	"title": "First seen in the wild – Malware uses Corporate MDM as attack vector",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 89284,
	"plain_text": "First seen in the wild – Malware uses Corporate MDM as attack vector\r\nBy etal\r\nPublished: 2020-04-29 · Archived: 2026-04-05 21:22:34 UTC\r\nResearch by: Aviran Hazum, Bogdan Melnykov, Chana Efrati, Danil Golubenko, Israel Wernik, Liav Kuperman, Ohad Mana\r\nOverview:\r\nCheck Point researchers discovered a new Cerberus variant which is targeting a multinational conglomerate, and is\r\ndistributed by the company’s Mobile Device Manager (MDM) server. This malware has already infected over 75% of the\r\ncompany’s devices. Once installed, this Cerberus variant can collect large amounts of sensitive data, including user\r\ncredentials, and send it to a remote command and control (C\u0026C) server.\r\nGeneral:\r\nThis is the first time we have a reported incident of lateral movement inside a corporate network that utilizes the MDM\r\nserver as a means of spreading.\r\nMalicious actors keep upgrading their tactics and techniques, becoming more and more complex. Cisco’s TALOS has\r\nreported in the past a campaign using actor-owned MDM to control victim’s devices, and this campaign takes it to the next\r\nlevel – compromising a corporate-owned MDM and spreading malware to more than 75% of the corporate’s devices via the\r\ncompromised MDM.\r\nThis incident underscores the importance of distinguishing between managing and securing mobile devices. Managing a\r\nmobile device means installing applications, configuring settings, and applying policies on multiple devices at once.\r\nSecuring a mobile device means protecting it from malware threats and attacks.\r\nMDM’s most prominent feature, arguably the reason for its existence, is also its Achilles’ heel – a single, central control for\r\nthe entire mobile network. If that platform is breached, so is the entire mobile network.\r\nIn this case, we can divide the company’s devices into two categories – those with SandBlast Mobile, and those without. The\r\nprotected device owners did not have access to corporate resources, while the owners of non-protected did – along with an\r\ninstalled malware that allowed the threat actor to control the device remotely.\r\nEncountering the Malware:\r\nOn February 18, 2020, we detected two malicious applications installed on a large number of the customer’s devices. As all\r\nthe malicious applications were installed in a very short window of time, we assume that there is some automation involved.\r\nTwo possibilities came to mind immediately – the first is a malware with lateral movement capabilities, and the second is\r\nthat the customer’s MDM was breached. Later, the customer confirmed that their MDM was indeed breached.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 1 of 11\n\nFigure 1: Two spikes showing a large number of new malicious applications were installed.\r\nThis suggests a targeted attack against the company. After gaining access to the customer’s MDM, the attacker utilized the\r\nMDM’s ability to install applications remotely to install malware on more than 75% of the company’s devices.\r\nWe started collecting data on the attack itself. We checked the C\u0026C and it is HTTP only. It listens on port 8888, and there is\r\nno hostname, just a Russian IP address. The On-device Network Protection’s verdict on the C\u0026C is ‘Malicious / Infecting\r\nWebsite.’ Under the right policy, with On-device Network Protection, all communications with the C\u0026C could have been\r\nblocked.\r\nAfter some initial research, we concluded that this malware is a new variant of the Cerberus Banking Trojan for Android, a\r\nknown Malware-as-a-Service (Maas) that allows anyone to rent its services to build your own payload, and configure,\r\ncommand and control its devices. But this new variant is equipped with more than the average banker – it has Mobile\r\nRemote Access Trojan (MRAT) capabilities.\r\nThese capabilities include logging all keystrokes on the device (credentials included), stealing Google Authenticator data\r\nand any SMS received (2FA included), and commanding the device remotely via TeamViewer.\r\nWe took a closer look at those two samples, and it became very clear that their abilities were almost identical. From this\r\nstage onward, we refer to those samples as ‘the main module’ of the malware. We explore the technical aspect of the\r\nmalware in the ‘Technical Analysis’ section.\r\nTechnical Analysis:\r\nMalware Capabilities:\r\nThough this malware belongs to the Cerberus Banker family, as we said previously, this campaign has MRAT capabilities\r\nand can steal users’ information such as call logs, SMS, credentials, and installed applications. This malware consists of two\r\nparts – the main application, and a DEX file that is received as a payload from the remote C\u0026C server.\r\nThe malware starts by showing a window that masquerades as an update for the Accessibility service. If dismissed, the\r\nwindow keeps popping up until the user accepts the update. The malware then uses the permissions to utilize the\r\naccessibility service at a later stage and automatically clicks on menu options and bypasses user interaction.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 2 of 11\n\nFigure 2: Popup window asking the user to update Accessibility Service.\r\nThe malicious application registers a receiver on various events, and when triggered, starts the execution of the malicious\r\nflow.\r\nFirst, the malware starts a service that sends the C\u0026C its bot-id, lock-screen protection status, top application package name,\r\nand the storage write access. Next, the application receives a list of commands to perform – which are configurable by the\r\nactor. Then, the application registers a receiver for SMS, and uses the ability to collect incoming SMS messages and send\r\nthem to the C\u0026C server at a later stage. More information is sent including the phone number, default SMS app, and locale.\r\nOnce the appropriate command is received, the malware downloads an encoded DEX file, and saves it on the device’s\r\nexternal storage as ‘ring0.apk’. From this point on, we refer to this as ‘the payload module.’\r\nFigure 3: Registering receiver to collect SMS.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 3 of 11\n\nFigure 4: Download ring0.apk payload.\r\nAfter downloading the payload module, the malware creates a JSON object containing various parameters to be used to\r\ncommunicate with the payload module. It then calls an entry point from the DEX payload using reflection.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 4 of 11\n\nFigure 5: JSON commands used for communication between the main and payload modules.\r\nThe major functionalities of the malware’s main module are related to data and file exfiltration as well as taking control of\r\nthe device.\r\nMalware main module:\r\nThe main module can use the accessibility service to steal Google authenticator credentials, Gmail passwords and phone\r\nunlocking patterns. This module can send the C\u0026C a list of files and installed applications and can even upload a specific\r\nfile upon request from the C\u0026C server. In addition, all the user’s keystrokes are logged and sent to the server, showing the\r\nactor all activities being performed on the device. The malware waits for the Google Authenticator application to be\r\naccessed, at which point all available information is read and stored to be sent to the C\u0026C.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 5 of 11\n\nFigure 6: Uploading a file to the C\u0026C server.\r\nThe main module can also run the TeamViewer remote access application, giving the actor complete remote control of the\r\ndevice. To achieve this, the malware receives connection parameters from the C\u0026C and enters them in the appropriate fields\r\nusing the Accessibility Service. After the evasion parameters are configured, the TeamViewer application can be run with the\r\nmalware keeping the device unlocked. When running TeamViewer on Samsung devices, the malware utilizes Samsung\r\nKNOX to automatically grant permission.\r\nFigure 7: Permission to run TeamViewer in Samsung KNOX.\r\nTo maintain control of the device, the malware can block attempts to uninstall TeamViewer and prevent the user from using\r\nthis application so as not to interfere with the attacker’s actions on the device.\r\nFigure 8: TeamViewer related commands.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 6 of 11\n\nThe module can also stop the RAT service responsible for receiving commands from the server. This service can later be\r\nrestarted by the ring0.apk payload module.\r\nThe malware maintains persistence using a few techniques. The malware gives itself administrative privileges, complicating\r\nthe application uninstallation. The malware also blocks attempts to remove the application by automatically closing the App\r\nDetail page every time the user tries to access it. In addition, Google Play Protect is disabled, using the Accessibility\r\nService, to prevent detection and removal of the malware.\r\nFigure 9: Preventing the malware removal.\r\nFigure 10: Disabling Google Play Protect.\r\nTo keep MIUI (MI user interface) optimizations from interfering with its execution, the malicious application enables Auto\r\nStart in the permission center and configures the power keeper so it does not suspend or terminate the application.\r\nFigure 11: Configuring MIUI powerkeeper.\r\nPayload Module:\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 7 of 11\n\nThe downloaded ring0.apk module has various functionalities for stealing data and credentials, performing assorted actions\r\non the device, and functionalities for maintaining the malware itself.\r\nThe ring0.apk module can collect all contacts, SMS and installed applications and send it to the C\u0026C. This module also can\r\nperform phone-related actions such as sending specific SMS messages, making calls and sending USSD requests. In\r\naddition, this module can show notifications, install or uninstall applications and open popup activities with URLs\r\nFigure 12: HTML popup to steal user’s Gmail credentials.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 8 of 11\n\nFigure 13: Stealing Google Authenticator credentials with Accessibility Service.\r\nThe ring0.apk module is also responsible for several self-maintaining changes needed for the malware to function properly.\r\nThese include granting itself permissions and enabling the service responsible for receiving commands from the C\u0026C. This\r\nmodule can also erase the payload file so an updated payload file can be received at a later stage, remove itself from the\r\ndevice’s administrators list, and completely remove the malware from the device.\r\nFigure 14: Deleting the ring0.apk payload file.\r\nThe following are the commands the main malware application can receive from the C\u0026C:\r\nUpload a specific file to the C\u0026C.\r\nopen_folder Send list of files in an external storage to the C\u0026C.\r\nget_apps Send list of installed applications to the C\u0026C.\r\nrat_disconnect Stop the RAT service.\r\ndevice_unlock Keep the screen unlocked.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 9 of 11\n\nopen_teamviewer\r\nConfigure evasion parameters for the TeamViewer application.\r\nStart the TeamViewer application\r\nconnect_teamviewer\r\nStore credentials received from the C\u0026C.\r\nConfigure evasion parameters for the TeamViewer application.\r\nConnect the TeamViewer application to the attacker’s infrastructure.\r\nsend_settings Configure evasion parameters for the TeamViewer app.\r\nThe following are the commands the payload module can receive from the C\u0026C:\r\npatch_update Delete the payload file.\r\nrat_connect Enable the RAT service.\r\nremove_bot Remove itself from device.\r\nrun_admin_device Remove the malware’s admin from the administrators list.\r\nrequest_permission Allow the malware to grant itself permissions.\r\ngrabbing_google_authenticator2 Intercept Google authenticator credentials via the Accessibility Service.\r\ngrabbing_pass_gmail Intercept Gmail passwords by showing a fake window.\r\ngrabbing_lockpattern Intercept the screen unlock pattern by showing a fake window.\r\nget_data_logs Collect installed applications, contacts and SMS .\r\nsend_sms Sends SMS to a specified number.\r\nussd Send USSD request.\r\ncall_forward Call a specific number.\r\nnotification Show notifications.\r\nurl Open popup activity with a specific URL.\r\nrun_app Launch a specific application.\r\nremove_app Uninstall the application.\r\nCorporate Damage:\r\nAlthough ONP (On-device Network Protection) was not active, and we cannot be sure which specific pieces of data were\r\nleaked, we do know the malware’s capabilities.  We know that every credential used from an unprotected device was\r\nreported to the C\u0026C server. We also know that every SMS message was intercepted. This makes it possible for us to\r\nspeculate regarding the potential damage for the affected company.\r\nIf one unprotected device was used by an administrator who then tried to access corporate resources with his credentials,\r\nthose credentials, along with any 2FA SMS codes, are compromised.\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 10 of 11\n\nDue to the extent of this malware’s capabilities, the company decided to ‘factory-reset’ all devices, just to be sure that no\r\nresidue of the malware, or the actor, remained on the unprotected devices. However, this type of response is extremely\r\ncostly, both in conducting the damage assessment, and re-establishing the entire mobile network after the factory-reset.\r\nConclusion:\r\nThis campaign demonstrates the importance of understanding the difference between managing and securing mobile\r\ndevices. While MDM offers an easy way to manage those devices, security cannot be ignored. Mobile devices are an\r\nintegral part of the way we work, how we communicate, and how our businesses operate. They need to be protected as any\r\nother endpoint as they offer a tempting target.\r\nIn recent months, we have observed malicious actors running campaigns that are embracing techniques and methodologies\r\nfrom the general threat landscape, using lessons learned from operating on different platforms to enhance operations in the\r\n“young” threat landscape of the mobile world.\r\nAppendix #1 – IOC’s:\r\nC\u0026Cs\r\n91.210.169[.]114\r\nPackage Name\r\nApplication\r\nName\r\nsha256\r\ncom.wjnjrmigikmpher.efaunxm\r\nGoogle\r\nPlay 1.0\r\n4254670ea5f353263570792a8ff4a1e6ea35999c2454fa1ec040786d7be33b69\r\ncom.dfxsdgr.qvoor Google 1.0 6291192d0c2f6318f9a4f345203b35cfe140be53889f9fefdd8e057a4f02e898\r\ncom.sakkkwyl.ncceberwpdhfq GTA V 1.0 3ef8349d4b717d73d31366dfbe941470e749222331edd0b9484955a212080ad8\r\nSource: https://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nhttps://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://research.checkpoint.com/2020/mobile-as-attack-vector-using-mdm/"
	],
	"report_names": [
		"mobile-as-attack-vector-using-mdm"
	],
	"threat_actors": [
		{
			"id": "f276b8a6-73c9-494a-8ab2-13e2f1da4c53",
			"created_at": "2022-10-25T16:07:24.441133Z",
			"updated_at": "2026-04-10T02:00:04.993411Z",
			"deleted_at": null,
			"main_name": "Achilles",
			"aliases": [],
			"source_name": "ETDA:Achilles",
			"tools": [
				"RDP",
				"Remote Desktop Protocol"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434164,
	"ts_updated_at": 1775791455,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/72e5fa27a19c9c2083bf8d530d81524ba2bac44d.pdf",
		"text": "https://archive.orkl.eu/72e5fa27a19c9c2083bf8d530d81524ba2bac44d.txt",
		"img": "https://archive.orkl.eu/72e5fa27a19c9c2083bf8d530d81524ba2bac44d.jpg"
	}
}