A Russian phone number, WhatsApp, and 140 outbound SSH alerts | nox.sh

For about five weeks, my UDM Pro kept generating the same alert from one iPhone on my network:

ET SCAN Potential SSH Scan OUTBOUND<br>source: [iPhone on local VLAN]<br>destination: [redacted cloud host]:22/tcp

I had 140 of these. No other device on the network generated one.

My setup is nothing unusual: a UDM Pro at the edge, with Pi-hole and Unbound handling DNS.

I took the alert name literally. One phone appeared to be opening SSH connections to cloud servers around the world, sometimes at 3am. I checked for unknown profiles, certificates, VPNs and linked devices. I found nothing and got close to recommending a wipe.

A controlled packet capture eventually tied the traffic to opening WhatsApp.

What the IDS actually recorded

Source<br>one iPhone

Observation window<br>about five weeks

Alerts<br>140

Other devices with the same alert

Total traffic involved<br>under 1 MB

The destinations were ordinary rented servers spread across several cloud providers. Most connection attempts failed. A few completed enough of a handshake to confirm that this was real traffic and not a reporting bug.

Before doing anything else, I should have read the rule:

flow:to_server; flags:S,12;<br>threshold: type threshold, track by_src, count 5, seconds 120;

It fires after five matching SYNs from one source within two minutes. So an alert is a threshold crossing, not a record of one connection. I had been treating the IDS output as a complete connection log when it was only showing me the events that crossed the threshold.

Port 22 was misleading too. The packet capture later showed the same behavior across several ports. Port 22 stood out because this particular rule watches it.

Where I wasted time

The phone queried a domain under .invalid, a suffix that is guaranteed not to resolve. That looked like a DNS-integrity probe: ask for something that cannot exist and see whether the resolver lies. I thought it was important until I searched the other devices and found the same probe on two more Apple devices, including my own phone. It was normal OS behavior. I had only searched the logs of the phone I already suspected.

I also calculated that 83% of the destinations appeared only once and started building a theory around a constantly changing server fleet. That number came from the sampled IDS alerts, not from all the traffic, so the calculation did not mean what I thought it meant.

The timestamps sent me in another bad direction. Alerts appeared at almost every hour of the day, which made persistent background networking seem likely. I left the phone idle for ten minutes and got no traffic at all. The owner simply uses the phone at odd hours.

There was also a burst of strange-looking hostnames around some alerts. What looked like a signature turned out to be my DNS server logging each step in an ordinary CNAME chain as a separate row.

Testing the apps

I finally stopped reading old logs and ran a passive capture on the phone&rsquo;s VLAN. I didn&rsquo;t send traffic to the phone or interfere with any connections.

PHONE_IP=192.0.2.10 # replace with the device IP<br>CAPTURE_IF=br0 # replace with the VLAN interface

sudo tcpdump -ni "$CAPTURE_IF" -s 96 \<br>"host $PHONE_IP" -w iphone-test.pcap

The short snap length limits how much application payload is stored while keeping the packet headers the analysis needs. It is not a guarantee of metadata only, since 96 bytes can still include the start of a payload. Captures can hold sensitive data either way, so I ran it only during the controlled tests and deleted it afterwards.

I tested one condition at a time:

Test<br>Result

Phone idle and untouched, ten minutes<br>no connections

Telegram force-quit and relaunched<br>no connections

Safari force-quit and relaunched<br>no connections

WhatsApp force-quit and relaunched<br>immediate burst, three launches in a row

That was the useful result. The phone was quiet while idle, the two unrelated apps were quiet, and WhatsApp produced the burst three times out of three.

The capture also showed the normal Meta connection succeeding while the alternate connections were still in flight, and the alternates being abandoned together shortly after.

What the capture showed

Each test launch produced two groups of connections:

WhatsApp launches<br>├── normal connection to Meta ─── succeeds<br>└── 10 to 24 other connections ───── abandoned together

The other connections went to rented servers across several cloud providers. They presented as ordinary remote-access sessions, but not consistently, and they were attempted across multiple ports. Once the normal Meta connection succeeded, the other connections were dropped nearly together.

This looks like a connection race: try the normal route and a set of possible alternate routes in parallel, then keep whichever works. On this network the normal route works, so the alternate attempts lose every time I tested it. The IDS had been reporting part of those...