E-mail phishing vs Unlimail

Alguns dos cyber-crimes mais importantes da história começaram quando alguém resolveu verificar um e-mail malicioso endereçado para algum C-Level, executivo, chefe de estado, assessor de um perfil high-profile, por mais óbvio que um e-mail malicioso pareça para alguns, este tipo de ataque vem sendo executado há anos tendo atingido redes governamentais e empresariais como a Casa Branca nos EUA, e em instituições privadas nos setores de Defesa, Energia, Financeiro, Seguros, Jurídico, Mídia, Farmacêutica, Tecnologia, Pesquisa e Desenvolvimento e até mesmo em universidades, mais recentemente, instituições financeiras e até mesmo o processo democrático nos EUA sofreram influência devido ao vazamento de e-mails pessoais conforme como descrevemos aqui, e também, o alto escalão da OTAN (Organização do Tratado do Atlântico Norte) teve assuntos sensíveis acessados indevidamente através de técnicas de intrusão para a coleta de e-mails.

Atualmente não são apenas cyber-criminosos, mas também governos que utilizam a metodologia intrusiva para intelligence gathering ou coleta de informações com a finalidade de prover conhecimento ou inteligência, há também grandes corporações agindo fora da lei ou espionagem industrial para o ganho de vantagem financeira.

Diante deste cenário, estendemos MarkzCorp Prodigy Framework e desenvolvemos Unlimail para adicionar uma camada de imprevisibilidade e blindagem digital quando e-mails com informação de alto valor forem acessados indevidamente, tornando a leitura de conteúdos privados inaccessíveis à acessos não autorizados, violação de privacidade, roubo de acesso e credenciais ou hacking de contas de instituições onde o valor da informação seja de alta monta, possua valor político, governamental ou confidencial.

Há alguns anos atrás os malwares ou APT softwares (Ameaça Persistente Avançada) eram endereçados diretamente no anexo de e-mail, levando fornecedores de client-email como outlook, mozila, gmail e outros a bloquear arquivos em anexo com extensões de execução como : *.exe (executável), *.bat (processamento em lotes), *.app (aplicativo executável) etc no intuito de impedir que arquivos em anexo executem códigos maliciosos de remetentes desconhecidos.

No passado também era possível transformar o corpo do e-mail em html com iframes imitando páginas bancárias onde os destinatários inseriam as suas informações pessoais que eram enviadas de volta para os atacantes, posteriormente, os provedores de e-mail passaram a alterar o “body format” para texto ou html.

Esta técnica passou a ser empregada também em arquivos de dados diversos tais como os de pacote office como o Excel, Word, Power Point, que permitem pré-programar o comportamento contido em seus dados onde os atacantes dissimulam e enviam anexos falsos como os de contas bancárias, pagamentos, informações pessoais e onde o conteúdo inserido nos anexos é encaminhado, após preenchido, para o remetente mal intencionado e responsável por enviar o anexo malicioso.

De maneira geral, toda metodologia de ataque bem sucedida, torna a acontecer, e com e-mail phishing não é diferente, ao longo dos anos, a metodologia é basicamente a mesma, mudando apenas a forma como é feita.

E-mail phishing utiliza e-mails falsos, dissimulação de remetentes e conteúdo falso no intuito de induzir os destinatários a confiar no seu conteúdo, parte desta técnica só é possível através da engenharia social onde o atacante estuda os hábitos, preferências e sugestões das vítimas em redes sociais no intuito de confeccionar um e-mail mais sugestivo e que induza os destinatários ou vítimas até que estas mordam a isca e abram o conteúdo destes e-mails falsos contendo códigos maliciosos.

Este ataque também pode conter urls dissimuladas , encurtadas ou de redirecionamento para domínios e links maliciosos para a execução de malwares ou vírus, coleta de informações e fingerprints como endereço IP, navegador, sistema operacional procedida de vetores de ataque ou o redirecionamento para páginas que sugiram as vítimas a fornecer dados pessoais como senhas, documentos, telefone, e-mail, data de nascimento, nomes de parentes como pai e mãe etc.

Nós sabemos que políticas de segurança da informação bem implementadas permitem identificar este tipo de ataque, mas como a forma em que é feita e a persistência do atacante são dinâmicas, eventualmente um colaborador sempre morderá uma isca comprometendo a rede de sua instituição, mesmo que esta instituição ou empresa possua políticas avançadas e alto investimento em segurança da informação. Neste caso, Unlimail é a última proteção que bloqueia o acesso não autorizado à contas de e-mail e seu conteúdo.

Diante de alguns incidentes de repercussão internacional listamos as principais características deste ataque e como Unlimail se comporta diante de cada cenário e com as nossas considerações

  1. E-mails falsos ou suspeitos: Após listar e-mails de instituições, o atacante procura dissimular o remetente e o assunto no intuito de fisgar o destinatário
  2. Não verifique ou confie em e-mails cujo o corpo não segue a sua política de chaves de criptografia, uma maneira de verificar a autenticidade do remetente é ter uma chave de criptografia em conformidade com a sua política de segurança da informação ou gerenciamento de criptografias;
  3. Se você desconfiar que um e-mail não encriptado pode ser de um conhecido, não responda ao e-mail, não forneça dados e verifique por outros meios diretamente com o destinatário a autenticidade do e-mail recebido.Nota: Usuários UNLIMAIL necessariamente são conhecidos e conhecem a política de chaves de criptografia por remetente, destinatário, assunto etc garantindo que e-mails abertos ou descriptografados não estejam em conformidade com as nossas recomendações e políticas de segurança. Aceite apenas e-mails onde o conteúdo possa ser aberto por uma chave de criptografia garantindo que o remetente sabe qual é a chave que o destinatário utilizará para abrir o seu conteúdo;

    Chaves de criptografia Unlimail não são públicas e não devem ser publicadas ou trocadas pelo meio digital, recomendamos protegê-las fisicamente.

    Solicite a nossa política para a composição de criptografia avançada.
  4. E-mails com URL’s dinâmicas para download e execução de arquivos maliciosos: Unlimail não trabalha com html no corpo da mensagem de maneira a garantir a proteção de algumas modalidades de phishing, entretanto é possível enviar urls em assuntos ou corpo de e-mail sem que sejam executadas, mas se estas URLs copiadas ou replicadas na sua máquina ou no seu navegador forem executadas será por sua contas e risco;

    Se você receber uma url ou endereço de um remente conhecido e ela estiver codificada você saberá que o remente conhece a sua política de chaves de criptografia garantindo a autenticidade do remetente;
Nota: Unlimail não faz pré-loading de urls ou htmls no intuito de impedir o carregamento de códigos maliciosos ou fornecer fingerprints;
  1. Information gathering: Ataques persistentes estão sendo desenvolvidos como vetores de ataque explorando múltiplas funcionalidades e coleta de informações de segurança do sistema atacado como antivírus, firewall, credenciais, logins e senhas, etc. No intuito de fugir da heurística de softwares de segurança estes malwares são descarregados em etapas neutralizando à conta-gotas a segurança da sua rede em um processo multiestágio de descompressão de módulos nocivos.

Nota: Uma premissa do MarkzCorp Prodigy Framework e softwares derivados, é que nós não armazenamos chaves de registro e nem demais informações impedindo que códigos maliciosos identifiquem e coletem informações de nossos softwares, nós também descarregamos pacotes de executável com nomes encriptados à cada execução na versão DEMO e este nome de processo + PID alterna on-the-fly na versão corporativa tornando qualquer coleta de informação acerca de Unlico inviável. Esteja seguro de que as informações imputadas em unlico não são salvas, não geram logs e não possuem backdoors.

Nota: Nosso código fonte e protocolos internos são fechados, obfuscados e com proteções avançadas na versão DEMO contra alguns dos ataques listados abaixo. Proteções adicionais extensíveis à versão DEMO estão disponíveis apenas na versão corporativa:

– MITM (Man in the middle) ;
– Rainbow Table/ Thunder Table;
– Engenharia Reversa e Cracking;
– DLL Injection / Assembly Injection
– Brute-Force;
Nota: Unlimail foi desenvolvido para não operar com Sessão, ou HTML impedindo ou reduzindo a superfície de outros tipos de ataque como XSS-Attack, Session Hijacking etc.

  1. Exploração de vulnerabilidades 0-Day e atualização de software: Comumente malwares e APT incrementam em seu vetor de ataque a exploração de vulnerabilidades encontradas em atualizações de software ou sistema operacional.

Nota: Uma premissa de MarkzCorp Prodigy Framework e softwares derivados é não delegar a sub-rotinas de sistema operacional, softwares proprietários ou de terceiros as suas funcionalidades. MarkzCorp Prodigy Framework não está vulnerável à falhas de segurança encontrada em navegadores, plugins, scripts, shells. Todas as nossas funcionalidades e módulos são de nossa propriedade estando livres da exploração de falhas e segurança em lançamentos e atualizações.

Solicite a nossa política para auditoria externa de software.

  1. Roubo de Credenciais, logins e senhas, LDAP, e cloud-services, roubo de Senhas: Unlimail utiliza a máquina de criptografia MarkzCorp Prodigy Framework e suas proteções são extensíveis aos demais softwares como Unlich, Unlift, Unlinet e não há a necessidade de passwords. Chaves de criptografia podem ser qualquer arquivo ou texto armazenados localmente ou remotamente em ftp, urls, páginas estáticas, e em qualquer formato.

Nota: MarkzCorp Prodigy Framework pode utilizar arquivos de qualquer formato conhecido como chaves incluindo ELF ou COFF, ou até mesmo sem formatos nativos de sistemas operacionais.

Nós não fornecemos chaves e não temos como saber o tamanho, formato ou quantas chaves cada usuário possui justamente para garantir que chaves não possam ser roubadas. MarkzCorp Prodigy Framework por não utilizar padrões de mercado como TLS/SSL com .cert, .key ou CSR files não pode ter chaves roubadas por malwares ou reconhecido por módulos de APTs pré-programados para roubar senhas que levam em consideração a extensão de arquivos comumente aplicados para senhas e credenciais.

MarkzCorp Prodigy Framework também não possui padrão de armazenamento de chaves e estas não necessitam estar em um diretório específico pois entendemos que malwares coletam informações de criptografias de mercado baseado não apenas em formato de arquivos mas também diretórios padronizados por outros softwares como navegadores.

É possível configurar múltiplas chaves para o mesmo remetente ou assunto, em múltiplos caminhos físicos ou virtuais, ou conforme sua política de segurança interna, por isso recomendamos não utilizar a mesma chave de criptografia para o driver interno, arquivos, remetentes, destinatários e demais funcionalidades.

Recomendamos o uso de chaves de criptografia no mínimo :

  • 1 para o driver interno;
  • 1 para cada destinatário de e-mail;
  • 1 para cada remetente de e-mail;
  • 1 para cada funcionalidade ou atividade que requeira proteger um dado sensível seja ele em armazenamento ou transporte via POP3/SMTP e (ou) arquivos locais.

Adicionalmente recomendamos que as chaves estejam isoladas fisicamente em pen-drives, dispositivos ou diretórios com políticas avançadas de segurança.

Chaves de criptografia também podem estar protegidas logicamente e (ou) fisicamente, em dispositivos impedindo que metodologias modernas de intelligence gathering como WindowsHooking, possam ser empregadas para identificar e roubar arquivos enganchados pelo nosso software, para isso recomendamos armazenar as chaves offline ou em dispositivos desconectados como pen-drives e carregar as chaves em memória somente na configuração inicial.

Nota: Nós temos proteções adicionais contra dll-Injection, dll-hijacking, assembly-Injection extensíveis à versão DEMO, tornando esta metodologias de alterar funções arbitrárias em assemblies Win32 inválidas reduzindo ainda mais a superfície de ataques para metodologias avançadas de hacking e cracking.

  1. Uso de Macros ou VBA em arquivos Office e scripts em arquivos adobe pdf: Unlimail não verifica, lê ou abre arquivos em anexo no intuito de impedir que scripts e macros maliciosas executem em arquivos em anexo. O uso de scripts e macros nestes arquivos também são empregados para executar comandos remotos e maliciosos se estes arquivos forem abertos. Campanhas de e-mail phishing e intrusão também exploram esta técnica no intuito de enganar destinatários de e-mail e comprometer sua rede.

Unlimail também permite que arquivos em anexo sejam encriptados garantindo que o remetente deve conhecer o destinatário, se o você suspeitar de e-mail e o conteúdo não estiver em conformidade com a sua chave não abra o conteúdo, ainda que um anexo malicioso seja encaminhado encriptado, ele não trará risco se for baixado, apenas se for “desencriptado” e posteriormente executado ou aberto fora de nossos softwares.

NOTA: provedores de e-mail e client de e-mail geralmente bloqueiam extensões de arquivo, se houver a necessidade de enviar arquivos bloqueados para anexo, basta encriptá-los e anexa-lo em um e-mail, ao “desencriptar” o seu conteúdo e extensão não serão comprometidos e os dados estarão íntegros. Firewalls não conseguem identificar arquivos criptografados em anexo, portanto recomendamos cuidado aos gestores que possuem usuários acessando dados sigilosos na sua empresa ou instituição, e-mails e anexos encriptados podem ser enviados para fora sem que outros softwares identifiquem o assunto e conteúdo de emails encriptados por Unlimail

Leonardo Metre
COO – MarkzCorp

Be the first to comment

Leave a Reply