Hands-on: detectando menções a ataques hackers

Como podemos utilizar o Twitter para rapidamente sabermos de ataques a corretoras de criptomoedas

Diego Zanellato
Heimdall Research Brasil
8 min readFeb 10, 2020

--

Motivação

O ano de 2019 foi marcado por uma série de ataques a corretoras de criptomoedas. Ao todo foram 11, ou seja, praticamente em quase todo mês do ano passado uma corretora foi atacada e milhões de dólares em criptomoedas foram roubados.

Acontecimentos dessa natureza podem influenciar, momentaneamente, o preço das criptomoedas em razão da insegurança generalizada que se propaga junto com a notícia do ocorrido. Como se não o bastasse, tal influência pode ainda manifestar-se de maneira abrupta, pois graças aos portais de notícias e às redes sociais, a ocorrência de um ataque hacker pode tornar-se de conhecimento geral rapidamente.

Diante disso, é de grande importância para aqueles que realizam trade de criptomoedas que informações sobre roubos de corretoras lhes cheguem o mais rápido possível, pois essas podem lhes ser úteis ao minimizarem os seus riscos de exposição às criptomoedas.

Ataques a corretoras e o preço do Bitcoin

Para entendermos melhor como ataques a corretoras podem influenciar o preço do bitcoin, e como a informação se propaga nas mídias sociais, realizamos alguns estudos de casos.

Primeiro, analisamos o “hack ”da Binance, ocorrido no dia 07 de maio de 2019. De acordo com o banco de dados da Heimdall, a primeira menção ao ataque foi feita às 19:39 h (UTC) no Twitter por um usuário chamado cryptoinsiderne enquanto que o primeiro portal a publicar a notícia foi o Coindesk às 23:57 h (UTC). O gráfico abaixo mostra o número de tweets contendo as palavras “Binance” e “hack” em função do tempo:

Número de tweets contendo as palavas Binance e hack.

Note que antes da notícia aparecer no primeiro portal, a informação do ataque sofrido pela corretora já circulava pelo Twitter e por volta das 23:40 h (UTC) o número de tweets que o mencionavam começou a aumentar significativamente. A partir deste mesmo horário, o preço do Bitcoin começou a cair de maneira abrupta conforme podemos ver abaixo:

Preço do Bitcoin em função do tempo

Situação muito semelhante ocorreu após o “hack” da Upbit, no dia 29 de novembro de 2019. A primeira notícia foi publicada às 06:30 h (UTC) por um portal coreano, o primeiro tweet em inglês ocorreu às 07:42 h (UTC) e às 09:32 h (UTC) o fato foi anunciado pela News BTC.

Preço do Bitcoin em função do tempo.

Por volta das 08:55 h (UTC), o número de tweets mencionando o ataque à Upbit começou a aumentar e a partir do mesmo horário o valor do Bitcoin começou a despencar.

Podemos concluir desses exemplos que:

  • acontecimentos como o hack de uma corretora pode influenciar momentaneamente o valor das criptomoedas;
  • a notícia de um ataque pode aparecer primeiro nas redes sociais e depois nos portais de notícias;
  • as redes sociais podem fornecer informações úteis para quem faz trade com criptomoedas.

É importante destacarmos que manter-se informado apenas pelos portais de notícias pode não ser uma boa ideia visto que, nos casos expostos, o preço do Bitcoin variou bastante antes da notícia sair em algum portal em inglês. Portanto, seria muito interessante e útil monitorarmos, por exemplo, o Twitter com o intuito de detectarmos menções a ataques em corretoras.

Protótipo de um Identificador de Tweets sobre Hack

Considerando a possibilidade de tomarmos conhecimento de ataques a corretoras monitorando o Twitter, resolvemos desenvolver um algoritmo de Machine Learning que identifique menções a ataques desse tipo. A ideia geral do algoritmo será descrita nesta seção.

Utilizando o banco de dados da Heimdall, selecionamos e classificamos manualmente diversos tweets que mencionavam os roubos sofridos pelas corretoras Binance, Bitrue, Bitpoint, Gatehub, Vindax e Upbit. Dos 3060 tweets reunidos para o dataset, 1365 dizem respeito aos hacks enquanto que os outros 1695 versam sobre os mais variados assuntos.

Deste dataset, criaremos os conjuntos de treino e teste para o modelo que será desenvolvido. Optamos por manter a proporção das realizações da variável “hack” em ambos os conjuntos mesmo que, pelo fato do dataset não ser desbalanceado, essa escolha seja irrelevante.

Pré-processamento de Texto

Para ganharmos alguma intuição sobre os passos que deveremos seguir, elaboraremos a nuvem de palavras mais frequentes dos tweets sobre hack que estão no conjunto de treino. Note que removeremos as chamadas ‘stop words’ da língua inglesa que foram elencadas pela biblioteca NLTK.

O código acima gera a seguinte nuvem de palavras:

São muito frequentes:

  • nomes de corretoras (Binance, Bitrue, Upbit etc.)
  • nomes de criptomoedas (Bitcoin, Ethereum, etc.)
  • siglas de criptomoedas (BTC, ETH, XRP etc.)
  • nome de países ou nacionalidades (Japan, Singapore, Korean, Japanese etc.)
  • verbos utilizados para informar os ataques (hacked, stolen, suffers etc.)
  • quantias financeiras (7000, million, 342000 etc.)
  • ‘sujeiras’ provenientes da captura do tweet (dollar_symbol)

Para que o modelo não atribua maior relevância a alguma corretora, país, nacionalidade, criptomoeda ou sigla de criptomoeda em particular, utilizaremos as seguintes substituições:

  • Nome de corretora →6b835dfdf3ae15b3730e1ab1bf8fa03c
  • Nome de país → 3b49eb7755c42c80eaa6c2655e738b80
  • Nacionalidade →3e5df2740b0cb5f3e0836d4a301cb294
  • Criptomoeda→3c8abbd38f0bb2506e4a2f24bc956991
  • Sigla de criptomoeda→4a9622f53d12d5438d0444e28f2aab7c

Também removeremos as “stop words” e utilizaremos a biblioteca Spacy para lematizarmos os tweets, i.e., deflexionaremos verbos, palavras no plural e outros lexemas para os seus respectivos lemas. Essas duas transformações são muito importantes, pois reduzirão o vocabulário empregado pelos usuário do Twitter.

Para as quantias financeiras/numerais em geral, averiguaremos o desempenho do modelo ao considerarmos ora as suas exclusões e ora as suas substituições pelo “hash” 44119bf3bae5d40a8d0766b91c304aac.

Por fim, alguns caracteres especiais e outras “sujeiras” provenientes da captura dos tweets, estes encontrados por inspeção do conjunto de treino, serão removidos.

A classe definida acima possui o método “transform” que implementará todas as transformações listadas anteriormente. Além disso, as classes “BaseEstimator” e “TransformerMixin” foram definidas como bases pois utilizaremos futuramente o scikit-learn.

Pipeline e Grid Search

Após a limpeza dos tweets, estes deverão ser transformados em vetores numéricos para posteriormente serem utilizados no treinamento do classificador de tweets de hack. Para a vetorização, utilizaremos a implementação do Sciki-learn do modelo “Bag of Words” e testaremos o algoritmo Random Forest.

Conforme podemos ver do código acima, 380160 combinações de parâmetros serão testadas. Estas combinações envolvem parâmetros de limpeza de dados (remoção dos numerais ou substituição por “hash”), além de diversos parâmetros do “Bag of words” (n_gram, por exemplo) e do Random Forest. Para a aferição de desempenho do classificador, utilizaremos as métricas: coeficiente de correlação de Matthews, precision, recall e accuracy.

Pelo fato de que testaremos variações de todas as etapas da pipeline e que alterações nos parâmetros de um determinado passo não afetam os resultados dos passos anteriores (por exemplo, alterações nos parâmetros do Random Forest não alteram a vetorização dos tweets), será conveniente estruturarmos a realização dos testes na seguinte forma: fixada uma combinação de parâmetros em uma determinada etapa, testa-se todas as possíveis combinações de parâmetros das etapas posteriores. Uma implementação do que acaba de ser discutido é:

Em suma, os passos do algoritmo acima são:

  1. O conjunto de treino passa pela limpeza de dados com uma certa configuração de parâmetros;
  2. Os dados “limpos” são vetorizados de acordo com certos parâmetros;
  3. Com os dados já vetorizados, para cada configuração possível dos seus parâmetros, realizam-se 15 validações cruzadas com o algoritmo Random Forest;
  4. Os dados “limpos” provenientes do passo 1 são vetorizados com uma configuração de parâmetros diferente daquela do passo 2.
  5. Repete-se os passos 3 e 4 até esgotarem-se todas as possibilidades de parâmetros de vetorização;
  6. O conjunto de treino passa pela limpeza de dados com parâmetros diferentes daqueles do passo 1;
  7. Repete-se os passos 2, 3, 4, 5 e 6 até esgotarem-se todas as possibilidades de parâmetros de limpeza de dados.

Os resultados de todos os testes foram salvos no dicionário “resultados”. Os melhores podem ser obtidos através da seguintes função:

Vamos considerar como o melhor modelo aquele que apresentou o maior coeficiente de correlação de Matthews, pois as métricas “precision” e “recall” ficaram mais “harmoniosas” (é bem conhecido que, devido ao balanço “precision-recall”, ao elevarmos um o outro cai!).

Estimando o erro de generalização

Vamos agora aferir o desempenho do modelo no conjunto de teste.

Os resultados foram:

De acordo com as métricas acima podemos afirmar que o modelo:

  • acertou 98,1% do que ele classificou como positivo para “hack”;
  • identificou 96,3% de todos os tweets mencionavam “hack”;
  • acertou 97,5% de todas as suas classificações.

Esses bons resultados se devem muito provavelmente ao fato dos “tweets de hack” presentes no conjunto de teste serem muito parecidos com aqueles do conjunto de treino. Isso é de se esperar, pois não existem muitas maneiras distintas de se noticiar um evento desse tipo.

Nem tudo são flores…

Devido ao enorme volume diário de tweets, o número de falsos positivos pode ser elevado. Poderíamos pensar em aumentar o “threshold” de classificação utilizado pelo Random Forest para diminuirmos esse número, entretanto, o número de falsos negativos aumentaria desproporcionalmente.

Para diminuirmos o número de falsos positivos sem afetarmos drasticamente o “recall” do classificador final, treinaremos um segundo algoritmo que “corrija” os erros cometidos pelo primeiro. O classificador final funcionará assim: um tweet terá classificação positiva para “hack” somente se os dois modelos o classificarem positivamente.

Para o treinamento do segundo algoritmo, selecionamos, utilizando o banco de dados da Heimdall, uma quantia de tweets erroneamente classificados como positivos pelo primeiro modelo e os reunimos com os “tweets de hack” do primeiro dataset em um novo conjunto de dados.

Neste novo dataset, treinamos um outro Random Forest seguindo exatamente os mesmos passos descritos anteriormente (split em conjunto de treino e teste, montagem da pipeline e grid search) e novamente escolhemos como melhor modelo aquele que apresentou o maior coeficiente de correlação de Matthews. A performance do modelo aferida no conjunto de teste encontra-se abaixo:

Para compararmos o desempenho do primeiro modelo com o classificador final (aquele que considera os dois modelos), selecionaremos os dados do conjunto de teste do primeiro dataset que não foram utilizados no conjunto de treino do segundo modelo:

Uma implementação do classificador final é:

Para o primeiro modelo sozinho, os resultados foram:

enquanto que para o classificador final:

Com exceção de “recall”, todas as métricas de desempoenho são melhores para o classificador final, em particular, houve uma melhora em 10% para “precision”!

Produto final

Conectando o modelo desenvolvido acima com tweets em tempo real, temos um serviço que consegue nos alertar sobre menções a ataques de corretoras com métricas de desempenho consideravelmente boas.

Nesse artigo discutimos especialmente o caso de detecção de hackings, entretanto, um modelo análogo poderia ter sido desenvolvido para a detecção de outros acontecimentos que influenciam o preço das criptomoedas (forks, eventos regulatórios, etc.)

Esse serviço torna possível que operadores do mercado de criptomoedas sejam informados de forma mais rápida de eventos relevantes, minimizando assim eventuais riscos de flutuações abruptas no preço.

Se você ficou interessado em testar essa solução, a Heimdall está lançando uma versão beta de acesso a esse e outros serviços. Basta se inscrever no link abaixo:

--

--