
Framework C2 multi-opérateur avec agents natifs en C et Python, canaux HTTP(S), tâches asynchrones et une interface web réactive pour les opérations d'équipe rouge.
Striker est un simple programme de commande et contrôle (C2).


Ce projet est en développement actif. La plupart des fonctionnalités sont expérimentales, d'autres à venir. Attendez-vous à des changements majeurs.
A) Agents
B) Backend / Teamserver
C) Interface utilisateur
Clonez le dépôt ;
$ git clone https://github.com/4g3nt47/Striker.git
$ cd Striker
Le code est divisé en 4 sections indépendantes ;
Il gère toute la logique serveur pour les opérateurs et les agents. C'est une application NodeJS réalisée avec ;
express - Pour l'API REST.socket.io - Pour la communication Web Socket.mongoose - Pour la connexion à MongoDB.multer - Pour la gestion des téléchargements de fichiers.bcrypt - Pour le hachage des mots de passe utilisateur.Le code source se trouve dans le répertoire backend/. Pour configurer le serveur ;
Striker utilise MongoDB comme base de données backend pour stocker toutes les données importantes. Vous pouvez l'installer localement sur votre machine en utilisant ce guide pour les distributions basées sur Debian, ou en créer une gratuite avec MongoDB Atlas (une plateforme de base de données en tant que service).
$ cd backend
$ npm install
$ mkdir static
Vous pouvez utiliser ce dossier pour héberger des fichiers statiques sur le serveur. Ce devrait également être l'emplacement où votre UPLOAD_LOCATION est défini dans le fichier .env (plus de détails plus tard), mais ce n'est pas nécessaire. Les fichiers de ce répertoire seront accessibles publiquement sous le chemin /static/.
.env ;NOTE : Les valeurs entre < et > sont des espaces réservés. Remplacez-les par des valeurs appropriées (y compris les <>).
Pour les champs qui nécessitent des chaînes aléatoires, vous pouvez les générer facilement en utilisant ;
$ head -c 100 /dev/urandom | sha256sum
DB_URL=<votre URL de connexion MongoDB>
HOST=<hôte sur lequel écouter (par défaut : 127.0.0.1)>
PORT=<port sur lequel écouter (par défaut : 3000)>
SECRET=<chaîne aléatoire à utiliser pour signer les cookies de session et chiffrer les données de session>
ORIGIN_URL=<URL complète du serveur où vous hébergerez le frontend. Utilisée pour configurer CORS>
REGISTRATION_KEY=<chaîne aléatoire à utiliser pour l'authentification lors de l'inscription>
MAX_UPLOAD_SIZE=<taille maximale de téléchargement de fichier, en octets>
UPLOAD_LOCATION=<répertoire pour stocker les fichiers téléchargés (par défaut : static)>
SSL_KEY=<votre fichier de clé SSL (optionnel)>
SSL_CERT=<votre fichier de certificat SSL (optionnel)>
Notez que SSL_KEY et SSL_CERT sont optionnels. Si l'un n'est pas défini, un serveur HTTP simple sera créé. Cela permet d'éviter une surcharge inutile lorsque le serveur est exécuté derrière un proxy inverse compatible SSL sur le même hôte.
$ node index.js
[12:45:30 PM] Connecting to backend database...
[12:45:31 PM] Starting HTTP server...
[12:45:31 PM] Server started on port: 3000
C'est l'interface web utilisée par les opérateurs. C'est une application web monopage écrite en Svelte, et le code source se trouve dans le répertoire frontend/.
Pour configurer le frontend ;
$ cd frontend
$ npm install
.env avec la variable VITE_STRIKER_API définie sur l'URL complète du serveur C2 configuré ci-dessus ;VITE_STRIKER_API=https://c2.striker.local
$ npm run build
Ce qui précède compilera tout en une application web statique dans le répertoire dist/. Vous pouvez déplacer tous les fichiers à l'intérieur dans la racine web de votre serveur web, ou même l'héberger avec un serveur HTTP basique comme celui de python ;
$ cd dist
$ python3 -m http.server 8000
Register.REGISTRATION_KEY dans backend/.env)Cela créera un compte utilisateur standard. Vous aurez besoin d'un compte administrateur pour accéder à certaines fonctionnalités.
Votre premier compte administrateur doit être créé manuellement, ensuite vous pouvez promouvoir ou rétrograder d'autres comptes dans l'onglet Users de l'interface web.
Pour créer votre premier compte administrateur ;
users et définissez le champ admin de l'utilisateur cible sur true ;Il existe différentes façons de procéder. Si vous avez mongo disponible dans votre CLI, vous pouvez le faire en utilisant ;
$ mongo <votre URL de connexion MongoDB>
> db.users.updateOne({username: "<votre nom d'utilisateur>"}, {$set: {admin: true}})
Vous devriez obtenir la réponse suivante si cela fonctionne ;
{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
Vous pouvez maintenant vous connecter :)
A) Redirection par tuyau brut
Un redirecteur par tuyau brut écrit pour Striker est disponible dans redirector/redirector.py. Évidemment, cela ne fonctionnera que pour le trafic HTTP simple, ou pour HTTPS lorsque la vérification SSL est désactivée (vous pouvez le faire en activant la macro INSECURE_SSL dans l'agent C).
L'exemple suivant écoute sur le port 443 sur toutes les interfaces et transmet à c2.example.org sur le port 443 ;
$ cd redirector
$ ./redirector.py 0.0.0.0:443 c2.example.org:443
[*] Starting redirector on 0.0.0.0:443...
[+] Listening for connections...
B) Proxy inverse Nginx comme redirecteur
$ sudo apt install nginx
/etc/nginx/sites-available/striker) ;Espaces réservés ;
<domain-name> - C'est le FQDN de votre serveur, et doit correspondre à celui de votre certificat SSL.<ssl-cert> - Le fichier de certificat SSL à utiliser.<ssl-key> - Le fichier de clé SSL à utiliser.<c2-server> - L'URL complète du serveur C2 vers lequel transférer les requêtes.ATTENTION : client_max_body_size doit être aussi grand que la taille définie par MAX_UPLOAD_SIZE dans votre fichier backend/.env, sinon les téléchargements de fichiers volumineux échoueront.
server {
listen 443 ssl;
server_name <domain-name>;
ssl_certificate <ssl-cert>;
ssl_certificate_key <ssl-key>;
client_max_body_size 100M;
access_log /var/log/nginx/striker.log;
location / {
proxy_pass <c2-server>;
proxy_redirect off;
proxy_ssl_verify off;
proxy_read_timeout 90;
proxy_http_version 1.0;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
$ sudo ln -s /etc/nginx/sites-available/striker /etc/nginx/sites-enabled/striker
$ sudo service nginx restart
Votre redirecteur devrait maintenant être opérationnel sur le port 443, et peut être testé en utilisant (en supposant que votre FQDN est striker.local) ;
$ curl https://striker.local
Si cela fonctionne, vous devriez obtenir la réponse 404 utilisée par le backend, comme ;
{"error":"Invalid route!"}
A) L'agent C
Ce sont les implants utilisés par Striker. L'agent principal est écrit en C, et se trouve dans agent/C/. Il prend en charge les hôtes Linux et Windows. L'agent Linux dépend extérieurement de libcurl, que vous trouverez installé sur la plupart des systèmes.
L'agent Windows n'a pas de dépendance externe. Il utilise wininet pour les communications, qui est disponible sur tous les hôtes Windows, je crois.
En supposant que vous êtes sur un hôte 64 bits, ce qui suit compilera pour un hôte 64 bits ;
$ cd agent/C
$ mkdir bin
$ make
Pour compiler pour 32 bits sur 64 ;
$ sudo apt install gcc-multilib
$ make arch=32
Ce qui précède compile tout dans le répertoire bin/. Vous n'aurez besoin que de deux fichiers pour générer des implants fonctionnels ;
bin/stub - C'est le stub de l'agent qui sera utilisé comme modèle pour générer des implants fonctionnels.bin/builder - C'est ce que vous utiliserez pour patcher le stub de l'agent afin de générer des implants fonctionnels.Le builder accepte les arguments suivants ;
$ ./bin/builder
[-] Usage: ./bin/builder <url> <auth_key> <delay> <stub> <outfile>
Où ;
<url> - Le serveur auquel se rapporter. Idéalement, cela devrait être un redirecteur, mais une URL directe vers le serveur fonctionnera aussi.<auth_key> - La clé d'authentification à utiliser lors de la connexion au C2. Vous pouvez la créer dans l'onglet auth keys de l'interface web.<delay> - Délai entre chaque rappel, en secondes. Cela devrait être d'au moins 2, selon le niveau de bruit que vous souhaitez.<stub> - Le fichier stub à lire, bin/stub dans ce cas.<outfile> - Le nom du fichier de sortie du nouvel implant.Exemple ;
$ ./bin/builder https://localhost:3000 979a9d5ace15653f8ffa9704611612fc 5 bin/stub bin/striker
[*] Obfuscating strings...
[+] 69 strings obfuscated :)
[*] Finding offsets of our markers...
[+] Offsets:
URL: 0x0000a2e0
OBFS Key: 0x0000a280
Auth Key: 0x0000a2a0
Delay: 0x0000a260
[*] Patching...
[+] Operation completed!
Vous aurez besoin de MinGW pour cela. Ce qui suit installera l'environnement de développement Windows 32 et 64 bits ;
$ sudo apt install mingw-w64
Compilez pour 64 bits ;
$ cd agent/C
$ mdkir bin
$ make target=win
Pour compiler pour 32 bits ;
$ make target=win arch=32
Cela compilera tout dans le répertoire bin/, et vous aurez le builder et le stub sous les noms bin\stub.exe et bin\builder.exe, respectivement.
B) L'agent Python
Striker est également fourni avec un agent Python autonome (testé sur Python 2.7.16 et 3.7.3). Il se trouve dans agent/python/. Seules les fonctionnalités les plus basiques sont implémentées dans cet agent. Utile pour les hôtes qui ne peuvent pas exécuter l'agent C mais ont Python installé.
Il y a 2 fichiers dans ce répertoire ;
stub.py - C'est le stub de payload à passer au builder.builder.py - C'est ce que vous utiliserez pour générer un implant.Exemple d'utilisation :
$ ./builder.py
[-] Usage: builder.py <url> <auth_key> <delay> <stub> <outfile>
# The following will generate a working payload as `output.py`
$ ./builder.py http://localhost:3000 979a9d5ace15653f8ffa9704611612fc 2 stub.py output.py
[*] Loading agent stub...
[*] Writing configs...
[+] Agent built successfully: output.py
# Run it
$ python3 output.py
Après avoir suivi les instructions ci-dessus, Striker devrait maintenant être prêt à être utilisé. Veuillez consulter le guide d'utilisation. Amusez-vous bien et bon hacking !
Si vous aimez le projet, envisagez de m'aider à transformer le café en code !