Wer nutzt Office 365 und wie?

Gerade in der Anfangszeit wurde gefragt: "Wer nutzt denn schon Office 365?". Das ist relativ einfach zu beantworten, wenn es um Firmen geht, die das "allgemeine" Office 365 Angebot nutzen. Mittlerweile habe ich hier eine ganze Menge von URLs und Checks zusammen getragen, mit denen Sie zu einer DNS-Domain, die vielleicht auch als UPN verwendet wird, etwas in Erfahrung bringen können. Über den Umfang einer Office 365 Nutzung können Sie über unterschiedliche Wege mehr in Erfahrung bringen.

Vorbemerkung zum Datenschutz

Ich habe einige Zeit überlegt, ob ich diese Details zur Ermittlung von Informationen über eine Office 365 Domain öffentlich machen soll. Da es sich aber um öffentlich zugängliche Daten handelt, die nicht durch einen "Einbruch" ermittelt werden, ist mir wichtiger, dass möglichst viele Menschen darum wissen.
Keine der Informationen erlaubt einen Rückschluss auf Personen sondern nur auf Domains, die so auch bei den NICs der Welt und per DNS-Abfragen öffentlich einsehbar sind, so dass es keine "personenbezogenen" Daten nach DSGVO sein dürften.

Was ich hier beschreibt ist letztlich das Ergebnis von Abfragen, die Office 365 Clients tagtäglich millionenfach anonym ausführen. Ich habe den Protokollen einfach etwas genauer auf die Finger geschaut. Jeder, der mit Fiddler, Charles und Co umgehen kann, wird in wenigen Minuten die gleichen Informationen erlangen und mit einem PowerShell-Script auch automatisiert abfragen können. Es ist also weder "geheim" noch "gehackt".

Sie können es einfach testen: Starten Sie einen Browser ihrer Wahl und gehen Sie auf https://portal.office365.com. Geben Sie hier nun nicht ihren Benutzernamen ein sondern eine beliebige "interessante" Domäne und einen ungültigen Benutzer wie z.B. invalidUser@microsoft.com, invalidUser@basf.com, invalidUser@parliament.uk, invalidUser@uclabor.de o.a. und klicken Sie auf "Weiter". Anhand dem nächsten Dialog können Sie z.B. erkennen, ob diese Domäne überhaupt registriert ist und wenn ja, welches Anmeldeverfahren (Cloud-Kennworte, ADFS-OnPrem, AzureADFS-Premium) genutzt wird. Diese "Analyse" kann Office 365 gar nicht verhindern. Ein möglicher Einbrecher kann sich ja auch ganz gefahrlosmal ihr Schloss ansehen. Ich war nur etwas überrascht, dass die APIs mehr Daten zurückliefern, als für die eigentliche Funktion erforderlich sind. Wenn ich mich mit einer Domäne anmelde, dann würde ein Check auf diese Domäne reichen. Die API müsste dann nicht die komplette Domainliste mitliefern.

Viel Spaß beim näheren Blick auf Office 365 Anmeldedienste, DNS-Einträge und der möglichen Rückschlüsse.

Wenn sie einen Tenant anlegen und ihre eigene Domain nicht addieren können, dann beachten Sie auch die Seite Viraler Tenant und PowerBI-Tenant

DNS Einträge

Wer einen Office 365 Tenant beantragt und eine eigene "Domain" addiert, muss den rechtmäßigen Besitz nachweisen. Um dann auch Dienste unter der Domain zu nutzen, sind weitere Einträge erforderlich. Das Office 365 Verwaltungsportal zeigt die erforderlichen Einträge schön grafisch an.

Es ist nicht zwingend erforderlich, dass eine Firma auch wirklich alle Einträge vornimmt. Wer von Office 365 z.B. kein Skype for Business nutzt, kann sich die Einträge sparen. Der MX-Record verweist nur dann auf Office 365,. wenn man auch den Spamfilter von Office 365 nutzt und nicht eine eigene Lösung bevorzugt. Bei Exchange im Hybrid-Mode verweist Autodiscover in der Regel auch auf die "On-Premises" Umgebung. Der TXT-Eintrag mit dem "MS=*" Inhalt muss eigentlich nur bei der Verifizierung vorhanden sind und könnte dann wieder entfernt werden. Die meisten Kunden lassen ihn aber dennoch drin.

Die gleichen Abfragen können Sie natürlich auch per NSLOOKUP oder PowerShell machen. Diese Daten lassen sich auch als relativ guter Indikator für Office 365 Kunden nutzen. Eine Firma kann eigentlich nicht verbergen, in welchem Maß sie Office 365 schon nutzt. Im Office 36 Portal bekommen Sie ja angezeigt, welche DNS-Einträge ein Administrator machen sollte:

Hinweis
Einige Domains haben auch eine "Wildcard"-Funktion aktiv, d.h. sie können jeden Namen mit *.<domain> abfragen und bekommen immer eine IP-Adresse als Antwort. So kann eine "lyncdiscover.firma.de"-Abfrage natürlich nur bedingt zuverlässig angesehen werden. Sicherheit bringt hier nur die aktive Abfrage der Ressource und qualitative Bewertung der Rückantwort.

Aber das sind nicht alle Einträge. Es gibt auch Einträge, die Microsoft unter der "onmicrosoft.com"-Domäne pflegt und auf den Tenant bezogen sind. Wenn Sie den Tenant-Namen "erraten", dann können Sie auf Verdacht auch das prüfen.

• Resolve-DnsName
  https://technet.microsoft.com/en-us/library/jj590781(v=wps.630).aspx

Resolve-DnsName -Type TXT uclabor.de | fl

Name    : uclabor.de
Type    : TXT
TTL     : 3600
Strings : {MS=ms43941090}

PS C:\> Resolve-DnsName -Type TX msoid.uclabor.de | fl

Name     : msoid.uclabor.de
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : clientconfig.microsoftonline-p.net

Name     : clientconfig.microsoftonline-p.net
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : clientconfig.microsoftonline-p.net.nsatc.net

Name     : clientconfig.microsoftonline-p.net.nsatc.net
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : aadg.windows.net.nsatc.net

PS C:\> Resolve-DnsName -Type MX uclabor.de | fl

Name         : uclabor.de
Type         : MX
TTL          : 3588
NameExchange : uclabor-de.mail.protection.outlook.com
Preference   : 0

PS C:\> (Resolve-DnsName -Type MX carius.mail.onmicrosoft.com)[0] | fl

Name         : carius.mail.onmicrosoft.com
Type         : MX
TTL          : 10
NameExchange : carius-mail-onmicrosoft-com.mail.protection.outlook.com
Preference   : 10

Resolve-DnsName -Type TXT uclabor.de | fl

Name    : uclabor.de
Type    : TXT
TTL     : 3600
Strings : { v=spf1 include:spf.protection.outlook.com -all}

Resolve-DnsName -Type TXT autodiscover.uclabor.de | fl

Name     : autodiscover.uclabor.de
Type     : CNAME
TTL      : 6
Section  : Answer
NameHost : autodiscover.outlook.com

Name     : autodiscover.outlook.com
Type     : CNAME
TTL      : 6
Section  : Answer
NameHost : autod.ha.office365.com

Name     : autod.ha.office365.com
Type     : CNAME
TTL      : 6
Section  : Answer
NameHost : autod.ms-acdc.office.com

PS C:\> Resolve-DnsName -Type TXT lyncdiscover.uclabor.de | fl

Name     : lyncdiscover.uclabor.de
Type     : CNAME
TTL      : 900
Section  : Answer
NameHost : webdir.online.lync.com

PS C:\> Resolve-DnsName -Type srv _sip._tls.uclabor.de | fl

Name       : _sip._tls.uclabor.de
Type       : SRV
TTL        : 3600
NameTarget : sipdir.online.lync.com
Priority   : 100
Weight     : 1
Port       : 443

PS C:\> Resolve-DnsName -Type srv _sipfederationtls._tcp.uclabor.de | fl

Name       : _sipfederationtls._tcp.uclabor.de
Type       : SRV
TTL        : 3600
NameTarget : sipfed.online.lync.com
Priority   : 100
Weight     : 1
Port       : 5061

PS C:\> Resolve-DnsName -Type a msxfaq.sharepoint.com | fl

Name     : msxfaq.sharepoint.com
Type     : CNAME
TTL      : 30
Section  : Answer
NameHost : prodnet185-282edgea0001.sharepointonline.com.akadns.net

Resolve-DnsName -Type any enterpriseregistration.uclabor.de | fl

Name     : enterpriseregistration.uclabor.de
Type     : CNAME
TTL      : 240
Section  : Answer
NameHost : enterpriseregistration.windows.net

Resolve-DnsName -Type any enterpriseenrollment.uclabor.de | fl

Name     : enterpriseenrollment.uclabor.de
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : enterpriseenrollment.manage.microsoft.com

Etwas "störend" ist natürlich, dass immer mehr Dienste den TXT-Records zur Bereitstellung von Informationen erwarten. Solange die TXT-Records noch einen Präfix wie "ms=" oder "spf=" haben, können diese noch einfach zugeordnet werden. Wenn dort aber nur BASE64-codierte Zertifikate oder Hashwerte landen, dann kann eine Auswertung nicht mehr sicher auf die Verwendung schließen.

• External Domain Name System records für Office 365
  https://support.office.com/en-us/article/External-Domain-Name-System-records-for-Office-365-c0531a6f-9e25-4f2d-ad0e-a70bfef09ac0
• What’s the purpose of the additional Office 365 CNAME record
  https://support.office.com/en-us/article/Whats-the-purpose-of-the-additional-Office-365-CNAME-record-19b67e2b-1b28-4432-8cca-394803fbdc87
  http://go.microsoft.com/fwlink/p/?LinkId=322005

OpenID-Information

Im Rahmen der Analysen bin ich auf eine höchst interessante URL gestoßen. Microsoft veröffentlicht unter einer URL auch die Anmeldedaten für eine bestimmte Domain. Sie können in jedem Browser ohne Authentifizierung einfach aufrufen.

https://login.microsoftonline.com/{tenant domain name}/.well-known/openid-configuration

Chrome zeugt die JSON-Datei an während der IE/EDGE einen Download startet. Hier am Beispiel von UCLABOR.DE:

Den gleichen Test können Sie natürlich für nicht existierende Domains machen.

Invoke-RestMethod https://login.microsoftonline.com/uclabor.de/.well-known/openid-configuration `
   | fl tenant_region_scope,cloud_instance_name

tenant_region_scope : NA
cloud_instance_name : microsoftonline.com

Invoke-RestMethod https://login.microsoftonline.com/carius.invalid/.well-known/openid-configuration
Invoke-RestMethod : {"error":"invalid_tenant","error_description":"AADSTS90002: Tenant carius.invalid not found. 
   This may happen if there are no active subscriptions for the tenant. 
  Check with your subscription administrator.\r\n
  Trace ID: 47c82edb-98f9-43df-896f-292d900a0000\r\n
  Correlation ID: 221a3f15-294b-404d-9dcf-527d1c713e44\r\n
  Timestamp: 2018-07-06 17:54:31Z",
   "error_codes":[90002],"timestamp":"2018-07-06 17:54:31Z",
  "trace_id":"47c82edb-98f9-43df-896f-292d900a0000",
  "correlation_id":"221a3f15-294b-404d-9dcf-527d1c713e44"} 

Die gleiche API nutzt wohl auch die Seite https://www.whatismytenantid.com. In der Antwort steht nämlich auch die GUID des Tenants zur Domain. Da Sie so aber auch die GUID des Tenant bekommen, könnten Sie auch ermitteln, ob zwei bekannte Domänen zum gleichen Tenant gehören. Ich habe aber noch keinen Weg gefunden, über die TenantID eine Liste der enthaltenen Domänen oder sogar eine Gesamtliste von Office 365 Tenants zu erhalten. Sie müssen also schon die Domäne wissen, nach der sie fragen.

• Microsoft identity platform UserInfo endpoint
  https://docs.microsoft.com/en-us/azure/active-directory/develop/userinfo
• TenantID zu einer Domain ermitteln
  https://www.whatismytenantid.com

Microsoft Graph

Auch über die GraphAPI können Sie als authentifizierter Benutzer weitere Details in Erfahrung bringen. Die meisten Funktionen sind z.B.: mit B2BConnect dazu gekommen.

• tenantInformation resource type
  https://learn.microsoft.com/en-us/graph/api/resources/tenantinformation?view=graph-rest-beta
• findTenantInformationByDomainName
  https://learn.microsoft.com/en-us/graph/api/tenantrelationship-findtenantinformationbydomainname?view=graph-rest-beta&tabs=http
• tenantRelationship: findTenantInformationByTenantId
  https://learn.microsoft.com/en-us/graph/api/tenantrelationship-findtenantinformationbytenantid?view=graph-rest-beta&tabs=http
• Find tenantId by domain name and vice versa by leveraging the Graph API
  https://www.michev.info/Blog/Post/3970/find-tenantid-by-domain-name-and-vice-versa-by-leveraging-the-graph-api

odc.officeapps.live.com

Bei der Analyse mit Fiddler bezüglich Autodiscover und Outlook 365 ist mir noch eine URL aufgefallen, die anscheinend anonym abgefragt werden kann

https://odc.officeapps.live.com/odc/v2.1/federationProvider?domain=<domain>

Allerdings liefert sie zumindest bei mir immer die gleichen URL zur LiveID-OAUTH-Servern, selbst wenn die Domain nur in Office 365 genutzt wird.

PS C:\> (Invoke-RestMethod https://odc.officeapps.live.com/odc/v2.1/federationProvider?domain=netatwork.de).endpoint

type  authentication_endpoint                           token_endpoint
----  -----------------------                           --------------
MSA   https://login.live.com/oauth20_authorize.srf      https://login.live.com/oauth20_token.srf
OrgId https://login.windows.net/common/oauth2/authorize https://login.windows.net/common/oauth2/token

Insofern ist das noch eine Sackgasse.

User-Realm-Check

Eine weitere Quelle ist eine Beschreibung von Microsoft selbst zur Übertragung von UPN-Domänen zwischen Tenants

• Responding to DSR requests for system-generated logs in Power Apps, Power Automate, and Common Data Service : Determining Tenant Type
  https://docs.microsoft.com/en-us/power-platform/admin/powerapps-gdpr-dsr-guide-systemlogs#determining-tenant-type

Hier wird beschrieben, wie ein einfacher HTTP-Request weitere Details zu einem Tenant liefert:

https://login.microsoftonline.com/common/userrealm/name@contoso.com?api-version=2.1

Diese URL können Sie natürlich auch für beliebige andere Domains verwenden. Der Anmeldenamen muss nicht mal gültig sein.

{"NameSpaceType":"Managed",
   "Login":"user@example.com",
   "DomainName":"example.com",
   "FederationBrandName":"Net at Work GmbH",
   "TenantBrandingInfo":[
   {"Locale":0,
     "BannerLogo":"https://aadcdn.msftauthimages.net/xxx/logintenantbranding/0/bannerlogo?ts=xxx",
     "Illustration":"https://aadcdn.msftauthimages.net/xxx-x/logintenantbranding/0/illustration?ts=xxx",
     "BoilerPlateText":"Bitte anmelden.",
     "UserIdLabel":"Vorname.Nachname@example.com",
     "KeepMeSignedInDisabled":false,
     "UseTransparentLightBox":false}
   ],
   "cloud_instance_name":"microsoftonline.com",
   "is_dsso_enabled":true
}

{"NameSpaceType":"Managed",
   "Login":"user@uclabor.de",
   "DomainName":"uclabor.de",
   "FederationBrandName":"test_test_msxfaq.onmicrosoft.com_test",
   "TenantBrandingInfo":null,
 "cloud_instance_name":"microsoftonline.com"
}

{"NameSpaceType":"Managed",
   "Login":"user@example.com",
   "DomainName":"example.com",
   "FederationBrandName":"example.com",
   "IsViral":true,
   "TenantBrandingInfo":null,
   "cloud_instance_name":"microsoftonline.com"
}

{"NameSpaceType":"Unknown",
   "Login":"user@invaliddomain.msxfaq.de",
   "cloud_instance_name":"microsoftonline.com"
}

Diese Abfrage kann man natürlich auch einfach per PowerShell ausführen.

• Responding to DSR requests for system-generated logs in Power Apps, Power Automate, and Microsoft Dataverse - Determining Tenant Type
  https://learn.microsoft.com/en-us/power-platform/admin/powerapps-gdpr-dsr-guide-systemlogs#determining-tenant-type
• USING POWERSHELL TO CHECK A USER’S TENANT LOGON SETTING IN OFFICE 365 (WITHOUT LOGGING IN)
  https://www.lieben.nu/liebensraum/2017/02/using-powershell-to-check-a-users-tenant-logon-setting-in-office-365/

Information aus der Anmeldung

Sie haben sich sicher schon einmal in einem Browser auf https://portal.office365.com oder https://manage.windowsazure.com oder anderen Seiten von Office 365 angemeldet. Haben Sie hier mal mit einem Benutzernamen variiert? ich habe da sehr unterschiedliche Reaktionen beobachtet, die einen direkten Rückschluss auf die Anmeldung erlauben.

Folgende Konstellationen sind möglich:

Sie können allein mit einem Browser diese Anmeldung "simulieren". Natürlich geht das auch per Browser, denn der Zugriff auf die eigentliche Anmeldeseite erfolgt ja über einen "Form Post", den Sie auch per PowerShell ausführen können. Beim ersten Zugriff auf einem Service werden sie ja auf die gemeinsame Anmeldeseite umgeleitet. Der Request sieht in etwas so aus:

https://login.microsoftonline.com/common/oauth2/authorize?
   client_id=xxx
   &response_mode=form_post
   &response_type=code+id_token
   &scope=openid+profile
   &state=OpenIdConnect.AuthenticationPropertiesxx-xxx-xxx
   &nonce=xxx.xxx
   &redirect_uri=https%3a%2f%2fwww.office.com%2f
   &ui_locales=de-DE
   &mkt=de-DE
   &client-request-id=xxx-xxx-xxx-xxx-xxx
   &msafed=0
   &sso_reload=true

Eine klassische OAUTH-Anmeldung, die im Browser dann eine Eingabe von Benutzername und Kennwort erwartet. Wenn Sie dann auf "Weiter" drücken, dann wird es interessant: ich habe mit Fiddler die Anmeldung mitgeschnitten und eine sehr interessante URL gefunden, wenn ich den Benutzernamen eingegeben und OK gedrückt habe:

Die Url "https://login.microsoftonline.com/common/GetCredentialType" habe ich mir in Fiddler dann mal genauer angeschaut

Ich habe dann mit PowerShell und Invoke-Restmethod experimentiert, welche Felder gesendet werden müssen und welche Antwort geliefert wird. Der erste Aufruf lieferte schon Daten:

Invoke-RestMethod `
   -Uri https://login.microsoftonline.com/common/GetCredentialType `
   -method POST `
   -ContentType "application/json; charset=UTF-8" `
   -Body '{"Username":"invalidUser@carius.de"}' Username       : invalidUser@carius.de
Display        : invalidUser@carius.de
IfExistsResult : 0
ThrottleStatus : 1
Credentials    : @{PrefCredential=1; HasPassword=True; RemoteNgcParams=; SasParams=}
EstsProperties : @{DesktopSsoEnabled=True; UserTenantBranding=; DomainType=3}
apiCanary      : AQABAAAAAADX8GCi6Js6SK82TsD2Pb7r90CiZ1qlB4KxeJQfxs61BYvAZFiAjN-ciOtpNF-VpULfZg7-ciN0V_2KdjakbYmQTva43p
                 F3K5BWnd3vTZdqJhHQthHNJWH28dp1ri01Su3PQmpY3m2R6TKKw8RLcLjO7hIpNEm1rFQsPHGs6HJteSqiL__PAP6yArOaAULL-8n6
                 ri4rRO4sK1mESeD4L4tcFEE3X7g0rb7y1SfqIUs-1yAA

Damit habe ich dann natürlich noch mal die Testserie mit den vier Anmeldetypen gemacht:

Locale                 : 0
BannerLogo             : https://secure.aadcdn.microsoftonline-p.com/
   <guid>/logintenantbranding/0/bannerlogo?ts=<nummer>
TileLogo               : https://secure.aadcdn.microsoftonline-p.com/
   <guid>/logintenantbranding/0/tilelogo?ts=<nummer>
Illustration           : https://secure.aadcdn.microsoftonline-p.com/
   <guid>/logintenantbranding/0/illustration?ts=<nummer>
BoilerPlateText        : Sie melden sich am Active Directory von FIRMA an.
KeepMeSignedInDisabled : False

Es ist also sehr einfach mit einem einzelnen Aufruf gegen diese URL zu prüfen, ob die Domäne mit Office 365 registriert ist und welches Anmeldeverfahren genutzt wird. Allerdings gibt es durchaus noch Lücken. So ist der "Domaintype =2  aktuell noch nicht aufgetreten.

Ich habe noch keine Quelle gefunden, die alle möglichen Konstellationen beschreibt. Insbesondere andere Cloud-Dienste (DECloud, 123Vianet, UKGOV, USMIL etc. könnten andere Werte liefern. Wenn Sie Domains mit anderen Rückgaben finden, bin ich um einen Hinweis dankbar und erweitere die Tabelle.

PTA URL https://autologon.microsoftazuread-sso.com

Während der Analysen zu HTTP Authentication habe ich noch einen Weg ermitteln könne, um den Status einer Domain und deren Anmeldefunktion genauer zu ermitteln. Wer für eine Domain die Funktion "Password HashSync" in Verbindung mit SingleSignOn nutzt, kann dies über folgende URL ermitteln:

https://autologon.microsoftazuread-sso.com/<upn-domain>/winauth/sso

In der URL muss die UPN-Domain eingetragen und dann einfach ein HTTP-GET ausgeführt werden. folgende drei Statuscode der HTTP-Antwort haben ich bislang ermitteln können:

• Gültige Domain für SSO und PTA .> 401 Authentication Required
  Dabei wird als "Authorization: Negotiate" geliefert.
• Nicht vorhandene Domain -> 400 Bad Request
• Domain mit ADFS -> "204 No Content"

Exchange Autodiscover und Federation

Normalweise ist ein Aufruf von "Autodiscover" nicht ohne Anmeldung möglich. Aber auf der Seite Autodiscover V2 habe ich beschrieben dass über diesen REST-Service eine gewisse Information über ein Postfach erhalten werden könnte. Wer einen Exchange Hybrid-Mode etabliert, wird in der Regel auch das eine Free/Busy-Federation eingerichtet. Dazu ist bis Exchange 2010 die Konfiguration des MFG Microsoft Federation Gateway erforderlich.

Mit Exchange 2013 oder höher ist das MFG nicht mehr erforderlich, da hier auch OAUTH genutzt wird. Wenn ein Tenant im Exchange Hybrid Mode ohne MFG agiert, dann liefert der Test keine Daten.

Die Einrichtung bedeutet nicht zwingend, dass es einen Exchange Hybrid Mode gibt, denn das Microsoft Federation Gateway kann auch genutzt werden, wenn zwei Exchange Organisationen On-Premises eine Federation miteinander einrichten. Allerdings ist es schon sehr wahrscheinlich für einen Office 365 Hybrid-Mode, wenn die Domain in Office 365 registriert ist. Auf einem Exchange "On-Premises"-Server können Sie dazu ganz einfach ausführen.

[PS] C:\>Get-FederationInformation uclabor.de


RunspaceId            : ceb7207b-c2c2-4458-9ae0-bf65f1171be9
TargetApplicationUri  : outlook.com
DomainNames           : {msxfaq.onmicrosoft.com, uclabor.de, msxfaq.mail.onmicrosoft.com}
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
TokenIssuerUris       : {urn:federation:MicrosoftOnline}
Identity              :
IsValid               : True
ObjectState           : Unchanged

Sie erhalten zu einer Domain sogar die Liste aller Domänen. Insofern ist dies eine sehr gute Quelle für weitere Analysen. Um aber zuerst einmal zu verstehen, was das Commandlet macht, musste ich mit Fiddler erst mal mitschneiden. und dazu den Exchange Server auch erst mal dazu bringen, über den Proxy zu gehen:

Set-ExchangeServer -InternetWebProxy http://localhost:8888
Get-FederationInformation uclabor.de 
Set-ExchangeServer -InternetWebProxy $null

Interessant fand ich schon, dass hier nur Autodiscover-Anfragen genutzt werden.

Nach einigen Versuchen habe ich einen einzelnen HTTP-POST-Request extrahiert, mit dem ich unter Nutzung einer bekannten Domain und einer eingerichteten Federation auch alle anderen Domänen ermitteln kann.

Früher war eine anonyme Abfrage möglich. Mittlerweile müssen sie sich mit einem beliebigen Office 365 Konto authentifizieren.
Anfang 2021 hat Microsoft die Bedingungen verschärft, dass man "Modern Authentication" nutzen muss oder eine X-Anchor-Mailbox als Header angibt.
Mit Fiddler sehen Sie ansonsten den Fehler "ms-diagnostics-public: 2.2.2.2 Please include an X-AnchorMailbox header or move to Modern Auth."

([xml](Invoke-WebRequest `
   -Method post `
   -Uri https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc `
   -ContentType "text/xml; charset=utf-8" `
   -Body '<?xml version="1.0" encoding="utf-8"?>
   <soap:Envelope xmlns:exm="http://schemas.microsoft.com/exchange/services/2006/messages"
                  xmlns:ext="http://schemas.microsoft.com/exchange/services/2006/types"
                  xmlns:a="http://www.w3.org/2005/08/addressing"
                  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Header>
      <a:Action soap:mustUnderstand="1">http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetFederationInformation</a:Action>
      <a:To soap:mustUnderstand="1">https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc</a:To>
      <a:ReplyTo>
         <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
      </a:ReplyTo>
   </soap:Header>
   <soap:Body>
      <GetFederationInformationRequestMessage xmlns="http://schemas.microsoft.com/exchange/2010/Autodiscover">
         <Request>
            <Domain>uclabor.de</Domain>
         </Request>
      </GetFederationInformationRequestMessage>
   </soap:Body>
</soap:Envelope>')).Envelope.Body.GetFederationInformationResponseMessage.Response.Domains.domain

msxfaq.onmicrosoft.com
uclabor.de
msxfaq.mail.onmicrosoft.com

Die Abfrage erfolgt komplett anonym und sie können damit auch andere Domänen abfragen. Ich habe mir natürlich überlegt, ob dies schon ein Risiko darstellen kann. Schließlich kann jeder mit dem Wissen um eine Domain durchaus eine vollständige Domänenliste von Office 365 Domains zum Tenant erhalten.

Interessant finde ich, dass ich auch die Domänenliste von Firmen erhalten, die gar keine Exchange Federation über das Microsoft Federation Gateway eingerichtet haben.

• Autodiscover V2
• MFG Microsoft Federation Gateway

• Create a TXT Record für Federation
  https://technet.microsoft.com/en-us/library/ee423548(v=exchg.141).aspx

• Get-FederationInformation
  https://docs.microsoft.com/en-us/powershell/module/exchange/federation-and-hybrid/get-federationinformation?view=exchange-ps

DMARC und DKIM

Jeder Exchange Online User kann seine Mails durch Office 365 per DKIM signieren lassen. Diese Funktion ist aber per Default nicht aktiv, da der Administrator dazu in der DNS-Domäne die Schlüsse veröffentlichen muss. Mit Office 365 sind es CNAME-Einträge zu den Microsoft Schlüsseln. Diese Einträge können Sie natürlich abfragen. In der Maildomain gibt es derer zwei, die auf die Office 365 Einträge verweisen. Hier meine Einträge der MSXFAQ.DE

selector1._domainkey.msxfaq.de  CNAME selector1-msxfaq-de._domainkey.<tenantname>.onmicrosoft.com
selector2._domainkey.msxfaq.de  CNAME selector2-msxfaq-de._domainkey.<tenantname>.onmicrosoft.com

Per NSLOOKUP oder PowerShell können Sie dies einfach prüfen:

PS C:\> Resolve-DnsName -Type CNAME selector1._domainkey.uclabor.de

Name                             Type   TTL   Section    NameHost
----                             ----   ---   -------    --------
selector1._domainkey.uclabor.de  CNAME  3553  Answer     selector1-uclabor-de._domainkey.msxfaq.onmicrosoft.com

Und entsprechend können Sie auch die Hostnamen der CNAME Adresse prüfen. Dies sind aber TXT-Records

PS C:\> Resolve-DnsName -Type TXT selector1-uclabor-de._domainkey.msxfaq.onmicrosoft.com

Name                                     Type   TTL   Section    Strings
----                                     ----   ---   -------    -------
selector1-uclabor-de._domainkey.msxfaq. TXT    3600  Answer     {v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb
onmicrosoft.com                                                  3DQEBAQUAA4GNADCBiQKBgQCklDvN/oSar
                                                                 kjPao5SHNxqYavUpW3jpAGP77dKDX+Lp6X
                                                                 TIZHN/QAkex6LTkjvKoWDzJNvQuuOJBtO3
                                                                 mZxofTmHlFJCcX8TK/zsTWqo6N1U2xKVon
                                                                 RU3OTAnvuzgK1qemgG0VPL3n6CxkqbpsLL
                                                                 TRLJ2n/w7TYUOcNCADhVK7ZBQIDAQAB;
                                                                 n=1024,1472531624,1}

Allerdings sind die TXT-Records nur vorhanden, wenn die Domain für DKIM im Exchange Admin-Center eingerichtet wurden. Jede Domain hat dabei einen eigenen Key. Über dieses Wissen können wir natürlich zum einen erkennen, ob es für eine Domain schon einen DKIM-Eintrag in der Cloud gibt, d.h. der Admin im Exchange Admin Center auf "Aktivieren" geklickt hat und über den CNAME, ob er den Eintrag auch in seiner eigenen DNS-Zone angelegt und damit scharf geschaltet hat. Office 365 prüft dies nämlich und wenn der CNAME nicht vorhanden ist, kann DKIM nicht aktiviert werden.

Das ist dann recht schnell auch im Skript umgesetzt.

• DKIM mit Office 365
• DMARC
• Mailingliste mit DMARC, DKIM, SPF, ARC
• SPF
• DKIM

Domain-Profilierungsskript Get-O365TenantInfo

Mit all der Vorarbeit gibt es schon einen schönen Blumenstraße von Tests, über die ich eine erste Aussage über die Office 365 Nutzung einer Domain erhalten kann.

In einer ersten Version reicht hier mir eine PowerShell-Lösung mit einfacher Bildschirmausgabe:

Ich kann natürlich per Pipeline auch eine Liste von Domains vorne einkippen und die Ausgabe mit Export-CSV in eine Datei schreiben lassen.

Das Skript ist noch kein öffentlicher Download. Es gibt noch zu viele "Sonderfälle" und Fehlersituationen, die noch nicht abgefangen werden. Ich programmiere hier ja nicht anhand einer bekannten vorgegebenen API sondern versuche Aufrufe nachzustellen, die ich per Tracing und Analyse glaube gefunden zu haben. Zudem prüfe ich Werte die MX, LyncDiscover, AuthEndpoint aktuell nur gegen die angefragte Domäne. Sinnvoll wären natürlich Tests gegen jede gefundene Domäne, da die Ergebnisse je Domains ja abweichend sein könnten.

Exemplarische Informationen

Ich habe einfach mal ein paar " bekannte" Firmen aber auch Behörden abgefragt und interessante Einblicke erhalten, wer denn alles schon Office 365 in welcher Tiefe nutzt.

msxfaq.onmicrosoft.com
uclabor.de
msxfaq.mail.onmicrosoft.com

msxfaq.onmicrosoft.com
msxfaq.com
msxfaq.mail.onmicrosoft.com

bmibundde.onmicrosoft.com
bmi.bund.de

StadtKoeln.onmicrosoft.com
stadt-koeln.de

basf.onmicrosoft.com
basf.com
basfad.basf.net
.. (total 77 Domains)

rwe.mail.onmicrosoft.com
service.rwe.com
rwenpower.com
npower-renewables.com
.. (total 109 Domains)

corp.webtv.net
microsoft.onmicrosoft.com
surface.com
bungie.com
navic.tv
middleeast.corp.microsoft.com
microsoft.com
.. (Total 254 Domains)

ibm.onmicrosoft.com
ibm.com
JP.ibm.com
cf.ibm.com
.. (total 266 Domains)

MicroFocusInternational.onmicrosoft.com
microfocus.com
suse.com
netiq.com
MicroFocusInternational.mail.onmicrosoft.com
attachmate.com
borland.com
attachmatewrq.com
wrq.com
cobolportal.com
liant.com
novell.com
gwava.com
gwava.eu

cdu365.onmicrosoft.com
cdu.de
365.cdu.de
ubg365.de
365.ubgnet.de
ubgnet.de

spdde.onmicrosoft.com
spd.de

gruenede.onmicrosoft.com
gruene.de

fdpde.onmicrosoft.com
fdp.de

afdde.onmicrosoft.com
afd.de

bmibundde.onmicrosoft.com
bmi.bund.de
"Viraler Tenant" ohne Admin. Siehe PowerBI-Tenant

hopuk.onmicrosoft.com
hopuk.mail.onmicrosoft.com
intranet.parliament.uk
parliament.uk
tmg.parliament.uk
email.parliament.uk
mail.tours.parliament.uk
mail.education.parliament.uk

modgovuk.onmicrosoft.com
mod.gov.uk
modgovuk.mail.onmicrosoft.com
mod.uk
ovs.mod.gov.uk

miele.onmicrosoft.com
miele.com.br
(Hat wohl nichts mit der deutschen Firma Miele zu tun)

allianzms.onmicrosoft.com
allianz.com
allianz.de

gws.onmicrosoft.com

datev.de
datevde1.onmicrosoft.com

Die Liste könnte noch endlos fortgesetzt werden.

Abfrage per Browser?

Interessant wäre natürlich auch eine Version als Webseite, bei der eine interessierte Person nur die UPN-Domain eingibt und ein passender Bericht generiert wird. Azure erlaubt es einem Entwickler bis zu 10 Webseiten kostenfrei zu hosten. Was liegt hier dann näher als diese Auswertungen über einen WebService bereit zu stellen anstatt per NSLOOKUP alle einzelnen Befehle abzusetzen?

Mittlerweile hat aadinternals eine passende Webseite aufgebaut, die eine Teilmenge liefert

OSINT: Tenant information
https://aadinternals.com/osint/

Ermittelt die Tenant-ID GUID anhand der Domain
https://www.whatismytenantid.com/

• Just looking: Azure Active Directory reconnaissance as an outsider
  https://aadinternals.com/post/just-looking/

Diese "Selbstauskunft" plane ich zu starten, wenn die Ergebnisse des PowerShell-Scripts ausreichend stabil sind. Eine Webseite wäre dann überall zu erreichen und da gibt es schon einige gesteigerte Anforderungen an DoS-Schutz, Throttling u.a.

• Host 10 ASP.NET websites für free with Azure
  http://azure.microsoft.com/en-us/develop/net/aspnet/
• Developing Windows Azure and Web Services Jump Start
  http://www.microsoftvirtualacademy.com/training-courses/developing-windows-azure-and-web-services-jump-start
• How to Create and Deploy a Cloud Service
  https://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/
• Create a REST service using ASP.NET Web API and SQL Database in Azure App Service
  https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-rest-service-aspnet-api-sql-database/

Weitere Links

• Viraler Tenant
• PowerBI-Tenant
• Office 365 Domain Umzug
• Get-Federationdomain
• MFG Microsoft Federation Gateway
• Autodiscover V2
• PS als DNSClient
• OSINT: Tenant information
  https://aadinternals.com/osint/
• Resolve-DnsName
  https://technet.microsoft.com/en-us/library/jj590781(v=wps.630).aspx
• DNS-Class
  https://msdn.microsoft.com/de-de/library/system.net.dns(v=vs.110).aspx
• Hey, Scripting Guy! How Do I Query and Retrieve DNS Information?
  http://blogs.technet.com/b/heyscriptingguy/archive/2009/02/26/how-do-i-query-and-retrieve-dns-information.aspx