Uma vez mais, e tal como aconteceu com a vaga de phishing do banco BPI no passado dia 17 de dezembro de 2019, o SI-LAB analisou todos os detalhes por trás desta nova campanha do NETFLIX.
Alerta: Autores da campanha de phishing do BPI lançam nova campanha desta vez atingindo o NETFLIX
O SI-LAB teve acesso ao bundle que os agente de ameças utilizam para alavancar este tipo de campanhas e onde foi possível identificar algumas semelhanças com a vaga de phishing do BPI.
Inicialmente notou-se que o agente de ameaças realizaram o lançamento da SMS potencialmente através da mesma origem do BPI, e a prova disso é o identificador do remetente “BPINet“. Esse descuido por parte dos criminosos permitiu desvendar que a campanha se tratava de um esquema malicioso, e gerou de imediato um alerta de preocupação por parte das vítimas que haviam recebido as mensagens.
Figura 1: SMS recebida pelas vítimas da campanha agrupando a mensagem do NETFLIX com a mensagem do BPI.
O SI-LAB procurou investigar alguma correlação dentro deste contexto, e identificou que 37 das vítimas que recebeu as mensagens do BPI também recebeu as mensagens desta nova campanha do NETFLIX.
Não foram obtidos números totais sobre o volume de utilizadores afetados por esta campanha, no entanto, este indicador apresenta um claro sinal sobre a origem do grupo que despoletou ambos os ataques (BPI e NETFLIX).
Em detalhe, a estrutura base da campanha do NETFLIX é a seguinte.
Figura 2: Ficheiros base da campanha do NETFLIX.
Os ficheiros index.php e geoplugin.class.php são as primeiras páginas a serem invocadas quando uma nova vítima acede ao servidor. Aqui são obtidos alguns detalhes iniciais sobre a vítima.
Em seguida, é despoletada a página “index3.php“, que possui alguns trechos de código que permitem bloquear acessos através de determinados hosts. Aqui é também realizada a copia das landing pages da diretoria “origem” para a nova diretoria única por vítima.
A diretoria “origem” possui todos os fichieros das landing pages da campanha. Esta diretoria é copiada para uma diretoria com nome aleatório no servidor baseado no hash MD5 de um número random. A vítima é depois direcionada para as landing pages dessa nova diretoria.
Para cada nova vítima, uma nova diretoria com as respetivas landing pages são geradas. Com este mecanismo, o agente de ameaças procuram evitar deteções com base em tráfego e sua correlação.
Finalmente, é invocado o ficheiro “atualizar.php” que é responsável por salvaguardar os detalhes da vítima na diretoria “dados“.
Ficheiro index.php (inicial)
Esta é a primeira página a interagir com a vítima. Como pode ser observado na Figura 3, inicialmente são obtidos detalhes sobre o tipo de navegador Web/dispositivo utilizado para aceder ao serviço. Este tipo de informações são geralmente utilizadas para encaminhar a vítima para diferentes landing pages consoante o tipo de dispositivo – web ou mobile.
No entanto, neste caso em específico, o agente de ameaças não efetuou essa distinção apesar de o código fonte para esse teste permanecer hardcoded nas páginas que suportam a campanha.
Figura 3: Código fonte da página index.php onde são obtidos alguns detalhes sobre a vítima.
Entre as linhas de código 26 e 37 podemos observar o tipo de informações obtidos, nomeadamente:
- Endereço de IP da vítima;
- Cidade;
- Região; e
- País.
Um detalhe a destacar está presente na linha 40.
#if($geoplugin->countryName=='Brazil')
{
fwrite($novoarquivo,$d ." - ".$ip." - ".$browser." - ".$browser_version." - ".$geoplugin->city." - ".$geoplugin->region." - ".$geoplugin->countryName."\r\n");
fclose($novoarquivo);
}
Inicialmente as informações eram escritas num no ficheiro dados.txt presente na raiz do servidor caso o país de origem da vítima fosse “Brazil” (#if($geoplugin->countryName==’Brazil’)).
Esta condição foi comentada pelo agente de ameça, porque neste momento, o objetivo da campanha seria atingir alvos portugueses.
Outro destalhe interessante é o default time zone “America/Sao_Paulo“, o mesmo identificado na campanha do BPI (linha 33 da Figura 3).
No final, a vítima é enviada para a página “acesso.class.php”.
Pagina acesso.class.php
Nesta página são realizadas validações relativas ao dispositivo de onde a vítima está a aceder ao servidor da campanha maliciosa. No entanto, na validação (linhas de código 4 e 5), a vítima é direcionada para a mesma página (index3.php). À primeira vista, o agente de ameaças descartou realizar qualquer distinção entre dispositivo de acesso, p.ex., web ou mobile.
Figura 4: Código fonte da página acesso.class.php.
Como pode ser observado na Figura 5 abaixo, estão disponíveis duas páginas identicas chamadas index2 e index3.
Figura 5: Estrutura raiz da campanha destacando os ficheiros index2 e index3.
O ficheiro ~index.php não é utilizado durante toda a campanha. Já os ficheiros index2 e index3 são muito similares, e apenas têm uma modificação entre si.
Qual a diferença entre o ficheiro index2.php e index3.php?
Figura 6: Diferenças entre o ficheiro index2 e index3.
Mais uma prova que a campanha foi adaptada de uma campanha BR. Como observado, o target está bem definido.
A campanha apenas executa se o endereço de IP de origem da vítima fizer parte do range de IPs portugueses. Caso contrário, uma mensagem com erro 404 é apresentada.
Página index3.php
Inicialmente é validado se quem acede à página o está a fazer de alguma origem relacionada com os hostnames indicados abaixo (blacklist by hostname e by IP). Caso isso aconteça, a página apresentará um erro “404 Not Found</h1>The page that you have requested could not be found.”.
Figura 7: Código fonte da págian index3.php com código de blacklist by IP e by hostname.
Também é vísivel a variável PHP na linha de código 29. Aqui é validada indiscutivelmente a origem da vítima. Se o acesso for realizado através de um endereço de IP portugues, a campanha prossegue. Caso contrário, é apresentada uma mensagem com erro 404.
A restante lógica desta págia é responsável por gerar um valor random entre 0 e 1000000000 que dá origem a uma hash do tipo MD5 que será o nome atribuído a uma nova diretoria criada no servidor que irá contem os ficheiros da landing page da campanha (linhas 34 e 35).
$random = rand(0,100000000000); $dst = substr(md5($random), 0, 1000000000); ---Output---- e2934f988b633c79610c3894e52ff796 7f04cc5809ab17e403f5b55d944e8017 9ffc3fc0603068d0c00609940df26864 1aee3116240d70d7c289432fbcdbbfc7 aafbb4aef4fedc2b303456dced7ee48f (...)
Figura 8: Página index3.php – geração de valor random para a criação das landing pages com base no acesso da vítima.
Na linha de código 37 é possível observar a geração do userID, ($uid). Esse valor é uma hash MD5 baseada no seu endereço de IP origem e servirá para identificar a vítima durante os acessos às diferentes páginas da campanha.
Entre as linhas 42-57 está disponível a função responsável por copiar todos os ficheiros base da landing page da diretoria origem para uma pasta destino e única por vítima. De notar que essa diretoria é mais tarde eliminada depois de a vítima concluir todo o ciclo.
Figura 9: Ficheiros base e diretoria “origem” com os ficheiros da landing page da campanha.
Por fim, linha 62 da Figura 8, a vítima é então direcioanda para essa diretoria onde acede à landing page de login do NETFLIX.
Nova diretoria criada por acesso (vítima) e ficheiros da landing page
Os ficheiros disponíveis nesas nova diretoria, única por vítima, são os seguintes.
Figura 10: Ficheiros da landing page disponíveis na nova diretoria única por vítima.
De notar que os ficheiros “index-terminal.php” e “confirmacao-terminar.php” não são utilizados. São versões incompletas dos ficheiros “index.php” e “confirmacao.php” (de uma tentativa inicial de aprimoramento).
Landing page: index.php
Pode ver-se na URL da landing page os detalhes que foram enunciados. A hash MD5 identificando a diretoria da vítima, e a variável “session” com a hash MD5 gerada a partir do endereço de IP da vítima e utilizada como identificador durante o acesso a todas as páginas.
Nesta página de autenticação, são obtidos os detalhes de acesso ao NETFLIX, nomeadamente:
- endereço de email de acesso; e
- palavra-passe.
Figura 11: Landing page de login.
É posível validar no código fonte da página (index.php) que após a vítima clicar em “Entrar”, a vítima é direcioanda até à página “get_pay.php“. Os detalhes (email e palavra-passe) são enviados através do método GET para a página seguinte (get_pay.php).
Figura 12: Trecho de código da landing page (index.php).
No entanto os dados recolhidos (email e palavra-passe) são descartados e não são salvaguardados pelo agente de ameça. Não são utilizados de forma alguma na página get_pay.php para realizar qualquer tipo de operação.
Página get_pay.php
Nesta nova página são solicitados à vítma novos detalhes:
- Nome Completo;
- Cartão de Cidadão;
- Data de Nascimento;
- Número do Cartão;
- Data de validada e código de segurança.
Figura 13: Detalhes adicionais são solicitados na página “get_pay.php”.
Como é possível observar através do código desta página (Figura 14), inicialmente é validado se todos os registos são introduzidos corretamente pela vítima – a função javascript “check_cadastro();” efetua esse processo.
Em seguida, os detalhes são transferidos para a próxima página (confirmacao.php) através do método POST.
Figura 14: A funcao check_cadastro() valida se todos os campos são preenchidos corretamente.
Página confirmacao.php
Esta representa a última landing page da campanha. Aqui são solicitados detalhes extra: número de telemóvel e senha do cartão.
Figura 15: Detalhes adicionais solicitados pela página confirmacao.php.
Analisando o código fonte desta página em específico, é possível observar que os dados obtidos via POST da landing page anterior são agora guardados em sessão.
Figura 16: Detalhes da vítima guardados em sessão PHP.
Em seguida, todos os detalhes da vítima recolhidos ao longo das landing page analisadas estão agora salvaguardados na sessão PHP.
A vítima ao prosseguir e confirmar a forma de pagamento (Figura 15), é direcionada para a página “atualizar.php” (Figura 17), que por sua vez, guarda os detalhes num ficheiro no servidor e direciona a vítima para a página legítima do NETFLIX brasil encerrando assim a campanha (Figura 18).
Figura 17: Formulário que direciona a vítima para a página “atualizar.php” disponível na raiz do servidor.
Página atualizar.php
Esta última página é responsável por obter os detalhes “nº de telemóvel” e “senha do cartão” introduzidos no formulário da página confirmacao.php pela vítima (Figura 15).
Figura 18: Página atualizar.php onde os detalhes da vítima são armazenados no servidor e é realizado o direcionamento da vítima para o serviço legítimo encerrando, aqui, a campanha de phishing.
Em seguida, é recolhido novamente o endereço de IP da vítima e user-agent, mas desta vez para os salvaguardar diretamente junto dos restantes detalhes num ficheiro de texto no servidor.
Como apresentado através da Figura 18, o ficheiro de texto é salvaguardado na diretoria “dados” com o prefixo “NET_ + nº_cartao_cidadao + .txt“.
$arquivo = 'dados/NET_' . $cpf. '.txt';
Nas linhas 41-49 está definida a função “delTree($pasta)” responsável por eliminar a diretoria única por vítima responsável por manter a landing page de phishing e criada quando a vítima acedeu ao servidor pela primeira vez (Figura 8).
Finalmente, e para manter o processo o mais real possível, o agente de ameça direciona as vítimas para a página oficial do NETFLIX brasil:
header('Location: https://www.netflix.com/br/logout');
Semelhanças entre a campanha do BPI e do NETFLIX
Embora não seja possível identificar o agente de ameças por detrás destas duas campanhas, é crucial manter o registo (tracking) das duas campanhas e atentar as suas semelhanças – uma mais valia para que em campanhas futuras desta natureza seja possível avaliar o seu grau de similaridade.
Do trabalho de investigação conduzido pelo SI-LAB, é importante corroborar o seguinte:
- Das 37 vítimas da campanha do BPI (dia 17 de dezembro 2019), as mesmas 37 vítimas também receberam a SMS do NETFLIX (dia 18 de dezembro de 2019), embora não seja possível indagar quanto ao número total de vítimas das duas campanhas.
- Ambas as SMS foram enviadas do mesmo dispositivo origem e com o mesmo cabeçalho (BPINet), sendo agrupadas nos dispositivos móveis das vítimas.
- As campanhas foram lançadas em dias consecutivos (dia 17 e 18 de dezembro).
- Ambas as vagas de ataque utilizam uma base br que é depois adaptada para a língua portuguesa nativa (pt).
- O detalhe do default time zone “America/Sao_Paulo” foi identificado em ambas as estruturas, indicando que a origem inicial destas campanhas foi o Brasil, e mais tarde adaptada para Portugal.
- Um sinal claro dessa adaptação foi identificado nas páginas index2 e index3 em que o agente de ameças definiu o target da campanha (Portugal) com base no endereço de IP origem.
- A estrutura de como os detalhes das vítimas são mantidos no servidor é muito similar (utilizando uma diretoria denominada “dados“).
Indicadores de Compromisso (IOCs)
hxxp://bit.ly/2tmvvwu hxxp://www.avisa-as.ir/sites/default/files/lerSMS.php hxxp://c83-253-170-71.bredband.comhem.se/ /get_pay.php?is_email= /confirmacao.php /dados/NET_ /atualizar.php
Pedro Tavares is a professional in the field of information security working as an Ethical Hacker/Pentester, Malware Researcher and also a Security Evangelist. He is also a founding member at CSIRT.UBI and Editor-in-Chief of the security computer blog seguranca-informatica.pt.
In recent years he has invested in the field of information security, exploring and analyzing a wide range of topics, such as pentesting (Kali Linux), malware, exploitation, hacking, IoT and security in Active Directory networks. He is also Freelance Writer (Infosec. Resources Institute and Cyber Defense Magazine) and developer of the 0xSI_f33d – a feed that compiles phishing and malware campaigns targeting Portuguese citizens.
Read more here.