Dans un établissement financier, le push bombing ne cible presque jamais le client final : il cible le collaborateur, parce qu'un poste de back-office paiement donne accès à des opérations qu'un compte client ne permettra jamais. L'attaquant détient déjà un identifiant valide et transforme la notification d'approbation en dernier verrou à faire sauter, par répétition ou par téléphone.
Les actifs qui rendent le compte interne intéressant
Un accès collaborateur bancaire ouvre sur des objets dont la valeur se mesure en minutes.
- Les outils d'exécution et de validation de virements, où l'irrévocabilité du virement instantané supprime la fenêtre de rattrapage habituelle.
- Les référentiels bénéficiaires et coordonnées bancaires : modifier un IBAN en base vaut mieux, pour un attaquant, que détourner un paiement unique.
- Les consoles de paramétrage des plafonds, des règles de contrôle et des listes de surveillance, dont la modification prépare la fraude plutôt qu'elle ne la commet.
- Les outils de relation client et de rappel sortant, qui permettent d'appeler un client depuis un contexte authentique et d'enchaîner sur une fraude au faux conseiller.
Le raisonnement à tenir est donc inverse de l'intuition : plus une population est habituée à approuver des demandes toute la journée, plus son compte vaut cher.
Ce que le rythme bancaire offre à l'attaquant
Trois particularités du secteur nourrissent l'automatisme d'approbation.
D'abord la densité d'authentifications. Un opérateur enchaîne les applications métier, l'authentification unique ne couvre pas tout, et le nombre de validations quotidiennes rend chaque demande individuellement insignifiante. Ensuite le fonctionnement continu : équipes de nuit, supervision des flux, astreintes de production. Une demande hors horaires ne déclenche aucune alarme mentale. Enfin la chaîne de sous-traitance : infogérance, éditeurs, centres de service délocalisés. Des comptes très privilégiés sont portés par des personnes qui ne connaissent pas les procédures internes de signalement.
Le scénario type combine ces trois éléments : rafale de notifications pendant une période de forte charge, puis appel d'un prétendu support production qui demande de valider « pour débloquer la chaîne de règlement ». La cible n'a ni le temps ni le réflexe de vérifier.
| Étape | Objectif de l'attaquant | Contre-mesure adaptée | Limite de la contre-mesure |
|---|---|---|---|
| Obtention de l'identifiant | Fuite, credential stuffing, phishing | Surveillance des fuites, mots de passe uniques | N'empêche pas la réutilisation externe |
| Rafale de notifications | Obtenir une approbation lasse | Limitation de débit, blocage après N refus | Décale l'attaque plutôt qu'elle ne l'annule |
| Appel de renfort | Rendre la demande crédible | Règle interne : aucun support ne demande d'approuver | Dépend de la formation, pas de la technique |
| Session ouverte | Agir sur les paiements | Validation d'intention par opération | Nécessite un facteur non rejouable |
| Persistance | Enrôler un second facteur | Alerte sur tout ajout de facteur | Détection a posteriori |
Ce qu'exigent DSP2 et DORA
La DSP2 (directive (UE) 2015/2366) impose l'authentification forte du client avec deux facteurs de catégories distinctes et un lien dynamique entre l'authentification, le montant et le bénéficiaire. Ce principe de lien dynamique est précisément ce qui manque aux parcours internes : côté client, on authentifie une opération ; côté collaborateur, on authentifie une session, puis on lui fait confiance pendant des heures. Le push bombing exploite cet écart.
Le règlement DORA (règlement (UE) 2022/2554), applicable depuis janvier 2025, déplace ensuite la question sur le terrain de la résilience opérationnelle et de la maîtrise des prestataires informatiques tiers. Un compte d'infogérant approuvé par lassitude relève exactement de ce périmètre. Quant à la DSP3 et au règlement sur les services de paiement, ils sont encore en processus législatif : les anticiper est raisonnable, les présenter comme applicables ne l'est pas.
Parades qui tiennent dans une chaîne de paiement
- Retirer la notification push simple des populations sensibles : back-office paiement, administration des référentiels, exploitation, comptes prestataires. Ces populations sont dénombrables, donc traitables.
- Déplacer le point de contrôle de la session vers l'opération. C'est la mesure la plus structurante : une authentification transactionnelle liée au montant et au bénéficiaire rend inutile une session volée. Le principe du lien dynamique, déjà admis côté client, mérite d'être appliqué en interne.
- Interdire par règle écrite toute approbation sollicitée par téléphone, et le dire assez souvent pour que le refus devienne le réflexe par défaut.
- Instrumenter les refus. Une rafale de refus est un indicateur de compromission d'identifiant, au même titre qu'un mot de passe pulvérisé.
- Adopter un facteur qui ne se rejoue pas. Un facteur lié à l'origine bloque le relais ; un facteur cognitif va plus loin en exigeant une intention humaine consciente au moment de l'action, ce qu'aucune rafale de notifications ne peut arracher.
Une mise en œuvre progressive est possible : un déploiement en overlay de la MFA existante permet de couvrir d'abord la validation des virements et les accès d'administration, sans refondre le socle d'identité de l'établissement.
FAQ
Le push bombing concerne-t-il aussi les clients particuliers ?
Il existe, mais il se heurte à des parcours déjà encadrés par la DSP2 et à des montants plafonnés. L'exposition la plus lourde reste interne, parce qu'un compte collaborateur agit sur des flux agrégés et sur les paramètres qui gouvernent les contrôles.
La correspondance de numéro règle-t-elle le problème ?
Elle supprime l'approbation purement réflexe, ce qui est un gain réel. Elle reste vulnérable au scénario où un attaquant, au téléphone, obtient de la victime qu'elle lui lise ou saisisse le nombre affiché. Il faut la compléter, notamment sur les opérations financières.
Faut-il traiter les prestataires différemment des salariés ?
Plus strictement, pas différemment. Leurs comptes portent souvent plus de privilèges et échappent aux campagnes internes de sensibilisation. DORA rend d'ailleurs la maîtrise de ces accès tiers explicitement opposable.
Que faire immédiatement après une approbation suspecte ?
Révoquer les jetons de session, pas seulement réinitialiser le mot de passe : le butin d'une intrusion réussie est la session. Il faut ensuite vérifier les facteurs enrôlés, les règles de redirection de messagerie et les modifications de référentiels bénéficiaires sur la période.
Aller plus loin : authentification cognitive : le principe · comprendre la MFA fatigue · DORA et le secteur bancaire · valider un virement par un facteur cognitif