Cloudbleed: Rethinking The Current State of Internet Security

The Cloudflare incident that derailed weekend plans for many cyber security professionals is turning out to be a huge eye opener. The culprit, a bug now known as Cloudbleed, resulted in a serious data leak which affected an abundance of websites. As the dust began to settle, it became clear that the implications were far more severe than anticipated. The Internet has undergone considerable changes, and security issues must now be handled differently.


An overview of Cloudflare

In order to understand the extent of Cloudbleed, it is crucial to become familiar with the role of Cloudflare in today’s Internet. While most people might not know what Cloudflare is, there is a good chance that these same individuals actually interact with a Cloudflare service multiple times a day. Take, for instance, the following example:


The above image is that of a Cloudflare feature in action. It serves the purpose of protecting the site that a given individual is about to visit, keeping it safe from spammers and bots by making sure the person is, in fact, human. Cloudflare is a content delivery network that also provides DDoS protection, web application firewalls, DNS (domain name server), and reverse proxy services. This network serves millions of websites, acting as a layer between those sites and their visitors.


That has some advantages and disadvantages. One disadvantage is that if something goes wrong at that layer, a lot of websites are going to be affected.


Cloudbleed in a nutshell

Cloudbleed was a bug in the Cloudflare infrastructure that resulted in a data leak involving passwords, keys, cookies, POST data, and HTTPS requests; the whole nine yards. Some of this data, which came from Cloudflare customer websites, included PII (personally identifiable information), private messages, and other confidential information. Although data would only leak out if certain conditions were met, the sheer size of Coudflare’s customer base made the incident a major issue.

To make matters worse, some of the information that leaked was caught by search engine crawlers and cached into memory. This means that, even after the bug was identified and fixed, one critical, and rather tricky, task still remained.

Cloudflare had to work with Google and other search engine providers to make sure leaked data was completely scrubbed from search engine caches. Otherwise, the data would run the risk of being targeted by shady (or simply curious) characters as soon as details of the security incident broke out.

Technically speaking, the bug only affected three features:

  1. Email Obfuscation – a feature that prevents bots from harvesting email addresses (which attackers use in their spamming campaigns) from web pages;
  2. Server-Side Excludes – a feature that hides sensitive content on your site from suspicious visitors; and
  3. Automatic HTTPS Rewrites – a feature that rewrites HTTP links to HTTPS.

In addition, the bug was only triggered if (in addition to any of those features being enabled) the HTML page that was served was malformed, i.e. the page had to end with an unterminated attribute.

However, because much of Cloudflare’s infrastructure is basically shared by its large customer base, a lot of websites were still affected by the bug – even if those sites did not have any of those three features enabled. Some of the popular websites known to have been impacted included Uber, Fitbit, and OkCupid. A much longer list of potentially affected sites can be found on Github.

In order to perform their specific functions, all three features – email obfuscation, server-side excludes, and automatic HTTPS rewrites – have to parse and modify HTML pages as the pages pass through Cloudflare’s edge servers and are subsequently served to clients. To do this, the three features rely on what is known as an HTML parser. It was this HTML parser that contained the bug, which in turn caused random memory leaks.

Cloudflare’s detailed explanation can be found here for those wanting to dive into more technical information.


Discovery and Remediation

The data leak was accidentally discovered by Tavis Ormandy, a security analyst at Google’s Project Zero.

“On February 17th 2017, I was working on a corpus distillation project, when I encountered some data that didn’t match what I had been expecting”, Tavis posted in a bug report. He added that “…It became clear after a while we were looking at chunks of uninitialized memory interspersed with valid data.”

When he and other members of the team managed to fetch some live samples, they were able to obtain data that should not have been out in the open – encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests. As soon as they were able to pinpoint Cloudflare as the source of the leaked data, they immediately tried to establish contact with Cloudflare’s security team. Tavis decided to reach out through twitter.

Fortunately, some members of the Cloudflare security team were active on social media and word of the tweet reached them. This led to a series of exchanges and some collaborative work. The bug was found and a patch was deployed in less than a day. As soon as the bug’s location was identified (but before a patch was released), Cloudflare initiated what they called a “global kill” switch that disabled the features in question throughout their global network.

However, it did take more time to work with the search engine engineers in purging leaked data that was already cached. After further investigation, it was later discovered that the bug may have been leaking data for months. The leak is estimated to have stretched from late September 2016 to February 2017.

That estimated period over which data leaked is quite alarming, considering that search engines aren’t the only entities who mobilize crawlers across the Web. Ideally, leaked data cached in those systems would be purged as well.

To be on the safe side, all Cloudflare customers must assume that their sites might have leaked some amount of data and take appropriate measures. Some of the countermeasures include resetting passwords, forcing re-authentication, invalidating session cookies, rolling internal authorization tokens, adapting two-factor authentication, and educating users of potential risks.


Cloudbleed and the Current State of the Internet

Cloudbleed (and the recent Amazon outage) indicates a couple of things. First, that the Internet, as many of us know it, is now heavily dependent on just a handful of organizations. The downside is that, when something goes wrong with the infrastructure of those few organizations, a massive fraction of the Internet – and everyone using it – suffers.

Indeed, if services from the top providers like Amazon and Cloudflare go offline or acquire some form of vulnerability, a lot of businesses will be affected. There is, however, an upside to this. Because things are provided as-a-service by a single provider, a fix can be made in a central location and then rapidly propagated across all nodes.

In the case of Cloudbleed, a simple activation of a kill switch at Cloudflare switched off all affected features, thereby plugging the holes throughout its entire global infrastructure in a matter of seconds. As soon as the bug was fixed, that fix was then propagated throughout the infrastructure, almost instantly.

The rise of ubiquitous cloud service providers has altered the Internet landscape in a big way. In order to mitigate the risks that accompany this new landscape, on can take the lessons learned from Cloudbleed into consideration when developing new security strategies.

Phishing and its Impact on Businesses and Employees

Despite the many tools in place to prevent them, phishing attacks continue to be a menace to employees and businesses. In Q3 of 2016, the Anti-Phishing Working Group detected at least 340 hijacked brands per month. In the last month of that same period, they also found 104,973 unique phishing sites. In order to understand the implications of these statistics, one needs to gain a better understanding of phishing attacks, the motivations behind them, why they succeed, and their impact to business.

In a nutshell, a phishing attack is a fraudulent message, usually in the form of an email, which lures users into clicking a link. That link in turn either leads the victim to a malicious website or initiates a malicious download.


Anatomy of a Phishing Attack

Phishing email is a form of spam email; it’s an undesirable message sent in bulk to a large number of recipients. While traditional spam emails are mostly part of advertising campaigns, phishing emails are more sinister. The main goal of a phishing email is usually to obtain confidential information from the email’s recipient.

In essence, the following is what takes place during a phishing attack:

  1. First, the phishing email is sent to a large collection of email addresses. These days, the mass mailings are launched from zombie computers or devices that belong to botnets.
  2. If the phishing email was well crafted, the victim would be compelled to either click on a link found in the email body, or download an attachment.
  3. If the victim clicks on the link, he or she will likely be redirected to a landing page closely resembling a legitimate webpage of a popular and trusted company. Most of the organizations impersonated are banks, credit card companies, online payment service providers (e.g. PayPal), and even social networking sites. The use of a reputable brand name increases the probability of the victim performing the desired action (e.g. fill out a form or download a file).
  4. If the victim downloads an email attachment, he or she will likely end up installing a trojan that might contain a key logger, botnet client, ransomware, or just about any other type of malware.


Why Cyber Criminals Phish

The goal of most phishing attacks is to acquire what is known as personally identifiable information, or PII. This information includes data that, either individually or combined with other relevant data, can be used to identify an individual. Examples of this kind of data would include social security numbers, bank account numbers, credit card numbers, medical records, educational records, mailing addresses, biometric records, and so on.

Stolen PII is often sold in shady online marketplaces, where they will then be purchased by identity thieves. These cybercriminals then use the information to carry out credit card or banking fraud and other fraudulent transactions. The cost of a single piece of stolen personal information can range from a few dollars to thousands of dollars, depending on the specific information that has been obtained. For example, a random credit card number can cost $5; a medical record, $50; and a bank account credential, $1,000.

Looking at the total value of PII belonging to thousands of individuals makes it is easy to understand why phishing can be so lucrative.


How Phishing Attacks Succeed

Phishing relies on the time-tested art of deception. These days, cyber security experts and cyber criminals have dubbed these deceptive acts “social engineering.” Social engineering plays on people’s emotions, curiosity, fear, or plain gullibility.

A simplified example of what one might read in a phishing email would be as follows:

Congratulations! You just won in the 2017 Online Lottery. Please claim your prize by clicking the link below.”

Most people get excited when they are told they won something – even if they never bought a ticket for any “2017 Online Lottery” in the first place.

Some phishing emails play on fear and take advantage of recent events, for example, a massive data breach. The following is what one might receive in the wake of a PayPal data breach:


“Dear [insert your name here]


Earlier today, PayPal’s databases were hacked and several user accounts were compromised. We regret to inform you that your account was one of them. While no funds have been stolen yet, we can confirm that the hackers were able to acquire your login credentials. To prevent any financial loss, you need to reset your password immediately. Click the link below and follow the instructions to carry out the reset.”


The message above can be quite alarming and can spur a sense of urgency. For this reason, some recipients of this email would no longer stop to think and just do as instructed.

These deceptive messages are made more believable with the advent of HTML-based emails. Unlike plain text emails, HTML-based emails can be spruced up with graphics and formatted text. Hence, it’s easier to make them resemble official communications from a trusted or reputable source – like a bank or, in the example above, Paypal.

When people are faced with a well-written and professionally formatted email bearing a trusted logo, most of them won’t bother to verify its authenticity.


Increasing Email Open Rates and Clicks Through Spear Phishing

Traditionally, phishing emails followed a spray and pray tactic. Attackers typically sent out large volumes of emails without any regard as to who would end up receiving them. For example, of the thousands who would receive the “Paypal” email, only a few may actually own a PayPal account. As a result, the majority of those who would receive the email would mark it as spam.

To increase the efficiency of their attacks, phishers started resorting to more sophisticated techniques. One of these techniques is known as spear phishing. This is a more targeted phishing attack aimed at a specific individual or group of people.

Spear phishing emails contain elements closely associated with the target. For example, a spear phishing email may mention and may appear to originate from the target’s boss, their organization’s network administrator, or HR manager. In addition, it may follow the company’s standard email format and include the corporate letterhead.

Because spear phishing emails are so customized, their open rates and click-through rates are quite high. The people who conduct spear phishing attacks usually have even more sinister intentions in mind than just stealing PII.

Many of these attackers are often after high value targets buried deep inside the organization. Hence, the main purpose of the phishing attack might be to acquire administrative credentials for privilege escalation or to infiltrate the network in preparation for an APT (advanced persistent threat) campaign.

Spear phishing emails are typically laced with malicious attachments that often take the form of corporate files like PowerPoint presentations, reports, spreadsheets, resumes, and business documents. While these files appear as common file formats like .PDFs, .PPTs, .DOCXs, and .XLSs, they are actually executable (.EXE) files containing trojans that may even connect to remote command-and-control (C&C) servers.


Business Impact

Although phishing attacks are primarily aimed at individuals (more specifically, their PII), they can have other unintended, but nevertheless unavoidable casualties as well.

When phishers launch an attack, they usually need to hijack a legitimate brand. As discussed earlier, attackers typically set up a malicious landing page that closely resembles the web page of a trusted brand. This makes it easier to convince victims into responding to a call-to-action, such as filling out a form or downloading something.

These brands become casualties once the phishing campaign is discovered and later disclosed in news outlets or social media. This type of publicity can hurt the brand’s image, leaving the impression that its web pages are unsafe. Some customers might end up avoiding the brand’s legitimate websites for fear of accidentally landing on a fake web page.

In most cases, the people who do land on a hijacked brand’s website are likely customers of that organization. These people can lose confidence in the brand and may ultimately drop it for a competitor. Worse, if they actually become victims (i.e. their personal data get stolen), they might even file a lawsuit, or, if the data is covered by data protection regulations, the company can be levied fines for noncompliance.


How to Defend a Business against Phishing Attacks

There are a couple of ways to thwart phishing attacks, the first of which being user education. This method of avoidance is primarily designed to counter the social engineering aspect of the attack. Because users are the recipients of phishing emails, your employees must be trained to determine when an email can be considered suspicious.


Some indicators include:

  • Requests for personal information
  • Deceptive domain names (e.g. is certainly not a legitimate PayPal domain)
  • Generic salutations (e.g. Dear Sir instead of Dear [your name])
  • URLs that don’t match what is being displayed on the link (You can verify this by hovering your mouse on the link and inspecting the link that appears on your browser’s bar)
  • Emails with executable file attachments (the common file types include exe, com, jar, msi, bat, and scr, but there are many others)
  • Any email attachment that wasn’t expected (you can always verify with the sender)
  • Messages that elicit heightened emotions, whether of happiness, fear, pity, etc.
  • A sender who’s not familiar to you


Although user education is an important component in countering phishing attacks, it is by no means ironclad. Employees can forget or even disregard warning signs; hence, one will need to augment user education with something immune to human shortcomings.

Learn how our DNS Security Solutions can help detect and block fraudulent links, phishing campaigns, rogue antivirus downloads, and forced redirection to malicious domains.

*APWG Phishing Activity Trends Report  – 3rd Quarter 2016

What is an exploit kit?

Attackers who want to infect systems with malware usually need a vehicle to reach as many infections as possible. These days, that vehicle is most often an exploit kit. In this post, we take a closer look at exploit kits, where they fit in the cybercrime industry, what’s inside a typical toolkit, and most importantly, how they work.


A peek into the exploit kit industry

Before we talk about what an exploit kit (EK) is and how it works, let’s first discuss the financial incentive for developing these kits. What drives people to create exploit kits?

Contrary to what most people think, not everyone who commits cyber crime has the technical skills to “hack into a system”. There are those who carry out cyber attacks by simply relying on ready-made tools they purchased in black hat marketplaces on the dark web.

Let’s say that Joe reads this article and learns that ransomware campaigns can be quite lucrative. Being morally flexible, Joe decides to launch a ransomware campaign. Joe then realizes that ransom malware by itself is not enough. He still needs to deliver the malware onto a victim’s system. One way to do that is by taking advantage of certain vulnerabilities in the system. Luckily, people have already written programs for doing just that.

These tiny programs or pieces of code are called ‘exploits’ and can be purchased through black hat hacking forums. The prices of these exploits vary, with zero-day exploits generally priced higher. So if an attacker like Joe gets a hold of an exploit, is he good to go? Not quite yet.

One exploit typically can only target one vulnerability. It’s hard to predict what vulnerabilities are present in a system. So if Joe only targets one vulnerability, chances are he would only be able to compromise a few systems, while ignoring other systems that have other vulnerabilities. If Joe wants to infect those systems too, he needs to acquire exploits for those vulnerabilities as well.

It gets even more complicated because different exploits might be written by different authors. That means, he would have to communicate with several parties. It would be so much easier if he could only deal with one vendor. That’s where exploits kits come in.

An exploit toolkit or kit is a tool, usually written in PHP, that already comes with a collection of exploits. The people who develop exploit kits purchase exploits from exploit authors and package them into one tool. They (the exploit kit developers) then sell their kits to people like Joe.


Some exploit kit licenses have validity periods. Once the license subscription expires, you would need to purchase a new subscription to continue using it. Other exploit kits are offered as a subscription service. The rates typically range from a few hundred dollars per month to a couple thousand dollars per month. This typically includes tech support and updates or patches. For example, there may be patches that introduce new evasion techniques, new exploits, or support for certain malware.

Some of the most notorious exploit kits in recent history include:

  • Angler
  • Rig
  • Neutrino
  • Blackhole
  • Sweet Orange
  • Nuclear
  • Magnitude


Inside an exploit toolkit

When an attacker purchases an exploit kit, he’ll be provided with a management console. Here he’ll see various information and statistics pertinent to his exploit campaign. This is to help him monitor how the overall campaign and the individual exploits are performing.

In addition to the number of times each exploit type was delivered, the attacker will also see where those exploits actually landed. Mostly, he’ll see the countries that were targeted. Cyber attackers normally want to target specific countries (US is the usual favorite), so they want to verify whether the campaign was actually successful in that geographical region. Toolkits can focus on specific areas through geolocation based on the victim’s IP address.

Another key piece of information is the victim’s Operating System and web browser. Certain malware only works on certain operating systems (e.g. Windows), so it’s important for the payloads to be dropped in those systems.

Here’s a screen grab from a Youtube video showing Black Hole EK’s management console:

screengrab blackholeek

Lastly, a toolkit would typically include a module for uploading or selecting the desired payload. The attacker can either pick from a selection of payloads bundled with the kit or upload his own payload. Some of the most commonly used payloads include:

  • Click-fraud bots (e.g. Bedep)
  • Ransomware (e.g. CryptXXX, TelsaCrypt)
  • Spambots (e.g. Tofsee)
  • Banking Trojans (e.g. Zeus, Panda Banker)
  • Worms (e.g. Qbot)
  • Botnets (e.g. Andromeda/Gamarue)
  • And many others


How exploit kits work

There are different kinds of exploit kits, but the most popular are those designed to exploit vulnerabilities in web browsers and browser plugins like Flash, Silverlight, Java, and ActiveX.

Below is a simplified diagram illustrating a web-based exploit kit. The actual set ups are often far more sophisticated than this and can also involve other processes, but this should give you an idea of the basic structure.



1.    Victim lands on a compromised website

The first stage of an exploit kit attack begins when a victim visits a compromised website. These are usually popular, legitimate websites, including blogs, news sites, and social networking sites. Examples of high-traffic sites that have already been hijacked by exploit kit attackers in the past include: BBC, Yahoo, MSN, AOL, MySpace, Forbes, and New York Times, to mention a few.

The way attackers do this varies. Some attackers target vulnerabilities in CMS (content management system) plugins or in the CMS themselves. Others, like those that carry out domain shadowing, take advantage of weak login credentials. There are also those who perform cross-site scripting, SQL-injection, or FTP compromise. Perhaps the most popular method, though, is malvertising.

In a malvertising campaign, attackers target ad networks. This then allows them to reach a wide range of legitimate (and often high-traffic) websites without having to hack into the websites themselves.


2. Victim is redirected to the exploit kit’s landing page

Once the victim visits a compromised site or one that serves malvertising-infected ads, the victim’s browser will then be redirected to the exploit kit’s landing page. This redirection is carried out through an HTML iframe, 302 cushioning or some surreptitious code that the attacker previously injected into the legitimate website or malicious ad.

This article about the Stegano exploit kit offers a nice example of how a typical malvertising campaign and the use of a banner ad laced with a malicious script works.

As soon as the victim gets redirected to the landing page, the profiling process begins. Here, pertinent information regarding the victim’s browser and its plugins is collected. What the exploit kit will want to know is the kind of vulnerabilities that are present on either the web browser or the browser’s plugins. Because each browser or plugin version will have already been associated with a set of known vulnerabilities, it’s usually enough to just determine the version numbers.


3. Exploits are served

Once the version numbers (and consequently, the corresponding vulnerabilities) have been identified, the exploit kit will know which exploits to deliver. In most cases, the landing page is only used for profiling. The exploits and the payloads are usually hosted on a separate server. In fact, in many cases, these two (exploits and payloads) are likewise separated as well.

The first thing that gets delivered to the victim’s browser are the exploits. As you have already learned, these exploits will take advantage of the vulnerabilities that have been previously identified. If the exploit or exploits are successful, the exploit kit then delivers the final blow.


4. Malicious payload is delivered

At this final stage, the exploit kit drops whatever payload it was configured for. As mentioned earlier, the payload can be ransomware, a keylogger, a banking trojan, or just about any type of malware.


How exploit kit attacks succeed

The main reason that these kits are so effective is that the malicious payloads are usually delivered without the victim having to click or intentionally download anything. All the victim has to do is visit a compromised site, and the payload will be downloaded automatically in the background.

Known as a drive-by-download, this covert method is a staple in many exploit kits and is one of the primary reasons they succeed in delivering various forms of malware. Since the victim doesn’t notice anything alarming or suspicious, they are less likely to think anything is amiss.

Another major reason why these kits succeed is because a lot of people don’t patch their software. Patches typically include security updates that fix known vulnerabilities. So, if people don’t patch, the vulnerabilities will remain. In fact, some exploit kit exploits have been found to target vulnerabilities that have already been known for years. Until we have a better solution for handling updates or remove the incentive to launch these attacks, there will be a busy trade in exploit kits.

7 Biggest Malware Threats of 2017

biggest_malware_threats_2017There are few worse ways to start the new year than scrambling to recover urgently needed files encrypted by ransomware. Unfortunately, the chances of that happening in your organization only seems to be growing. What’s more, although ransomware infections are arguably the most publicized, they’re not the only malware poised to pounce in the Year of the Rooster.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles” – Sun Tzu

In this post, we help you prepare for this year’s wave of malware attacks by identifying which types of malware are most likely to hit your organization.


1. Ransomware

Easily the most disruptive, and publicized malware of 2016, ransomware is positioned to become a much bigger threat in 2017. Ransomware cyber crooks raked in no less than $1 billion last year. The amount of profit that can potentially be earned from this type of malware is enough to attract even more cyber criminals.

A ransomware attack is typically characterized by files or entire systems being held captive, usually through encryption, and freed only after victims pay up, usually through Bitcoin. While most victims are individuals, there were many instances when infections managed to spread throughout an organization and crippled entire networks, like in the case of the Hollywood Presbyterian Medical Center and San Francisco’s Municipal Transport Agency (a.k.a. Muni).

It’s easy to see why launching ransomware attacks is a lucrative business model. A large number (if not most) of victims are willing to pay. We discussed the possible drivers behind ransomware’s recent rapid growth in the blog post “The Secrets Behind Ransomware’s Surging Notoriety”.


2. IoT botnets

If it weren’t ransomware up there in number 1, it would most likely have been IoT botnets. Last year, we witnessed some of the largest DDoS attacks of all time. Some of these record-breaking attacks were launched not through typical zombie computers, but rather, through botnets of IoT (Internet of Things) devices.

Many of these attacks were carried out by a single botnet known as Mirai. Unfortunately, the source code of the Mirai malware was shared to the hacking community, setting into motion separate initiatives for the development of Mirai-like offspring. As more cyber gangs gain access to the code, the likelihood of new and improved versions of the malware is likely.

IoT adoption has started to go mainstream. If Gartner’s predictions were accurate, 43% of organizations ended up implementing IoT technology by the end of 2016. With even more companies planning to use IoT and several IoT vulnerabilities still waiting to be plugged, criminals are going to have a massive source of vulnerable devices at their disposal.


3. Extra cautious exploit kits

When the Stegano Exploit Kit was exposed last December, a lot of the attention was focused on how it used steganography to avoid detection. Although steganography certainly contributed to its avoidance capabilities, there was an even craftier mechanism working behind the scenes.

Before Stegano EK would proceed with each attack, it would first verify whether any monitoring or security product was present. If it found one, it would promptly retreat. It did this twice, in fact. First, before redirecting the browser to the exploit kit’s landing page, and secondly, before dropping the payload. This, as much as its use of steganography, allowed Stegano to avoid detection for so long.

By being extra cautious and extra selective of its targets, exploit kits like Stegano might not be able to infect as quickly as others, but it does enable them to remain in existence much longer. As is often said, the biggest malware infections are most likely the ones that have yet to be uncovered.


4. Android malware

Android continues to dominate the mobile market, as well as the mobile malware market. The Android platform has long been plagued with vulnerabilities and in July 2016 alone, Google released a massive security update that aimed to address 108 vulnerabilities in Android. Just last week, security researchers discovered what is now known as the Switcher Trojan, malware that infects Android devices and uses them to attack routers, altering the router’s DNS settings and rerouting DNS queries to attacker-controlled networks.

Smartphones contain mountains of confidential information, including passwords, credit card data, and a large collection of personal details. In many cases, particularly in BYOD environments, smartphones even contain company-owned data. The amount of valuable information that can be stolen from smartphones makes them a prime target for identity thieves and cyber criminals of all stripes.


5. Malware distributed through malvertising

The types of malware dropped through malvertising campaigns can vary substantially. Some drop spyware, some keyloggers, others ransomware, etc.

Malvertising often infects through drive-by downloads. This method of infection doesn’t require any deliberate action from the victim, making it particularly dangerous. The victim doesn’t have to click, download, or install anything. As soon as the victim lands on a web page serving a malicious or compromised ad, the victim will be automatically redirected to a malicious server.

That server can then download an exploit kit that will, in turn scan for vulnerabilities and subsequently drop the payload. All this happens in the background, without any hint to the user of it taking place. The level of obscurity achieved by drive-by downloads makes malvertising a very compelling means of attack.

In addition, some cyber crooks manage to hijack ad networks, enabling them to display their malvertising on multiple legitimate, high-traffic websites. In this way, even those individuals who take care to avoid sketchy websites can still be victimized.


6. Banking/financial malware

Not so long ago, banking trojans and botnets towered over the malware landscape. The first piece of malware that comes to mind is Zeus/Zbot, a trojan that became the foundation of what has now evolved into the Zeus malware family. This trojan primarily stole banking information through man-in-the-browser keystroke logging and form grabbing.

Malware developers built on top of Zbot to create even more sophisticated malware. One of Zbot’s offsprings is Gameover Zeus, a notorious botnet that infected over a million users around the globe. It stole login credentials and credit card data, which were later used to carry out banking fraud. Other descendants of Zbot include SpyEye, Ice IX, Citadel, Carberp, Bugat, and many others. Banks won’t be going away anytime soon, and while they’re here, they’ll always be a prime target for cyber criminals.


7. Point of Sale (POS) malware

Closely related to banking malware, in the sense that it also steals credit card and debit card information, POS or Point of Sale malware targets POS terminals. POS devices are simply specialized types of computers and actually run on operating systems like Windows, Unix, or Linux, making them just as vulnerable to malware as a traditional computer.

These terminals often process hundreds or thousands of transactions per day and thus store a ton of payment card data. Much of this data finds its way to hacking forums where it can be bought for identity or credit card fraud.

POS malware has become more popular than manual methods like skimming, which requires the installation of a device on the POS terminal. Skimming is time-consuming, and riskier for criminals since they have to be physically present in order to install the device.

Some of the more notable companies that were attacked in 2016 through some kind of POS malware include Wendy’s, Cici’s Pizza, and Rosen Hotels and Resorts. Of course, the most highly publicized attack involving POS malware happened a couple of years ago; the infamous Target data breach involved millions of credit and debit cards.

Like banks, credit cards aren’t going away. While e-commerce and online shopping is on the rise, most credit card transactions still happen in grocery stores, restaurants, and other brick-and-mortar establishments. As such, POS malware will continue to thrive

Malware Using Steganography to Hide Malicious Code

The biggest malware infections are probably the ones that have yet to be uncovered. Earlier this month, security researchers revealed a massive malvertising-based exploit kit whose earliest variants may have been operating since 2014 and whose infected banner ads might have already been displayed to millions. How could it have remained hidden in plain sight for so long? Apparently, it evaded detection through a combination of fingerprinting/probing and steganography.

The folks at ESET, who recently carried out extensive research on this cyber attack, are attributing the infections to what they now call the Stegano exploit kit. The name comes from the way the exploit kit conceals its malicious code on banner ads, i.e., through steganography.

Steganography is a known technique (not always for malicious purposes) for concealing content inside another piece of content. In most cases, that “other piece of content” is an image. And in this particular case, that image is the one on the banner ad. The content being concealed here is a malicious script and some accompanying variables.

Stegano EK is believed to have reached millions of users. The reason is because it managed to serve its malicious ads on advertising networks whose content is displayed on high traffic news websites. The volume of visitors on these sites number in the millions … per day.


An overview of how the Stegano exploit kit works.

1. Initial environment check.

When a user arrives at an infected news site’s web page, the web page loads along with the malicious banner ad. But before loading the ad, Stegano does an initial check. It does this through a modified version of countly. Countly is a tool normally used for web analytics, so it doesn’t raise any red flags.

The modified tool then reports back to the attacker’s server, providing it with information that enables the server to determine whether to display a clean ad or a malicious ad.


2. Malicious ad is served

The malicious ad is almost identical to the clean ad, except that it has a slightly modified alpha channel. The alpha channel is that part of an RGBA (red green blue alpha) image that dictates a pixel’s degree of transparency. Because the change in the malicious image’s alpha channel is so minimal, the difference between the malicious ad and the clean ad is virtually imperceptible to the naked eye.

However, because a banner’s image consists of a large number of pixels, that difference is enough to conceal information. In this case, malicious script. That script then checks the user’s system for a vulnerability in Internet Explorer (CVE-2016-0162) which allows the exploit kit to determine whether any tools and applications normally used by security professionals are present in the system. If any packet capturing, sandboxing, virtualization and similar applications are found, the exploit kit promptly backs off.


3. Exploit stage

In the event the exploit kit determines the coast is clear, it then redirects the victim’s browser to the exploit landing page. The landing page then loads a Flash file, which in turn exploits any of three Flash-related vulnerabilities (CVE-2015-8651, CVE-2016-1019, CVE-2016-4117).

If the exploit succeeds, Stegano then drops its payload(s), which may range from keyloggers, trojans, to ransomware. Before downloading the payload, Stegano performs yet another check to determine the presence of security tools. It’s this highly cautious approach (coupled with steganography) that has allowed Stegano to avoid detection for so long.


Other malware that has used steganography

While the use of steganography is certainly a unique way of hiding malicious information, Stegano EK isn’t the only malware that has employed this technique. Here are some examples of malware that have also done it in the past.



A variant of the notorious banking trojan Zeus/Zbot, ZeusVM is one of the more popular pieces of malware that has used steganography. Unlike Stegano though, ZeusVM didn’t hide malicious code in an image. Instead, it hid its configuration data in it. This data, which is equally vital to the malware’s functionality, included domains of banking and financial institutions which the malware targeted.

The configuration data was appended to the image and encrypted using Base64, RC4, and XOR to make it indecipherable to anyone who decided to inspect the image more closely. The ZeusVM toolkit, which included a builder that would enable the user to inject the malware’s config to any JPG file, was spread online, so several script kiddies were able to get their hands on it.



Also known as VAWTRAK, Gozi is a banking trojan that steals personal information and credentials (usually through screen captures and keyloggers) that are then used by the attackers to carry out fraudulent transactions. Gozi leveraged steganography to hide a configuration file that contained a list of domain names that in turn corresponded to its Command and Control servers.

The configuration data was hidden in what is known as a favicon. This is a tiny icon (.ico) associated with a website that’s displayed on a web browser. So, for example, you have favicon for Wikipedia and a different favicon for, say, Yahoo. Because it’s normal for websites to be accompanied by a favicon, security solutions failed to flag the favicon downloads as threats.

Gozi more closely resembled Stegano in the manner by which it hid malicious information. Unlike ZeusVM, which simply appended malicious information to the image, Gozi (like Stegano) made very small changes to the image’s pixels. But while Stegano altered the alpha channel, Gozi altered the least significant bits (LSB) of the R, G, B, and A parameters of each pixel.



Most malware that use steganography hide malicious information in visually appealing images like cats or sunsets. However, there is one that hid the information in what looked like plain white images but actually had very small alterations in its pixels.

The use of “white color” is actually very clever because the naked eye can’t differentiate between a pure white pixel (RGB = 255,255,255) and one that’s slightly grey (e.g. RGB = 254, 254, 254). Again, that difference, when spread across the pixels that comprise the entire image, is enough to contain malicious information.

This is the kind of image that Lurk used. Lurk is primarily a downloader. When it was discovered, Lurk’s usual payload was click-fraud malware. To retrieve the URL of the malware it was configured to download, Lurk first downloaded an image (the “white” image we discussed earlier), extracted the LSB from each pixel, performed some XOR operations to decode, and then used the retrieved URL to download the actual payload.

To illustrate how difficult it is to distinguish between pure white (RGB=255,255,255) and slightly greyish white with RGB = 254,254,254, try to compare the two images below. The top NEMESIS logo uses pure white, while the bottom logo uses slightly greyish white with RGB = 254,254,254.


Can you tell the difference?




This is one piece of malware that has a couple of similarities with Stegano. Stegoloader is primarily an information stealer but consists of several modules. Its downloader module is the one that employs steganography.

Its use of steganography isn’t the only characteristic that makes Stegoloader similar to Stegano. First, like Stegano, Stegoloader initially inspects the target system to make sure it’s not running in an analysis environment or that any security tools are present. If it determines that the environment is not safe enough, it automatically aborts the attack. Secondly, unlike Gozi and Lurk, which simply hid URLs, Stegoloader (like Stegano) also hid code.


How to protect your system from Stegano

There are a couple of ways to protect yourself from a Stegano EK attack. There’s absolutely no way you can identify a malicious banner ad by simply looking at it, so you can forget about countering the steganography part of the attack.

First, you can simply avoid using Internet Explorer. The first vulnerability Stegano exploits, which allows it to detect any security monitoring software, is an IE vulnerability. So if you use Chrome, Firefox, or Safari, that could put Stegano off.

Second, you can either update your Adobe Flash installations, switch Flash off, or stop using Flash altogether. This month, Chrome will stop using Flash as the default enabler of web media. The makers of Firefox, Safari, and Edge (Microsoft’s replacement for IE) are also planning a similar move, so that’s something you might want to put into consideration when prescribing browsers to your end users.

Third, you can deploy advanced anti-malware solutions. Remember that, as part of Stegano’s (and Stegoloader’s) security avoidance techniques, it scans for security tools. If it finds one, it will back off.

SF Transit System Held Hostage by Ransomware

sf-muni-ransomware-attackWhile most ransomware incidents go unreported, the attack on San Francisco’s Municipal Transport Agency (locally known as Muni) last Black Friday was hard to keep under wraps. The conspicuous message on the screens at ticketing agents’ booths said it all: “You Hacked, ALL Data Encrypted, Contact For Key (,Enter Key.”

SFMTA, which operates fleets of buses, cable cars, historic streetcars, light railway vehicles (subway), trolley buses and a handful of other public transportations, is now part of a rapidly growing list of businesses that have been victimized by ransomware. For more about this highly disruptive menace of a malware, read our post “The Secrets Behind Ransomware’s Surging Notoriety”.

The disruption from the ransomware attack on Muni, which affected over 2,000 computers, began Friday night and continued the entire Saturday. Affected systems had their hard drives encrypted, forcing the SFMTA to switch off ticket machines at the subway stations. As a result, the commuters were able to get free rides that weekend.

People who communicated with the email address left by the hackers were told that the ransom amount was 100 bitcoins, roughly equivalent to $73,000. This is much bigger than another high-profile ransomware attack that happened earlier this year.

In that attack, the Hollywood Presbyterian Medical Center ended up paying the ransom of $17,000 worth of bitcoins. Although most attacks only cost about $600-$700, there have been reports of ransom demands reaching up to as high as $150,000.

According to the extortionist who replied at the Yandex email address, SFMTA was not a victim of a targeted attack. Rather, it was more likely that someone working at SFMTA unwittingly downloaded a trojan that actually contained the ransomware. The reason the malware was able to spread through the network was likely because the user might have been using a workstation with admin level privileges.

This is consistent with the common characteristics of ransomware. They’re usually designed to spread through non-targeted phishing attacks and exploit kits. Whomever accidentally downloads the malware becomes a victim. Not all ransomware has worm-like capabilities that allow it to propagate through the network, but sadly for SFMTA, this one did.

There has been no indication that SFMTA paid any ransom to get their systems back. In fact, it’s believed their IT folks managed to recover from backups. Backups are an effective way of recovering from a ransomware attack. However, you shouldn’t be over-dependent on them, as ransomware developers have started introducing features that enable their malware to spread to backup systems as well.

So, which particular ransomware was responsible for this attack? Apparently, that distinction goes to HDDCryptor. Upon infection, which is initiated through a downloaded executable, HDDCryptor drops several components in the Windows root folder and then runs a service known as DefragmentService. The service is responsible for maintaining the malware’s persistence in the infected system.

HDDCryptor is designed to identify currently mounted drives as well as previously connected drives and then encrypt all files. To encrypt, the malware relies on an open source disk encryption software known as DiskCryptor. DiskCryptor also enables HDDCryptor to overwrite the Master Boot Record and display the ransom message.

Because of the malware’s capability to scan the system for mounted drives and previously accessed network folders, it’s highly possible that backups (depending on how they were configured) were also infected.

This particular case brings to the fore the cyber threats faced by public transportation and utilities. While this attack fortunately did not result in any physical harm, future attacks might not be as harmless.

How Does A Botnet Attack Work?

botnetBotnets are responsible for many of the cyber attacks we encounter these days; from DDoS and spam attacks to keylogging and click fraud. In today’s post, we take a closer look at how a botnet attack works – how it gains a foothold into each botnet slave, how each slave communicates with the C&C servers, and how the entire botnet carries out nefarious acts.


Malware infection

All botnets are networks of enslaved devices known as “bots”. That’s really where the term “botnet” comes from. And so, before a botnet comes into existence, a large number of devices must first be infected with malware that turn these devices into unwitting bots (a.k.a. zombies).

So how do these devices get infected in the first place? Well, it depends on the type of device. In the case of desktops, laptops, phones, and tablets, these devices typically get infected when the people using them either:

  1. Visit a malicious site and download malware without noticing it (a.k.a. drive-by-download) or
  2. Consciously download a file through an email or website without knowing it’s actually malware (a.k.a. a trojan).

In the case of IoT devices, they usually get compromised after attackers actively break into them. For example, the attacks that ensnared IoT devices into the Mirai botnet and Mirai-wannabes, the attackers used automated tools that scanned networks for weak passwords, broke in through brute force, and installed the malware.

Once devices become infected and become bots, they then communicate with the command and control servers or C&Cs.


Botnet C&Cs

The C&Cs are the servers that deliver commands to the bots, directing them to targets and instructing them what to do. Traditionally, botnets operate under a client-server model, wherein the bots act as the botnet clients and the C&Cs act as the servers. There can be one or more Command and Control servers in a botnet.

Having multiple C&Cs provides redundancy and enables botnets to acquire high availability capabilities. Meaning, if one C&C goes down, the botnet clients can still receive commands from the other C&Cs. Nevertheless, having multiple C&Cs doesn’t make a client-server-type botnet indestructible. Its survival still relies heavily on the C&Cs. If the C&Cs are identified and eventually brought down, the entire botnet will be no more.

This is how massive botnets like Mariposa and Bredolab were dismantled. After their C&Cs were tracked down, the end of these malicious networks became imminent.

Today, many botnets follow a different architecture. To avoid total reliance on a group of C&Cs, these botnets now use a P2P model, wherein each botnet client also functions as a C&C. This type of botnet is much harder to take down.


Botnet Communications

Most bots communicate with their C&Cs using either one of two communications protocols – IRC (Internet Relay Chat) or HTTP (HyperText Transfer Protocol). Other botnets also employ other communication methods but these two are definitely the most commonly used.

IRC communications can be easily automated (using scripts). In addition, open source IRC servers are readily available. That’s why this protocol used to be a perfect fit for botnet creation and deployment. During infection, a typical botnet malware would install an IRC client, which in turn would then communicate with the IRC server on the C&C.

The characteristics of IRC, while a boon for botnet operations, has ironically also become many a botnet’s undoing. If you really think about it, Internet Relay Chat is no longer a common method of communication (most people now use Instant Messaging applications). And so, ever since IRC became associated with botnets, the presence of IRC packets has often raised red flags. Some system admins even started blocking IRC packets in their firewalls.

It is for this reason that malware writers have started to turn to a more firewall-friendly option as their botnet communication protocol of choice. And what network protocol can be more firewall-friendly than HTTP? All websites (including popular ones like Google, Facebook, and Amazon) all communicate via HTTP. So if a botnet uses HTTP, there’s a lower chance of it getting flagged down because, unlike IRC packets, HTTP packets don’t easily stand out.

Zeus, one of the most notorious botnets ever, communicated via HTTP. In fact, several exploit kits incorporate HTTP communications into their botnet malware payloads.


Botnet attacks

One of the most common botnet attacks is the DDoS or Distributed Denial of Service attack. In this type of attack, all bots send out requests to a target server with the purpose of overwhelming it and preventing legitimate requests from getting through or processed.

Another common botnet attack – in fact, arguably the most common cyber attack that employs botnets – is sending out tons of spam. In a typical spam attack, bots send out spam emails to target email addresses with the purpose of getting click-throughs and, ultimately, generating ad revenue.

Botnets can also be used to steal information from enslaved devices. Some bot clients operate as keyloggers that record end user keystrokes. Keyloggers can, for example, record the password characters an end user enters during login and then send this information to the bot herders.

Lastly, botnets can also be used for click fraud activities. Bot clients can click on ads and trick ad networks that the clicks came from legitimate end users.


Preventing botnet attacks

Botnet malware infections can be avoided by educating end-users about the risks and best practices of downloading email attachments and visiting web sites. Of course, this countermeasure has its limitations. Most end users find security practices too tedious and time consuming, and often disregard them. Further, some threats (like drive-by-downloads) are just too difficult to avoid.

The best way would is to employ advanced malware protection solutions. These solutions typically combine advanced network behaviour analysis and real time intelligence to detect even the most stealthy malware infections.

Mirai Isn’t the Only IoT Botnet You Should Worry About

mirai-iot-botnetIoT botnets have been responsible for multiple record-breaking DDoS attacks that managed to cripple even some of the most resilient networks in the world.

So far, the largest attacks have been caused by one particular malware family – Mirai. Although the original botnet is probably on its way out, its offspring and competitors in the malware trade are on the rise.




Record breaking DDoS attacks

The Mirai’s claim to fame included massive attacks on the Krebs On Security site (620 Gbps), French web host OVH (1 Tbps), and DNS provider Dyn (1.2 Tbps). That attack on Dyn, the largest DDoS on record (for now), prevented users in Europe and North America from connecting to a large number of popular sites.

Twitter, Amazon, CNN, PayPal, Reddit, Visa, SoundCloud, and AirBnB were just some of the many high-profile sites that were affected by that single attack.

Mirai malware source code

There seemed to be a sliver of good news when a Hackforums user, whom some believed was the creator of Mirai, expressed intention of hanging up his/her cape. Going by the nickname of “Anna-senpai”, the user posted that when he/she first entered into the DDoS industry, he/she “wasn’t planning on staying in it long.”, adding that “I made my money, there’s lots of eyes looking at IOT now, so it’s time to GTFO”

But as it turned out, the entire announcement was really a portent of what could potentially be an even greater threat. The user continued the post saying, “So today, I have an amazing release for you…”. That release turned out to be the source code of the Mirai malware itself. The source code can now be found on Github.

So with the Mirai source code out in the open, what else could anyone expect? Naturally, it shouldn’t take long for other miscreants to develop their own versions of IoT botnet malware.

That’s probably what happened here…



Very recently, a botnet with similar characteristics as Mirai was discovered by researchers at white hat security research group Dubbed Linux/IRCTelnet, this botnet snags IoT devices by taking advantage of the default passwords hard-coded in them. These passwords are usually weak (and hence easily broken by brute force attacks) or have already been disclosed in hacking forums (some, via the Mirai botnet).

The botnet clients receive commands from malicious C&C IRC servers through the Telnet protocol. To cripple targets, the Linux/IRCTelnet can carry out Denial-of-Service mechanisms like UDP flood, TCP flood, and several other attacks through both the IPv4 or IPv6 protocols.


Another IoT botnet we should be worried about is Bashlite. While Linux/IRCTelnet is still on the rise, Bashlite is already quite well established. Apparently, this malware family has already managed to infect a million endpoint devices, the majority of which are IoT devices, and has even been used to conduct DDoS attacks-for-hire.

Like the other two IoT botnets, Bashlite also exploits default usernames and passwords. It can launch TCP and UDP floods, and can even carry out HTTP attacks.

The malicious code used by these types of malware reside in memory. So, theoretically, they can be removed by simply restarting the compromised devices. However, the volume of scans conducted by these malware are so large, that they can also as easily re-infect the restarted devices.

The use of default or non-configurable login credentials is one of the vulnerabilities we outlined in our post “IoT Vulnerabilities – What Should You Secure?”. Unless this vulnerability, which exists in a large number of IoT devices out there, is addressed, IoT botnets like Linux/IRCTelnet and Mirai will continue to exploit it.

IoT Vulnerabilities – What Should You Secure?

iot-vulnerabilitiesWe’ve already seen what IoT vulnerabilities can lead to. The massive DDoS attacks on DYN, was easily one of the largest DDoS attack ever. As it turned out, that attack was launched not from the usual botnet of hijacked servers, but from a multitude of IoT devices.


It happened before. It can happen again.

Sadly, the use of IoT devices as an attack vector is just one of the myriad of security issues that now plague this nascent technological ecosystem. It’s important to grasp the implications of these developments and see if we can learn from what has happened in the past.

Not so long ago, we also saw the explosion of the Internet. During the early stages of its rapid growth, architects, engineers, and developers rolled out wave upon wave of technologies that, while equipped with great functionality, were seriously lacking in security. Protocols like FTP, HTTP, and Telnet are the first few examples that come to mind.

Many of these grossly insecure technologies, which even now are still used by many organizations, are putting people and businesses at risk. Attackers exploit their vulnerabilities to steal confidential information, infiltrate networks, or carry out a variety of nefarious acts.

Alarmingly, we seem to be experiencing deja vu with the Internet of Things. Stimulated by the almost unlimited supply of IP addresses through IPv6 along with technological advancements and cost reductions, we’re now seeing a market being flooded by a plethora of products. But close inspection of these products reveal that many of them were built with very little regard to security.

The Open Web Application Security Project has identified these ten (10) as the top vulnerabilities and security issues that afflict most IoT devices and their supporting systems.


1.   Insecure Web Interface

Most IoT devices are administered through a Web Interface. Unfortunately, many of these Web interfaces have weak security. For example, some of them simply accept login credentials in plaintext. Others don’t require the use of strong passwords. Still others don’t have provisions to lock out users who have made several failed login attempts (an indication of a brute force attack). If these weaknesses are not addressed, they can be exploited and subsequently result in data loss or even loss of control over the device.


2.   Insufficient Authentication/Authorization

When IoT is introduced into highly critical areas like energy, healthcare, manufacturing, transportation, and telecommunications, run-of-the-mill authentication/authorization systems are not enough. IoT systems deployed in mission-critical areas must be equipped with multi-factor authentication and granular access control mechanisms that can substantially reduce the risk of unauthorized access.

Without strong authentication/authorization systems, administrative user accounts can easily fall into the hands of impostors, who will then have the ability to execute commands or access other parts of the internal network. These malicious individuals can then wreak havoc and endanger lives and property.


3.   Insecure Network Services

IoT systems rely heavily on network communications. For this reason, these networks must be tightly secured. Otherwise, network services can be compromised through buffer overflows, fuzzing, DDoS, and other forms of attacks.

First, devices can be rendered unusable. Second, they can either be subjected to a denial of service attack or themselves used to launch such attacks. The DDoS attacks on and DYN are perfect examples of what can happen when IoT devices fall into the wrong hands.


4.   Lack of Transport Encryption/Integrity Verification

In an IoT environment, data transmissions are usually carried out between several endpoints. There may be data exchanges between:

  • Mobile apps and front-end cloud services
  • Web applications and front-end cloud services
  • IoT devices and back-end cloud services
  • Mobile apps and IoT devices
  • IoT devices and other IoT devices

Ideally, these data exchanges should be transmitted through TLS-protected protocols or other secure channels. But if these communications are carried out over unencrypted protocols, transmitted data can be intercepted and acquired.

Depending on the kind of data that ends up compromised, attackers can do different things to it. If it were login credentials, those credentials could be used for gaining access to the system. Other pieces of data could be aggregated and then used to provide insightful information regarding certain behaviors of either the users or the system as a whole. Still others could be tampered with, thereby harming the integrity of the system.


5.   Privacy Concerns

Some IoT devices collect and store personal information such as the user’s birthday, phone number, home address, gender, or, worse, financial or health information. This can have huge repercussions from a privacy perspective, as personal information can be used to perform identity theft. Businesses that use these kinds of IoT devices are subject to the requirements of laws and regulations like HIPAA, PCI-DSS, SOX, GLBA, and several state data breach notification legislations.

Thus, if your business is operating in a highly regulated industry and you’re planning to deploy IoT devices in the workplace, you should make sure personal information is adequately protected.


6.   Insecure Cloud Interface

Cloud services are vital to IoT systems. They facilitate data exchanges between IoT devices and their respective web/mobile applications as well as data exchanges between IoT devices and other IoT devices. It’s also where the bulk of the data gathered by IoT endpoints are stored and processed. This data is used for analytics, control, integration with enterprise applications, and several other purposes.

It’s therefore imperative to ensure the security of cloud interfaces. Failure to do so may result in massive data loss as well as loss of control of all devices connected to the cloud platform. Worse, if these cloud services are also connected to enterprise applications, those applications can likewise be at risk of getting attacked. Poorly designed cloud interfaces usually suffer from weak authentication/authorization mechanisms, lack of data-in-motion encryption, and other access control deficiencies.


7.   Insecure Mobile Interface

There are usually two ways to administer/manage IoT devices. One is through a web interface, which we discussed earlier, another is through a mobile interface, i.e. through an app running on an iOS, Android, or Windows device. Like web interfaces, mobile interfaces need to be equipped with strong authentication/authorization mechanisms.

If an attacker manages to gain unauthorized access into an IoT device’s corresponding mobile app, that attacker will in turn be able to control the IoT device. In other words, he could, for example, open doors, manipulate processes, cut off power, or shut down support systems.


8.   Insufficient Security Configurability

Secure devices are usually equipped with configurable security features. You can, for example, choose the number and type of characters required for password authentication. It might be all right if the built-in security level is only high/strict. But this is seldom the case. Devices that have non-configurable security are usually set to low levels of security.


9.   Insecure Software/Firmware

Some IoT devices perform firmware updates (mostly during restarts or at regular time intervals) through insecure network protocols like TFTP. On its own, TFTP is neither encrypted nor is it equipped with strong authentication features. Hence, it is highly vulnerable to man-in-the-middle attacks.

Once an attacker is able to grab the firmware update as it traverses the network, he could modify it to serve his own purposes. After tampering with it, the attacker can then push the modified update to the device and subsequently gain control. If the device is a hub that communicates with other IoT devices, the attacker might then be able to take over those devices as well.

These man-in-the-middle attacks are typically carried out in the local network. However, it’s also possible to perform a malicious update through Internet-based attacks like DNS hijacking.

Equally important is the ability of the device to perform security updates. If the device is incapable of carrying out updates, it wouldn’t be able to patch security vulnerabilities.


10.       Poor Physical Security

The physical security of an IoT device, especially one used in a business setting, is as critical as the other technical security we mentioned earlier in this post. Imagine what could happen if a malicious individual gains physical access to a mission-critical device.

He could remove or break into the storage medium and extract whatever information is stored there. If the device is equipped with external ports like a USB port or an SD card slot, the intruder could gain access through those and attack the operating system or storage medium.

It might seem like a pretty long list but there’s really no way around it. IoT is poised to be tightly interwoven into the fabric of society. If IoT systems can be easily compromised, the potential damage to people (not just IT systems or infrastructure) can be catastrophic. It is therefore imperative that businesses carefully scrutinize what and how IoT systems are incorporated into the organization and ensure that more than just adequate security is enforced.


Learn how Defence Intelligence can improve your security posture

DDoS Takes Down Krebs’ Site

super-ddos-akamai-krebsonsecurityLate last week, one of the leading sources of cyber security news was shut down after getting hit by one of the largest DDoS attacks in history. The massive assault on came after the site’s owner, Brian Krebs, reported on the exploits and business operations of a company that offers DDoS attacks-for-hire services.

A couple of weeks prior to the attack, Krebs brought to light the activities of vDOS, a company that rendered services for people who wanted to subject certain organizations to a Distributed Denial-of-Service (DDoS) attack. This type of attack is designed to cripple servers by overwhelming them with a flood of network traffic.

vDOS is believed to be behind many of the larger DDoS attacks that have been carried out in the last couple of years. The group had been operating under the radar all this time and is estimated to have amassed no less than $600,000 USD.

In Krebs’ exposé, it was revealed that vDOS was operated by two Israeli teenagers who launched their attacks mainly through servers in Bulgaria. According to Kreb’s article, vDOS not only provided DDoS services to direct customers, they also provided “firepower” to other outfits who, like them, also offered booter services.

Krebs managed to acquire substantial information about vDOS through a source who was investigating another booter service provider called PoodleStresser. During the investigation, that source was able to acquire configuration data from PoodleStresser’s attack servers. Some of the configuration data pointed to vDOS. The source then managed to gain access to vDOS’ servers and acquire databases and configuration files, which in turn led to more disclosures.

The two alleged owners of vDOS were eventually arrested by the FBI (although it’s not known whether the arrest was fueled by Krebs’ revelations). The duo have since been released under a bond of USD $10,000, placed under a 10-day house arrest, and prohibited from using the Internet or telecommunications equipment for 30 days.

But that wasn’t the end of it. About two weeks later, was under a DDoS attack. It wasn’t the first for Krebs by any means, but it certainly was (by a very big margin) the largest. Akamai, which provides pro bono DDoS protection to, was able to withstand the assault at first, but at about 620 Gbps, the attack traffic began to take its toll on Akamai’s resources. To continue defending against the sustained assault meant Akamai had to deploy millions of dollars-worth of resources.

Eventually, Akamai had to throw in the towel and had to temporarily go offline. As of this writing, is back online. It’s now being secured by Project Shield, a free DDoS protection service owned by Google.

Later, analysis of the attack revealed that, unlike most large scale DDoS attacks, which relied on botnets of misconfigured DNS servers, this one seemed to be originating from hacked IoT-enabled consumer electronic devices like routers, digital cameras, smart firewalls, light bulbs, thermostats, espresso machines, and many others.

These events underline how serious the booter services menace has now become and has taught us a few important things:

  • The scale of this attack is alarming and causes everyone to re-evaluate their defences.
  • Attackers have added IoT devices (of which there are billions) to their real-world arsenal.
  • The criminal business model for DDoS has matured and become very lucrative.

It looks like the Internet of things is really growing up.

Now might be a good time to get a free network risk assessment.