PWN-ALL · Cibersegurança e desenvolvimento de software

A PWN-ALL oferece quatro áreas de atuação interligadas: testes de penetração e simulação de ataques; resposta a incidentes e análise forense digital; engenharia de software segura em Rust e Python; e consultoria de segurança independente de fornecedores. Cada projeto tem um âmbito definido por escrito, resultados concretos e critérios de aceitação acordados.

Sim. A PWN-ALL Auditing, Reviewing & Testing Cyber Risks CO. L.L.C é uma empresa sediada no Dubai, nos Emirados Árabes Unidos, fundada em 2024 e que opera ao abrigo da licença n.º 1324553 do DET do Dubai. A empresa possui ainda os códigos D-U-N-S 571235572 e NCAGE 10G8W.

Trabalhamos principalmente com empresas, organizações governamentais e plataformas de elevado valor em todo o mundo. Os projetos podem ser realizados remotamente em diferentes jurisdições, com comunicação disponível em mais de 20 idiomas; quaisquer requisitos legais, probatórios ou relativos ao tratamento de dados específicos de cada localidade são acordados durante a definição do âmbito do projeto.

Sim. Podemos assinar um acordo de confidencialidade (NDA) antes de partilharmos informações sensíveis e utilizar o Signal, e-mail encriptado com PGP ou outro canal aprovado pelo cliente. O acesso às informações do cliente é gerido com base no princípio da necessidade de saber, de acordo com os controlos acordados para o projeto.

Comece por definir o resultado pretendido, o serviço ou os ativos envolvidos, a urgência, os prazos e quaisquer restrições operacionais ou regulamentares; não envie informações confidenciais antes de terem sido celebrados um acordo de confidencialidade (NDA) e de ter sido estabelecido um canal seguro. Em seguida, confirmamos por escrito o âmbito, as exclusões, a autorização, as regras de intervenção, os resultados esperados, os critérios de aceitação, os contactos e o calendário.

Os testes de penetração planeados podem, normalmente, ter início no prazo de 3 a 5 dias úteis após a definição do âmbito e a autorização por escrito, dependendo da disponibilidade do momento. Os incidentes ativos seguem um processo de resposta distinto, disponível 24 horas por dia, 7 dias por semana; por isso, qualquer emergência deve ser comunicada imediatamente por telefone ou através de um canal de mensagens seguro.

O preço depende dos ativos, da complexidade, dos prazos, do risco, dos requisitos em termos de provas e dos resultados a entregar. Após a definição do âmbito do projeto, receberá uma proposta por escrito; estão disponíveis opções de preço fixo para trabalhos claramente definidos, as condições de pagamento são estabelecidas no contrato e, no caso de projetos de maior dimensão, poderão ser discutidas garantias bancárias.

Os âmbitos autorizados podem incluir aplicações web, APIs, redes externas e internas, o Active Directory, ambientes na nuvem e aplicações móveis. As intervenções mais abrangentes da equipa vermelha também podem testar controlos de identidade, de pessoal e físicos, desde que essas atividades sejam explicitamente autorizadas.

Não. As ferramentas automatizadas podem contribuir para a cobertura, mas o processo é liderado por profissionais que mapeiam vias de ataque, testam a lógica de negócio, validam a vulnerabilidade e avaliam o impacto realista. O resultado são evidências e medidas corretivas priorizadas, e não um relatório de análise não verificado.

Os testes seguem práticas alinhadas com as diretrizes da OWASP e do PTES, ao longo de cinco fases: definição do âmbito e regras de intervenção, reconhecimento e mapeamento da superfície de ataque, exploração segura, elaboração de relatórios em duas fases e repetição dos testes. Os casos de teste específicos são adaptados aos ativos e ao modelo de ameaças acordados.

Testamos apenas os recursos abrangidos por uma autorização por escrito e pelas regras de intervenção acordadas. O cliente deve ser o proprietário dos sistemas ou ter autorização do proprietário ou fornecedor em questão; os recursos de terceiros, a engenharia social, o acesso físico e as ações destrutivas ficam fora do âmbito do teste, a menos que sejam especificamente aprovados.

O trabalho foi concebido para minimizar as perturbações, mas os testes nunca podem ser isentos de riscos. As janelas de ataque, os limites de taxa, as exclusões de sistemas críticos, os contactos de escalonamento, as condições de interrupção e os planos de reversão são acordados antecipadamente, e não são realizados testes destrutivos sem aprovação explícita.

A duração depende do âmbito, do acesso, da complexidade e das necessidades de repetição dos testes. A página do serviço apresenta valores indicativos iniciais de cerca de duas semanas para testes web e de API, três semanas para testes de rede e seis semanas para um exercício de «red team»; a proposta apresenta o calendário efetivo.

Recebe um resumo executivo destinado à liderança, bem como conclusões técnicas para os engenheiros, incluindo evidências, ativos afetados, impacto realista, gravidade e orientações de correção por ordem de prioridade. O âmbito final pode também definir reuniões de balanço, workshops de correção ou formatos de evidência necessários às partes interessadas internas.

Sim, o reexame das falhas corrigidas, conforme acordado, está incluído no fluxo de trabalho padrão dos testes de penetração. A proposta regista o período previsto para o reexame, as falhas elegíveis, o acesso necessário e a forma como as correções verificadas serão refletidas no relatório final.

Não. Um teste de penetração é uma avaliação com duração limitada do âmbito autorizado e não pode provar que não existe nenhuma vulnerabilidade. Reduz a incerteza e fornece prioridades baseadas em evidências, mas a segurança continua a depender das medidas corretivas, das operações, da monitorização e de alterações futuras.

Sim. O serviço de resposta a incidentes, disponível 24 horas por dia, 7 dias por semana, encarrega-se da contenção, da preservação de provas, da avaliação forense, da erradicação, da recuperação e do reforço de segurança pós-incidente. No caso de um incidente em curso, ligue ou utilize o Signal imediatamente e evite enviar provas sensíveis através de um canal não aprovado.

Não. A área de DFIR também lida com roubo de dados e extorsão sem encriptação, comprometimento de e-mail empresarial e fraude nos pagamentos, apropriação de contas, comprometimento do Microsoft 365, do Google Workspace e da nuvem, casos envolvendo colaboradores e aplicações web ou servidores comprometidos.

Isole os equipamentos afetados da rede sem os desligar, preserve as provas voláteis, proteja as cópias de segurança contra qualquer acesso posterior, registe as ações realizadas e estabeleça um canal de resposta. Não proceda a reinicializações generalizadas, apagações, restaurações, descodificações nem negociações antes de o responsável pelo incidente e as partes interessadas do ponto de vista jurídico ou dos seguros chegarem a acordo sobre um plano.

O serviço de incidentes dispõe de uma ponte de resposta disponível 24 horas por dia, 7 dias por semana. O nível de serviço declarado é inferior a 60 minutos desde a primeira chamada até um analista se juntar à ponte partilhada, com orientações iniciais de contenção a começarem durante a triagem; o tempo real de contenção depende do acesso, do âmbito do incidente e da capacidade do cliente para executar as ações necessárias.

Normalmente, sim, embora o desligamento possa destruir provas voláteis, tais como chaves residentes na memória, processos injetados e ligações ativas. Não volte a ligar os sistemas; preserve o seu estado atual e contacte a equipa de resposta para que se possa planear a triagem a frio e outras fontes de provas.

Não. A recuperação depende da família do ransomware, das chaves ou descriptografadores disponíveis, da qualidade das provas, da integridade das cópias de segurança, do estado do sistema, das restrições legais e do nível de atividade que ocorreu após a infeção. Avaliamos cópias de segurança não afetadas, reconstruções, investigação de descriptografadores e opções de recuperação de chaves, para depois indicar o que é e o que não é recuperável.

O pagamento não deve ser a primeira resposta e não garante a recuperação nem a eliminação dos dados roubados. As opções de recuperação e as provas devem ser avaliadas em primeiro lugar; qualquer comunicação com o operador ou decisão relativa ao pagamento deve envolver o cliente, o consultor jurídico, a seguradora, quando aplicável, e a autorização relativa a sanções.

Dependendo do âmbito, os resultados finais podem incluir um registo de provas e da cadeia de custódia, um cronograma de resposta, conclusões sobre a causa principal e o acesso inicial, análise do movimento lateral e da exfiltração, indicadores de comprometimento, prioridades de recuperação e um relatório pronto para apresentação à seguradora ou à entidade reguladora, acompanhado de um plano de reforço da segurança. As conclusões continuam a ser limitadas pelas provas preservadas e pelo processo de custódia mantido.

Desenvolvemos back-ends seguros em Rust e Python, APIs, sistemas de dados, automação, integrações de IA, migrações e serviços de produção críticos em termos de segurança. A mesma equipa de engenharia também cria coletores forenses específicos para incidentes, analisadores sintáticos, geradores de cronologias, scanners de IOC ou YARA e ferramentas de investigação para descodificação ou recuperação de chaves.

O Rust é utilizado em contextos em que a segurança da memória, a concorrência, o desempenho previsível e o controlo de baixo nível são importantes; o Python é utilizado em contextos em que a rapidez de implementação, os dados, a aprendizagem automática, a orquestração e as integrações são importantes. O trabalho de arquitetura atribui a linguagem a cada componente, em vez de obrigar todo o sistema a utilizar uma única pilha.

O modelo de entrega passa pelas fases de análise, arquitetura, implementação, reforço da segurança e entrega, com testes de aceitação e de desempenho acordados para o projeto. A entrega pode incluir código-fonte, recursos de implementação, contratos de API, decisões de arquitetura, manuais operacionais, diagramas, transferência de conhecimentos e apoio pós-lançamento durante 30 dias, caso tal esteja previsto no contrato.

A consultoria abrange a arquitetura de segurança, a avaliação de riscos centrada no negócio, a preparação para o RGPD, a preparação para auditorias, políticas e processos de resposta a incidentes, a integração do desenvolvimento seguro e a formação específica para cada função. Os resultados típicos incluem conclusões ordenadas por prioridade, um registo de riscos com os responsáveis, um plano de ação para o reforço da segurança, manuais operacionais e um conjunto de provas pronto para auditoria.

Não. A preparação para a conformidade consiste em apoio técnico e operacional, não em aconselhamento jurídico nem numa garantia de certificação; as conclusões forenses dependem das provas preservadas; a recuperação depende das condições do incidente; e os testes de segurança não podem provar a ausência de vulnerabilidades. Cada proposta define um conjunto de tarefas mensuráveis e critérios de aceitação, sem prometer resultados que estejam fora do controlo da PWN-ALL.

O PWN-ALL apresenta o «Dark-Web and Leak Monitor», a deteção de bots «BotGuard» e o «Vulnerability Scan Hub» como produtos separados. Além disso, disponibiliza mais de 20 ferramentas gratuitas baseadas no navegador para tarefas como hash, geração de chaves, esteganografia, identificação de ransomware e visualização de ficheiros ou análise forense; as ferramentas identificadas como do lado do cliente são executadas localmente no navegador, sem que os dados processados sejam enviados para o servidor.

Redefina a palavra-passe da conta afetada a partir de um dispositivo que se saiba estar limpo, em vez de utilizar o dispositivo comprometido; termine a sessão e revogue todas as sessões ativas; remova quaisquer palavras-passe de aplicações ou acessos de aplicações ligadas; e ative a autenticação multifator. Preserve a caixa de correio juntamente com os registos de início de sessão e de auditoria e verifique se existem regras ocultas de reencaminhamento ou da caixa de entrada, mas não elimine mensagens, regras ou a conta, pois constituem provas. Se o comprometimento ainda estiver ativo ou se envolver qualquer movimento de fundos, ligue ou utilize o Signal para contactar a linha disponível 24 horas por dia, 7 dias por semana, em vez de esperar pelo chat. A equipa de DFIR trata de casos relacionados com o Microsoft 365, o Google Workspace e a apropriação de contas de ponta a ponta, desde a contenção até à identificação da causa raiz e ao reforço de segurança.

Trata-se de um incidente ativo de comprometimento de e-mail empresarial e fraude de pagamentos, pelo que a rapidez é fundamental — contacte imediatamente o seu banco e o banco destinatário para tentar anular ou congelar a transferência e comunique o caso às autoridades competentes. Contacte-nos através da linha disponível 24 horas por dia, 7 dias por semana, em vez de esperar pelo chat, especialmente enquanto os fundos ainda possam estar em trânsito. A nossa equipa de DFIR investigará então como a caixa de correio ou a conta foi acedida, se os dados de faturação ou bancários foram alterados e que outros elementos foram afetados, preservando simultaneamente as provas para o seu banco, seguradora e qualquer entidade reguladora. Mantenha os e-mails e os registos da conta intactos e evite apagar seja o que for, para que o panorama forense permaneça completo.

Trata-se de roubo de dados e extorsão sem encriptação, e enquadra-se perfeitamente no âmbito de atuação da equipa de DFIR, apesar de não ter sido utilizado qualquer ransomware. A prioridade é preservar as provas, determinar o âmbito do que foi efetivamente acedido e exfiltrado, conter a via de acesso e compreender a alegação antes de alguém responder ao autor da ameaça. Não pague, não negocie nem responda à exigência antes de o responsável pelo incidente e as partes interessadas das áreas jurídica e de seguros chegarem a acordo sobre uma estratégia. Comunique o incidente através da linha disponível 24 horas por dia, 7 dias por semana, e partilhe as mensagens de ameaça através de um canal seguro, em vez de um canal público ou não aprovado.

Quando existem indicadores ou suspeitas, mas nenhum incidente confirmado, a equipa de DFIR pode analisar os seus registos, terminais e dados na nuvem e de identidade para determinar se há indícios de intrusão atual ou passada, persistência ou acesso não autorizado aos dados. Em seguida, informa se existem sinais de comprometimento e quais os próximos passos a tomar; caso seja detetada uma atividade maliciosa evidente, passa a uma intervenção completa de resposta a incidentes, incluindo contenção e análise forense. Enquanto essa avaliação estiver em curso, preserve os registos existentes e evite reinstalar o sistema operativo ou apagar os sistemas, uma vez que isso pode eliminar as provas necessárias para responder à questão. Se estiver a assistir a um ataque a decorrer ativamente, ligue para a nossa linha disponível 24 horas por dia, 7 dias por semana, ou contacte-nos imediatamente através do Signal, em vez de esperar pelo chat.

Cada resposta inclui medidas de reforço de segurança pós-incidente, assim que a ameaça imediata for resolvida. Com base nas conclusões sobre a causa raiz e o acesso inicial, a equipa apresenta-lhe um plano de reforço de segurança priorizado que colmata as lacunas específicas que o atacante explorou e reduz as vias para que tal se repita. Para um trabalho mais aprofundado e contínuo, a equipa de consultoria pode transformar isso num registo de riscos com responsáveis, políticas atualizadas e manuais de resposta a incidentes, bem como formação específica para cada função, enquanto a equipa de engenharia pode desenvolver as ferramentas necessárias para as correções. O reforço da segurança reduz o risco e melhora a resiliência, mas nenhum prestador de serviços pode prometer que um incidente futuro seja impossível.

Restaurar o serviço é importante, mas isso não revela como o atacante conseguiu entrar, se ainda se encontra no sistema ou a que dados teve acesso; além disso, a restauração pode sobrescrever as provas relativas a estes três aspetos. Se a via de acesso inicial e qualquer mecanismo de persistência não forem identificados e eliminados, a mesma intrusão pode repetir-se após a recuperação. Vale a pena que a equipa de DFIR identifique a causa raiz, verifique se ainda existe acesso remanescente e confirme o que foi exfiltrado; em seguida, deve aplicar medidas de reforço de segurança específicas — e preservar quaisquer registos, imagens ou suportes afetados que ainda existam, em vez de os descartar. Se não tiver a certeza de que a ameaça desapareceu por completo, trate-a como ativa e comunique-a através da linha disponível 24 horas por dia, 7 dias por semana.

Os sistemas existentes estão claramente abrangidos pelo âmbito de atuação; a equipa de engenharia dedica-se regularmente a migrações, reforço de segurança e serviços de produção críticos em termos de segurança, em vez de se limitar apenas a construções totalmente novas. Um projeto começa com uma fase de descoberta para determinar como o código, os dados e os limites de confiança atuais funcionam na prática antes de qualquer alteração ser efetuada, seguida da definição da arquitetura, da implementação e de uma etapa dedicada ao reforço de segurança. Quando a necessidade principal é uma avaliação de segurança do código de uma aplicação existente, esta é realizada através de testes de penetração da aplicação e da integração de desenvolvimento seguro da consultoria, sendo que a combinação adequada é definida durante a conversa inicial.

É possível assumir sistemas herdados, parcialmente construídos ou paralisados, mas o trabalho começa sempre com uma fase de descoberta que determina o estado real atual — o que existe, o que funciona e onde se encontram os riscos e as lacunas — antes de se definir qualquer abordagem. A partir daí, o modelo padrão aplica-se ao longo da arquitetura, implementação, reforço de segurança e entrega, cada uma delas regida por uma Declaração de Trabalho escrita com critérios de aceitação acordados, em vez de uma promessa aberta de resolver tudo. O que é realisticamente exequível, e em que ordem, é definido assim que o estado atual for compreendido.

A integração da IA e dos LLM faz parte explícita da engenharia em Rust e Python, sendo concebida com segurança desde a conceção através do mesmo fluxo de descoberta, arquitetura, implementação e reforço de segurança, com testes de segurança e de aceitação previamente acordados. Os riscos específicos das funcionalidades dos LLM, tais como a entrada de dados não fiáveis no modelo, a exposição de dados sensíveis, aquilo a que o modelo está autorizado a aceder e os controlos contra abusos ou custos descontrolados, são definidos no âmbito do projeto e abordados como parte integrante desse trabalho, em vez de serem acrescentados posteriormente. Tal como em qualquer trabalho de segurança, o projeto define controlos mensuráveis e critérios de aceitação, em vez de garantir que um sistema não possa ser utilizado indevidamente.

Não fica apenas com código em bruto — a entrega está concebida para ser implementada e operada no seu ambiente, podendo incluir recursos de implementação, contratos de API, decisões de arquitetura, manuais de operações, diagramas e transferência de conhecimentos, com apoio pós-lançamento de 30 dias, caso tal esteja previsto no contrato. Uma vez que o trabalho se destina a uma utilização em produção com requisitos críticos de segurança, é realizada uma etapa dedicada de reforço de segurança antes da entrega. Quem, exatamente, executa e opera a implementação é acordado para cada projeto na Declaração de Trabalho.

A integração da segurança na forma como uma equipa já desenvolve software é concretizada através da integração de desenvolvimento seguro da consultoria, que tem um caráter consultivo: analisar onde a segurança se enquadra no seu fluxo de trabalho existente, definir as verificações e as medidas de proteção que nele devem ser incluídas e fornecer aos programadores orientações específicas para cada função. Nos casos em que esse processo necessite de automação personalizada ou da criação de ferramentas, por exemplo, scanners ou verificações personalizados, a equipa de engenharia pode implementá-lo num âmbito separado. A consultoria aconselha e define o processo, mas não desenvolve software; por isso, tudo o que tenha de ser criado é considerado um produto de engenharia.

O Rust e o Python constituem o núcleo: o Rust nos casos em que a segurança da memória, a concorrência e o desempenho previsível são importantes, e o Python nos casos em que a rapidez de implementação, os dados, a aprendizagem automática e as integrações são importantes. O trabalho de arquitetura atribui a linguagem a cada componente, em vez de forçar todo o sistema a utilizar uma única pilha, e os sistemas existentes e as migrações estão abrangidos, pelo que a escolha é decidida com base nos seus requisitos durante a definição do âmbito do projeto.

A consultoria inclui a preparação para o RGPD e a preparação para a auditoria: uma avaliação das lacunas, os controlos e as políticas para as colmatar e um conjunto de provas pronto para a auditoria, fornecido de forma independente de fornecedores. Trata-se de apoio à preparação e à adequação, não de aconselhamento jurídico, e, por si só, não garante a conformidade nem a certificação — estas dependem das suas operações e do organismo de avaliação. Os resultados consistem em conclusões priorizadas, um registo de riscos com os responsáveis e um plano de ação para reforçar a segurança que pode ser posto em prática.

A formação em segurança específica para cada função faz parte da consultoria, adaptada à sua pilha de tecnologias, aos seus riscos e às funções que dela necessitam. Normalmente, é combinada com o trabalho de consultoria associado — integração de desenvolvimento seguro, políticas e processos de resposta a incidentes — para que a formação reflita a forma como as suas equipas realmente desenvolvem e operam. Tal como em toda a consultoria, o âmbito e os resultados são acordados antecipadamente.

A análise da arquitetura de segurança, ou de um projeto de sistema proposto antes do seu lançamento, constitui uma parte essencial da nossa atividade de consultoria. Avaliamos o projeto à luz dos riscos do seu negócio e das restrições operacionais e, em seguida, apresentamos conclusões ordenadas por prioridade, um plano de reforço da segurança e, quando útil, manuais de procedimentos e um registo de riscos com responsáveis designados. Uma vez que esta atividade é independente de fornecedores, as recomendações baseiam-se nos seus riscos e não em qualquer produto que possamos vir a vender.

A diferença reside no âmbito: a consultoria consiste num trabalho de aconselhamento independente de fornecedores que avalia riscos, analisa a arquitetura e prepara a empresa para auditorias, mas não desenvolve software nem gere respostas a incidentes de emergência. Se precisar de código escrito ou de um sistema desenvolvido, trata-se da engenharia de software segura; se estiver a ocorrer um ataque, trata-se do processo de resposta a incidentes 24 horas por dia, 7 dias por semana; e se precisar que sejam identificadas vulnerabilidades e exploradas com segurança, mediante autorização, trata-se de testes de penetração. Iremos encaminhá-lo para o serviço adequado, ou combinar vários, com base no resultado de que necessita.

Pode contactar-nos por e-mail (PGP disponível), Signal, Telegram em t.me/pwn_all, WhatsApp ou por telefone através do número +971 58 594 6337; existe ainda uma linha disponível 24 horas por dia, 7 dias por semana, para incidentes ativos. Para qualquer assunto sensível, recomendamos o Signal ou e-mail encriptado com PGP, e pedimos que não envie informações confidenciais ou credenciais antes de terem sido celebrados um acordo de confidencialidade (NDA) e estabelecido um canal seguro. Se tiver um incidente em curso, ligue ou utilize o Signal imediatamente, em vez de esperar pelo chat.

O acesso às suas informações é gerido com base no princípio da necessidade de saber, de acordo com os controlos acordados para o projeto, estando em vigor um acordo de confidencialidade (NDA) e um canal seguro antes de quaisquer detalhes sensíveis serem partilhados. Os termos específicos relativos ao tratamento, armazenamento e retenção são definidos no âmbito desse acordo, em vez de se basearem num modelo padrão único, e solicitamos que não envie informações confidenciais antes de esses termos estarem em vigor. Para qualquer informação sensível, o Signal ou o e-mail encriptado com PGP são os canais recomendados.

A prova que publicamos são as cartas de referência assinadas apresentadas na secção de referências do site, que pode consultar diretamente. Uma vez que a confidencialidade é prioritária, não descrevemos clientes ou incidentes específicos para além disso, e quaisquer detalhes adicionais só podem ser partilhados com a autorização do cliente em questão e ao abrigo de um acordo de confidencialidade (NDA). Também podemos apresentar, durante uma chamada, exemplos ilustrativos e não atribuídos de como decorre um projeto típico.

Não, o site e este chat têm caráter informativo e não constituem um contrato. Cada projeto é regido por uma Declaração de Trabalho assinada que define o âmbito, as exclusões, a autorização, as regras de intervenção, os resultados esperados, os critérios de aceitação, os contactos e o calendário, sendo os preços confirmados numa proposta por escrito após a definição do âmbito. Nenhuma informação confidencial deve ser partilhada até que estejam em vigor um acordo de confidencialidade (NDA) e um canal seguro.

Um projeto típico de segurança na Web ou de API começa com a definição do âmbito, as regras de intervenção e a autorização por escrito, passando depois pela fase de reconhecimento e mapeamento da superfície de ataque, pela exploração segura dos alvos acordados, pela elaboração de relatórios em dois níveis e por um novo teste das vulnerabilidades corrigidas. Os profissionais mapeiam manualmente as vias de ataque e validam a explorabilidade, em vez de apresentarem apenas os dados brutos exportados pelo scanner; assim, recebe um resumo executivo para a direção, conclusões técnicas com evidências e classificação de gravidade, e orientações de correção priorizadas. A página do serviço apresenta um prazo inicial indicativo de cerca de duas semanas para trabalhos relacionados com a Web e APIs, sendo que o calendário efetivo e o âmbito elegível para o novo teste são definidos na proposta. Trata-se de um esboço ilustrativo; os casos de teste exatos são adaptados aos ativos autorizados e ao modelo de ameaças.

Um caso típico inicia-se na ponte de resposta 24/7 com a contenção e a preservação de provas, seguindo-se uma análise forense para determinar a causa raiz, o acesso inicial, o movimento lateral e quais os dados que foram exfiltrados. A recuperação é planeada com base no que as provas sustentam — cópias de segurança limpas, reconstruções e, quando relevante, investigação de descriptografadores e opções de recuperação de chaves —, com o cliente, o consultor jurídico e a seguradora envolvidos em qualquer decisão relativa a pagamentos ou negociações. Recebe um registo da cadeia de custódia, um cronograma de resposta, indicadores de comprometimento, prioridades de recuperação e um relatório pronto para a seguradora ou entidade reguladora, incluindo um plano de reforço de segurança. Trata-se de um esboço ilustrativo; o que é recuperável depende da família do ransomware, das chaves, das cópias de segurança e das provas, e nada é garantido.

Um projeto típico passa pelas fases de descoberta, arquitetura, implementação, reforço de segurança e entrega, com os testes de aceitação e de desempenho acordados para o projeto desde o início. A linguagem de programação é escolhida consoante o componente — Rust quando a segurança e o desempenho são importantes, Python quando a velocidade, os dados e as integrações são importantes — e a segurança é incorporada desde o início, em vez de ser adicionada no final. A entrega pode incluir código-fonte, recursos de implementação, contratos de API, decisões de arquitetura, manuais de operações, diagramas e transferência de conhecimento, com apoio pós-lançamento de 30 dias, caso tal esteja previsto no contrato. Trata-se de um esboço ilustrativo; o âmbito exato e os critérios de aceitação são definidos na Declaração de Trabalho.