Skip to content

Add Quark malware analysis report for BrainTest - #977

Merged
haeter525 merged 2 commits into
ev-flow:masterfrom
pulorsok:docs/braintest-report
Oct 3, 2026
Merged

haeter525 merged 2 commits into
ev-flow:masterfrom
pulorsok:docs/braintest-report

Conversation

@pulorsok

Copy link
Copy Markdown
Member

BrainTest Malware Family Analysis Report

This report analyses the BrainTest malware family using Quark's rule classification. BrainTest is Android malware Check Point found in 2015 inside a Google Play game of the same name. It runs root exploits, installs a component into the system partition so that a factory reset does not remove it, and pulls further code from its server on demand. The four samples analysed here are one chain: the game itself, the helper package it drops, and the payload that helper installs. This run added a new rule (#280) for running a shell command and capturing its error output; the rule fires inside BrainTest's own root-shell helper, but under a technique this report does not claim — see the coverage-gap note on T1404. Check here for the rule details.

Quark's rule classification flagged 4 of 4 BrainTest samples as high-risk in this experiment (detection rate 100%). Benign-cohort false-positive rate was not measured here. See tested APKs below.

Identified Well-Known Threats

This section uses MITRE ATT&CK Mobile as its reference taxonomy, anchored to the S0293 BrainTest software entry. Of the 5 techniques documented for the family, Quark's static bytecode analysis confirms the 1 listed below; see the coverage-gap notes at the end of this section for the other 4.

MITRE Technique Real-world manifestation
T1407 Download New Code at Runtime Fetching executable modules from the server after installation and running them

All behavior maps below were rendered from sample 135d6acff3ca27e6e7997429e5f8051f88215d12351e4103f8344cd66611e0f3.apk (package com.android.system.certificate, the payload at the end of the chain) — chosen as the representative sample whose detected behaviors most fully cover the documented profile of BrainTest. The other 3 family samples were used to compute the detection-rate figure above.

Each section below corresponds to one technique from the table above. Within each section we first quote the MITRE definition, then show the Quark behavior map extracted from the representative sample's bytecode, then walk through the call sequence and list the underlying rules.

1. T1407 Download New Code at Runtime

T1407 Download New Code at Runtime — attack.mitre.org

MITRE definition (T1407): Adversaries may download and execute dynamic code not included in the original application package after installation. This technique is primarily used to evade static analysis checks and pre-publication scans in official app stores. On Android, dynamic code could include native code, Dalvik code, or JavaScript code that utilizes Android WebView's JavascriptInterface capability.

T1407 Download New Code at Runtime

Lcom/android/system/certificate/ConfigService$1;run calls ConfigService;f, which opens a URL and reads the server's response. The response names the file to fetch and the method to call; run then writes that file into the app's private directory, loads it, and invokes the named method through reflection.

Behaviors detected by Quark:

Coverage-gap notes

The 4 MITRE techniques documented for BrainTest that this report does NOT demonstrate, grouped by the reason Quark could not confirm them on these samples:

The evidence sits in a string argument, which Quark does not read (3) — T1404 Exploitation for Privilege Escalation, T1645 Compromise Client Software Binary and T1643 Generate Traffic from Victim. Quark's rules match API calls, not the values passed to them, and for all three techniques the API call is generic while the argument carries the meaning:

  • BrainTest's own code contains a root-shell helper (Lcom/android/system/certificate/h;g and its twin Lcom/android/music/helper/i;C): it calls Runtime.exec, writes command lines to the process's input stream, and reads back both output streams. Quark confirms that helper at full data-flow depth — it is where this run's new rule Version 21.11.1 #280 fires — but whether the command is an exploit (T1404) or the system-partition copy MITRE records for T1645 is decided by the text handed to it. The commands themselves are in the samples: Lcom/android/music/helper/f$1;run assembles mount -o remount,rw /system, mkdir /system/bin/.daemon, and a cat that writes a binary into that directory.
  • For T1643, MITRE records BrainTest using infected devices to post reviews and to pull other apps from the Play Store. The samples carry Lcom/nn/googlePlayInstall;startInstall and Lcom/nn/AutoGuideGPInstall;startInstall — each drawing a mask view over the screen while it runs — plus FileUtil;installPackage and main;doRate. Quark flags these as "implicit intent" and "install other APKs from file". What makes them store manipulation is the intent's destination, which is not part of the API pair, so the cluster reads as ordinary intent launching and was not claimed.

No rule in the pool covers the primitive (1) — T1406 Obfuscated Files or Information. MITRE records that BrainTest keeps a second Android package in its assets in encrypted form and decrypts it at runtime. One sample does carry such a package (assets/brother), though in that sample it is stored as a plain ZIP, and Lcom/android/music/helper/e holds AES-CBC and DES routines used elsewhere in the code. But of the 280 rules in the pool, only one touches cryptography at all (#24, Base64 decoding followed by a file write) and none pairs a Cipher call with anything, so the decryption step cannot fire. The rules that do fire show an asset being read, which is what every app does with its bundled resources. Separately, the game sample 96f95e43… is wrapped in the Baidu packer (libbaiduprotect.so), so Quark cannot see the code it hides — which is why that sample contributes no behaviour evidence here, though the rule pool still scores it high-risk.

List of Tested APKs

The table below lists the APKs we tested.

index sha256
1 135D6ACFF3CA27E6E7997429E5F8051F88215D12351E4103F8344CD66611E0F3
2 422FEC2E201600BB2EA3140951563F8C6FBD4F8279A04A164ACA5E8E753C40E8
3 96F95E432B6325F00042E67C4CEAD6061563D833E35C531B372581AC0F51EAC2
4 AD61E0ABE570C3575B01FBD07FC92E88C2516D1B74BB2ED536C6E2CC8E70435E

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@codecov

codecov Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.28%. Comparing base (845a35f) to head (58959ad).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #977   +/-   ##
=======================================
  Coverage   81.28%   81.28%           
=======================================
  Files          84       84           
  Lines        7923     7923           
=======================================
  Hits         6440     6440           
  Misses       1483     1483           
Flag Coverage Δ
unittests 81.28% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@haeter525
haeter525 merged commit f6147d7 into ev-flow:master Oct 3, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants