Comment gérer un serveur compromis?

Question

Je soupçonne qu'un ou plusieurs de mes serveurs sont compromis par un pirate informatique, un virus ou un autre mécanisme:

Quelles sont mes premières étapes? Lorsque j'arrive sur le site, dois-je déconnecter le serveur, conserver les "preuves", y a-t-il d'autres considérations initiales?
Comment dois-je procéder pour remettre les services en ligne?
Comment puis-je empêcher la même chose de se reproduire immédiatement?
Existe-t-il des meilleures pratiques ou méthodologies pour tirer des enseignements de cet incident?
Si je voulais élaborer un plan de réponse aux incidents, par où commencer? Cela devrait-il faire partie de ma planification de reprise après sinistre ou de continuité des activités?

_{Ceci est censé être un article canonique pour ce sujet. à l'origine de serverfault .}

Lucas Kauffman · Accepted Answer

À l'origine de serverfault. Merci à Robert Moir (RobM)

Il est difficile de donner des conseils spécifiques à partir de ce que vous avez publié ici, mais j'ai quelques conseils génériques basés sur un post que j'ai écrit il y a longtemps alors que je pouvais encore être dérangé pour bloguer.

Ne paniquez pas

Tout d'abord, il n'y a pas de "solution rapide" autre que la restauration de votre système à partir d'une sauvegarde effectuée avant l'intrusion, et cela a au moins deux problèmes.

Il est difficile de déterminer quand l'intrusion s'est produite.
Cela ne vous aide pas à fermer le "trou" qui leur a permis de s'introduire la dernière fois, ni à gérer les conséquences de tout "vol de données" qui aurait également pu avoir lieu.

Cette question continue d'être posée à plusieurs reprises par les victimes de pirates informatiques s'introduisant dans leur serveur Web. Les réponses changent très rarement, mais les gens continuent de poser la question. Je ne sais pas pourquoi. Peut-être que les gens n'aiment tout simplement pas les réponses qu'ils ont vues en cherchant de l'aide, ou ils ne peuvent pas trouver quelqu'un en qui ils ont confiance pour leur donner des conseils. Ou peut-être que les gens lisent une réponse à cette question et se concentrent trop sur les 5% des raisons pour lesquelles leur cas est spécial et différent des réponses qu'ils peuvent trouver en ligne et manquent les 95% de la question et de la réponse lorsque leur cas est assez proche de la même manière comme celui qu'ils lisent en ligne.

Cela m'amène à la première pépite d'informations importante. J'apprécie vraiment que vous soyez un flocon de neige unique et spécial. J'apprécie que votre site Web soit également un reflet de vous et de votre entreprise ou, à tout le moins, de votre travail acharné pour le compte d'un employeur. Mais pour quelqu'un à l'extérieur qui regarde, que ce soit un responsable de la sécurité informatique qui regarde le problème pour essayer de vous aider ou même l'attaquant lui-même, il est très probable que votre problème sera au moins à 95% identique à tous les autres cas qu'ils ont jamais regardé.

Ne prenez pas l'attaque personnellement, et ne prenez pas personnellement les recommandations qui suivent ici ou que vous recevez d'autres personnes. Si vous lisez ceci après avoir été victime d'un piratage de site Web, je suis vraiment désolé et j'espère vraiment que vous pourrez trouver quelque chose d'utile ici, mais ce n'est pas le moment de laisser votre ego vous empêcher de faire ce dont vous avez besoin. faire.

Vous venez de découvrir que vos serveurs ont été piratés. Et maintenant?

Ne paniquez pas. N'agissez absolument pas à la hâte et n'essayez absolument pas de prétendre que les choses ne se sont jamais produites et de ne pas agir du tout.

Premièrement: comprenez que la catastrophe s'est déjà produite. Ce n'est pas le moment du déni; c'est le moment d'accepter ce qui s'est passé, d'être réaliste à ce sujet et de prendre des mesures pour gérer les conséquences de l'impact.

Certaines de ces étapes vont faire mal, et (à moins que votre site Web ne contienne une copie de mes coordonnées), je m'en fiche vraiment si vous ignorez tout ou partie de ces étapes, mais cela améliorera les choses à la fin. Le médicament peut avoir un goût horrible, mais vous devez parfois l'oublier si vous voulez vraiment que le remède fonctionne.

Empêchez le problème de devenir pire qu'il ne l'est déjà:

La première chose à faire est de déconnecter les systèmes concernés d'Internet. Quels que soient les autres problèmes que vous rencontrez, laisser le système connecté au Web ne fera que poursuivre l'attaque. Je veux dire cela littéralement; demandez à quelqu'un de visiter physiquement le serveur et débranchez les câbles réseau si c'est ce qu'il faut, mais déconnectez la victime de ses agresseurs avant d'essayer de faire autre chose.
Modifiez tous vos mots de passe pour tous les comptes sur tous les ordinateurs qui sont sur le même réseau que les systèmes compromis. Pas vraiment. Tous les comptes. Tous les ordinateurs. Oui, vous avez raison, cela pourrait être exagéré; d'un autre côté, ce n'est peut-être pas le cas. Vous ne savez pas de toute façon, n'est-ce pas?
Vérifiez vos autres systèmes. Portez une attention particulière aux autres services accessibles sur Internet et à ceux qui contiennent des données financières ou commerciales sensibles.
Si le système contient les données personnelles de quiconque, informez immédiatement la personne responsable de la protection des données (si ce n'est pas vous) et demandez instamment une divulgation complète. Je sais que celui-ci est difficile. Je sais que celui-ci va faire mal. Je sais que de nombreuses entreprises veulent balayer ce genre de problème sous le tapis, mais l'entreprise va devoir y faire face - et doit le faire en tenant compte de toutes les lois pertinentes sur la vie privée.

Quelle que soit la gêne de vos clients de vous faire parler d'un problème, ils seront bien plus agacés si vous ne le leur dites pas, et ils ne le découvriront qu'après que quelqu'un aura facturé 8 000 $ de marchandises en utilisant les détails de leur carte de crédit volé sur votre site.

Rappelez-vous ce que j'ai dit précédemment? La mauvaise chose est déjà arrivée. La seule question qui se pose maintenant est de savoir comment vous y parvenez.

Comprenez parfaitement le problème:

Ne remettez PAS les systèmes concernés en ligne avant la fin de cette étape, à moins que vous ne souhaitiez être la personne dont le message a été le point de basculement pour moi qui décide d'écrire cet article. Je ne vais pas créer de lien vers cet article pour que les gens puissent rire à bon marché, mais la vraie tragédie, c'est quand les gens n'apprennent pas de leurs erreurs.
Examinez les systèmes "attaqués" pour comprendre comment les attaques ont réussi à compromettre votre sécurité. Faites tout votre possible pour savoir d'où viennent les attaques, afin de comprendre les problèmes que vous avez et que vous devez résoudre pour assurer la sécurité de votre système à l'avenir.
Examinez à nouveau les systèmes "attaqués", cette fois pour comprendre où les attaques se sont déroulées, afin de comprendre quels systèmes ont été compromis lors de l'attaque. Assurez-vous de suivre tout pointeur suggérant que des systèmes compromis pourraient devenir un tremplin pour attaquer davantage vos systèmes.
Assurez-vous que les "passerelles" utilisées dans toutes les attaques sont bien comprises, afin que vous puissiez commencer à les fermer correctement. (par exemple, si vos systèmes ont été compromis par une attaque par injection SQL, alors non seulement vous devez fermer la ligne de code défectueuse particulière par laquelle ils se sont cassés, mais vous devriez auditer tout votre code pour voir si le même type d'erreur a été faite ailleurs).
Comprenez que les attaques peuvent réussir en raison de plusieurs failles. Souvent, les attaques réussissent non pas en trouvant un bogue majeur dans un système mais en enchaînant plusieurs problèmes (parfois mineurs et triviaux par eux-mêmes) pour compromettre un système. Par exemple, utiliser des attaques par injection SQL pour envoyer des commandes à un serveur de base de données, découvrir le site Web/l'application que vous attaquez s'exécute dans le contexte d'un utilisateur administratif et utiliser les droits de ce compte comme tremplin pour compromettre d'autres parties de un système. Ou comme les pirates aiment l'appeler: "un autre jour au bureau en profitant des erreurs courantes que les gens font".

Pourquoi ne pas simplement "réparer" l'exploit ou le rootkit que vous avez détecté et remettre le système en ligne?

Dans de telles situations, le problème est que vous n'avez plus le contrôle de ce système. Ce n'est plus votre ordinateur.

La seule façon d'être certain que vous avez le contrôle du système est de reconstruire le système. Bien qu'il soit très utile de trouver et de réparer l'exploit utilisé pour pénétrer dans le système, vous ne pouvez pas être sûr de ce qui a été fait d'autre dans le système une fois que les intrus ont pris le contrôle (en effet, ce n'est pas inconnu pour les pirates qui recrutent systèmes dans un botnet pour patcher les exploits qu'ils ont utilisés eux-mêmes, pour protéger "leur" nouvel ordinateur des autres pirates, ainsi que pour installer leur rootkit).

Faites un plan de récupération et remettez votre site Web en ligne et respectez-le:

Personne ne veut être déconnecté plus longtemps que nécessaire. C'est une évidence. Si ce site Web est un mécanisme générateur de revenus, la pression pour le réactiver rapidement sera intense. Même si la seule chose en jeu est la réputation de votre/votre entreprise, cela va encore générer beaucoup de pression pour remettre les choses en place rapidement.

Cependant, ne cédez pas à la tentation de revenir en ligne trop rapidement. Au lieu de cela, allez aussi vite que possible pour comprendre ce qui a causé le problème et pour le résoudre avant de vous reconnecter, sinon vous serez certainement à nouveau victime d'une intrusion, et rappelez-vous, "se faire pirater une fois peut être considéré comme un malheur; se faire pirater à nouveau tout de suite après ressemble à de la négligence "(avec des excuses à Oscar Wilde).

Je suppose que vous avez compris tous les problèmes qui ont conduit à l'intrusion réussie en premier lieu avant même de commencer cette section. Je ne veux pas exagérer l'affaire, mais si vous ne l'avez pas fait en premier, vous en avez vraiment besoin. Désolé.
Ne payez jamais d'argent de chantage/protection. C'est le signe d'une marque facile et vous ne voulez pas que cette expression soit utilisée pour vous décrire.
Ne soyez pas tenté de remettre les mêmes serveurs en ligne sans une reconstruction complète. Il devrait être beaucoup plus rapide de construire une nouvelle boîte ou de "neutraliser le serveur depuis l'orbite et de faire une installation propre" sur l'ancien matériel qu'il ne le serait de vérifier chaque coin de l'ancien système pour s'assurer qu'il est propre avant de le remettre en place. en ligne à nouveau. Si vous n'êtes pas d'accord avec cela, vous ne savez probablement pas ce que cela signifie vraiment de garantir un nettoyage complet du système, ou les procédures de déploiement de votre site Web sont un gâchis impie. Vous disposez probablement de sauvegardes et de tests de déploiement de votre site que vous pouvez simplement utiliser pour créer le site en direct, et si vous ne le faites pas, le piratage n'est pas votre plus gros problème.
Soyez très prudent lorsque vous réutilisez des données qui étaient "en direct" sur le système au moment du piratage. Je ne dirai pas "ne jamais le faire" parce que vous m'ignorerez, mais franchement, je pense que vous devez considérer les conséquences de la conservation des données lorsque vous savez que vous ne pouvez pas garantir leur intégrité. Idéalement, vous devez restaurer cela à partir d'une sauvegarde effectuée avant l'intrusion. Si vous ne pouvez pas ou ne voulez pas le faire, vous devez être très prudent avec ces données car elles sont entachées. Vous devez surtout être conscient des conséquences pour autrui si ces données appartiennent aux clients ou aux visiteurs du site plutôt qu'à vous directement.
Surveillez attentivement le ou les systèmes. Vous devez vous résoudre à le faire en tant que processus continu à l'avenir (plus ci-dessous), mais vous vous efforcez d'être vigilant pendant la période suivant immédiatement la remise en ligne de votre site. Les intrus seront certainement de retour, et si vous pouvez les repérer en train de pénétrer à nouveau, vous pourrez certainement voir rapidement si vous avez vraiment fermé tous les trous qu'ils ont utilisés auparavant, plus ceux qu'ils ont faits pour eux-mêmes, et vous pourriez rassembler des informations utiles informations que vous pouvez transmettre à votre application de la loi locale.

Réduire le risque à l'avenir.

La première chose que vous devez comprendre est que la sécurité est un processus que vous devez appliquer tout au long du cycle de vie de la conception, du déploiement et de la maintenance d'un système accessible sur Internet, pas quelque chose que vous pouvez ensuite gifler quelques couches sur votre code comme bon marché Peindre. Pour être correctement sécurisé, un service et une application doivent être conçus dès le départ en gardant cela à l'esprit comme l'un des principaux objectifs du projet. Je me rends compte que c'est ennuyeux et que vous avez déjà entendu tout cela auparavant et que je "ne me rends pas compte de la pression exercée sur l'homme" pour que votre service bêta web2.0 (bêta) devienne bêta sur le Web, mais le fait est que cela se répéter parce que c'était vrai la première fois qu'on l'a dit et que ce n'est pas encore devenu un mensonge.

Vous ne pouvez pas éliminer le risque. Vous ne devriez même pas essayer de faire ça. Ce que vous devez cependant faire est de comprendre quels risques de sécurité sont importants pour vous, et de comprendre comment gérer et réduire à la fois l'impact du risque et la probabilité que le risque se produise.

Quelles mesures pouvez-vous prendre pour réduire la probabilité de réussite d'une attaque?

Par exemple:

La faille qui permettait aux utilisateurs de pénétrer dans votre site était-elle un bogue connu dans le code du fournisseur, pour lequel un correctif était disponible? Dans l'affirmative, devez-vous repenser votre approche de la façon dont vous corrigez les applications sur vos serveurs Internet?
La faille qui permettait aux utilisateurs de pénétrer dans votre site était-elle un bogue inconnu dans le code du fournisseur, pour lequel un correctif n'était pas disponible? Je ne préconise certainement pas de changer de fournisseur chaque fois que quelque chose comme ça vous mord parce qu'ils ont tous leurs problèmes et que vous manquerez de plates-formes dans un an au maximum si vous adoptez cette approche. Cependant, si un système vous laisse constamment tomber, vous devez soit migrer vers quelque chose de plus robuste ou, à tout le moins, réorganiser votre système afin que les composants vulnérables restent enveloppés de coton et aussi loin que possible des yeux hostiles.
La faille était-elle un bug dans le code développé par vous (ou quelqu'un travaillant pour vous)? Dans l'affirmative, devez-vous repenser votre approche de la façon dont vous approuvez le code pour le déploiement sur votre site en ligne? Le bogue aurait-il pu être détecté avec un système de test amélioré ou avec des modifications de votre "standard" de codage (par exemple, bien que la technologie ne soit pas une panacée, vous pouvez réduire la probabilité d'une attaque par injection SQL réussie en utilisant des techniques de codage bien documentées ).
La faille était-elle due à un problème de déploiement du serveur ou du logiciel d'application? Si oui, utilisez-vous des procédures automatisées pour créer et déployer des serveurs dans la mesure du possible? Ceux-ci sont d'une grande aide pour maintenir un état "de base" cohérent sur tous vos serveurs, minimisant la quantité de travail personnalisé qui doit être effectué sur chacun et donc, espérons-le, minimisant la possibilité d'une erreur. Il en va de même pour le déploiement de code - si vous avez besoin de quelque chose de "spécial" pour déployer la dernière version de votre application Web, essayez de l'automatiser et assurez-vous qu'elle est toujours effectuée de manière cohérente.
L'intrusion aurait-elle pu être détectée plus tôt grâce à une meilleure surveillance de vos systèmes? Bien sûr, une surveillance 24h/24 ou un système "sur appel" pour votre personnel peut ne pas être rentable, mais il existe des entreprises qui peuvent surveiller vos services Web pour vous et vous alerter en cas de problème. Vous pourriez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... il suffit de le prendre en considération.
Utilisez des outils tels que tripwire et nessus lorsque cela est approprié - mais ne les utilisez pas simplement à l'aveugle parce que je l'ai dit. Prenez le temps d'apprendre à utiliser quelques bons outils de sécurité adaptés à votre environnement, gardez ces outils à jour et utilisez-les régulièrement.
Envisagez d'embaucher des experts en sécurité pour "auditer" régulièrement la sécurité de votre site Web. Encore une fois, vous pourriez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... il suffit de le prendre en considération.

Quelles mesures pouvez-vous prendre pour réduire les conséquences d'une attaque réussie?

Si vous décidez que le "risque" d'inondation de l'étage inférieur de votre maison est élevé, mais pas suffisamment élevé pour justifier un déménagement, vous devez au moins déplacer les héritages irremplaçables de la famille à l'étage. Droite?

Pouvez-vous réduire la quantité de services directement exposés à Internet? Pouvez-vous maintenir une sorte d'écart entre vos services internes et vos services accessibles sur Internet? Cela garantit que même si vos systèmes externes sont compromis, les chances de l'utiliser comme tremplin pour attaquer vos systèmes internes sont limitées.
Stockez-vous des informations que vous n'avez pas besoin de stocker? Stockez-vous ces informations "en ligne" alors qu'elles pourraient être archivées ailleurs. Il y a deux points à cette partie; la plus évidente est que les gens ne peuvent pas vous voler des informations que vous ne possédez pas, et le deuxième point est que moins vous stockez, moins vous avez besoin de maintenir et de coder, et donc il y a moins de chances pour que les bogues se glissent dans la conception de votre code ou de vos systèmes.
Utilisez-vous les principes du "moindre accès" pour votre application Web? Si les utilisateurs ont uniquement besoin de lire à partir d'une base de données, assurez-vous que le compte que l'application Web utilise pour le service n'a qu'un accès en lecture, ne lui permettez pas un accès en écriture et certainement pas un accès au niveau du système.
Si vous n'êtes pas très expérimenté dans quelque chose et qu'il n'est pas au cœur de votre entreprise, envisagez de l'externaliser. En d'autres termes, si vous exécutez un petit site Web qui parle d'écrire du code d'application de bureau et décidez de commencer à vendre de petites applications de bureau à partir du site, envisagez d'externaliser votre système de commande de cartes de crédit à quelqu'un comme Paypal.
Dans la mesure du possible, intégrez la pratique de la récupération à partir de systèmes compromis à votre plan de reprise après sinistre. C'est sans doute juste un autre "scénario de catastrophe" que vous pourriez rencontrer, simplement un avec son propre ensemble de problèmes et de problèmes qui sont distincts de l'habituel "la salle des serveurs a pris feu"/"a été envahie par le genre de chose du serveur géant qui mange des furbies".

... Et enfin

Je n'ai probablement laissé aucune fin à des choses que d'autres considèrent importantes, mais les étapes ci-dessus devraient au moins vous aider à trier les choses si vous n'avez pas la chance de devenir victime de pirates informatiques.

Surtout: ne paniquez pas. Pense avant d'agir. Agissez fermement une fois que vous avez pris une décision et laissez un commentaire ci-dessous si vous avez quelque chose à ajouter à ma liste d'étapes.

Tom Leek · Answer

Rendre un fichier "non supprimable" sous Linux se fait avec attributs, en particulier l'attribut "immuable". Voir lsattr pour voir les attributs, chattr pour les changer.

Cependant, cela ne répond qu'à la cause proximale. La chose importante est que votre machine a été soumise à un contrôle hostile, et le pirate de l'air a installé des choses pour ses propres objectifs sournois. En particulier, il a probablement installé un rootkit afin de garder l'entrée ouverte malgré les tentatives de nettoyage comme ce que vous essayez de faire. Les rootkits peuvent avoir modifié le noyau et/ou les binaires du système d'une manière qui ne sera pas visible depuis la machine elle-même et qui empêchera leur propre suppression. L'essentiel est que votre machine ne peut pas être enregistrée; il n'y a aucun moyen que vous pouvez fiable rendre votre machine à nouveau propre, enregistrer en reformatant le disque et en réinstallant à partir de zéro.

Évitez les soucis et les maux de tête futurs; neutraliser votre système depuis l'orbite .

M15K · Answer

Comme je le disais dans la réponse au cross-post de ServerFault. Que c'est une bonne explication. En outre, cela dépend certainement du type d'attaque; j'espère ou malheureusement, cette attaque est suffisamment bruyante pour que vous la reconnaissiez comme une attaque en cours. Ou, à ce que vous pouvez être raisonnablement certain sont les premiers stades d'une attaque, je dirais que cet ordre des opérations est un bon plan à suivre.

Mais, il est possible que les indicateurs de compromis que vous connaissez, ne peignent pas l'image complète de l'infection et déconnecter ce PC ne soit pas dans votre intérêt tant que vous ne comprenez pas l'étendue, je soutiens qu'il pourrait être préférable de le découvrir les points d'entrée et les systèmes que vous ne pouvez pas contrôler avant de commencer à retirer tous les systèmes/périphériques affectés du réseau.

La vérité peut être que ces acteurs sont dans vos systèmes depuis plus longtemps que vous ne le pensiez et montrer votre main trop tôt (c'est-à-dire que j'ai finalement remarqué que vous étiez assis dans mes systèmes) pourrait rendre beaucoup plus difficile l'éradication.

Il n'y a pas de vraie réponse facile, mais celle fournie par RobM est un point de départ plus que suffisant. Avec toutes les pressions, il y a plusieurs bonnes réponses qui pourraient tout aussi bien être de mauvaises réponses. Presque comme le principe d'incertitude s'applique, vous ne savez pas si la réponse sera exacte jusqu'à ce que vous l'essayiez.

Le (PDF) NIST Computer Security Incident Handling Guide devrait également être examiné.

Sayan · Answer

La méthodologie est soumise au scénario exact du monde réel, mais ci-dessous serait une approche possible.

• Quelles sont mes premières étapes? Quand j'arrive sur le site dois-je déconnecter le serveur, conserver les "preuves", y a-t-il d'autres considérations initiales?

Rép: Bien sûr, vous devez déconnecter le serveur du réseau mais ne devez pas éteindre/arrêter le serveur, car vous devrez peut-être faire un examen médico-légal pour comprendre la situation, l'impact de l'incident et devez conserver les preuves ( les données de votre mémoire peuvent être effacées si vous arrêtez le serveur).

Gestion de crise et communication - Si vous avez une politique de gestion de crise et de DR/BCP, suivez les procédures indiquées. Ceci est à nouveau soumis au scénario dans ce cas, cela pourrait être une propagation de virus, vous devrez donc peut-être suivre votre processus.

• Comment dois-je procéder pour remettre les services en ligne?

Rép: Comme indiqué ci-dessus, suivez vos instructions de gestion de crise/DR/BCP. Cela peut varier selon la situation.

Par exemple, si ce virus était une bombe à retardement ou déclenché par une action sur le serveur et une attaque Ransomware, il est préférable de ne pas mettre votre DR immédiatement (cela pourrait déclencher la propagation d'un autre malware à partir de votre serveur DR). La meilleure méthode serait d'évaluer l'impact de l'incident sur votre réseau, puis de prendre les mesures nécessaires pour ramener vos services.

• Comment puis-je empêcher que la même chose ne se reproduise immédiatement?

Rép: La cause première de l'incident doit être déterminée dès que possible pour éviter que le même incident ne se reproduise. Comme indiqué dans la réponse ci-dessus, dans un scénario Ransomware, vous devrez peut-être vous assurer que le malware n'est pas propagé sur votre DR/Backup.

Si l'incident s'est produit en raison d'une vulnérabilité de votre réseau (par exemple, un port de pare-feu a été ouvert par erreur et l'attaque est passée par ce port, des mesures immédiates doivent être prises pour fermer la vulnérabilité connue/identifiée afin d'éviter que l'incident ne se reproduise.

• Existe-t-il des meilleures pratiques ou méthodologies pour apprendre de cet incident?

Rép: Oui, chaque incident peut être de nature unique. Donc, mettez à jour vos procédures de gestion de crise/DR/BCP pour refléter l'apprentissage de tels incidents.

Il est toujours recommandé de mettre en place une surveillance proactive/identification des incidents pour éviter/détecter rapidement de tels incidents. Par exemple, vous pouvez déployer des outils SOC (Security Operations Center) ou SIEM (Security Incident Event Management).

• Si je voulais élaborer un plan de réponse aux incidents, par où commencer? Cela devrait-il faire partie de ma planification de reprise après sinistre ou de continuité des activités?

Rép: Cela devrait faire partie de votre plan BCP/DR et généralement couvert par la gestion de crise (partie du plan BCP).

Tim Seed · Answer

Sauvegardez le tout - afin que vous puissiez effectuer des analyses judiciaires dans un environnement de type sandbox.

Ensuite - commencez à partir de 0 - oui de RIEN.

Nouveau O/S - entièrement corrigé. Applications - Fichiers de données actuels et à jour ... à partir de vos sauvegardes (avant le moment où vous avez été compromis si possible). Si ce n'est pas le cas, vous devez TOUT numériser le contenu et les autorisations.

Ensuite, effectuez un examen approfondi de la façon dont les pirates informatiques sont entrés et assurez-vous que cela ne se reproduise plus.

Lorsque vous découvrez ce qui s'est passé - prenez des mesures pour vous assurer que cela ne se reproduise plus et publiez (en interne et/ou en externe) ce que vous avez trouvé (vous pouvez choisir d'omettre les contre-mesures).

À moins que vous ne tiriez des leçons de cela, vous subirez de nouveau le même sort.