Salutations! Ayant vu suffisamment d'intérêt pour ce qui se passe à The Standoff dans les rangs des défenseurs des PHDays 9, nous avons décidé de parler de la façon dont la préparation et la "confrontation" se sont déroulées à travers les yeux du Jet CSIRT au sein de l'équipe Jet Security.
Guo Standoff, j'ai créé
Quelque chose comme ça, les collègues ont rapporté que nous participons à nouveau à The Standoff, et nous avons naturellement accepté.
Il faut dire tout de suite que pour les défenseurs de cette année, le format de la compétition a quelque peu changé. Toutes les équipes ont reçu des infrastructures de bureaux très similaires, ce qui a permis aux organisateurs d'entrer un classement de défenseurs dans certains perroquets. Et pour l'équipe Jet Security, c'était la première "Confrontation", où le bureau était défendu, et non l'infrastructure industrielle.
Nous avons eu accès à l'infrastructure pour préparer la cyber-bataille fin avril. Après l'audit de l'infrastructure, tout un wagon de déficiences a été assemblé, en voici quelques-unes. Absolument dans toute l'infrastructure, il n'y avait pas de correctifs réels. Les mots de passe de tous les utilisateurs peuvent être obtenus via Ntds.dit en texte clair. De plus, certains utilisateurs avaient des mots de passe de la liste TOP-500 ou des mots de passe avec un hachage facilement réversible. Le durcissement du système était pratiquement nul ou nul. Certains hôtes de la DMZ avaient une interface dans le sous-réseau du serveur.
Sur la base des résultats de l'audit, nous avons développé certaines mesures de sécurité, à leur tour, les organisateurs, après approbation préalable, nous ont permis d'appliquer les politiques dont nous avions besoin et d'apporter tous les outils de sécurité et les outils qui peuvent être déployés dans un environnement virtuel. En raison des délais serrés, certaines idées sur les mesures de protection sont tombées au départ. Les principaux réglages et le profilage du SPI ont été effectués pendant les vacances de mai (bonjour à tous ceux qui ont jeté des photos des pique-niques, nous vous aimons aussi), et certains des équipements de protection ont dû être ajustés juste avant le départ, directement sur le site. De plus, un certain nombre de services étaient interdits de correction et de reconfiguration stricte. Par exemple, Oracle Weblogic avec CVE-2019-2725, dont PoC a été publié au tout début de mai 2019, était l'un d'entre eux.
Eh bien, et une liste de ce que nous avons apporté avec nous:
- Pare-feu (fourni par les organisateurs a été remplacé);
- Solution antivirus;
- WAF;
- EDR
- Quelques solutions de déception;
- Une paire de scanners de vulnérabilité;
- Pile ELK pour une analyse Netflow supplémentaire;
- SIEM.
Nous devrions également parler de ce qui allait au SIEM. Comme sources d'événements, nous avions à notre disposition les journaux Windows, Sysmon, les journaux Auditd et, comme vous pouvez le deviner, les événements du SZI lui-même. S'il n'y avait pas de problèmes particuliers avec les deux premiers, et nous nous sommes rapidement mis d'accord sur des changements dans la politique et la configuration de Sysmon, alors nous avons dû lutter avec les organisateurs pour la configuration Auditd.
Parallèlement à cela, nous avons identifié les principaux vecteurs d'attaque, et sur cette base, nous avons sélectionné et adapté des scénarios et des règles de corrélation pertinents - un total d'environ 160 règles de corrélation. De plus, un ensemble de tableaux de bord hétéroclites a été assemblé pour les nœuds critiques, SZI et ce qui nécessitait une attention particulière dans l'infrastructure de jeu.
Le bras de fer
Pour The Standoff, nous avons décidé d'adhérer au concept de séparation des incidents en externe et interne, car il était parfaitement entendu que nous essaierions activement d'explorer et d'exploiter le Web de l'extérieur. Les incidents liés à la numérisation et aux tentatives de contournement du WAF ont été surveillés séparément, à une priorité inférieure, ce qui nous a permis de nous concentrer sur les incidents internes. Des tableaux de bord pour SPI ont été distribués entre les défenseurs dans les zones de responsabilité, et au moins 2 personnes ont été affectées à chaque outil - pour la possibilité de rotation et de repos.
Tout s'est passé, comme nous nous y attendions. La confrontation a commencé vers 10 heures du matin, et dès le début du processus, le système SIEM a commencé à diffuser un tas d'incidents liés à une analyse externe et à des tentatives d'agresseurs d'exploiter le Web. Dans certains cas, même le groupe n'a pas enregistré. Parallèlement à cela, les vérificateurs des organisateurs ont commencé à travailler, vérifiant l'état des différents services dans le bureau, ce qui nous a obligés à reconduire le profilage dans une certaine mesure pour éliminer les faux positifs qui leur sont associés.
Dans les toutes premières heures du jeu, l'équipe Hack.ERS a réussi à trouver les informations d'identification standard de l'administrateur (admin / admin) sur le CMS de l'une des ressources et à détecter une vulnérabilité potentielle LFI. Ces tentatives ne sont pas passées inaperçues, nos défenseurs ont mené une intervention opérationnelle et les attaquants n'ont finalement pas pu avancer davantage.
Jusqu'à la fin de la première journée de jeu, les méthodes n'ont pas changé, WAF a quand même repoussé toutes les tentatives de téléchargement de quelque chose d'intéressant sur les sites Web de la société, et les mêmes «adresses externes», sans cesse, ont essayé de scanner nos ressources.
Au total, pour l'ensemble de l'événement, 3000 incidents liés aux tentatives de scan ont été enregistrés, sans tenir compte du regroupement des événements en incidents.
Et environ 2500 incidents avec tentatives de contournement du WAF, également sans tenir compte du regroupement des événements en incidents.
Vers la nuit, l'intensité de toutes les activités a diminué - pour plusieurs raisons. Une partie des défenseurs et des attaquants n'a pas pu résister à la vérification du son et à la répétition du concert, qui devait se tenir le lendemain. Certaines équipes attaquantes ont décidé de faire une pause et de poursuivre les attaques plus près du matin dans l'espoir que les défenseurs et la surveillance auraient moins de ressources de surveillance et une certaine fatigue.
Le matin du deuxième jour, les assaillants ont changé de tactique. Des informations sur une partie de ses employés ont été publiées sur l'un des sites Web de l'entreprise. Les pirates ont profité de ces informations et ont commencé à collecter activement des comptes d'utilisateurs via Exchange (statistiques des tentatives dans la capture d'écran).
Un peu plus tard, des tentatives non sécurisées ont été faites pour sélectionner un mot de passe sur la passerelle VPN, des comptes qui n'étaient pas dans notre infrastructure ont participé à la brute. Avec une forte probabilité, les attaquants ont tenté d'utiliser des comptes de l'infrastructure déjà piratée dans l'espoir que les organisateurs les laissaient les mêmes partout. En conséquence, toute la situation avec la force brute nous a amenés à créer un groupe de tableaux de bord sur les tendances en termes d'authentification des utilisateurs. De plus, nous avons resserré la surveillance des incidents liés au succès de la force brute, mais, heureusement, aucun de ces cas n'a été détecté.
Environ une heure avant la fin du jeu, les tendances ont vu une seule tentative réussie d'authentifier plusieurs utilisateurs, y compris ceux sur Exchange, l'analyse opérationnelle a montré que les sources étaient des machines utilisateur directement, la plupart des événements ont indiqué que les organisateurs se sont connectés à partir de la console VMware Vcenter.
Dans le même temps, nous avons enregistré une analyse interne à partir d'un nœud qui s'est connecté avec succès via VPN. Après une analyse opérationnelle des événements liés à l'incident, il est devenu clair que les attaquants ont pu compromettre les informations d'identification de plusieurs utilisateurs, et à en juger par l'absence de tentatives d'authentification infructueuses, il est probable que les données utilisateur aient été «divulguées».
Des informations ont été transmises aux défenseurs. Pendant tout le temps de réponse sur les ordinateurs personnels des utilisateurs compromis, la solution de point de terminaison a été mise en mode de protection préventive pour ralentir la capacité de prendre pied dans le système. Les sessions d'attaque sur la passerelle VPN ont été abandonnées de force et les attaquants ont été expulsés du périmètre protégé. Dans l'UZ compromise, les mots de passe ont été rapidement modifiés.
À ce moment précis, les gars de l'équipe True0xA3 sont montés sur scène et ont utilisé avec succès OSINT et ont signalé le compromis du bureau Behealthy, qui est sous la protection d'une autre équipe. Les attaquants ont réussi à compromettre l'administrateur du domaine. Les organisateurs ont été informés de notre incident et des preuves ont été fournies.
La dernière heure a été particulièrement chaude en raison de la soudaine OSINT, tout le monde attendait quelques préparatifs supplémentaires de la part des organisateurs. L'équipe de surveillance, à son tour, a surveillé toutes les anomalies et incidents suspects, mais après une tentative infructueuse de pénétrer de nouvelles tentatives de piratage, elle n'a pas suivi. Les dernières minutes de jeu se sont donc écoulées et le piratage réussi du bureau protégé par la Jet Security Team n'a pas eu lieu.
Et un peu de statistiques finales pour deux jours de jeu:
- 1 200 EPS en moyenne et un peu moins de 3 000 EPS au sommet;
- Environ 7 000 incidents;
- Plus de 120 millions d'événements.
Facteurs qui nous ont aidés à gagner
- Répartition compétente des rôles. Chacun s'est installé et s'est engagé dans la plupart de ses activités quotidiennes. Personne n'a eu à étudier des matériaux de la catégorie des "pare-feu pour les nuls".
- Profilage opérationnel des règles de corrélation. Tous les faux positifs ont été traités et corrigés en fonction des caractéristiques de l'infrastructure de jeu.
- Réponse rapide. Étant donné que plusieurs personnes ont été affectées à chaque type de SZI et de systèmes, nous n'avons eu aucun problème avec le fait que la personne responsable se soit reposée ou soit partie pendant quelques minutes. Toutes les informations issues de la surveillance ont été traitées le plus rapidement possible.
- Expérience du durcissement et de la surveillance de diverses infrastructures.
PS Un merci spécial à tous ceux qui sont venus et ont posé des questions, et nous nous excusons auprès de ceux qui n'ont pas pu dire quelque chose au cours du processus - l'équipe attendait des «Cosaques maltraités» des attaquants et n'a pas pu divulguer tous les détails.
Dmitry Lifanov, expert au Centre de surveillance et de réponse aux incidents de sécurité de l'information Jet CSIRT