Red October : les modules pour mobiles

Magazine
Marque
MISC
Numéro
68
Mois de parution
juillet 2013
Domaines


Résumé
En octobre 2012, l’équipe d’experts de Kaspersky Lab a mené une enquête à la suite d’une série d’attaques contre des réseaux informatiques ciblant des services diplomatiques internationaux. L’enquête a permis de mettre à jour et d’analyser un réseau de cyberespionnage à grande échelle. L’opération « Red October » aurait débuté en mai 2007 et se poursuivait encore en janvier 2013 lors de la publication de notre premier rapport.Le principal objectif des assaillants était de recueillir des renseignements auprès des organismes compromis. Les informations obtenues sur les réseaux infectés étaient souvent réutilisées pour s’introduire dans d’autres systèmes (liste d’identifiants collectés, etc.). Pour piloter le réseau des machines infectées, les auteurs des attaques ont créé plus de 60 noms de domaines et ont utilisé plusieurs serveurs hébergés dans différents pays, dont la majorité en Allemagne et en Russie.Outre les cibles traditionnelles (postes de travail), le système est capable de voler des données à partir d'appareils mobiles (iPhone, Nokia, Windows Mobile), d’équipements réseau d'entreprise (Cisco) et de disques amovibles (y compris les données déjà supprimées via une procédure de récupération).Cet article s’intéresse à la partie mobile de Red October.Avant de présenter les modules pour mobiles, nous allons voir comment ceux-ci sont installés sur la machine cible.

1. Vecteur d'infection

Toutes les attaques contre les mobiles sont effectuées à l'aide d'une machine (PC) infectée au préalable. Les machines sont compromises à l'aide d'attaques classiques (en l'occurrence du spearphishing et des documents piégés) afin d'installer un cheval de Troie sur la machine :

firststage

L'exécutable embarqué est un « Dropper », qui extrait et exécute trois fichiers supplémentaires. Parmi ces trois fichiers, deux d'entre eux sont intéressants. Le premier est un Loader, responsable du chargement du second. Celui-ci est compressé avec la bibliothèque zlib puis chiffré en RC4. Le Loader s'assure que la machine est connectée à Internet avant de décompresser et déchiffrer la backdoor en mémoire, qui contactera le serveur C & C.

Une fois la connexion avec le serveur C & C établie, la backdoor commence le processus de communication, ce qui conduit au chargement des modules additionnels. Ces modules peuvent être divisés en deux catégories :

-...

Cet article est réservé aux abonnés. Il vous reste 92% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

Les lolbas, des amis qui vous veulent du bien

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Il existe des fichiers nativement présents sur Windows pouvant être détournés par un attaquant et ainsi être utilisés lors des différentes phases de compromission. Dans cet article, nous présenterons quelques cas d’utilisations de ces fichiers par des attaquants, ainsi que des solutions de prévention contre ces attaques.

Sécurité réseau dans un cluster Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

En introduisant le concept de micro-services, Kubernetes lance un nouveau défi aux solutions d’isolation et de filtrage réseau : comment gérer les droits d’accès réseau dans une infrastructure en constante mutation et dans laquelle une machine n’a plus un rôle prédéterminé ?

Définissez l'architecture de vos serveurs et installez-les

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.

Migrez de iptables vers nftables

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Il y a cinq ans, je lisais un premier article sur nftables [1] : l’outil semblait intéressant, mais il n’était pas disponible sur ma machine. En 2019, une distribution majeure, Debian, a basculé sur nftables avec sa version 10 (Buster) [2] : il est donc temps de voir comment migrer du vénérable pare-feu iptables vers son successeur.

Cas pratique sur la sécurisation d'un cluster Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Cet article présente trois exemples de problèmes de sécurité rencontrés sur des clusters Kubernetes, causés par un manque de maîtrise des applications déployées sur un cluster par ses administrateurs ou par les développeurs des applications s’y exécutant. Nous donnons ensuite des pistes afin de mieux maîtriser et sécuriser ces applications.