Êtes-vous prêt pour l'étape 2 des attaques Log4Shell ?

Les raz-de-marée provoqués par l’attaque zero-day Log4Shell récemment découverte restent à déterminer. De nombreuses organisations se sont empressées de mettre à jour leurs serveurs, les rendant ainsi immunisés contre les attaques massives signalées. Cependant, l'application de correctifs à vos serveurs ne suffit pas à elle seule à garantir que ces problèmes critiques surface d'attaque a été couvert. Bien que l'exécution de la version mise à jour de log4j protège effectivement contre les attaques futures, il convient également d'aborder la possibilité que certains serveurs aient été compromis. avant au patch. Dans cet article, nous expliquerons la faisabilité de ce scénario et ferons un suivi avec des recommandations pratiques pour l'atténuer de manière proactive.

Récapitulatif de l'activité Log4Shell-In-the-Wild

Apache Log4j est un utilitaire de journalisation open source basé sur Java largement utilisé par les applications d'entreprise. Les rapports initiaux sur Log4Shell (CVE-2021-44228) datent du 9 décembre. Ces rapports ont été rapidement suivis d'un développement extrêmement rapide de nouvelles variantes d'exploit avec de nouvelles variantes de l'exploit original introduites rapidement - plus de 60 en moins de 24 heures. De plus, au cours de ces seules 24 heures, les attaques contre des organisations du monde entier ont augmenté, divers fournisseurs de sécurité signalant que de vastes portions de leurs clients étaient ciblées par des pirates tentant d'exploiter la vulnérabilité. Actuellement, l'exploit est maintenant rapidement intégré dans l'arsenal des logiciels malveillants courants et serait également utilisé par des groupes d'attaque avancés d'États-nations.

Assumer une infraction - Attaqué jusqu'à preuve du contraire

L'énorme volume de ces attaques représente un défi pour tout acteur de la sécurité qui a corrigé ses serveurs vulnérables. Le développement rapide et le rythme d'utilisation de l'exploitation de la vulnérabilité signifient qu'il existe au moins une probabilité viable que vos serveurs aient été ciblés par l'exploit avant la mise en place du correctif. Nous croyons fermement que la meilleure pratique de sécurité, dans ce cas, consiste à agir comme si vos serveurs avaient été compromis jusqu'à ce que cette menace soit réfutée de manière fiable. Passons en revue les différentes implications d'un tel compromis afin de mieux comprendre comment faire face efficacement à cette menace.

Scénarios de menace possibles de stade 2 à la suite d'une compromission silencieuse

Faire profil bas jusqu'à ce que le moment soit venu

Log4Shell permet à lui seul aux attaquants d’établir un premier point d’ancrage dans votre environnement. Cette prise de pied n’est pas l’objectif des attaquants mais plutôt une étape préalable indispensable. Cela signifie que si des attaquants ont effectivement exploité la vulnérabilité et sont devenus présents sur l’un de vos serveurs Web, ils n’ont aucune incitation à attirer l’attention sur eux. Au contraire, ils sont plus susceptibles de fonctionner lentement et lentement, récoltant des informations d’identification supplémentaires et peut-être s’étendant à des machines supplémentaires de votre réseau avant de tenter d’exécuter l’objectif réel de l’attaque. A en juger par les exploits communs que l'on constate, il y a de fortes chances que cet objectif soit un ransomware attaque qui entraînerait l'arrêt de vos opérations, mais il peut également s'agir d'un vol de votre propriété intellectuelle ou des informations personnelles de vos employés ou clients.

Vendre l'accès

Alternativement, l'attaquant peut ne pas utiliser lui-même l'accès au réseau. Au lieu de cela, ils pourraient vendre leur accès au serveur à un tiers sur le dark web.

Résultat final : exposition aux mouvements latéraux et à la propagation des ransomwares

D'une manière ou d'une autre, il peut très bien y avoir des attaquants avec les clés de votre royaume, à savoir les noms d'utilisateur et les informations d'identification de vos utilisateurs standard et administrateurs. C'est mauvais parce que si le compromis initial endommage une seule machine, c'est le mouvement latéral partie qui transforme un événement local en un risque à l'échelle de l'entreprise. Les informations d'identification compromises permettent aux attaquants de faire exactement cela.

L'effet de Noël

N'oublions pas que les attaquants optent généralement pour les vacances et les week-ends. Les prochaines vacances de Noël sont un moment particulièrement difficile pour que les informations d'identification de vos employés soient entre de mauvaises mains. Nous pensons que les attaquants des deux types décrits ci-dessus resteront silencieux en attendant, attendant la bonne heure - Noël peut être le moment idéal.

Silverfort Recommandations de meilleures pratiques pour les informations d'identification compromises

À la lumière de tout ce qui précède, nous avons compilé un ensemble de meilleures pratiques exploitables pour faire face de manière proactive à la possibilité que certains de vos serveurs aient été et soient peut-être encore compromis par des attaquants qui exploité la vulnérabilité Log4Shell:

• Correctif de bout en bout
  • Assurez-vous que tous les systèmes vulnérables sont corrigés en accordant une attention particulière à vos serveurs connectés à Internet.

• • Isolez les applications que vous ne pouvez pas corriger à la fois au niveau du réseau et au niveau de la couche d'identité.

• Empêcher les attaquants d'utiliser le Identifiants compromis pour un accès malveillant supplémentaire

• • Exiger MFA pour tous les comptes d'administrateur pour toutes les ressources de l'environnement. Assurez-vous également que la protection MFA s'applique aux interfaces d'accès, y compris les utilitaires de lignes de commande tels que PsExec, PowerShell, etc., et pas seulement pour se connecter à RDP et au bureau.
  • Restreindre les comptes de service fonctionner uniquement à partir d'ordinateurs autorisés. Vous devez vous baser sur le comportement prévisible et répétitif de ces comptes.
  • Surveillez de près votre environnement pour détecter les événements suspects et malveillants tels qu'une augmentation des demandes d'accès simultanées d'un seul utilisateur ou tout autre écart par rapport à l'activité standard de votre compte utilisateur.

Suivre ces recommandations augmentera considérablement votre résilience à un compromis préexistant basé sur Log4Shell et annulera la capacité de l'attaquant à exploiter ses informations d'identification volées pour un accès malveillant supplémentaire.

La Silverfort La plate-forme Unified Identity Protection permet à ses utilisateurs d'étendre Authentification Active Directory basée sur les risques et MFA à tout utilisateur, service ou système, offrant une protection proactive contre les attaques basées sur l'identité qui utilisent des informations d'identification compromises pour accéder aux ressources ciblées. Cela inclut une protection MFA de bout en bout, ainsi qu'une surveillance continue de toutes les authentifications sur site et dans le cloud. En savoir plus sur Silverfort ici.