{ "id": "4b82c04c-9e24-42b5-b8e8-81ae4257a464", "created_at": "2026-04-06T00:22:21.906469Z", "updated_at": "2026-04-10T03:20:02.1515Z", "deleted_at": null, "sha1_hash": "cc3f83bfc880929554558a34d8729bba35a6fb4c", "title": "Anatsa Campaign Technical Analysis | ThreatLabz", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2245946, "plain_text": "Anatsa Campaign Technical Analysis | ThreatLabz\r\nBy Himanshu Sharma, Gajanan Khond\r\nPublished: 2024-05-27 · Archived: 2026-04-02 11:50:37 UTC\r\nAs mentioned previously, Anatsa utilizes remote payloads retrieved from C2 servers to carry out further malicious\r\nactivity.\r\nIn the figure below, the dropper application is shown with encoded links to remote servers, from which the next\r\nstage payload will be downloaded. In addition to downloading the payload, the malware also retrieves a\r\nconfiguration file from the remote server to execute the next stage payload.\r\n \r\nFigure 3: Anatsa dropper’s payload and configuration URLs.\r\nIn the figure below, the DEX file is downloaded and will be loaded by the parent fake QR code application.\r\nFigure 4: Anatsa dropper’s network request to download the DEX file for the next stage payload.\r\nThe application utilizes reflection to invoke code from a loaded DEX file. The necessary configuration to load the\r\nDEX file is downloaded from the control server, as depicted in the network response shown below.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google\r\nPage 1 of 5\n\nFigure 5: Anatsa dropper’s configuration to run the downloaded DEX file.\r\nAfter the next stage payload is downloaded, Anatsa performs a series of checks for the device environment and\r\ndevice type. This is likely designed to detect analysis environments and malware sandboxes. Upon successful\r\nverification, it proceeds to download the third stage and final payload from the remote server, as depicted in the\r\nfigure below.\r\nFigure 6: Code that checks the device environment and downloads final stage Anatsa payload.\r\nIn this particular campaign, the Anatsa malware injected uncompressed raw manifest data into the APK. The threat\r\nactors also intentionally corrupted the compression parameters in the manifest file to hinder analysis. The figure\r\nbelow depicts the corrupted ZIP headers.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google\r\nPage 2 of 5\n\nFigure 7: Anti-analysis technique utilized by Anatsa with malformed ZIP parameters.\r\nIn order to statically analyze the payload, the headers of the ZIP file must be fixed alongside the compressed data.\r\nAfter the APK is loaded, the malware requests various permissions, including the SMS and accessibility options,\r\nwhich are commonly associated with mobile banking trojans. The malware conceals the final DEX payload within\r\nthe asset files. During runtime, the payload decrypts the DEX file using a static key embedded within the code.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google\r\nPage 3 of 5\n\nFigure 8: Anatsa malware with the correct manifest.\r\nUpon execution, the malware decodes all encoded strings, including the C2 communication. The malware\r\nestablishes communication with the C2 server to carry out various activities, such as registering the infected\r\ndevice and retrieving a list of targeted applications for code injections.\r\nIn order to steal data from financial applications, Anatsa downloads a target list. The figure below shows the\r\nAnatsa configuration request and response. \r\nFigure 9: Anatsa configuration request and response being intercepted.\r\nThe figure below shows the request and response data being decoded with an XOR key.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google\r\nPage 4 of 5\n\nFigure 10: Example decrypted Anatsa request and response data using an XOR key.\r\nUpon receiving a list of financial application package names, the malware scans the victim's device to check if any\r\nof these targeted applications are installed. Once the malware identifies the presence of a targeted application,\r\nAnatsa communicates this information to the C2 server. In response, the C2 server provides a fake login page for\r\nthe banking application. This activity is illustrated in the figure below.\r\nFigure 11: Anatsa injection configuration request based on the presence of a specific financial application.\r\nThe fake login page is loaded within a JavaScript Interface (JSI) enabled webview, which is designed to deceive\r\nthe user into providing their banking credentials. Once the victim enters their credentials that data is sent back to\r\nthe C2 server.\r\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://www.zscaler.com/blogs/security-research/technical-analysis-anatsa-campaigns-android-banking-malware-active-google" ], "report_names": [ "technical-analysis-anatsa-campaigns-android-banking-malware-active-google" ], "threat_actors": [], "ts_created_at": 1775434941, "ts_updated_at": 1775791202, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/cc3f83bfc880929554558a34d8729bba35a6fb4c.pdf", "text": "https://archive.orkl.eu/cc3f83bfc880929554558a34d8729bba35a6fb4c.txt", "img": "https://archive.orkl.eu/cc3f83bfc880929554558a34d8729bba35a6fb4c.jpg" } }