Mobile Malware · Cutting Off Malware · Lesson 1 of 5

What Defenders See on the Network

Read network logs the way a security team does, without decrypting a thing.

Reading the log from the other side

In Watching an App Run you read PDF Scanner Pro's network log as a malware analyst. This course looks at the same kind of evidence from the other side: the people who run networks and protect companies. They rarely have the malicious app in hand. What they have is what the network saw.

In plain terms, most mobile malware contacts a server controlled by the attackers to receive instructions and send stolen data. Security teams call that server command-and-control, or C2. Defenders don't need to know how it works inside. They need to notice when a phone starts talking to one.

Their main sources are:

• DNS logs, a record of every domain name devices look up through the company's resolver (DNS: The Internet's Phone Book showed how lookups work).
• Connection logs from firewalls, showing which IP addresses a device reached, when, and how much data moved.
• Gateway logs, from a company filter that web traffic passes through.

The patterns that stand out are simple to describe:

• Unusual destinations. A phone that normally talks to mail, chat and a few big cloud services suddenly reaches a domain nobody else in the company uses.
• Many failed lookups. Bursts of random-looking names, most of which don't exist. Analysts link this pattern to a domain generation algorithm (DGA), which you met in Inside a Malicious App.
• Data leaving. An upload soon after an app is installed, bigger than the app's job would explain.
• New downloads. A file fetched from an unfamiliar host shortly after install.
• Clockwork. Small connections at a fixed interval, day and night.

On the simulated phone, open the network log for PDF Scanner Pro's sandbox run. This time, read each entry as a network defender would, and ask which ones would show up in DNS or connection logs even without reading the traffic itself.

Baselines, new domains and what encryption leaves visible

Spotting something unusual means knowing what usual looks like. A baseline is a picture of normal traffic for a device, a group of devices or a whole network: which domains get looked up, how often, at what times of day, and how much data moves. Security tools build one automatically by watching for weeks, then flag what's new or out of pattern.

Clues defenders weigh:

• Regular intervals. People are irregular. They use apps in bursts, sleep, and put the phone down. Mail and push notifications check in on their own too, but they go to well known providers. A small connection to an unknown domain every 60 seconds, all night, is the kind of rhythm that earns a second look.
• Newly registered domains. Registration dates for most domains can be looked up publicly. A domain created a few days ago and contacted by one phone is more suspicious than one that's existed for ten years. Malicious domains are often fresh, because older ones end up on blocklists.
• Reputation. Threat intelligence feeds, shared lists of known bad domains and IP addresses, tell defenders whether a destination has already been reported.
• Rarity. A destination contacted by one device in a company of 5,000 deserves a look. One that all of them use usually doesn't.

None of these is proof by itself. Plenty of honest apps poll a server on a timer, and new businesses register new domains every day. Defenders combine clues, then check the device.

What about encryption? From What an Observer Sees you know HTTPS hides the contents of traffic, but not everything. The domain name usually shows in the DNS lookup and in the Server Name Indication field of the handshake. The IP address, timing and size of each connection are visible too. This leftover information is metadata, and it's exactly what the patterns above are built from. A defender can say a phone sent 40 kilobytes to a four day old domain every minute without reading a single byte of it.