Brèche présumée : L’évolution de la sécurité offensive…

L’objectif de ce billet est singulier : vous informer (lecteur innocent, client ou concurrent) sur la manière dont TrustedSec tente de répondre aux besoins spécifiques de l’industrie qui se sont accrus au fil du temps en matière de tests d’intrusion présumée. Dans notre petit monde de l’infosec où les flux d’informations hautement techniques sont omniprésents et incessants, ce billet prend un chemin plus contemplatif, et espérons-le, humoristique, jusqu’à sa conclusion. Pas de remplissage GPT, ni même de mèmes, juste un regard rétrospectif sur l’industrie offensive, pondéré et teinté de shenanigan, de la part d’un gars de la campagne disposant d’une connexion Internet excessivement rapide et d’un penchant pour les toupies mentales.

Je recommande de le lire en buvant votre boisson préférée, mais pour les impatients, j’aborde les spécificités de notre modèle de test de violation présumée dans la rubrique « Scénarios ».

Une promenade salée sur le chemin des souvenirs

Depuis un certain temps, le pentesting de réseau a été largement divisé en deux catégories principales : externe et interne. Les tests externes sont généralement limités à l’adresse IP/au nom d’hôte et exécutés en boîte noire (pas d’accréditation, pas d’accès à distance, trouvez-le vous-même), et les tests internes sont généralement exécutés à partir d’un dispositif d’implantation de réseau livré au client. Ce dispositif consiste généralement en une distro Linux, par exemple Kali, Ubuntu ou BlackArch, et établit un tunnel SSH inverse vers le siège, que le testeur utilise pour se connecter et effectuer le test.

Ces concepts sont des sentiers battus avec lesquels la plupart des organisations sont raisonnablement à l’aise en 2024. Les craintes de pannes majeures ne se sont guère concrétisées, bien qu’il y ait de temps en temps un lot de comptes verrouillés et quelqu’un d’assez stupide pour tripoter le Configuration NC dans Active Directory, mais dans l’ensemble, la plus grande ombre au tableau de l’industrie de la sécurité offensive est constituée par les entreprises de test qui ne testent pas du tout, mais impriment simplement les résultats de nmap/Nessus dans un rapport. J’entends encore parler de cela et c’est aussi choquant aujourd’hui qu’il y a 10 ans. Il faut ajouter une dose supplémentaire de dégoût pour ces entreprises, car avant l’avènement des contrôles basés sur le comportement, le pentesting n’était pas seulement facile pour ceux qui connaissaient les arts sombres, c’était aussi un moyen d’améliorer la sécurité des données. glorieux.

Depuis des années, les équipes offensives s’appuyaient sur les techniques DA-by-lunch telles que Responder, Mimikatz et PowerSploit. Toutes les conférences données par les membres de l’équipe rouge insistaient sur la nécessité de respecter les « principes de base » (le moins d’accès possible, des systèmes corrigés, de bonnes bases de sécurité, etc.) ad nauseumau point de jeter l’opprobre sur les défenseurs avec des tweets à la une du genre « nous ne sommes même pas capables de respecter les règles de base, comment sommes-nous censés le faire ? ??’ Les défenseurs étaient inondés de larmes et de culpabilité, condamnés à d’interminables divulgations de failles, à des cauchemars de vacances et à des railleries « McAfee LOL » de la part de l’équipe rouge, tandis qu’un flot ininterrompu de hashdumps défilait sur l’écran dans un brouillard de shellibrations infusées au Taureau rouge. La jubilation allait cependant être de courte durée.

Pour ne pas être en reste, la défense a fait ce qu’elle fait toujours, et parfois bien : elle s’est adaptée. Comme s’ils étaient sortis de la timidité de l’adolescence, les défenseurs ont réalisé que l’AV n’allait pas les sauver et ont commencé à ingérer des quantités massives de journaux internes, déterminés à accroître la visibilité là où c’était important (à l’époque, il s’agissait des points d’extrémité). L’industrie s’est réveillée en masse aux codes d’événements importants tels que 4688, 4662 et 5145, apprenant ainsi que les précieuses données qu’ils recherchaient depuis tout ce temps n’attendaient que le bon GPO pour les activer.

Des gigaoctets et plus de journaux ont été générés, tous bien rangés dans des SIEM open-source et commerciaux tels que Splunk, Graylog et ELK Stack. Les engagements de la Purple Team sont entrés en scène, améliorant et affinant les détections, mettant pour la première fois des tableaux de bord d’alertes de haute qualité entre les mains du SOC. Et les SOC, du moins ceux qui n’ont pas supprimé ces tableaux de bord parce qu’ils n’ont jamais rien fait, ont bénéficié d’un sommeil plus paisible.

Mais les équipes de défense internes n’étaient pas les seules à prêter attention. Les fournisseurs avaient également remarqué que les outils de sécurité existants étaient inefficaces pour arrêter… eh bien, à peu près tout, ce qui laissait un vide sur le marché des outils qui fonctionnaient réellement pour détecter et prévenir les attaques réelles (et pas seulement pour « arrêter les mimikatz » lol). De nouveaux produits ont été lancés qui, pour la première fois dans l’histoire, semblaient concrétiser le rêve ultime des entreprises en matière d’infosécurité : une bonne sécurité qui pouvait être achetée. L’EDR a débarqué sur le marché avec une force incroyable et a été adopté avec enthousiasme en l’espace de quelques années seulement. La grande majorité des clients contre lesquels nous menons des équipes rouges utilisent aujourd’hui essentiellement l’un des deux systèmes de contrôle des points finaux : CrowdStrike ou Microsoft. Les deux sont efficaces. Enfin, les défenseurs ont réalisé ce qui était vrai depuis toujours : le champ de bataille leur appartient.

L’équipe rouge, habituée depuis des années à ce que les mots de passe lui soient remis (littéralement dans le cas du CCDC, ce qui n’a pas aidé notre ego), a été mise au pied du mur et a maladroitement commencé à réapprendre l’art de la curiosité, après être devenue léthargique face à l’approvisionnement incessant en journaux des répondeurs. Peu habituée à être détectée, l’équipe rouge a mis en place le « protocole fantôme » et a commencé à dissimuler les TTP dans les médias sociaux. Les simulations d’adversaires (« AdSim ») et les engagements de l’équipe rouge ont pris le devant de la scène, donnant à l’équipe rouge plus de temps pour s’adapter aux défenses et rechercher de nouvelles méthodes d’attaque. Bien que blessantes pour l’ego, les améliorations massives des défenses ont forcé les équipes rouges de premier plan à faire des investissements significatifs dans leur savoir-faire et leurs outils internes et, par conséquent, à les utiliser pour améliorer les défenses de leurs clients de manière très efficace. Les organisations qui ont tiré parti de cette situation ont bénéficié d’une amélioration considérable de leur position en matière de sécurité.

En dépit de tout ce qui se dit sur les OST et des débats mesquins mais hilarants sur les C2 et les termes tels que « bypass », la méthodologie rouge/bleue a fait ses preuves à maintes reprises. Améliorez l’équipe rouge et vous améliorerez l’équipe bleue. Presque simultanément, les défenseurs ont réalisé que l’équipe rouge avait vraiment son intérêt à cœur et que l’adversité fabriquée était vraiment une bonne chose. Les équipes rouges ont conclu à juste titre qu’une bonne défense est incroyable (peut-être même un peu… amusant…), et que s’ils y prêtent attention, les défenseurs aideront l’équipe rouge à développer de nouvelles techniques. Comment poursuivre ce cycle d’amélioration ?

Pour rester en phase avec des défenses qui semblent s’améliorer de jour en jour, les équipes rouges ont réagi par la première mesure logique : ajouter du temps d’engagement. Cela fonctionne jusqu’à un certain point, et certains clients s’engageront volontiers pour une mission de plusieurs mois de l’équipe rouge, privilégiant avant tout le réalisme et la furtivité. Mais la furtivité exige du temps, et tout le monde ne peut pas se permettre les mouvements les plus bas et les plus lents d’un réseau. L’avantage du temps continue d’être érodé par les détections basées sur le comportement qui évaluent désormais l’activité des utilisateurs en semaines et en mois. Les équipes rouges avaient besoin d’un moyen de fournir une valeur ciblée sans se ruiner.

Entrer dans la brèche supposée

Les évaluations de la violation présumée (AB) sont conçues pour imiter un scénario de menace dans lequel un attaquant a déjà obtenu l’accès au réseau interne d’une manière ou d’une autre. Mais de quels scénarios parlons-nous ? N’est-ce pas ce que fait déjà un pentest interne ? Oui. En quelque sorte. Le scénario de menace le plus proche imité par un pentest interne standard est une intrusion physique, mais même dans ce cas, l’accent est mis sur la couverture. En d’autres termes, il s’agit de savoir combien de voies d’escalade vulnérables peuvent être découvertes et quelles vulnérabilités ont été documentées en cours de route qui peuvent mettre un terme à ces voies si elles sont corrigées. Faites tout cela aussi vite que possible, en ciblant autant de systèmes que possible, puis livrez les résultats avec précision et professionnalisme.

La posture de sécurité d’une entreprise peut aller loin, et beaucoup l’ont fait, en corrigeant simplement les résultats de leur pentest. Ironiquement, la plupart des grands pentesters que je connais sous-estiment gravement leurs propres compétences. C’est peut-être une bonne chose (dans une petite mesure du moins), car les performances d’un pentest associé à une morale non contrôlée peuvent facilement basculer dans l’activité criminelle, comme le leader de LockBit y a fait allusion lors d’une réunion en 2022 interview avec vx-underground.

Toutes mes excuses pour cette digression. Quelle est donc la différence matérielle entre l’AB et le pentesting ? En bref, et j’y ai déjà fait allusion, le pentesting est couverture-alors que les AB sont basés sur la couverture scénario-sur la base d’un scénario. Les AB sont-ils une « évolution » des pentests ? Pas exactement. Les tests de pénétration continueront à être utiles tant qu’il y aura des environnements d’entreprise. Toutefois, comme nous l’avons vu plus haut, les contrôles se sont considérablement améliorés, obligeant les boutiques offensives à adapter leurs services. Même les entreprises qui ont encore des utilisateurs non informaticiens disposant de droits d’administration locaux peuvent acheter un EDR et bénéficier d’une amélioration immédiate de la sécurité de leurs points d’accès, et par conséquent d’une frustration pour l’équipe rouge. Cela signifie simplement que les Red Teams doivent restreindre l’objectif des intrusions, c’est-à-dire les tests basés sur des scénarios, pour les organisations matures.

Chez TrustedSec, nous avons identifié plusieurs scénarios de menace :

• Violation du périmètre
• Travailleur mécontent/initié malveillant
• Attaque d’ingénierie sociale réussie
• Abus de confiance
• Vol physique ou perte d’un dispositif interne
• Intrusion physique

Il s’agit bien entendu de catégories de compromission de haut niveau et elles sont censées l’être. Elles se recoupent également. Par exemple, il est facile d’envisager une attaque d’ingénierie sociale réussie qui mène à un abus d’informations d’identification. Les équipes rouges font cela tout le temps. Cela dit, il a fallu tracer certaines lignes, et nous avons tenté de le faire le plus proprement possible.

Qu’en est-il des ransomwares ? J’entends clairement la question et des clients m’ont souvent posé des questions similaires. Les rançongiciels ne constituent-ils pas un scénario de menace valable ? La réponse directe est : pas exactement. Oui, les ransomwares représentent une menace à fort impact. résultat d’un compromis, mais il n’est pas le compromis lui-même. La perte de données est également un résultat potentiel mais ne constitue pas un scénario de menace. Il est important de bien catégoriser nos termes et ce que nous entendons par là. En outre, les conditions requises pour déployer un ransomware sont similaires aux objectifs d’élévation standard dans le cadre d’un exercice AB ou Red Team. Avant de pouvoir déployer un ransomware à grande échelle, l’attaquant doit disposer de privilèges élevés sur les hôtes cibles. En résumé, corrigez les voies d’escalade découvertes lors d’un exercice AB et vous « contiendrez l’explosion » d’un déploiement de ransomware. Demandez à votre sympathique Red Teamer de découvrir les chemins liés aux systèmes de sauvegarde. xD

Scénarios

TrustedSec a élaboré sept scénarios AB destinés à couvrir ces scénarios de menace. En regardant le tableau ci-dessous, vous pourriez penser que certains scénarios ne font pas partie de votre modèle de menace. C’est tout à fait normal (voire discutable), car l’objectif est de fournir différents types de tests ciblés qui chevaucheront votre modèle de menaces.

1) Compromis de la signature unique

• Scénario(s) de menace: Travailleur mécontent, attaque réussie d’ingénierie sociale (ES), abus d’identité
• Description: Simulant la compromission d’un compte O365, TrustedSec tentera d’accéder à des services tiers attachés au locataire O365 en utilisant le SSO, en exfiltrant et en analysant les informations accessibles. L’analyse du réseau interne, si elle est réalisée, n’est pas effectuée.
• Durée minimale: 1 semaine
• Exigences du client :
  • Informations sur le portail SSO (Okta, Ping, O365) à cibler.
  • Informations d’identification valides représentant un utilisateur compromis. Pour une valeur maximale, TrustedSec recommande d’utiliser un employé actif (de préférence) ou un compte récemment résilié avec des droits d’accès intacts.
  • Point de contact pour fournir un accès MFA si nécessaire.

2) Pivot du réseau

• Scénario(s) de menace: Violation réussie du périmètre du réseau, travailleur mécontent, attaque réussie de l’ES, abus de compétences
• Description: TrustedSec travaillera avec un employé fourni par le client pour simuler la compromission qui peut être obtenue par une attaque d’ingénierie sociale réussie. A l’aide d’une infrastructure et de charges utiles autorisées, le C2 de la machine d’un utilisateur est établi et utilisé pour attaquer le réseau dans la poursuite ciblée d’un objectif unique de post-exploitation. La mission se concentre sur les activités de post-exploitation et la détection, et non sur les tests de contrôle évasif des points finaux.
• Durée minimale: 2 semaines
• Exigences du client:
  • L’un des éléments suivants :
    • Un employé interne (de préférence non informaticien) qui servira de point de terminaison compromis. TrustedSec travaillera avec l’employé pour établir un C2 non intrusif.
    • Un ordinateur portable et/ou une image Citrix VDI avec des identifiants de domaine (nom d’utilisateur/mot de passe) avec un accès qui reflète un rôle professionnel existant.
  • TrustedSec soumettra à l’avance les détails de la charge utile et de l’infrastructure pour les utilisateurs autorisés.

3) Compromission et pivotement des points d’extrémité

• Scénario(s) de menace: Violation réussie du périmètre du réseau, travailleur mécontent, attaque réussie de l’ES, abus de compétences
• Description: TrustedSec travaillera avec un employé fourni par le client pour simuler la compromission qui peut être obtenue par une attaque d’ingénierie sociale réussie. En utilisant une infrastructure personnalisée et des charges utiles évasives, le C2 de la machine de l’utilisateur est établi et utilisé pour attaquer le réseau de manière furtive et ciblée afin d’atteindre des objectifs post-exploitation.
• Durée minimale: 3 semaines
• Exigences du client:
  • Un employé interne (de préférence non informaticien) jouera le rôle de point de terminaison compromis. *TrustedSec travaillera avec l’employé pour établir un C2 non intrusif.
  • Le client peut choisir deux cibles (application, serveur, adresse IP, niveau d’accès).

*Remarque : un « ordinateur portable de réserve » ou « une image d’or » avec des identifiants de domaine génériques n’est pas pris en charge pour cette évaluation, car les attaquants s’appuient fortement sur l’utilisation quotidienne pour la connaissance de la situation.

4) Compromission du périmètre

• Scénario(s) de menace: Violation réussie du périmètre du réseau, attaque SE réussie
• Description: Simulant la compromission d’une application web externe, TrustedSec acquiert le C2 d’un serveur web ou d’un serveur de base de données désigné (attaque par injection SQL réussie) et tente d’ouvrir une brèche dans une application ciblée ou un environnement réseau à partir d’une variété de points de vue. Cela peut prendre diverses formes telles qu’un shell web ou un C2 complet.
• Durée minimale: 3 semaines
• Exigences du client:
  • L’exécution d’un implant sur un serveur web ou un serveur de base de données choisi dans le contexte du compte de l’application.
  • En fonction des règles du pare-feu, une dérogation peut être nécessaire pour autoriser le trafic sortant nécessaire.

5) DevOps

• Scénario(s) de menace: Travailleur mécontent, Abus de confiance
• Description: En utilisant un ordinateur portable fourni par le client, TrustedSec se connectera au réseau interne et recherchera les vulnérabilités liées aux opérations de développement, telles que les privilèges de repo, les informations d’identification codées en dur et l’accès inapproprié à l’infrastructure. Les attaques sont très ciblées sur l’environnement DevOps du client et l’infrastructure correspondante.
• Durée minimale: 3 semaines
• Exigences du client:
  • Un compte doté de privilèges de développeur
  • Ordinateur portable avec la version développeur standard
  • Accès à distance à l’environnement DevOps

6) Compromission des postes de travail

• Scénario(s) de menace: Travailleur mécontent, vol physique ou perte d’un appareil
• Description: TrustedSec testera une station de travail physique ou une image Citrix VDI pour une variété de fausses configurations de sécurité, y compris les vulnérabilités matérielles et logicielles, le cas échéant. L’exploitation est généralement limitée à la machine locale et ne traverse pas les limites du réseau. Tout matériel fourni peut être désassemblé à la discrétion de TrustedSec.
• Durée minimale: 2 semaines
• Exigences du client:
  • Ordinateur portable avec accès standard et/ou Citrix VDI
  • Identifiants de connexion pour les non-administrateurs
  • (Facultatif) Accès à distance au réseau de l’entreprise

7) Violation physique

• Scénario(s) de menace: Travailleur mécontent, intrusion physique réussie
• Description: TrustedSec simulera une compromission physique réussie en envoyant un dispositif spécial qui peut échapper à la plupart des systèmes NAC et ne nécessite aucune exemption de pare-feu sortant. Destiné à être un dispositif réellement furtif, TrustedSec utilisera la connexion correspondante pour compromettre le réseau à l’aide de techniques standard.
• Durée minimale: 2 semaines
• Exigences du client:
  • Une machine physique avec une connectivité réseau interne persistante
  • Proximité d’un service cellulaire LTE

Conclusion

J’espère que cet article vous a donné matière à réflexion sur votre propre modèle de menace et sur la manière dont il pourrait s’appliquer à vos prochaines séries de tests offensifs, et si je vous ai fait sourire en cours de route, c’est un bonus heureux. Si vous faites partie d’une équipe interne, vous pouvez plier et adapter ces scénarios à votre avantage, car vous disposez sans aucun doute de plus de temps et de capacités qu’une tierce partie.

Et si vous m’avez suivi aussi longtemps, vous méritez une promenade, ou une gorgée, comme bon vous semble.

A la vôtre !