greenwolf / spray Goto Github PK

Spray can now be used to spray cisco web vpn portals.

These are commonly enumerated on the following path:
/+CSCOE+/logon.html

The script uses

for u in $(cat $userslist); do 
    (echo -n "[*] user $u%$password " && rpcclient -U "$domain/$u%$password" -c "getusername;quit" $target) >> logs/spray-logs.txt
done

Without modifying IFS as so (this might be an improper fix though, as far as I'm concerned, the actual way to read lines in bash is with read, as in the password reading part of the script):

IFS=$'\n'
...
unset IFS

This translates into usernames with whitespace in them not being supported. the logs also use "cut -d ' ' ", that would also break with whitespace in the username

There's, unfortunately, no brew cask (official or unofficial) for rpcclient, nor is there an official package that can be installed. As such, the SMB portion of the script sadly will not work on a Mac.

If someone finds a version of rpcclient for Darwin or a workaround I'll gladly close this- I spent a few hours trying to find a copy that would work.

I'm attempting to spray an OWA instance I know should contain some hits, but after letting a spray job run overnight it had gone through a decent chunk of the password list and found nothing which I thought was odd since this was against a userlist of 600+. I noticed that the spray-logs.txt file had a very large number in front of each attempt, which didn't match up with what I'd expect the byte size of a failed attempt to be. I double checked the post request file to make sure I didn't mess something up, and noticed that the IP in the host header was missing some digits. At first I thought I must have screwed it up when I pasted that data in from Burp, but then I realized every line had some characters chopped off the end. I set up a new spray to replicate the issue and verified that once the tool starts running, it is editing the supplied post request file in a way that mangles the attack. I redacted the actual IP and domain I was testing against, but you can see below that the post request looks correct before I start, and when checked after the attack is running it is missing the last character of every line.

root@kali:~# cat owa-post-request.txt 
POST /owa/auth.owa HTTP/1.1
Host: 1.1.1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://1.1.1.1/owa/auth/logon.aspx?replaceCurrent=1&reason=2&url=https%3a%2f%2f1.1.1.1%2fowa
Content-Type: application/x-www-form-urlencoded
Content-Length: 155
Connection: close
Cookie: ClientId=LLDFBDMQA0OGJRADTIGW; PrivateComputer=true; PBack=0
Upgrade-Insecure-Requests: 1

destination=https%3A%2F%2F1.1.1.1%2Fowa&flags=4&forcedownlevel=0&username=§sprayuser§%40redacted.org&password=spraypassword&passwordText=&isUtf8=1
root@kali:~# spray -owa "https://1.1.1.1/owa/auth/logon.aspx?replaceCurrent=1&reason=2&url=https%3a%2f%2f1.1.1.1%2fowa" test-users.txt /opt/Spray/passwords-English.txt 2 35 owa-post-request.txt &
[1] 910149
root@kali:~# 
Spray 2.1 the Password Sprayer by Jacob Wilkin(Greenwolf)

11:38:35 Spraying with password: Users Username
11:38:36 Spraying with password: RedactedOrgName1
cat: logs/usernamestoremove.txt: No such file or directory
rm: cannot remove 'logs/usernamestoremove.txt': No such file or directory

root@kali:~# tail logs/spray-logs.txt 
56468 joe.shmoe%joe.shmoe
56468 example.person%example.person
56468 abraham.lincoln%abraham.lincoln
56468 singleword%singleword
56468 joe.shmoe%Unity1
56468 example.person%Unity1
56468 abraham.lincoln%Unity1
56468 singleword%Unity1
root@kali:~# cat owa-post-request.txt
POST /owa/auth.owa HTTP/1.
Host: 1.1.1.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.
Accept-Language: en-US,en;q=0.
Accept-Encoding: gzip, deflat
Referer: https://1.1.1.1/owa/auth/logon.aspx?replaceCurrent=1&reason=2&url=https%3a%2f%2f1.1.1.1%2fow
Content-Type: application/x-www-form-urlencode
Content-Length: 15
Connection: clos
Cookie: ClientId=LLDFBDMQA0OGJRADTIGW; PrivateComputer=true; PBack=
Upgrade-Insecure-Requests: 

destination=https%3A%2F%2F1.1.1.1%2Fowa&flags=4&forcedownlevel=0&username=§sprayuser§%40redacted.org&password=spraypassword&passwordText=&isUtf8=
root@kali:~# 

The RPC Client version present on Kali Linux changed the error message used in the text log processing from STDOUT to STDERR.

Found that adding (2&>1 Edit: this was wrong use 2>&1) after the file redirect would send the STDERR to STDOUT and properly log in the file like before.

Only tested in SMB mode on Kali Linux, but similar fixes might be applied to other areas where STDOUT is relied on.

For troubleshooting purposes, it would be very helpful to have the option of a verbose output. The user has no idea what is really going on under the hood when spraying, which can take place over days/weeks. Is it returning errors? Was the OWA post incorrectly formatted? Did I use the wrong URL? There doesn't seem to be any way to figure out this out with the current state of the tool.

Hi there,

I have a fresh Kali box and was trying to run Spray against a new lab AD environment. Even though I knew I had a good username and password list, Spray would never find a match on its login attempts. I went through the rpcclient commands manually and I think the issue is this:

getusername:quit should be getusername;quit

Once I made that change throughout the script, everything ran fine for me!

Thanks,
Brian