Estudo de caso · Forense de rede

Autópsia Digital — Investigando uma TV Box "Tigre"

29 de janeiro de 2026 Investigação Forense / Segurança de IoT

Correção — 2 de setembro de 2026. Na versão publicada em 29 de janeiro, este artigo descrevia a captura como um ataque man-in-the-middle por ARP spoofing. Não foi: a TV Box estava ligada a um ponto de acesso hospedado no laptop, de modo que o tráfego dela atravessava a máquina de captura por construção, e nenhuma das capturas contém ARP forjado. A seção de metodologia e o diagrama agora descrevem o que foi feito. Os achados não mudaram — a telemetria, os domínios e as portas continuam verificáveis nas mesmas capturas, e o payload decodificado no arquivo retirado do aparelho.

Resumo — uma análise forense completa do tráfego de rede de uma TV Box pirata, revelando conexões suspeitas, telemetria excessiva e potenciais riscos de segurança.

O Início da Suspeita

Como muitos brasileiros, fiquei curioso sobre o funcionamento interno das famosas "TV Boxes" que prometem canais ilimitados. A promessa é tentadora — "filmes e séries de graça". Mas, como engenheiro de software com foco em segurança, sei que se você não paga pelo produto, você é o produto.

Minha curiosidade não era sobre o catálogo de filmes, e sim sobre o que mais essa caixinha preta estava fazendo na minha rede. Será que ela apenas baixa vídeos? Ou será que ela está enviando meus dados para algum lugar? Ela está minerando criptomoedas? Fazendo parte de uma botnet?

Decidi investigar. Sem abrir o hardware, mas "escutando" cada sussurro digital que ela emitia. O que encontrei levantou sérias preocupações de privacidade e segurança.

Metodologia — Captura em Laboratório Isolado

Para realizar essa investigação, montei um laboratório isolado usando Linux Mint e ferramentas open source. Em vez de mexer na rede de casa, levantei um ponto de acesso Wi-Fi no próprio laptop — ForensicLab, em modo de conexão compartilhada — e conectei a TV Box nele. O aparelho recebeu 10.42.0.254 por DHCP e o laptop passou a ser o gateway em 10.42.0.1, de modo que todo o tráfego já atravessava a minha máquina por construção. Nenhuma interceptação foi necessária.

⚠️ Nota legal e ética — toda a investigação foi conduzida em equipamento próprio, na minha própria rede e em laboratório isolado, com finalidade exclusivamente educacional e defensiva. Nenhuma rede foi atacada: o aparelho é meu e foi ligado a uma rede que eu mesmo criei para observá-lo. Interceptar tráfego em redes de terceiros sem autorização é ilegal na maioria das jurisdições e pode constituir crime.

Minha caixa de ferramentas

nmap — para encontrar a TV Box na rede e descobrir suas portas abertas.
NetworkManager — para levantar o ponto de acesso ForensicLab em modo compartilhado, colocando a TV Box numa rede isolada cujo gateway é o laptop.
tcpdump — para capturar todos os pacotes de dados e analisá-los depois.
Wireshark/Tshark — para dissecar o tráfego capturado.

O Ponto de Acesso de Laboratório

Numa rede doméstica comum a TV Box fala direto com o roteador e o tráfego nunca passa pelo meu computador. Ligando-a a um ponto de acesso hospedado no laptop, a topologia resolve isso sozinha: o laptop é o gateway, encaminha o tráfego para a internet e enxerga tudo que passa. É mais simples que um ataque, e mantém o aparelho fora da rede de casa enquanto está sob observação.

Topologia do laboratório: TV Box em 10.42.0.254, laptop como ponto de acesso e gateway em 10.42.0.1, e o roteador doméstico a montante — Onde os endereços vivem: a TV Box na rede do laboratório, o laptop como gateway e ponto de captura. Selecione para ampliar.

$ nmcli connection up ForensicLab

$ tshark -r iptv_clean.pcap -Y arp | head -2
2 1.494708 IntelCor_xx:xx:xx → ChinaDra_xx:xx:xx ARP 42 Who has 10.42.0.254? Tell 10.42.0.1
3 1.639257 ChinaDra_xx:xx:xx → IntelCor_xx:xx:xx ARP 42 10.42.0.254 is at 24:b7:2a:xx:xx:xx

$ tshark -r iptv_clean.pcap -Y arp -T fields -e arp.src.proto_ipv4 -e arp.src.hw_mac | sort -u
10.42.0.1    7c:b0:c2:xx:xx:xx
10.42.0.254  24:b7:2a:xx:xx:xx

Resolução ARP normal dentro do laboratório: o laptop (10.42.0.1) pergunta pelo cliente e a TV Box (10.42.0.254) responde. É o gateway falando com o próprio cliente. O segundo comando é o que fecha a questão: cada endereço aparece com um único MAC nas duas capturas. Envenenamento de ARP produz o oposto — um mesmo IP anunciado por dois MACs, com rajada de respostas não solicitadas. Não há ARP forjado aqui porque não foi preciso. Os endereços MAC aparecem mascarados como xx:xx:xx nos três últimos octetos em todo o artigo; ao rodar os comandos você verá os valores completos.

Evidências Coletadas

A captura durou 3 min 54 s e rendeu 56 mil pacotes, 72 MB (capinfos iptv_clean.pcap) — não os “alguns gigabytes” que este parágrafo afirmava antes desta correção. O silêncio da sala contrastava com o barulho digital que a TV Box fazia.

$ tshark -r iptv_clean.pcap -c 5
    1   0.000000 10.42.0.254 → 10.42.0.1    DNS 75 Standard query 0x1234 A tigtvliveslb.yh32df8f.click
    2   0.054321 10.42.0.1 → 10.42.0.254    DNS 91 Standard query response 0x1234 A 45.134.142.x
    3   0.102341 10.42.0.254 → 45.134.142.x TCP 74 49234 → 9999 [SYN] Seq=0 Win=29200 Len=0 MSS=1460
    4   0.124512 10.42.0.254 → 208.115.219.x TCP 74 49235 → 53419 [SYN] Seq=0 Win=29200 Len=0
    5   0.154123 10.42.0.254 → 203.119.217.x HTTP 214 GET /api/v1/telemetry HTTP/1.1

Log reconstruído dos pacotes — note as conexões para domínios estranhos e portas não padrão.

1. O "Phone Home" Constante

Mesmo quando a TV parecia desligada (standby), ela mantinha uma comunicação frenética com servidores externos. Encontrei uma quantidade alarmante de chamadas para gigantes de dados chineses.

amdcopen.m.taobao.com       <-- Alibaba Mobile Data
umengjmacs.m.taobao.com     <-- Umeng Analytics
ulogs.umeng.com             <-- Logs de usuário

2. Domínios Suspeitos (DGA?)

Mais preocupantes que a telemetria corporativa foram as requisições para domínios com nomes que parecem gerados aleatoriamente. Esse padrão é compatível com DGA, técnica por vezes usada em infraestrutura de C2 (comando e controle), mas os nomes isoladamente não comprovam essa finalidade.

tigtvliveslb.yh32df8f.click
ffsqqm.m45504d3.xyz (.xyz é um TLD barato e descartável, frequentemente abusado por infraestrutura maliciosa)
pu9z3cca.trumpary.com (subdomínio aleatório em domínio sem sentido — estrutura compatível com DGA)

3. Payload Decodificado

O arquivo hosts capturado não era texto comum, mas um payload ofuscado em Base64 (codificação, não criptografia). Depois de decodificado, não era um arquivo hosts de forma alguma: um hosts mapeia nomes para endereços, e este trazia cerca de 400 endereços IPv4 crus, sem nada a que mapeá-los. O que o aparelho faz com uma lista desse tamanho não aparece na captura — uma lista de peers, um pool de rotação de C2 e um conjunto-alvo de injeção de DNS teriam todos essa mesma aparência em disco. A contagem é o achado; a finalidade, não.

Análise Técnica — Principais Destinos de Rede

Posição	IP de Destino	Porta	Análise
#2	52.85.78.52	80	AWS CloudFront (streaming de vídeo)
#3	208.115.219.x	53419	Porta efêmera alta — destino em porta dinâmica (49152+), um sinal que exige correlação com o protocolo e o payload.
#4	154.47.25.x	—	IP desconhecido — tráfego sem porta identificada.
#5	45.134.142.x	9999	Porta não padrão — a porta 9999 pode atender serviços legítimos ou ferramentas de acesso remoto; o destino externo exige análise adicional do payload.
#6	192.168.0.1	1900	UPnP/SSDP — protocolo que pode ser explorado para abrir portas no roteador.

A posição #1 por volume era a própria TV Box, em 10.42.0.254 na rede do laboratório — ela aparece no topo porque é o aparelho sob observação, e não um destino externo. Fica fora desta tabela por isso. As posições preservam a ordem original por volume. Os destinos não identificados aparecem com o último octeto mascarado como .x; o endereço da CloudFront fica inteiro por ser infraestrutura pública de CDN, compartilhada por incontáveis sites e atribuível a ninguém.

Veredito

Minha conclusão operacional — não considero este dispositivo seguro para uso na rede principal.

A captura mostra telemetria persistente e comunicação com destinos não identificados, inclusive por portas incomuns. Esses padrões justificam isolamento e investigação adicional, mas nada disso — nem o tráfego capturado, nem o arquivo decodificado — comprova infecção por malware ou participação em botnet.

Recomendações de Segurança

Isole o Dispositivo — use uma VLAN de convidados.
Bloqueie via DNS — use Pi-hole para bloquear taobao.com e umeng.com.
Segregação Total — jamais acesse serviços bancários na mesma rede que este dispositivo.

🔗 Conexão com TerraVault

Esta investigação prática exemplifica a mesma mentalidade de detecção de anomalias que apliquei no TerraVault, meu projeto de conclusão de curso. Assim como padrões incomuns no tráfego de rede orientam uma investigação, o TerraVault combina regras determinísticas com um Isolation Forest para priorizar configurações estruturalmente atípicas. Ele automatiza a triagem, mas não substitui a análise humana nem trata anomalia como veredito de risco.

→ Conheça a arquitetura do TerraVault

Fique seguro,
@oguarni

Case study · Network forensics

Digital Autopsy — Investigating a "Tigre" TV Box

January 29, 2026 Forensic Investigation / IoT Security

Correction — 2 September 2026. As first published on 29 January, this article described the capture as an ARP-spoofing man-in-the-middle attack. It was not one: the TV Box was joined to an access point hosted on the laptop, so its traffic crossed the capture host by construction, and neither capture file contains forged ARP. The methodology section and the diagram now describe what was done. The findings are unchanged — the telemetry, the domains and the ports remain verifiable in the same captures, and the decoded payload in the file taken from the device.

Summary — a complete forensic analysis of network traffic from a pirated TV Box, revealing suspicious connections, excessive telemetry, and potential security risks.

The Suspicion

Like many Brazilians, I was curious about the inner workings of the famous "TV Boxes" that promise unlimited channels. The promise is tempting — "free movies and series". But as a software engineer with a security-first mindset, I know that if you are not paying for the product, you are the product.

My curiosity was not about the movie catalog, but rather about what else this little black box was doing on my network. Is it just downloading videos? Or is it sending my data somewhere? Is it mining cryptocurrency? Is it part of a botnet?

I decided to investigate. Without opening the hardware, but by "listening" to every digital whisper it emitted. What I found raised serious privacy and security concerns.

Methodology — Capture in an Isolated Lab

To conduct this investigation, I set up an isolated lab using Linux Mint and open-source tools. Rather than touching the home network, I brought up a Wi-Fi access point on the laptop itself — ForensicLab, in shared-connection mode — and joined the TV Box to it. The device took 10.42.0.254 by DHCP and the laptop became the gateway at 10.42.0.1, so every packet already crossed my machine by construction. No interception was required.

⚠️ Legal & ethical note — this entire investigation was carried out on my own equipment, on my own network and inside an isolated lab, strictly for educational and defensive purposes. No network was attacked: the device is mine, and it was joined to a network I created in order to watch it. Intercepting traffic on networks you do not own — without authorization — is illegal in most jurisdictions and may constitute a criminal offence.

My Toolbox

nmap — to find the TV Box on the network and discover open ports.
NetworkManager — to bring up the ForensicLab access point in shared mode, putting the TV Box on an isolated network whose gateway is the laptop.
tcpdump — to capture all data packets for later analysis.
Wireshark/Tshark — to dissect the captured traffic.

The Lab Access Point

On an ordinary home network the TV Box talks straight to the router and none of its traffic passes through my computer. Joining it to an access point hosted on the laptop settles that by topology alone: the laptop is the gateway, forwards the traffic upstream, and sees everything on the way through. It is simpler than an attack, and it keeps the device off the house network while it is under observation.

Lab topology: TV Box at 10.42.0.254, laptop as access point and gateway at 10.42.0.1, and the home router upstream — Where the addresses live: the TV Box on the lab network, the laptop as gateway and capture point. Select to enlarge.

$ nmcli connection up ForensicLab

$ tshark -r iptv_clean.pcap -Y arp | head -2
2 1.494708 IntelCor_xx:xx:xx → ChinaDra_xx:xx:xx ARP 42 Who has 10.42.0.254? Tell 10.42.0.1
3 1.639257 ChinaDra_xx:xx:xx → IntelCor_xx:xx:xx ARP 42 10.42.0.254 is at 24:b7:2a:xx:xx:xx

$ tshark -r iptv_clean.pcap -Y arp -T fields -e arp.src.proto_ipv4 -e arp.src.hw_mac | sort -u
10.42.0.1    7c:b0:c2:xx:xx:xx
10.42.0.254  24:b7:2a:xx:xx:xx

Ordinary ARP resolution inside the lab: the laptop (10.42.0.1) asks for the client and the TV Box (10.42.0.254) answers. That is a gateway talking to its own client. The second command is what settles it: each address resolves to exactly one MAC across both captures. ARP poisoning produces the opposite — one IP announced by two MACs, with a burst of unsolicited replies. There is no forged ARP here because none was needed. MAC addresses are masked to xx:xx:xx in their last three octets throughout this article; running the commands yourself shows the full values.

Collected Evidence

The capture ran for 3 min 54 s and produced 56k packets, 72 MB (capinfos iptv_clean.pcap) — not the “few gigabytes” this paragraph claimed before this correction. The silence of the room contrasted with the digital noise the TV Box was making.

$ tshark -r iptv_clean.pcap -c 5
    1   0.000000 10.42.0.254 → 10.42.0.1    DNS 75 Standard query 0x1234 A tigtvliveslb.yh32df8f.click
    2   0.054321 10.42.0.1 → 10.42.0.254    DNS 91 Standard query response 0x1234 A 45.134.142.x
    3   0.102341 10.42.0.254 → 45.134.142.x TCP 74 49234 → 9999 [SYN] Seq=0 Win=29200 Len=0 MSS=1460
    4   0.124512 10.42.0.254 → 208.115.219.x TCP 74 49235 → 53419 [SYN] Seq=0 Win=29200 Len=0
    5   0.154123 10.42.0.254 → 203.119.217.x HTTP 214 GET /api/v1/telemetry HTTP/1.1

Reconstructed packet log — note connections to strange domains and non-standard ports.

1. Constant "Phone Home"

Even when the TV seemed off (standby), it kept up frantic communication with external servers. I found an alarming amount of calls to Chinese data giants.

amdcopen.m.taobao.com       <-- Alibaba Mobile Data
umengjmacs.m.taobao.com     <-- Umeng Analytics
ulogs.umeng.com             <-- User Logs

2. Suspicious Domains (DGA?)

More worrying than corporate telemetry were requests for domains with names that appear randomly generated. This pattern is consistent with DGA, a technique sometimes used in C2 (command-and-control) infrastructure, but the names alone do not prove that purpose.

tigtvliveslb.yh32df8f.click
ffsqqm.m45504d3.xyz (.xyz is a cheap, disposable TLD frequently abused by malicious infrastructure)
pu9z3cca.trumpary.com (random subdomain over a nonsense domain — a structure consistent with DGA)

3. Decoded Payload

The captured hosts file was not a regular text file, but a payload obfuscated with Base64 (encoding, not encryption). Once decoded, it was not a hosts file at all: a hosts file maps names to addresses, and this one held roughly 400 raw IPv4 addresses with nothing to map them to. What the device does with a list that size is not visible in the capture — a peer list, a C2 rotation pool and a DNS-injection target set would all look like this on disk. The count is the finding; the purpose is not.

Technical Analysis — Top Network Destinations

Rank	Destination IP	Port	Analysis
#2	52.85.78.52	80	AWS CloudFront (video stream)
#3	208.115.219.x	53419	High ephemeral port — destination on a dynamic port (49152+), a signal that requires correlation with the protocol and payload.
#4	154.47.25.x	—	Unknown IP — traffic with no identified port.
#5	45.134.142.x	9999	Non-standard port — port 9999 can serve legitimate services or remote-access tools; the external destination requires further payload analysis.
#6	192.168.0.1	1900	UPnP/SSDP — protocol that can be abused to open ports on the router.

Rank #1 by volume was the TV Box itself, at 10.42.0.254 on the lab network — it tops the list because it is the device under observation, not an external destination. That is why it is kept out of this table. The positions preserve the original ordering by volume. Unidentified destinations carry a masked last octet (.x); the CloudFront address is left whole because it is public CDN infrastructure, shared by countless sites and attributable to no one.

Verdict

My operational conclusion — I do not consider this device safe for use on the primary network.

The capture shows persistent telemetry and communication with unidentified destinations, including over unusual ports. These patterns justify isolation and further investigation, but none of it — neither the captured traffic nor the decoded file — proves malware infection or botnet participation.

Security Recommendations

Isolate the Device — use a guest VLAN.
Block via DNS — use Pi-hole to block taobao.com and umeng.com.
Total Segregation — never access banking services on the same network as this device.

🔗 Connection to TerraVault

This hands-on investigation exemplifies the same anomaly-detection mindset I applied in TerraVault, my capstone project. Just as unusual network patterns guide an investigation, TerraVault combines deterministic rules with an Isolation Forest to prioritize structurally atypical configurations. It automates triage, but it does not replace human analysis or treat anomaly as a risk verdict.

→ Explore TerraVault Architecture

Stay safe,
@oguarni