SuperTekBoy

While deploying an Exchange server, you may run into the following error during setup, which will block the installation from continuing.

[07/01/2020] ErrorRecord: Cannot find an overload for "CompareTo" and the argument count: "1".
[07/01/2020] ErrorRecord: System.Management.Automation.MethodException: Cannot find an overload for "CompareTo" and the argument count: "1".

This error is definitely cryptic. Thankfully the Exchange Setup Logs (located at “C:\ExchangeSetupLogs\ExchangeSetup.txt”) is excellent at providing more clues when troubleshooting.

In our case, the logs identified that setup was trying to process the Offline Address Book (“OAB”) at the time of the error. The error occurred during a function that contained OAB-related PowerShell commands, including Get-OfflineAddressBook, Get-OabVirtualDirectory, and Set-OfflineAddressBook. So, this was the logical place to continue troubleshooting.

From another Exchange Server, we ran the PowerShell command Get-OfflineAddressBook, and strangely, three address books were returned.

 C:\> Get-OfflineAddressBook | Format-List Name

Name: Default Offline Address List
Name: Default Offline Address List (Ex2013)
Name: Default Offline Address List (Ex2013)
      CNF:3e4b413a-e5d6-4371-8541-defecb812f98

The returned results were strange.

• Default Offline Address List is an OAB from a legacy Exchange installation (Exchange 2010 and earlier) and is common to see in an Exchange environment.
• Default Offline Address List (Ex2013) is present whenever an Exchange 2013 or 2016 server is installed into a legacy Exchange environment. This address list is standard, and it is common to see both this OAB and the first OAB coexisting in mixed Exchange environments.
• Default Offline Address List (Ex2013)CNF:<GUID>, is an address list I had never seen before.

Default Offline Address List (Ex2013)CNF:<GUID> being an unknown quickly became the focus of our investigation.

When introducing a new Exchange Server into your existing Exchange environment, the installer may throw the error “Database is mandatory on UserMailbox” and prevent you from continuing.

If you examine the Exchange Setup Logs (which can be found at “C:\ExchangeSetupLogs\ExchangeSetup.txt”) you may find a few more clues as to which mailboxes are missing their databases parameter.

Towards the end of our Exchange setup log, we found the following two error lines.

[07/01/2020] [1] [ERROR] Database is mandatory on UserMailbox.
[07/01/2020] [1] [ERROR-REFERENCE] Id=SystemAttendantDependent___04cc4eded45c32a6bf14ee3fe543df60 Component=EXCHANGE14:\Current\Release\PIM Storage\Discovery

The key here is “SystemAttendant.” The System Attendant is an arbitration mailbox. Let’s check on the health of all our arbitration mailboxes. We can do this by entering the following command into the Exchange Management Shell.

 C:\> Get-Mailbox -Arbitration | Select Name | Format-Table

Name
----
SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
SystemMailbox{1f05a927-7f83-496b-a118-a96cdde1cd3c}
WARNING: The object SKARO.LOCAL/Users/SystemMailbox{1f05a927-7f83-496b-a118-a96cdde1cd3c}
has been corrupted, and it's in an inconsistent state. The following validation errors happened:
WARNING: Database is mandatory on UserMailbox.
WARNING: Database is mandatory on UserMailbox.
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}
Migration.8f3e7716-2011-43e4-96b1-aba62d229136
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}

The output from this command identifies that we have a single broken system mailbox.

A homoglyph is when a glyph (or character) from one character set looks identical to that of another character set. For example, the lower-case letter “а” from the Cyrillic alphabet appears to be identical to the lower-case letter “a” from the Latin alphabet.

While seemingly identical to the human eye, they are very different for a computer. Pasting a string that contains each of these characters into a web browser will take you to very different places.

Homoglyphs are frequently used in URL impersonation attacks because their substitution is indistinguishable to the human eye.

Homoglyphs are also more effective than other forms of impersonation, such as replacing lowercase “m” with “rn,” which can look almost identical in some fonts—for example, arnazon.com versus amazon.com. Or impersonation that preys on common misspellings—for instance, micosoft.com

So just how identical can a homoglyph attack be? In the next section, we will explore an example.

Note: To keep everyone safe, we have used screenshots for all impersonated domains.

Creating a homoglyph

To create an impersonated domain, we are going to use the Homoglyph Attack Generator at irongeek.com. From this page, we first need to type in the domain we want to impersonate. I am going to use supertekboy.com.

The generator then allows us to swap out each letter with a letter from another character set. The first two rows are the Latin character set in upper and lower case. However, several other character sets, including Cyrillic, are included.

Using the generator, we can switch one or more letters with those from a different character set. Let’s change the Latin letter “e” for the Cyrillic letter “e” (Unicode 435). This gives us the output below. Can you tell the difference?

If you were to click that link or cut and paste the URL into a browser, you would be redirected to the following URL.

Were a bad actor to register this redirected domain, they could use it as a launchpad for any number of attacks, such as delivering a malicious payload, social engineering, or password capture. (I believe some domain registrars are blocking these types of domains).