Por Victor Leme Beltran, analista de Machine Learning do ICTi

Com a criação de IAs multimodais e sua implementação em ferramentas e em áreas de negócio, surge um grande desafio para a cybersegurança que é como mapear e identificar potenciais vulnerabilidades nestes sistemas e como pensar em defesas e protocolos para mitigação de ataques.

Apesar de se tratar de um mundo completamente diferente do tradicional do ponto de vista de interação do usuário com as plataformas e de vetores potenciais de ataque, podemos nos utilizar com pouca adaptação de princípios de modelagem de ameaças já bem estabelecidos, como os propostos em OWASP e a análise de Kill-Chain.

Inspirado neste desafio, trazemos com este artigo, um exemplo de como um profissional de cybersegurança poderia pensar e modelar ameaças à um sistema que conta com mecanismos multimodais de interação com usuários.

O exercício de pensamento

No cenário a ser analisado, iremos modelar as ameaças para um sistema hipotético pensando em ameaças externas com foco somente no vetor de ataque de áudio de um usuário que interage com uma IA. Claramente é uma versão simplificada de cenários reais focada no aspecto da interação com IAs, mas que pode servir ao leitor como referência para pensar em seus próprios desafios, sejam relacionados ao vetor de áudio ou a qualquer outro cenário multimodal, como por exemplo, imagens. Tendo isto em mente, nosso objetivo ao realizar a modelagem é entender e responder as seguintes perguntas: quem quer nos atacar, com o que pode nos atacar, como pode nos atacar, o que querem com os ataques e qual a probabilidade e criticidade dos ataques mapeados. Nos tópicos abaixo vamos pouco a pouco pensar juntos em como responder estas perguntas de modo a definir defesas em nosso sistema.

Entendendo sua realidade

Quando pensamos em modelagem de ameaças, podemos utilizar uma das máximas do famoso estrategista chinês, Sun-Tzu, como nosso guia “Se você conhece o inimigo e a si mesmo, não precisa temer o resultado de cem batalhas”.

Conhecer a si mesmo é o primeiro passo para iniciarmos nossa modelagem, para isso, precisamos entender o que os sistemas que queremos defender podem ou não fazer, quais os níveis de acesso necessários para realizar certas ações e o que de fato queremos proteger, seja por exemplo a imagem da instituição, os dados internos que são guardados, operações em nome de um usuário etc. Para o caso do nosso exemplo, vamos imaginar uma interface para a plataforma de uma empresa em que áudio será utilizado de duas maneiras, primeiramente como meio do usuário interagir com uma IA que por sua vez o permite sanar dúvidas e realizar algumas operações financeiras de seu desejo e em segundo lugar, como meio de autenticar se o usuário que está falando com a IA é de fato quem seria o dono da conta realizando a interação.

Dado este cenário, podemos entender que qualquer ataque que exista, será claramente relacionado ou ao mecanismo de autenticação ou à interação com a IA conversacional. Dado isto, iremos realizar um paralelo ao OWASP para entender o que seria possível dentro das categorias STRIDE de ameaças. Em nosso contexto, podemos imaginar que seria possível um atacante tentar realizar “Spoofing”, ou seja, tentar se passar por um usuário que não o legítimo dado o mecanismo de autenticação; poderia tentar se utilizar de uma ameaça de “Information Disclosure” ao tentar interagir com a IA conversacional para tentar obter informações confidenciais sobre o sistema e poderia também se utilizar de “Tampering”, para realizar ataques de prompt injection para tentativas de jailbreak. Seria possível também mencionar ataques de DoS mas estes não são o foco deste artigo dado que a ideia é olhar mais para a perspectiva do uso de áudio e interação com IA dado o contexto de multimodalidade do modelo e o fato de DoS ser um ataque tradicionalmente já mapeado relacionado à disponibilidade do serviço.

Figura 1 – Modelo Stride de Ameaças – Fonte: https://dzone.com/articles/stride-threat-modeling-guide-secure-implementation

Agora que entendemos sobre nosso sistema e identificamos potenciais ameaças, vamos para uma segunda parte que é entender nosso “inimigo”. Entendendo o perfil do atacante permite-nos preparar mais claramente contra o nível de ameaça que esperamos receber, bem como facilita a entender melhor com qual frequência iremos presenciar certos tipos de ataques. Podemos categorizar atacantes em inúmeros grupos, que vão desde hackers financiados por governos até um jovem qualquer entediado que decide “brincar” com seu sistema.  Na figura abaixo, podemos observar um exemplo de como listar estes potenciais atacantes.

Figura 2 – Profiling de atacantes, Fonte: https://www.telenor.com/security-architecture-design-phase-the-concept-of-a-threat-intelligence-driven-defendable-architecture/

Os “tiers” nos quais os potenciais agentes maliciosos estão organizados representam a capacidade ofensiva destes grupos, sendo o tier 6 o mais capaz, representando estados-nação e o tier 1, atacantes sem habilidade técnica significativa. Aqui iremos responder à pergunta de “quem quer nos atacar?”

Para responder à esta pergunta, primeiramente vamos nos questionar quanto as motivações dos possíveis agentes. Caminhando do topo da pirâmide para baixo, iremos analisar quais potenciais agentes poderiam querer nos atacar e se teriam algo a ganhar com isso. Dado que nosso sistema não se trata de algo crítico o bastante para ser tema de segurança nacional, podemos excluir os atacantes Tier 5 e 6 dado que estes não teriam nada a ganhar com um ataque contra nosso sistema, logo, podemos desconsiderar estes agentes na análise. Quando olhamos ao Tier 4 e 3, podemos observar entidades que representam crime organizado e mercenários, estes que por sua vez, geralmente detém interesse em ganho financeiro por meio de seus ataques, sendo, portanto, um perfil potencial de atacante contra nosso sistema. Ainda olhando no tier 3, temos a figura do Hackativista, um agente de ataque com perfil diferente que poderia ter como objetivo não só o ganho financeiro como nos anteriores, mas também o de prejudicar a imagem da instituição. Isso poderia ser feito por exemplo, por meio de um jailbreak com prompt injection onde o atacante faz com que a IA diga coisas inapropriadas ou expresse opiniões ofensivas a fim de alegar que o que foi dito seria a visão da empresa por exemplo. No tier 2 podemos ver criminosos independentes que podem ter um mesmo objetivo de ganho financeiro, mas que no entanto são menos capacitados e operam independentemente. No tier 1 temos script-kiddies e trolls, sendo estes dois últimos muito interessantes, pois não detém um motivador maior como ganhos financeiros ou ativamente prejudicar a instituição alvo, eles em geral podem realizar ataques simplesmente pelo caos, focando em ataques contra a IA em si, induzindo a falas inapropriadas, comportamentos inapropriados simplesmente por diversão de quebrar coisas. Apesar de não ser diretamente malicioso, este uso indevido pode indiretamente gerar repercussão em redes sociais e eventualmente prejudicar a imagem da instituição, além de acarretar custos computacionais para responder à estas interações ilegítimas, logo, é bom também se prevenir contra estes casos também.

Agora que mapeamos os agentes com potenciais motivações, vamos pensar em quais ferramentas e técnicas estes agentes têm à sua disposição ou que poderiam desenvolver para utilizarem contra nossos sistemas. Assim como com os próprios agentes maliciosos, vamos dividir estas em tiers para melhor organizá-las levando em conta o nível técnico requerido para deter e operar com sucesso estas tecnologias. Para nosso exercício de pensamento, iremos usar de 3 tiers, sendo o 1, o mais simples e 3 o mais avançado.

O tier 1 representa técnicas e ferramentas facilmente acessíveis, que agentes sem muita especialização técnica poderiam ter acesso e utilizar delas, apresentando um nível menor de ameaça quando comparado aos outros tiers. Exemplos de ferramentas neste nível são: edição de áudio manual, TTS padrão oferecido online, prompt injection via áudio.

O tier 2 representa um nível mais avançado que requer mais de conhecimento técnico e disposição por parte do atacante para utilizar, no entanto não são de nível profissional. Exemplos deste tier são: voice cloning gerado de graça em plataformas online e TTS customizado.

Por fim, o tier 3 representa uma classe de técnicas e ferramentas muito avançadas, de nível profissional que requerem uma alta especialização técnica, não estando facilmente disponível e que representam uma ameaça significativa para nosso sistema. Exemplos: ruído adversarial injetado em áudios, clone de prosódia/clone de voz customizado de alto nível.

Figura 3 – Profiling de ferramentas

Com nosso set de ferramentas estabelecido, podemos agora conectar estes aos nossos agentes atacantes e com isso, entendermos o que esperamos ver de cada um deles. Para os script-kiddies e trolls, iremos presumir que estes irão usar ferramentas do tier-1 dado que este tipo de atacante não é técnico e em geral não muito disposto a se utilizar de técnicas trabalhosas para seus objetivos. No caso de criminosos independentes, podemos presumir que estes terão acesso até no máximo ferramentas de tier 2, dado que também não são particularmente técnicos e não detém recursos ou conhecimento para se utilizarem das ferramentas de tier 3. Já os Hackativistas, crime organizado e mercenários detém em geral capacidade técnica alta, recursos e incentivos para se utilizarem de ferramentas do estado da arte como as do tier 3, os colocando no nível mais capaz em termos de potencial ofensivo.

Com isto esclarecido, conseguimos responder algumas das perguntas que nos propusemos no início deste artigo que são: quem irá nos atacar, com o que podem nos atacar e o que querem. No entanto, falta à nossa análise entender ainda como irão nos atacar e identificar a potencial criticidade e probabilidade de certos ataques ocorrerem.

Pensando como o atacante

Nesta seção tentaremos responder às perguntas que nos faltam para concluir a nossa análise. Para isso, tentaremos pensar como cada um dos agentes atacantes e imaginaremos cenários possíveis de ataque, tentando detalhá-los o máximo possível, seguindo aproximadamente a lógica de uma Kill-Chain. Para contextualizar, “Kill-Chain” é o termo que se usa para explicar o processo que um atacante segue desde a identificação de um alvo até a exploração ativa de uma vulnerabilidade em um ataque. Na imagem abaixo, temos a ilustração do que seria uma “Kill-Chain” em um ataque genérico à sistemas de TI, o qual usaremos como referência para nosso cenário.

Figura 4 – Diagrama de Killchain padrão, Fonte: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

Dado que queremos manter este artigo o mais breve possível, iremos só exemplificar um único ataque potencial e demonstrar como classificá-lo e entendê-lo na nossa matriz de ataques. No entanto, é importante notar que o mesmo processo de pensamento pode ser estendido para outros ataques.

No cenário de nossa análise, temos um troll que deseja fazer com que a IA de nosso chatbot diga frases inapropriadas, como por exemplo, de conteúdo NSFW. Tendo em vista este objetivo de nosso agente malicioso, iremos pensar como ele e criar uma “Kill-Chain” para este ataque.

Dado o perfil do atacante e seu objetivo, podemos presumir que a técnica que será utilizada é a de prompt injection via áudio, uma técnica que de acordo com nossa avaliação prévia é classificada como tier 1. Ou seja, nosso atacante tentará injetar comandos em nossa IA a fim de realizar um “jailbreak” para que esta tenha o comportamento inapropriado.

Pensando na “Kill-Chain”, iremos tentar agora enxergar como será o modus operandi de nosso adversário. Para isso, vamos agora nos colocar no lugar do agente malicioso e imaginar como realizaríamos este ataque. O primeiro passo de qualquer ataque é o reconhecimento. Em nosso cenário, o que provavelmente seria o mais lógico presumir é que o atacante irá realizar algumas pesquisas rápidas, buscando coletar por meio de OSINT (open source intelligence), pistas sobre o modelo que utilizamos por trás de nossa interface, potenciais vulnerabilidades comumente vistas em LLMs para prompt injection e montará alguns ataques básicos no mais simples modo “copia e cola”.  Para a etapa de “weaponization”, iremos imaginar que nosso atacante irá gravar um áudio que contém algum mecanismo existente de prompt injection de acordo com o que ele encontrou previamente disponível em informações públicas. Dado que estamos tratando de uma interface pública, a etapa de “delivery” se trata tão somente do envio deste áudio malicioso para o chatbot que faz a interface com o usuário, não envolvendo nenhum passo complexo envolvido. Com esse áudio malicioso recebido pela IA, vamos para uma etapa de “exploitation”, onde o atacante agora irá explorar a vulnerabilidade do prompt injection para fazer com que a IA responda de maneira inadequada. Com isto feito, o atacante completou com sucesso o objetivo inicial que era fazer com que a IA respondesse de maneira inadequada ao usuário. Tendo isto em consideração, podemos ignorar as outras etapas no processo de “Kill-Chain” e, portanto, podemos ir para o próximo passo de nossa análise que é classificar este ataque.

Como pudemos observar, este ataque poderia ser feito sem muito conhecimento técnico, dado as ferramentas envolvidas, além disto, dado a popularidade de práticas de prompt-injection e viralização de ataques do gênero, podemos presumir que a probabilidade deste acontecer é alta. No entanto, este tipo de ataque não apresenta um risco institucional muito grande ao pensarmos que se trata de um troll simplesmente tentando fazer a IA falar uma besteira, portanto, podemos classificá-lo como um ataque de baixa criticidade. Com isso em mente, podemos posicionar este ataque em nossa matriz de ataques do seguinte modo:

Figura 5 – Diagrama de Probabilidade x Criticidade onde o ponto azul representa este ataque em nossa matriz

Basicamente, um típico ataque de baixo risco. Boas chances de acontecer, no entanto, nada muito grave em termos de criticidade.

Hora da defesa

Como nossa final etapa na modelagem de vulnerabilidades, iremos agora pensar como iremos nos defender dos ataques. Para demonstrar esta etapa, iremos partir do caso descrito no tópico anterior, onde mapeamos um ataque de injection via áudio por parte de um troll.

Quando pensamos em defesas, nem sempre conseguimos impedir diretamente o atacante detectando todas suas ações de maneira bem-sucedida. Tendo isto em vista, o principal objetivo das defesas é mitigar o máximo que pudermos as consequências de um potencial ataque que passe desapercebido por defesas ativas e que façamos do trabalho do atacante o mais difícil possível a ponto de fazer com que o custo de um ataque seja tão alto, que os ganhos não o justifiquem a tentativa.

Revendo a Kill-Chain proposta, podemos imaginar alguns pontos para mitigação e bloqueio do ataque. A primeira mitigação possível se encontra na camada de “reconhecimento” da cadeia de ataque. Nesta etapa, idealmente devemos reduzir ao máximo possível fontes de OSINT que possibilitem a identificação dos modelos utilizados internamente pela instituição, evitando que atacantes detenham algum conhecimento que facilite o ataque. Isto pode fornecer um “edge” defensivo dado que qualquer ataque sem conhecimento apropriado do sistema, se torna consideravelmente mais difícil. O segundo passo que podemos pensar em uma mitigação é impor rate-limits. Se presumirmos que o atacante precise de sucessivas tentativas, podemos diferenciá-lo do tráfego normal de usuários se utilizando da plataforma, permitindo assim que por meio de rate-limits dificultemos a execução bem-sucedida do ataque ou neste cenário, geremos impedimentos o suficiente para que este agente desista do ataque. A última linha de defesa para nosso cenário seriam os guard-rails de modelos e detecção ativa, estes que por sua vez são modelos de IA que devem detectar potenciais injections e bloquear estes de alcançarem a IA conversacional e impedir que caso a detecção na etapa de envio por parte do usuário falhe, que a IA responda de maneira nociva à injeção, regulando também os outputs da IA conversacional.

Conclusão

Finalmente, com todos os passos concluídos, conseguimos com sucesso modelar potenciais ameaças ao nosso sistema, respondendo todas as perguntas que nos fizemos inicialmente com sucesso e com isso, conseguimos pensar em defesas contra-ataques potenciais ao nosso sistema. Assim como neste artigo, encorajamos para suas análises que adapte os métodos utilizados de acordo com o que couber em seu contexto em específico. O principal que devemos nos atentar é as perguntas que queremos responder e não às metodologias específicas ou frameworks.

Espero que este artigo seja de grande utilidade para suas modelagens de ameaça e que nosso pequeno experimento lhe sirva de referência para o futuro na construção de defesas ainda mais poderosas!

Referências

[1] LOCKHEED MARTIN. The cyber kill chain. Disponível em: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

Acesso em: 31 mar. 2026.

[2] OWASP FOUNDATION. Threat modeling cheat sheet. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html

Acesso em: 31 mar. 2026.

[3] OWASP FOUNDATION. Threat modeling process. Disponível em: https://owasp.org/www-community/Threat_Modeling_Process

Acesso em: 31 mar. 2026.

[4] IBM. What is a threat actor? Disponível em: https://www.ibm.com/think/topics/threat-actor

Acesso em: 31 mar. 2026.

[5] IBM. Prompt injection. Disponível em: <https://www.ibm.com/br-pt/think/topics/prompt-injection>.

Acesso em: 31 mar. 2026.

Victor Leme Beltran é engenheiro de machine learning especializado em computação quântica no ICTi, engenheiro da computação por formação.