[Office365] - Error logging into other accounts "a transport layer error occurred. Got a protocol error response:"

[rawum]

trafficstars

I am trying to use NotRuler to determine which of our mailboxes, if any, were compromised. I am our Office 365 administrator so I therefore have full access to all mailboxes in our tenant. I am able to run NotRuler with the - - self argument with no issues. When I attempt to run NotRuler on mailboxes other than my own, I get the error "a transport layer error occurred. Got a protocol error response:". No error response number is returned. I am running NotRule on a Windows 10 machine from an elevated command prompt. Please help as a security firm has confirmed that we were attacked by Ruler.

[staaldraad]

Hi! Thank you for the report.

I'll need to get setup on Office 365 again to try and debug. In the meantime, could you try the following two options:

not-ruler --rpc

and

not-ruler --debug

The first option will try switch to the older RPC transport, which might work. I have a feeling Office365 might be using cookie values for auth instead of only checking the MAPI data. The --debug might shed some light on that

I'll try get a test account setup asap to verify.

[rawum]

Thanks for your help staaldraad.

[staaldraad]

I've figured out where the issue is, now need to figure out a way around it without breaking things :)

[staaldraad]

This version will definitely try login to the second mailbox, however with my test accounts it is failing with RPC errors. Specifically this: https://www.codetwo.com/kb/mapi-e-logon-failed-0x80040111/ - which I don't think is the real issue but haven't been able to get around it. Please see if this works for you: notruler-win64.zip

[rawum]

Thanks staalraad. I tried the new package and it is giving a more descriptive error: "

ERROR: HH:MM:SS notruler.go:566 Looks like [email protected] failed: mapi: Invalid login. Admin privileges requested but user is not an admin".

Do I have the arguments in the correct place? The --username argument is the admin user correct?

Also - Do you think the Powershell script would help us detect Ruler canaries? Remember, we are 100% Office 365.

[staaldraad]

It is the same as what I'm running into. It seems like there is an issue in Office365 with the UseAdminPrivilege flag needed for this. The full error happening in the back-end is similar to this:

IMicrosoft.Exchange.Rpc.ServerUnavailableException: Connection must be re-established ---> Microsoft.Exchange.RpcClientAccess.ServerUnavailableException: Connection must be re-established ---> Microsoft.Exchange.RpcClientAccess.SessionDeadException: The 
primary owner logon has failed. Dropping a connection. ---> Microsoft.Exchange.Data.Storage.ConnectionFailedTransientException: Cannot open mailbox /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=202a71c9a32d412cbbc6c9
a593. ---> Microsoft.Mapi.MapiExceptionLogonFailed: MapiExceptionLogonFailed: Unable to open message store. (hr=0x80040111, ec=-2147221231)

I'm trying to find a way around this. In theory it should work exactly the same as on-premise, but it seems like there might be some context switching issues that get introduced in multi-tenant systems like Office365.

[rawum]

Do you think the Powershell script would help us detect Ruler canaries? Remember, we are 100% Office 365.

[staaldraad]

If you are using Federated Auth, then I believe you may be able to detect the login events.

From Office365 side, I'm not sure what the logging capabilities offer, I have not had a chance to dig into it in detail. If you can see how often a user logs into a mailbox, Ruler activity should cause a small spike in login activity - as it does a "connect" - "make change" - "disconnect". Where-as normal Outlook behaviour is to keep a session alive.

[staaldraad]

I have a feeling this might work; It does seem to be a permission issue so this makes sense: https://social.technet.microsoft.com/Forums/ie/en-US/6b0d9dbe-8aa4-4cc7-82ae-79cb3cb00f99/majority-of-mailboxes-fail-to-migrate-to-exchange-online-cutover-migration-from-exchange-2010?forum=onlineservicesmigrationandcoexistence

Basically need to give the user extended rights to "receive-as":

Add-ADPermission -Identity "Mailbox Database 0383061665" -User "iif.admin" -ExtendedRights Receive-As

[rawum]

Unfortunately in Office 365, I don't think we have access to the Mailbox Database. This is a big limitation. My company is 100% Office 365. No hybrid environment.

[rawum]

Hello staaldraad, please let me know if you can think of anything else for this issue. Thanks for your help.

[staaldraad]

Unfortunately I haven't had a chance to find a solution yet. It is on the stack :+1:

[rawum]

Thanks staaldraad.

[tanujain]

I am getting the same error. Is this fixed now? We are trying to use this tool at scale. please help with any suggestions.