Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites

April 15, 2017 – 7:05 PM

There is a phishing attack that is receiving much attention today in the security community.

As a reminder: A phishing attack is when an attacker sends you an email that contains a link to a malicious website. You click on the link because it appears to be trusted. Merely visiting the website may infect your computer or you may be tricked into signing into the malicious site with credentials from a site you trust. The attacker then has access to your username, password and any other sensitive information they can trick you into providing.

This variant of a phishing attack uses unicode to register domains that look identical to real domains. These fake domains can be used in phishing attacks to fool users into signing into a fake website, thereby handing over their login credentials to an attacker.

This affects the current version of Chrome browser, which is version 57.0.2987 and the current version of Firefox, which is version 52.0.2. This does not affect Internet Explorer or Safari browsers.

We created our own example to demonstrate how an attacker can register their own domain that looks identical to another company’s domain in the browser. We decided to imitate a healthcare site called ‘’ by registering our own fake site. You can visit our demo site here in Chrome or Firefox. For comparison you can click here to visit the real


Most of the Shadow Brokers exploits are already patched

April 15, 2017 – 10:53 AM

This is getting a ton of press lately, but here is Microsoft’s response to the latest leaks:

Today, Microsoft triaged a large release of exploits made publicly available by Shadow Brokers. Understandingly, customers have expressed concerns around the risk this disclosure potentially creates. Our engineers have investigated the disclosed exploits, and most of the exploits are already patched. Below is our update on the investigation.

When a potential vulnerability is reported to Microsoft, either from an internal or external source, the Microsoft Security Response Center (MSRC) kicks off an immediate and thorough investigation. We work to swiftly validate the claim and make sure legitimate, unresolved vulnerabilities that put customers at risk are fixed. Once validated, engineering teams prioritize fixing the reported issue as soon as possible, taking into consideration the time to fix it across any impacted product or service, as well as versions, the potential threat to customers, and the likelihood of exploitation.

Most of the exploits that were disclosed fall into vulnerabilities that are already patched in our supported products. Below is a list of exploits that are confirmed as already addressed by an update. We encourage customers to ensure their computers are up-to-date.


Booby-trapped Word documents in the wild exploit critical Microsoft 0day

April 8, 2017 – 5:03 PM

There’s a new zeroday attack in the wild that’s surreptitiously installing malware on fully-patched computers. It does so by exploiting a vulnerability in most or all versions of Microsoft Word.

The attack starts with an e-mail that attaches a malicious Word document, according to a blog post published Saturday by researchers from security firm FireEye. Once opened, exploit code concealed inside the document connects to an attacker-controlled server. It downloads a malicious HTML application file that’s disguised to look like a document created in Microsoft’s Rich Text Format. Behind the scenes, the .hta file downloads additional payloads from “different well-known malware families.”

The attack is notable for several reasons. First, it bypasses most exploit mitigations: This capability allows it to work even against Windows 10, which security experts widely agree is Microsoft’s most secure operating system to date. Second, unlike the vast majority of the Word exploits seen in the wild over the past few years, this new attack doesn’t require targets to enable macros. Last, before terminating, the exploit opens a decoy Word document in an attempt to hide any sign of the attack that just happened.

The zeroday attacks were first reported Friday evening by researchers from security firm McAfee.


Fake Font Update on Google Chrome Uses Social Engineering to Infect Users with Ransomware

February 24, 2017 – 8:57 PM

We’ve seen social engineering attacks manipulate users time and time again. From phishing emails, to baiting attempts – this breed of cyberthreat has continued to manipulate users for years. And now a new scam has emerged that utilizes a fake update on Google Chrome to trick users into downloading and infecting themselves with the infamous Spora ransomware.

The trick is simple. First, the attackers insert JavaScript into poorly secured, but legitimate websites to modify the text rendering on them. Then, when victims visit these sites, the script makes the website indecipherable and prompts them to fix the issue by updating their “Chrome font pack.” Essentially, a window pops up, showing, “The ‘HoeflerText’ font wasn’t found,” and users are asked to update the Chrome Font Pack. And if they click, they’re immediately infected with the highly-effective Spora ransomware, instead of an update for their browser.

So why is this attack seeing such easy success? Believe it not, Hoefler Text is, in fact, a real font, adding a sense of legitimacy behind the scam. However, the malware has primarily seen so much success due to its ability to fly under the radar, as it does not get flagged as an infection by a variety of security programs.

What’s worse is that this isn’t the first time this has happened – delivery of malware through the EITest redirect gates has been around since at least 2014. Additionally, the infected sites and samples change all the time and simply blocking URLs, domains, and IP’s at the perimeter would just be playing “whack-a-mole.”

In fact, EITest gates are typically used in combination with the RIG, Angler, and Sundown EK’s to redirect victims to quite a few ransomware strains, including Spora, CryptoShield, CryptoMix, and Cerber, as well as banking Trojans and various other malware types.


Announcing the first SHA1 collision

February 24, 2017 – 5:49 AM

Cryptographic hash functions like SHA-1 are a cryptographer’s swiss army knife. You’ll find that hashes play a role in browser security, managing code repositories, or even just detecting duplicate files in storage. Hash functions compress large amounts of data into a small message digest. As a cryptographic requirement for wide-spread use, finding two messages that lead to the same digest should be computationally infeasible. Over time however, this requirement can fail due to attacks on the mathematical underpinnings of hash functions or to increases in computational power.

Today, more than 20 years after of SHA-1 was first introduced, we are announcing the first practical technique for generating a collision. This represents the culmination of two years of research that sprung from a collaboration between the CWI Institute in Amsterdam and Google. We’ve summarized how we went about generating a collision below. As a proof of the attack, we are releasing two PDFs that have identical SHA-1 hashes but different content.

For the tech community, our findings emphasize the necessity of sunsetting SHA-1 usage. Google has advocated the deprecation of SHA-1 for many years, particularly when it comes to signing TLS certificates. As early as 2014, the Chrome team announced that they would gradually phase out using SHA-1. We hope our practical attack on SHA-1 will cement that the protocol should no longer be considered secure.

We hope that our practical attack against SHA-1 will finally convince the industry that it is urgent to move to safer alternatives such as SHA-256.