Phishing via Apple ID name fields: emails passam SPF/DKIM com payload legítimo
Atacantes injetam texto de phishing nos campos de nome/sobrenome de uma Apple ID falsa, forçam trigger de notificação de alteração de endereço, e a mensagem chega na caixa da vítima assinada por appleid@id.apple.com — SPF pass, DKIM pass, IP Apple real.
O ataque não explora falha no servidor Apple, explora lógica de negócio: o sistema de alertas de segurança da Apple ecoa o conteúdo dos campos de perfil sem sanitizar o que vai no corpo do e-mail. O payload é splittado em first name e last name por causa do limite de caracteres por campo. Resultado: 'Dear User 899 USD iPhone Purchase Via Pay-Pal To Cancel 18023530761' chega de rn2-txn-msbadger01107.apple.com com headers impecáveis.
Contexto
Técnicas de phishing via infraestrutura legítima têm crescido desde 2023 — o vetor de iCloud Calendar invite já era abusado da mesma forma, injetando convites maliciosos que chegavam como notificações genuínas da Apple. A lógica é sempre a mesma: usar o pipeline de notificações da plataforma como relay confiável pra bypassar filtros de spam corporativos e SEGs (Secure Email Gateways). Apple ainda não respondeu ao disclosure da BleepingComputer publicado em 19/04/2026, e o abuso permanece ativo.
Mecânica técnica
O atacante cria uma Apple ID throwaway e seta first name + last name com o texto do scam — ex: 'User 899 USD iPhone' + 'Purchase Via PayPal Cancel 18023530761'. Em seguida altera o shipping address da conta, o que dispara automaticamente o sistema de alertas de segurança da Apple (account change notification). O e-mail gerado pela Apple inclui o nome do titular da conta no corpo — que agora é o payload completo. O e-mail sai de appleid@id.apple.com, IP 17.111.110.47 (Apple legítimo), relay outbound.mr.icloud.com, com spf=pass e dkim=pass. Filtros de conteúdo veem domínio Apple com auth completa e deixam passar. Análise de headers indica uso de mailing lists para distribuição em escala — o atacante provavelmente usa automação pra criar contas e disparar triggers em batch.
O que a gente tira disso
Isso não é bug report clássico — não tem CVE, não tem CVSS, não vai render bounty direto. Mas o vetor é gold pra phishing campaigns altamente direcionadas: executive targeting, bypassing de SEGs corporativos, ataques a usuários de programa que usa Apple Pay/iCloud em fluxo crítico. O hunter que caça business logic abuse em plataformas de pagamento deveria checar se campos de perfil de outros serviços (Google, PayPal, Stripe) ecoam sem sanitização em notificações transacionais — a classe é replicável. Programas como Apple Security Bounty aceitam reports de abuso de infraestrutura pra phishing se houver impacto demonstrável em usuários Apple — vale tentar com PoC documentado.
Como replicar em outros alvos
- Criar conta de teste em plataforma alvo (Apple, Google, PayPal) e popular campos de nome com texto suspeito
- Triggerar qualquer notificação de alteração de perfil/endereço que ecoe o nome do usuário no corpo do e-mail
- Inspecionar headers do e-mail recebido: checar spf, dkim, domínio remetente, IP de origem
- Grep em templates de e-mail se tiver acesso a código: `grep -r '{{user.name}}\|{{account.name}}\|firstName' templates/` pra identificar onde campos de perfil são renderizados sem escape
- Testar limite de caracteres por campo e split de payload entre múltiplos campos (first/last name, city/state, etc.)
Quer virar hunter de verdade? Curso do Ofjaaah.
Metodologia de quem já reportou 3 dígitos de vulnerabilidades em HackerOne, Bugcrowd e Intigriti. Do recon ao report pago — sem teoria inútil.
Ver curso →