Skip to content

Mathematik verstehen am Beispiel einer Defintion

Kürzlich ging eine Erschütterung durch die Welt der Kryptografie. Das Paper Quantum Algorithms for Lattice Problems versprach einen neuen Angriff gegen bestimmte Algorithmen. Diese heißen Learning-With-Errors (LWE) und bilden eine Grundlage für Algorithmen, die gegen Quantencomputer sicher sein sollen. Hier spielt eine Menge Mathematik mit hinein. Als Beispiel seht ihr eine halbe Seite aus dem Paper:

Seite 22 des Papers
Seite 22 des Papers

Das Thema klang hinreichend interessant und ich wollte mich ein wenig einlesen. Zum konkreten Paper muss man sagen, dass mittlerweile ein Fehler im Algorithmus gefunden wurde und die Autoren schreiben:

Now the claim of showing a polynomial time quantum algorithm for solving LWE with polynomial modulus-noise ratios does not hold.

Beim Lesen fiel mir wieder etwas auf, was mir schon früher auffiel. Es gibt Sätze, die kommen recht unschuldig daher und klingen leicht verständlich. Dennoch steckt soviel Theorie dahinter, dass es eine Weile dauern könnte, um diese zu durchdringen.

Gleich in der Einführung findet sich ein Beispiel: An n-dimensional lattice L is a discrete additive subgroup of ℝn. (Ein n-dimensionales Gitter L ist eine diskrete additive Untergruppe von ℝn.)

Welche Begriffe muss man verstehen oder interpretieren können, um die Definition zu verstehen?

  1. n-dimensional
  2. diskrete additive Untergruppe
  3. n

Das heißt, nahezu jedes Wort ist erklärungsbedürftig und mit Schulwissen kaum zu durchdringen. Wenn wir jetzt die Wikipedia konsultieren, kommen wir ein Stück weiter. Dort findet sich auch eine Definition des Gitters als diskrete Untergruppe eines euklidischen Raums sowie einige Beispiele. Wenn wir beide Definitionen vergleichen, steht in dem Paper zusätzlich das Wort additiv und anstatt euklidischer Raum wird von ℝn gesprochen. Aus der Wikipedia-Seite zum euklidischen Raum wird schnell klar, dass ℝn ein euklidischer Raum ist. Also sind beide Definitionen ähnlich. Das heißt, mit kleinen Einschränkungen können wir mit der Wikipedia-Definition weiterarbeiten.

Um den Satz nun zu verstehen, sollten wir uns dem zweiten Begriff, der diskreten additiven Untergruppe, zuwenden. Beim Aufdröseln ergeben sich neue Begriffe, die man entweder kennen oder lernen muss.

  • Untergruppe
    • Eine Untergruppe hat eine Verknüpfung (Addition, Multiplikation etc.) und bildet eine Gruppe.
      • Eine Gruppe ist eine Menge mit einer Verknüpfung (Addition, Multiplikation etc.). Bei der Verknüpfung ist es egal, wie man Klammern setzt (Assoziativgesetz), es gibt ein so genanntes neutrales Element und ein inverses Element. Wenn man ein neutrales Element verknüpft, ändert sich nichts, so wie bei einer Addition mit 0. Wenn man ein Element der Menge mit dessem inversen Element verknüpft, erhält man das neutrale Element (12-12=0 bei der Addition, -12 ist das inverse Element).
  • Additive Untergruppe
    • Das ist eine Untergruppe, wo die Verknüpfung Addition heißt.
  • Diskrete Untergruppe
    • Eigentlich geht es hier um diskrete Teilmengen eines Raumes mit der zusätzlichen Eigenschaft, dass diese Teilmenge eine Untergruppe bildet.
    • Eine Teilmenge ist, wie der Name schon sagt, ein Teil der Menge.
    • Diskret bedeutet nun, dass jedes Element der Menge eine Umgebung hat, dass kein weiteres Element der Teilmenge enthält. Das heißt, die einzelnen Elemente der Menge sind isolierte Punkte.
    • Die ganzen Zahlen …, -2, -1, 0, 1, 2, … sind als Teilmenge der reellen Zahlen eine solche Menge. Denn bei jeder Zahl gibt es nach links und rechts einen Abstand, wo sich keine andere Zahl drin findet. Bei den Brüchen (rationale Zahlen) ist das anders. Dort finden sich keine zwei Zahlen mit einem kleinen Abstand, dass keine andere rationale drin läge. Daher ist das keine diskrete Teilmenge.
  • n
    • n ist der n-dimensionale Raum der reellen Zahlen. Aus der Schule kennt man ℝ1 (Zahlenstrahl), ℝ2 (Zahlenebene) und ℝ3 (dreidimensionaler Raum).

Damit haben wir alle Bauteile zusammen, um den obigen Satz zu verstehen. Wobei ich zugeben, muss, dass ich oben einige Abkürzungen genommen habe und auf intuitives Verständnis gesetzt habe. Dennoch reicht das in der Mathematik oftmals nicht. Es ist sinnvoll, sich Beispiele auszudenken. Diese sollten sowohl den positiven Fall abdecken (erfüllt die Definition), aber auch den negativen Fall (erfüllt die Definition nicht). Das sorgt dann wirklich für ein Verständnis des Ganzen.

Das war es auch, was ich am Anfang meinte, als ich von dem kleinen unschuldig klingenden Satz schrieb. Um den zu verstehen, muss man entweder tief im irgendwann mal Erlernten graben oder neues lernen und es dauert eine längere Zeit, bis man ein Paper einmal durchgearbeitet hat. Noch viel länger dauert es, bis man es verstanden hat. :-)

Der obige Satz war der Einstieg in das Paper und nur die Einleitung. Später geht es um gaussche Funktionen und Fouriertransformationen. Das sind Konzepte über die es semesterlange Vorlesungen gibt. Das heißt, um das zu verstehen, kann man wirklich aus den Tiefen der Mathematik schöpfen. Ich wünsche euch viel Spaß bei der Lektüre. :-)

Mit dem Paper haben sich einige andere auseinandergesetzt. Hier findet ihr interessante Lektüre dazu:

Leitfaden für Mastodon

Vor etwa einem Jahr schrieb ich hier einen Beitrag zu Mastodon und der DSGVO. Darin beschrieb ich, was Betreiber:innen zur Einhaltung der DSGVO zu beachten haben. Daraufhin wurde ich von der Stiftung Datenschutz kontaktiert. Sie wollten gern einen Leitfaden zum Datenschutz bei Mastodon schreiben und fragten mich, ob ich gern daran mitarbeiten wolle. Natürlich wollte ich. wink

So entstand in einer Zusammenarbeit mit Rebecca Sieber und Malte Engeler der Leitfaden als PDF-Datei sowie weitere sehr hilfreiche Dokumente. Ich habe die Zusammenarbeit sehr genossen und insbesondere der wissenschaftliche Aufsatz von Rebecca Sieber bringt viele interessante Aspekte beim Betrieb des Dienstes ans Licht.

Wenn also jemand von euch Mastodon betreibt, kann ich euch die Lektüre der Dokumente bzw. die Umsetzung unserer Hinweise nur raten. Viele der Hinweise lassen sich auch auf andere Dienste im Fediverse übertragen. Das heißt, auch hier bieten die Dokumente einen Mehrwert. Wenn ihr Fragen, Hinweise oder Kommentare habt, freue ich mich sehr über einen Kommentar hier im Blog. Ihr könnt natürlich auch die Stiftung Datenschutz gern direkt kontaktieren.

Viel Spaß beim Lesen und Umsetzen. :-)

Continue reading "Leitfaden für Mastodon"

Mehr Informationen zum Podcast "Your are fucked"

Beim MDR wurde vor kurzem die Sendung “You are fucked” ausgestrahlt. Über sechs Sendungen stellte Marcel Roth den Sicherheitsvorfall im Landkreis Anhalt-Bitterfeld vor.

Bei dem Sicherheitsvorfall wurden Rechner des Landkreises mit einer Schadsoftware infiziert. Nach der Infektion erkundeten die Kriminellen das Netzwerk und als sie genug Daten bzw. Informationen gesammelt hatten, verschlüsselten sie die Rechner. Dies führte dazu, dass der Landkreis nicht mehr arbeitsfähig war und den Katastrophenfall ausrief.

In den Sendungen geht es um den Vorfall an sich, es wird eine zeitliche Beschreibung der Vorfälle präsentiert, die Auswirkungen werden diskutiert und Roth versucht auch, in einer Sendung auf die Hintermänner einzugehen. Insgesamt kann ich euch die sechs Folgen nur ans Herz legen. Es ist interessant aufbereitet und man erfährt viel über die Hintergründe.

Ein Nachteil des Formats ist, dass nur Audioinhalte zur Verfügung gestellt werden. Weiterführende Informationen, wie etwa die Shownotes bei Podcasts, vermisse ich. Gerade im Teil 5 “We know who you are” werden einige Experten interviewt und auf deren Dokumente verwiesen. Da hätte ich mir die Shownotes sehr gewünscht. So habe ich einige der Links gesammelt und will sie mit euch teilen. Die Links gehen teils zu Wikipedia-Seiten (deutsch, englisch), zum Teil verlinke ich auch Fahndungsaufrufe bei FBI oder BKA oder ich verwende andere Quellen, die mir sinnvoll erscheinen.

Ransomware-Gruppen

In der Sendung ging es viel um die Gruppen, die Schadsoftware in Form von Ransomware verbreiten, und deren Hintermänner. Der Ursprung lag bei Jewgeni Bogatschow. Er entwickelte die Zeus-Schadsoftware. Deren Sinn war es anfangs, Kontodaten abzugreifen und die Bankkonten leerzuräumen. Diese war so “erfolgreich”, dass er andere benötigte, um alles abzuwickeln. Die Gruppe nannte sich dann The Business Club. Später wurde die Zeus-Software so geändert, dass die mehr militärische Geheimnisse ausleitete. Eine wichtige Person beim Business Club war Maksim Jakubez (Fahndungsseite beim FBI).

Dieser arbeitete später u.a. mit Igor Turaschew (Fahndungsseite beim BKA und beim FBI) in der Gruppe Evil Corp (Beiträge bei Brian Krebs) zusammen. Aus dieser Gruppe entstand schließlich PayOrGrief, die den Angriff gegen den Landkreis durchführten.

Gegen einige der Beteiligten gibt es Haftbefehle, Anklagen und ähnliches:

Das sind ein paar Informationen zur Einführung. Die Genese der Gruppen und deren Schadsoftware ist ein eigenes Kapitel. Hier könnt ihr gern weiter suchen. Wenn ihr interessante Links findet, freue ich mich über Kommentare. Solltet ihr einen Einblick in das Leben einiger der Akteure haben wollen, schaut bei YouTube und anderen Seiten. Da findet sich einiges.

Experten in der Sendung

Brett Callow

Zuerst kam Brett Callow zu Wort. Er arbeitet bei Emsisoft und schrieb als einer der Ersten über die Gruppe PayOrGrief:

Jon DiMaggio

Titelseite des Berichts Nationstate Ransomware
Titelseite des Berichts Nationstate Ransomware

Jon DiMaggio arbeitet bei Analyst1 und ist der Autor des Berichts “Nationstate Ransomware”. In der Sendung wird recht häufig aus diesem Bericht zitiert und die Titelseite sehr ausführlich beschrieben. Im Bericht findet ihr sehr detaillierte Angaben zu den obigen Ransomware-Gruppen, wer mit dahintersteckt, welche Software die benutzt haben usw. Der ist sehr lesenswert.

Marco di Felice

Marco di Felice ist ein Forscher im Bereich der IT-Sicherheit und hat auf DataBreaches.net einiges veröffentlicht. Unter dem Titel »Claiming to be the “new generation,” threat actors declare, “No more discounts or long negotiations”« ist das Statement der Gruppe PayOrGrief zu finden, welches auch in der Sendung verlesen wurde:

Who are we? We are the new generation… No more Discounts, time of long-term negotiations with brainwashing and tons of proofs is finished. The game is over for companies who like long negotiations, pay or grief come to you. We have all leaked files… On our website What about GDPR? Everyone just talks about GDPR. Nobody obeys this law. Plenty of hacked companies that leaked files including id, confidential information, scans etc wasn’t sanctioned for leak. We could stay inside the companies for weeks. It is enough for downloading confidential information, mails, id and other We have analyzed many ransomware groups and we are not like they. Companies are spending a lot of money hiring company-negotiatiors. Where is the result? Nothing. They spend money and time while the documents are publishing. Who won? Company-negotiatiors/Insurance companies. Now we define the rules of the game, fuck discounts, fuck negotiations, fuck time wasting… Pay or Grief. This is our statement

Weitere Informationen:

Molfar

Die Firma Molfar bzw. deren CEO Artem Starosiek machen Analysen aufgrund offener Quellen (OSINT). Dabei stießen sie auf einen Hackathon der Gruppe Wagner. Dort tauchte jemand auf, der sehr viele Ähnlichkeiten zu Turaschew hat und vermutlich mit der identisch ist.

Ich hoffe, ihr fandet die Sammlung oben hilfreich. Wenn ihr mehr Hinweise oder Links habt, kommentiert gern.

security.txt

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. :-) Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag. ;-)

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

  • Reddit
  • Wikipedia
  • Zoom
  • Netflix
  • Stackoverflow
  • Apple
  • und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

DSGVO-Aufwand bei den Aufsichtsbehörden

Ende 2018 veröffentlichte die CNIL einige Statistiken zu deren Arbeitsaufwand durch die EU-Datenschutzgrundverordnung (DS-GVO). Ich fragte mich damals, wie das wohl bei den deutschen Aufsichtsbehörden so aussieht. Also fragte ich dort nach.

Ich schickte eine E-Mail an alle 16 Landesbehörden sowie an die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI). In der Mail bat ich um Auskunft, wie viele Datenschutzbeauftragte gemeldet wurden, wieviel Datenschutzpannen bisher gemeldet wurden und wieviel Anfragen insgesamt eingetroffen sind. Wie sahen die Antworten so aus?

Anfragen

Alle Behörden antworteten durch die Bank, dass es einen enormen Anstieg der Anfragen gegeben hat. In einigen Fällen schrieb man von einer Verdrei- bis Vervierfachung der Anfragen. Leider erhielt ich nicht von allen konkrete Zahlen. Legt man die Meldungen mit Zahlen zugrunde, so liegt die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen mit mehr als 10.000 Anfragen an der Spitze aller Bundesländer. Dies erscheint auch logisch, da das Bundesland entsprecht groß ist. Auf der anderen Seite sprach die Landesbeauftragte von Bremen von etwa 30 monatlichen Anfragen (ggü. durchschnittlich 18 vor dem Mai 2018). Sachsen als Flächenland meldete mir 776 Anfragen in den sechs Monaten von Mai bis November 2018 zurück. Das entspricht knapp 130 Anfragen pro Monat.

Beschwerden

Leider hatte ich in meiner E-Mail das Wort Anfragen verwendet. Bei der Beantwortung stellte sich heraus, dass zwischen einfachen Anfragen und Beschwerden unterschieden wird. So wurden beim TLfDI 284 Beschwerden angelegt und Hessen verzeichnete über 1200 Beschwerden.

Anzahl der gemeldeten Datenschutzbeauftragten

Mit der DS-GVO sind die Firmen verpflichtet, Datenschutzbeauftragte (DSB) an die Behörden zu melden. Hier interessierte mich, wieviel Meldungen bei den Behörden eingegangen sind. Das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) meldete bereits im August die Zahl von 10.000. Im benachbarten Baden-Württemberg waren es mit 23.000 mehr als doppelt so viele. Aber auch hier liegt Nordrhein-Westfalen mit 24.800 DSB an der Spitze.

Beim BfDI gingen mit 1270 die wenigsten Meldungen ein. Ich würde vermuten, dass auch da einige fehlgeleitete Meldungen darunter sind. Denn zumeist sollten die Meldungen im jeweiligen Bundesland abgegeben werden. Wie schon bei den Anfragen hat Bremen mit etwas mehr als 1500 die wenigsten Meldungen zu verzeichnen. Schaut man in die anderen Bundesländer so haben das Saarland (knapp 2100) und Sachsen-Anhalt (2100) recht wenige erhalten. Aber auch der Freistaat Thüringen liegt mit ca. 3550 Meldungen weit hinten.

Meldungen zu Datenpannen

Wenn es zu Problemen bei der Verarbeitung personenbezogener Daten kommt, so muss gegenüber den Behörden eine Meldung abgegeben werden. Das heißt, wenn Seiten gehackt, Daten unbefugt gelöscht werden oder es andere Probleme mit der IT-Sicherheit gibt und dabei Risiken für die Menschen entstehen, entsteht eine solche Pflicht. Hier hatte mich interessiert, wieviele Meldungen entstanden sind.

Mit Abstand die meisten Meldungen gingen beim BfDI ein. Dort wurden knapp 4700 Meldungen verzeichnet. Hier wäre eine Übersicht nach einzelnen Bundesländern interessant. Denn vermutlich stammen diese aus dem kompletten Bundesgebiet.

Das BayLDA kommt dann an Platz 2 und hat mit 2005 weniger als die Hälfte der Meldungen des BfDI. Die Anzahl der Meldungen auf Platz 3 (NRW) halbiert sich dann noch einmal (1032). Baden-Württemberg (> 700) und Hessen (640) werden auf die weiteren Plätze verwiesen.

Auf den hinteren Plätzen liegen wiederum Bremen (29), Sachsen-Anhalt (>50), Saarland und Thüringen (<70).

Neben den reinen Zahlen würde mich eine Statistik über die Inhalte der Datenpannen interessieren. Auch fände ich es schön, die Zahl im Verhältnis zu den Firmen im jeweiligen Bundesland auszuwerten.

Sonstiges

Bei den obigen Zahlen fehlen zwei Bundesländer. Der Landesbeauftragte für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern schrieb mir zurück, dass aufgrund des Arbeitsaufkommens eine Antwort nicht möglich sei. Vom Hamburgischen Beauftragten für Datenschutz und Informationsfreiheit erhielt ich bis zum heutigen Tag keine Rückmeldung.

 

Continue reading "DSGVO-Aufwand bei den Aufsichtsbehörden"

Wer ist hinter APT3?

Habt ihr schon mal von APT3 oder Gothic Panda oder Buckeye gehört? Oder sagen euch die Operationen Double Tap oder Clandestine Fox etwas?

Zugegeben sind die Aktionen aus dem Jahr 2014 und damit schon etwas älter. Die Gruppe, die als APT3, UPS, Gothic Panda, Buckeye etc., bekannt ist, ist schon weit älter. Das Unternehmen FireEye berichtete bereits im Jahr 2010 zum ersten Mal darüber.

Die Operation Double Tap bestand aus einer Phishing Mail, die Leute zu einer Mitgliedschaft in einem Playboysclub einlud. Wer dann auf den Link in der Mail klickte, gelangte auf eine Webseite, die einen Exploit ausnutzte. Dieser installierte letztlich eine Schadsoftware auf dem Rechner und diese kommunizierte mit einem Server. FireEye hat mehr Details zu der Operation. Die Operation Clandestine Fox war ähnlich interessant.

Nun fragen sich viele, wer eigentlich hinter der Gruppe steckt. Wenn man aktuelle Pressemitteilungen liest, so ergibt sich der Eindruck, dass es immer entweder russische oder chinesische Angreifer sind. Im Falle von APT3 gibt es noch ein paar mehr Hinweise:

  • Die Domainnamen müssen von einer Person registriert werden. Dabei wurde die E-Mail-Adresse mxmtmw@gmail.com angegeben. Ausgehend davon gelang es, eine Person mit dem Namen Wu Yingzhou zu ermitteln. Die Seite https://intrusiontruth.wordpress.com/2017/05/02/who-is-mr-wu/ hat alle Details dazu.

  • Auch bei einer zweiten Domain spielte eine andere E-Mail-Adresse eine wesentliche Rolle. Die Forscher konnten die Person Dong Hao ermitteln.

  • Beide Personen sind Eigentümer der Firma Boyusec. Diese Firma wiederum ist Auftragnehmer des Ministeriums für Staatssicherheit in China.

Das ist doch ein recht klarer Hinweis, dass Boyusec hinter APT3 steckt. Dies folgt einem Trend. Denn viele Dienste lagern die Aufgaben an Privatfirmen aus.

cronjob