Aufdeckung von HinataBot: Ein tiefer Einblick in eine Go-basierte Bedrohung

• Akamai-Forscher im Security Intelligence Response Team (SIRT) haben ein neues Go-basiertes, auf DDoS ausgerichtetes Botnet entdeckt. Der Malware-Entwickler scheint die Malware nach einer Figur aus der beliebten Anime-Serie Naruto benannt zu haben: Hinata. Wir nennen sie „HinataBot“. 

• HinataBot wurde in den ersten drei Monaten des Jahres 2023 verbreitet und wird von den Entwicklern/Betreibern aktiv aktualisiert. 

• Die Probe wurde in HTTP- und SSH-Honeypots entdeckt und nutzt alte Schwachstellen und schwache Anmeldedaten aus. 

• Zu den beobachteten Infektionsversuchen gehört die Ausnutzung des miniigd-SOAP-Service auf Realtek-SDK-Geräten (CVE-2014-8361), Huawei HG532-Routern (CVE-2017-17215) und verfügbar gemachten Hadoop YARN-Servern (CVE n. v.). 

• Durch eine Kombination aus Reverse Engineering der Malware und der Imitation des C2‑Servers (Command and Control) konnten wir genau untersuchen, wie die Malware funktioniert und was ihren Angriffstraffic einzigartig macht.

Die beobachteten Verbreitungsmethoden waren eine Mischung aus Infektionsskripten und vollständigen Payloads unter Verwendung zweier primärer Schwachstellen: ein Hadoop YARN RCE (Abbildung 1) und eine Schwachstelle im SOAP-Service „miniigd“ auf Realtek-SDK-Geräten (CVE-2014-8361; Abb. 2).

Diese Angriffe traten an mehreren Tagen zwischen dem 11. und 16. Januar 2023 auf. Die Angreifer nutzten mehrere Versionen von Infektionsskripten, die im Laufe der Zeit aktualisiert wurden. Die beiden primären Skripte hießen „wget.sh“ (Abbildung 3) und „tftp.sh“ (Abbildung 4) – die Namen spiegeln die entsprechenden Protokolle zum Abrufen der Payload wider.

Die HinataBot-Malware wurde in Form von Go-Binärdateien verbreitet, die in verschiedenen Architekturen und Betriebssystemen ausgeführt werden können. Dieser Trend, dass Malware-Entwickler spezielle Payloads für mehrere Plattformen entwickeln, hat in den letzten Jahren immer stärker zugenommen (Abbildung 6) – wahrscheinlich aufgrund der einfachen übergreifenden Kompilierung und weil das Internet of Things (IoT) sowie kleine Büros/Homeoffices weniger gängige CPU-Architekturen verwenden. Und diese Umgebungen sind für Angreifer äußerst attraktiv.

Indem wir die Verbreitungs-IP als Ausgangspunkt verwendet haben, konnten wir zwei weitere IPs identifizieren, die zuvor für die Verbreitung verwendet wurden. Als Proxy wurde jeweils die Ausgangs-IP verwendet. Eine weitere Analyse ergab, dass die Angreifer vor der Entwicklung ihrer eigenen Go-basierten Malware versucht hatten, eine generische Mirai-Variante zu verbreiten, die in UPX-Paketen verpackt war und einen weniger offensichtlichen Namen verwendete (Abbildung 7).

Darüber hinaus konnten wir eine weitere Schwachstelle identifizieren, die die Angreifer missbraucht haben, um frühere Versionen ihrer Infektionsskripte zu verbreiten (Abbildung 9). Diese Schwachstelle, CVE-2017-17215, wirkt sich auf HG532-Router von Huawei aus und ermöglicht die Remoteausführung von willkürlichem Code.

Wie bereits erwähnt, verbreiteten die Akteure hinter HinataBot ursprünglich Mirai-Binärdateien, eine bekannte Malware-Familie, die zu Anfang auf IoT-Geräte abzielte, Open-Source-basiert war und immer wieder von verschiedenen Akteuren und Gruppen übernommen (und dementsprechend auch weiterentwickelt) wurde. Mirai ist nun für zahlreiche Varianten und Botnets verantwortlich, die von verschiedenen Entwicklern, Akteuren und Gruppen erstellt wurden. 

Bei der Betrachtung älterer DNS-Datensätze können wir sehen, dass die zuletzt mit HinataBot verbundene IP-Adresse seit Februar 2023 für die Domain „hihi.mirailovers.pw“ aufgelöst wurde (Abbildung 10).

Wir haben zunächst versucht, die neueste Verbreitungs-IP zu erreichen, doch obwohl wir sie anpingen konnten, konnten wir die Probe nicht direkt vom Server herunterladen. Das kann darauf hinweisen, dass die Angreifer einen Schutzmechanismus implementiert haben oder dass sie die Proben nach der Verbreitung entfernen, wodurch es schwieriger wird, sie außerhalb eines direkten Angriffs abzurufen. Bei älteren Kampagnen derselben Akteure haben wir scheinbar randomisierte Namensmuster beobachtet (siehe Abbildung 9).

Glücklicherweise haben wir Zugang zu einer Probe erhalten, die unsere automatisierten Analysetools zum Zeitpunkt der ersten Infektion gespeichert hatten. Wir haben sowohl die MIPS32- als auch die x86-64-Version aus unserem Malware-Repository heruntergeladen und mit der statischen Analyse begonnen. Die Binärdateien wurden beide in Go geschrieben, doch sie waren relativ leicht zu bearbeiten, da sie nicht beschädigt, nicht gepackt und nicht reduziert waren (Abbildung 11). Die Versionen der Binärdateien aus den Tagen vor dieser Veröffentlichung wurden seither entfernt, wodurch das Reverse Engineering in Zukunft schwieriger wird.

Zunächst begannen wir mit der Analyse einer zweimonatigen HinataBot-Malware-Probe (Abbildung 12), doch später fanden wir eine neuere Probe (Abbildung 13), die am selben Tag veröffentlicht worden war, an dem wir die Malware in unseren Protokollen entdeckt hatten. Wir haben uns anschließend dazu entschieden, stattdessen die neuere Probe zu analysieren. 

Der Hauptunterschied zwischen den beiden Versionen besteht darin, dass die neuere Probe optimiert wurde und über mehr modulare Funktionalität verfügt. Darüber hinaus enthält die neuere Probe einige grundlegende Sicherheitsmaßnahmen, die in der Originalversion nicht vorhanden waren. Wir werden diese Unterschiede in einem späteren Abschnitt dieses Beitrags näher erläutern.

Bei unserer Analyse haben sich sofort mehrere Funktionen als interessant erwiesen. Drei verschiedene Angriffsfunktionen sind uns sofort ins Auge gesprungen: sym.main.startAttack, sym.main.http_flood und sym.main.udp_flood (Abbildung 14). Die Namen dieser Funktionen deuten darauf hin, dass die Malware zum Starten von DDoS-Angriffen gedacht ist.

Eine weitere Analyse der Malware gab Hinweise auf die C2‑Kommunikation, die ebenfalls darauf hindeutete, dass HinataBot Teil einer DDoS-orientierten Botnet-Kampagne war (Abbildung 15). 

Um zu verstehen, wie die HinataBot-Malware eine Verbindung zu ihrem C2‑Server herstellt, haben wir von der Zeichenfolge „Connection to CNC is OK!“ (Verbindung zu CNC ist okay!) aus rückwärts gearbeitet und mit der Suche nach Querverweisen auf die Zeichenfolge begonnen (Abbildung 16). Mit diesem Prozess konnten den Mechanismus abbilden, über den die Malware mit ihrem C2‑Server kommuniziert.

Im Assemblycode fanden wir auch Verweise auf eine API, die für Verbindungen verwendet wird („API_CONNECTION_ATTACK“), sowie zahlreiche mögliche Befehle, die an das infizierte Gerät ausgegeben werden können – und die wir alle unbedingt ausprobieren wollten (Abbildung 18).

Zu diesem Zeitpunkt waren wir zuversichtlich, dass die Probe, das uns vorlag, eine Verbindung zum Verbreitungs-/C2-Server aufbauen würde, um ihn zu benachrichtigen, dass der Bot ausgeführt wird und auf Befehle wartet. Doch der C2-Server war mittlerweile offline. 

Eine interessante Beobachtung ist, dass HinataBot auch einen eigenen Listening-Port an TCP/61420 öffnet (Abbildung 19). Da unser Hauptziel dieser Studie darin bestand, den von diesem Botnet erzeugten Angriffstraffic besser zu verstehen, haben wir nicht viel Zeit mit der Untersuchung dieser Funktion verbracht, da sie scheinbar nicht relevant war. 

Wir haben jedoch festgestellt, dass die Timing-Unterschiede dieses Listeners von einer erfolgreichen Verbindung mit dem C2 abhängen: In Fällen, in denen erfolgreich ein C2‑Server kontaktiert wurde, wird dieser Listener nach drei Minuten deaktiviert. In Fällen, in denen der C2‑Server nicht erreicht werden konnte, überwacht dieser Port weiterhin ohne offensichtliche Zeitbegrenzung. An diesem Port müssen weitere Untersuchungen durchgeführt werden, um vollständig zu verstehen, welche Funktionen er den Betreibern ermöglicht, z. B. ob es sich um eine Art Peer-to-Peer-Funktionalität oder möglicherweise um eine Aktualisierungs-, Kontroll- oder Wiederherstellungsfunktion handelt. Zum Zeitpunkt der Verfassung dieses Beitrags können wir keine definitive Antwort geben.

Wie bereits erwähnt, enthielt die neuere HinataBot-Probe einige grundlegende Sicherheitsmaßnahmen, die in früheren Versionen nicht vorhanden waren. Die erste Maßnahme war eine Passwortanforderung. Beim Ausführen der Probe ist das Erste, was ins Auge springt, eine nicht erfasste Ausnahme. Die daraus resultierende Fehlermeldung macht es ziemlich deutlich (Abbildung 20). 

Nach näherer Untersuchung der Fehlermeldung haben wir festgestellt, dass für die Probe ein zusätzliches Argument bei der Ausführung übergeben werden muss. Zwar kommen Sie mit jeder beliebigen Zeichenfolge, die Sie an dieses Argument übergeben, an der nicht erfassten Ausnahme vorbei, doch HinataBot wird ordnungsgemäß beendet. So wurde offensichtlich, dass wir zur Disassemblierung zurückkehren mussten, um zu sehen, wonach HinataBot in diesem Argument suchen könnte.

Wir haben die Malware-Probe durchsucht und schließlich die 17-stellige (0x005fe3d2) Zeichenfolge "HINATA_START_NICE" (0x005fe3d8) gefunden, die in einem sym.runtime.memequal-Aufruf (0x005fe3e0) verwendet werden, der fehlschlug und die Malware dazu veranlasste, zu einer ret-Anweisung überzugehen und die Ausführung zu beenden (Abbildung 21). Wir haben diese Zeichenfolge als Argument bei der Ausführung der Probe verwendet, was zu einem interessanteren Code führte.

Interessanterweise beginnt die Naruto-Anime-Figur namens Hinata als friedlicher und sanfter Charakter, bevor sie zu einer wilden Kämpferin wird, worauf die Malware-Autoren möglicherweise anspielen, wenn sie das Argument „HINATA_START_NICE“ verwenden, bevor die Malware mit ihrem C2-Server kommuniziert und sich an der Ausführung von Angriffen beteiligt.

Es ist erwähnenswert, dass diese Passwortanforderung in den älteren HinataBot-Malware-Proben vom Januar 2023 nicht vorhanden war. Daher enthielten die meisten der Infektionsskripte, auf die wir gestoßen sind, dieses Argument nicht. Nachdem wir diese Anforderung entdeckt hatten, konnten wir jedoch bei näherer Betrachtung die neueren Infektionsskripte aufspüren (Abbildung 22), die dieses Argument zum Zeitpunkt der Infektion an die Binärdateien weitergaben. Es wäre praktisch gewesen, das im Voraus zu wissen.

Unsere Analyse der HinataBot-Probe ergab eine große Anzahl sehr langer Klartext-Zeichenfolgen, die in der Binärdatei eingebettet sind. Go verwendet einen einzigartigen Ansatz beim Speichern von Zeichenfolgenliteralen, indem sie in einem zusammenhängenden Speicherblock platziert werden, der als „Zeichenfolgentabelle“ oder „Zeichenfolgenpool“ bezeichnet wird. 

Wenn also der Zeichenfolgenbefehl oder die Disassembler in einer Go-Bibliothek ausgeführt werden, wirkt die Ausgabe wie eine verwirrende Mischung aus Zeichen, was die Unterscheidung zwischen einzelnen Zeichenfolgen in der Tabelle erschwert (Abbildung 23).

Diese Technik unterscheidet sich von anderen Programmiersprachen, die in der Regel Null-terminierte Byte-Strings speichern. Ohne diese abschließenden Null-Bytes lesen Tools eine ermittelte Zeichenfolge so lange, bis sie auf ein Null-Byte stoßen. Das erschwert die einfache Analyse von Zeichenfolgen.  

Mit einem Blick auf die Querverweise von Codesegmenten auf die Adresssegmente der Zeichenfolgentabelle lässt sich erkennen, wo einzelne Zeichenfolgen in der größeren Tabelle beginnen. In der Regel können Sie auch feststellen, dass ihre Länge in ein Register geladen wird, bevor oder nachdem die Zeichenfolge geladen wird, oder als Teil eines Funktionsaufrufs, der das referenzierte Zeichenfolgensegment verwendet (Abbildung 24). Es ist etwas gewöhnungsbedürftig, aber wenn man die Konvention verinnerlicht hat, ist es ziemlich einfach.

Der Handshake bestand aus einer ersten Verbindung, gefolgt von einem Bot, der die Meldung „API_CONNECTION_BOT [Betriebssystem]/[Architektur] [Hostname]“ sendete. Der Bot erwartet dann eine Meldung API_CONNECTION_SIGNAL_OK vom C2-Server, der den Bot darauf vorbereiten sollte, auf eingehende Befehle zu warten (Abbildung 26). Nachdem der Handshake erledigt wurde, senden wir das Signal API_CONNECTION_ATTACK: zum Initiieren von Angriffen. 

Wir haben einen sehr einfachen C2-Server erstellt, um die Wartung dieser Verbindung zu automatisieren. Außerdem konnten wir so einen in einer Textdatei gespeicherten Befehl ändern und senden, ohne den Code ändern zu müssen, was sehr einfache und schnelle Tests ermöglichte (Abbildung 27). Das hat uns im Verlauf dieser Studie ziemlich viel Zeit erspart.

Die neueste Version dieser Malware verfügt über zwei primäre Angriffsmethoden: HTTP und UDP. Die ältere Version enthielt diese beiden Methoden sowie Angriffsmethoden, die ICMP- und TCP-Floods nutzten. Es ist unklar, warum diese Methoden entfernt wurden.

Um einen genaueren Blick auf den tatsächlichen Angriffstraffic zu erhalten, nutzten wir unseren eigens erstellten C2-Server, um die Verbindung aufrechtzuerhalten, während der Bot uns Heartbeat-Signale sendete. So konnten wir uns nur auf die Angriffsbefehle konzentrieren und mussten uns keine Gedanken über die Aufrechterhaltung einer Verbindung zum infizierten Gerät machen.

Nach umfangreichen Analysen und Tests waren wir schließlich in der Lage, die Struktur und die Felder zu bestimmen, die erforderlich sind, um Angriffe zu starten und Pakete bei der Übertragung abzufangen. Der Malware-Entwickler nutzt mehrere Go-Konventionen wie anonyme Funktionen, Goroutines, Channels, Workerpools und Waitgroups, was das Reverse Engineering ein wenig erschwerte. Nach einer Reihe von Tests hatten wir schließlich die Befehlsstruktur des Angriffs ermittelt (Abbildung 28).

Einmal vollständig abgebildet, ist die grundlegende Befehlsstruktur sehr einfach. Angriffsbefehle beginnen immer mit API_CONNECTION_ATTACK: gefolgt von drei erforderlichen Feldern: Angriffstyp ( ATTACK_TYPE), Ziel ( TARGET) und Angriffsdauer ( DURATION. Für den Typ udp_flood gibt es auch ein viertes Angriffsfeld: „UDP_OPTIONS“. Grund dafür, dass dieses Feld bei udp_flood-Angriffen erforderlich ist, ist die Art und Weise, wie die Befehlsprüfung erfolgt. Seltsamerweise muss es jedoch nicht gültig sein.

Angriffstyp 0: http_flood

Der Befehl http_flood verwendet anscheinend keine zusätzlichen Optionsparameter, wie der Angriff udp_flood es tut. Da der Bot auf der nativen Go-Bibliothek „ net.http “ basiert, kommt der Großteil der Konfiguration und des Optionsparsings für diesen Angriff direkt von der Go-Bibliothek selbst und wird über die TARGET-Anweisung gesteuert. 

Im Angriffsbefehl in Abbildung 29 starten wir einen http_flood-Angriff (Typ 0) auf 127.127.127.127 über TCP/31337, der 10 Sekunden dauern wird. Pfad, Port, GET-Parameter und Protokoll werden alle von dieser TARGET-Anweisung abgeleitet. Wenn kein Port angegeben wird, wird standardmäßig TCP/80 verwendet.

Wie bereits erwähnt, stützt sich diese Binärdatei auf die Go-eigene net.http -Bibliothek, um Angriffe durchzuführen. Der Bot erstellt über Goroutines einen Workerpool mit 512 Workern, und jeder Worker erstellt sein eigenes net.http.Request -Objekt. In Abbildung 30 sehen wir, wie dies innerhalb eines einzelnen Workers funktioniert.

Zunächst wurde ein neues Context -Objekt und eine neue RequestWithContext -Klasse erstellt. Dieses Context -Objekt wird mit HTTP-Headern gefüllt, die während des Angriffs von der RequestWithContext -Klasse verwendet werden. Einige dieser Header sind statisch, andere werden randomisiert. In Abbildung 30 sehen Sie die Aufrufe Rand Seed und Intn. Diese werden verwendet, um einen zufälligen User-Agent aus einer Liste von zehn statischen User-Agents auszuwählen, die in der Binärdatei hartcodiert sind. Im Folgenden erfahren Sie, auf welche Header wir achten müssen, während wir den Traffic analysieren, der während eines http_flood -Angriffs von der Malware kommt.

Sehen wir uns einige wichtige Aspekte der HTTP-Header an, die wir bei den simulierten Angriffsereignissen beobachtet haben. Es gibt hier mehrere ziemlich offensichtliche Werte für das Fingerprinting, sowohl in statischen als auch in randomisierten Feldern. Verteidiger sollten sich diesen Beispieltraffic ansehen. Doch da wir dem Entwickler nicht dabei helfen wollen, seine Angriffsmöglichkeiten zu verbessern, wollen wir nicht genau herausstellen, warum dieser Traffic für Verteidiger leicht zu erkennen und zu blockieren ist. Ohne den Malware-Entwicklern zu sehr zu helfen, können wir sagen, dass ein Großteil der Payload hinsichtlich Größe, Reihenfolge und Wert ziemlich statisch ist. Einige Felder sind randomisiert – dazu gehören User-Agent (aus einer Liste von zehn statischen User-Agents), Keep-Alive und Cookie-Header. Verteidiger sollten sich auch die Header Host und Referrer im Probentraffic in Abbildung 31 genauer ansehen. Wenn der Angriffsbefehl keinen Zielport in der Target-Anweisung angibt, wird er standardmäßig auf TCP/80 oder TCP/443 gesetzt und der Port ist in keinem der Header enthalten.

Dieser Angriffsbefehl sieht etwas anders aus als die http_flood -Variante, hauptsächlich aufgrund des UDP_OPTIONS -Wertes (1531337), der im finalen Parameter übergeben wird. Dieser Parameter steuert den Zielport, an den die UDP-Pakete gesendet werden. Der Wert besteht aus drei Teilen: Der erste Teil ist der Parametertyp (1), der zweite ist die Länge des Wertes (5) und der dritte ist der Wert selbst (31337). 

Dieser vierte Parameter scheint für das Parsing des Befehls erforderlich zu sein, aber der Wert kann verworfen werden. Und wenn hier kein Portwert angegeben wird, verwendet die Binärdatei standardmäßig UDP/80 als Zielport des Angriffs. Zunächst wurde angenommen, dass wir – da diese Daten auf diese Weise übergeben werden – zusätzliche Konfigurationsparameter für 1–9 finden würden. Doch es scheint, dass nur der Port-Parameter (1) Auswirkungen auf den Angriffstraffic hat, der den Bot verlässt.

Der Screenshot in Abbildung 34 zeigt die Einrichtung des udp_flood -Sockets. Der Bot verwendet die Go-Bibliothek net mit net.Dial , um das UDP-Socket zu erstellen. Anschließend werden 512 Worker erstellt, die den Socket gemeinsam nutzen, wobei jeder in einer Schleife ausgeführt wird, die Daten über den Socket überträgt, bis der Dauer-Timer einen Kill-Befehl über einen gemeinsam genutzten Kanal sendet. Die UDP-Pakete (Abbildung 35), die den Bot verlassen, sind sehr groß (65.549 Byte pro Paket insgesamt) und werden wahrscheinlich fragmentiert bei Opfern über das Internet ankommen. Diese Größe ist innerhalb der Binärdatei hartcodiert und kann bei Attacken nicht vom Angreifer gesteuert werden.

Die 65.507 Bytes im UDP-Datensegment sind allesamt Null-Bytes (Abbildung 36). Der IP-ID-Header wird während des Angriffs sequentiell erhöht. Und obwohl der Quellport flüchtig ist, bleibt er während der Dauer der Flood statisch. Dies ist aller Wahrscheinlichkeit nach eine Nebenwirkung davon, dass net.Dial den UDP-Socket über den gesamten Angreifer-Workerpool hinweg verwaltet. Eine weitere Beobachtung sind die fehlgeschlagenen Prüfsummen der UDP-Daten.

IPs

• 77.73.131,247
  

• 156.236.16,237
  

• 185.112.83,254
  

Ports

• 61420
  

• 4120
  

CVEs

• CVE-2017-17215
  

• CVE-2014-8361
  

Dateinamen

• tftp.sh
  

• wget.sh
  

• hinata-linux.amd64
  

• hinata-windows-arm5
  

• hinata-plan9-arm5
  

• hinata-openbsd-arm5
  

• hinata-netbsd-arm5
  

• hinata-linux-arm5
  

• hinata-freebsd-arm5
  

• hinata-windows-arm7
  

• hinata-windows-arm64.exe
  

• hinata-windows-arm6
  

• hinata-windows-arm
  

• hinata-windows-amd64.exe
  

• hinata-windows-386.exe
  

• hinata-solaris-amd64
  

• hinata-plan9-arm7
  

• hinata-plan9-arm6
  

• hinata-plan9-arm
  

• hinata-plan9-amd64
  

• hinata-plan9-386
  

• hinata-openbsd-mips64
  

• hinata-openbsd-arm7
  

• hinata-openbsd-arm64
  

• hinata-openbsd-arm6
  

• hinata-openbsd-arm
  

• hinata-openbsd-amd64
  

• hinata-openbsd-386
  

• hinata-netbsd-arm7
  

• hinata-netbsd-arm64
  

• hinata-netbsd-arm6
  

• hinata-netbsd-arm
  

• hinata-netbsd-amd64
  

• hinata-netbsd-386
  

• hinata-linux-s390x
  

• hinata-linux-riscv64
  

• hinata-linux-ppc64le
  

• hinata-linux-ppc64
  

• hinata-linux-mipsle
  

• hinata-linux-mips64le
  

• hinata-linux-mips64
  

• hinata-linux-mips
  

• hinata-linux-arm7
  

• hinata-linux-arm64
  

• hinata-linux-arm6
  

• hinata-linux-arm
  

• hinata-linux-amd64
  

• hinata-linux-386
  

• hinata-js-wasm
  

• hinata-illumos-amd64
  

• hinata-freebsd-arm7
  

• hinata-freebsd-arm64
  

• hinata-freebsd-arm6
  

• hinata-freebsd-arm
  

• hinata-freebsd-amd64
  

• hinata-freebsd-386
  

• hinata-dragonfly-amd64
  

• hinata-darwin-arm64
  

• hinata-darwin-amd64
  

• hinata-android-arm64
  

• hinata-aix-ppc64
  

Jüngste Hashes

• 01422e34b2114c68cdb6ce685cd2e5673bbe5652259a0c4b862d5de2824a9375
  

• 1b958fd718f1419700c53fed10807e873e8399c354877b0a3dfceac7a8581456
  

• 8a84dc2a9a06b1fae0dd16765509f88f6f54559c36d4353fd040d02d4563f703
  

• 4aba67fdd694219ff0dff07ebd444ed154edacc00c3a61f9b661eabe811a0446
  

• 71154ad6bd1a8a79fc674c793bb82b8e7d1371eca0f909c6e4a98ef8e7f5d1da
  

• c6a7e25290677cc7b9331343166b140f2c320764a815b241747e6913b1a386d9
  

• 92adfbe6aae06d7c99469aeb6551db8eee964b589f2b8774e29d987cfbd0e0d6
  

• 8eda08ce362c09b5f45772467f94d5370068c1798f78c5316f15647ac898c621
  

• ff7638c0c893c021c3a059a21a71600249881afd84dc0d751d99db1c8edd3cac
  

• a3fac6fea9201c3c3eaae47bd95e0be93e91298e48df75540958834f9e75ac4d
  

• 9875bb9dd6d159a3b327de80e151ef7f3831c0d6833ae781490d68e426b73680
  

• 6ec35ef48ffdf9a92aa8845c336b327c280e1f20d7130ba0856540aed3233bbc
  

• C0aa34dd8dbf654d5230d4ef1db61f9befc89a0ea16cb7757edbf8a8090c9146
  

• 5643bf01e113de246575a9ec39ea12a85f9babb6ac069132ad8d1a7bfa56ed1b
  

• 845134ee7335f07b23e081f024cad5cbfc9ef453d6e2adc7970d6543292e5bcc
  

• 995681f388f5e0a405c282ae9ce22dc41f2249f0f5208254e1eec6e302d7ad7d
  

• 07326cce5325eabbe1caa2b3f8a4ab78e7913b65703c0afc3bab808441c30688
  

• 61181b4b7b7040ce4ab9c489a2b857f5a7fe8407c422327fff798f3b55e0cbe3
  

• 75c050580725279a6592eecc2b02b6fa78f5469c2f08fb1d0e2fe616beb8bf0d
  

• E3427838132b6161f10e77d0beca1beac90c63a8ccc4aabd523041aec25aab67