These symptoms are suggestive of a man-in-the-middle attack. A piece of malware running on the router may be generating bogus certificates on the fly — it's easy to fill in all the fields, but if the attacker does not have access to a trusted root certificate's private key, it can't properly sign it —, intercepting HTTPS traffic, and pretending to be miscellaneous webservers. Because your traffic flows through your WiFi router when you're connected to it, this sort of attack does not necessarily need to show up in DNS records; a router directly on the path from you to the webserver has the power to act as though it was a TCP endpoint. If, for one reason or another, the user errs and chooses to accept the bogus certificate as valid, the malware running on the router can listen to and tamper with traffic from this user to this server, and use this power as a springboard to further attacks, whose targets may possibly including either or both of the user's hardware or legal identity.
You may be able to diagnose this class of issues by attempting TCP connections to faraway HTTPS servers but setting the TTL value to low values. (hping3 is a handy tool for this sort of experiments.) Normally, on each hop in the path of an IP packet, routers decrement the IP packet's TTL header field by one, and when TTL reaches zero, the packet will not be forwarded; instead, polite routers will send back an ICMP TTL expired response. This strategy helps guard against immortal packets eternally travelling accidental routing loops, wasting resources. It is also useful for diagnostic tools such as traceroute.
Let's suppose you're one hop away from the WiFi router, and, say, accounts.google.com is ten hops away. If you send at accounts.google.com:443 a TCP packet with its SYN flag set, indicating that you're trying to open an HTTPS connection, but its TTL at a value of, say, five, the packet should never be able to reach accounts.google.com, like this:
$ sudo hping3 -c 3 -p 443 -S -t 5 accounts.google.com
HPING accounts.google.com (en1 216.58.209.141): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=62.115.61.30 name=google-ic-314684-s-b5.c.telia.net
(Note, however, that the ICMP response may, these days, not be delivered or get lost in traffic, so the diagnostic criterion is lack of a TCP SYN+ACK response rather than arrival of a TTL expired ICMP response.)
If, however, you get a SYN ACK response, like this:
len=44 ip=216.58.209.141 ttl=59 id=23005 sport=443 flags=SA seq=0 win=42780 rtt=8.1 ms
it means that somebody within five hops from you — which, if you're ten hops away from a genuine accounts.google.com, is almost certainly a nefarious imposter — is responding to traffic meant for accounts.google.com, and you can know for sure that something is wrong within these five hops on the IP path.
Note, however, that smart malware may be wise to this trick, so this is conclusive in only one direction. If you, indeed, can't reach faraway servers with low-TTL packets, it hints against, but is not strong evidence against, presence of MiTM malware in the WiFi router. Also note that it is quite possible to be nearer than ten hops to accounts.google.com, so you may want to play with the TTL value (-t option to hping3) a bit.
nslookup itunes.apple.com? – multithr3at3d Apr 3 '18 at 0:56