Sometimes the most interesting investigations end with the most boring conclusions. This is one of those.
It Started With a Low-Priority Alert
ET JA3 Hash - Possible Adware landed in the queue on a Tuesday. Middle of the stack, easy to defer. Adware alerts are the fast food of security investigations: ubiquitous, rarely satisfying, usually traceable to someone’s browser extension or a sketchy download. I have closed hundreds of them.
Except the source IP was not a laptop.
It was the cafeteria menu board.
The Logs Did Not Get the Memo That This Was Supposed to Be Boring
I pulled the firewall logs anyway. That is the job.
762 sessions. Single source, single destination. An AWS IP. All SSL/443. Five consecutive days. Every hour of every day, including 3 AM, including weekends. The elapsed time on every session: 60 to 75 seconds, with only 14 unique duration values across all 762 connections. Bytes sent clustering around the same handful of values. Bytes received doing the same.
The intervals were not a fixed timer. They were jittered, rotating between roughly 2.7 minutes, 6.2 minutes, and 15 minutes. A pattern specifically designed to defeat naive statistical detection. This was not a metronome. It was a metronome that had been told to act casual.
I pulled 30 days of logs. Then I found out the retention window for this device was 57 days. The traffic went back to the oldest available entry. Unknown start date. Unknown dwell time.
Rotating AWS infrastructure on a weekly cycle. Dual C2 channels running simultaneously on different timing cadences. A JA3 hash associated with known malicious tooling.
On a device displaying the soup of the day.
What I Was Looking At
By this point the behavioral profile looked like a textbook implant. The jitter, the rotating IPs, the dual channel design, the consistency of payload sizes. All of it pointed toward something that had been engineered to blend in and stay persistent. The 57-day visibility floor with no confirmed start date meant the dwell time could have been months.
So I did what you do when a cafeteria menu board looks like it might be running a persistent implant: I called the vendor.
The Punchline
The vendor uses AWS for their content management infrastructure. The jitter is intentional, built into their sync protocol to avoid hammering the CDN. The rotating IPs are AWS load balancers cycling on their standard schedule. The dual channels are primary and backup sync. The JA3 hash match was coincidental. The TLS client fingerprint happened to overlap with a known adware signature because both use a common SSL library.
Everything was legitimate. The menu board was doing exactly what it was supposed to do, in exactly the way it was designed to do it, and that design happened to look indistinguishable from a well-engineered persistent implant.
The conclusion was soup.
Why I Am Writing This Up Anyway
This is worth documenting because the process was right even though the outcome was benign.
I did not assume it was the vendor because it was “just a menu board.” I pulled the logs, ran the behavioral analysis, established the timeline, and then confirmed with the vendor. The alternative (closing the ticket because menu boards do not get infected) is how real infections go undetected for 90 days on devices that nobody thinks to look at.
The methodology is the same regardless of outcome. Catch the alert, pull the logs, analyze the behavior, confirm the verdict. Sometimes the verdict is malware. Sometimes the verdict is an aggressively engineered content sync protocol that really should have been documented in the vendor’s security questionnaire.
A few things worth acting on regardless of the benign outcome: get the vendor to document their full IP range and add it as a named object in the firewall. That way the next analyst who pulls these logs has context and does not have to run the same investigation from scratch. And take a hard look at what other devices on the network share the same vendor or the same traffic profile. If the menu board looks like this, what else does?
The investigation produced a correct answer. That is what the methodology is for.
This writeup describes an investigation at a large institution. Device and infrastructure details have been generalized.