Microsoft Cloud Access Tokens - Kontrolliere die Token, Kontrolliere die Cloud

Microsoft Cloud Access Tokens

Kontrolliere die Token, Kontrolliere die Cloud

Marius Elmiger
von Marius Elmiger
am 23. Mai 2024
Lesezeit: 22 Minuten

Keypoints

Warum es wichtig ist, Microsoft Cloud Access Tokens zu schützen

  • Access Tokens werden für die Authentifizierung verwendet
  • Sie werden von der Microsoft Identity Platform generiert und ausgegeben
  • Access Tokens sind Sicherheits-Token, die im JSON Web Tokens (JWTs)-Format kodiert sind
  • Diese können aus verschiedenen Quellen extrahiert werden
  • Access Tokens, insbesondere von privilegierten Benutzern, sollten geschützt werden
  • die aktuellen Optionen zum Schutz von Access Tokens sind begrenzt

Da immer mehr Unternehmen Cloud-Dienste für ihren täglichen Betrieb nutzen, ist es wichtig, die potenziellen Risiken eines Token-Diebstahls zu kennen. In der Welt der On-Premise-Systeme gibt es mehrschichtige Schutzmöglichkeiten für Tokens, aber es gibt immer noch Vorfälle, bei denen Tokens nicht ausreichend geschützt waren. In der Cloud ist das Risiko höher, da die Access Tokens oft nicht ausreichend geschützt sind und auf verschiedene Arten entwendet werden können. Einmal erlangt, können Angreifer schnell von Remote auf Unternehmensdaten zugreifen, was es wahrscheinlicher macht, dass ein Vorfall grosse Auswirkungen hat.

Obwohl Access Tokens bei verschiedenen Cloud-Plattformen, Lösungen oder Websites einen ähnlichen Zweck erfüllen, kann es Unterschiede in der Implementierung und der spezifischen Funktionalität geben. In diesem Artikel geht es in erster Linie darum, wie man die von der Microsoft Cloud ausgestellten Access Tokens auslesen kann. Abschliessend werden einige Möglichkeiten aufgezeigt, wie man den Diebstahl von Access Tokens erschweren kann.

Was ist ein Microsoft Cloud Access Token?

Ein Access Token ist ein Sicherheits-Token, das von einem Autorisierungsserver als Teil eines OAuth 2.0-Flows ausgegeben wird. Es enthält Informationen über den Nutzer und die Ressource, für die das Token bestimmt ist. Diese Informationen können verwendet werden, um auf Web-APIs und andere geschützte Ressourcen zuzugreifen. Ressourcen validieren Zugriffstoken, um einer Client-Anwendung Zugang zu gewähren.

Die Microsoft Identity Platform implementiert Sicherheits-Tokens als JSON Web Tokens (JWTs), die Claims enthalten. Da JWTs als Sicherheits-Token verwendet werden, wird diese Form der Authentifizierung manchmal auch als JWT-Authentifizierung bezeichnet. Ein Claim enthält Aussagen über eine Entität, z. B. eine Client-Anwendung oder einen Ressourcenbesitzer, gegenüber einer anderen Entität, z. B. einem Ressourcenserver. Ein Claim kann auch als JWT-Claim oder JSON-Web-Token-Claim bezeichnet werden. Zusätzlich stellt die kryptografische Signierung die Integrität und Authentizität des Tokens sicher. Das Token wird mit einem privaten Schlüssel digital signiert, und der Empfänger kann seine Authentizität mit dem entsprechenden öffentlichen Schlüssel überprüfen.

Das standardmässige Microsoft Cloud JWT-Token ist base64url-kodiert, kann also enkodiert werden. Die enkodierung erfolgt vorzugsweise offline, um das Risiko einer Kompromittierung zu vermeiden. Zum Beispiel, indem der Code von jwt.ms oder jwt.io heruntergalden und überprüft wird. Danach kann die HTML/JavaScript Lösung offline verwendet werden. Oder indem ein PowerShell-Skript wie das von Vasil Michev oder die Python-Lösung roadtx von DirkJan verwendet wird. Sobald das JWT enkodiert ist, kann es wie das folgende verkürzte Access Token Beispiel aussehen:

{
  "typ": "JWT",
  "nonce": "OwJxBtbDQCPbBNDAfLGfXVExE0pF8sLb36nC_MWvpDQ",
  "alg": "RS256"
}.{
  "aud": "https://graph.microsoft.com",
  "iss": "https://sts.windows.net/d2a16643-x/",
  "iat": 1715765602,
  "nbf": 1715765602,
  "exp": 1715770910,
  "amr": [
    "pwd",
    "mfa"
  ],
  "app_displayname": "My Profile",
  "appid": "8c59ead7-d703-4a27-9e55-c96a0054c8d2",
  "appidacr": "0",
  "ipaddr": "141.195.x.x",
  "name": "Rabban",
  "oid": "4c422389-x-x-x-x",
  "scp": "AuditLog.Read.All BitlockerKey.Read.All CrossTenantInformation.ReadBasic.All CrossTenantUserProfileSharing.ReadWrite.All Device.EnableDisableAccount.All Device.Read.All email Group.Read.All Group.ReadWrite.All GroupMember.Read.All MailboxSettings.ReadWrite openid Organization.Read.All Policy.Read.All profile RoleManagement.ReadWrite.Directory User.Invite.All User.Read.All User.ReadBasic.All User.ReadWrite",
  "signin_state": [
    "kmsi"
  ],
  "tid": "d2a16643-x-x-x-x",
  "upn": "rabban@x.onmicrosoft.com",
  "xms_cc": [
    "cp1"
  ],
}.[Signature]

Im obigen Beispiel enthält das Token mehrere Angaben. Die wichtigsten sind unten aufgelistet, um zum Beispiel den Eigentümer, die Zielgruppe, den Geltungsbereich, die xms_cc und das Ablaufdatum zu identifizieren.

Claim typeNotes
audIdentifiziert den vorgesehenen Empfänger des Tokens. Bei id_tokens ist die Zielgruppe die Anwendungs-ID der App, die der App im Azure-Portal zugewiesen wurde. Die App sollte diesen Wert validieren und das Token zurückweisen, wenn der Wert nicht übereinstimmt.
expDie Angabe “exp” (expiration time) gibt die Ablaufzeit an, nach der das JWT nicht mehr zur Verarbeitung akzeptiert werden darf. Es ist wichtig zu wissen, dass eine Ressource das Token auch vor dieser Zeit ablehnen kann – wenn zum Beispiel eine Änderung der Authentifizierung erforderlich ist oder ein Token-Widerruf festgestellt wurde.
amrGibt an, wie das Subjekt des Tokens authentifiziert wurde. Microsoft-Identitäten können sich auf verschiedene Arten authentifizieren, die für eine Anwendung relevant sein können. Der amr-Claim ist ein Array, das mehrere Elemente enthalten kann, z. B. [“mfa”, “rsa”, “pwd”] für eine Authentifizierung, die sowohl ein Kennwort als auch die Authenticator-App verwendet. Die Werte findet man im Abschnitt amr claim in der Dokumentation zu den Entra ID-Zugriffstokens.
appidDie Anwendungs-ID des Clients, der das Token verwendet. Die Anwendung kann für sich selbst oder im Namen eines Nutzers handeln. Die Anwendungs-ID steht in der Regel für ein Anwendungsobjekt, sie kann aber auch ein Service Principal Objekt in Entra ID darstellen.
ipaddrDie IP-Adresse, von der aus sich der Benutzer authentifiziert hat.
scpDie Menge der Bereiche, die von einer Anwendung offengelegt werden und für die die Client-Anwendung eine Genehmigung angefordert (und erhalten) hat. Die Anwendung sollte überprüfen, ob es sich um gültige Bereiche handelt, die von der Anwendung offengelegt werden, und die Autorisierungsentscheidungen auf der Grundlage des Wertes dieser Bereiche treffen. Nur für Benutzer-Tokens enthalten.
tidEine GUID, die den Entra ID Tenant repräsentiert, zu dem der Nutzer gehört. Bei Arbeits- und Schulkonten ist die GUID die unveränderliche Tenant ID der Organisation, zu der der Nutzer gehört. Für persönliche Konten lautet der Wert 9188040d-6c67-4c5b-b112-36a304b66dad. Der Profilbereich ist erforderlich, um diesen Claim zu erhalten.
upnDer Benutzername des Benutzers. Kann eine Telefonnummer, eine Email-Adresse oder ein unformatierter String sein. Sollte nur zu Anzeigezwecken und als Hinweis auf den Benutzernamen bei einer erneuten Authentifizierung verwendet werden.
xms_ccDer xms_cc-Claim mit dem Wert cp1 im Access Token ist der massgebliche Weg, um zu erkennen, dass eine Client-Anwendung in der Lage ist, einen Claim Challenge zu bearbeiten. Access Tokens mit diesem Claim können durch Continuous Access Evaluation (CAE) geschützt werden

Weitere Details zu den Token-Claims der Microsoft-Cloud sind dokumentiert unter der ID token claims reference.

Ein Microsoft Cloud Access Token ist auf eine Ressource beschränkt, in der Regel eine Stunde lang gültig und kann nicht widerrufen werden. Es gibt auch ein Continuous Access Evaluation (CAE) Access Token, das 24 Stunden lang gültig ist und widerrufen werden kann. Tools wie TokenTacticsV2 oder roadtx können verwendet werden, um ein CAE-Zugangs-Token aus einem gültigen Refresh-Token oder einem Cookie zu erstellen. Leider werden Refresh-Tokens in diesem Artikel nicht behandelt, da sie ein ganz eigenes Thema sind. Wenn du mehr über Refresh-Tokens erfahren möchtest, schau dir Dirk-Jan Mollema blogs an.

Wenn ein Access Token extrahiert werden kann, kann dieses in der Regel von jedem Gerät und von jedem Ort aus verwendet werden, solange dieses gültig ist. Deshalb ist es wichtig, Access Tokens vor allem von privilegierten Nutzern zu schützen. Wie man das macht, ist im Kapitel Access Token Schützen beschrieben.

Ich will eins

Es gibt viele Möglichkeiten, ein Microsoft Cloud Access Token zu erhalten. Hier sind einige Beispiele, die wir bei Security Assessments, Pentests oder Red Teaming verwenden.

Über den Browser

Der einfachste Weg für einen angemeldeten Nutzer, ein Access Token zu erhalten, ist das Öffnen der Browser-Entwicklertools und das browsen von Microsoft Cloud-Frontend URLs wie https://myapps.microsoft.com/, https://myaccount.microsoft.com/, https://portal.azure.com/ oder https://mysignins.microsoft.com/. Hier ist ein kurzer Überblick über die Zugriffstoken, die von bekannten API-Endpunkten extrahiert werden können, und ob sie für Tools wie RoadRecon oder AzureHound verwendet werden können.

URL Recipient (aud) Scopes RoadRecon AzureHound
https://mysignins.microsoft.comhttps://graph.microsoft.comemail openid profile AuditLog.Read.All CrossTenantInformation.ReadBasic.All Directory.Read.All Policy.Read.All User.Read UserAuthenticationMethod.ReadWrite UserAuthenticationMethod.ReadWrite.All .defaultNoYes
(Entra ID only)
https://mysignins.microsoft.com0000000c-0000-0000-c000-000000000000tenants.read .defaultNoNo
https://portal.azure.comhttps://graph.windows.netrestricted_user_impersonation .defaultYesNo
https://portal.azure.comhttps://management.core.windows.netrestricted_user_impersonation .defaultNoNo
https://entra.microsoft.comhttps://graph.windows.netrestricted_user_impersonation .defaultYesNo
https://entra.microsoft.comhttps://management.core.windows.netrestricted_user_impersonation .defaultNoNo
https://myaccount.microsoft.com/https://graph.microsoft.comemail openid profile AuditLog.Read.All BitlockerKey.Read.All CrossTenantInformation.ReadBasic.All CrossTenantUserProfileSharing.ReadWrite.All Device.EnableDisableAccount.All Device.Read.All Group.Read.All Group.ReadWrite.All GroupMember.Read.All MailboxSettings.ReadWrite Organization.Read.All Policy.Read.All RoleManagement.ReadWrite.Directory User.Invite.All User.Read.All User.ReadBasic.All User.ReadWriteNoYes
(Entra ID only)
https://myaccount.microsoft.comhttps://graph.microsoft.comemail openid profile AuditLog.Read.All BitlockerKey.Read.All CrossTenantInformation.ReadBasic.All CrossTenantUserProfileSharing.ReadWrite.All Device.EnableDisableAccount.All Device.Read.All Group.Read.All Group.ReadWrite.All GroupMember.Read.All MailboxSettings.ReadWrite Organization.Read.All Policy.Read.All RoleManagement.ReadWrite.Directory User.Invite.All User.Read.All User.ReadBasic.All User.ReadWrite .defaultNoYes
(Entra ID only)
https://myaccount.microsoft.comhttps://graph.microsoft.comopenid profile AuditLog.Read.All BitlockerKey.Read.All CrossTenantInformation.ReadBasic.All CrossTenantUserProfileSharing.ReadWrite.All Device.EnableDisableAccount.All Device.Read.All Group.Read.All Group.ReadWrite.All GroupMember.Read.All MailboxSettings.ReadWrite Organization.Read.All Policy.Read.All RoleManagement.ReadWrite.Directory User.Invite.All User.Read.All User.ReadBasic.All User.ReadWriteNoYes
(Entra ID only)
https://myaccount.microsoft.comhttps://graph.windows.netrestricted_user_impersonation .defaultYesNo
https://cosmos.azure.comhttps://management.azure.comuser_impersonation .defaultNoYes
(ARM only)
https://portal.office.comhttps://graph.microsoft.comemail openid profile Calendars.Read Contacts.Read Family.Read Files.ReadWrite.All InformationProtectionPolicy.Read Notes.Create People.Read Presence.Read.All Sites.Read.All Tasks.ReadWrite User.Read User.ReadBasic.All .defaultNoYes
(Entra ID only)
https://portal.office.comhttps://x.sharepoint.comFiles.ReadWrite.All Sites.FullControl.All User.Read.All .defaultNoNo
https://portal.office.comhttps://outlook.office365.comsearch/SubstrateSearch-Internal.ReadWrite search/.defaultNoNo

Access Tokens vom Browser

Eine andere Möglichkeit, ein Access Token zu erlangen, ist das Stehlen von Web-Session-Cookies. Das Cookie wird dann gegen ein Access Token ausgetauscht. Das Stehlen von Cookies aus einem Browser wird von Justin Bui in seinem Artikel Hands in the Cookie Jar: Dumping Cookies with Chromium’s Remote Debugger Port sehr gut beschrieben. Danach kann roadtx von Dirkjan verwendet werden, z.B. mit dem Befehl roadtx interactiveauth --estscookie 0.AYIAQ --tokens-stdout -r msgraph -c azps, um das Cookie gegen ein Access Token auszutauschen. Verwende zum Beispiel für Azurehound und RoadTools für -r: msgraph, https://graph.windows.net oder https://management.azure.com. Für -c sollte jede Family of Client IDs (FOCI) funktionieren.

Um zu verhindern oder zu erschweren, dass ein Angreifer die oben genannten Methoden als Benutzer mit geringen Rechten ausführt, können die Entwicklerwerkzeuge und das Remote-Debugging für die meisten Browser über Gruppenrichtlinien deaktiviert werden.

Aus Dateien oder Prozessen

Access Token können auch aus Dateien extrahiert werden. Zum Beispiel hat Sander Maas früh entdeckt, dass Outlook für Windows (ja, nur das neue) Refresh und auch Access Token unter %localappdata%\Microsoft\Olk\EBWebView\Default\Session Storage\00000x.log speichert. Ältere Versionen von Azure CLI und anderen Cmdlets haben Access Tokens im Klartext unter %USERPROFILE%\.azure gespeichert. Es ist immer noch ein guter Ordner zum Überprüfen, denn wer aktualisiert schon PowerShell Module?

Access Tokens in Dateien

Access Tokens können auch in Prozessen wie Outlook, Word, Teams, PowerShell usw. gefunden werden. Am einfachsten ist es, den Prozess über den Task Manager zu dumpen und im Dump mit sysinternals strings.exe und findstr /i eyJ0eX nach Zugriffstokens zu suchen. Token, die für https://graph.microsoft.com ausgestellt wurden, können normalerweise gefunden werden und sind für AzureHound verwendbar.

Weitere Informationen oder Tools zur Automatisierung der Suche und Extraktion von Access Tokens aus Prozessen:

Von APIs

Eine einfache Möglichkeit, ein Access Token zu erhalten, ist der OAuth 2.0 Device Authorization Grant Flow. Weitere Details dazu sind im Artikel mit dem Titel Hidden dangers of phishing attacks beschrieben. Heutzutage kann dieser Flow durch Conditional Access Policies blockiert werden.

Es gibt weitere OAuth 2.0 Grant Flows, über die ein Access Token erhalten werden kann. Zum Beispiel der password credentials grant flow oder andere, die unter Microsoft identity platform app types and authentication flows gut dokumentiert sind. Diese Flows können verwendet werden, wenn die Anmeldedaten bekannt sind oder missbraucht werden, z. B. durch den Einsatz einer Phishing-Anwendung. Eine gute Artikel ist der von Nyxgeeks Creating a Malicious Entra ID OAuth2 Application.

Von Cmdlets

Es gibt mehrere Azure- oder Entra-ID-bezogene Cmdlets. Mit einigen der Cmdlets kann das Access Token angezeigt/abgerufen werden, wenn eine Sitzung zwischengespeichert wurde oder nach einer erfolgreichen Anmeldung.

TypeModule Command RoadRecon AzureHound
PowerShellAz.AccountsGet-AzAccessToken Yes Yes
Azure CLIazaz account get-access-token —resource=https://graph.microsoft.com —query accessToken -o tsv Yes Yes

Das Cmdlet connect-mggraph verfügt derzeit nicht über eine integrierte Methode zur Anzeige des Access Tokens. Mit der Prozessdump-Methode kann jedoch das Zugriffstoken aus einem aktiven PowerShell-Prozess extrahiert werden, der das Cmdlet connect-mggraph verwendet hat.

Vom Microsoft Graph Explorer

Wenn eine zwischengespeicherte Sitzung zum Microsoft Graph Explorer geöffnet ist, kann ein Access Token über die GUI extrahiert werden. Das Access Token kann nicht für die Tools azurehound oder roadtools verwendet werden. Manchmal wird die Anwendung Microsoft Graph Explorer jedoch für alle Benutzer zugelassen und ist daher eine gute Möglichkeit, eine erste Enumeration vorzunehmen.

Access Token vom Microsoft Graph Explorer

Vom Abfangen des Webverkehrs

Tools, die den Webverkehr abfangen können, wie z.B. Proxies, Burp, Fiddler oder Zap, können zum Abfangen von Access Tokens verwendet werden.

Von Azure Cloud Ressourcen

Wenn ein Benutzer über ausreichenden Zugriff auf Ressourcen wie Azure Cloud Shell, Azure Cloud Shell-Images, RunAs-Konten für Azure Automation, DevOps-Pipelines oder eine virtuelle Maschine verfügt, die Managed Identities verwendet, ist es häufig möglich, Access Tokens zu extrahieren.

Access Token von Azure Cloud Shell

Weitere Informationen:

Access Token Schützen

Wenn ein Access Token gestohlen wird, kann es verwendet werden, um von jedem beliebigen Gerät aus auf Daten zuzugreifen oder diese zu manipulieren, und zwar unter Umgehung aller Conditional Access Regeln. Microsoft hat zwar Sicherheitsfunktionen wie CAE oder Token Protection implementiert, um den Diebstahl von Access Token zu verhindern, indem sichergestellt wird, dass ein Token nur von dem dafür vorgesehenen Gerät verwendet werden kann. Diese Funktionen unterstützen jedoch nicht alle 1st-Party-Cloud-Anwendungen, und Token Protection unterstützt derzeit nur Refresh-Tokens. Die einzige vielversprechende Funktion, die vor Access Token-Diebstahl schützen könnte, ist Global Secure Access. Wir haben die Preview Implementierung noch nicht getestet und können daher nicht sagen, ob sie hält, was sie verspricht.

Die oben genannten Methoden zum Extrahieren von Access Tokens, mit Ausnahme der Gerätecode-Authentifizierung, bösartigen OAuth 2.0-Anwendung sowie Azure Cloud Ressourcen, setzen voraus, dass sich ein Angreifer bereits auf dem Gerät befindet. Dazu sind jedoch nicht-lokale Administratorrechte erforderlich. Der Schutz des Endgerätes und insbesondere der privilegierten Benutzer ist daher von entscheidender Bedeutung. Aber hey, es gibt einen einfachen Trick für privilegierte Benutzer (z. B. Tier-0), fast kostenlos, ein bisschen nervig und nicht sehr schick, er heisst Privileged Access Workstation. Wenn dieser angewendet wird, ist es die stärkste Verteidigung gegen Token-Diebstahl und löst das Problem am Anfang, nämlich wo die Tastatur sitzt.

Im Allgemeinen und für nicht privilegierte Benutzer ist es ein guter Anfang, den Diebstahl von Access Tokens zu erschweren, indem man den Zugriff nur von vertrauenswürdigen und gesicherten Endpunkten aus zulässt, die empfohlenen Tenant-Sicherheitsempfehlungen umsetzt, Anmeldedaten sicher behandelt und eine phishing-resistente Multifaktor-Authentifizierung (MFA) verwendet.

Weitere Informationen zu Schutzmassnahmen:

Fazit

Wie wir gelernt haben, gibt es mehrere Möglichkeiten, Access Tokens zu erlangen. Gelingt es einem Angreifer, ein Token zu erhalten, kann es eine Stunde oder 24 Stunden lang gültig sein. Genug Zeit, um Daten zu exfiltrieren oder eine Hintertür für die Persistenz zu installieren, wobei letzteres von den Berechtigungen des Benutzers abhängt.

Es gibt derzeit keine einfache Möglichkeit, die unbefugte Verwendung von Access Tokens zu verhindern, ausser es einem Angreifer schwer zu machen, in die Nähe eines Benutzers mit einem privilegierten Access Token zu gelangen. Dies beginnt oft mit der Methode, eine sichere Strategie für den privilegierten Zugriff zu implementieren. Richtig gemacht, würde dies einem Angreifer den unbefugten Zugriff erschweren. Bei unseren Sicherheitsüberprüfungen kommt es jedoch nicht selten vor, dass privilegierte oder unternehmenskritische Benutzer private Telefone oder sogar Heimcomputer für den Zugriff auf den Tenant des Unternehmens verwenden. Ähnliche Fehler wurden in der Vergangenheit mit Active Directory gemacht, als jeder ein Domänenadministrator war und es keine Sicherheitshärtung und keinen Token-Schutz gab. Zumindest gab es die Festungsmethode der Firewalls, die die Umgebung vor dem Internet schützten. Aber mit der Cloud funktioniert diese Methode nicht mehr.

Wir haben ein anderes Bedrohungsmodell, wenn wir mit einer Cloud-Umgebung arbeiten: Die Priorität liegt am Endpunkt, wo dem Benutzer der Zugriff auf die Cloud entweder erlaubt oder verwehrt wird. Folglich sind die Erlaubnis des Zugriffs nur von vertrauenswürdigen und gehärteten Endpunkten, die Umsetzung der empfohlenen Tenant-Sicherheitsempfehlungen, die Anwendung sicherer Praktiken für den privilegierten Zugriff, die sichere Handhabung von Anmeldeinformationen, die Verwendung einer Phishing-resistenten Multi-Faktor-Authentifizierung (MFA) und die Denkweise von Angreifern, um nur einige zu nennen, die Eckpfeiler des Schutzes von Cloud-Ressourcen und der für den Zugriff erforderlichen Access Tokens.

Über den Autor

Marius Elmiger

Marius Elmiger hat seit den frühen 2000er Jahren Erfahrung in verschiedenen Rollen als Administrator, Engineer, Architekt und Consultant gesammelt. Sein Fokus lag hauptsächlich in der Implementierung von komplexen IT-Infrastruktur Projekten, Umsetzung von Sicherheitskonzepten und Compromise Recoveries. Später wechselte er zur offensiven Seite, um sein Wissen weiter auszubauen. Als Grundlage neben zahlreichen Zertifikaten absolvierte Marius ein MSc in Advanced Security & Digital Forensics an der Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Fremde Workloadidentitäten

Fremde Workloadidentitäten

Marius Elmiger

Credential Tiering

Credential Tiering

Marius Elmiger

Credential Tiering

Credential Tiering

Marius Elmiger

Hardware-Keylogger

Hardware-Keylogger

Marius Elmiger

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv