Enquête sur la résurgence de la campagne Mexals
Synthèse
Commentaires éditoriaux et additionnels de Tricia Howard
Le service de recherche en sécurité d'Akamai a suivi et analysé la résurgence de Mexals, une campagne de cryptojacking probablement basée en Roumanie.
La campagne est menée depuis au moins 2020 et a déjà fait l'objet d'un rapport de Bitdefender en juillet 2021.
La nouvelle vague d'attaques et d'améliorations des logiciels malveillants semble avoir débuté en octobre 2022. Ces derniers se font désormais appeler Diicot, qui est également le nom de l'agence roumaine de lutte contre le terrorisme et le crime organisé.
Les chercheurs en sécurité d'Akamai ont commencé à analyser la campagne suite à la détection d'un DNS malveillant chez un client d'Akamai. Tous les clients d'Akamai concernés ont été rapidement informés et des contre-mesures appropriées ont été prises.
Les pirates utilisent une longue chaîne de charges utiles avant d'exécuter un mineur de cryptomonnaies Monero.
Ils utilisent désormais un module de ver SSH (Secure Shell Protocol), établissent plus de rapports, améliorent le brouillage des charges utiles et disposent d'un nouveau module de diffusion sur le réseau local (LAN).
En analysant le pool du mineur, nous estimons que les pirates ont extrait des pièces XMR d'une valeur d'environ 10 000 $.
Nous proposons des stratégies de protection, des outils de détection et un référentiel complet d'indicateurs d'infection (IOC). Ces outils nous ont également permis de contacter les personnes concernées, avant la publication de ce blog.
Introduction
Les chercheurs en sécurité d'Akamai ont analysé une campagne active de cryptojacking. Nous pensons qu'il s'agit d'une résurgence de la campagne de 2021 couverte par Bitdefender. Malgré plusieurs similitudes avec le rapport initial, ces logiciels malveillants ont progressé depuis lors.
Les deux campagnes ont notamment changé de nom : le groupe anciennement connu sous le nom de Mexals (voir leur page Web à la Figure 1) se fait désormais appeler Diicot, et l'un de leurs outils porte le même nom. Diicot est également le nom de l'agence antiterroriste roumaine.Afin d'éviter toute confusion, nous désignerons le groupe de cybercriminels sous le nom de Mexals. Lors de l'analyse de leur mode opératoire, de la chaîne des charges utiles et des IOC, il est devenu évident que, malgré le changement de nom, ces deux campagnes étaient liées.
Figure 1 : Page Web par défaut affichée sur le domaine du pirate, qui héberge également ses charges utiles
Dans cette campagne, nous avons constaté que le brouillage avait été amélioré, que les noms de fichiers étaient plus discrets et que les proxies du pool minier étaient personnalisés, ce qui n'était pas le cas dans l'itération précédente. La première étape du processus est l'attaque en force par le biais de l'authentification SSH. Ensuite, on trouve une longue chaîne de charges utiles brouillées, qui finit par exécuter un mineur de cryptomonnaies XMRig. L'une des charges utiles larguées est un module de ver qui, selon nous, a été actif dans cette résurgence.
Nous estimons également que leurs serveurs d'attaque sont hébergés dans un VPS basé aux Pays-Bas, et que leurs victimes sont éparpillées aux quatre coins du monde. Selon nos calculs, les pirates ont réussi à extraire plus de 10 000 $ en pièces XMR.
Certains pirates disposent d'une boîte à outils. Ces personnes semblent avoir une véritable chaîne
Notre analyse de la chaîne d'infection des pirates nous a permis de trouver huit exécutables. Ils ne semblent pas très différents de ceux observés par Bitdefender, à l'exception des noms de fichiers et des chemins d'accès, ainsi que de quelques nouvelles fonctionnalités (Figure 2).
Nom de la charge utile |
Utilisation |
|---|---|
History |
Un script bash. Vérifie si Update est en cours d'exécution. Si ce n'est pas le cas, il l'exécute. |
Update |
Un script bash compilé. Informe les pirates via un webhook Discord et exécute un scan réseau sur un réseau IP aléatoire de classe B pour les machines avec SSH ouvert. Fournit les résultats à aliases. |
Chrome/ps |
Un scanner réseau. Accepte un réseau de classe B (255.255.0.0) et un port. Recherche sur le réseau les machines dont le port est ouvert et enregistre les résultats dans un fichier. |
Un module de ver SSH écrit en Golang. Exécute payload. |
|
Le principal module post-intrusion. En fonction des ressources dont dispose la victime, ce module installe soit une porte dérobée, soit un mineur de cryptomonnaies, soit un ver LAN SSH. |
|
.diicot |
Un script bash compilé. Télécharge Opera, un mineur de cryptomonnaies. De plus, il installe une autre porte dérobée sous la forme d'un nouvel utilisateur et d'une clé SSH. |
Opera |
Un mineur de cryptomonnaies XMRig. |
Un script bash compilé. Il correspond au début du module de diffusion LAN. Exécute un balayage de port SSH sur la plage IP du LAN interne et lance ensuite un appel à Network pour essayer de pirater les machines à l'aide de SSH. |
|
Network |
Une autre variante d' aliases avec moins de capacités. Exécute une attaque par dictionnaire SSH sur le LAN local, enregistre les informations sur les machines piratées (et les identifiants de travail) dans un fichier texte. |
Figure 2 : Résumé des différentes charges utiles utilisées par les pirates
Génération de binaires et brouillage
Le changement le plus important observé concerne le brouillage des charges utiles. Auparavant, la plupart des charges utiles exécutables étaient en fait des scripts bash compilés avec shc, mais ces scripts bash compilés étaient également compressés avec UPX, et l'en-tête UPX a été tronqué pour entraver l'analyse et la décompression (Figure 3).
Figure 3 : Un exécutable compressé ne peut pas être décompressé par UPX en raison d'un en-tête tronqué
Heureusement, nous disposions d'un outil conçu par Larry Cashdollar, chercheur chez Akamai, dans le cadre d'une précédente alerte SIRT. Cet outil nous a permis de rétablir facilement l'en-tête UPX, de décompresser les exécutables ELF et d'extraire les scripts bash qu'ils contiennent.
Nous nous retrouvons alors avec un binaire entièrement tronqué et compilé de manière statique, sans aucun moyen de distinguer le code du logiciel malveillant de celui de la glibc (Figure 4).
Figure 4 : Le point d'entrée du binaire tronqué
Le code source de la glibc nous permet de comprendre les caractéristiques du point d'entrée. La fonction principale est celle qui est chargée dans rdi. Après avoir étudié plus en détail la question, nous avons trouvé une chaîne d'erreur assez spécifique : E : neither argv[0] nor $_ works.qui peut être recherchée sur le Web. Cette erreur nous mène à shc. Malheureusement, les décompilateurs ne sont pas accessibles facilement. Plutôt que de procéder à une rétro-ingénierie et de créer un décrypteur (opération trop fastidieuse), nous pouvons déboguer la charge utile et interrompre l'exécution au bout d'une seconde. Le script shell décrypté résidera dans la mémoire du logiciel malveillant, que nous pourrons ensuite extraire et analyser.
Chaîne d'infection
Figure 5 : La chaîne de charge utile complète
Chaque charge utile s'enchaîne de manière relativement simple, avec différentes méthodes pour établir le lien suivant. Par exemple, la destruction de mineurs concurrents ou de processus gourmands en ressources processeur, le nettoyage de l'historique de bash ou l'installation de la persistance, puis le téléchargement et l'exécution de la charge utile suivante (Figure 5).
Analyse technique des principales charges utiles
aliases
Il s'agit d'un binaire en Golang, qui n'a pas été tronqué pour permettre de trouver facilement toute la logique du logiciel malveillant. Le logiciel malveillant lit deux fichiers créés lors des étapes précédentes : le fichier protocols (liste de mots de passe utilisateur déposée par Update) ainsi que le fichier bios.txt (liste d'adresses IP cibles de machines avec SSH ouvert, créée par Chrome). Il procède ensuite à une attaque par dictionnaire sur chaque cible et, en cas d'authentification réussie, exécute payload et d'autres commandes pour établir le profil du système violé.
La dernière commande à être exécutée est uname -s -v -n -r -m, et son résultat est analysé. Plus précisément, elle recherche des noms de systèmes d'exploitation spécifiques dans ce résultat qui peuvent indiquer des cibles intéressantes. Pour la plupart des noms de systèmes d'exploitation recherchés, elle ne fait rien, mais si la machine cible exécute OpenWrt, elle lance une autre commande bash pour télécharger et exécuter un autre script shell à partir de 107.182.129.219, qui exécutera une variante de Mirai. Selon nos recherches, la raison pour laquelle OpenWrt est ciblé réside dans le fait qu'il est installé sur des terminaux intégrés et qu'il pourrait servir de vecteur d'accès initial aux réseaux d'entreprise. Les pirates montrent ainsi qu'ils sont intéressés par plus qu'une simple campagne de cryptomining et qu'ils cherchent activement de nouveaux terrains à conquérir.
Une fois la tentative d'intrusion terminée, le logiciel malveillant envoie un rapport aux pirates par l'intermédiaire d'un webhook Discord (une pratique d'attaque qui gagne en popularité). Il existe quatre webhooks distincts, avec des objectifs différents (Figure 6).
Figure 6 : Interception des webhooks Discord appelés par le logiciel malveillant
Le premier webhook provient d'une fonction appelée toDiscord, et il relègue les résultats des différentes commandes de profilage exécutées sur la machine cible. Les deux suivants sont appelés à partir des fonctions toAPIlogs et toDisc, et relèguent tous deux les mêmes informations : l'adresse IP de la cible, ainsi que le nom de l'utilisateur et le mot de passe permettant de s'authentifier sur cette dernière.
Enfin, si la victime exécute OpenWrt, une autre fonction, toMirai, est appelée et envoie les mêmes informations à un autre webhook. La redondance est notable ici, et nous supposons qu'elle permet aux pirates de suivre plus facilement différentes mesures, ou qu'elle sert à séparer les différentes parties de leur campagne d'attaque (Mirai en tant que botnet/IAB par rapport à l'utilisation régulière de Mirai en tant que mineur de cryptomonnaies).
payload
Bien qu'il ne s'agisse « que » d'un script bash compilé, la payload est intéressante car elle est truffée de commentaires et de messages de progression, qui peuvent nous renseigner sur le processus de réflexion des opérateurs du logiciel malveillant.
Les commentaires et les messages de progression sont rédigés en roumain, ce qui nous conforte dans l'idée que les pirates sont roumains (le domaine de commande et de contrôle/téléchargement du logiciel malveillant se traduit littéralement par « l'archive du pirate »).
Le script détecte également la présence d'autres mineurs de cryptomonnaies connus et détruit leurs processus, notamment dhpcd et ksmdx. Les pirates sont donc conscients de leur écosystème et ne se contentent pas seulement de tenter leur chance dans le monde du minage de cryptomonnaies.
Après avoir éliminé ses concurrents et d'autres processus gourmands en ressources processeur, le script vérifie le nombre de cœurs de processeur de la machine. S'il y en a moins de quatre, il installe simplement History et Update ainsi qu'une tâche cron pour eux. (Les deux exécutables sont chargés de télécharger la charge utile d' aliases et sont programmés pour s'exécuter lors du redémarrage de la machine cible.) S'il y a quatre cœurs ou plus, le script télécharge et exécute également .diicot, un script bash compilé qui télécharge et exécute un mineur de cryptomonnaies XMRig.
Enfin, s'il y a huit cœurs de processeur ou plus, le script télécharge et exécute retea, le diffuseur LAN.
retea
Le module de diffusion LAN présente une nouvelle capacité dans la chaîne des pirates. Il s'agit d'un autre script shell compilé, qui extrait tous les utilisateurs configurés sur le système et crée un fichier appelé .usrs. Le fichier est utilisé pour une attaque par dictionnaire SSH et est alimenté à l'aide des utilisateurs extraits et d'une liste de mots de passe par défaut codés en dur. Il télécharge et exécute ensuite un scanner réseau sur le LAN, qui détecte les machines avec des ports SSH ouverts et écrit le résultat dans un fichier. Ensuite, il télécharge et exécute Network, qui est une version réduite d' aliases, avec des capacités moindres. Au lieu d'installer une charge utile malveillante ou d'envoyer un rapport à un webhook Discord, il se contente d'enregistrer le résultat des machines piratées dans un fichier, qui peut être récupéré ultérieurement par les pirates.
Rencontre avec les victimes
Mais le sont-elles vraiment ?
Dans la mesure où les pirates disposent d'une charge utile en module de ver, il est difficile de distinguer les IP sources détectées par nos capteurs de menaces de l'infrastructure des pirates, et de celles des victimes. Dans cette section, nous allons essayer de disséquer l'infrastructure des pirates et de trouver des victimes réelles.
Toutes les adresses IP d'attaque que nous avons détectées (50 adresses IP uniques) ont été mises en correspondance avec leur emplacement géographique dans le monde. Outre les adresses IP attaquées, nous avons également trouvé des preuves d'infection chez certains clients d'Akamai, qui ont donc été ajoutés à notre liste de victimes. La répartition géographique des victimes/infrastructures est présentée dans la Figure 7.
Figure 7 : Carte du monde avec géolocalisation des adresses IP pirates
Bien que la plupart des sites montrent très peu d'activité, nous avons quelques zones de forte activité en Europe de l'Ouest. Le pic d'activité à cet endroit (Figure 8) nous amène à supposer que les zones de forte activité correspondent en réalité à des machines contrôlées par les pirates, tandis que les autres sont des machines piratées prises en charge par le module de ver. Le module de ver ne semble pas particulièrement actif, car nous ne constatons que très peu de machines actives en même temps. Ceci paraît logique, puisque aliases n'est exécuté qu'une seule fois par exécution de tâche cron, sur une classe B aléatoire. Le cron est programmé pour s'exécuter au redémarrage de la machine, ce qui est probablement peu fréquent, compte tenu de la nature des machines piratées (c'est-à-dire des serveurs Linux ouverts à Internet).
Figure 8 : Nombre d'adresses IP attaquant simultanément nos capteurs de menaces au fil du temps
Si l'on examine les adresses IP qui ont été enregistrées le plus souvent dans nos pots de miel, que nous supposons constituer l'infrastructure des pirates, on constate une répartition claire des hôtes (Figure 9). Les adresses IP les plus anciennes étaient hébergées chez DigitalOcean. Les adresses plus récentes (de la résurgence récente) semblent avoir été hébergées chez Serverion, un fournisseur de VPS et d'hébergement Web néerlandais (son ASN est en fait enregistré sous sa société mère, Des Capital B.V., une agence immobilière, ce qui nous a déconcertés au départ).
Date de l'attaque |
Nombre d'attaques |
IP du pirate |
Nom de l'entreprise d'hébergement |
|---|---|---|---|
1er février 2023 |
14 |
185.225.74.231 |
Des Capital B.V. |
1er octobre 2022 |
72 |
45.139.105.222 |
Des Capital B.V. |
1er octobre 2022 |
62 |
212.193.30.11 |
Des Capital B.V. |
1er mars 2022 |
22 |
195.133.40.157 |
Des Capital B.V. |
1er décembre 2021 |
43 |
134.209.95.47 |
DigitalOcean, LLC (DO-13) |
1er décembre 2021 |
37 |
134.209.195.231 |
DigitalOcean, LLC (DO-13) |
1er décembre 2021 |
34 |
104.248.85.104 |
DigitalOcean, LLC (DO-13) |
1er décembre 2021 |
27 |
134.209.198.229 |
DigitalOcean, LLC (DO-13) |
1er décembre 2021 |
27 |
167.71.48.128 |
DigitalOcean, LLC (DO-13) |
1er décembre 2021 |
74 |
188.166.60.8 |
DigitalOcean, LLC |
Figure 9 : Principales adresses IP, qui, à notre avis, correspondent à l'infrastructure des pirates et pas seulement à celle des victimes
Avant la publication de cet article de blog, nous avons contacté les clients d'Akamai concernés pour leur fournir des informations sur les attaques, ainsi que les adresses électroniques abusives enregistrées pour chaque adresse IP concernée.
Venez dehors, on va régler ça !
Il semble que les pirates aient modifié leur configuration de minage depuis la campagne précédente. Auparavant, ils demandaient à leurs mineurs de travailler directement avec supportxmr.com, tandis que les mineurs que nous avons récemment analysés communiquent avec des adresses IP qui sont probablement contrôlées par les cybercriminels. Notre crainte portait sur la possibilité que ces pools soient privés, ce qui signifierait que nous ne pourrions pas suivre les paiements. Cependant nos craintes n'étaient pas justifiées, car supportxmr a toujours suivi les paiements de minage vers le portefeuille, ce qui nous amène à penser que leurs serveurs ne sont que des proxys vers le pool hébergé par supportxmr. Il pourrait donc s'agir d'un moyen d'échapper au blocage et à la détection DNS en ne s'adressant pas directement au pool.
Nous sommes parvenus à extraire deux adresses de portefeuilles différentes des charges utiles XMRig que nous avons observées en enquêtant sur cette campagne. Ces adresses de portefeuilles sont différentes de celles observées par Bitdefender, mais d'après l'historique de leurs paiements, elles semblent avoir été actives pendant cette période également.
Les montants des paiements ont beaucoup varié avant novembre 2021 (atteignant même deux fois un XMR complet), mais ils sont devenus beaucoup plus fréquents et réguliers par la suite (Figure 10). Ce phénomène résulte peut-être d'une modification du système de paiement ou de l'ajout d'ouvriers mineurs. Les dates correspondent à d'autres pics d'activité des logiciels malveillants que nous avons détectés.
Figure 10 : Historique des paiements miniers au portefeuille des pirates, tel qu'extrait depuis supportxmr
Au total, nous estimons que les pirates ont réussi à extraire des XMR d'une valeur de plus de 10 000 $ pendant toute la durée de leur campagne, dont plus de 75 % ont été extraits depuis leur résurgence. Le montant réel extrait est probablement encore plus élevé par rapport à notre estimation. En effet, à en juger par le nombre de travailleurs uniques indiqué par supportxmr, nous n'avons observé que la moitié des charges utiles et des configurations XMRig (Figure 11).
Figure 11 : Les mineurs associés à l'un des portefeuilles des pirates
Résumé
La chaîne de charges utiles employée par les cybercriminels est assurément impressionnante et témoigne de la sophistication de ces derniers. Généralement, la chaîne de charges utiles n'est pas aussi longue, et il existe plusieurs raisons pour lesquelles les pirates ont choisi d'utiliser un si grand nombre de charges utiles.
Dissimulation : plus le système comporte de pièces mobiles, plus il est difficile de l'analyser et d'en garder la trace. Le brouillage des binaires ne fait que renforcer cette hypothèse.
Le groupe de cybercriminels est composé de plusieurs personnes. Même si nous ne disposons d'aucune information concrète sur les cybercriminels à l'origine de la campagne, nous avons constaté des différences de code frappantes entre les différents échantillons des mêmes scripts, ce que nous ne pouvons qu'attribuer au fait qu'ils ont été développés par des personnes différentes.
La campagne de logiciels malveillants est conçue pour évoluer au fil du temps. Nous en voyons la preuve dans les nouvelles capacités et le renforcement du brouillage qui ont été ajoutés, ainsi que dans certaines redondances du code qui ont été créées pour servir de base à une utilisation future.
Améliorations et ajouts par rapport au système précédent
La compression UPX et l'en-tête UPX tronqué.
La fonction de mise à jour automatique a été déplacée de l'intérieur de la charge utile vers des scripts extérieurs (History et Update).
Les noms de fichiers plus discrets (Chrome, Opera , imitant des navigateurs).
Les signalements supplémentaires de logiciels malveillants sur Discord.
Le comportement spécifique lié à OpenWRT (et probablement d'autres à venir).
L'utilisation de proxies de pools miniers personnalisés au lieu de pools publics.
Archives du défenseur
Protection de votre périmètre et de votre réseau
La diffusion du logiciel malveillant ne fait appel à aucune technique novatrice ou sophistiquée. Le logiciel utilise simplement une attaque par dictionnaire sur SSH. Ainsi, seules les machines ouvertes à SSH depuis Internet sont menacées. Bloquer le SSH au niveau du périmètre du réseau, ou le déplacer derrière un VPN, peut réduire considérablement les risques que posent de telles attaques.
Par ailleurs, l'utilisation d'identifiants autres que ceux par défaut ou de mots de passe complexes réduit considérablement le risque d'une attaque par dictionnaire telle que celle employée par ce logiciel malveillant. Nous vous recommandons également d'utiliser des clés SSH pour l'authentification, celles-ci étant encore plus sûres que les mots de passe (elles ne peuvent pas être devinées et le « secret » n'est jamais transmis sur la connexion).
Enfin, il convient également de prendre en compte le module de diffusion LAN. Puisqu'il utilise également SSH pour le mouvement latéral, la segmentation de votre réseau peut atténuer ce risque en toute sécurité. Si nous considérons les serveurs ouverts à Internet comme une zone démilitarisée (DMZ), il est logique d'empêcher le trafic SSH (et en règle générale tout autre trafic pouvant être utilisé pour un mouvement latéral, comme RDP, MS-RPC ou WinRM) de passer de la DMZ au reste du réseau. Si, pour une raison quelconque, vous avez besoin qu'un de ces serveurs ait un accès SSH au réseau interne (parce qu'il sert de jumpbox, par exemple), il convient alors de le déplacer hors de la DMZ et de le placer sous le VPN. Veillez simplement à ne pas exposer les serveurs à Internet et à ne pas permettre aux pirates d'y accéder en interne pour réduire le rayon d'action et les voies de propagation.
Détection des attaques
Notre référentiel GitHub contient des outils pour vous aider à détecter les attaques issues de cette campagne malveillante. Vous y trouverez un script bash, une liste complète d'IOC et des requêtes osquery que les clients de Guardicore Segmentation d'Akamai peuvent utiliser. Vous retrouverez également le script de détection et une liste partielle d'IOC à la fin de cet article.
En plus de ces outils, nous aimerions également vous recommander une méthode générale de détection des mineurs de cryptomonnaies qui pourrait s'appliquer dans ce cas : la détection du trafic sortant vers les pools miniers en examinant le port de destination. Les ports par défaut des pools miniers sont parfois assez uniques, et il peut donc s'avérer utile de les surveiller. Par exemple :
Le port TCP 4242 est le port par défaut pour la mise en œuvre de ce pool
Les ports TCP 3333, 5555, 7777, 9000 sont les ports par défaut pour la mise en œuvre du pool nodejs
Bien entendu, les mineurs peuvent également communiquer avec leur pool via HTTP et HTTPS, auquel cas la détection serait beaucoup plus difficile. Néanmoins, cela vaut la peine de surveiller ces ports.
Script de détection
Le script de détection recherche différents IOC qui peuvent indiquer la présence passée ou actuelle de la campagne d'attaque. Il recherche des artefacts dans crontab, leurs chemins d'accès aux fichiers ainsi que les processus en cours d'exécution, et également la clé SSH malveillante de la porte dérobée. Pour l'exécuter, il suffit de le télécharger sur la machine que vous souhaitez vérifier et de l'exécuter. Il analysera la machine et publiera ses conclusions :
Figure 12 : Exécution du script de détection pour rechercher des artefacts Mexals.
Indicateurs d'infection
Il s'agit d'une liste partielle des IOC. La liste complète est disponible sur notre référentiel GitHub.
Chemins
/var/tmp/.update-logs/
/var/tmp/Documents/
/var/tmp/.ladyg0g0/
/dev/shm/.x/
/dev/shm/.magic/
Noms de fichiers
protocols
bios.txt
Update
History
aliases
payload
retea
.usrs
Adresses IP
107.182.129.219
45.139.105.222
185.225.74.231
212.193.30.11
Domaines et URI
arhivehaceru[.]com
discord[.]com/api/webhooks/954295081765072926/Zu7Vu-LpfgRqSmCyFvz3BCkR1Lt7clYOJeayCFzZwtPmZlVn9og_6mPS_BJY-374m5Y3
discord[.]com/api/webhooks/1036206037373571082/9bs01KrT-TrcbSAPI_i-adV1Bhn56A4X4fxzCYEw3zMq95H1mFvlKWb6-KYzvEoVfTnS
discord[.]com/api/webhooks/1036205058456563722/1_saZM0fE7nLgYG668LmDfNmSvrWpD-6Z8nIXljm0qlm6YyMxAyYuZIu4LhN2gHsgSQy
discord[.]com/api/webhooks/965651135102865479/PFdU4u8yZrn0XhzIKShcaxL3_IaBjsstYmFEXlThF2_1XCnwXSAjKos3ptwKYpPyGqvI
discord[.]com/api/webhooks/848592916951203860/WeWBGYSVreTlE0aO_6alVN3Qrj6_aRxnaDpq4_6wD04V2aHlMFvgik2Z2h78Dstg9fZY
discord[.]com/api/webhooks/1036225255049531422/qyOrT3SxHaOC-9yS2NQiPxlSMYmRFFIpU-rMKzmcDv9pQyP4uaZEiZXDXioUtf0DJLUB
