Mobile Malware · Inside a Malicious App · Lesson 3 of 5

Watching an App Run

Run a sample in an isolated lab and read what it does on the network.

A sandbox and a network log

Static analysis shows what an app could do. Dynamic analysis shows what it actually does, by running it and watching. Because the sample may be malicious, it never runs on anyone's real phone. Professionals use a sandbox: an isolated environment, often an emulator (software that pretends to be a phone on a computer) or a dedicated test device with no personal accounts, kept on a separate network. When the run is over, the sandbox is wiped back to a clean state.

The richest thing to watch is usually network traffic, because most mobile malware is useless until it talks to its operators. Analysts record every connection: which names the app looks up, which servers it contacts, and what it sends. Most traffic is encrypted with HTTPS, so a lab device is typically set up to trust the analyst's own monitoring tool, letting them read what this one app sends. That's done only on lab equipment, never on a phone someone actually uses.

Patterns analysts look for include:

• Exfiltration, sending data off the phone, like device details or the list of installed apps.
• Downloads of extra code, the second stage you learned about in the last module.
• A beacon: a regular check-in, every minute or so, asking a command-and-control (C2) server whether there's anything to do.
• Lookups of strange, random-looking domain names. Some malware uses a domain generation algorithm (DGA), which produces a stream of new names so the operators only need to register one or two. Most lookups fail. The one that works leads to the C2 server.

Remember from Overlays & Banking Trojans that banking trojans keep a target list of apps and show fake login screens over them.

On the simulated phone, open the network log for PDF Scanner Pro's 10 minute emulator run. Tap each timeline entry and read what it means.

When malware knows it's being watched

Network traffic isn't the only thing analysts record. A good sandbox also logs file activity (what the app writes, downloads and deletes), permission activity (which permissions it requests, and when), and attempts to gain powerful access, such as nudging the user toward an accessibility service or to allow installs from unknown sources.

Malware authors know their apps get run in sandboxes, and some try to behave innocently there. MITRE ATT&CK lists this as Virtualization/Sandbox Evasion (T1633). Conceptually, it takes a few forms:

• Environment checks. The app looks for signs it's on an emulator rather than a real phone. If it thinks it's being watched, it stays quiet. Zscaler ThreatLabz reported in 2025 that Anatsa's droppers ran emulation checks and verified device models, and showed an ordinary file manager screen when the checks failed.
• Waiting. Some samples do nothing suspicious for hours or days, longer than a typical automated run.
• Waiting for orders. The harmful step only happens if the C2 server sends a command, and the server may only answer phones in certain countries or with certain apps installed.

This is why a clean sandbox result doesn't prove an app is safe. Analysts respond by combining methods. Static analysis might reveal code that checks for an emulator, or a URL that never got contacted. Longer runs, more realistic test devices and repeated runs can coax out more behavior. And every finding gets compared against what others have reported about the same family.

One rule holds through all of it. This is professional work done with samples obtained through proper channels and run in isolated labs. Nobody should install a suspicious app on their own phone just to see what happens. If you think a phone is infected, the cleanup steps from Cleaning Up a Phone are the right tool.