Des hackers ciblent des systèmes F5 BIG-IP APM avec un web shell Linux sans fichier

Des acteurs malveillants auraient compromis des systèmes déployés dans des environnements F5 BIG-IP Access Policy Manager et installé un rootkit Linux capable de manipuler le chargement des fichiers PHP. Ce rootkit injecte directement un web shell en mémoire, permettant aux attaquants de conserver un accès furtif sans déposer de fichier web shell classique sur le disque.

L’activité a été signalée le 8 septembre 2026. Toutefois, les premiers éléments publiés n’identifient ni le vecteur d’intrusion, ni une vulnérabilité correspondante, ni les versions logicielles concernées, ni le nombre d’organisations compromises.

Cette incertitude complique la remédiation. Les équipes de défense ne peuvent pas encore déterminer si l’installation d’une mise à jour particulière suffit à neutraliser le point d’entrée utilisé par les attaquants. En revanche, le comportement observé après la compromission fournit une base pour lancer immédiatement les investigations.

Quand une passerelle de sécurité devient un point d’appui pour l’attaquant

L’environnement concerné est F5 BIG-IP Access Policy Manager, généralement placé en amont de ressources d’entreprise sensibles afin d’appliquer des politiques d’accès. La compromission d’un tel système est plus lourde de conséquences que l’infection d’un poste classique.

Un attaquant qui prend le contrôle d’une appliance de gestion des accès peut s’installer durablement à proximité des flux d’authentification et des services réseau protégés. Selon la configuration et les privilèges de l’appliance, celle-ci peut également devenir un point de départ pour tenter d’atteindre des systèmes internes.

Le malware signalé s’exécute dans le contexte Linux sous-jacent à l’environnement BIG-IP. Ses principales capacités documentées sont les suivantes :

• Intercepter le chargement des fichiers PHP.
• Injecter un web shell en mémoire.
• Éviter la création d’un fichier web shell classique sur le disque.
• Dissimuler l’exécution malveillante grâce à des fonctionnalités de rootkit.

Aucun élément n’a été publié pour établir un vol de données, une interruption de service, une interception d’identifiants ou une progression vers des réseaux en aval. Ces scénarios restent des conséquences possibles, et non des faits confirmés.

L’ampleur de l’activité reste également inconnue. Aucun nombre d’appliances ou d’organisations touchées n’a été publié, et aucune information sur un ciblage géographique ou sectoriel n’a été identifiée. Les opérateurs, le nom de la campagne et celui du malware n’ont pas été communiqués.

Comment le web shell résidant en mémoire échappe à l’analyse des fichiers

Les web shells classiques sont généralement des scripts côté serveur déposés dans un répertoire accessible depuis le web. L’attaquant envoie ensuite des requêtes conçues pour exécuter des commandes ou mener d’autres actions non autorisées.

Cette méthode laisse un fichier sur le système. Les outils de sécurité peuvent alors le détecter grâce à la correspondance avec des signatures, à la surveillance de l’intégrité, à l’identification de noms de fichiers suspects, à l’inspection du contenu ou à la comparaison avec une installation de référence fiable.

La technique signalée sur les systèmes BIG-IP APM supprime cette dépendance. Au lieu d’enregistrer le composant PHP malveillant comme un fichier classique, le rootkit intercepte l’activité de chargement de PHP et injecte le web shell en mémoire.

Il en résulte un écart entre ce que le système semble contenir sur le disque et ce qu’il exécute lors de son fonctionnement. Une analyse du système de fichiers peut ne révéler aucun fichier PHP inhabituel alors que la logique malveillante du web shell reste active en mémoire.

Le rootkit ajoute un niveau supplémentaire de furtivité. Les rootkits sont conçus pour perturber la visibilité normale du système d’exploitation sur les processus, les fichiers, l’activité réseau ou d’autres ressources. Les mécanismes précis de dissimulation utilisés dans cette campagne n’ont pas été communiqués. Les équipes de défense ne doivent donc pas considérer que les sorties des outils d’administration standards donnent une vision complète d’une appliance touchée.

De même, les informations disponibles n’expliquent pas comment la persistance résiste à un redémarrage, comment les attaquants communiquent avec le shell injecté ni quel mécanisme de chargement de PHP est intercepté. Aucune infrastructure de commande et de contrôle, aucun nom de fichier ou de processus, aucun indicateur réseau, aucune empreinte cryptographique et aucune signature de détection n’ont été publiés.

Versions, vulnérabilités et vecteur d’entrée encore inconnus

La famille de produits concernée est F5 BIG-IP, plus précisément les environnements utilisant Access Policy Manager. Les versions exactes de BIG-IP et les modèles d’appliances concernés n’ont pas été identifiés.

Aucun CVE n’a été associé à ces compromissions. Il est donc impossible de déterminer si les attaquants ont exploité une vulnérabilité logicielle non corrigée, utilisé des identifiants administratifs volés, détourné une interface de gestion exposée ou obtenu leur accès par un autre moyen.

Cette distinction est essentielle pour le confinement. Une mise à jour logicielle peut supprimer une vulnérabilité, mais elle ne retire pas nécessairement un rootkit d’un appareil déjà compromis. À l’inverse, la rotation des identifiants ne suffirait pas à neutraliser une faille exploitable encore non identifiée.

Aucune version corrigée, aucun correctif éditeur et aucune mesure de contournement confirmée n’ont non plus été communiqués spécifiquement pour cette activité. Les organisations doivent continuer à appliquer les mises à jour de sécurité et les recommandations de durcissement applicables de F5, sans pour autant considérer qu’une mise à jour régulière prouve qu’une appliance est saine.

Aucun identifiant de vulnérabilité n’ayant été fourni, cette activité ne peut pas être associée à une entrée du catalogue Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency des États-Unis. Aucune date d’ajout au catalogue KEV ni aucune échéance de remédiation n’ont donc été communiquées pour cet incident.

La détection doit aller au-delà du système de fichiers

L’analyse traditionnelle des malwares fondée sur les fichiers ne suffit pas face à cette menace. Les équipes de défense doivent combiner les journaux de l’appliance, la télémétrie réseau, l’inspection de l’exécution, l’examen de la configuration et, lorsque ces capacités sont disponibles, l’analyse de la mémoire.

Les priorités d’investigation sont les suivantes :

1. Examiner les accès administratifs. Rechercher dans les journaux de gestion et les journaux système de BIG-IP les connexions inexpliquées, les utilisations de privilèges, les modifications de configuration, les créations de comptes ou les accès provenant de sources inattendues.

2. Inspecter le comportement lié à l’exécution de PHP. Rechercher les requêtes inhabituelles, les schémas inattendus de chargement de PHP, les chemins d’exécution qui ne correspondent à aucun fichier présent sur le disque et les écarts entre le contenu applicatif déployé et le comportement observé lors de l’exécution.

3. Analyser l’activité résidant en mémoire. Examiner les processus et les composants chargés qui présentent un comportement anormal. Le web shell étant apparemment injecté en mémoire, les éléments volatils peuvent être essentiels pour déterminer si l’appliance est compromise.

4. Examiner les connexions réseau. Identifier le trafic sortant inattendu, les sessions persistantes, les destinations inconnues et les connexions qui ne correspondent pas au rôle opérationnel de l’appliance.

5. Rechercher le comportement d’un web shell, pas uniquement les fichiers correspondants. Des commandes suspectes ou des schémas de requêtes inhabituels peuvent rester visibles dans les journaux ou les données réseau, même lorsqu’aucun script malveillant n’existe sur le disque.

6. Vérifier l’intégrité du système. Comparer la configuration et l’état logiciel de l’appliance à des référentiels fiables en utilisant les procédures d’administration ou d’investigation approuvées par F5.

En l’absence d’indicateurs publiés, ces vérifications devront reposer sur une analyse comportementale plutôt que sur une simple comparaison avec des empreintes ou des adresses IP. Une analyse propre du disque ne doit pas, à elle seule, conduire à clore l’investigation.

Les appliances suspectes doivent être isolées tout en préservant les éléments de preuve

Les organisations qui identifient des signes crédibles de compromission doivent isoler le système BIG-IP concerné tout en préservant les journaux et la mémoire volatile. Une reconstruction ou un redémarrage immédiat pourrait modifier les éléments nécessaires pour comprendre le rootkit et sa charge utile en mémoire.

Les équipes de réponse à incident doivent déterminer à partir de quel moment un accès non autorisé a été possible, quels comptes ont interagi avec l’appliance et quels systèmes internes ou externes ont communiqué avec elle. L’analyse doit dépasser le seul appareil BIG-IP, car une passerelle d’accès compromise a pu servir à atteindre des infrastructures protégées.

Les identifiants accessibles depuis le système concerné ou utilisés par son intermédiaire doivent être renouvelés après le confinement. Les comptes privilégiés, les identifiants utilisés par les outils d’automatisation, les comptes de service et les chemins d’accès administratifs doivent faire l’objet d’une attention particulière.

Le rétablissement de la confiance peut nécessiter davantage que la suppression de fichiers suspects, notamment lorsqu’aucun fichier de ce type n’est présent. Les organisations doivent utiliser les procédures de récupération et de validation de l’intégrité prises en charge par le fournisseur, puis vérifier que les modifications malveillantes de l’environnement d’exécution ne peuvent ni persister ni réapparaître après la remédiation.

Tant que les versions de F5, la méthode d’accès initiale et les correctifs validés n’auront pas été communiqués, les équipes de défense devront mener deux actions distinctes : réduire l’exposition au moyen des mises à jour de sécurité disponibles et déterminer si des attaquants opèrent déjà au sein des appliances déployées. La seconde ne peut pas être résolue par la seule application de correctifs.