Magento piraté : Magecart, admin et clés API
Sur Magento, l'attaque vise le checkout, pas le CMS. Un admin étrange ou une clé d'intégration oubliée survit au changement de mot de passe. Révoquez, puis inspectez le layout XML et les extensions. La home propre n'exclut rien.
L'attaque vise le checkout. Un utilisateur admin étrange ou une clé d'intégration oubliée survit au changement de mot de passe. Révoquez, puis inspectez le layout XML.
Suspecter le tunnel, pas le design
Un skimmer Magento (souvent rangé sous le mot Magecart) se loge dans le JS du checkout, un layout XML, un observer, une extension de paiement. Le storefront reste « normal ». Testez le tunnel comme un client, lisez le HTML de l'étape paiement, notez les domaines des scripts. Cadre court : guide Magento ; service : Magento piraté.
Capturez, copiez (fichiers + DB), tournez le panel d'hébergement avant l'admin Magento. Un admin encore ouvert réécrit le layout que vous venez de corriger.
Coupez le paiement si le HTML est douteux. La vitrine peut rester. Boutique fermée ?.
Admin, rôles ACL et sessions
System → Permissions → All Users : comptes que vous ne nommez pas, emails jetables, last login à des heures étranges. Les rôles custom trop ouverts (un merchandiser avec `all`) valent un admin. Exportez, désactivez, forcez la déconnexion (invalidate sessions). Changez le chemin admin s'il est encore `/admin` — utile après, pas à la place de la révocation. Voir chemin admin Magento.
Un utilisateur API / integration n'apparaît pas toujours comme un humain. Passez à la section clés dans la même heure.
Clés d'intégration et tokens
System → Extensions → Integrations : OAuth que vous ne pouvez pas nommer (vieux ERP, ancien connecteur marketplace, prestataire 2019). Révoquez, puis changez le mot de passe admin — l'inverse laisse le token vivant. Les access tokens et les clés dans `env.php` / `local.xml` (M1) se tournent aussi. Article dédié : clés API oubliées.
Un token « read orders » suffit à une exfiltration. Un token write pose un admin ou un CMS block avec un script. Traitez toute clé innommable comme compromise, pas « peut-être read-only ».
- Integrations : aucune sans responsable nommé.
- Tokens REST / OAuth révoqués ou tournés.
- Secrets `env.php` relus après copie.
Layout XML et Magento Magecart
Un bloc CMS, un `default.xml` de thème, un layout dans `app/design` ou une extension qui ajoute un `script` sur `checkout_index_index`. Comparez le thème au vendor / à l'archive. Grep `checkout`, `<script`, des hôtes inconnus dans `app/design` et `app/code`. Les contenus CMS (blocks, pages) en base : même grep. Un block « footer scripts » est le cousin des `theme_mods` WordPress.
La compilation / static content : après correctif, `static-content:deploy` et flush cache (full page, block, layout). Sinon Magento ressert l'ancien JS minifié — même piège que LiteSpeed.
Extensions marketplace et « nullées »
Paiement, transport, promo, one-step checkout : les plus visés. Comparez aux paquets officiels (composer, Adobe Marketplace). Une archive « débridée » arrive déjà équipée. Ne réinstallez pas la même archive. Désactivez, inspectez, remplacez par l'officiel ou retirez.
Les extensions abandonnées (plus de patch) sont des portes même sans skimmer livré. Planifiez le remplacement après l'incident, pas une maj au milieu du feu.
Webhooks, cron et files d'export
Chez Stripe / Adyen / PayPal : URLs de notification. Dans Magento : cron (`cron_schedule`) qui appelle un endpoint inconnu, files d'export ERP. Un cron qui POST les commandes vers un tiers est une exfiltration silencieuse : les commandes « marchent ». Webhooks.
Les journaux Magento (`var/log`) et le journal d'envoi mail datent les pics. Ne les videz pas « pour faire de la place » avant copie.
Ce qu'il faut dire au prestataire de paiement
Fenêtre de dates, URL checkout, volume, nature (JS / redirection / clé API), constat. Canal incident, pas le chat marketing. Stripe, banque, PCI. Clients : que dire.
Nettoyer sans jeter le catalogue
Comparez `vendor/` et le cœur Composer, retirez le code hors arbre, gardez catalog / sales. Un `setup:upgrade` sur un site encore sale n'est pas un nettoyage. Restaurer un backup « pre-black-friday » non lu ramène souvent le layout infecté.
Refermez : admin, clés, FTP, panel. Surveillez `cron_schedule` et le HTML checkout 14 jours.
Adobe Commerce / Magento 2 : particularités
Magento 1 en fin de vie est une surface à part : planifiez la sortie, mais ne « migrez pas » pendant l'incident avec un dump sale. M2 : `app/etc/env.php`, 2FA admin (l'activer après, pas comme seul geste), compile. Les stores multiples : le skimmer peut ne vivre que sur un store view / un website. Testez chaque vue qui a un checkout.
Pour un audit layout + clés, déclarez le Magento.
- HTML checkout sans hôte JS inconnu.
- Integrations et tokens nommés ou morts.
- Caches et static content régénérés propres.
- PSP informé si doute cartes.