Grizzly Steppe and the Appallingly Slow Response to a Digital Threat by the United States.

January 20th, 2017

On December 29th the Department of Homeland Security (DHS) and the Office of the Director of National Intelligence (DNI) released a Joint Analysis Report, or JAR, compiled by the DHS and FBI, that attributed election related security compromises to Russian intelligence operatives. The report was given the codename 'GRIZZLY STEPPE'. One of the apparent goals of the Grizzly Steppe report was to publicly provide "indicators of compromise" from the recently de-classified data collected on the Russian hacking operation meant to affect the 2016 Presidential elections. In a corresponding press release by the White House on the Russian malicious cyber activity the following was stated:

"The report also includes data that enables cybersecurity firms and other network defenders to identify certain malware that the Russian intelligence services use. Network defenders can use this information to identify and block Russian malware, forcing the Russian intelligence services to re-engineer their malware. This information is newly de-classified."

There was only one piece of malware discussed in the accompanying Grizzly Steppe JAR report and that was on the PHP based webshell now more precisely documented and described as PAS v3.1.0 by the company Wordfence. Wordfence determined that this webshell appeared to be an easily obtained webshell written by an Ukrainian researcher and has since been updated to v4.1.1b which is also publicly available for download.

We were curious at just how quickly the Yara signature, provided in the JAR report by the US Government, would be incorporated into the major anti-virus scanners. Maybe more importantly, we wanted to know how effective it would be at identifying this webshell and any of its variants in the wild. We created three different variants of the PAS webshell for testing. The first was the original PAS v3.1.0 described in the Grizzly Steppe report. The second was a modified PAS v3.1.0 where only ten characters were changed. This simple change in one line of code allowed the PAS webshell to retain all its original functionality but altered the code profile such that the Yara signature, as originally stated in the JAR report, might not be as effective. The last test was done on the more current version of the PAS webshell, v4.1.1b.

To our surprise eight days after the initial report by the US Government still only 4 out of 53 anti-virus scanners used by the online virus checker "" were able to identify the PAS webshell as malicious (Figure 1). When we tested our modified version of the Grizzly Steppe PAS (change of 10 characters) only the anti-virus scanner by Bkav was able to correctly identify the file as malicious (Figure 2). The other 53 commercial scanners did not identify it as malicious. When we tested the newest version of the PAS webshell, which has significant changes in its code from that of the v3.1.0 version, only Symantec was able to correctly identify it as a malicious webshell (Figure 3). No single anti-virus scanner was able to correctly identify all three variants that we used as malicious.

One would expect that the operators behind these webshells are very well-informed on all the recent news about the Grizzly Steppe report, saw the Yara signature stated in the report, and made necessary adjustments. One of the functions of these webshells is to essentially allow for the creation of additional webshells or to have the existing webshell replaced with a modified version. So it would not take much time to either cover their tracks or burrow further into a breached site.

Its not clear to us why the lag between the Grizzly Steppe report and the implementation of its key points by "Network Defenders", as the report describes , seems unacceptably long. For a state sponsored hacker group eight days is a lifetime.

We retested these three different PAS webshell variants January 20th, now three weeks out from the initial Grizzly Steppe report, and saw no improvements from our initial test done January 7th. The vast majority of the ant-virus scanners continue to not even pick up the original v3.1.0 PAS webshell and our modified v3.1.0 PAS webshell continues to be only picked up by one anti-virus scanner.

Company News, Website Security

Grizzly Steppe and a Two Prong Strategy to Compromise a Rural City in Northern Wisconsin

January 11th, 2017

[PLEASE NOTE that many of the website domains discussed in this report remain compromised and likely contain malware. Do not visit them unless you absolutely know you have the appropriate safeguards in place on your own computer]

Recently in mid-December we reported on unusual Russian and Kyrgyzstan based web traffic coming to the City of Ashland, Wisconsin website server starting on March 16th. The unusual nature and circumstances were such that we reported it to local authorities who in turn reported it to the FBI.

This unusual pattern of traffic starting on March 16th has been confirmed by others in the area to have occurred in at least two other Northern Wisconsin area cities -- Bayfield and Washburn. We have evidence to believe it likely also occurred in La Pointe Wisconsin as well.

What led us to investigate this traffic in the first place was all the talk at the time about Russia’s potential interference in our presidential elections. This prompted us to take a more careful look at the various sources of foreign traffic coming to the City of Ashland’s website. What we found was entirely unexpected. Traffic from both Russia and Kyrgyzstan showed sharp, unprecedented increases to the City website starting around March 16 of this year and this traffic remained elevated and sustained through the election (figure 1). This traffic pattern did not occur on any other non-government or non-municipal websites in the area that we were able to analyze. This made the results all the more odd.

Initial analysis done on the website files and server log files could not identify any compromise. Further analysis on the server log files did however identify numerous attempts to compromise the site and/or look for the presence of malicious files previously uploaded. Initial analysis identified malicious attempts in March coming from the following countries:

Czech Republic

Many of these attempts appeared to be automated and potentially coming from a botnet as the requests were occurring many times a second and in some cases from rapidly changing IP addresses and user agents. Because none of the attempts appeared to have been successful and absent any other evidence or data we ended our analysis of the log files and focused more on why this started in March and what aspect of the US election season this would correspond to.

This all changed a few weeks ago when the Grizzly Steppe JAR report was released jointly by the Department of Homeland Security and the FBI. This report documented some of the government's findings on the purported involvement of the Russian government's interference in the US elections via cyber means. Part of the Grizzly Steppe report discussed an IOC (indicator of compromise) which was a PHP based webshell used to establish sustained access and compromise of a website including WordPress based websites. It was of the type of webshell that we routinely look for on our clients websites. We quickly updated our scanner with a new regex based code fingerprint and verified that this particular webshell was not present. Very good analysis on this webshell has already been done by Mark Maunder at the company Wordfence. Many of the malicious attempts to compromise the City of Ashland website, that we found in the server logs, were of the type that if successful would subsequently lead to the upload and installation of a webshell on the website server. It should be noted that the webshell described in the JAR report was NOT the same as the malware found on the DNC network by the company CrowdStrike. There is alot of confusion in the media that the less sophisticated webshell described in the JAR report was the same malware that infected the DNC. The two pieces of malware are very different and serve very different purposes. The other part of the JAR report that provided new information was a list of over 800 IP addresses that our government said were used during the Russian hacking operations.

We cross-checked this list against the server logs from the City of Ashland and found at least 8 IP addresses from their report that exactly matched IP addresses that were probing the City of Ashland website back in March. I am not sure how to calculate the odds of this happening by random but considering there are roughly 4 billion IP addresses in use at any given time the odds are astronomical that these Grizzly Steppe IP addresses just happened to randomly also hit the City of Ashland website in March. Of these eight IP addresses three were from TOR exit nodes, which is an encrypted and anonymous browsing service that is essentially untraceable. The list is shown below with the identified country of origin for the IP address. -- -- Sweden (tor exit node) -- ??? -- Germany -- -- Norway (tor exit node) -- -- Luxembourg -- -- France (tor exit node) -- ???? -- Germany -- ???? -- Slovak Republic -- -- Romania

What was interesting about these entries in the server logs were that they primarily appeared to be referral spam. Basically entries that were injected with fake referrer data and sometimes fake user agent data. Because most of them were aimed at the non-www version of the city website this request caused an immediate 301 redirect to the "www" version. In many cases this in turn generated a request from a new IP address. Based on the groupings of the requests there seemed to be a set of 10-15 different domains that were used repeatedly throughout March.

Other IP entries (non-Grizzly Steppe matched) showed a more garden variety type of request that had the goal of testing whether the website had already been compromised with a previously uploaded malicious file. This block of entries made 10 requests in 3 seconds from 7 different rotating IP addresses. Some of these IP addresses were from the same networks identified by the Grizzly Steppe report but were not exact matches.

What was also interesting to us was that the vast majority of all the entries described in this report came from 1 of 2 user agent profiles. These could be identified using the below regex pattern.

regex = Mozilla\/5\.0 \(X11; (Ubuntu|Linux)

When we searched for this pattern against the city server logs in March we found even more entries that were consistent with what we identified in the Grizzly Steppe report. That leads us to believe that the +800 IP addresses identified in the Grizzly Steppe report was by no means an exhaustive list. Below shows a couple of new IP addresses we identified.

So we already knew that one of the goals of these requests to the City of Ashland website server back in March and through the election was to look for vulnerabilities, exploit the website and potentially insert malware into the website. These newly identified requests in the server logs appeared to be solely referral spam and was an entirely different campaign. Generally, referral spam has a simple financial goal of getting additional traffic to be referred to the domains that the owner has created which could be ecommerce sites, porn site or simple parking pages with Google Adsense campaigns running on them. That is usually done by a single operator running a couple of websites. What was odd about this was there were so many different domains being generated in rapid succession and more importantly they were using IP addresses identified in the Grizzly Steppe report. This type of referral spam would also only really be viewable by a website administrator who is generally the primary person reviewing the webstats. Seeing a significant uptick in traffic coming from one of these strange referral sites might entice an administrator to click on the link and check out why this site was sending traffic to their particular website.

When we looked at who owned these domains, when they were registered and where they were hosted we noticed more Russian ties. We could identify at least two individuals responsible for these domains: Wang Wu of Chengdu, China and Svetlana Dobrynina of Tokyo, Japan. A third group of domains had their registration information private. Interestingly one of Wang Wu's domains was later made private through a Russian privacy registrar.

Group 1:

http:// hundejo(dot)com --> Location: Chengdu, China Name: Wang Wu RegistryGate GmbH DNS: (owned by Wang WU since April 2015)

http:// burger-imperia(dot)com --> Location: Chengdu, China Name: Wang Wu RegistryGate GmbH DNS: (owned by Wang WU since May 2015 - then in July 2016 this was then made private using a Russia Privacy service with a Moscow address, IANA=1606. DNS remained as

http:// pizza-imperia(dot)com --> Location: Chengdu, China Name: Wang Wu RegistryGate GmbH DNS: (owned by Wang WU since April 2015)

http:// hvd-store(dot)com --> Location: Chengdu, China Name: Wang Wu RegistryGate GmbH DNS: (owned by Wang WU since April 2015)

http:// pizza-tycoon(dot)com --> Location: Chengdu, China Name: Wang Wu RegistryGate GmbH DNS: (owned by Wang WU since April 2015)

Group 2:

http:// azartniy-bonus(dot)com --> Registered using a Hong Kong Privacy company. DNS: (first created in May 2015)

http:// sale-japan(dot)com --> Location: Tokyo, Japan Name: Svetlana Dobrynina (Russian National with Russian email address) Company: Nikko Capital Registar: REGTIME LTD DNS: (first created Dec 2014)

http:// bio-japan(dot)net --> Location: Tokyo, Japan Name: Svetlana Dobrynina (Russian National with Russian email address) Company: Nikko Capital Registar: REGTIME LTD DNS: (first created Dec 2014)

http:// --> Location: Tokyo, Japan Name: Svetlana Dobrynina (Russian National with Russian email address) Company: Nikko Capital Registar: REGTIME LTD DNS: (first created May 2011 -- last updated May 15, 2016)

http:// xrus(dot)org --> Location: Nassau, Bahamas Private Registration. DNS recently changed to (first created in Dec, 2014 -- Changed to Private Registration info on March 22, 2016)

http:// royal-betting(dot)net --> Location: Nassau, Bahamas Private Registration. DNS: (first created in Apr, 2015)

Note: xrus(dot)org appears to be a Russian porn site and was likely compromised at some point in the past.

Below is an example of what one of these parking domains looked like.

When we further analyzed the structure and code on these various domains we found a few to be using outdated CMSs that had well known security vulnerabilities and some that loaded suspicious javascripts and/or PHP files. Most seemed to either be compromised or had indicators that they had been compromised in the past. The hvd-store(dot)com domain in particular caused a cycling of redirects in our browser until it sent us to a URL hosted on lazymae(dot)com that was clearly intended to compromise our computer with a fake Adobe Flash update download.

It is likely that many of these other domains are or were infected with malware with the intention of infecting or compromising the user's computer who might unwittingly download what they thought was a valid software update. It is our hope that the vast majority of administrators and IT specialists would be experienced enough to know this was fake .. but it only takes a few people to make a mistake. There have been some 0day exploits found in web browsers (like the recent Firefox exploit) so some admins could have been compromised by just clicking on the links if they weren't using the most up to date and secure web browser.

To the best of our knowledge this is the first time we have seen the coordinated use of referral spam solely to target website administrators and attempt to compromise their computers with malware. The goal would be to intercept communications and capture administrator credentials that could then be used to compromise other networks and systems under the administrator's control.

It is our belief that the foreign based attack on the City of Ashland website server was a two pronged attack. One goal was to target us as the website administrator and the other goal was to probe the website and server for vulnerabilities that could then be exploited.

What is still unanswered is whether the owners of these referral spam networks were aware of what was going on or were they also compromised and used as a proxy network to further the goals of the Russian government.

Company News, Website Security

When Redesigning a Website is a Financial No-brainer

January 9th, 2017

There are many factors that can go into the calculation of whether or not to redesign and/or update a company website. Factors such as "mobile compatible" or "search engine friendly" have dominated this calculation in the past couple of years and will continue doing so for at least the next few years. But a metric like bounce-rate is often over-looked. Bounce-rate for a website is generally defined as traffic that comes to your website and then very quickly leaves within a few seconds. So essentially it does not look at any other pages. It would be similar to someone walking into the front door of a retail store, did a quick scan of the store and then turned around and left. This is not what you would call a high quality sales interaction.

A high bounce-rate for a website is often an indication of a poor user experience and response to the design, content and functionalities. It can indicate that a number of problems exist on the site like poor navigation, slow page loads, poor aesthetics, and low content quality. Keep in mind that there are situations where a high bounce-rate may not be a bad thing and has to always be assessed along with with other factors like session time before it can be suggested that it is a negative indicator. Getting alot of traffic to your website is pointless if the traffic immediately leaves. This is especially troublesome if you are paying for this traffic. We see many companies running online advertising campaigns that are paying thousands of dollars a month and the traffic that these campaigns generate has a bounce rate of over 90% and session times of only a few seconds. This is akin to using hundred dollar bills as fuel for the fireplace to heat your office.

When a company website has a very high bounce rate and hasn't been updated in a number of years a redesign could be warranted both for the aesthetic improvements and more importantly the potential improvements in the pocketbook. In many cases just redesigning and updating the website itself will likely instantly double the "effective" traffic to the website without any other advertising or optimizations.

What do I mean by "effective" traffic? For the purpose of this discussion I am talking about the percentage of traffic that your company has a chance of converting into a lead, a sale or some other beneficial metric for the company. Here is an example. Let's compare two Belize Resort websites that both get 500 visitors a day.

Website A gets 500 visits and has a bounce rate of 76%
Website B gets 500 visits and has a bounce rate of 38%

If you analyze website metrics like bounce rates alot you can quickly see that Website B will be getting more "effective" traffic than Website A. You can more clearly see this if we make the comparison of the two sites and only look at the traffic to the sites that does not immediately bounce and go away. This is the non-bounce traffic or "effective" traffic as I am describing it here.

Website A gets 500 visits x 76% = 380
-- non-bounce traffic is 500 - 380 = 120 visits
Website B gets 500 visits x 38% = 190
-- non-bounce traffic is 500 - 190 = 210 visits

Website B, because of its lower bounce rate, has almost twice as much "effective" user traffic.

Now lets go from the hypothetical to an actual example of a website redesign that we did recently and show some hard numbers. The below case study describes the redesign we did for the WhistleStop marathon website which is the Upper Midwest’s top fall classic marathon. Prior to our redesign the WhistleStop marathon website was not mobile compatible and suffered from a very high bounce rate (roughly 76% over a period of the last two years).

After the launch of the new website design, which was a mobile responsive theme, the bounce rate instantly dropped to about 46% and has continued to go down to now an average of about 38% (Figure 1).

Below are some calculations on how the redesign and the significantly lower bounce rate for the WhistleStop website immediately produced a significant financial benefit.

WhistleStop savings from the new design.

From the various online advertising campaigns we will use the average cost per click of $1.70 per visit.

Traffic over a period of 3 days and their different bounce-rates.
931 x (46% bounce rate) = 502 (these are non-bounced visits) in 2016
931 x (74% bounce rate) = 242 (these are non-bounced visits) in 2015

The improvement above in bounce-rate produced an increase in 260 "effective" and convertible traffic over three days (502 in 2016 which is 260 visits larger than 242 in 2015).

This would be an increase in 87 visits per day * $1.70 or $148 per day in advertising cost savings. For a month this equals = $4440.00

This means the new design for the WhistleStop website is saving them $148 per day in extra advertising costs that they might otherwise have to spend to produce the same level of "effective" traffic.

This savings is before you take into account the increase in traffic because of the site being more search engine friendly. The screenshot below shows that the traffic to the WhistleStop website was up 16% this year over last year not taking into account any changes in bounce-rate. The year over year increase gets greatly amplified when you look at the increase in "effective" traffic year over year  and in this case it was an increase in 198%. In just one cycle the savings easily pay for the redesign costs. As you can clearly see this redesign project was a "financial no-brainer".


Company News, SEO and SEM

PHPmailer has Remote Code Execution Vulnerability Affecting Millions: Hackers get huge present on Christmas Day

December 27th, 2016

A critical vulnerability in the nearly ubiquitous PHPmailer transport class was published by Dawid Golunski of LegalHackers on Christmas day (CVE-2016-10033). The PHPMailer code class is one of the world's most popular transport classes, with an estimated 9 million users worldwide. It is one of the most popular code classes to send email via PHP and is the primary method used in many open-source projects such as WordPress, Joomla, Drupal, 1CRM, SugarCRM, Yii, and many more. It is also used in plugins, modules, extensions and themes in many of these CMSs.

The vulnerability disclosed is a Remote Code Execution so it is a serious vulnerability. Many vendors are scrambling to determine just how vulnerable they are and the big open-source CMS companies (WordPress, Joomla, and Drupal) have not yet released patches.

As Dawid Golunski described in his advisory, "to exploit the vulnerability an attacker could target common website components such as contact/feedback forms, registration forms, password email resets and others that send out emails with the help of a vulnerable version of the PHPMailer class."

All versions of PHPMailer before the critical release of PHPMailer 5.2.18 are affected, so web administrators and developers are strongly recommended to update to the patched release.

The staff at SlickRockWeb are taking this vulnerability seriously and the day after Christmas we were already identifying plugins, themes and core files that could be affected. We have also begun applying a custom patch to all of our customer sites' well in advance of the vendor patches which as of yet have not been released.

If you have any questions about this vulnerability and whether you think you might be affected do not hesitate to call us at 1-800-975-5695.

We will be providing more updates as we discover more information and as more information by other security analysts are published about this vulnerability.

[UPDATE - 12/28/16: Dawid Golunski discovered that the patch for the RCE exploit he found in PHPmailer that was implemented in 5.2.18 has created a new 0-day exploit. All web administrators and developers are strongly recommended to update to the 5.2.21 version of PHPmailer which fixes this inadvertent 0-day exploit. Note the 5.2.21 version also covers the original RCE vulnerability first discovered by Dawid. ]

Company News, Website Security

Beware the Ides of March? Troubling Early Hints of Russian Interference in the U.S. Presidential Election

December 13th, 2016

[UPDATE -- 01/03/17 -- After analyzing the Grizzly Steppe JAR report released jointly by DHS and FBI on 12/29/16 we can confirm that at least 7 IP addresses from their report exactly match IP addresses that were probing the City of Ashland website back in March. Of these seven IP addresses three were from TOR exit nodes, which is an encrypted and anonymous browsing service that is essentially untraceable. We are in the process of submitting more details to journalists and we will publish our own report shortly. UPDATE  2 -- 01/11/17 --  Our subsequent Grizzly Steppe article was published on Jan. 11th, 2017.]


After spotting some odd Russian and Kyrgyzstan-based traffic to the website for the City of Ashland, Wisconsin, we were recently interviewed by a local newspaper about the significance of this strange traffic (ref-01). As we stated in the interview, recent talk about Russia’s potential interference in our presidential elections prompted us to take a more careful look at the various sources of foreign traffic coming to the City of Ashland’s website.

What we found was entirely unexpected. Traffic from both Russia and Kyrgyzstan showed sharp, unprecedented increases to the City website starting around March 16 of this year (figure 1). This traffic remained elevated and sustained through the election. We could not find any other increase like this in the previous two years of log files for the city. When we looked at other countries that are known sources of hacker traffic, like Brazil, India, and Pakistan to name a few, none showed anything other than flat baseline levels of traffic, with no dramatic spikes in March or other months during the presidential election. As we told the Ashland Daily Press, “On most websites you are always going to get a little bit of traffic there, and every day there is always somebody looking for a security issue, so you are always going to see a baseline of traffic that is always a little suspect. Most of the time they don’t find anything, they are just trolling for security flaws.”

Figure 1.

The Russian and Kyrgyzstan traffic patterns were different and unusual in that they both started around the same day, March 16. The anomaly was significant enough for us to contact Ashland Mayor Deborah Lewis and to ask if anyone else in the area had seen something similar. Mayor Lewis spoke with Paul Houck, Bayfield County Director of Information Technology, who confirmed that the county had discovered the same pattern of web traffic to its own website. Houck agreed with our initial speculation that the traffic might be related to the U.S. presidential election. Once Houck had confirmed seeing the same thing in Bayfield County, Ashland Mayor Lewis passed this information on to local law enforcement, who in turn passed it on to the FBI.

We also expanded our analysis to look at other non-city and non-county websites in the area and found only one other website that had the exact same pattern: the Madeline Island Chamber of Commerce website. We believe it is possible that this website was mistaken for a municipal or county website. We have also reached out to the city administrator of La Pointe, Wisconsin to see if they observed a similar pattern and they are currently looking into the issue.

As reporter Rick Olvio stated in the original Ashland Daily Press article, “Still it’s difficult to ascribe a non-malevolent motivation for this kind of behavior. It is difficult to see what legitimate interest computer operators in Russia would have in repeatedly hitting on computers in the Chequamegon Bay region” (ref-01).  We agree with his assessment.

So why did all of this begin happening in mid-March and what was the motivation or purpose of this traffic? The pattern was certainly unnerving to us, considering that the U.S. Government has now formally accused Russia of hacking the computer networks of both major political parties’ national committees along with multiple party officials and asserting that Moscow was trying to interfere with the U.S. Presidential election (ref-02). Some of our initial analysis of the server logs files revealed that much of the suspect traffic was indeed scanning for known security flaws in common website-related code. No obvious flaws existed on this site, but clearly at least a portion of the Russian traffic was looking for vulnerable code that could be exploited. Some of the other traffic appeared to be information gathering, possibly looking for key people involved with the election apparatus.

We have so far found no evidence of a breach but at the same time aren’t confident we would even be able to identify a state-sponsored hacker. Russia is known to have some of the best hackers in the world. If they can breach a U.S. Department of Defense website, we certainly are not naïve enough to think that we could stop them.

With the Wisconsin presidential recount now ending, the areas related to the odd website traffic in question have all finished their recount. At least in Ashland, Bayfield, Douglas and Iron counties, the recount was done by hand and did not reveal any significant differences in the vote totals or widespread vote tampering. Of course, many counties in Wisconsin did not do a full hand-recount of the paper ballots and instead fed the ballots back through the same machines to be counted again. It’s not yet clear if other Wisconsin counties experienced similar and unusual levels of website traffic coming from Russia or Eastern Bloc countries and starting in mid-March.

Besides providing cyber-security services for small businesses all over the country, our bread and butter service is search engine optimization (SEO). In this case, we reasoned, SEO tools might at least help put the unusual mid-March traffic surge in context to events related to the election, and we used a combination of Google searches and Google Trends to analyze events occurring around the same time. March was particularly newsworthy for many of the presidential contenders and the heart of the primary season (March 15, in fact, was one of the Super Tuesday primaries that included Ohio, Florida and North Carolina).

We started our analysis with a simple Google search that included the names of the top four presidential candidates (Donald Trump, Ted Cruz, Hillary Clinton, Bernie Sanders) and a separate set using their campaign managers at the time. Trump had two different campaign managers in March, Corey Lewandowski and Paul Manafort, so we included both in our analysis.

The first set of searches included the following search criteria: [“full name of candidate or manager” + "march" + "russia"] and we instructed Google to only search within the past year to increase the relevancy of the results. By using the “+” sign and putting the terms in quotes, we also forced the search engine to include only those results with all three terms. Trump’s name appeared most often in our results, shown below (figure 2). This wasn’t entirely unexpected, given his previous statements appearing to praise Russian Federation President Vladimir Putin and his other mentions of Putin on the campaign trail (ref-03).

Figure 2.

We repeated the process using a more selective search to further reduce the number of results and weed out peripheral and unrelated results. This search included the following criteria: [“full name of candidate or manager” + "march" + "ties to russia"] and again was limited to the past year. Our results are shown below (figure 3).

Figure 3.

This time, we saw that the search results included Trump’s campaign manager, Manafort, four times as often as any other campaign manager. This was certainly an intriguing result. A few Google searches of Paul Manafort and whether he had any potential ties to Russia, revealed numerous in-depth articles like this one from the Atlantic (ref-04). He appeared to have numerous ties to Russian oligarchs, Vladimir Putin and pro-Russian politicians in the Ukraine.

Google Trends is a particularly useful tool that can look for historical spikes in certain topics or searches and zero in on when significant changes occur. We examined the March 1, 2016 to April 30, 2016 time period and specifically looked for spikes in “Paul Manafort” in referenced articles and Google searches. Interestingly, one hit occurred on March 15 and the first major spike then began on March 29, when Manafort was formally announced as Trump’s new campaign manager. Lewandowski was removed as Trump’s campaign manager on March 17 because of an apparent rift with Manafort, who at the time was Trump’s chief strategist (ref-05).

Figure 4.

We note that according to CNN, unnamed officials now believe that the initial hack of John Podesta’s email account, the campaign chair for Hillary Clinton, occurred on March 19 (ref-06). This was four days after the unusual traffic we discovered in two small, rural, northern Wisconsin counties. This illustrates a very important point when it comes to hacking. Most hackers that are good find an initial doorway (breach) into the site or network, create some extra backdoors in case the initial breach gets patched and then they wait for months and months to either collect surveillance, carefully steal data from their target or find the perfect time to further exploit their hack. The hack of John Podesta's email is a perfect example of this. The first public revelation of this hack through a wikileaks dump was at the beginning of October, about six months after the initial breach in March. We have repeatedly seen this same pattern in the small business websites that we have helped remediate and harden. Almost always the initial breach was successfully done months prior to the final attack or end goal of the hackers.

Although intelligence officials have gathered evidence of Russian-based hacks of other government and political party-affiliated websites dating back months or even years, March 2016 appears to have been a particularly active period for Russian involvement and/or interference in the U.S. Presidential election. The how and for what purpose at this point is not clear. What is clear however, is that a larger and more extensive investigation needs to be done and other city and county websites across the country need to verify whether they were scanned and/or breached prior to the elections.

Company News, Website Security

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