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