Infecté par XMRig, comment s'en débarrasser proprement ?

parazitenew · Le 03/03/2023, à 22:33

Bonjour,

Aujourd'hui je me connecte sur mon VPS ubuntu 18, et j'ai vu une adresse IP inconnue comme étant la dernière utilisée pour accéder au serveur. Basée au Netherland, j'ai compris que je m'étais fait pirater. Je remarque aussi que le CPU était à 100%, un petit top et je vois ceci:

Une petite recherche et j'apprends qu'il s'agit d'un programme de crypto-minage. Alors je cherche son emplacement:

Je change le mot de passe root, je fais un kill pour arrêter le programme, je supprime le répertoire et je vérifie qu'il n'y a pas de cronjob le concernant. Cependant, avant de le supprimer, je vois ce propriétaire:

Il se trouve que j'ai bel est bien jitsimeet sur mon VPS. Mais comment interpréter ça ? Est-ce un hasard ou dois-je en déduire qu'il y a une faille sur Jitisi au quel cas je devrais en référer à leur forum ? Car il est également important de savoir comment le programme a été introduit sur mon serveur.

Par ailleurs ai-je fait tout ce qu'il fallait ou y a-t-il autre chose à faire pour s'assurer que le serveur est propre ?

Merci.

Vobul · Le 04/03/2023, à 01:05

Salut,

En effet il serait intéressant de voir si ça vient de Jitsi. Il était à jour ton jitsi ?

Un vps c'est fait pour être jeté. Donc tu peux faire un snapshot entier pour analyse ultérieure, mais le garder n'est pas une option. Tu détruis ce VPS et t'en crées un nouveau. Tu ne pourras jamais être certain qu'il est propre sinon. Au passage, tu fais une upgrade à 22.04

Il faut que tu analyses les logs HTTP, que tu détermines quand il a été piraté et par quel moyen.

Au passage, considère tout ce qui était sur ce serveur comme public, et change toutes tes clés ssh et mots de passe.

parazitenew · Le 04/03/2023, à 03:13

Vobul a écrit :

Salut,
En effet il serait intéressant de voir si ça vient de Jitsi. Il était à jour ton jitsi ?
Un vps c'est fait pour être jeté. Donc tu peux faire un snapshot entier pour analyse ultérieure, mais le garder n'est pas une option. Tu détruis ce VPS et t'en crées un nouveau. Tu ne pourras jamais être certain qu'il est propre sinon. Au passage, tu fais une upgrade à 22.04
Il faut que tu analyses les logs HTTP, que tu détermines quand il a été piraté et par quel moyen.
Au passage, considère tout ce qui était sur ce serveur comme public, et change toutes tes clés ssh et mots de passe.

Bonsoir merci pour ta réponse.

Je faisais mes mises à jour de cette façon, et je ne voyais aucune mise à jour:

apt-get upgrade

Mais d'après le forum jitsi, il faut le faire comme ceci

apt-get --with-new-pkgs upgrade

Alors je viens de le faire, il y a eu ajout d'un nouveau paquet "jitsi-meet-turnserver" et je me suis retrouvé avec php 8.2.3 alors que je crois que j'avais le 7.4.
Cependant, j'ai toujours cette ligne

Les paquets suivants ont été conservés :
  jicofo jitsi-meet jitsi-meet-web jitsi-meet-web-config jitsi-videobridge2

Le fichier de minage a été installé le 28 février à 15h05 j'en déduis que c'est à ce moment là que l'intrusion a été faite, je devrais pouvoir trouver quelques logs, je vais également voir s'il n'y a pas un web ui pour me faciliter la recherche.

Concernant la suppression du VPS, ce n'est pas une solution pour moi car il s'agit d'un VPS que je loue chez un prestataire (je ne citerai pas l'entreprise), au moment où je me suis abonné, il y avait que Ubuntu 18, et j'ai tellement de services installés dessus, que ça me prendrait des mois à tout remettre en place.

Je sais qu'il y a une commande pour lister des fichiers modifiés à une date définie, mais n'y a-t-il pas une commande pour lister des fichiers créés depuis une date donnée, ça pourrait m'aider à savoir si le pirate n'a pas laissé un script derrière lui.

Edit: Qu'entends tu par "mes clés ssh" ?

Dernière modification par parazitenew (Le 04/03/2023, à 03:27)

bruno · Le 04/03/2023, à 09:21

Bonjour,

Désolé mais vobul a entièrement raison. La réinstallation complète de ton serveur est indispensable.
Ton, serveur a été compromis et tu ne sais pas jusqu'à quel point. Il peut y avoir bien d'autres choses,beaucoup plus difficiles à détecter, que l'application de cryptominage.

geole · Le 04/03/2023, à 10:35

parazitenew a écrit :

Le fichier de minage a été installé le 28 février à 15h05 j'en déduis que c'est à ce moment là que l'intrusion a été faite,
mais n'y a-t-il pas une commande pour lister des fichiers créés depuis une date donnée

Bonjour
Normalement, un pirate installe ses outils et attends plusieurs semaines pour les activer. Donc je doute de la fiabilité de la date de recherche.
Sinon cette commande trouvée sur le net mais que je n'ai pas vérifié.

sudo find / -newerBt '2019-05-28 23:00'

Dernière modification par geole (Le 04/03/2023, à 10:37)

bruno · Le 04/03/2023, à 11:02

geole a écrit :

Normalement, un pirate installe ses outils et attends plusieurs semaines pour les activer.

Et il sait comment ne pas laisser de traces dans les logs et modifier les dates de fichiers (lire man touch).

Le logiciel de minage a été assez grossièrement installé sans chercher à masquer son activité et a probablement profité d'une faille bien connue de Jitsi puisque le propriétaire est jitsi. Le système n'était probablement maintenu à jour correctement et la question sur les clefs SSH n'augure pas de bonnes pratiques en matière de sécurité.

Encore une fois on ne peut pas savoir jusqu'à quel point le serveur et compromis il doit donc être impérativement arrêté et une analyse post-mortem effectuée à partir d'une image du VPS (logs, fichiers modifiés et installés, etc.)

Vobul · Le 04/03/2023, à 14:55

@parazitenew, vois ça comme une occasion de parfaire tes connaissances. Apprends à utiliser Ansible, pour migrer tes services sur d'autre serveurs. Apprends à configurer correctement un serveur web, comme par exemple "aide" pour détecter ce genre d'intrusions (https://aide.github.io/).

Après j'avoue être un peu étonné que tu utilises les paquets de la distribution pour un web service comme jitsi. Mais bon on en revient au vieux débat du docker vs deb. Perso j'ai jamais compris pourquoi il y avait des paquets genre "phpmyadmin" et compagnie (enfin aujourd'hui en tout cas). Si tu apprends à isoler tes services dans des containers, et avoir des déploiement reproductibles, semi-automatisés + une config sérieuse niveau sécurité, t'auras sacrément avancé. Regarde les recommandations de l'ANSSI : https://www.ssi.gouv.fr/guide/recommand … -gnulinux/. Après en anglais il y a les CIS benchmark aussi. Et après tu peux passer à une distribution plus "sérieuse" comme Rocky Linux avec SELinux (sans vouloir cracher sur ubuntu hein, mais il faut regarder les choses en face).

Mais j'espère que tu te rends bien compte que garder ton VPS n'est pas une option.

geole a écrit :

Normalement, un pirate installe ses outils et attends plusieurs semaines pour les activer

Dans ce cas, j'opterai plutôt pour un truc automatisé qui commence à miner dès que possible. Un petit coup de shodan pour détecter les jitsi vulnérables et zou ! Mais cela n'est que supposition.

parazitenew · Le 04/03/2023, à 20:06

@bruno oui, je comprends
@geole la commande me retourne

find: This system does not provide a way to find the birth time of a file.
find: invalid predicate `-newerBt'

@Vobul Je n'ai rien contre docker, d'ailleurs il y a un container docker Jitsi sur leur site officiel, mais à l'époque je n'avais pas encore appris docker. Mais je ne vois pas en quoi ça aurait changé quoi que ce soit. La faille étant toujours là (si elle existe), le container est connecté à internet, alors je pense que ça aurait fini par être la même chose non ?

J'ai téléchargé le document PDF je le lirai à tête reposé.

J'ai analysé le /var/log/auth.log,

grep "Accepted password for root" auth.log
grep -P '^(?=.*sshd)(?=.*session opened)' auth.log

le pirate (ou bot) s'est connecté une seule fois en ssh en root. Si le programme avait été installé de cette façon, il aurait eu le ownership du root. En plus, jitsi n'est pas un utilisateur dans mon serveur, c'est le nom du groupe et son code est 1000.

Comment il aurait pu avoir le mot de passe root, le bruteforcing étant contré par fail2ban ?
Comment se fait-il que le programme avait le ownership d'un groupe, sans avoir d'utilisateur, et est-ce un indice ?

ps: J'ai exporté mes BDD, maintenant je fais l'inventaire de mes services et mes applications web, des fichiers de configuration etc.

Dernière modification par parazitenew (Le 04/03/2023, à 20:07)

bruno · Le 04/03/2023, à 20:50

Concernant Docker, je suis d'accord cela n'améliore pas la sécurité. C'est même plutôt l'inverse si les conteneurs ne sont pas maintenus à jour. D'ailleurs il y avait une faille de sécurité énorme sur une image docker de jitsi il y a un moment.
Il faut arrêter de tout vouloir déployer avec Docker parce que c'est la mode. Il faut l'utiliser a bon escient, quand c'est réellement utile, et surtout bien maîtriser l'outil et les aspects sécurité.

Concernant fail2ban cela ne fait que diminuer le bruit dans les logs et ralentir (un peu) la réussite d'une attaque par force brute vis à vis d'un mot de passe faible. Si le mot de passe est très fort, ou mieux l'identification se fait par clefs, l'attaque par force brute est de toute façon vouée à l'échec.

Nuliel · Le 04/03/2023, à 20:56

Bonjour,
docker permet d'isoler les applications, et aurait permis de limiter l'infection, que ça reste dans le conteneur en fait (s'il a été bien conçu évidemment, et si c'est bien le conteneur qui a été attaqué).
fail2ban limite le bruteforce, mais il ne l'empêche pas. Si ton mot de passe root est faible, ou si ce mot de passe se trouve dans une base de mots de passe (c'est notamment le cas si c'est un mdp utilisé sur plusieurs sites et que l'un d'eux s'est fait piquer sa base de mdp), alors le bot réussira à entrer tôt ou tard.
Interdire l'authentification par mot de passe (et donc forcer l'auth par clé) est l'idéal.
As tu plein de mdp testés sur ssh? As tu des logs de jitsi et des infos sur ce qu'a fait le bot dedans?
+1 pour les guides de l'ANSSI.
1000 c'est le premier uid des utilisateurs non privilégiés. Tu n'as pas d'utilisateur non privilégié plus classique? Le fait d'avoir nobody 1000 comme owner/group fait effectivement penser que ton jitsi a été attaqué, mais s'il s'est connecté en root, il n'y a peut-être pas de lien avec jitsi. Ou alors c'est pour se cacher dans un service.

Dernière modification par Nuliel (Le 04/03/2023, à 20:58)

Vobul · Le 04/03/2023, à 21:30

Nuliel a écrit :

Interdire l'authentification par mot de passe (et donc forcer l'auth par clé) est l'idéal.

Je dirais même que c'est un pré-requis essentiel. Regarder du côté de Lynis (https://github.com/CISOfy/lynis) pour avoir une conf solide sur les services. Et pour ssh, ceci : http://static.open-scap.org/ssg-guides/ … _group_ssh.

Laisser son port ssh ouvert aux quatre vents en se disant que fail2ban fera le job c'est chercher des emmerdes ! Une restriction IP source sur le port 22 + une config restrictive c'est super important !

Sinon pour Docker j'en parlais surtout pour l'aspect reproductibilité et portabilité des services, moins sur l'aspect sécurité qui implique comme le mentionne bruno d'être vigilant sur les images qu'on utilise, et d'avoir un process de scan des vulnérabilités des containers qui tournent (voir snyk.io et autres). De mon point de vue, Docker facilite grandement le déploiement de multiples services hétéroclites sans trop avoir à se soucier des versions proposées dans les paquets de la distrib'. J'aime assez cette idée que les paquets systèmes sont strictement pour le cœur du serveur, et tout le reste est containerisé, ce qui permet également de faire tourner toute l'infra localement très facilement sans avoir à installer 10000 trucs.

parazitenew · Le 04/03/2023, à 22:30

@bruno j'ai configuré fail2ban pour bannir une adresse IP durant 3 ans après 3 tentatives échouées en l'espace de 5 min. J'ai testé le mot de passe root sur des sites d'estimation de temps de bruteforcing, j'ai des résultats variables:
https://www.security.org/how-secure-is-my-password/ 42 min
https://www.passwordmonster.com/ 171 ans
https://random-ize.com/how-long-to-hack-pass/ 9h56 min

Je pense alors que ça devrait venir d'un dictionnaire. Mon mot de passe a du fuité de quelque part car en effet je l'avait utilisé ailleurs, c'était mon erreur.

Nuliel a écrit :

As tu plein de mdp testés sur ssh? As tu des logs de jitsi et des infos sur ce qu'a fait le bot dedans?

SI par mdp testés sur ssh tu veux dire tentatives de connexion en ssh sur mon serveur, alors oui, dans les logs de auth.log il n'y a que ça.

Je n'ai pas très bien compris ta question sur d'autres utilisateurs non privilégiés plus classic, dans le doute:

 cat /etc/passwd|grep 1000
jvb:x:999:1000::/usr/share/jitsi-videobridge:/bin/bash
jicofo:x:998:1000::/usr/share/jicofo:/bin/bash

@Vobul je vais chercher comment utiliser iptables pour bloquer l'accès ssh depuis des adresses IP non connues

Nuliel · Le 04/03/2023, à 22:50

Oui je parlais de tentatives de connexion.
Habituellement les uid < 1000 sont réservés au système, et les uid >= 1000 sont pour les utilisateurs. En fait ça m'étonne que tu aies un UID < 1000 et un GID >= 1000.
Les deux utilisateurs en question peuvent récupérer un shell, s'il y a un mdp associé à l'un des deux comptes, alors je pense qu'on peut se connecter au compte en question via ssh: voir /etc/shadow (ne donne pas son contenu, il y a les hash des mdp des utilisateurs), si tu as une étoile devant l'utilisateur

jicofo:*
jvb:*

alors il n'y a pas de mdp

parazitenew · Le 05/03/2023, à 00:14

Nuliel a écrit :

Oui je parlais de tentatives de connexion.
Habituellement les uid < 1000 sont réservés au système, et les uid >= 1000 sont pour les utilisateurs. En fait ça m'étonne que tu aies un UID < 1000 et un GID >= 1000.
Les deux utilisateurs en question peuvent récupérer un shell, s'il y a un mdp associé à l'un des deux comptes, alors je pense qu'on peut se connecter au compte en question via ssh: voir /etc/shadow (ne donne pas son contenu, il y a les hash des mdp des utilisateurs), si tu as une étoile devant l'utilisateur
jicofo:*
jvb:*
alors il n'y a pas de mdp

Donc si je comprends bien, * correspond au /usr/sbin/nologin

Dans mon cas, les deux comptes ont un "!", et puisqu'il n'y a pas de hash je peux le mettre

jvb:!:19082::::::
jicofo:!:19082::::::

et ils ont un /bin/bash

Vobul · Le 05/03/2023, à 00:29

Et surtout n'oublie pas, c'est hyper important : change le port de ssh ! Non je déconne c'était juste pour hérisser les poils de bruno

EDIT: quoique dans ce cas précis où l'authentification par mot de passe root simple et réutilisé sur d'autres sites est active, ne pas être sur le port 22 aurait pu aider....

Dernière modification par Vobul (Le 05/03/2023, à 00:42)

bruno · Le 05/03/2023, à 09:08

Nuliel a écrit :

docker permet d'isoler les applications, et aurait permis de limiter l'infection, que ça reste dans le conteneur en fait (s'il a été bien conçu évidemment, et si c'est bien le conteneur qui a été attaqué).

Attention à ce genre d'affirmation, il y a des techniques pour s'échapper d'un conteneur docker mal sécurisé.

--

@Vobul : rien ne prouve que l'intrusion ait eu lieu via SSH. Au contraire tout laisse supposer que c'est une faille Jitsi qui a été exploitée.

--

parazitenew a écrit :

@bruno j'ai configuré fail2ban pour bannir une adresse IP durant 3 ans après 3 tentatives échouées en l'espace de 5 min.

Et a chaque fois que tu bannis une adresse IP, il y a a une autre qui peut faire trois tentatives (en réalité souvent bien plus le temps que fail2ban réagisse). Donc si ton mot de passe est trop faible, il finira par être trouvé. Encore un fois cela peut ralentir un peu, mais ce n'est pas de la sécurité.

parazitenew a écrit :

J'ai testé le mot de passe root sur des sites d'estimation de temps de bruteforcing, j'ai des résultats variables:
https://www.security.org/how-secure-is-my-password/ 42 min
https://www.passwordmonster.com/ 171 ans
https://random-ize.com/how-long-to-hack-pass/ 9h56 min

Les différences énormes de résultats devraient te faire comprendre que ce type d'outil n'est pas fiable ! Un mot de passe fort pour root (si tu ne peux pas utiliser les clefs) c'est un mot de passe long : 20 -30 caractères.

parazitenew a écrit :

Dans mon cas, les deux comptes ont un "!", et puisqu'il n'y a pas de hash je peux le mettre
jvb:!:19082::::::
jicofo:!:19082::::::

Le point d'exclamation signifie que les deux comptes sont « verrouillés », c'est à dire qu'ils ne peuvent pas ouvrir de session. Le GID=1000 est effectivement étrange.

Nuliel · Le 05/03/2023, à 09:45

bruno a écrit :

Attention à ce genre d'affirmation, il y a des techniques pour s'échapper d'un conteneur docker mal sécurisé.

Je sais bien, c'est pour ça que j'ai parlé de conteneur bien conçu (j'ai déjà fait quelques challenges docker sur ce sujet d'ailleurs)

Dernière modification par Nuliel (Le 05/03/2023, à 09:45)

matrix-bx · Le 05/03/2023, à 11:27

Salut,

bruno a écrit :

@Vobul : rien ne prouve que l'intrusion ait eu lieu via SSH. Au contraire tout laisse supposer que c'est une faille Jitsi qui a été exploitée.

Bah quand même

parazitenew a écrit :

le pirate (ou bot) s'est connecté une seule fois en ssh en root.

bruno a écrit :

Le point d'exclamation signifie que les deux comptes sont « verrouillés », c'est à dire qu'ils ne peuvent pas ouvrir de session.

Ça ne concerne que les sessions avec authentification via password, pas ssh avec clef.

$ sudo usermod -L matrix-bx
$ sudo grep matrix-bx /etc/shadow | cut -b 1-12
matrix-bx:!$
$ su matrix-bx
Mot de passe : 
su: Échec de l’authentification
$

$ ssh matrix-bx@localhost
matrix-bx@localhost's password: 
Permission denied, please try again.
$

Mais.

matrix-bx@laptop:~$ ssh laptop2.lan pwd
/home/matrix-bx
matrix-bx@laptop:~$

Si on veux aussi interdire l'authentification par clef, soit on la vire, soit on met /bin/false en shell par exemple.
Bon Dimanche.

bruno · Le 05/03/2023, à 13:45

[HS]Si tu veux chipoter, effectivement j'aurais du préciser que ces comptes ne peuvent pas ouvrir de session directement. Mais c'est possible via SSH avec des clefs. Et il est possible d'obtenir un shell via une autre session utilisateur avec su / sudo (avec ou sans /sbin/nologin ou autre).
Exemple avec l'utilisateur mysql :

# getent passwd mysql
mysql:x:109:113:MySQL Server,,,:/nonexistent:/bin/false

pas de shell (/bin/false)

# grep mysql /etc/shadow
mysql:!:18079:0:99999:7:::

compte « verrouillé »

# su -s /bin/bash mysql
mysql@ks10:/root$

depuis un shell root j'obtiens facilement un shell mysql.
[/HS]

Je persiste : je n'ai pas vu de début de preuve d'une intrusion via SSH, juste une affirmation sans aucun élément technique pour l'appuyer.

matrix-bx · Le 05/03/2023, à 13:59

C'était pas du tout pour chipoter, juste préciser un truc qui m'a mordu par le passé.

parazitenew · Le 06/03/2023, à 22:53

Même si je suis entrain de préparer ma certification LPI Linux Essentials voire LPIC-1 par la suite. J'avoue que je ne comprends pas ce que vous venez de tester. En gros, vous avez été capable de déverrouiller les comptes qui étaient verrouillés ? Aussi vous avez accéder au shell root en passant par un shell d'un autre utilisateur ? Comme mysql pour le cas de bruno ?

Mais pour faire ça, il faudrait d'abord être dans le shell, donc s'être déjà connecté avec un utilisateur.

Dernière modification par parazitenew (Le 06/03/2023, à 22:53)

bruno · Le 07/03/2023, à 10:01

Oublie, nous étions hors-sujet et nous n'avons fait qu'ajouter de la confusion. Désolé.

NicoApi73 · Le 07/03/2023, à 12:39

bruno a écrit :

parazitenew a écrit :
J'ai testé le mot de passe root sur des sites d'estimation de temps de bruteforcing, j'ai des résultats variables:
https://www.security.org/how-secure-is-my-password/ 42 min
https://www.passwordmonster.com/ 171 ans
https://random-ize.com/how-long-to-hack-pass/ 9h56 min
Les différences énormes de résultats devraient te faire comprendre que ce type d'outil n'est pas fiable ! Un mot de passe fort pour root (si tu ne peux pas utiliser les clefs) c'est un mot de passe long : 20 -30 caractères.

Salut bruno,

Ca montre surtout que le mot de passe est faible. J'ai essayé un mot de passe de 20 caractères (majuscules, minuscules et chiffres, ce qui n'est d'ailleurs plus suffisant), avec les résultats suivants dans l'ordre des sites (copier-coller du résultat) :
5 hundred quadrillion années (contre 42 min)
63 trillion trillion years (contre 171 ans)
7977542961637926000 years (contre 9h56 min)

parazitenew · Le 08/03/2023, à 17:39

Merci en tout cas pour vos réponses et suggestions.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 03/03/2023, à 22:33

Infecté par XMRig, comment s'en débarrasser proprement ?

#2 Le 04/03/2023, à 01:05

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#3 Le 04/03/2023, à 03:13

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#4 Le 04/03/2023, à 09:21

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#5 Le 04/03/2023, à 10:35

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#6 Le 04/03/2023, à 11:02

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#7 Le 04/03/2023, à 14:55

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#8 Le 04/03/2023, à 20:06

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#9 Le 04/03/2023, à 20:50

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#10 Le 04/03/2023, à 20:56

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#11 Le 04/03/2023, à 21:30

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#12 Le 04/03/2023, à 22:30

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#13 Le 04/03/2023, à 22:50

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#14 Le 05/03/2023, à 00:14

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#15 Le 05/03/2023, à 00:29

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#16 Le 05/03/2023, à 09:08

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#17 Le 05/03/2023, à 09:45

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#18 Le 05/03/2023, à 11:27

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#19 Le 05/03/2023, à 13:45

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#20 Le 05/03/2023, à 13:59

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#21 Le 06/03/2023, à 22:53

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#22 Le 07/03/2023, à 10:01

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#23 Le 07/03/2023, à 12:39

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

#24 Le 08/03/2023, à 17:39

Re : Infecté par XMRig, comment s'en débarrasser proprement ?

Pied de page des forums