Anatomy of a Spam Email and New Techniques Being Used to Evade Detection – Part I

December 9th, 2017

As what probably some would think is an odd hobby, we collect and analyze spam in our spare time. What is interesting about looking at the nuts and bolts of spam campaigns is the ever changing techniques that are used to evade detection. There are all kinds of digital weapons deployed to identify and stop spam. All the way from sophisticated algorithms that ISPs use down to simple client-side signature based software on your grandpa and grandma’s home computer.

There are spam campaigns to promote erectile dysfunction pills, various over the counter or difficult to get medications, any type of ecommerce product ever created, travel vacation and cruise scams, payday loans, porn / adult content and the more nefarious spearphishing campaigns. Some spearphishing campaigns come with embedded links to hidden payloads containing ransomware or malware. While other spearphising emails aim to harvest / steal your credentials to your email, banking, or any other online or social media account. Below is an example of a spearphishing email attempting to steal the credentials to an Apple ID account.

This above Apple related spearphishing attempt has a number of interesting features that helps it bypass spam filters. One is that the “L” in apple for this particular spam is actually a capital “i” but uses a font that makes it nearly impossible to tell. Second it uses some fancy code in the From: field to make sure the user only sees the word “Apple” (in this case Appie) in the from box even though the sending email is clearly not from Apple.

This is what a normal from field should look like:

From: Google Alerts <>

Below is a another spam email that we recently received in one of our many honeypot inboxes. It is an email promoting international matchmaking with Russian and Ukrainian women. Obviously, this spam campaign is aimed at men and aims to promote the idea of international brides. So for the purpose of brevity I will avoid getting into the exploitative nature and social commentary on this type of business.

Whether this particular business is even legitimate is not really  the point of this article … and in fact we spent really no time trying to determine whether the business / site being promoted was even an actual company and have redacted the business website. As we lay out the building blocks of this particular spam campaign here and in part II, it will become quite obvious that one should  “run not walk” away from anything promoted in this email.



The first component of any spam email is what is found in the header section. Most email clients have a tab that allows you to look behind the scenes of an email and see some of the code and metadata. Here is an example of where to find the header information and raw source metadata of a spam email if you are Mac user.

When we look at the raw source data of the Russian international bride spam we immediately see that the sender domain does not match the public facing domain of the spam email. That is always the first red flag and for a less sophisticated user this is the easiest first step to look at in case you are suspicious about a particular email.


The sending domain of this spam email, indicated by the red arrow, is red2copprr[.]us and the sending IP address, indicated by the blue arrow, is 176.10.250[.]145. This sender’s IP address maps to the ISP, Bahnhof Internet, in Kista, Sweden. As everyone knows, the sender IP address can be spoofed so where this is mapped to certainly isn’t conclusive proof of anything. More on this in part II. Next we look at the subject section of the raw code below and see suspicious looking embedded PHP links and a big chunk of whitespace as indicated by the red arrow.


This is followed by a large section of random text with no obvious words that could be flagged by a spam filter. It is a little curious their use of injecting “c” characters in certain places and replacing other letters in some words with periods. Not exactly sure what specific algorithmic filter this is trying to defeat. However, the use of random lengths of whitespace and random chunks of scrambled text serves two purposes. It makes it difficult for normal spam filters to flag this as spam based on textual parameters such as certain words, the ratio of words to images, and other common flags. It also defeats filters created to detect the size of the spam email and percent identity to similar emails or even other emails sent out from this same campaign. So already there are multiple methods coded into this email to help it defeat spam filters.

So where is the raw code section that actually generates the public facing text in the email shown in figure 2? Well this is the interesting part and something we only started seeing within the last year. In the original email all the text can be selected and copy and pasted so we knew it wasn’t just an embedded image. Incidentally this would create a very low text / image ratio and is itself a red flag. Instead, what has been done in this email and many of the spam emails we have collected this year is the use of base64 encoding all the text. Generally this is only done for images and to be honest up until this year I didn’t even know most email clients could handle base64 encoding and decoding using the Content-type: text/html designation. So what happens is the spammers take their text and encode it using base64 encoding and place the block of scrambled alpha-numeric characters into the email and essentially the two code directives indicated by the red arrow tell your email client to decode this block into the actual text when you load up this email to actually read it. A spam filter sees the raw code below and again would not be able to flag anything based on obvious spam words like “Russian” or “Ukrainian girls” or “your perfect mate”.

Below is an example from Wikipedia [] of how this base64 encoding of a paragraph of text from Thomas Hobbes' Leviathan would work.

So once again another level of spam construction meant to evade spam filters. In our part II article tomorrow, we will delve into who might be responsible for this campaign.


Website Security

A Different Take on the Krebs on Security Article about Marcus Hutchins' Past (aka @malwaretechblog the accidental hero who stopped Wannacry)

September 6th, 2017

Most people who spend any time online know about the Wannacry ransomware incident that happened in May of this year. Less know how the global spread of WannaCry was serendipitously stopped by a British whitehat security researcher known at the time by his twitter handle @malwaretechblog.  Journalists would later determine that his name was Marcus Hutchins. Although as I found and show below, he was doxxed all the way back in 2015.

Fast forward to August of this year when FBI agents in Las Vegas arrested 23-year-old Marcus Hutchins and charged him with authoring and potentially selling “Kronos,” a strain of malware designed to steal online banking credentials. This decision to arrest Marcus apparently stemmed from the takedown of AlphaBay, the dark web marketplace that was recently seized by federal law enforcement in July of this year.

Since this arrest, there has been much discussion about Marcus Hutchins within the infosec community and whether he might be innocent or guilty of the charges. Much has already been uncovered which would point to his innocence of these federal charges as I mention at the end of this post. Although I caution much is still not known and much of what the FBI has will eventually come out in court.

But not much of Marcus' past, his teenage years, had been discussed up until yesterday when Brian Krebs of Krebs on Security, an investigative blog on cybersecurity issues posted the article "Who is Marcus Hutchins".

Brian Krebs' article does a good job of connecting the dots and multiple aliases allegedly belonging to Marcus going all that way back to 2009. And it is clear from Brian's article that Marcus was probably not a saint in his teens. Where the allegations start to break down, for me at least, are around the alias "ElementProducts". This part of Krebs' story documents some of the more serious blackhat activities. It is also where the attempts to connect the dots to Marcus Hutchins start to become very fuzzy. Bear in mind that all of what Brian Krebs alleges that Marcus may have done occurs 5-8 years ago and are based on posts in hacker forums and domain name registrations. There is no evidence provided that point to financial dealings or gains that Marcus might have made from these activities. There is also no direct proof that any harm came directly from these activities while he was a teenager. Also none of these activities documented in Brian Krebs' article have any direct relationship to the federal charges Marcus Hutchins is currently facing.

After reading the Krebs' article I decided to do a little investigative research as well and based on what I found I present a slightly different look at Marcus' more recent past below. Some of what I found also illustrates that Marcus' not guilty pleas to the current federal charges may in fact be quite sincere.

First off, in my limited experience, underaged hackers (actually most hackers) are BIG talkers. You don't have to read more than one IRC chat log to come to this conclusion. I also always go under the assumption that everyone on the internet lies. So anything I read in a chat forum or IRC has the potential to be 50% true and 50% false. So with that said, when one hacker on a forum or IRC chat says something about someone else, it could be true or it could be a lie and there could be all kinds of ulterior motives. The stuff Brian Krebs documented in the "Gh0sthosting" section of his article occurred while Marcus was a minor and was prior to 2011. On the surface the connected dots seem fairly strong but again most of what Brian is alleging is based on the idea that a change in an alias can be determined to be the same person because of how the Hackforums functioned.

Everything builds off of this assumption so it would have been nice to see Brian demonstrate a known example of one of his past aliases on Hackforums within a thread and then the changed alias. I honestly don't know how the database at Hackforums functions, whether it can be manipulated, how the deletion of an account is handled by the database and whether someone else could have logged in under Marcus' account. Brian does state that the credentials of Hackforum users were hacked and dumped back in 2012. Given that the databreach at Hackforums probably included at least one of @malwaretechblog 's passwords there is also no way of knowing whether someone else logged in and posted as him. It also isn't clear that the connections to the various domain name registrations prove a connection to Marcus. Many of these domains fail to get renewed and are picked up by other hackers. Thus Michael Chanata could really be a completely different persona from that of Marcus Hutchins.

As Brian Krebs well knows hackers can get very creative when attempting to take someone down. Back in 2013 hacker(s) attempted to frame Brian Krebs by anonymously mailing him heroin. Brian has also admitted that a number of hackers have posed as himself on IRC chat logs, presumably to try and discredit him.

Since at least 2013 there have been one and possible multiple hackers that have had in for @malwaretechblog going by the following aliases of LOLzzzzzz, LOLz, Randy, Xehanort and RealDude.

Looking at Pastebin dumps, @malwaretechblog was doxxed all the way back in 2015, August 12th, 2015 to be exact ( I would note that this anonymous person posted "Larkey" as an alias and Brian Krebs says it is "Iarkey". I am assuming that was a typo by the person doing the pastebin dump.

After reading more IRC chat logs than I had really planned on doing, one hypothesis that started to form was that someone or some group had it out for @malwaretechblog and believed he somehow contributed to the darkode bust. From another pastebin dump I found the following conversations occurred in October of 2016.

It is also clear in this IRC chat log and a couple others I found that <RealDude> attempted to hire @malwareblogtech to write a banking malware and @malwaretechblog said no.

This came up eariler in the chat along with accusations of previous collaborations by <RealDude>. Again and again @malwaretechblog essentially calls him unhinged and denies the allegations.

more chats

more chats

Prior to this chat log conversation I found another one in a Pastebin dump that was uploaded in early January 2016 and the conversation appears to be from late December 2015 around Christmas. Essentially the same conversation occurs. Just replace <RealDude> with <LOLzzzzzz>.

more chats

more chats

And then later in the IRC chat log <LOLzzzzz> logs back in as <Randy>. Here is where Marcus says <Randy> has been trolling him and giving him grief for over three years. All the way back to 2013.

And then there are the timestamped tweets from @malwaretechblog back in 2014 bemoaning that someone stole a block of his code that was incorporated into Kronos.

What would be interesting to find out is whether Brendan Johnston in Brian Krebs piece is the alias Randy / Xehanort and if he had it out for Marcus Hutchins. That would quickly kick out one leg of the allegations made by Brian Krebs, at least within the attempt to connect the alias ElementProducts to Marcus.

Brian Krebs also said Element Scanner was later incorporated as the default scanning application for the “Blackshades" trojan and this is what Brendan Johnston was arrested for. So I actually see more evidence linking the alias ElementProducts to Brendan Johnston and not Marcus Hutchins.

Don't get me wrong this blog post is not meant to defend what Marcus Hutchins may or may not have done. It is also not meant to disprove Brian Krebs' article. He has done good research into Marcus' past and as a minor I am sure there were transgressions. However, I agree with others in the infosec community that Marcus deserves a fair defense and that the case against him seems rather hyperbolic and weak. It is also not based on anything he did as a minor. Nothing I have found or anything Brian Krebs has found would indicate that their is any validity to the current federal charges against him. Rather, much of the IRC logs, malware samples and prior occurrences of Kronos all point to Marcus Hutchins' innocence in this case. Time will tell.

Company News, Website Security

New Base64 Obfuscated Spam Email Campaign

June 9th, 2017

Over the past couple of months we have been noticing spam coming to us and many of our clients that has a consistent structure. The content varies, the sending email varies and the destination URL for the embedded text links varies but how the spam email is obfuscated does not. Outwardly the spam looks like a basic text only email with one or two text links. The content is very spammy and is generally trying to sell weight watching or diet products. This is content that should generally be easily blocked and not even received. So it was odd that these were slipping by the spam filters. After getting a few of these and hearing about it from some of our clients we decided to investigate these spam emails a little further. The first giant red flag was the URL structure of the destination links, which you generally see in your email client by just hovering your mouse over the text link without actually clicking on the link. Many of the links appeared to go to compromised WordPress websites of varying domains. The image below shows a couple example emails and the destination links in the hover-over popup box.

The second red flag was that we weren't able to cursor-select any of the text in the email. At first we thought maybe part of or all of the email was actually just an image ... although that wouldn't allow text links to work or the "hover over the link" feature to work. When we looked at the raw message data it became obvious what was going on. Basically all the text in the email was being obfuscated through base64 encoding (image below).

What all the spam emails had in common in the raw message data were these two lines below. This base64 encoded all the text and in some cases all the HTML content in the visible body of the email message. I am not sure if all email clients automatically base64 decode text/html content but I presume that they do ... even though this seems like a very non-standard use within an email.

Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

Normally base64 encoding is used for adding embedding images or attachments to an email message. I am not sure if I have ever seen it used in this way before, but it explains why the text was not selectable by a cursor and why it was slipping past standard keyword spam filters. The destination link for this example was clearly a compromised WordPress site. Interestingly, the domain name enilgincbilgiler(dot)com was just recently registered and is being hosted in Turkey (see below). However, I would be willing to guess that there is no consistent pattern, country of origin, or hosting provider with all of the different spam emails we have seen and archived. Maybe when I have some extra time I can look into what these destination links are trying to accomplish and if the registrants are even aware that their sites are being used in this way. In all likelihood it is malicious and trying to install malware and/or ransomware on unsuspecting users.

We would love to hear from our readers if any of you have seen something like this before and what some of the message rules or spam filters you used to catch this kind of spam.

Company News, Website Security

We Are Ill-Prepared for Russian Cyber Attacks and Congress Has Its Head in the Sand

May 25th, 2017

Last week was an eventful week of cybersecurity-related events and news, starting with the fallout from the WannaCry ransomware attack on May 12. The global attack spread very quickly to more than 150 countries, and hit critical infrastructure in industries ranging from healthcare and rail to telephone and some power utilities. Midweek, we speculated and other groups suggested that the WannaCry attack may have been the work of North Korea, specifically the Lazarus Group, as a proverbial cyber-shot across the bow. A Forbes article subsequently detailed the first-ever ransomware infection of a medical device in a U.S. hospital – a Bayer Medrad device used to assist with MRI scans – that apparently represented a secondary infection from the initial WannaCry attack.

The week ended with another unwelcome surprise: the discovery that Congressman Devin Nunes (R-CA), chairman of the House Permanent Select Committee on Intelligence, had a live campaign website compromised with Russian SEO spam. The issue was quickly fixed later that day after we alerted Rep. Nunes's office.

These worrisome events underscore what's beginning to sound like a broken record in cybersecurity circles: we remain far too vulnerable to cyber attacks and dis-information warfare at all levels of government. As NSA director and U.S. Cyber Command head Adm. Michael Rogers recently said at a Senate Armed Services Committee hearing, "We are not prepared to counter info operations."

These events also come at a time when Congress should be developing a comprehensive strategy to counter the cyber and dis-information warfare capabilities of hostile nations like Russia and North Korea. In a separate congressional hearing, former Director of National Intelligence James Clapper said, "I don't think we as a nation do a good enough job [at combating information warfare]".

Congressional leadership hasn't provided much reason for optimism either. Polarization in Congress, for instance, has hampered the investigation of Russia’s clear meddling in and campaign to undermine confidence in the 2016 U.S. Presidential Election and more controversial suggestions of inappropriate contact or coordination between Russian officials and the Trump campaign.

One such investigation was launched by the House Intelligence Committee and initially headed by Rep. Nunes. Since January, the inquiry has been beset by a series of missteps, canceled hearings and controversies. One of the biggest was the April 6 decision by Rep. Nunes to recuse himself from the investigation after the House Ethics Committee announced its own investigation of potential coordination between Rep. Nunes and the White House and "allegations that he may have disclosed classified information to the White House." Representative Mike Conaway (R-TX) has now assumed control of the House investigation.

To add to the confusion, poor optics, and general distrust by the American public, we and others revealed on Friday that Rep. Nunes himself was the victim of a cyber-hack. Late Thursday, May 18, a Twitter user by the handle @3L3V3NTH posed this question: Why were some internal pages in the campaign website indexed by Google and entirely in Russian?

We saw the tweet Friday morning and immediately suspected injected SEO malware. We have seen similar injected SEO spam in different languages on other websites that we later determined had been hacked. Some have been from new clients requesting our help, while we found other instances of the SEO spam when we conducted Google searches and then promptly alerted the website owners. Many times, SEO spam and its associated malware can go unnoticed for months because it occurs on internal auto-generated pages that a site’s owner would not know about or even how to look for.

An easy way to find these injected SEO spam pages is to isolate a Google search to find only pages indexed within a particular domain. The following Google search: "" revealed at least 11 internal pages that were all XML pages residing in the /images/userfiles/ folder (see image below). All appeared to have Russian sentences and keywords in the titles, meta tags and body content of the pages.

Based on our experience, there are only two plausible explanations. Either these were legitimate files with Russian content being housed on Rep. Devin Nunes's campaign site, or his site had been hacked and the files had been put there without his authorization. A big initial tipoff that his site had indeed been hacked was our observation that within the code of all XML files, a simple JavaScript command redirected the user to a completely new website that appeared to be a Russian travel agency. This technique is very commonly used in SEO spam hacks. You can turn JavaScript off in your web browser to disable this redirect and see the full-page code revealing this redirect.

To investigate further, we used a public website-checking tool created by the online security company for finding certain simple forms of malware and possible code vulnerabilities. Based on this straightforward approach, we found multiple, fairly clear vulnerabilities existing in the live website.

Our check also revealed the presence of an outdated installation of WordPress (4.5.2) that had been moved to a /temp/ directory but was still public facing and fully accessible on the Internet. Here's why this is so problematic: moving an outdated installation of WordPress to another public directory such as a temp folder does not change or reduce its security risk. These directories are standard places for hackers and pentesters (ethical hackers) to look for old installations; finding internal directories via automated hacker bots is a fairly simple process. The public Sucuri malware checker automatically does this as well and found the vulnerable installation within seconds. This outdated WordPress install was also using a number of outdated plugins that had not been patched for their recent security vulnerabilities.

We immediately took steps to document what we had found and alerted Congressman Nunes's office of our findings just before 12:00 CST on Friday, May 19. We did not receive any response: however, the XML files were removed and the outdated WordPress install was taken down by about 4:00 pm CST on Friday, effectively correcting the issues.

Additional Details.

We have done additional investigations into this hack and are documenting some of our general findings here. After analyzing about 20 other websites with nearly identical injected Russian SEO spam we are able to make some general statements about the how, the when, the what and speculate a little on the why.

First, it's clear to us that the website was hacked at some point in the past (more on this later). We found multiple, unpatched well-documented vulnerabilities and additional ones that could have been present in the past. By looking at archived copies of the website using the Internet's Wayback Machine, we can see that some of the vulnerabilities have existed for just over a year.

As of last week they remained publicly exposed with an insecure and vulnerable installation of WordPress (4.5.2). The current, most secure version of this branch of WordPress is 4.5.9, which includes seven additional security patches, and properly addresses a host of security vulnerabilities. Most average hackers could easily exploit many of these well-known and well-documented vulnerabilities. The outdated WordPress installation also used a number of outdated WordPress plugins that contained known security vulnerabilities, and were accessible from the Internet. The "MailPoet" plugin below, for example, is well known for its serious security vulnerabilities.

/plugins/wysija-newsletters/ (2.7.2 version found -> safe is 2.7.3)

Note that this is a well-known vulnerability and that versions 2.6.8 and prior were vulnerable to an unauthenticated file upload. Version 2.7.2 suffers from an SQL injection vulnerability that is also very serious.

These two additional plugins also contain known vulnerabilities:

/plugins/woocommerce/  (2.5.5 version found -> safe is 2.6.9)
/plugins/LayerSlider/ (5.4.0  version found -> safe is 6.2)

Interestingly, the website was also using the Revolution Slider plugin, which brought down the Panamanian law firm Mossack Fonseca back in early April of 2016. At the time, it was the largest data leak ever. The is currently using an up-to-date and secure version of Revolution Slider. But that doesn’t mean it was always properly secured in the past.

Based on our analysis into the other similarly hacked websites, it is clear a backdoor of some kind was installed on the The backdoor would have full read, write and execute permissions and would have been used to install the spammy XML files in the /images/userfiles/ directory. We believe that we have identified the precise backdoor used by the hackers and the authors of this PHP based webshell / backdoor script. We will include this and other more technical details in a future report.

One important caveat: without having the ability to look at and analyze the files on the webserver, we can't be completely certain of the precise backdoor used. We also have no way of knowing whether there was or still is more than one backdoor installed on the site. From our past experience remediating hacked websites, we have commonly seen multiple infections from completely different hacker groups all installing their own backdoor of choice. The IT staff for would be able to verify this and whether other backdoors were found. Keep in mind that some webshell backdoors have a "suicide" feature, which allows the webshell to delete itself from the server when no longer needed.

The backdoor webshell we found appears to have been created in August of 2016. Of the 20 similarly infected sites we have studied the oldest cached page we could find in Google was from February 2017, while the vast majority were from March and April of 2017. We should also note that it can take SEO spam infections several months to show up in the Google search results. So we know this specific injection of Russian SEO spam in the website likely occurred at least a few months ago and could have happened as far back as the fall of 2016.

As we mentioned above we also can't exclude the possibility that the website wasn't hacked in the past, prior to this year. Once a hacker has breached a site they will install a backdoor allowing them future full access to the website and many times they will wait many months before executing their final objective.

The link below was captured in a Google cache of another similarly infected site and it clearly shows the specifically crafted weblink that includes the webshell used to upload one of these XML files.

This is Google's cache of

It is a snapshot of the page as it appeared on Apr 23, 2017 07:16:51 GMT.

In this example the webshell (backdoor) was named "281_newshell.php" but these files can really have any name the hacker chooses. We've seen other file names like "linkk.php" and "g.php".

So why did this happen? As we mentioned above a typical feature of injected SEO spam is the use of JavasScript redirects. This is usually done because most search bots like Google don't always follow JavasScript redirects whereas a human user will. There are some perceived SEO-based technical advantages for doing something like this (too much to get into here), but the bottom line is that these JavasScript redirects will be embedded somewhere in the code of the auto-generated spam pages. It was no different with this attack and in all of the sites we looked at, we found three root domain names that were common to all of them and were responsible for creating the location where the user would ultimately be redirected.

All of the XML files contained these two lines of code where "xx" in line two was replaced with any two alphanumeric characters. Line one could have many different unique subdomains but the root domain was always one of the three listed above.

<base href="http://<subdomain>.(js-cloudbox|tdskakts|traffka-mix).com/" />
<script src="8cxx"></script>

All three of these domains have different nameservers, different creation dates, and different registrant information. The "" domain, for example, was first registered in February of 2017.

The why is the most difficult question to answer. The simplest explanation is that the website, was caught up in an automated drive-by hacking. It contained a number of common vulnerabilities that we see used in automated hacker tools. Injected SEO spam is generally done for financial gain. It is also one of the easier infections to detect so the shelf life for this type of hack is generally fairly short. (We'll share more about this aspect and details on the webshell in a future post).

Because Rep. Nunes is chairman of the House Intelligence committee, he would be considered a high-value target. Many times, hackers sell or even lease their backdoor access to other hackers or state-sponsored actors. Once a hacker is able to infect a trusted source like an individual's website, hackers can get creative. They can engage in spearphishing or catphishing, gather sensitive information, or create specific links on the website that prompt its user to accidentally download malware or ransomware onto his or her own personal computer (watering hole attacks).

Only Rep. Nunes’s office can say how severe this security breach was. The hacking, however, underscores the critical importance of good website hygiene for both private individuals hoping to safeguard their data and for public officials entrusted with safeguarding national security.

Company News, Website Security

Was the Google Phishing / Oauth Attack a Russian Pawn Storm Operation?

May 4th, 2017

Wednesday, May 3rd, there was a massive phishing attack coming from valid Google Gmail accounts that hit people's inboxes worldwide. It was a simple email asking people to click on a link to open up an online Google Doc that the sender was sharing with them.

We received one of these emails at about 1:30 pm central time and were notified by numerous people across a range of locations and businesses that they had also received a similar email.

After analyzing a few of these emails it was clear it was some type of malicious phishing attempt. We would later have a better understanding of the simplicity and sophistication of this attack.

After warning our clients we posted this warning on Twitter at 2:30 pm. This tweet was retweeted 139 times and viewed by over 50,000 people. Many others had already taken to Twitter to post similar warnings and word got out really fast.

Within a few hours Google had made their first statement saying the malicious content and redirect domains had been shut down. Nevertheless many accounts were compromised in those first couple of hours.

Google later put out a second statement that said the phishing campaign was halted "within approximately an hour" and that it "affected fewer than 0.1% of Gmail users." Given Gmail has around 1 billion users that is still a very significant 1 million victims. Many question whether the attack was really completely shut down within an hour and think it was more likely closer to two hours. Nevertheless, it was taken down very quickly and yet it is amazing to think how effective the viral propagation of this email was to have caused this much havoc in only a couple of hours. We will discuss the viral propagation of this attack in a subsequent technical analysis on the data retrieved from this attack.

What made this attack especially sinister is that it harnessed legitimate Google infrastructure. The hack used a malicious Google app which was legitimately signed with the appropriate API connections and client ID but was apparently not properly vetted and thus allowed to exist on Google's infrastructure. This app was also for some reason allowed to be called "Google Docs" even though it clearly was not created or signed by Google. Thus, other than the strange "hhhhhhhhhhhhhhhh(at)" email address used in the to: field there were no other tell tale signs of a fake phishing email attack and this email easily made it through many security filters and company firewalls.

Briefly, how it worked is that the phishing e-mail, that likely came from someone you already knew, appeared in your inbox and the sender asked that they share a Google Doc with you. If you took the bait and clicked on the Google Docs icon you would be redirected to the very real and legitimate OAUTH2 service on  There you would get another real Google screen asking you if you wanted to allow "Google Docs" permission to access your account, including your Gmail. If you granted permission the real fireworks would begin and the hackers would now have access to your contacts and Gmail account via what is called an OAUTH attack. What makes this unique is that once they had this access (which you granted) changing your password no longer mattered. They essentially had access to your account independent of your password. To fully protect yourself you needed to go into your Google security settings and remove the permissions you granted to the malicious "Google Docs" app. Google provided a simple link here ( that makes it easier to accomplish this. Much of the early advice was just telling people to reset their passwords which we now know was insufficient.

A number of twists and turns have occurred around this story in the past 24hrs since it broke and it may be some time before the intentions and actors involved become more apparent. What is very interesting to us is the fact that just last week Trend Micro published a two year long study on the mysterious Russian hacking group Cozy Bear. This is the same group that hacked the DNC. One of the methods they highlighted in the report that Cozy Bear uses, was exactly this type of OAUTH attack that was seen yesterday on Google Gmail users. Check out this Trend Micro report published April 25th, 2017 and titled "From Espionage to Cyber Propaganda: Pawn Storm's Activities over the Past Two Years" and pay special attention to pages 21 and 22 of the report.

So the big question is could yesterday's Google phishing / OAUTH attack have been done by the Russian intelligence hacker group Cozy Bear and what was the significance of yesterday?


Company News, Website Security

SlickRockWeb Inc.
601 Carlson Parkway, Suite 1050
Minnetonka, MN 55305
Call : 1-866-486-7747
Email Us