The alert came in from the IDS on a Tuesday. A user’s mobile device was beaconing out to an Akamai IP (23.61.214.171) every 17 minutes. Not exactly the most alarming thing you’ll see in a day. Akamai is everywhere, and a regular interval doesn’t automatically mean malware. But a few things about this one were worth a closer look.
What Caught My Attention
The first thing I checked was DNS. In this environment, DNS-over-HTTPS is blocked at the firewall, which means if a device is talking to an IP there should be a corresponding DNS lookup somewhere. There wasn’t one. No resolution, no lookup, nothing. The device was going directly to 23.61.214.171 without asking anyone what it was called first.
Legitimate apps, even ones backed by Akamai’s CDN, don’t hardcode IPs. They resolve a hostname. When you see traffic going to a numeric IP with no DNS activity behind it, the universe of benign explanations gets thin pretty quickly.
The 17-minute interval was the other flag. Consumer apps that check in regularly (email clients, update services) tend to use intervals tied to user behavior or platform push notifications. A fixed clockwork interval is a beacon, not a heartbeat.
The Triage
I pulled the firewall traffic logs for the device (10.44.114.68) and ran interval analysis on the sessions. The timing was consistent enough to rule out coincidence. The byte sizes across sessions were uniform too, which is another beaconing indicator. This wasn’t browsing traffic.
The next step was VirusTotal. Using the Relations tab on the destination IP, I found a DMG file associated with the traffic that came back 26/61. High confidence malicious by any reasonable threshold. The signing certificate on the file had been revoked, which is a detail worth noting: a revoked cert means the developer’s identity was at some point verified, then pulled. That’s a common pattern with adware distributed through sketchy download sites.
The malware family came back as InstallMiez, a macOS adware installer with a long history of bundling unwanted software alongside whatever the user thought they were downloading. Not a RAT, not ransomware, but not nothing either. It installs persistence mechanisms, can redirect browser traffic, and generally makes a mess of the system it lands on.
Where Defense-in-Depth Actually Showed Up
This is the part worth documenting, because it’s easy to talk about layered controls in the abstract and harder to point at a real example.
Three separate systems flagged this device independently.
The IDS caught the beaconing pattern first. Behavioral detection, no signature required. It saw the regular interval traffic and raised its hand.
The firewall’s application identification flagged the traffic characteristics as suspicious, separate from the IDS alert.
The threat prevention engine also fired on the traffic.
Three controls, same device, same traffic, same conclusion. None of them needed the others to make the call. That’s the point. If one control had a gap (misconfigured rule, missed signature, blind spot), the other two were still there. The device didn’t make it out undetected because it couldn’t.
Containment
Containment on a BYOD device is a different problem than on a managed endpoint. I can’t image it, I can’t run remediation scripts on it, and I can’t verify the user actually cleaned it. What I can do is cut off its network access until they do.
The destination IP was blocked at the firewall. The device was flagged in the network access control system as requiring remediation before it could re-register. The user was notified and given guidance on what to look for and how to clean it.
Whether they actually followed through is a different question. One of the less satisfying parts of BYOD environments is that remediation is ultimately on the user.
Takeaway
The InstallMiez incident wasn’t complicated. It wasn’t a multi-stage campaign or a sophisticated threat actor. It was adware on a user’s device, caught because three controls did their jobs. That’s actually the best-case version of how this is supposed to work, and it’s worth writing down. Not every post needs to be about a six-host RAT outbreak. Sometimes the story is just: the system worked.
This writeup describes an incident at a large institution. All internal IPs have been substituted with RFC 1918 ranges and identifying details have been generalized.