Telegram C2-Profil für Mythic

Telegram stellt ein Mythic C2-Profil für die Agents Athena und Apollo bereit. Es verwendet private Bot-zu-Bot-Nachrichten von Telegram als Transport und Mythics Push-C2-gRPC-Dienst als Controller-Bridge.

Architektur

Athena- oder Apollo-Agent-Bot <-> Telegram Bot API <-> Controller-Bot <-> Telegram-C2-Dienst <-> Mythic

Jeder laufende Agent verwendet sein eigenes Bot-API-Token. Der C2-Dienst verwendet ein Controller-Bot-Token. Beide Bots müssen den Bot-zu-Bot-Kommunikationsmodus von Telegram aktiviert haben.

Nachrichten verwenden einen kleinen JSON-Umschlag und werden in 2.800-Zeichen-Chunks aufgeteilt, bevor sie über sendMessage gesendet werden. Agent-Payloads behalten ihre aes256_hmac-Verschlüsselung bei; der Telegram-Dienst leitet verschlüsselte Mythic-Nachrichten weiter, ohne sie zu entschlüsseln.

Voraussetzungen

• Mythic 3
• Ein unterstützter Agent-Fork mit dem Telegram-Transport:
  • Athena
  • Apollo
• Ein Telegram-Controller-Bot
• Ein Telegram-Bot für jede gleichzeitig laufende Payload-Instanz

Installation

Führen Sie diesen Befehl aus dem Mythic-Verzeichnis aus:

./mythic-cli install github https://github.com/DavidCarliez/mythic_telegram_profile

Für die lokale Entwicklung installieren Sie stattdessen den Checkout:

./mythic-cli install folder /path/to/telegram -f

Installieren Sie einen der unterstützten Agent-Forks in derselben Mythic-Bereitstellung:

# Athena
./mythic-cli install github https://github.com/DavidCarliez/Athena -b telegram-c2

# Apollo
./mythic-cli install github https://github.com/DavidCarliez/Apollo -b telegram-c2

Telegram-Einrichtung

1. Verwenden Sie @BotFather, um den Controller-Bot zu erstellen.
2. Erstellen Sie einen separaten Bot für jede Payload-Instanz, die gleichzeitig ausgeführt wird.
3. Aktivieren Sie den Bot-zu-Bot-Kommunikationsmodus für den Controller-Bot und jeden Agent-Bot.
4. Notieren Sie das Token und den Benutzernamen des Controller-Bots.
5. Notieren Sie jedes Agent-Bot-Token. Verwenden Sie ein Token nicht für gleichzeitige Payloads wieder, da sich getUpdates-Konsumenten eine Update-Warteschlange teilen.

Private Bot-zu-Bot-Nachrichten erfordern den Kommunikationsmodus bei beiden Bots. Telegram dokumentiert die Anforderung in seinem Leitfaden Bot-to-Bot Communication.

Den C2-Dienst konfigurieren

Öffnen Sie in Mythic C2 Profiles, erweitern Sie die Aktionen für telegram und wählen Sie View/Edit Config. Legen Sie fest:

Key	Value
botToken	Controller-Bot-Token von BotFather
apiBase	https://api.telegram.org, sofern kein kompatibler lokaler Bot-API-Server verwendet wird
pollTimeout	Long-Poll-Timeout von 1 bis 50 Sekunden
mythicGrpc	Mythic Push C2 gRPC-Endpunkt; behalten Sie den mitgelieferten Wert für eine normale Mythic-Bereitstellung bei

Speichern Sie die Konfiguration und starten Sie dann das Profil.

Eine Payload erstellen

Wählen Sie das C2-Profil telegram beim Erstellen von Athena oder Apollo aus und geben Sie Folgendes an:

Parameter	Beschreibung
bot_token	Token für den dedizierten Agent-Bot der Payload
controller_bot	Benutzername des Controller-Bots, mit oder ohne @
api_base	Basis-URL der Telegram Bot API
message_checks	Maximale Long-Polls beim Warten auf jede Controller-Antwort
time_between_checks	Long-Poll-Timeout in Sekunden
callback_interval	Agent-Callback-Intervall in Sekunden
callback_jitter	Agent-Callback-Jitter in Prozent
AESPSK	aes256_hmac-Nachrichtenverschlüsselung
user_agent	HTTP-User-Agent, der an Telegram gesendet wird
proxy_*	Optionale HTTP-Proxy-Einstellungen
killdate	Ablaufdatum der Payload

Betriebliche Einschränkungen

• Ein Bot-API-Token ist ein Bearer-Credential. Beschränken Sie den Zugriff und widerrufen Sie es nach der Verwendung über BotFather.
• Das Agent-Token ist in der Payload eingebettet. Behandeln Sie eine wiedererlangte Payload als kompromittiertes Token.
• Der Telegram-Transport ist nicht Ende-zu-Ende-verschlüsselt. Lassen Sie AESPSK aktiviert.
• Telegram speichert Nachrichtenmetadaten und kann Nachrichteninhalte gemäß seinen Dienstrichtlinien speichern.
• Dieses Profil verwendet Long Polling, keine Webhooks.
• Ein einzelnes Bot-Token darf nicht von gleichzeitigen Agent-Instanzen gemeinsam genutzt werden. Ihre getUpdates-Aufrufe würden die Antworten der jeweils anderen konsumieren.
• Der Controller akzeptiert nur von Bots verfasste, versionierte Transport-Umschläge. Die Mythic-Verschlüsselung bietet weiterhin Nachrichtenauthentifizierung und Vertraulichkeit.
• Agent-Anfragen bleiben ausstehend, bis eine korrelierte Controller-Antwort eintrifft. Wiederholte Anfragen verwenden denselben Anfragebezeichner wieder, und der Controller spielt zwischengespeicherte Antworten erneut ab, ohne doppelten Datenverkehr an Mythic weiterzuleiten.
• Mythic kann Tasking pushen, wenn keine Agent-Anfrage aussteht. Der Controller stellt dieses Tasking in die Warteschlange und korreliert es mit dem nächsten Austausch des Agents, anstatt es zu verwerfen.
• Der Controller meldet eine Route als getrennt nach drei verpassten maximalen Jitter-Callback-Intervallen plus 30 Sekunden, mit einem Mindest-Timeout von 60 Sekunden.

Wire-Format

Jede Telegram-Textnachricht enthält ein JSON-Objekt mit diesen Feldern:

• v: Protokollversion, derzeit 1
• sender_id: zufälliger Routenbezeichner, der vom Agent-Prozess generiert wird
• client_id: Antwort-Routenbezeichner
• to_server: Richtungsflag
• packet_id: Chunk-Set-Bezeichner
• reply_to: Anfragebezeichner, der durch eine Controller-Antwort bestätigt wird
• sleep: aktuelles Agent-Callback-Intervall in Sekunden
• jitter: aktueller Agent-Callback-Jitter in Prozent
• chunk: nullbasierter Chunk-Index
• chunks: Gesamtzahl der Chunks, begrenzt auf 256
• message: verschlüsseltes Mythic-Nachrichtenfragment

Unvollständige Chunk-Sets laufen nach zehn Minuten ab.