Not too long ago, I acquired an Amazon Echo. It's certainly a nifty gadget, but the "always listening" nature of the device makes one wonder. Room audio data concerns aside, what else does the Echo access on the Internet? To look into this, I simply ran tcpdump for 48 hours and captured everything from the Echo. I intentionally never "asked Alexa" anything in order to keep the capture file limited to the Echo's background activities.

So what did the Echo do?

Power On Activity

For this analysis, I simply loaded the capture file into Wireshark and looked at the sequential contents.

1. Routine DHCP acquisition of an IP address
2. 5 ICMP pings of the DHCP defined gateway address
3. 1 ICMP ping to the 1st DHCP defined DNS (8.8.8.8)
4. 1 DNS request for the A record on www.example.com from the 2nd DHCP defined DNS (8.8.4.4)
5. 1 DNS request for the AAAA record on www.example.com from the 2nd DHCP DNS
6. 1 mDNS request
7. 1 DNS request for the A record on pindorama.amazon.com to the 1st DHCP defined DNS
8. 1 DNS request for the A record on pins.amazon.com to the 1st DHCP defined DNS
9. 1 SYN/ACK/FIN TCP sequence with no data to 93.184.216.34 on port 80
10. 1 SYN/ACK/FIN TCP sequence with no data to pindorama.amazon.com on port 80
11. 1 DNS request for the A record on www.example.net from the 1st DHCP defined DNS (8.8.4.4)
12. 1 DNS request for the AAAA record on www.example.net from the 1st DHCP DNS
13. 3 UDP packets with the same 136 byte payload to 3 high ports on pins.amazon.com
14. 1 SYN/ACK/FIN TCP sequence with no data to www.example.net on port 80
15. At this point, the Echo negotiates a secure TLS 1.2 session with pindorama.amazon.com and proceeds to exchange data
16. 1 DNS request for the A record on softwareupdates.amazon.com from the 1st DHCP defined DNS
17. 1 SYN/ACK/FIN TCP sequence with no data to softwareupdates.amazon.com on port 80
18. At this point, the Echo negotiates a secure TLS 1.0 session with softwareupdates.amazon.com and proceeds to exchange data
19. 1 DNS request for the A record on 1.north-america.pool.ntp.org
20. 1 DNS request for the A record on 2.north-america.pool.ntp.org
21. 1 DNS request for the A record on 3.north-america.pool.ntp.org
22. 50 NTP exchanges between the identified NTP servers
23. 2 UDP packets TBD pins.amazon.com
24. 1 DNS request for the A record on ntp-g7g.amazon.com
25. 1 DNS request for the AAAA record on ntp-g7g.amazon.com
26. 1 DNS request for the A record on 0.north-america.pool.ntp.org
27. 1 DNS request for the A record on todo-ta-g7g.amazon.com
28. 1 DNS request for the AAAA record on todo-ta-g7g.amazon.com
29. 1 DNS request for the AAAA record on 1.north-america.pool.ntp.org
30. 1 DNS request for the AAAA record on 2.north-america.pool.ntp.org
31. 1 DNS request for the AAAA record on 3.north-america.pool.ntp.org
32. At this point, the Echo negotiates a secure TLS 1 session with todo-ta-g7g.amazon.com and proceeds to exchange data

A relative pattern of activity begins to emerge at this point. It is apparent the Echo is socially awkward and checks its watch via NTP rather fervently. When its not checking the time, the Echo hammers away at the gateway IP with ICMP pings. Additionally, it continues to perform DNS lookups on the www.example.net, www.example.com and www.example.org addresses. All of the communications from prior connections remain over TLS v1 and v1.2 links ... except the UDP packets to pins.amazon.com which remain a one-sided communique.

Following the boot activity, the remaining capture file was run over 48 hours just allowing the Echo to idle in order to see where it reached out.

ICMP

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the ICMP activity.

tshark -nr echo.cap -Y "icmp" -T fields -e icmp.type | sort | uniq -c

The Echo processed 3 ICMP types:

• Type 0 - Echo Reply - 6199 hits
• Type 3 - Destination Unreachable - 24 hits
• Type 8 - Echo Request - 6199 hits

1549 of the pings were to the internal LAN gateway. These were a little odd as they took place over a span of 24 hours, a flurry of pings every five minutes.

3100 of the pings were to Google's DNS 8.8.8.8 and 1550 of the pings were to 8.8.4.4, Google's secondary DNS.

The destination unreachable packets seem to just be related to the natural state of network connectivity. 21 of them came from 176.32.98.204, an Amazon address in Ashburn, VA. Another 2 came from a compute host, 23.23.78.3, on Amazon AWS. The last packet was associated to an NTP host in Canada - 199.182.221.110.

NTP

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the NTP activity.

tshark -nr echo.cap -Y "ntp" -T fields -e ip.dst | sort | uniq -c

The Echo reached out to 15 NTP servers 1552 times, nearly every two minutes:

• 38.229.71.1 - 194 hits
• 45.63.71.165 - 66 hits
• 52.0.56.137 - 63 hits
• 64.113.44.54 - 117 hits
• 72.21.192.213 - 304 hits
• 132.163.4.101 - 130 hits
• 132.163.4.102 - 21 hits
• 199.182.221.110 - 125 hits
• 204.11.201.12 - 174 hits
• 204.2.134.163 - 19 hits
• 208.75.89.4 - 9 hits
• 208.88.126.226 - 203 hits
• 209.141.59.16 - 90 hits
• 209.242.224.117 - 39 hits

DNS

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the DNS hosts it resolved.

tshark -nr echo.cap -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c

The Echo reached out to resolve six separate domains:

• device-metrics-us.amazon.com - 100 hits
• pindorama.amazon.com - 23 hits
• softwareupdates.amazon.com - 1 hit
• www.example.com - 624 hits
• www.example.net - 620 hits
• www.example.org - 622 hits

The Echo equally balanced the DNS requests between my local DNS and the 8.8.8.8 Google DNS server.

TCP Connections

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the TCP activity.

tshark -nr echo.cap -Y "tcp" -T fields -e ip.dst | sort | uniq -c
tshark -nr echo.cap -Y "ssl" -T fields -e ip.dst -e ssl.handshake.version | sort | uniq
tshark -nr echo.cap -Y "dns" -T fields -e dns.a -e dns.resp.name| sort | uniq

The Echo reached out to 10 IP addresses over TCP:

• 54.239.26.180
  • device-metrics-us.amazon.com
  • 470 hits
  • 123K downloaded / 126K uploaded
  • Traffic conducted over TLS 1.0
• 54.239.29.231
  • pindorama.amazon.com
  • 1696 hits
  • 158K downloaded / 163K uploaded
  • Traffic conducted over TLS 1.2
• 72.21.207.109
  • device-metrics-us.amazon.com
  • 511 hits
  • 138K downloaded / 137K uploaded
  • Traffic conducted over TLS 1.0
• 72.21.207.120
  • device-metrics-us.amazon.com
  • 439 hits
  • 119K downloaded / 118K uploaded
  • Traffic conducted over TLS 1.0
• 93.184.216.34
  • www.example.com
  • www.example.net
  • www.example.org
  • 3724 hits
  • 386K downloaded / 253K uploaded
  • The Echo just exchanged SYN and ACK TCP packets back and forth with this host.
• 176.32.100.25
  • pindorama.amazon.com
  • 1691 hits
  • 173K downloaded / 159K uploaded
  • Traffic conducted over TLS 1.2
• 176.32.98.204
  • pindorama.amazon.com
  • 2287 hits
  • 206K downloaded / 214K uploaded
  • Traffic conducted over TLS 1.2
• 176.32.99.246 - 12 hits
  • softwareupdates.amazon.com
  • 12 hits
  • 4K downloaded / 3K uploaded
  • Traffic conducted over TLS 1.0
• 205.251.242.52
  • pindorama.amazon.com
  • 545 hits
  • 51K downloaded / 50K uploaded
  • Traffic conducted over TLS 1.2

UDP Connections

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the UDP activity.

tshark -nr echo.cap -Y "udp" -T fields -e ip.dst | sort | uniq -c

33% of the Echo's UDP packets were related to the aforementioned NTP and DNS traffic. However, one IP address continued to standout from the crowd and represented all of the remaining UDP traffic:

• 23.23.78.3
  • pins.amazon.com
  • 6620 hits
  • 1224 downloaded / 1296K uploaded
  • only 2 packets of 191 and 201 bytes sent continuously