Résumé
Okta Threat Intelligence a découvert une plateforme d’hameçonnage en tant que service (PhaaS) nouvelle, sophistiquée et activement déployée, ciblant les comptes Microsoft 365 et Google Workspace, que nous suivons sous le nom de VoidProxy ou O-TA-083.
L'activité de VoidProxy PhaaS est observée depuis au moins janvier 2025, et de nouveaux domaines et tentatives d'usurpations de compte (ATO) sont observés quotidiennement. La plateforme est utilisée pour cibler des organisations dans de multiples secteurs d'activité.
VoidProxy exploite les techniques d'Adversaire-au-Milieu (AitM) pour intercepter les flux d'authentification en temps réel, capturer les identifiants et les codes d'authentification multifacteur (MFA), et voler les cookies de session, contournant ainsi les protections MFA.
Cette capacité rend inefficaces les méthodes d'authentification multifacteur courantes, telles que les codes SMS et les mots de passe à usage unique (OTP) des applications d'authentification. Cependant, Okta offre un choix d'authentificateurs résistants au phishing, notamment Okta FastPass, qui a empêché toutes les tentatives d'usurpation de compte (ATO) de VoidProxy lors des attaques que nous avons observées.
L'objectif principal de VoidProxy est de compromettre les comptes d'entreprise afin de faciliter les activités malveillantes ultérieures, telles que la compromission de l'e-mail professionnelle (BEC), la fraude financière, l'exfiltration de données et le mouvement latéral au sein des réseaux des victimes.
Compte tenu de son modèle PhaaS, VoidProxy abaisse la barrière technique pour un large éventail d'acteurs malveillants afin d'exécuter des attaques de phishing AitM, amplifiant considérablement son impact potentiel. La plateforme représente une menace mature, évolutive et évasive qui met au défi la sécurité des e-mails conventionnels et les contrôles d'authentification.
Les informations contenues dans cet avis sont fournies pour permettre aux organisations de comprendre et d'atténuer les risques posés par cette menace.
VoidProxy - Principaux points à retenir
Analyse des menaces
Anatomie d’une attaque : la chaîne de frappe (kill chain) VoidProxy
La méthodologie d'attaque VoidProxy suit une chaîne de frappe (kill chain) à plusieurs étapes conçue pour contourner systématiquement les contrôles de sécurité et tromper les utilisateurs finaux. Chaque étape est soigneusement orchestrée, tirant parti d'une infrastructure distribuée pour atteindre son objectif d'usurpation de compte (ATO).
Étape 1 : Livraison
Le vecteur initial d'une attaque VoidProxy est un e-mail de phishing ciblant les utilisateurs de services cloud majeurs tels que Microsoft 365 et Google Workspace.
Pour contourner les contrôles de sécurité standard, les opérateurs utilisent des fournisseurs de services d'e-mail (ESP) légitimes et de haute réputation. Nous avons observé l'utilisation de Constant Contact, Active Campaign (Postmarkapp), NotifyVisitors et autres pour envoyer leurs appâts malveillants. Il s'agit d'un choix délibéré, car les e-mails provenant des plages d'adresses IP fiables de ces services sont moins susceptibles d'être signalés comme spam ou malveillants par les passerelles d'e-mail.
Intégré dans ces e-mails se trouve un lien qui utilise souvent des services de raccourcissement d'URL légitimes comme TinyURL pour masquer l'adresse réelle de la page de phishing. Cela sert à masquer la véritable destination à la fois à l'utilisateur et aux scanners automatisés, augmentant ainsi la probabilité que l'utilisateur clique sur le lien et atteigne la destination finale.
Redirections de TinyURL vers des pages de phishing
Dans une campagne, un acteur malveillant s'est fait passer pour le service des RH d'Okta afin d'inciter le destinataire à cliquer sur un lien malveillant pour une fiche de paie numérique.
Figure 2 : Un message de phishing intercepté utilisant abusivement Constant Contact
En analysant plus avant l'activité de VoidProxy, nous avons découvert un document DocuSign frauduleux, hébergé sur la plateforme Zoom Docs, qui a également été utilisé pour tromper les victimes.
Figure 3 : L'appât DocuSign livré via Zoom Docs, identifié à l'aide d'AnyRun
Figure 4 : Une analyse AnyRun montre la redirection d’un lien Zoom Doc vers le domaine de phishing.
Étape 2 : Évasion et chargement de leurres via Cloudflare Workers
Lorsqu'un utilisateur ciblé clique sur le lien malveillant, il n'est pas directement dirigé vers un formulaire de connexion. Au lieu de cela, le site de phishing présente une demande d'authentification CAPTCHA Cloudflare. Ceci est conçu pour filtrer les scanners de sécurité et les bots automatisés, garantissant que seuls les utilisateurs humains passent à l'étape suivante.
Figure 5. Un CAPTCHA Cloudflare présenté à un utilisateur ciblé sur le domaine de phishing
Le navigateur de l'utilisateur communique alors avec un Cloudflare Worker (*.workers.dev). Nous pensons que ce worker agit probablement comme un gardien et un chargeur d'appâts. Ses fonctions principales sont de filtrer le trafic entrant et de charger la page de phishing appropriée pour une cible donnée. Cette architecture sépare le filtrage initial des opérations de phishing principales de la campagne. Une fois qu'une demande d'authentification est relevée, l'utilisateur est présenté avec la page de phishing finale, qui est une réplique parfaite d'un portail de connexion légitime.
Les domaines de phishing utilisent les modèles suivants :
- Pour les cibles Microsoft 365 : connexion. <phishing_domain>.<tld>
- Pour les cibles Google Workspace : comptes. <phishing_domain>.<tld>
Figure 6 : Une page de phishing VoidProxy ciblant les comptes Google
Figure 7 : Une page de phishing VoidProxy ciblant les comptes Microsoft
Si la page de phishing détecte que le visiteur est un scanner ou un outil de sécurité plutôt qu'une cible prévue, elle renvoie une page blanche qui affiche le texte « Bienvenue! ».
Figure 8. Une page de phishing affiche un message de « Bienvenue ! » page pour les visiteurs indésirables
Étape 3 : Interception des identifiants pour les comptes protégés par authentification unique
Cette étape révèle la nature sophistiquée et multicouche de VoidProxy, en particulier sa capacité de compromission de cibles de grande valeur qui utilisent des fournisseurs d’identité comme Okta.
Une fois que la victime a entré ses identifiants Microsoft ou Google primaires sur la page de phishing, les données sont redirigées vers le serveur proxy AiTM principal (hébergé sur l’infrastructure sslip.io/nip.io).
Si le proxy détecte que le compte est fédéré via Okta, l’utilisateur est redirigé de manière transparente vers une deuxième page de phishing, qui imite le widget d’authentification Okta spécifique à l’organisation.
Cette page de phishing de deuxième étape utilise un ensemble différent de modèles de sous-domaines :
- Okta (via un appât Microsoft) : newnewdom<random>.<phishing_domain>. <tld>
- Okta (via un leurre Google) : securedauthxx<random>.<phishing_domain>. <tld>
securedauthxxccbgchgfj.xhfwez[.]icu
securedauthxxdcigbjdddj.losozr[.]icu
securedauthxxeafihgjdhb.dcohcv[.]icu
newnewdomnewcgbdhghjhi.prophfrot[.]top
newnewdomnewebjjfjegfd.eeocl[.]com
newnewdomnewdihbddahf.access-point[.]icu
Figure 9. Exemple de modèles de sous-domaine générés pour les utilisateurs protégés par authentification unique
Étape 4 : Relais AitM et détournement de session
Dans la phase finale de l'attaque de phishing, un serveur proxy central hébergé sur l'infrastructure sslip.io ou nip.io exécute une attaque de type Adversary-in-the-Middle (AitM).
Le serveur agit comme un reverse proxy pour capturer et relayer des informations, notamment les noms d'utilisateur, les mots de passe et les réponses d'authentification multifacteur, vers des services légitimes tels que Microsoft, Google et Okta. Ce processus entraîne la prise de contrôle du compte par l'acteur malveillant.
Infrastructure VoidProxy
VoidProxy emploie une approche multicouche composée d'étapes distinctes, chacune ayant ses propres caractéristiques spécifiques.
L'infrastructure opérationnelle de VoidProxy est une combinaison de front-ends jetables à rotation rapide et d'un backend plus persistant et résilient hébergé sur une architecture sans serveur.
Modèles de domaine et de sous-domaine
Les opérateurs de VoidProxy adhèrent à un ensemble cohérent de modèles pour le déploiement de l'infrastructure :
- Domaines de phishing : Les pages principales sont hébergées sur des domaines enregistrés avec une variété de domaines TLD à faible coût et à faible réputation, tels que .icu, .sbs, .cfd, .xyz, top et .home. Cette stratégie minimise les coûts opérationnels et permet aux attaquants de traiter les domaines comme des actifs jetables, en les abandonnant rapidement une fois qu'ils sont identifiés et mis sur liste noire. Les sites de phishing sont placés derrière Cloudflare, masquant efficacement l'adresse IP réelle du serveur du site de phishing et rendant plus difficile pour les équipes sécurité de retracer et de supprimer l'hôte malveillant.
- Préfixes de sous-domaine : L’analyse de plusieurs URL VoidProxy révèle l’utilisation récurrente de préfixes de sous-domaine spécifiques, notamment : accounts, connexion, portail, securedauthxx et newnewdom. Nous estimons qu’il est probable que ces préfixes soient générés automatiquement par le script de déploiement du kit afin de cibler les modèles utilisés par des fournisseurs d’identité spécifiques.
Filtrage de sécurité à l'aide de Cloudflare Workers
Comme décrit ci-dessus, la plateforme PhaaS utilise une architecture distribuée. Cloudflare Workers (*.workers.dev) agit comme un portier initial, servant le contenu phishing et effectuant des vérifications préliminaires, telles que la présentation d’une demande d'authentification Cloudflare CAPTCHA.
Un aperçu intéressant du modèle opérationnel de VoidProxy PhaaS provient de la convention de nommage de ses terminaux Cloudflare Worker. Après avoir analysé plusieurs cas, un modèle cohérent est apparu : tous les terminaux Cloudflare Worker ont été conçus en utilisant la même construction de nommage. L'acteur malveillant a utilisé des noms anglais à consonance plausible comme aidenveliz, kelvingomez et sammybruce dans le sous-domaine :
<alphanumeric>.<firstnamelastname>.workers.dev.
Ce modèle suggère fortement un système de provisionnement automatisé ou semi-automatisé pour les clients PhaaS (cybercriminels qui louent le kit). La création et la gestion manuelles de comptes Cloudflare uniques pour chaque acteur malveillant ayant acheté le kit seraient inefficaces et difficiles à mettre à l'échelle. Au lieu de cela, il est probable que les opérateurs de VoidProxy utilisent un compte maître ou une clé API pour générer cette infrastructure par programmation. Le <firstnamelastname> composant <prénomnom> généré de manière aléatoire sert probablement d'espace de noms unique pour un client spécifique ou une campagne à grande échelle. Le <alphanumeric> préfixe <alphanumérique> sert ensuite d'identifiant unique pour une instance de page de phishing spécifique déployée par ce cybercriminel. Cette architecture fournit une couche d'isolation entre les acheteurs du kit et rend plus difficile pour les chercheurs de lier toute l'activité de VoidProxy à une seule entité de contrôle.
Figure 10 : Exemples d'abus des Cloudflare Workers
Infrastructure principale de proxy et de C2
Le cœur du fonctionnement de VoidProxy - à la fois le reverse proxy AiTM et le panneau d'administration de l'attaquant - est hébergé sur des serveurs accessibles via les services DNS dynamiques wildcard sslip.io et nip.io. Ces services sont conçus pour résoudre les noms d'hôtes avec des adresses IP embarquées directement vers ces IP, une fonctionnalité destinée au développement qui a maintenant été militarisée à des fins malveillantes.
Cette infrastructure sert de :
- Moteur proxy AitM : Il s’agit du serveur qui effectue l’attaque de l’intercepteur (adversaire-intercepteur), relayant le trafic entre la victime et le service légitime afin de voler les cookies de session.
- Panneau d’administration de l’attaquant : Ces URL hébergent également le panneau web que les clients PhaaS utilisent pour configurer des campagnes, surveiller les victimes en temps réel et accéder aux données volées.
L'utilisation du préfixe « voidproxy » est un marqueur d'auto-identification pour cette infrastructure C2. Cette architecture, qui sépare le chargement initial de l'appât sur les domaines d'URL de phishing de la logique centrale (*.sslip.io), démontre une approche sophistiquée et multicouche conçue pour l'efficacité opérationnelle et la résilience.
Infrastructure utilisée dans l’activité d'usurpation de compte (ATO)
Okta Threat Intelligence a observé plusieurs tentatives d'usurpation de compte (ATO) suite à des campagnes de phishing VoidProxy réussies.
Les tentatives d'usurpation de compte (ATO) ont réussi contre les utilisateurs qui s'appuient sur des méthodes d'authentification multifacteur (MFA) non résistantes au phishing (telles que les OTP et les requêtes push). Les capacités AitM de VoidProxy permettent aux attaquants d'intercepter et de relayer ces codes à usage unique et notifications push en temps réel, contournant ainsi efficacement la demande d'authentification MFA (authentification multifacteur).
En revanche, Okta FastPass a empêché avec succès toutes les tentatives d'usurpation de compte (ATO). FastPass lie l'authentification au domaine et au terminal légitimes, ce qui rend impossible pour les proxys AitM d'intercepter et de relire les informations de session valides.
Cela démontre l'importance cruciale de déployer l'authentification multifacteur résistante au phishing pour atténuer efficacement les menaces provenant de plateformes PaaS sophistiquées comme VoidProxy.
Après une compromission réussie des identifiants de l’utilisateur, le ou les cybercriminels ont été vus en train de tenter de s’authentifier à partir d’adresses IP qui étaient principalement hébergées sur les ASN suivants :
- AS36352 - HostPapa
- AS149440 - Evoxt Enterprise
- AS210558 - 1337 Services GmbH
- AS401120 - cheapy.host LLC
- AS23470 - ReliableSite.Net LLC
Figure 11 : Tableau de bord des fournisseurs d'hébergement derrière l'infrastructure VoidProxy
Le panneau d'administrateur de VoidProxy
L'analyse du kit de phishing révèle un panneau d'administration complet qui permet aux clients PhaaS de gérer et de surveiller leurs campagnes. Ce panneau fournit une interface complète pour orchestrer les attaques et collecter les données volées.
Figure 12 : Page de connexion administrateur VoidProxy
En effectuant une analyse plus approfondie de la page Web du panneau d'administrateur, nous avons observé les
différentes capacités et services offerts par le PhaaS.
Page de tableau de bord (/dashboard)
Figure 13 : Tableau de bord du panneau d'administration VoidProxy
Cette page sert de hub central pour l'opérateur, fournissant une vue d'ensemble de haut niveau des performances de la campagne et de l'activité récente. Les métriques clés affichées comprennent :
- Aperçu de la campagne
- Nombre total de clics et nombre total de soumissions
- Vol d’identifiants
- Activité récente et fil d'actualité
- Emplacements des victimes
Page Campagnes (/tableau de bord/campaigns)
Figure 14 : Page des campagnes du panneau d'administration de VoidProxy
Cette section du panneau d'administration est dédiée à la création et à la gestion des campagnes de phishing. Elle comporte un tableau de données avec une fonctionnalité permettant de contrôler chaque campagne.
- Gestion : les opérateurs peuvent créer une « Nouvelle campagne » ou gérer celles qui existent déjà.
- Détails : les colonnes affichent « Nom de la campagne », « Service cible » (par exemple, Microsoft 365, Google), « Statut » (Actif, En pause) et « Date de création ».
- Métriques : les statistiques clés comme le « Nombre total de clics » et le « Nombre total de soumissions » sont affichées pour chaque campagne.
- Actions : les opérateurs peuvent « Démarrer », « Arrêter », « Suspendre » ou « Supprimer » des campagnes.
Page de campagne individuelle (/tableau de bord/campaigns/[campaign_id])
Cette page offre une vue détaillée et granulaire d'une seule campagne, permettant à l'opérateur d'inspecter les données et les logs capturés.
- Log des victimes : fournit des logs détaillés des interactions des victimes.
- Données capturées : affiche toutes les données volées, y compris les "identifiants volés", les "Cookies de session", les "Adresses IP" et les "agents utilisateurs".
- Actions : comprend une option pour « Télécharger le log » pour une analyse hors ligne.
Page des paramètres (/tableau de bord/settings)
Figure 15 : Page des paramètres des campagnes du panneau d'administration de VoidProxy
Cette page permet à l’opérateur de configurer la plateforme et de l’intégrer à d’autres services pour l’exfiltration de données et les notifications.
- Gestion de compte : comprend les options permettant de « modification du mot de passe » et de gérer les « clés API ».
- Intégrations : les opérateurs peuvent configurer un « token de bot Telegram » ou une « URL de webhook » générique pour recevoir des notifications en temps réel et exfiltrer automatiquement les données volées.
Liaison de VoidProxy à des identités clandestines
Après avoir analysé la campagne, Okta Threat Intelligence a étudié l'écosystème clandestin à la recherche d'une activité qui pourrait lier cette nouvelle plateforme PhaaS à un acteur malveillant spécifique.
La recherche a révélé un message Telegram daté d'août 2024 publié sur le canal « BIGFATCHAT™ » — un canal connu pour abriter des escrocs — où un utilisateur sous le pseudonyme VOID proposait un service pour « contourner toutes les 2FA ».
Figure 16 : Cette chaîne Telegram était inactive au moment de la publication.
Le service, au prix de 250 $ à l’époque, promet de contourner les connexions 2FA d’AOL, Yahoo, iCloud, Live, Google et Office 365 (ADFS, GODADDY, ΟΚΤΑ). Un message contenait une capture d’écran montrant un service nommé « voidproxy » en cours d’exécution sur ce qui semblait être un serveur AWS. La capture d’écran a révélé que plusieurs composants du service étaient actifs, y compris un « MITMSERVER » (serveur Man-in-the-Middle), qui était déjà configuré pour contourner les flux d’authentification pour des plateformes comme Google et Office 365.
Notamment, l'infrastructure semblait conçue pour intercepter les cookies de session, qui étaient exfiltrés via des bots Telegram mentionnés dans l'interface. La présence d'un serveur AitM, ainsi que ces indicateurs, suggère fortement que cette configuration était un environnement Phaas pleinement opérationnel, prêt à collecter des identifiants et à détourner des sessions utilisateur.
Figure 17 : Capture d'écran VoidProxy jointe à une publicité sur le dark web
L'utilisateur derrière le service est actif dans la cybercriminalité depuis au moins 2022, s'engageant initialement sur plusieurs chaînes Telegram anglophones, dont beaucoup sont associées à des activités liées à l'escroquerie.
Opérant sous les alias VOID et GODLESS666, l'individu a démontré un intérêt précoce pour les stratagèmes BEC et a cherché des partenaires pour réaliser ce qu'il appelait « le phishing par SMS » (alias smishing).
En 2023, VOID a commencé à s'intéresser aux fournisseurs de services d'identité, recherchant spécifiquement les identifiants pour Okta et Duo Security. L'équipe Okta Threat Intelligence a trouvé des pseudonymes supplémentaires utilisés par VOID, qui incluent « godlessvoid666 », un utilisateur actif sur le forum anglophone bien connu « Breached ».
Figure 18 : profil utilisateur VOID
Au moment de la rédaction de ces lignes, aucun lien définitif n'a été établi pour confirmer que cet utilisateur est directement affilié à VoidProxy Phaas, comme mentionné dans ce rapport d'avis de menace. Toutefois, sur la base des indicateurs contextuels et du mode opératoire décrits ci-dessus, une telle affiliation peut être évaluée avec un niveau de confiance modéré.
Réponse aux Menaces
Ce que nous faisons :
Nous sommes activement impliqués dans les activités suivantes pour atténuer cette menace :
- Surveillance continue des nouveaux domaines d’hameçonnage et des infrastructures associées à cette campagne.
- Dépôt proactif de signalements d’abus auprès des registraires et des fournisseurs d’hébergement concernés afin de lancer des demandes de retrait pour les sites malveillants identifiés.
- Alimenter un flux continu d'indicateurs de menace pertinents dans Okta Identity Threat Protection avec Okta Al.
- Fournir des conseils et une assistance aux organisations afin d'améliorer la sécurité de leurs environnements Okta et d'enquêter sur toute activité suspecte liée à des comptes potentiellement compromis.
Contrôles de protection
Recommandations pour les clients
- Inscrivez les utilisateurs à des authentificateurs forts tels que Okta FastPass, FIDO2 WebAuthn et les cartes à puce, et appliquez la résistance au phishing dans la politique. Si des exceptions sont faites pour les notifications push Okta Verify, nous recommandons d'appliquer des demandes d'authentification numériques pour toutes les tentatives de connexion ou pour les tentatives de connexion à haut risque.
- Les politiques d’authentification Okta peuvent également être utilisées pour restreindre l’accès aux comptes d’utilisateurs en fonction d’une série de conditions préalables configurables par le client. Nous recommandons aux administrateurs de restreindre l’accès aux applications sensibles aux terminaux qui sont gérés par les outils de gestion des terminaux et protégés par les outils de sécurité des terminaux. Pour accéder aux applications moins sensibles, exigez des terminaux enregistrés (utilisant Okta FastPass) qui présentent des indicateurs d'hygiène de base.
- Refuser ou exiger un niveau d'assurance plus élevé pour les demandes provenant de réseaux rarement utilisés. Avec Okta Network Zones, l'accès peut être contrôlé par emplacement, ASN (Autonomous System Number), IP et IP-Type (qui peut identifier les proxys d'anonymisation connus).
- Les évaluations Okta Behavior and Risk peuvent être utilisées pour identifier les demandes d'accès aux applications qui s'écartent des modèles d'activité utilisateur établis précédemment. Les politiques peuvent être configurées pour effectuer une authentification renforcée ou refuser les demandes en utilisant ce contexte.
- Formez les utilisateurs à identifier les indicateurs d’e-mails suspects, de sites d’hameçonnage et de techniques d’ingénierie sociale courantes utilisées par les attaquants. Facilitez le signalement des problèmes potentiels par les utilisateurs en configurant les Notifications de l'utilisateur final et le Signalement d'activité suspecte.
- Documenter, promouvoir et respecter un processus normalisé de validation de l'identité des utilisateurs distants qui contactent le personnel de support informatique, et vice versa.
- Adoptez une approche de « privilèges permanents nuls » pour l'accès administratif. Attribuez aux administrateurs des Rôles d'administrateur personnalisés avec le minimum d'autorisations requises pour les tâches quotidiennes, et exigez une double autorisation pour l'accès JIT (en flux tendu (JIT)) aux rôles plus à privilèges.
- Appliquez la liaison de session IP à toutes les applications administratives pour empêcher la relecture des sessions administratives volées.
- Activez les Actions Protégées pour forcer la réauthentification chaque fois qu'un utilisateur administratif tente d'effectuer des actions sensibles.
Observation et réponse à l'infrastructure de phishing :
- Examinez les logs d'application (logs Okta, proxies Web, systèmes d'e-mail, serveurs DNS, pare-feu) pour toute preuve de communication avec de tels domaines suspects.
- Surveillez régulièrement les domaines pour vérifier si le contenu change.
- Si le contenu hébergé sur le domaine viole les droits d'auteur ou les marques légales, envisagez de fournir des preuves et d'envoyer une demande de retrait auprès du registraire de domaine et/ou du fournisseur d'hébergement Web.
Annexe A : Indicateurs de compromission
Il s'agit d'une enquête en cours et des IOC supplémentaires peuvent être identifiés à mesure que la campagne évolue. Il est conseillé aux organisations de rester vigilantes et de mettre en œuvre les stratégies d'atténuation recommandées. Voici les IOC observés.
| Type | Indicateur | Comment | Vu à |
|---|---|---|---|
| Domaine | connexion.<phishing.page>.<tld> | Domaine de phishing ciblant Microsoft | 08.2024 - 08.2025 |
| Domaine | accounts.<phishing_domain>.<tld> | Domaine de phishing ciblant | 08.2024 - 08.2025 |
| Domaine | newnewdom<random>. <phishing_domain.tld> | Domaine de phishing à partir d'une redirection vers Okta via Microsoft | 01.2025 - 08.2025 |
| Domaine | securedauthxx<random>. <phishing_domain>.domaine TLD | Domaine de phishing à partir d’une redirection vers Okta via Google | 01.2025 - 08.2025 |
| Domaine | <alphanumeric>. <firstnamelastname>.workers.dev. | Cloudflare Workers infrastructure | 01.2025 - 08.2025 |
| Numéro AS | AS36352 - HostPapa | Infrastructure utilisée par le Proxy | 01.2025 - 08.2025 |
| Numéro AS | AS149440 - Evoxt Enterprise | Infrastructure utilisée par le Proxy | 01.2025 - 08.2025 |
| Numéro AS | AS210558 - 1337 Services GmbH | Infrastructure utilisée par le Proxy | 01.2025 - 08.2025 |
| Numéro AS | AS401120- cheapy.host LLC | Infrastructure utilisée par le Proxy | 01.2025 - 08.2025 |
| Numéro AS | AS23470 - ReliableSite.Net LLC | Infrastructure utilisée par le Proxy | 01.2025 - 08.2025 |
Des indicateurs supplémentaires sont également disponibles dans un avis non expurgé que les clients Okta peuvent télécharger sur security.okta.com
Une note sur la langue d'estimation
Les équipes d'Okta Threat Intelligence utilisent les termes suivants pour exprimer la probabilité, comme indiqué dans la directive 203 de la Communauté du renseignement du Bureau du directeur du renseignement national des États-Unis - Normes analytiques.
| Probabilité de survenue | Presque aucune chance | Très peu probable | Peu probable | Environ une chance égale | Probable | Fort probablement | Presque certain(ement) |
|---|---|---|---|---|---|---|---|
| Probabilité | À distance | Très improbable | Improbable | À peu près probabilités égales | Probable | Très Probable | Presque Certain |
| Pourcentage | 1-5 % | 5 - 20 % | 20-45 % | 45-55% | 55-80 % | 80-95 % | 95-99 % |