Instaladores do ScreenConnect trojan evoluem, deixando várias RATs em uma única máquina

Autores: Ilia Dafchev, Eliad Kimhy

• Aumento do abuso do ScreenConnect: desde março de 2025, a Acronis TRU observou um aumento nos ataques que utilizam instaladores do ScreenConnect da ConnectWise trojanizados para obter acesso inicial a organizações dos EUA. O que estamos vendo é uma tendência de longo prazo e contínua de abuso de ferramentas de RMM que continua a atrair atacantes, talvez devido à sua eficácia.

• Instaladores ClickOnce evasivos: os atacantes agora utilizam um instalador de execução ClickOnce para ScreenConnect, que não possui configuração incorporada e, em vez disso, busca componentes em tempo de execução. Essa evolução torna os métodos tradicionais de detecção estática menos eficazes e complica a prevenção, deixando os defensores com poucas opções confiáveis.

• Implantação automatizada de dois RATs: imediatamente após a instalação do ScreenConnect, os atacantes utilizam seus recursos de automação para implantar rapidamente dois trojans de acesso remoto: o bem conhecido AsyncRAT e um RAT personalizado, baseado em PowerShell. Essa implantação dupla pode servir como redundância, teste de ferramenta ou refletir a infraestrutura compartilhada entre vários atores de ameaças.

• RAT do PowerShell personalizado: a equipe da TRU descobriu um novo RAT caseiro, não visto em repositórios de código aberto, que realiza reconhecimento de sistema, exfiltra dados via Microsoft.XMLHTTP e utiliza várias técnicas de ofuscação. Sua base de código exclusiva sugere que foi desenvolvida pelo atacante, potencialmente para evitar a detecção baseada em assinaturas.

• Evolução das cadeias de infecção: duas semanas após a violação, os atacantes fizeram upgrade de sua cadeia de infecção para usar carregadores de lotes e VBS que buscam e executam assemblies .NET codificados para implantar o AsyncRAT, demonstrando adaptabilidade e evolução da infraestrutura.

• Engenharia social e reutilização de infraestrutura: instaladores maliciosos são distribuídos com nomes de arquivos que imitam documentos oficiais ou financeiros, provavelmente via phishing. Os agentes de ameaças também reutilizam VMs do Windows Server 2022 pré-configuradas (com nomes de host consistentes) em várias campanhas, o que permite a rápida redistribuição e rotação da infraestrutura.

• Medidas defensivas: as organizações devem monitorar de perto o uso de ferramentas RMM e analisar as implantações do ScreenConnect.

Nos últimos meses, a Unidade de Pesquisa de Ameaças (TRU) da Acronis identificou várias campanhas ativas e em andamento que utilizam versões trojanizadas do ConnectWise ScreenConnect para obter acesso inicial a redes de vítimas e comprometer máquinas de destino. Nossas pesquisas mostram que a frequência dessas campanhas aumentou desde março de 2025 e, no momento, a maioria das empresas vítimas está nos Estados Unidos, embora atualmente não haja indicação de onde os atores de ameaças estão baseados.

Embora o uso do ConnectWise ScreenConnect para estabelecer uma presença inicial não seja um fenômeno novo, essas campanhas recentes introduzem várias mudanças, como a implantação de instaladores menores do tipo ClickOnce Runner em vez dos instaladores completos. Esses instaladores ClickOnce são mais evasivos do que os instaladores observados anteriormente, pois não dependem mais de configurações incorporadas, o que, por sua vez, oferece menos oportunidades para detecção. Uma vez instalado, os atacantes conseguem controlar a máquina comprometida, o que lhes permite instalar malware adicional, roubar informações, estabelecer persistência e se mover lateralmente pela rede.

O abuso de software de RMM (monitoramento e gerenciamento remotos) como o ScreenConnect está se tornando cada vez mais comum, aumentando a lista crescente de ferramentas legítimas que são reutilizadas para atividades maliciosas. Nesses tipos de ataques, os instaladores do ScreenConnect são frequentemente assinados e aparecem como aplicativos confiáveis, mas concedem ao atacante um controle extensivo sobre a máquina comprometida.

As equipes de TI geralmente usam o ScreenConnect para acessar remotamente sistemas para suporte ou resposta a incidentes. Os agentes de ameaças podem transformar o software RMM em uma arma por meio de várias vias, desde a exploração de vulnerabilidades até a quebra ou o uso indevido do produto legítimo. Seja qual for o caso, o resultado final é um executável que vincula a máquina da vítima a um servidor controlado pelo atacante. Os atacantes podem esperar dias ou até semanas antes de agir, desde que o software RMM malicioso permaneça indetectável.

Esta pesquisa examina as campanhas recentes que utilizam o ScreenConnect para acesso inicial e detalha o malware implantado após a infecção. As equipes de segurança podem utilizar as descobertas e recomendações aqui apresentadas para fortalecer as defesas e neutralizar ameaças semelhantes.

O ataque começa com um executável malicioso chamado agreement_support-pdf.Client.exe, que parece ter sido baixado por meio do navegador Microsoft Edge. Este arquivo é um instalador ClickOnce, disfarçado como um documento de suporte legítimo — um método de engenharia social frequentemente utilizado para enganar os usuários e fazê-los executar código não confiável. O ataque provavelmente teve origem em uma campanha de engenharia social, provavelmente distribuída via phishing por e-mail, mas possivelmente também por outros meios.

Ao ser executado, o instalador inicia o ScreenConnect.ClientSetup.exe, que, uma vez instalado, conecta a máquina da vítima ao servidor C2 dos atacantes.

Como mencionado, esses instaladores diferem dos ataques anteriores que envolviam o ScreenConnect, pois utilizam um instalador ClickOnce Runner. Esta versão do instalador é menor e não tem a configuração incorporada. Em vez disso, ele se conecta diretamente ao servidor ScreenConnect configurado, fazendo o download dos componentes e configurações necessários para prosseguir com a instalação. Isso melhora muito a capacidade dos instaladores de se esquivarem. Em iterações anteriores desses ataques, um produto de segurança podia procurar frases específicas encontradas na configuração incorporada para detectar e interromper execuções suspeitas do ScreenConnect. No entanto, na nova versão, isso não é mais possível. As únicas duas formas de prevenção confiáveis que restam são incluir o domínio C2 em uma lista negra (o que é difícil de saber antecipadamente) ou bloquear o ScreenConnect por completo.

Pesquisadores da TRU observaram o endereço malicioso por meio dos parâmetros de instalação presentes no instalador. O instalador foi executado com os parâmetros: e=Suporte&y=Guest&h=morco[.]rovider[.]net&p=8041 que se conecta a um domínio controlado pelo atacante, morco.rovider[.]net. O domínio foi registrado recentemente e está em hosting em um servidor virtual privado (VPS) associado ao stealthrdp[.]com. Também foi observada a distribuição de outras amostras maliciosas, o que indica que o malware faz parte de uma infraestrutura de campanha de malware mais ampla.

Esse ataque abusa de um tipo de instalador local do ScreenConnect. Como as instalações locais precisam ser independentes da infraestrutura de nuvem, a ConnectWise fornece aos clientes os meios para configurar um servidor e clientes dentro de sua rede, sem depender de quaisquer componentes de nuvem. Este sistema tem dois componentes, um instalador de servidor e um instalador de cliente, e, em aplicativos legítimos, o instalador de servidor será configurado com um endereço e também poderá criar instaladores para os clientes.

Nesse ataque, os invasores provavelmente obtiveram uma versão crackeada do instalador do servidor que lhes permitiu alterar o endereço do servidor. Essa modificação permite que os atacantes criem instaladores que se conectem ao próprio servidor malicioso do ScreenConnect, enquanto parecem legítimos para os produtos de segurança. Sem o conhecimento do endereço do servidor incorporado, a detecção é difícil.

Com o ScreenConnect instalado e conectado ao servidor C2 do atacante, um padrão de ataque complexo se desenrola ao longo de aproximadamente dois meses. Pesquisadores da TRU analisaram a progressão do ataque ao longo do tempo e descobriram que o atacante implantou vários RATs simultaneamente e os utilizou de forma intercambiável. Um deles era um RAT baseado em PowerShell com funcionalidade básica, enquanto os outros eram ferramentas bem estabelecidas e amplamente utilizadas, como o AsyncRAT. Essa sobreposição torna incerto se um único atacante é responsável ou se a infraestrutura é compartilhada entre vários operadores, com a acessibilidade vendida a múltiplos indivíduos que podem não ter conhecimento uns dos outros.

Enquanto o ScreenConnect é instalado, dois payloads são descarregados em questão de minutos. Isso se deve a uma funcionalidade do ScreenConnect que permite aos administradores definir automações específicas, como a execução de um script quando o usuário se conecta ao servidor pela primeira vez. Isso permite que o invasor instale automaticamente um conjunto de diferentes RATs em questão de minutos após a instalação.

Para o seu primeiro payload malicioso, o atacante utiliza o ScreenConnect para descarregar e executar um arquivo de batch, BypaasaUpdate.bat. Esse arquivo de batch inicial atua como um downloader e stager para todos os estágios restantes da primeira infecção do payload, fazendo o download e, em seguida, extraindo um arquivo zip contendo:

• 1.txt: um arquivo de texto contendo o AsyncRAT.

• Pe.txt: um arquivo de texto contendo um mecanismo de persistência e bypass do AMSI do .NET.

• Skype.ps1: um script do PowerShell para processar e carregar os arquivos txt acima como assemblies .NET.

• b.bat: um script em lote usado para executar o script do PowerShell acima.

Com os arquivos extraídos, b.bat é chamado primeiro, o que por sua vez executa Skype.ps1. Em seguida, Skype.ps1 carrega pe.txt e 1.txt como assemblies .NET na memória.

O último, 1.txt, é o AsyncRAT, um trojan de acesso remoto (RAT) conhecido e amplamente utilizado tanto por testadores de penetração legítimos quanto por cibercriminosos, enquanto o primeiro, pe.txt, é usado para contornar o AMSI (anti-malware scan interface), permitindo que o script continue executando códigos maliciosos e também para estabelecer persistência.

A persistência é alcançada por meio da criação de um arquivo adicional chamado Microsoft.vbs, cujo único propósito é executar novamente o Skype.ps1. Em seguida, uma tarefa agendada é criada para executar o arquivo Microsoft.vbs uma única vez, um minuto no futuro. Quando a tarefa é executada, o Microsoft.vbs executa o Skype.ps1 novamente, o que por sua vez carrega o AsyncRAT e o pe.txt novamente, configurando uma nova tarefa agendada para um minuto no futuro, criando assim um mecanismo de persistência no qual o AsyncRAT é recarregado na memória a cada minuto e o mecanismo de persistência inteiro é recriado.

Embora isso signifique que Skype.ps1 tenta carregar o AsyncRAT na memória a cada minuto, 1.txt (também conhecido como AsyncRAT) verifica um mutex específico, AsyncMutex_al026, para ver se o AsyncRAT já está em execução e, se estiver, ele é encerrado. Dessa forma, o AsyncRAT não será recarregado a cada minuto, mas apenas quando não estiver em execução.

Também deve ser observado que esse mecanismo de persistência é incrivelmente barulhento. Executar um script do PowerShell a cada minuto deixa um número enorme de rastros, algo que os atacantes corrigirão em um estágio posterior do ataque.

Alguns minutos após o carregamento e a configuração do AsyncRAT, observamos a queda e a execução de outro script pelo ScreenConnect. Mas, enquanto o primeiro script deixou cair uma ferramenta bem conhecida, o AsyncRAT, o segundo script deixou cair um novo payload surpreendente, uma espécie de RAT caseiro. Esse RAT é escrito como um script do PowerShell e oferece algumas funcionalidades básicas, como executar programas, baixar e executar arquivos e um mecanismo de persistência simples. Não se parece com nenhuma ferramenta de código aberto que já tenhamos visto, e foi, talvez, escrita pelo atacante.

Isso é muito provavelmente outra execução automática, o que nos leva a perguntar por que dois RATs foram lançados na máquina infectada. Não há respostas claras, mas existem algumas possibilidades:

1.      Os atacantes podem estar agindo com muita cautela. Se uma ferramenta for detectada, outra poderá ser usada para manter a porta dos fundos. Ou talvez este segundo RAT seja evasivo de maneiras que o primeiro não é.

2.      Os atacantes podem estar testando uma nova ferramenta que estão desenvolvendo e decidiram descartar ambas.

3.      Múltiplos atacantes estão usando a mesma infraestrutura (ou compraram acessibilidade à mesma infraestrutura).

Seja qual for o motivo, vemos um novo endereço C2, e vimos ambos os RATs sendo usados nas semanas seguintes em nossa análise do ataque.

A cadeia de ataque parece mais direta também — ela começa com um arquivo JavaScript, aparentemente nomeado com a porta do endereço C2, que é descarregado em uma pasta temporária. O script, então, executa essencialmente o RAT inteiro como um comando do PowerShell.

O comando em si, quando desofuscado, revela um script que age como um tipo de RAT caseiro — um que desativa o AMSI, configura um ouvinte para comandos, realiza alguma coleta de informações inicial, estabelece a persistência e inicia um loop infinito que age como um manipulador de comandos do ACT.

O script realiza primeiro uma varredura do sistema, coletando informações sobre os nomes dos antivírus, consultando o WMI para obter os produtos antivírus instalados, bem como o nome e a arquitetura do sistema operacional, UUID, nome do computador e nome do usuário. Tudo isso é então transmitido para o C2 do atacante, usando Microsoft.XMLHTTP, que também é usado para ouvir comandos. Este é um uso bastante interessante deste objeto COM, já que ele é mais comumente utilizado em scripts VBS. É possível que o invasor tenha escolhido usar esse comando em vez dos comandos internos do PowerShell para evitar a detecção, já que muitos produtos de segurança procuram por comandos do PowerShell que estabeleçam comunicações pela Internet.

O manipulador de comando é composto por um loop que envia solicitações POST para o servidor C2 a cada três segundos e aguarda uma resposta. O loop, então, executa os comandos seguintes, com base na resposta:

1.      RF (run file): esse comando permite que o invasor grave um arquivo binário em uma pasta temporária e o execute.

2.      TR: recebe o código do PowerShell do atacante, grava-o no disco como um arquivo .ps1 e o executa. Além disso, ele configura um mecanismo de persistência usando um script VBS. O script VBS é configurado para ser executado na inicialização por meio da pasta de inicialização e é usado para iniciar o script do PowerShell. Isso pode ser usado para configurar qualquer número de backdoors adicionais, ou qualquer outro script que o invasor queira persistir.

3.      Exc: permite que o invasor grave um script VBS em uma pasta temporária e o execute.

4.      Sc: executa uma ação semelhante ao comando RF, mas é usado para gravar texto simples e provavelmente usado para gravar e executar scripts.

5.      Cl: encerra o loop e fecha o script.

6.      Un: encerra o loop e fecha o script.

A persistência é estabelecida pela criação de uma cópia do arquivo 8911.js (o arquivo JavaScript que originalmente inicia o script RAT) na pasta de inicialização com o nome FirefoxUpdate.js.

O script emprega várias técnicas de ofuscação para evitar a detecção e dificultar a análise. Os nomes de variáveis e funções são deliberadamente longos, sem sentido ou não relacionados ao seu propósito, enquanto a execução de comandos é ocultada por trás de aliases calculados dinamicamente. Payloads essenciais, como o script de persistência VBS, são armazenadas como matrizes de charcode e somente decodificadas em tempo de execução, e a violação do AMSI é armazenada como uma montagem .NET codificada em Base64. O manipulador de comandos utiliza códigos curtos e enigmáticos (como RF, TR, SC) em vez de nomes descritivos, e os arquivos descartados recebem nomes aleatórios ou baseados em GUID.

O script utiliza objetos do Windows incorporados, como Microsoft.XMLHTTP para comunicação C2 e Microsoft.VisualBasic.Interaction para criação de objeto, mesclando-se com atividade legítima. Os dados de reconhecimento do sistema são exfiltrados por meio de cabeçalhos HTTP, em vez de parâmetros óbvios, e as mensagens de erro são suprimidas para evitar chamar a atenção. Juntas, essas estratégias de ofuscação em camadas tornam o comportamento real do script mais difícil de ser detectado e prevenido automaticamente por produtos de segurança.

Em resumo, este script é bastante interessante de se ver, especialmente porque não conseguimos encontrá-lo sendo usado em nenhum outro lugar. Embora partes do código pareçam ser reutilizadas, este RAT caseiro parece ter sido escrito principalmente pelo atacante. Isso talvez dê vantagem ao atacante, pois ele pode ajustar a ferramenta às suas necessidades e evitar a detecção com base em padrões ou assinaturas específicos e bem conhecidos, mas, por outro lado, a ferramenta pode não ter alguns dos recursos mais avançados oferecidos por outras ferramentas. No geral, é uma descoberta interessante e levanta a questão de saber se mais de um atacante está usando a mesma infraestrutura.

Duas semanas após o comprometimento inicial, os atores da ameaça aproveitaram o acesso ao ScreenConnect para implantar uma nova versão do AsyncRAT, juntamente com uma cadeia de infecção reformulada.

A cadeia de infecção atualizada começa com um script em lote que inicia o MicrosoftUpdate.vbs – um simples wrapper para um comando de uma linha do PowerShell que funciona como um carregador. Este script do PowerShell faz download de dois arquivos, logs.ldr e logs.ldk, para o diretório C:\Usuários\Public.

Ambos os arquivos, logs.ldk e logs.ldr, são assemblies .NET codificados. O script do PowerShell decodifica e executa logs.ldk primeiro, que é uma DLL .NET chamada Obfuscator.dll e que serve a dois propósitos: estabelecer a persistência e atuar como um carregador secundário para logs.ldr, o payload do AsyncRAT propriamente dito.

A persistência é alcançada por meio de uma tarefa agendada chamada "Skype Atualizador", configurada para executar C:\Users\Public\Ab.vbs no logon do usuário. Este script VBS espelha o comportamento do MicrosoftUpdate.vbs, funcionando como um wrapper que invoca o carregador baseado em PowerShell.

O AsyncRAT (logs.ldr) é decodificado e carregado na memória via chamada de método Obfuscator.dll [Obfuscator.A]::Main($f2) usada dentro do script do PowerShell.

A instância do AsyncRAT recém-implantada tinha um recurso atualizado. De forma notável, ele utilizou uma nova string de mutex: “AsyncMutex_alosh20215” e comunicou-se com o servidor de comando e controle (C2) nas seguintes portas: 4501, 4502 e 4503.

A infraestrutura de C2 permaneceu inalterada, ainda com hosting no endereço 185.196.9.158.

Vários dias após a implantação do AsyncRAT atualizado, observamos a entrega de um RAT adicional via WMI. A atividade ocorreu minutos após a execução de scripts relacionados ao AsyncRAT e, embora a atribuição definitiva não seja possível com as evidências disponíveis, a proximidade temporal sugere uma forte probabilidade de que as duas atividades estejam relacionadas.

Foi observado o processo WmiPrvSE.exe executando um comando do PowerShell que utilizava o comando Invoke-WebRequest para baixar um script chamado NvContainerRecovery.ps1 no diretório C:Users\Public. Logo em seguida, o mesmo processo WMI invocou o PowerShell novamente para executar o script baixado.

O script NvContainerRecovery.ps1 estabelece a persistência inicialmente, criando um script VBS na pasta de inicialização. Este arquivo VBS simplesmente atua como um invólucro para executar o mesmo script do PowerShell em cada logon de usuário.

Após a configuração da persistência, o script do PowerShell carrega uma DLL .NET que implementa o processo de esvaziamento. Este método é usado para injetar outra montagem .NET em uma instância gerada de RegAsm.exe. O assembly injetado é responsável por descriptografar e carregar um payload .NET final — identificado como PureHVNC RAT.

A instância do PureHVNC está configurada para se conectar à porta 8020 no endereço 169.156.208.185.

Uma investigação da infraestrutura de ataque revela vários domínios diferentes que acreditamos poderem estar sendo usados pelo atacante. Além de morco.rovider.net, incluem-se nessa lista outros dois domínios: gaza.rovider.net e lightc.rovider.net. Ambos estão relacionados a instaladores do ScreenConnect, com servidores hosting no stealthrdp.com. Eles são observados em conexão com o XWorm e o DCRat, o que pode indicar uma infraestrutura de ataque mais ampla do que a que observamos até agora.

Identificamos inúmeros casos que envolviam o uso de instaladores do ScreenConnect que se conectavam a servidores ScreenConnect locais provavelmente violados. A grande maioria desses incidentes ocorreu nos Estados Unidos, e os nomes dos arquivos dos instaladores sugerem fortemente a distribuição por meio de phishing ou outras técnicas de engenharia social.

Os executáveis geralmente tinham nomes que os faziam parecer documentos legítimos, o que provavelmente tinha o objetivo de enganar os usuários para que eles os executassem. Exemplos incluem:

• Social_Security_Statement_Documents_386267.exe

MD5: 2EECA7166487DDC0B4C36B718DF31C93

• ssa_view.exe MD5: C92D37BC45F6088458C70C1CF53C06F6

• Social-Security-Available-Statement-3025147.ClientSetup.exe MD5: BA261666A657BDE2E8E071EE6E7D5357

• agreement_support-pdf.Client.exe MD5: 34ED21AC2399CC08BD051A283FD59FCE

• SSADocumentViewer-nXpJ2.exe MD5: A58719D9DDE0179C25215637766C2AB0

• 2024 BUSINESS SCHEDULE COMPLETE ORGANIZERpdf.exe MD5: 316119C77032A24822A64C86C1E4B2A0

Esse padrão de nomenclatura indica uma tentativa clara de se fazer passar por documentos oficiais ou financeiros, principalmente relacionados à segurança social ou a acordos legais.

Nesses casos, observamos principalmente a implantação do AsyncRAT e do Remcos RAT.

Com relação ao Remcos, identificamos que o ator da ameaça reutilizou a mesma máquina virtual em várias campanhas, embora ela estivesse em hosting em diferentes endereços IP. De acordo com os resultados do Shodan, a VM estava executando o Windows Server 2022, tinha o RDP ativado e estava fazendo hosting de um servidor ScreenConnect. O nome do host da máquina foi consistente em todas as ocorrências: WIN-BUNS25TD77J.

Ao coletar amostras adicionais de fontes de inteligência de ameaças, descobrimos também outro nome de host comum usado por várias campanhas: COPY-OF-VM-2022. Parece que os atacantes podem ter VMs pré-configuradas que eles fazem hosting em diferentes endereços, o que permite uma rápida configuração e alterações de infraestrutura.

Rede:

• 169.156.208.185

• 185.196.9.158

• 185.196.8.100

• morco[.]rovider[.]net

• hxxps://eywordvailabom[.]com/sa/16-05.txt

• hxxps://systemwindowsupdate[.]com/alosh/logs.ldk

• hxxps://guilloton[.]fr/x.zip

Mutexes:

• AsyncMutex_al026

• AsyncMutex_alosh20215

Arquivos:

• agreement_support-pdf.Client

67A32455A94B3396AD956CBDDA81D8ED1CD3727315159E025299057118DEB6AC

• Skype.ps1

BB182B8545B8C825811C6D09C738C230FE54BC96ADF1F10A3683B7E5294B5289

• 1.txt

C260779FB1C9FF775739F6CF1853C9C33131ECF176737F6AF26B0AC60A6081DC

• Pe.txt

53AAD05571E86F22E2C75ED4FA6C8F553C3EBD58DCA8BE9FE8A143784AEF29D7

• BypaasaUpdate.bat

973A02FF597864E3920ED1041D24D629A0762CDE932EB69AEA066CD2235404F8

• Pe.txt decodificado (Amsi Patcher)

1DA9428DF9A04E6CA1D836D1E941B61E30B6AF952D24D7B451A8D1E906ECE0C0

• 1.txt decodificado (AsyncRAT)

E7C482E66EFA99EA98E2C79BEB0A31C5120B73E4951A5F33133066B17E009DA1

• logs.ldr

A4BF71F97C3A2F3FDA496D204B5E744D6F1DA8D888ACE3867DA08D072AF01245

• logs.ldk

6FA549F446A541856784695DB808DE2E5C67DA271C64ECC966C7C0B02622D58B

• Logs.ldr (decodificado)

10EEB21202E7EB055F9FAC37DAB96F86DFEB9F28C0510F33E4324D12087CACF2

• Logs.ldk (decodificado)

6AE546DA4D6D78D4262F3A2FF5E4F58C345294383ED9FF5E4DAA52466FE79E2F

• Powershell RAT

B82E616E956A956FF5D9AFFCC13C907CF5054439FB5EE5A6F7AA5FFEE030DA56

• NvContainerRecovery.ps1

EF66D80511CD46C5173BF13E750C51114EE891E833F4F256A23E7DE4790ACC73

• PureHVNC RAT

068504CB4AC18D504247EF7A2C19A76B17A85E795B52E541FA8A49DE69B91F01