Envio de registos, alertas e telemetria através de um diodo de dados

Descubra como
Utilizamos inteligência artificial para as traduções dos sítios e, embora nos esforcemos por garantir a exatidão, estas podem nem sempre ser 100% precisas. Agradecemos a sua compreensão.
Página inicial/ Blog / Como Secure os repositórios Server Secure Server
Segurança de ficheiros

Como Secure os repositórios Server Secure Server

Proteger os repositórios de ficheiros contra o malware e o ransomware que a verificação pontual, realizada por um único motor, deixa escapar
Por Bianca Bobirca, Gestora de Marketing de Produto
Partilhar esta publicação

Para proteger um repositório Server SharePoint Server , é necessário aplicar controlos adicionais ao seu antivírus integrado, que analisa cada ficheiro apenas uma vez durante o carregamento ou a transferência, utilizando um único motor. Multiscanning, o CDR (Content Disarm and Reconstruction), o DLP (Data Loss Prevention) e a reanálise contínua colmatam as lacunas que permitem que o malware e o ransomware permaneçam inativos.

Principais conclusões

  • O antivírus integrado Server SharePoint Server(VSAPI ou AMSI) analisa cada ficheiro com um único motor, apenas no momento do upload ou do download. Nunca volta a analisar ficheiros já armazenados.
  • Um ficheiro classificado como «limpo» no primeiro dia mantém essa classificação indefinidamente, pelo que o malware e o ransomware podem permanecer inativos e indetetados enquanto as assinaturas e os modelos de deteção evoluem à sua volta.
  • O histórico de versões agrava a exposição: cada cópia arquivada apresenta o mesmo risco de dados não verificados e em repouso que o ficheiro atual.
  • Os ataques ToolShell/Warlock de julho de 2025 revelaram que os atacantes estavam a instalar ficheiros web-shell que uma análise pontual com um único motor nunca foi concebida para detetar.
  • Para colmatar essa lacuna, é necessário um conjunto de controlos em camadas. Esse conjunto inclui a verificação múltipla, o CDR (Content Disarm and Reconstruction), o DLP (Data Loss Prevention) e a reverificação contínua, para além da verificação nativa.
  • O MetaDefender™ Storage Security a plataforma de proteção de dados empresariais OPSWAT, que utiliza o Metascan™ Multiscanning™, a tecnologia Deep CDR™ e o Proactive DLP™ para inspecionar tanto os novos ficheiros carregados como os ficheiros já armazenados.

Quando os utilizadores e administradores do SharePoint local carregam um ficheiro, esse ficheiro é analisado por um antivírus de terceiros ou por motores compatíveis com AMSI (como o Microsoft Defender). Se o ficheiro passar nessa análise inicial, é considerado tratado. Limpo uma vez, limpo para sempre. É precisamente esta suposição que permite que cargas úteis de malware e ransomware permaneçam no repositório sem serem detetadas, por vezes durante anos.

A Microsoft afirma isso mesmo de forma direta: a proteção contra malware do SharePoint pode limitar os danos, mas não funciona como um único ponto de defesa.

Nos setores BFSI (Banca, Serviços Financeiros e Seguros), cuidados de saúde, administração pública e OT (Tecnologia Operacional) ou em ambientes de infraestruturas críticas, os dados em risco incluem documentos de conformidade, registos de doentes, processos e documentação de engenharia. Tudo isto encontra-se numa base de dados que não pára de crescer, ano após ano, sem que haja qualquer revisão do conteúdo já existente.

O que se segue resume-se a três aspetos: como funciona, na prática, a verificação antivírus do SharePoint, o que esta não abrange e como deve ser uma segurança em camadas e eficaz para o repositório de ficheiros do SharePoint.

Por que razão os repositórios de ficheiros do SharePoint constituem uma superfície de ataque maior do que a maioria das equipas imagina

Por natureza, os repositórios Server do SharePoint Server podem acumular malware e cargas úteis de ransomware que permanecem inativas, sem serem detetadas, até serem ativadas. Eis o motivo.

Os dados considerados «limpos» não são, de facto, limpos

Um ficheiro infetado pode ser classificado como «limpo» no momento do upload porque o motor ainda não tinha sido atualizado para o detetar na altura da verificação. As bases de dados de assinaturas são atualizadas diariamente. Os modelos de deteção melhoram a cada nova versão. No entanto, nada disso importa quando um ficheiro já se encontra na biblioteca; sem novas verificações periódicas, essas melhorias aplicam-se apenas a partir daí em diante, nunca retroativamente. Um ficheiro verificado uma vez, no primeiro dia, nunca beneficia de nada do que o motor aprenda posteriormente.

Além disso, existe uma segunda via de entrada de ficheiros: migração, restauração, atualizações da base de dados ou sincronizações de terceiros. No entanto, não existe nenhum processo documentado do SharePoint que preveja verificações obrigatórias de malware para estas vias. Os ficheiros que entram através destas operações contornam completamente a verificação, pelo que existe o risco de ameaças veiculadas por ficheiros chegarem aos repositórios do SharePoint.

Dependência excessiva da análise de um único motor

Embora exista uma verificação inicial, esta continua a ser limitada, uma vez que apenas um motor está ativo. A cobertura da deteção baseia-se em assinaturas e heurísticas provenientes de um único fornecedor, pelo que a capacidade de reconhecer malware está limitada a uma única base de dados. E, para reiterar a questão central: não há uma nova verificação contínua do repositório existente para acompanhar a evolução da base de dados.

Malware propaga-se a partir do SharePoint

As próprias funcionalidades de partilha e sincronização do SharePoint podem transformar essa biblioteca num canal de distribuição de ficheiros infetados:

  • Ficheiros partilhados com as permissões «qualquer pessoa com o link»
  • Acesso para convidados externos
  • O OneDrive sincroniza-se com os dispositivos finais

Todas as situações acima referidas são formas através das quais os ficheiros infetados chegam aos utilizadores e parceiros que nunca realizaram uma verificação de ficheiros carregados; estão simplesmente a abrir um ficheiro que outra pessoa já colocou no repositório.

Os atacantes também têm utilizado sites do SharePoint comprometidos diretamente como infraestrutura de alojamento, ou incorporado documentos de phishing e links maliciosos em URLs do SharePoint que, de outra forma, seriam considerados fiáveis, o que aumenta as probabilidades de estes passarem despercebidos pelos filtros de segurança de e-mail e pela desconfiança dos utilizadores.

Conclusão principal: Existem três razões que permitem que o malware e o ransomware se acumulem nos Server do SharePoint Server . Ficheiros que escapam totalmente à verificação durante a migração, restauração ou sincronização. Ficheiros que foram verificados antes de o motor os poder reconhecer como ameaças e que nunca voltaram a ser verificados. E ameaças veiculadas por ficheiros que um único motor simplesmente não consegue identificar.

A adoção aumentou a pressão

Os dados da Enlyft sobre a adoção de tecnologia abrangem 256 295 empresas que utilizam atualmente o Microsoft SharePoint, abrangendo setores que vão desde os serviços de TI até à banca, cuidados de saúde, petróleo e gás e administração pública. Estas empresas têm, normalmente, entre 50 e 200 colaboradores e um volume de negócios entre 1M e 10M de dólares.

É precisamente essa dimensão que faz com que os atacantes prestem atenção e considerem os repositórios do SharePoint como alvos de grande valor.

Como funciona, na prática, a digitalização integrada ServerSharePoint Server

Nada do que foi referido acima significa que o SharePoint não proteja os seus servidores ou negligencie a segurança dos ficheiros. De acordo com a documentação da Microsoft, o SharePoint Server com duas interfaces de verificação possíveis:

  • VSAPI (Virus Scanning API), uma interface de integração antivírus do SharePoint que permite que software antivírus de terceiros compatível analise documentos durante operações como o carregamento e a transferência.
  • AMSI (Antimalware Scan Interface), uma estrutura de integração antimalware da Microsoft que permite Server SharePoint Server ficheiros para motores antivírus compatíveis com a AMSI (como o Microsoft Defender) para a verificação de malware durante operações de conteúdo suportadas.

O SharePoint Server pode ser configurado para utilizar o VSAPI, o AMSI ou o modo automático. Independentemente da opção selecionada, apenas um motor de análise avalia um ficheiro de cada vez.

A verificação é baseada em eventos e é acionada quando os utilizadores carregam ou descarregam documentos, não de forma retroativa nem periódica. Apenas um motor (o Microsoft Malware Protection Engine, vulgarmente conhecido como MpEngine.dll) avalia o ficheiro.

Conclusão principal: Os ficheiros são analisados por um único motor, quer no momento do upload quer no momento do download, utilizando as assinaturas e as capacidades de deteção atuais desse motor.

Esta abordagem não foi concebida para detetar uma ameaça veiculada por ficheiros que tenha sido especificamente criada para contornar a lógica de deteção desse motor específico. As ameaças persistentes avançadas, em particular, exploram frequentemente precisamente esta limitação, permanecendo indetetadas durante longos períodos.

Essa persistência abre uma porta para que os atacantes possam utilizar conteúdo confiável do SharePoint como arma. Já existem ataques documentados em que os autores das ameaças abusaram de sites do SharePoint comprometidos para alojar documentos de phishing e links maliciosos.

O que a funcionalidade de digitalização nativa do SharePoint não abrange

A Microsoft é clara ao alertar os utilizadores de que as funcionalidades antivírus integradas no SharePoint podem conter vírus, mas não se destinam a ser o único ponto de defesa contra malware. Vale a pena abordar três pontos cegos específicos.

A advertência da Microsoft

Dados já armazenados

A deteção fica rapidamente desatualizada. Como o motor de deteção não é acionado de forma recorrente, a classificação de um ficheiro reflete apenas o que um único motor conseguiu identificar no momento em que o ficheiro foi analisado.

Histórico de versões

As bibliotecas do SharePoint, com o histórico de versões ativado, guardam cada versão guardada como uma cópia separada do ficheiro. Dependendo das políticas de controlo de versões da organização, um único ficheiro pode acumular centenas de versões históricas ao longo do tempo.

A documentação da Microsoft sobre o histórico de versões não menciona a realização de análises de malware nas versões armazenadas.

Cada versão histórica armazenada numa biblioteca apresenta, portanto, o mesmo nível de exposição em repouso que a versão atual. Em bibliotecas com atualizações frequentes, a exposição acumula-se ao longo do tempo. Podem acumular-se centenas de versões não digitalizadas do mesmo ficheiro (infetado). Os riscos aumentam exponencialmente com a profundidade do histórico de versões.

Ameaças desconhecidas ou de dia zero

Um ataque «zero-day» será aprovado na verificação da mesma forma que um ficheiro limpo, simplesmente porque ainda não existe nenhum motor que o identifique. E como o SharePoint não volta a verificar o conteúdo existente posteriormente, um ficheiro «zero-day» que seja aprovado no primeiro dia não será revisto no dia duzentos, mesmo depois de o fornecedor ter lançado uma atualização de assinaturas que o detectaria.

As ameaças desconhecidas seguem a mesma lógica. Como não têm nenhuma assinatura associada, a análise estática (o que os motores antivírus fazem) não consegue detetar a ameaça.

Nota: trata-se de lacunas no âmbito de aplicação e não de defeitos. O antivírus nativo Server SharePoint Server foi concebido para realizar verificações pontuais em pontos de interação específicos, e não para revalidar continuamente um repositório em crescimento e com versões, face a um panorama de ameaças em constante evolução.

Os ataques ao SharePoint com o ToolShell/Warlock em 2025

Em julho de 2025, a Microsoft divulgou a exploração ativa de uma cadeia de execução remota de código sem autenticação que afetava o SharePoint Server instalado localmente: CVE-2025-49706, CVE-2025-49704, às quais se juntaram posteriormente o CVE-2025-53770 e o CVE-2025-53771. A exploração não necessitava de credenciais nem de um início de sessão para funcionar.

A Microsoft corrigiu posteriormente a falha, e à cadeia de exploração foi atribuído um nome: ToolShell.

De acordo com a análise da Eye Security, citada pela Infosecurity Magazine, foram identificados 396 sistemas comprometidos em 145 organizações, espalhadas por 41 países. O setor governamental foi o mais afetado, representando 30% das infeções confirmadas, e só os EUA representaram 31% do total. Por outro lado, a Shadowserver Foundation informou que mais de 10 700 instâncias do SharePoint continuavam expostas, acessíveis a qualquer pessoa que executasse a mesma cadeia de exploração, mesmo depois de a vulnerabilidade — que comprometeu centenas de organizações — ter sido tornada pública. O Storm-2603, um dos grupos por trás da exploração, transformou essa exposição numa carga útil do ransomware Warlock.

Assim que conseguiram entrar, o Storm-2603 utilizou credenciais roubadas e ferramentas de administração legítimas para se deslocar lateralmente pelos sistemas. Este movimento não despertou suspeitas, uma vez que se baseou em ferramentas que deveriam estar presentes. O Storm-2603 instalou web shells e exfiltrou dados importantes. Mantiveram o acesso mesmo depois de a vulnerabilidade ter sido corrigida, porque os atacantes já tinham roubado as chaves necessárias para falsificar tokens de autenticação válidos.

O ToolShell foi desenvolvido com base em quatro CVEs, encadeadas entre si, com mecanismos de contorno das correções incorporados desde o início. As vulnerabilidades CVE-2025-53770 e -53771 existem especificamente porque as correções originais para as vulnerabilidades CVE-2025-49704 e -49706 podiam ser contornadas.

O que realmente importa é que um atacante se adaptou mais rapidamente do que o ciclo de correções, por duas vezes, no mesmo alvo, no espaço de algumas semanas.

Os controlos estáticos, como os programas antivírus individuais que verificam um ficheiro uma única vez, comparando-o com as assinaturas de um único fornecedor, nunca foram concebidos para detetar uma cadeia de explorações do lado do servidor. Além disso, não conseguem proteger contra um atacante que regresse após a aplicação da correção com uma forma de contornar essa correção.

O ToolShell demonstra o nível de sofisticação que agora visa especificamente os servidores SharePoint. Não há motivos para supor que esta tenha sido a última vez que ocorreu uma exploração deste tipo. Os dados armazenados nestes servidores estão protegidos por algo concebido para acompanhar a evolução das ameaças, ou por uma verificação que analisa uma única vez e dá o assunto por encerrado?

Para ser justo, o ToolShell não era um documento malicioso que tivesse escapado a uma verificação de ficheiros carregados. Mas e o web shell (spinstall0.aspx e as suas variantes renomeadas) que os atacantes colocaram no servidor? Esse é um ficheiro. Ficou no servidor e o facto de ter sido ou não detetado dependia das mesmas limitações descritas anteriormente: um único motor de verificação, uma única verificação, num único momento.

É esse o mecanismo que liga este incidente ao argumento mais geral. A aplicação da correção bloqueia especificamente a cadeia de exploração do ToolShell. Não tem qualquer efeito sobre o próximo ficheiro ainda não analisado que já se encontre num repositório.

Como é um conjunto de controlos de segurança de ficheiros do SharePoint em camadas

Tudo o que foi abordado até agora aponta para a mesma conclusão: a verificação nativa cumpre bem a sua função num âmbito restrito, e esse âmbito deixa em aberto possíveis pontos de entrada. Para os colmatar, as organizações precisam de implementar controlos de segurança adicionais aos controlos do SharePoint.

Vários motores em vez de um só

A maior limitação da análise nativa é o facto de ser apenas um motor a efetuar a verificação, utilizando as assinaturas de que dispõe nesse momento. Analisar um ficheiro através de vários motores em simultâneo, em vez de apenas um, elimina uma parte significativa dessa limitação; uma ameaça que um fornecedor não detete será identificada por outro.

A higienização como complemento à deteção

A análise baseada na deteção, independentemente do número de motores que utilize, continua a depender do reconhecimento prévio de algo como sendo malicioso.

Tecnologias como o CDR (Content Disarm and Reconstruction) eliminam essa dependência. Em vez de perguntar se um ficheiro é perigoso, a tecnologia reconstrói o ficheiro numa estrutura reconhecidamente segura, independentemente da resposta.

O que mais importa são os pontos em que a deteção tem dificuldades: vulnerabilidades «zero-day», ameaças desconhecidas ou ameaças veiculadas por ficheiros, criadas especificamente para contornar a deteção. Não é necessário que algo seja reconhecido como malicioso para que o CDR o neutralize.

Incorporar a Prevenção da Perda de Dados ao Processo

O malware não é a única coisa que não deve ficar sem supervisão num repositório.

Os dados sensíveis (informações de pagamento reguladas pela norma PCI, PHI (Informações de Saúde Protegidas) e CUI (Informações Não Classificadas Controladas), dependendo do setor) estão armazenados nas mesmas bibliotecas que todos os restantes dados, e um conjunto de controlos de segurança centrado exclusivamente no malware não aborda essa exposição.

A pesquisa específica de dados confidenciais (e a sua ocultação ou bloqueio) resolve o problema de conformidade, a par do problema relacionado com o malware.

Reanalisar o que já se encontra no repositório

Nada do que foi referido acima tem grande importância para conteúdos que permanecem inalterados desde 2023, a menos que sejam efetivamente digitalizados.

Esta é a camada que o antivírus nativo do SharePoint não consegue cobrir: a revisão do conteúdo armazenado, incluindo versões anteriores mantidas no histórico de versões, de forma recorrente ou contínua, em vez de apenas no momento do upload ou download. A reanálise em tempo real, programada e a pedido colmata essa lacuna, inspecionando periodicamente os ficheiros à medida que as bases de dados são atualizadas.

Individualmente, cada um destes controlos colmata uma lacuna específica já abordada anteriormente. Em conjunto, formam o tipo de defesa em camadas a que a própria documentação da Microsoft se refere quando afirma que o antivírus integrado não se destina a ser um único ponto de defesa.

Como Storage Security do MetaDefender™ Storage Security estes requisitos

Storage Security MetaDefender™ Storage Security é a plataforma de proteção de dados empresariais OPSWAT, concebida para proteger ficheiros em ambientes de armazenamento locais, híbridos e nativos da nuvem, utilizando o Metascan™ Multiscanning, a tecnologia Deep CDR™ e o Proactive DLP™, analisando tanto novos ficheiros carregados como o conteúdo já armazenado.

Para os utilizadores do SharePoint, a plataforma pode resolver tanto o problema do conteúdo inativo como as limitações decorrentes de uma deteção restrita a um único motor. Eis como isso acontece:

  • Análise com mais de 30 motores antimalware através da tecnologia Metascan™ Multiscanning; uma ameaça que escape a um fornecedor tem mais 29 oportunidades de ser detetada.
  • A tecnologia Deep CDR™ elimina os pontos cegos na deteção; a tecnologia Deep CDR™ desmonta e reconstrói os ficheiros numa estrutura segura, útil para ameaças de dia zero e desconhecidas ocultas em ficheiros de produtividade. O ficheiro é desmontado independentemente de ter sido ou não reconhecida uma ameaça.
  • A tecnologia Proactive DLP™ mitiga os riscos de fugas de dados ao identificar, bloquear e ocultar dados sensíveis ou confidenciais nos ficheiros. Para os setores BFSI, dos cuidados de saúde e da administração pública, regulados pelos requisitos PCI DSS, PHI ou CUI, trata-se de um controlo de conformidade que se sobrepõe à proteção contra malware e às pistas de auditoria.

Várias opções de análise no MetaDefender Storage Security

Uma diferença fundamental em relação ao modelo nativo do SharePoint, MetaDefender Storage Security a verificação em tempo real, programada e a pedido do conteúdo já armazenado no repositório. A proteção em tempo real protege os novos ficheiros carregados em poucos segundos, enquanto as verificações programadas e a pedido garantem que os ficheiros existentes e as versões históricas permaneçam protegidos.

A implementação permanece onde for necessário

MetaDefender Storage Security pode ser implementado através de vários modelos: servidores físicos para instalações diretas de hardware, plataformas de virtualização (compatíveis com VMware, Hyper-V e XenServer), IaaS (Infraestrutura como Serviço) dos principais fornecedores de serviços na nuvem ou através de implementações em contentores em clusters do Kubernetes.

Avalie a exposição atual do seu repositório do SharePoint; lista de verificação prática

Esta lista de verificação baseia-se nas orientações da CISA sobre a exploração do ToolShell.

1. Confirmar o estado da correção.

Todas as vulnerabilidades CVE exploradas têm atualizações de segurança disponíveis, mas os servidores que não foram atualizados continuam expostos ao ToolShell. Aplique as atualizações de segurança da Microsoft a todas Server SharePoint Server afetadas.

2. Verifique se o AMSI está configurado.

Um AMSI implementado, mas mal configurado, deixa a mesma lacuna que a ausência total de AMSI. Certifique-se de que a integração do AMSI está ativada e de que existe uma solução antivírus implementada em todos os servidores SharePoint.

3. Alternar as chaves de máquina do ASP.NET

As chaves de máquina roubadas permitem que os atacantes falsifiquem tokens de autenticação válidos, mesmo depois de o servidor ter sido atualizado. A aplicação da atualização, por si só, não invalida as chaves já roubadas. Faça a rotação das chaves de máquina, aplique a atualização de segurança e, em seguida, faça novamente a rotação das chaves de máquina. Reinicie o IIS utilizando o iisreset.exe após cada rotação para remover entradas maliciosas dos ficheiros applicationHost.config e web.config.

4. Procure manualmente sinais de uma violação anterior.

A CISA salienta que as cargas úteis .dll utilizadas nesta campanha podem ser utilizadas para obter chaves do sistema. A aplicação de correções não remove a carga útil já instalada no servidor. Inspecione os sistemas e ficheiros específicos à procura de IOCs (Indicadores de Comprometimento), e não apenas da própria vulnerabilidade.

5. Verifique se existem versões em fim de vida útil ou em fim de suporte.

Algumas instâncias do SharePoint estão no fim do ciclo de vida (EOL) e já não recebem atualizações de segurança, independentemente da existência de atividades de exploração. Verifique se as versões utilizadas pela sua empresa ainda são suportadas. Caso contrário, tome as medidas necessárias.

6. Analisar os registos para identificar indicadores conhecidos

A CISA identifica padrões específicos de pedidos e endereços IP associados a esta campanha. Pesquise nos registos os pedidos que correspondam às referências da CISA.

7. Verificar os privilégios de administração e de layout.

Para limitar a extensão dos danos, verifique quem detém as permissões de configuração e de administração no SharePoint e remova os direitos de acesso que não sejam atualmente necessários.

8. Avaliar o que já está armazenado, e não apenas o que está atualmente exposto

Tudo o que foi referido acima diz respeito à própria cadeia de exploração. Nada disso avalia o conteúdo que já se encontra nas bibliotecas de documentos, incluindo ficheiros anteriores a qualquer uma destas correções.

Determine se o conteúdo existente no repositório foi novamente analisado desde a aplicação das correções e atualizações de assinaturas relevantes, ou se ainda mantém o resultado da análise original, que pode estar desatualizado.

Proteger o armazenamento do SharePoint contra ataques do tipo ToolShell

O ToolShell era rápido, difícil de conter e causava danos reais. Isso merece respeito.

Provavelmente não será a última vez que assistiremos a uma cadeia de ataques como esta; afinal, utilizar o SharePoint Server expor uma superfície de ataque. O importante é garantir que os ficheiros que se encontram no seu repositório estejam protegidos quando surgir um novo ToolShell.

Essa parte está sob o teu controlo.

MetaDefender Storage Security impedirá que uma vulnerabilidade do lado do servidor seja descoberta, mas eliminará a possibilidade de ameaças veiculadas por ficheiros permanecerem no seu repositório, não detetadas por um único motor e indetetadas até serem ativadas.

Para saber mais, descarregue o documento técnico «Securing Enterprise File Storage», que tem como objetivo explicar como é possível reduzir as ameaças transmitidas por ficheiros, proteger a sua capacidade de restauração sem alterações e garantir a segurança do seu armazenamento empresarial sem abrandar as operações.

Descarregar o Livro Branco

Perguntas mais frequentes

1. O SharePoint Server automaticamente os ficheiros em busca de malware?

Sim, mas apenas em momentos específicos. O SharePoint Server analisar documentos durante o carregamento, o descarregamento e a edição online, utilizando um único mecanismo através da VSAPI ou da funcionalidade de antivírus para documentos baseada em AMSI. Não volta a analisar automaticamente os ficheiros já armazenados nas bibliotecas.

2. É possível que um malware permaneça indetetado numa biblioteca Server do SharePoint Server ?

Sim. As integrações antivírus nativas ServerSharePoint Server(VSAPI ou AMSI) verificam um ficheiro no momento do carregamento ou da transferência, utilizando as assinaturas de um único motor disponíveis nesse momento. Os ficheiros não são verificados novamente posteriormente, pelo que um ficheiro que estivesse isento de vírus, ou que simplesmente não tivesse sido reconhecido, quando as assinaturas do motor estavam desatualizadas, pode permanecer na biblioteca indefinidamente.

3. O SharePoint Server os ficheiros que já estão armazenados?

Não. A análise nativa é baseada em eventos, sendo acionada por atividades de upload ou download. Não é executada de forma recorrente em conteúdos existentes, incluindo versões mais antigas de ficheiros mantidas no histórico de versões.

4. De que forma é que os atacantes podem utilizar o SharePoint para distribuir malware, e não apenas para o armazenar?

Os atacantes podem utilizar as funcionalidades de partilha e sincronização do SharePoint — links externos ou para convidados, bibliotecas sincronizadas ou sites comprometidos que alojam documentos de phishing e links maliciosos — para transferir um ficheiro já preparado num repositório para outros utilizadores e terminais.

5. O SharePoint Online (Microsoft 365) é afetado pelas mesmas falhas e pelo ToolShell?

Não. A cadeia de explorações do ToolShell afetou Server SharePoint Server instalado localmente; o SharePoint Online não foi afetado. As limitações relativas à análise de dados em repouso e à análise com um único motor aqui discutidas aplicam-se igualmente às Server instaladas localmente.

6. O que é o ToolShell e a aplicação do patch resolve totalmente o problema?

O ToolShell é uma cadeia de explorações (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771) que permite a execução remota de código sem autenticação no SharePoint Server instalado localmente. A aplicação de correções corrige as vulnerabilidades, mas, como os atacantes roubaram as chaves das máquinas, as organizações devem também fazer a rotação das chaves e procurar os web shells já instalados.

7. Por que é que preciso de atualizar as chaves de máquina do ASP.NET após a aplicação de correções?

Os atacantes que roubaram as chaves do seu computador podem falsificar tokens de autenticação válidos, mesmo depois de aplicar a correção. A orientação da CISA é alternar as chaves, aplicar a atualização, alternar as chaves novamente e reiniciar o IIS com o comando iisreset.exe, para que a aplicação da correção expulse efetivamente o atacante.

8. A ativação do AMSI protege o SharePoint contra o ToolShell?

A integração de filtragem de pedidos do AMSI (ativada por predefinição desde as atualizações de setembro de 2023, idealmente no Modo Completo) analisa os pedidos recebidos e pode bloquear a exploração não autenticada do ToolShell. Esta funcionalidade é distinta da funcionalidade antivírus para documentos baseada no AMSI, que analisa o conteúdo dos ficheiros durante o carregamento e a transferência.

Etiquetas:

Mensagens mais recentes

Subscrever a newsletter OPSWAT

Obtenha as últimas actualizações da empresa OPSWAT , juntamente com informações sobre eventos e as notícias que estão a fazer avançar a indústria.
Inscrever-me

Siga-nos nas redes sociais Media

Siga OPSWAT no seu LinkedIn, Facebook, Twitter e YouTube para mais informações!

Mantenha-se atualizado com OPSWAT!

Inscreva-se hoje para receber as últimas actualizações da empresa, histórias, informações sobre eventos e muito mais.
Subscrever